AI辅助测试用例生成实战——用大模型把测试设计效率提升300%

不是AI替代测试人员，而是会用AI的测试人员替代不会用的。

一、AI+测试：现在是入局的最佳时机

1.1 测试人员的真实痛点

痛点	具体表现
😫 需求文档几十页，提炼测试点耗时	一个中等功能模块，人工分析需求+设计用例需要2-4小时
😫 场景覆盖靠经验，新人容易漏测	老测试能想到的边界场景，新人根本想不到
😫 重复性劳动占比高	正向流程、必填校验、格式校验这些"套路化"用例占60%+
😫 需求变更频繁，用例维护成本高	改一个字段，相关的几十条用例都要手动更新
😫 写用例耗时多，真正测试时间被压缩	测试设计:测试执行 = 4:6甚至5:5

1.2 AI能做什么（现实版，不画饼）

AI能做的（已验证）	AI做不到的（当前）
✅ 根据需求描述生成结构化用例	❌ 理解隐含业务规则（文档没写的）
✅ 补充边界值和异常场景	❌ 替代人工探索性测试
✅ 生成多组测试数据	❌ 判断用例是否真的有效
✅ 按指定格式输出（Excel/表格/Markdown）	❌ 理解公司特有的业务上下文
✅ 从代码生成单元测试	❌ 发现UI/UX体验问题
✅ 补充你可能遗漏的测试点	❌ 完全替代测试人员的判断力

一句话总结 ：AI是测试设计的加速器 和查漏补缺器，不是自动驾驶仪。

1.3 效率对比实测

以一个典型的"用户注册"功能为例（包含手机号、验证码、密码、确认密码4个字段）：

环节	纯人工	AI辅助
需求分析（提取测试点）	30分钟	5分钟（AI提取+人工审核）
设计正向用例	20分钟	3分钟（AI生成+人工筛选）
设计异常用例	30分钟	5分钟（AI补充+人工确认）
设计边界值用例	20分钟	3分钟（AI自动穷举）
设计安全用例	25分钟	5分钟（AI列举攻击向量）
合计	125分钟	21分钟
最终用例数量	28条	46条（覆盖更全）

💡 实测结论：效率提升约5-6倍，覆盖率提升约60%。

二、核心技能：写好测试用例的Prompt

2.1 Prompt六要素框架

一个高质量的测试用例生成Prompt，必须包含以下六个要素：

复制代码

┌────────────────────────────────────────────┐
│  ① 角色设定  你是谁？（资深测试工程师）      │
│  ② 任务描述  要做什么？（设计测试用例）      │
│  ③ 输入内容  基于什么？（需求文档/代码）     │
│  ④ 覆盖要求  覆盖什么场景？（正向/异常/边界） │
│  ⑤ 输出格式  怎么输出？（表格/编号/字段）    │
│  ⑥ 约束条件  有什么限制？（最少条数/优先级）  │
└────────────────────────────────────────────┘

2.2 基础版Prompt模板

markdown

复制代码

你是一名拥有10年经验的资深软件测试工程师，精通测试用例设计方法（等价类划分、边界值分析、判定表、场景法、错误推测法）。

【任务】
请根据以下功能需求，设计完整的测试用例。

【功能需求】
{在此粘贴需求描述}

【覆盖要求】
- 正常场景：所有正向业务流程
- 异常场景：错误输入、空输入、超长输入、特殊字符
- 边界值场景：对每个输入字段进行边界值分析
- 安全场景：SQL注入、XSS、CSRF等常见安全风险
- 并发场景：多用户同时操作的场景
- 兼容场景：不同设备、浏览器、网络环境

【输出格式】
请按Markdown表格输出，每一条用例包含以下字段：
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 优先级 | 用例类型 |

【约束条件】
- 用例编号格式：TC_模块名_序号（如TC_LOGIN_001）
- 优先级分为P0（核心功能）、P1（重要功能）、P2（一般功能）
- 测试步骤要具体可执行，每条步骤以动词开头
- 至少生成15条用例

2.3 进阶版：Few-Shot示例引导

给AI一个示例，它会模仿你的风格和格式：

markdown

复制代码

你是一名拥有10年经验的资深软件测试工程师。

【任务】
请根据以下功能需求，参照示例用例的风格和格式，设计完整的测试用例。

【示例用例】
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 优先级 |
|:--|:--|:--|:--|:--|:--|:--|
| TC_LOGIN_001 | 正确手机号+正确验证码登录 | 1.已注册手机号13800138000<br>2.验证码服务正常 | 1.打开登录页<br>2.输入手机号13800138000<br>3.点击获取验证码<br>4.输入收到的验证码<br>5.点击登录 | 手机号:13800138000<br>验证码:（从短信获取） | 1.登录成功<br>2.跳转到首页<br>3.显示用户昵称 | P0 |
| TC_LOGIN_002 | 正确手机号+错误验证码登录 | 1.已注册手机号13800138000<br>2.验证码服务正常 | 1.打开登录页<br>2.输入手机号13800138000<br>3.输入错误验证码000000<br>4.点击登录 | 手机号:13800138000<br>验证码:000000 | 1.登录失败<br>2.提示"验证码错误"<br>3.停留在登录页 | P1 |
| TC_LOGIN_003 | 手机号为空点击登录 | 无 | 1.打开登录页<br>2.不输入手机号<br>3.点击登录按钮 | 手机号:空 | 1.登录按钮置灰不可点击<br>或<br>2.提示"请输入手机号" | P1 |

