1. 概述

测试用例生成是AI辅助测试中最具落地价值的场景之一。借助大语言模型（LLM）强大的语义理解和生成能力，测试人员可以从需求文档、代码、API定义等多种输入源自动生成结构化的测试用例，显著提升测试设计的效率与覆盖面。

1.1 AI生成 vs 传统用例设计

1.2 适用场景

• 需求评审阶段：基于用户故事快速生成验收测试用例，支撑评审质量
• 接口测试设计：从OpenAPI/Swagger/Postman定义自动生成接口测试用例
• 回归测试补充：针对已有功能自动扩展边界条件和异常场景
• 单元测试编写：分析代码逻辑生成对应单元测试，提升代码覆盖率
• 监管合规验证：结合行业监管要求（如银行业），自动补充合规测试用例

2. LLM用例生成的核心方法

2.1 基于需求的用例生成

这是最常见的用例生成方式。将需求文档、用户故事或功能规格说明输入LLM，模型从自然语言需求中提取测试场景，并输出结构化的测试用例。该方法的核心优势在于能够理解业务上下文，生成更贴近用户视角的测试用例。

典型流程：

1. 整理需求输入：User Story / PRD / 功能规格文档
2. 构造Prompt：设定角色、输入需求、输出格式
3. LLM生成：输出包含前置条件、步骤、预期结果的用例
4. 人工审核：检查逻辑正确性、补充遗漏场景
5. 迭代优化：将反馈注入Prompt，重新生成或调整

2.2 基于代码的用例生成

直接将源代码或函数签名输入LLM，让模型分析代码逻辑并生成对应的单元测试用例。此方法特别适合结合AI Coding工具（如GitHub Copilot、Cursor等）使用，在开发阶段同步生成测试代码。

适用场景：

• 为纯函数生成 JUnit / pytest / Go test 等单元测试
• 分析复杂分支逻辑，生成覆盖所有路径的用例
• 从已有测试代码学习模式，为新函数生成风格一致的测试
• 为遗留代码生成回归测试，补齐测试缺口

2.3 基于接口的用例生成

从API的定义文件（OpenAPI 3.0、Swagger 2.0、Postman Collection等）中提取接口信息，自动生成接口测试用例。LLM能够理解接口语义，自动推断业务场景，并生成包含参数组合、状态码验证、响应断言等内容的测试用例。

典型生成内容：

2.4 边界与异常场景生成

LLM在发现边界条件和异常场景方面具有独特优势。人类测试人员在设计用例时容易遗漏"冷门"的边界值，而LLM通过对大量测试案例的学习，能够系统性地枚举各种边界条件和异常分支。

LLM擅长发现的边界类型：

• 数值边界：最小值、最大值、零值、负数、小数精度
• 字符串边界：空字符串、超长字符串、特殊字符、SQL/XSS注入
• 集合边界：空集合、单元素、海量元素、重复元素
• 时间边界：过去时间、未来时间、跨时区、闰秒
• 状态边界：非法状态跳转、并发冲突、超时中断
• 组合爆炸：多参数交叉边界、顺序依赖异常

3. 提示词设计策略

Prompt的质量直接决定了生成用例的质量。以下总结经过实践验证的提示词设计策略和模板。

3.1 核心Prompt模板

一个高质量的用例生成Prompt应包含以下要素：角色设定 + 任务描述 + 输入内容 + 输出格式 + 约束条件。以下是一个通用模板：

你是一位资深软件测试专家，拥有10年以上金融系统测试经验。请根据以下需求生成测试用例。

## 需求描述
[此处粘贴需求文档/用户故事/接口定义]

## 输出要求
请以JSON格式输出，每个用例包含以下字段：
- id: 用例编号
- title: 用例标题
- preconditions: 前置条件
- steps: 测试步骤（数组）
- expected: 预期结果
- priority: 优先级（P0/P1/P2/P3）
- type: 用例类型（功能/边界/异常/性能/安全）

## 约束条件
1. 必须覆盖正向、边界、异常三类场景
2. 用例步骤应具体可执行，避免模糊描述
3. 预期结果应可验证，有明确判定标准
4. 优先级P0的用例不超过总数的20%

3.2 角色设定策略

不同的角色设定会显著影响LLM生成的用例风格和侧重点。角色描述越具体，生成效果越好。

3.3 少样本示例（Few-shot）技巧

在Prompt中提供1-3个高质量示例用例（输入需求→期望输出），可大幅提升生成的一致性和质量。示例应覆盖不同类型的测试场景，展示理想的格式和粒度水平。

## 示例

输入需求："用户登录功能：输入用户名和密码，验证通过后跳转到首页，连续3次失败锁定账户"

输出用例：
{
  "id": "TC-LOGIN-001",
  "title": "正确的用户名和密码登录成功",
  "preconditions": "用户已注册，账户状态正常",
  "steps": ["打开登录页", "输入正确用户名", "输入正确密码", "点击登录按钮"],
  "expected": "登录成功，跳转到首页，显示用户昵称",
  "priority": "P0",
  "type": "功能"
}

请参照以上格式生成以下需求的用例...

4. 生成质量评估

AI生成的用例并非"开箱即用"，需要从多个维度进行质量评估，确保其真正满足测试需求。

