为什么从用例续写开始？
1）测试分析和设计是整个测试活动中对于业务和技术理解能力要求最高的部分
测试人员在完成这类工作时，不仅仅需要参考本次业务改造对应的需求文档/PRD, 也需要参考过往的同类需求、系统的实现、业务背景等等各个方面的知识。而目前即使LLM自身能力已经相当强悍，但是在现实中大部分公司团队的软件工程能力还处于作坊阶段，研发团队自身的数字化水平很低，无法通过RAG等方式为LLM提供除了PRD之外的上下文，会严重限制LLM进行测试设计的效果。
而用例续写场景相对简单，主要依赖已有测试用例的模式与逻辑，对额外上下文依赖度低。即使团队数字化水平有限，LLM 也能基于现有的用例历史数据进行学习与模仿，避开因上下文不足导致的 “信息盲区”，在可控范围内发挥作用，提升测试用例编写效率，避免因团队数字化短板导致 AI 应用失效。
2. 匹配 LLM 能力优势，解决测试用例编写痛点
测试用例编写存在大量重复劳动（如下图所示，同一测试点下，测试步骤、数据高度相似），这不仅耗费人工精力，也被视为测试工作 “低值易耗” 的典型问题。
LLM 的核心能力之一是通过学习已有模式生成内容，“参考先前用例续写新用例” 正好契合这一特性，与 AI 在软件开发中广泛应用的 “代码续写” 逻辑一致。利用 LLM 进行用例续写，能高效处理重复、机械的编写任务，将测试人员从简单劳动中解放，使其聚焦于复杂场景设计、业务风险分析等更具价值的工作。这种方式充分发挥了 LLM 的能力优势，同时直接解决了测试用例编写环节的现实痛点，是 AI 技术与测试工作结合的高效切入点。
3. 降低项目风险，提升团队信心
用例续写功能相对简单明确，实施过程中技术复杂度与不确定性较低，失败风险可控。与直接尝试复杂的测试分析、设计等 AI 应用相比，用例续写更易快速取得阶段性成果（如生成一定数量符合要求的测试用例），让团队切实感受到 AI 对测试效率的提升，从而增强对 AI + 测试进一步深入应用的信心，减少团队对新技术引入的抵触情绪，为后续更复杂的 AI 测试应用（如智能测试分析、自动化场景设计）奠定信任基础。
一、方案核心目标
##以下内容是豆包生成，不保证与实际实现方案的一致性。内部项目已完成测试要点-测试用例-自动化用例的续写POC##
以下是针对 LLM 测试用例续写 的完整方案设计，实现从 “测试要点” 自动扩写为 “完整测试用例（含步骤 + 数据）”，结合知识库检索、提示工程及验证机制，确保生成质量与业务适配性：
输入：测试要点（如 “支付金额与订单金额一致”）
输出：结构化测试用例（前置条件、测试步骤、测试数据、预期结果）核心能力：利用 LLM基于历史用例模式，生成符合业务规则的测试步骤与数据，支持 正常 / 异常 / 边界场景 全覆盖。
二、方案架构与技术栈
三、核心模块设计
1. 测试要点解析模块
·关键词提取：
o利用 NLP 工具（如 spaCy）解析测试要点，提取 功能模块（如 “支付”“订单”）、测试类型（如 “功能测试”“边界条件”）、核心对象（如 “金额”“支付方式”）。
o示例：输入 “支付金额与订单金额一致” → 功能模块 = 支付，测试类型 = 功能测试，核心对象 = 金额一致性。
·场景分类：
o映射到预设的 测试场景标签（正常流程 / 异常流程 / 边界条件 / 合规性），指导后续生成方向。
2. 历史用例知识库构建
·数据来源：
o收集历史人工编写的 优质测试用例（包含完整的步骤、数据、预期结果），按功能模块（支付、订单、用户中心等）分类存储。
o标注关键特征：如 “支付方式 = 余额支付”“测试类型 = 异常场景”“数据类型 = 边界值”。
·检索策略：
o基于 RAG（检索增强生成）：将测试要点关键词与知识库中的用例标签匹配，返回 Top 3 相似用例 作为 LLM 生成的参考上下文。
o示例：输入 “免密支付限额验证” → 检索到历史用例 “PAY-015 免密支付限额验证” 及其步骤模板。
3. LLM 生成引擎（核心逻辑）
·提示工程设计：
o基础提示模板（引导 LLM 生成结构化内容）：
【任务】根据测试要点“{测试要点}”，扩写完整测试用例，包含：
1. 前置条件（需明确用户状态、数据准备，如“用户余额50元，绑定银行卡”）
2. 测试步骤（分步骤描述操作，每步不超过20字，如“1. 选择余额支付”）
3. 测试数据（分正常/异常/边界数据，如正常数据=订单金额80元，异常数据=订单金额0元）
4. 预期结果（与步骤对应，明确状态/数据变化，如“1. 系统提示‘余额不足’”）
【参考用例】{相似历史用例内容}
【业务规则】{补充业务规则，如“免密支付限额为100元，超过需二次验证”}
o数据生成引导：
§要求 LLM 按 3 类数据 生成：
·正常数据：符合业务规则的合法输入（如订单金额 = 99 元，≤免密限额）
·异常数据：违反规则的非法输入（如订单金额 =-50 元，负数金额）
·边界数据：刚好触发规则的临界值（如订单金额 = 100 元，等于免密限额）
·生成优化：
o限制输出格式为 表格或结构化文本，便于后续解析和导入测试管理工具。
o对复杂场景（如跨系统交互），在提示中加入 接口调用逻辑（如 “支付成功后需调用订单状态更新接口”）。
4. 验证与优化模块
·自动化校验规则：
o格式校验：检查是否包含 4 大必备字段（前置条件、步骤、数据、预期结果），步骤数是否≥3 步。
o逻辑校验：
§测试数据是否覆盖 3 类场景（正常 / 异常 / 边界），且每类至少 1 条。
§预期结果是否与步骤、数据一一对应（如输入负数金额，预期结果应包含 “错误提示”）。
·人工审核接口：
o对自动化校验不通过的用例，推送至测试人员进行人工修正（如补充业务细节、调整步骤顺序）。
o建立 反馈闭环：将人工修正后的用例反哺知识库，优化 LLM 训练数据。
四、实施步骤示例
输入：测试要点 “支付金额与订单金额一致”
1.解析与检索：
o关键词：支付、金额、订单、一致性 → 匹配到历史用例 “PAY-016 支付金额与订单金额一致（含运费 / 税费）”。
o业务规则：支付金额 = 商品价 + 运费 + 税费，优惠可抵扣。
2.LLM 生成输出：
【前置条件】
1. 用户登录，订单包含商品价100元、运费10元、税费5元，可用50元优惠券
2. 支付方式可选余额/银行卡，余额充足
【测试步骤】
1. 提交订单，选择使用优惠券
2. 确认应付金额并选择支付方式（如余额支付）
3. 输入支付密码，完成支付
【测试数据】
| 数据类型 | 订单金额（元） | 优惠金额（元） | 运费（元） | 税费（元） |
|------------|----------------|----------------|------------|------------|
| 正常数据 | 100 | 50 | 10 | 5 |
| 异常数据 | -50 | 0 | 10 | 5 | （负数商品价，非法输入）
| 边界数据 | 0 | 0 | 10 | 5 | （商品价0元，运费税费正常）
【预期结果】
1. 应付金额显示100+10+5-50=65元
2. 支付成功后，订单状态更新为“已支付”
3. 账户余额减少65元，支付凭证金额与订单一致
3.验证与输出：
o自动化校验：数据覆盖 3 类，步骤与预期结果对应 → 通过。
o输出：结构化测试用例（可导入 Excel 或 TestRail）。
五、关键技术点
1.知识库冷启动：
o初期可人工编写 50-100 条标准用例 作为种子数据，覆盖核心场景，引导 LLM 学习业务模式。
2.动态提示调整：
o根据生成结果质量，实时调整提示词（如增加 “步骤需包含异常处理”“数据需标注边界值” 等细化要求）。
3.与测试管理工具集成：
o通过 API 将生成的用例同步至 Jira、TestLink 等工具，支持批量导入和状态管理。
六、效果评估指标
指标 | 定义 | 目标值 |
生成成功率 | 符合格式且逻辑正确的用例占比 | ≥90% |
人工修改率 | 需人工调整的用例比例 | ≤20% |
场景覆盖度 | 生成用例覆盖的测试类型（正常 / 异常 / 边界） | 100% |
业务合规率 | 符合业务规则的用例比例 | ≥95% |
七、风险与应对
·业务规则理解偏差：LLM 可能误解复杂规则（如分期手续费计算），需在提示中明确附加 规则说明文档链接 或示例。
·数据生成不完整：强制要求 LLM 按 “正常 + 异常 + 边界” 模板生成，缺失时触发重新生成机制。
·历史用例质量差：初期人工审核所有生成用例，逐步淘汰低质量历史数据，构建优质知识库。
通过此方案，可实现从 “测试要点” 到 “完整用例” 的高效扩写，大幅减少测试人员在重复劳动上的投入，同时保证生成内容的规范性与业务适配性，为 AI + 测试落地提供可复用的工程化路径。