【功能需求】
{在此粘贴需求描述}

【覆盖要求】
（同基础版）

【输出格式】
请参照上述示例的格式和详细程度输出。

2.4 分步引导式Prompt（推荐，效果最好）

与其一次性让AI输出所有用例，不如分步引导，效果更精准：

Step 1：先提取测试点

markdown

复制代码

你是一名资深测试工程师。请从以下需求中提取所有可测试的功能点、业务规则和约束条件。

【需求】
{粘贴需求}

【输出要求】
1. 功能点列表（每个功能点一句话描述）
2. 业务规则列表（包括验证规则、权限规则、流程规则）
3. 输入字段列表（字段名、类型、长度限制、是否必填、格式要求）
4. 依赖条件（需要哪些前置数据或环境）

Step 2：基于测试点生成用例

markdown

复制代码

基于以下测试点清单，为每个测试点设计测试用例。

【测试点清单】
{粘贴Step 1的输出}

【要求】
- 每个功能点至少设计1条正向用例
- 每个输入字段至少覆盖：正常值、空值、边界值、超长值、特殊字符
- 每个业务规则至少设计1条验证用例
- 补充安全测试、并发测试、兼容性测试场景
- 按Markdown表格输出，包含用例编号、标题、前置条件、步骤、数据、预期结果、优先级

Step 3：查漏补缺

markdown

复制代码

以下是为"用户注册"功能生成的测试用例清单。请审查并提出补充建议：

【已生成的用例清单】
{粘贴Step 2的输出}

【请检查】
1. 是否有遗漏的测试场景？
2. 是否有边界值未覆盖？
3. 异常场景是否充分？
4. 是否有安全风险未考虑？
5. 优先级分配是否合理？

三、实战：6个真实场景的完整操作

3.1 场景一：从PRD生成功能测试用例

输入（PRD片段）：

用户可以通过手机号注册账号。注册时需要输入手机号（11位中国大陆手机号）、获取并输入短信验证码（6位数字，60秒内有效，每天最多发送5次）、设置密码（8-20位，必须包含字母和数字）、确认密码。注册成功后自动登录并跳转到首页。

操作步骤：

第1步：将PRD粘贴到分步引导Prompt的Step 1中，让AI提取测试点。

AI输出测试点清单：

第2步：将测试点清单输入Step 2，让AI生成用例。

AI输出部分用例（实际输出约40+条）：

用例编号	用例标题	前置条件	测试步骤	测试数据	预期结果	优先级
TC_REG_001	正确信息完成注册	手机号未注册，短信服务正常	1.打开注册页 2.输入正确手机号 3.点击获取验证码 4.输入正确验证码 5.输入合规密码 6.输入相同确认密码 7.点击注册	手机号:13800138001 密码:Test1234	1.注册成功 2.自动登录 3.跳转首页	P0
TC_REG_002	手机号格式错误-少于11位	无	1.打开注册页 2.输入10位手机号 3.输入其他字段 4.点击注册	手机号:1380013800	1.提示"请输入正确的手机号" 2.注册失败	P1
TC_REG_003	手机号格式错误-非1开头	无	1.打开注册页 2.输入2开头的11位号码 3.输入其他字段 4.点击注册	手机号:23800138001	1.提示"请输入正确的手机号" 2.注册失败	P1
TC_REG_004	已注册手机号再次注册	手机号13800138000已注册	1.打开注册页 2.输入已注册手机号 3.点击获取验证码	手机号:13800138000	1.提示"该手机号已注册" 2.无法获取验证码	P1
TC_REG_005	密码不含字母	手机号未注册	1.输入正确手机号和验证码 2.输入纯数字密码 3.点击注册	密码:12345678	1.提示"密码必须包含字母和数字"	P1
TC_REG_006	密码长度边界-7位	手机号未注册	1.输入正确手机号和验证码 2.输入7位合规密码 3.点击注册	密码:Test123	1.提示"密码长度为8-20位"	P1
TC_REG_007	密码长度边界-8位（最小值）	手机号未注册	1.输入正确手机号和验证码 2.输入8位合规密码 3.确认密码一致 4.点击注册	密码:Test1234	1.注册成功	P1
TC_REG_008	确认密码不一致	手机号未注册	1.输入正确手机号和验证码 2.输入合规密码 3.输入不同确认密码 4.点击注册	密码:Test1234 确认密码:Test5678	1.提示"两次密码输入不一致"	P1
...	...	...	...	...	...	...

第3步：用Step 3 Prompt让AI查漏补缺。

AI补充建议：

复制代码