4.1 覆盖率评估

评估生成的测试用例对需求或代码的覆盖程度，主要包括：

• 需求覆盖率：每条需求是否都有对应的测试用例？是否遗漏了某些功能点？
• 场景覆盖率：正向、边界、异常场景是否齐全？是否只覆盖了"快乐路径"？
• 代码覆盖率（适用于单元测试）：生成的用例是否覆盖了所有分支、循环、异常处理？

4.2 有效性评估

评估每个用例本身是否"可用"，核心指标包括：

• 可执行性：步骤是否明确具体？前置条件是否可达？数据是否可获取？
• 可验证性：预期结果是否有明确的判定标准？是否存在模糊表述如"正常显示"？
• 可复现性：在同等条件下，能否重现用例描述的场景？
• 可追溯性：用例是否能追溯到具体需求条目或代码位置？

4.3 冗余度控制

LLM生成的用例中常出现以下冗余问题，需要识别并清理：

• 语义重复：多个用例本质上验证同一逻辑，仅措辞不同
• 过度拆分：将参数值的每个枚举都拆成独立用例，导致用例爆炸
• 模板化冗余：对每个接口重复生成大量"骨架用例"但无实质内容

4.4 评估案例

以下展示一个真实的评估案例，说明如何判断和提升AI生成用例的质量：

5. 银行业应用场景

5.1 银行系统接口测试用例生成

银行系统的接口测试有其特殊要求：高安全性、事务一致性、幂等性保障、精确的金额计算等。结合OpenAPI定义和银行业务规则，LLM可以生成高质量的接口测试用例。

银行接口测试关注要点：

• 资金安全：金额计算精度（分 vs 元）、负数金额、溢出保护
• 事务一致性：分布式事务、补偿机制、冲正流程
• 幂等性：重复提交保护、唯一流水号去重
• 超时处理：支付超时、回调未到达、状态未知的交易
• 渠道兼容：柜面、网银、手机App、ATM、POS 不同渠道的特殊场景

5.2 结合监管要求的用例覆盖

银行业受到严格监管（银保监会、人民银行等），测试用例必须覆盖监管合规要求。LLM可以将监管条文作为输入，自动生成合规验证用例。

• 反洗钱（AML）：大额交易上报、可疑交易监测、客户身份识别（KYC）
• 数据安全：个人信息保护、数据脱敏验证、访问权限控制
• 业务连续性：灾备切换、降级策略、限流熔断
• 审计要求：操作日志完整性、不可篡改性、保存期限验证

5.3 某银行AI建设工程的测试用例需求

某银行AI建设工程（中国农业发展银行智能化系统）对测试用例生成提出了更高的要求，结合AI能力可重点解决以下需求：

• 政策性业务验证：粮食收购贷款、扶贫专项、乡村振兴相关业务的特殊流程验证
• 多级审批流程：从县级支行到总行的多级审批路径全覆盖
• 涉农数据校验：土地面积、产量预测、补贴核算等涉农数据的业务规则验证
• 智能风控场景：基于AI的信贷风险评估模型的输入/输出测试

6. 实践建议与坑点

6.1 AI生成用例必须人工审核

这是最重要的原则，没有之一。LLM可能会产生"看起来合理但实际错误"的内容（幻觉），也可能遗漏业务特有的隐含规则。人工审核应重点关注：

• 业务逻辑是否正确，尤其是有隐含规则或约定俗成的场景
• 用例之间是否有逻辑矛盾和冲突
• 是否遗漏了关键的高风险场景
• 预期结果是否符合实际系统行为而非"理想状态"

6.2 避免过拟合到训练数据的常见模式

LLM的训练数据中包含了大量互联网上的测试用例模板，可能产生以下问题：

• 生成"通用模板式"用例，缺乏领域特色（如生成的银行测试用例像电商系统）
• 偏好生成某些高频场景（如"登录功能"），而忽略低频但关键的业务场景
• 对某些测试技术（如等价类划分、边界值分析）生搬硬套，不考虑是否适用

对策：在Prompt中提供领域上下文和约束；使用Few-shot示例引导输出风格；对生成结果进行领域知识交叉验证。

6.3 提示词工程的重要性

提示词工程不是一次性的工作，而是持续迭代优化的过程。建议：

• 维护团队的Prompt库，积累经过验证的高质量Prompt模板
• 记录每个Prompt版本对应的生成质量评分，便于回溯和对比
• 定期（如每季度）评估最新模型版本下Prompt的适用性，及时调整
• 不同业务域使用不同的Prompt模板，而非"一个模板打天下"

6.4 持续优化：通过反馈迭代

用例生成的质量提升是一个闭环过程：

1. 生成：使用Prompt + 输入 → 输出用例初稿
2. 审核：人工审查，标记问题用例，记录问题类型
3. 反馈：将问题用例和改进后版本作为新的Few-shot示例
4. 优化：根据问题模式调整Prompt中的约束条件和格式要求
5. 度量：统计用例通过率、修改率等指标，量化迭代效果

6.5 常见坑点总结

7. 🎯 实战演练

以下三个实战任务帮助你从"知道"到"做到"，建议按顺序完成，预计总耗时约 90-120 分钟。