上周做一个后台管理系统的回归测试，遇到一个挺尴尬的问题：一个"很小"的权限修复，上线后又引出了另一个边界 Bug。代码改动不大，接口也没新增，但某个角色在特定筛选条件下能看到不该看的数据。复盘时大家都知道问题在哪里------测试用例覆盖了主流程，但没有把"角色 + 数据范围 + 查询条件"组合起来验证。
我后来没有继续让测试同事手写一大批排列组合，而是试着把 Bug 描述、接口字段、角色规则交给 AI，生成一版可复核的回归用例。为了方便观察不同模型的输出差异，我把同一份输入放在一个多模型聚合环境里跑了一遍，在同一界面切换 ChatGPT、Claude、Gemini、Grok 等模型，适合做文档处理、任务拆解、代码辅助和同题输出对比。
这篇文章记录的不是"AI 自动测试平台"这种大方案，而是一个更小、更容易落地的流程：如何让 AI 帮测试工程师、后端开发和产品同事，把一次 Bug 复盘变成更完整的回归测试用例。
问题不是不会写用例，而是漏掉组合
这次 Bug 的背景大概是这样：
- 系统里有管理员、区域经理、普通销售三类角色；
- 每类角色能看到的数据范围不同；
- 列表接口支持按客户状态、所属区域、创建时间筛选；
- 修复前，普通销售在某些组合条件下能查到跨区域数据；
- 修复后，主流程通过了，但另一个筛选条件下仍然有遗漏。
最开始的测试用例长这样：
| 用例 | 角色 | 操作 | 预期 |
|---|---|---|---|
| 查看客户列表 | 普通销售 | 打开客户列表 | 只能看到本人客户 |
| 按状态筛选 | 普通销售 | 选择"跟进中" | 只返回跟进中客户 |
| 区域经理查看 | 区域经理 | 打开客户列表 | 看到本区域客户 |
这些用例没错，但颗粒度太粗。真正出问题的是：
text
普通销售 + 指定区域筛选 + 特定客户状态 + 时间范围也就是说，不是单个功能点漏测，而是规则组合漏测。
AI 在这里能发挥作用的地方，不是替代测试人员判断，而是帮人把组合维度摊开，提醒哪些路径需要补。
第一步：把 Bug 复盘材料整理成结构化输入
我没有直接对 AI 说"请帮我写测试用例"。这种提示词太宽，很容易生成一堆看起来标准但没贴合业务的用例。
我先整理了四类信息：
text
1. Bug 描述普通销售在客户列表中使用区域筛选时，可能查询到非本人负责的客户数据。
2. 角色规则- 管理员：可查看全部客户- 区域经理：可查看本区域客户- 普通销售：只能查看本人负责客户
3. 接口信息GET /api/customers参数：- status：客户状态- regionId：区域 ID- createdStart：创建开始时间- createdEnd：创建结束时间- ownerId：负责人 ID
4. 修复目标无论前端传入什么筛选条件，后端都必须基于当前登录用户权限进行数据范围约束。然后再让模型生成测试用例：
text
请基于下面的 Bug 复盘信息，生成回归测试用例。
要求：1. 不要只覆盖正常流程；2. 必须覆盖角色、数据范围、筛选条件的组合；3. 每条用例包含：用例名称、前置数据、操作步骤、预期结果、优先级；4. 标记哪些用例适合自动化；5. 不要编造不存在的接口字段；6. 如果信息不足，列出需要向产品或后端确认的问题。这个 Prompt 的关键点是：先给约束，再给输出格式，再明确"不足就提问"。
否则模型很容易把测试用例写得很完整，但里面混入了系统并不存在的字段或操作。
第二步：让 AI 先列"测试维度"，不要急着写用例
我后来发现，更稳的做法是先让 AI 输出测试维度，而不是直接输出最终用例。
比如：
| 维度 | 可选值 |
|---|---|
| 角色 | 管理员、区域经理、普通销售 |
| 数据归属 | 本人、本区域、跨区域、无归属 |
| 查询条件 | 无筛选、状态筛选、区域筛选、时间筛选、组合筛选 |
| 请求来源 | 正常前端请求、手动构造参数 |
| 结果验证 | 返回数据范围、总数、分页、空结果 |
这一步很有用。
测试人员可以先看维度是否完整，再决定是否让 AI 继续生成用例。
我用的提示词是：
text
请不要直接写测试用例，先分析这个 Bug 涉及的测试维度。
输出：- 权限维度- 数据维度- 查询参数维度- 异常输入维度- 自动化验证维度- 需要人工确认的问题
要求：每个维度给出具体取值，不要写抽象概念。这比一上来生成 30 条用例更可控。
如果维度都错了，后面的用例再多也没意义。
第三步：把用例分成三层，而不是一股脑全测
AI 很容易生成大量用例。看起来很勤奋，但真实项目里不可能每次回归都跑几十条低价值用例。
我会把它生成的用例分成三层：
1. 冒烟层
只验证核心修复是否生效。
| 用例 | 角色 | 操作 | 预期 |
|---|---|---|---|
| 普通销售默认查询 | 普通销售 | 不传筛选条件查询客户 | 只返回本人客户 |
| 区域经理默认查询 | 区域经理 | 查询客户列表 | 只返回本区域客户 |
2. 组合层
验证 Bug 相关维度是否存在交叉遗漏。
| 用例 | 角色 | 查询条件 | 预期 |
|---|---|---|---|
| 普通销售按区域筛选 | 普通销售 | regionId=其他区域 | 不返回非本人客户 |
| 普通销售按状态筛选 | 普通销售 | status=跟进中 | 返回本人且状态匹配客户 |
| 普通销售组合筛选 | 普通销售 | regionId + status + 时间范围 | 不突破本人数据范围 |
3. 防绕过层
验证前端没有暴露的参数，后端是否也做了约束。
| 用例 | 操作 | 预期 |
|---|---|---|
| 手动传 ownerId 为他人 | 构造请求 ownerId=其他销售 | 不返回他人客户 |
| 手动传 regionId 为跨区域 | 构造跨区域查询 | 不返回越权数据 |
| 修改分页参数 | pageSize 较大 | 返回数据仍受权限限制 |
这一层很关键。权限类 Bug 不能只测 UI，因为用户请求不一定来自正常页面操作。后端接口必须独立校验权限边界。
第四步：让 AI 生成可自动化的断言
很多 AI 生成的测试用例停留在"预期结果正确"这种描述上，不能直接拿去做自动化。
我会继续追问：
text
请把适合自动化的用例转换成接口测试断言。
要求：1. 使用伪代码表达，不依赖具体测试框架；2. 每条断言要能验证权限边界；3. 不只判断 HTTP 状态码；4. 要检查返回列表中每条数据的 ownerId 或 regionId；5. 如果需要测试数据，请列出前置数据。输出会接近这样：
text
登录普通销售 userA请求 GET /api/customers?regionId=regionB&status=active
断言：- response.status == 200- response.data.list 中每条记录的 ownerId == userA.id- response.data.list 中不存在 regionId == regionB 且 ownerId != userA.id 的记录- response.data.total 与符合 userA 权限的数据数量一致这就比"只能看到本人客户"更适合交给自动化测试。
如果项目里使用 JUnit、Pytest、Postman、Apifox 或其他测试工具，可以再让模型按团队现有格式改写。但我建议先生成伪代码，确认逻辑后再转成具体框架代码。
不同模型的输出差异
这次我没有做严谨排行榜，只是用同一份 Bug 材料做了几轮观察。
| 模型 | 更适合的环节 | 需要注意 |
|---|---|---|
| ChatGPT | 把 Bug 复盘转成测试流程，用例表达比较清楚 | 偶尔会补充不存在的字段，需要核对 |
| Claude | 长文本分析、规则整理、边界条件归纳 | 输出较长，要人工压缩 |
| Gemini | 快速给出多个测试维度和用例变体 | 需要加强业务约束 |
| DeepSeek | 中文测试用例、接口断言、技术表达 | 要明确不要扩展业务假设 |
| Grok | 适合做反向提问和异常路径补充 | 输出风格有时偏发散 |
我的经验是：
权限、金额、数据范围这类问题，不要只看哪个模型写得顺，而要看它是否能把边界讲清楚，是否能提出"你还缺哪些信息"。
一个模型如果在信息不足时仍然给出非常肯定的结论，反而要小心。
用 AI 生成测试用例的验收表
为了避免"看起来很多，但实际没用"，我给 AI 生成的用例做了一个小验收表：
| 检查项 | 通过标准 |
|---|---|
| 覆盖 Bug 根因 | 用例能验证本次缺陷的真实原因 |
| 覆盖组合条件 | 不只测单个筛选项 |
| 权限断言明确 | 能检查 ownerId、regionId 等关键字段 |
| 可复现 | 前置数据清楚，步骤能执行 |
| 可自动化 | 至少部分用例能转成接口测试 |
| 无编造字段 | 不出现系统不存在的参数或状态 |
| 有人工确认点 | 不确定规则标记出来 |
这张表比用例数量更重要。
有时候 8 条高质量用例，比 40 条泛泛的用例更有价值。
数据和日志要先脱敏
测试场景里经常会涉及用户 ID、手机号、客户名称、合同编号、内部接口、线上日志。这些内容不要直接贴给 AI。
可以这样处理：
text
真实用户 ID -> userA / userB客户名称 -> customer_001手机号 -> 138****0000合同编号 -> contract_xxx线上域名 -> api.example.com内部 Token -> removed_token如果要让 AI 分析日志，也建议只保留和问题相关的字段，比如请求路径、状态码、错误码、耗时、脱敏后的用户标识。权限类、金融类、医疗类、政务类数据尤其要谨慎，AI 只能辅助整理和分析，不能替代最终合规判断。
常见误区
只让 AI 写正常流程
正常流程用例通常不难，真正容易漏的是边界、组合、异常输入和绕过前端的接口请求。Prompt 里要明确要求这些维度。
直接把 AI 用例放进测试计划
AI 输出必须经过测试人员和开发人员确认。尤其是权限规则、金额计算、审批流、数据范围这类场景，不能只靠模型判断。
只断言状态码
接口返回 200 不代表逻辑正确。权限类测试至少要检查返回数据里的关键字段，必要时还要校验 total、分页、排序和空结果。
把模型当需求来源
AI 可以发现问题，但不能替产品补规则。遇到"区域经理能否查看离职销售客户"这类业务定义不清的问题，应该标记为待确认，而不是让模型拍板。
一个可以复用的 Prompt 模板
text
你是测试工程师，请基于以下 Bug 复盘材料生成回归测试方案。
输入内容包括：- Bug 描述- 修复目标- 角色权限规则- 接口字段- 已知测试数据- 不确定规则
请分三步输出：1. 先列测试维度，不要直接写用例；2. 再生成分层测试用例：冒烟层、组合层、防绕过层；3. 最后把适合自动化的用例转成接口断言伪代码。
要求：- 不编造不存在的字段；- 不确定内容标记为"需确认"；- 每条用例包含前置数据、操作步骤、预期结果、优先级；- 权限类用例必须检查返回数据中的关键字段；- 输出 Markdown 表格。这个模板不只适合权限问题，也能改成订单状态、优惠券规则、审批流、报表统计、数据同步等场景。
结尾：从一次真实缺陷开始做，不要上来追求全自动
如果团队想用 AI 辅助测试，我建议从"最近一次线上 Bug"开始，而不是一上来建设大而全的测试平台。
比较稳的路径是：
- 选一个真实 Bug；
- 整理复盘材料和接口字段；
- 让 AI 先拆测试维度；
- 人工确认维度后再生成用例；
- 把高价值用例转成自动化断言；
- 下次回归时验证它是否真的拦住了问题。
AI 生成测试用例的价值，不在于一次输出多少条，而在于帮团队把容易漏掉的组合条件、边界条件和验证断言提前摊开。测试人员仍然要负责判断规则是否正确，开发人员仍然要验证接口实现，产品也要确认业务边界。把这几层关系理清楚，AI 才能真正进入测试流程，而不是停留在"生成一份看起来很完整的文档"。