建议补充以下用例：
1. 验证码60秒过期后再次获取 → TC_REG_015
2. 同一天第6次获取验证码 → TC_REG_016
3. 获取验证码倒计时期间退出页面再进入 → TC_REG_017
4. 密码包含特殊字符（如@#$%）→ TC_REG_020
5. 手机号含空格（如138 0013 8001）→ TC_REG_021
6. 验证码输入字母（非数字）→ TC_REG_022
7. 快速连续点击"获取验证码" → TC_REG_023
8. 无网络时点击注册 → TC_REG_024

3.2 场景二：从接口文档生成接口测试用例

输入（接口文档片段）：

Prompt：

markdown

复制代码

你是一名资深接口测试工程师。请根据以下接口文档，设计接口测试用例。

【接口文档】
{粘贴上面的接口文档}

【覆盖要求】
1. 正常场景：合法参数的各种组合
2. 参数校验：每个字段的必填、类型、范围、枚举值校验
3. 业务规则：库存、优惠券、地址、用户校验
4. 边界值：quantity的边界（0, 1, 99, 100）
5. 异常场景：请求体缺失、格式错误、超时
6. 安全场景：SQL注入、XSS、越权（用他人userId）

【输出格式】
| 用例编号 | 用例标题 | 请求方法 | 请求体 | 预期HTTP状态码 | 预期响应code | 预期message |

AI输出（部分）：

用例编号	用例标题	请求方法	请求体	预期状态码	预期code	预期message
TC_API_001	正常创建订单	POST	`{"userId":"U001","productId":"P001","quantity":1,"addressId":"A001","payMethod":"WECHAT"}`	200	0	success
TC_API_002	quantity为0	POST	`{"userId":"U001","productId":"P001","quantity":0,...}`	400	-	数量必须大于0
TC_API_003	quantity为100（超出上限）	POST	`{"userId":"U001","productId":"P001","quantity":100,...}`	400	-	数量超出限制
TC_API_004	quantity为1（边界值）	POST	`{"userId":"U001","productId":"P001","quantity":1,...}`	200	0	success
TC_API_005	quantity为99（边界值）	POST	`{"userId":"U001","productId":"P001","quantity":99,...}`	200	0	success
TC_API_006	payMethod非法值	POST	`{"userId":"U001",...,"payMethod":"BITCOIN"}`	400	-	支付方式不支持
TC_API_007	使用过期优惠券	POST	`{"userId":"U001",...,"couponCode":"EXPIRED001"}`	200	1002	优惠券无效或已过期
TC_API_008	库存不足	POST	`{"userId":"U001","productId":"OUT_OF_STOCK",...}`	200	1001	商品库存不足
TC_API_009	缺失必填字段userId	POST	`{"productId":"P001","quantity":1,...}`	400	-	userId不能为空
TC_API_010	SQL注入测试	POST	`{"userId":"' OR '1'='1",...}`	400/200	-	参数格式错误或正常拒绝

3.3 场景三：从代码生成单元测试

输入（Python代码）：

python

复制代码

def calculate_shipping_fee(weight, distance, is_vip=False, is_urgent=False):
    """
    计算快递运费
    :param weight: 包裹重量（kg），范围 (0, 50]
    :param distance: 配送距离（km），范围 (0, 1000]
    :param is_vip: 是否VIP用户，VIP享受8折
    :param is_urgent: 是否加急，加急费1.5倍
    :return: 最终运费（元）
    :raises ValueError: 参数超出范围
    """
    if weight <= 0 or weight > 50:
        raise ValueError("重量必须在(0, 50] kg范围内")
    if distance <= 0 or distance > 1000:
        raise ValueError("距离必须在(0, 1000] km范围内")
    
    # 基础运费：首重10元/kg，续重5元/kg
    base_fee = 10 * min(weight, 1) + 5 * max(0, weight - 1)
    # 距离系数
    distance_factor = 1.0 if distance <= 100 else 1.0 + (distance - 100) * 0.01
    # 加急系数
    urgent_factor = 1.5 if is_urgent else 1.0
    
    fee = base_fee * distance_factor * urgent_factor
    
    if is_vip:
        fee *= 0.8
    
    return round(fee, 2)

Prompt：

markdown

复制代码

你是一名精通Python单元测试的测试工程师。请为以下函数生成pytest单元测试。

【函数代码】
{粘贴上面的代码}

【要求】
1. 使用pytest框架
2. 覆盖正常场景、边界值、异常场景
3. 使用@pytest.mark.parametrize参数化
4. 覆盖VIP和非VIP场景
5. 覆盖加急和非加急场景
6. 使用pytest.raises测试异常
7. 覆盖率要求：100%语句覆盖

【输出格式】
直接输出可运行的pytest代码。

AI输出（可直接运行）：

python

复制代码

import pytest
from shipping import calculate_shipping_fee

class TestCalculateShippingFee:
    """运费计算函数测试"""
    
    # ===== 正常场景 =====
    @pytest.mark.parametrize("weight,distance,is_vip,is_urgent,expected", [
        (1, 10, False, False, 10.00),    # 首重1kg，近距离
        (2, 50, False, False, 15.00),    # 首重10元 + 续重5元
        (5, 80, False, False, 30.00),    # 首重10元 + 续重4×5=20
        (1, 100, False, False, 10.00),   # 距离边界100km
        (1, 101, False, False, 10.10),   # 距离超出100km
        (1, 500, False, False, 50.00),   # 距离500km
    ])
    def test_normal_shipping(self, weight, distance, is_vip, is_urgent, expected):
        result = calculate_shipping_fee(weight, distance, is_vip, is_urgent)
        assert result == expected
    
    # ===== VIP折扣场景 =====
    @pytest.mark.parametrize("weight,distance,is_vip,is_urgent,expected", [
        (1, 10, True, False, 8.00),      # VIP 8折
        (2, 50, True, False, 12.00),     # 15 × 0.8 = 12
    ])
    def test_vip_discount(self, weight, distance, is_vip, is_urgent, expected):
        result = calculate_shipping_fee(weight, distance, is_vip, is_urgent)
        assert result == expected
    
    # ===== 加急场景 =====
    @pytest.mark.parametrize("weight,distance,is_vip,is_urgent,expected", [
        (1, 10, False, True, 15.00),     # 10 × 1.5 = 15
        (2, 50, False, True, 22.50),     # 15 × 1.5 = 22.5
    ])
    def test_urgent_shipping(self, weight, distance, is_vip, is_urgent, expected):
        result = calculate_shipping_fee(weight, distance, is_vip, is_urgent)
        assert result == expected
    
    # ===== VIP+加急场景 =====
    @pytest.mark.parametrize("weight,distance,is_vip,is_urgent,expected", [
        (1, 10, True, True, 12.00),      # 10 × 1.5 × 0.8 = 12
    ])
    def test_vip_urgent(self, weight, distance, is_vip, is_urgent, expected):
        result = calculate_shipping_fee(weight, distance, is_vip, is_urgent)
        assert result == expected
    
    # ===== 边界值场景 =====
    @pytest.mark.parametrize("weight,distance,is_vip,is_urgent,expected", [
        (0.01, 0.01, False, False, 0.10), # 最小重量+最小距离
        (50, 1000, False, False, 2550.00),# 最大重量+最大距离
        (0.01, 1000, False, False, 10.00),# 最小重量+最大距离
        (50, 0.01, False, False, 255.00), # 最大重量+最小距离
    ])
    def test_boundary_values(self, weight, distance, is_vip, is_urgent, expected):
        result = calculate_shipping_fee(weight, distance, is_vip, is_urgent)
        assert result == expected
    
    # ===== 异常场景 =====
    @pytest.mark.parametrize("weight,distance,error_msg", [
        (0, 10, "重量必须在(0, 50] kg范围内"),
        (-1, 10, "重量必须在(0, 50] kg范围内"),
        (51, 10, "重量必须在(0, 50] kg范围内"),
        (1, 0, "距离必须在(0, 1000] km范围内"),
        (1, -1, "距离必须在(0, 1000] km范围内"),
        (1, 1001, "距离必须在(0, 1000] km范围内"),
    ])
    def test_invalid_params(self, weight, distance, error_msg):
        with pytest.raises(ValueError, match=error_msg):
            calculate_shipping_fee(weight, distance)

3.4 场景四：生成测试数据

Prompt：

markdown

复制代码

请为"用户注册"功能的测试生成以下测试数据，以JSON数组格式输出：

1. 10组合法的注册数据（手机号使用符合规范的虚拟号码）
2. 10组不合法的手机号（覆盖：空、少于11位、多于11位、非1开头、第二位为0/1/2、含字母、含特殊字符）
3. 5组不合法的密码（覆盖：纯数字、纯字母、少于8位、多于20位、含中文）
4. 5组验证码异常数据（覆盖：少于6位、含字母、过期、错误）

【输出格式】
分类输出，每组标注场景说明。

3.5 场景五：评审已有用例

Prompt：

markdown

复制代码

你是一名测试架构师。请评审以下测试用例的质量，并给出改进建议。

【已有用例】
{粘贴用例清单}

【评审维度】
1. 场景覆盖是否完整？（是否有遗漏的功能点、边界值、异常场景）
2. 用例设计是否合理？（步骤是否可执行、预期结果是否明确）
3. 优先级分配是否合理？
4. 是否有冗余用例？（多个用例测试同一个点）
5. 用例描述是否清晰？（新同事能否看懂并执行）

【输出要求】
1. 总体评分（1-10分）
2. 具体问题清单（逐条列出）
3. 改进建议（逐条给出）
4. 建议补充的用例

3.6 场景六：需求变更后更新用例

Prompt：

markdown

复制代码

需求发生变更，请更新以下测试用例。

【变更内容】
原需求：密码长度为6-16位
新需求：密码长度为8-20位，且必须包含字母和数字

【原有用例（受影响的部分）】
| TC_REG_010 | 密码长度6位（原最小值）可注册 | ... | P1 |
| TC_REG_011 | 密码长度5位（原边界-1）拒绝 | ... | P1 |
| TC_REG_012 | 密码长度16位（原最大值）可注册 | ... | P1 |
| TC_REG_013 | 密码长度17位（原边界+1）拒绝 | ... | P1 |
| TC_REG_014 | 纯数字密码可注册 | ... | P1 |

【要求】
1. 标注哪些用例需要修改、删除、新增
2. 输出修改后的完整用例
3. 新增"密码必须包含字母和数字"相关的用例

四、提示词工程进阶------让AI输出更精准

4.1 角色设定的艺术

角色设定	效果
❌ "请帮我写测试用例"	输出泛泛，没有专业感
⭐ "你是一名测试工程师"	有所改善，但仍不够
⭐⭐ "你是一名拥有10年经验的资深测试工程师，精通等价类划分、边界值分析、场景法、错误推测法等测试设计方法"	输出更专业
⭐⭐⭐ "你是一名资深测试工程师，曾主导过电商、金融、社交等多领域大型项目的测试设计。你擅长从需求文档中提取隐含的业务规则，善于发现容易遗漏的边界条件和异常场景。你的用例以'可执行性强、覆盖全面、优先级合理'著称。"	输出质量最高

4.2 约束条件越具体越好

模糊约束	精准约束
"多写几条"	"至少生成20条用例，其中P0不少于3条，P1不少于8条"
"覆盖全一点"	"覆盖：正常场景5+条、异常场景8+条、边界值5+条、安全场景3+条"
"写详细点"	"每条测试步骤以动词开头，包含具体的输入数据和操作对象"

4.3 分治策略------复杂需求分段处理

复制代码

一个200页的PRD不要一次性扔给AI

正确做法：
  PRD → 按功能模块拆分 → 逐模块生成测试点 → 逐模块生成用例 → 汇总审查

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│ 登录模块  │   │ 注册模块  │   │ 订单模块  │   │ 支付模块  │
│  → 35条  │   │  → 42条  │   │  → 58条  │   │  → 46条  │
└─────────┘   └─────────┘   └─────────┘   └─────────┘
                     ↓
              ┌──────────────┐
              │  汇总 + 端到端  │
              │  场景补充 12条  │
              └──────────────┘
                     ↓
              总计：193条用例

4.4 迭代优化------多轮对话出精品

复制代码

第1轮：生成基础用例（覆盖正向流程）
  ↓ 审查 → 发现缺少异常场景
第2轮：请补充异常场景和边界值用例
  ↓ 审查 → 发现缺少安全场景
第3轮：请补充SQL注入、XSS、越权等安全测试用例
  ↓ 审查 → 发现缺少并发场景
第4轮：请补充并发和性能相关场景
  ↓ 审查 → 发现缺少弱网环境场景
第5轮：请补充弱网、超时、断网等网络异常场景
  ↓
最终：人工审核、修改、定稿

五、不同AI工具的选型与对比

5.1 主流AI工具测试用例生成能力对比

维度	ChatGPT / GPT-4	Claude	文心一言	通义千问	CodeBuddy
通用用例生成	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
中文需求理解	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
代码→单元测试	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
接口测试生成	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
测试数据生成	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
上下文长度	128K	200K	较有限	较有限	取决于模型
免费可用	⚠️ 有限	⚠️ 有限	✅ 基础版	✅ 基础版	✅ IDE集成
IDE集成	需API	需API	需API	需API	✅ 原生集成

5.2 选型建议

场景	推荐工具
日常用例设计（中文）	通义千问 / 文心一言（免费、中文友好）
复杂业务逻辑	Claude / GPT-4（推理能力更强）
单元测试代码生成	Claude / GPT-4 + IDE中的CodeBuddy
接口自动化测试脚本	GPT-4 / Claude
在IDE中边写代码边生成测试	CodeBuddy（原生集成，无需切换窗口）

六、AI测试用例的局限性与避坑指南

6.1 五大陷阱

陷阱	表现	应对策略
幻觉问题	AI编造不存在的API、参数、业务规则	所有AI输出的业务规则必须与PRD核对
上下文遗忘	长对话中忘记之前的约束条件	关键约束每轮都重申；复杂需求分模块处理
格式不稳定	同一Prompt不同时间输出格式可能不同	使用结构化Prompt + Few-Shot示例锁定格式
"看上去正确"	用例格式完美但实际不可执行	抽查3-5条用例实际执行一遍
过度自信	AI不会说"我不确定"，会硬编答案	对不确定的场景追问"你确定吗？依据是什么？"

6.2 必须人工把关的6个环节

复制代码

AI输出 → 必须人工审核 →

  ① 业务规则准确性：AI是否正确理解了需求？
  ② 测试数据真实性：手机号、身份证号是否符合真实规则？
  ③ 步骤可执行性：按步骤操作能否真的走到预期结果？
  ④ 场景完整性：是否有AI不知道的隐含场景？（如特定行业规则）
  ⑤ 优先级合理性：P0/P1/P2分配是否符合项目实际？
  ⑥ 无冗余：是否有3条用例实际测的是同一个东西？

6.3 什么情况下不建议用AI

场景	原因
高度行业化的业务（医疗、金融合规等）	AI缺乏行业专有知识
涉及复杂状态机的场景	AI难以追踪多状态流转
全新产品0→1的需求	没有参考上下文，AI容易"自由发挥"
安全测试中的渗透测试	AI无法替代专业安全工具和人工渗透
需要实际操作设备验证的	硬件测试、IoT设备测试

七、进阶：如何制定AI测试用例生成Skill的规则体系

授人以鱼不如授人以渔。前面教你写Prompt，这里教你如何将Prompt体系化，封装成一个可复用的Skill。

7.1 为什么需要规则体系？

单次Prompt对话的问题是：

问题	表现
每次都要重新写	换一个需求就要重新写一遍Prompt
输出格式不稳定	同样的需求描述，不同时间输出格式不一样
团队标准不统一	A同事和B同事用不同的Prompt风格，用例格式各异
新人上手成本高	新人不知道该怎么写Prompt，也不知道好的用例长什么样

解决方案：将你的测试经验和标准固化为一套"规则体系"，封装成Skill。之后每次只需输入需求，AI按规则自动输出标准化用例。

7.2 十条核心规则详解

以下是我总结的10条核心规则，覆盖从输入到输出的完整链路：

规则①：默认交付规则（高优先级）

目的：规定AI在不明确指令下的默认行为，确保基础质量。

复制代码

【默认交付规则】
1. 如果没有指定用例数量，默认生成不少于20条用例
2. 如果没有指定覆盖范围，默认覆盖：正常场景 + 异常场景 + 边界值 + 安全场景
3. 如果没有指定输出格式，默认使用Markdown表格
4. 如果没有指定优先级规则，默认按以下标准：
   - P0：核心正向流程、涉及资金/数据的操作
   - P1：重要异常校验、边界值
   - P2：非关键路径、极端边界
5. 如果没有指定用例编号格式，默认使用 TC_{模块名}_{序号}

为什么重要：你不说"写20条"，AI可能只写5条敷衍。默认规则保证每次输出下限不低。

规则②：输入读取规则

目的：规定AI如何解析你输入的需求文档。

复制代码

【输入读取规则】
1. 从需求文档中提取以下信息：
   - 功能点清单（每个可独立测试的功能）
   - 输入字段清单（名称、类型、长度限制、是否必填、校验规则）
   - 业务规则清单（显式规则 + 从描述中可推导的隐式规则）
   - 前置依赖（需要什么数据/环境/状态）
   - 异常路径（文档中提到但非主流程的分支）
2. 如果需求文档不完整，列出"需要澄清的问题"而不是猜测
3. 如果需求包含"参考某某功能"，将该功能的规则也纳入分析

反例：AI看到"用户可上传头像"就只测上传功能，忽略了"格式限制、大小限制、裁剪功能、默认头像"等隐含需求。

规则③：可选补充材料规则

目的：规定用户可以额外提供哪些材料，以及AI如何处理它们。

复制代码

【可选补充材料规则】
1. 用户可提供以下补充材料（非必填，提供后质量显著提升）：
   - 原型图/UI设计稿：用于补充UI交互相关用例
   - 接口文档：用于生成接口级别用例
   - 数据库表结构：用于补充数据校验用例
   - 已有测试用例：用于AI学习团队的用例风格
   - 历史Bug清单：用于针对性补充易错场景
2. 当用户提供原型图时，额外生成：
   - 页面元素展示校验用例
   - 交互跳转流程用例
   - 不同分辨率/暗黑模式适配用例
3. 当用户提供历史Bug清单时，优先补充：
   - 与历史Bug同类型的回归用例
   - 历史Bug发生模块的边界增强用例

规则④：用例生成流程规则

目的：规定AI生成用例的内部流程，确保不跳步骤。

复制代码

【用例生成流程规则】
Step 1：解析需求 → 输出"测试点清单"供用户确认
Step 2：用户确认后 → 生成正向用例（核心业务流程）
Step 3：基于正向用例 → 推导异常场景用例
Step 4：基于输入字段 → 穷举边界值用例
Step 5：补充安全用例（注入、越权、加密等）
Step 6：补充非功能用例（兼容性、网络、并发等）
Step 7：自检 → 逐条检查是否违反"明确禁止的写法"（见规则⑧）
Step 8：最终输出 → 完整的用例表格

⚠️ 关键原则：每步输出后等待用户确认，不要一次性输出所有内容。

为什么分步：一次性输出50条用例，用户很难逐条审核。分步输出让用户在每一步都能纠正方向。

规则⑤：用例结构规则

目的：规定每条用例必须包含哪些字段，以及每个字段的填写标准。

复制代码

【用例结构规则】
每条用例必须包含以下字段：

| 字段 | 是否必填 | 填写标准 |
|:--|:--|:--|
| 用例编号 | ✅ 必填 | 格式：TC_{模块名}_{三位序号}，如 TC_LOGIN_001 |
| 用例标题 | ✅ 必填 | 格式：{场景描述}_{预期结果}，如"正确手机号+正确验证码_登录成功" |
| 测试模块 | ✅ 必填 | 所属功能模块，如"登录模块" |
| 前置条件 | ✅ 必填 | 编号列表，包含账号状态、数据状态、环境要求 |
| 测试步骤 | ✅ 必填 | 编号列表，每步以动词开头，具体到可执行 |
| 测试数据 | ✅ 必填 | 具体的输入值，不要写"输入正确数据"这种模糊描述 |
| 预期结果 | ✅ 必填 | 编号列表，包含页面反馈、数据变化、跳转行为 |
| 优先级 | ✅ 必填 | P0/P1/P2 |
| 用例类型 | ✅ 必填 | 功能测试/接口测试/兼容性测试/安全测试/性能测试 |
| 关联需求 | 选填 | 对应的需求编号或PRD章节 |
| 备注 | 选填 | 特殊说明、已知限制、依赖的外部系统 |

规则⑥：编写质量规则

目的：规定每条用例的质量标准，确保"可执行、可复现、无歧义"。

反例 vs 正例：

反例（质量不合格）	正例（质量合格）
"输入正确数据，检查是否正常"	"输入手机号13800138001，验证码123456，密码Test1234，点击注册按钮"
"系统响应正确"	"1.页面提示'注册成功' 2.自动跳转至首页 3.顶部显示用户昵称'测试用户'"
"前置条件：已登录"	"前置条件：1.使用账号test@qq.com登录 2.该账号有3个收货地址 3.购物车中有2件商品"

规则⑦：普适覆盖规则

目的：规定无论什么功能都必须覆盖的通用场景，防止遗漏。

规则⑧：明确禁止的写法

目的：规定AI绝对不能使用的写法，从源头杜绝低质量用例。

规则⑨：表格输出规则

目的：规定最终输出的格式标准，确保可以直接导入测试管理平台。

复制代码

【表格输出规则】
1. 使用Markdown表格格式
2. 表头固定为：用例编号 | 用例标题 | 测试模块 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 优先级 | 用例类型
3. 表格列对齐：编号列左对齐，标题列左对齐，其余列左对齐
4. 如果一条用例的"测试步骤"超过5步，考虑是否可以拆分
5. 在表格前先输出以下汇总信息：
   - 模块名称
   - 用例总数
   - P0数量 / P1数量 / P2数量
   - 覆盖类型分布（功能X条、接口X条、安全X条......）
6. 如果有任何需要用户确认的假设，在表格后以"⚠️ 需要确认"列出

规则⑩：回复用户时的规则

目的：规定AI与用户交互时的行为规范，保证协作体验。

7.3 如何将规则封装为Skill

有了10条规则后，下一步是将它们封装成一个可复用的Skill。以下是完整示例：

markdown

复制代码

---
name: test-case-generator
description: 根据需求文档自动生成标准化测试用例，覆盖正向/异常/边界/安全场景
version: 1.0.0
---

# 测试用例生成Skill

## 触发条件
当用户说"生成测试用例"、"设计用例"、"帮我写用例"、"测试用例"时触发。

## 角色设定
你是一名拥有10年经验的资深测试工程师，精通等价类划分、边界值分析、判定表、场景法、错误推测法。
你以"可执行性强、覆盖全面、格式标准"著称。

## 执行规则
严格遵循以下10条规则（详见规则体系）：
1. 默认交付规则
2. 输入读取规则
3. 可选补充材料规则
4. 用例生成流程规则（分步执行，每步确认）
5. 用例结构规则
6. 编写质量规则
7. 普适覆盖规则
8. 明确禁止的写法
9. 表格输出规则
10. 回复用户时的规则

## 核心禁止项
- 禁止使用"正常"、"正确"、"合理"等主观词
- 禁止一条用例测多个场景
- 禁止编造不存在的业务规则
- 禁止跳过用户确认直接输出全部用例

7.4 规则体系的迭代维护

Skill不是一蹴而就的，需要持续迭代：

复制代码

版本迭代记录模板：

v1.0（初始版本）
- 建立10条基础规则
- 支持功能测试用例生成

v1.1（使用1周后）
- 规则⑦补充：增加"弱网环境"为普适覆盖项
- 规则⑧补充：增加"禁止使用emoji作为测试数据标识"
- 发现AI对"密码加密"场景覆盖不足，强化安全场景规则

v1.2（使用1个月后）
- 规则③补充：新增"原型图输入"的处理规则
- 规则⑤补充：新增"关联需求"字段
- 根据团队反馈，调整P0/P1/P2的默认分配比例

维护建议：

频率	动作
每周	收集使用中遇到的问题和不满意输出
每两周	团队Review，讨论规则是否需要调整
每月	更新Skill版本，记录变更日志
每季度	全量审查，剔除过时规则，补充新场景

八、AI+测试的未来：从用例生成到智能测试

8.1 当前AI+测试的能力全景

复制代码

                    当前成熟度
                    高  ←──────→  低

测试用例生成        ████████████░░░░  85%
测试数据生成        ██████████░░░░░░  75%
单元测试代码生成    ██████████░░░░░░  70%
接口测试脚本生成    ████████░░░░░░░░  60%
测试报告分析        ██████░░░░░░░░░░  45%
自动化脚本修复      █████░░░░░░░░░░░  35%
探索性测试          ████░░░░░░░░░░░░  25%
测试策略制定        ███░░░░░░░░░░░░░  20%
性能瓶颈分析        ██░░░░░░░░░░░░░░  15%
安全渗透测试        █░░░░░░░░░░░░░░░  10%

8.2 测试人员如何不被AI替代

能力	为什么AI替代不了
业务理解	只有人才能真正理解"用户想要什么"
探索性测试	基于直觉和经验的发散性测试
质量判断	什么算Bug？严重程度如何？需要人的判断
沟通协作	与产品、开发的沟通和推动
测试策略	什么先测什么后测、资源怎么分配
使用AI的能力	会写Prompt、会审核AI输出的测试人员更稀缺

一句话：AI负责"生成"，你负责"判断"。

8.3 推荐学习路径

复制代码

第1周：掌握基础Prompt工程
  → 学会角色设定、输出格式控制、Few-Shot示例

第2周：在1-2个模块上实践
  → 选一个中等复杂度的模块，用AI辅助完成全量用例设计

第3周：建立自己的Prompt模板库
  → 总结好用的Prompt，按场景分类保存

第4周：推广到团队
  → 分享模板和经验，建立团队的AI辅助测试流程

持续：跟踪AI工具更新
  → 关注GPT-5、Claude 4等新模型的能力提升

九、Prompt模板速查库

9.1 功能测试用例生成

markdown

复制代码

你是资深测试工程师。请根据以下需求设计测试用例：
【需求】{粘贴需求}
【要求】覆盖正常/异常/边界/安全/并发场景，至少{N}条
【格式】表格：编号|标题|前置条件|步骤|数据|预期|优先级

9.2 接口测试用例生成

markdown

复制代码

你是接口测试专家。请根据以下API文档设计接口测试用例：
【API文档】{粘贴文档}
【要求】覆盖参数校验/业务规则/异常/安全，每个字段覆盖：正常/空/类型错误/边界
【格式】表格：编号|标题|方法|请求体|预期状态码|预期响应

9.3 单元测试代码生成

markdown

复制代码

你是{python/java/js}单元测试专家。请为以下函数生成单元测试：
【代码】{粘贴代码}
【要求】pytest/unittest/jest框架，parametrize参数化，覆盖正常/边界/异常，100%语句覆盖
【格式】直接输出可运行的测试代码

9.4 用例评审

markdown

复制代码

你是测试架构师。请评审以下用例：
【用例】{粘贴用例清单}
【评审维度】场景覆盖/设计合理性/优先级/冗余/可执行性
【输出】总体评分+问题清单+改进建议+建议补充用例

9.5 测试数据生成

markdown

复制代码

请为{功能名称}生成{N}组测试数据：
【要求】包含正常数据{数量}组、异常数据{数量}组、边界数据{数量}组
【格式】JSON数组

9.6 需求变更影响分析

markdown

复制代码

需求发生以下变更：{描述变更}
请分析对现有用例的影响：
【原有用例】{粘贴受影响用例}
【输出】需修改的用例/需删除的用例/需新增的用例/修改后的完整用例

十、总结

10.1 AI辅助测试用例的核心原则

复制代码

┌─────────────────────────────────────────────┐
│                                             │
│   输入质量决定输出质量（Garbage In = Garbage Out） │
│                                             │
│   AI负责"生成" + "穷举"                        │
│   人负责"判断" + "决策"                        │
│                                             │
│   多轮迭代 > 一次性输出                         │
│   分模块处理 > 全量输入                         │
│   结构化Prompt > 随意提问                       │
│                                             │
└─────────────────────────────────────────────┘

10.2 能力自检清单

技能	掌握标准
□ Prompt六要素	能写出包含角色/任务/输入/覆盖/格式/约束的完整Prompt
□ Few-Shot示例	能给AI提供1-3个示例引导输出风格
□ 分步引导	能分3步（提取测试点→生成用例→查漏补缺）完成用例设计
□ 迭代优化	能通过3-5轮对话逐步完善用例集
□ 人工审核	能快速识别AI输出中的错误、遗漏和冗余
□ 多场景应用	能将方法应用于功能测试、接口测试、单元测试
□ 模板积累	建立了自己的Prompt模板库，能快速复用

10.3 与系列文章的配合

已有文章	本文的关联
测试用例设计方法论	本文是方法论的AI加速版，用AI快速落地等价类/边界值/场景法
从需求到高质量用例	本文的"分步引导法"可以替代人工需求拆解的部分环节
接口自动化测试实战	本文3.2节的接口用例生成可直接对接Postman/Newman
测试策略与计划制定	AI生成的用例按优先级排序后，可快速制定测试策略
测试职业发展	AI辅助测试是测试人员2025-2026年必须掌握的核心竞争力

10.4 记忆口诀

六要素Prompt要记牢，角色任务输入不能少。 覆盖格式约束写清楚，Few-Shot示例质量高。 分步引导效果好，先拆测试点再生用例。 多轮迭代查漏补缺，人工审核最后把关。 AI负责生成你负责判断，人机协作才是正解。

📝 行动建议：打开你手头正在测试的一个需求，按照本文第三章的"分步引导法"实际操作一遍。先用AI提取测试点，再生成用例，最后让AI查漏补缺。你会惊讶于AI的效率和覆盖度。