前天面试了一个有着五年经验的测试工程师。
简历上写得挺漂亮：熟练使用 AI 生成测试用例，用 AI 实现自动化测试。我心想，这哥们儿应该有点东西，就抛了一个真实的项目问题过去。
没想到，他的回答把我惊呆了。
题目是这样的：
你用 AI 做测试，需求文档是完整的电商订单流程。AI 生成了 120 条测试用例，3000 行 UI 自动化脚本，覆盖了正向下单、支付、退款流程。结果上线后一小时，大量用户反馈无法完成订单支付。
排查发现两个核心问题：
- AI 生成的用例漏了订单金额为 0.01 元的边界值、支付时网络中断重试这两个关键场景
- 自动化脚本只实现了点击操作，没有断言支付成功后订单状态变为待发货，也没有处理支付超时的异常场景，导致测试时没发现问题，上线后直接引发生产故障。
我接着追问了三个问题，每一个都是面试必问：
第一，你在审核 AI 生成的订单支付用例时，怎么判断 AI 有没有漏测边界值异常场景？
第二，自动脚本跑通就代表没问题吗？你会具体检查脚本的哪些细节，如何避免没有断言、没有异常处理的情况。
第三，这次故障后，你会怎么优化 AI 测试的流程，保证下次不再出现漏测脚本无效的问题？
没想到，他张口就来：
"我就把 AI 生成的用例大致扫了一遍，看步骤完整、没有明显错误就够了。"
"脚本能跑通就行，没必要查那么细。"
"故障后……下次让 AI 多生成几条用例，再多看两眼就好了。"
听到这里，我心里叹了口气。
兄弟，你这根本不是懂 AI 测试，你就是拿 AI 当甩手掌柜。AI 一天能生成几百条用例、几万行脚本，你粗略扫一眼，能发现藏在细节里的边界漏洞、断言缺失吗？
他不知道该怎么回答了，面试到这里，基本也就结束了。
这道题为什么能筛掉大部分人？
说实话，这类题我面了不下二十几个人，能答到点上的不超过三个。
很多人有个误区：觉得会用 AI 生成几条用例、让 Copilot 写几行 Selenium 脚本，就叫"AI 测试"了。
大家一定要明白一个核心真相，AI 擅长批量生成模板化输出，但永远不懂隐性业务，不懂行业规则，不懂项目历史问题。
AI 最大的隐患不是写不出用例，而是特别容易产出看起来专业，实际全是漏洞的内容。
比如漏掉权限互斥场景、忽略流程依赖关系、边界值只写常规，不写极值、异常场景只做表面覆盖、自动化脚本缺少关键断言、接口测试漏了参数加密和并发场景等。
比如，AI 生成测试内容的常见翻车点：
| 翻车类型 | 具体表现 | 危害等级 |
|---|---|---|
| 边界值漏测 | 只写常规值，不写极值（如 0.01 元、999999.99 元） | 🔴 高 |
| 异常场景表面化 | 写了"网络异常"，但没写异常后的状态恢复 | 🔴 高 |
| 权限互斥缺失 | 没覆盖"同时操作冲突"（如退款 + 退货并发） | 🔴 高 |
| 断言缺失 | 脚本只点不验，跑通≠通过 | 🟠 中 |
| 流程依赖断裂 | 步骤 A 失败后重试，步骤 B 的状态没同步校验 | 🟠 中 |
| 参数安全忽略 | 接口测试漏了加密、防篡改、并发场景 | 🟠 中 |
| 重复冗余 | 同一个场景换说法生成多条，浪费执行资源 | 🟡 低 |
这也是初级测试和高级测试的核心分水岭：前者只看 AI 产出的 “数量”，后者能看透背后的风险，用系统化方法驾驭 AI。
真正玩转 AI 测试，需要五层质量管控体系
结合我多年的实战经验，以及踩过的 AI 测试坑，我始终认为：想要真正用好 AI 测试，既发挥它的效率优势，又杜绝漏测、错测、无效用例上线，绝不能 “甩手掌柜式” 用 AI，而是要建立一套完整的 AI 测试全流程质量管控体系。
这不是简单的 “让 AI 多生成几条用例、多看两眼”，而是从需求到复盘的全链路把控，每一步都要融入人的专业判断和业务经验。
我把这套体系，分为五个层级，每一层都是面试高频考点，也是实际工作能落地的标准流程。
第一层：业务需求前置拆解，不给 AI 盲目发挥的机会
很多人用 AI 测试最大的误区，就是直接把一份笼统的需求文档丢给 AI，让它自由发挥生成测试用例。
这本身就是最大的风险。
AI 看不懂文字背后的隐性规则，也不知道你们项目过往的高频缺陷点。
比如"支付功能"三个字，AI 理解的就是"输入金额→确认支付→扣款成功"。但它不会知道：
- 你们的支付通道有金额下限（0.01 元）
- 网络中断后需要支持 3 次重试，每次间隔 5 秒
- 支付超时后订单状态要回滚为"待支付"，不能卡在"支付中"
- 同一笔订单不能重复支付（幂等性）
正确的做法是先人工拆解需求，梳理出几大模块：
- 核心业务流程（主路径必须 100% 覆盖）
- 次要分支流程（异常分支、降级方案）
- 隐藏业务规则（风控拦截、金额限制、时间窗口）
- 权限角色划分（普通用户/VIP/管理员的不同逻辑）
- 边界极值清单（最小值、最大值、空值、超长值）
- 异常故障场景（网络中断、服务超时、数据不一致）
- 安全风控要求（SQL 注入、越权访问、敏感信息脱敏）
把这几大模块的结构化清单、历史 Bug 案例、业务禁止规则，一起喂给 AI，限定生成范围，限定覆盖维度。让 AI 在你划定的框架内产出，而不是任由它随意编造业务逻辑。
尤其是支付、订单、用户权限、数据隐私、资金流转这类核心模块，
必须提前做场景锁定，强制 AI 全覆盖，绝不让它随意编造业务逻辑。这一步的核心是 “人主导、AI 辅助”，用人工的业务理解弥补 AI 的认知盲区。
第二层：给 AI 产出 “做减法”，筛选有效内容
AI 产出的测试用例，从来不是全部可用的。而是要学会快速分类筛选：
第一类：标准正向用例
- 常规流程、基础操作
- AI 基本不会出错，可以直接保留
- 占比约 60%-70%
第二类：待修改用例
- 边界值不精准（如写了"输入负数"，但没写具体-1 还是-0.01）
- 异常场景描述模糊（如"网络异常"没定义异常类型）
- 步骤顺序错乱
- 这类不用直接删掉，人工微调后就能复用
第三类：直接废弃用例
- 逻辑前后矛盾（如前置条件说"未登录"，步骤里却要求"点击个人中心"）
- 编造不存在的业务功能（AI"幻觉"出来的菜单或按钮）
- 重复冗余（同一个场景换说法写了 3 遍）
- 完全脱离实际业务（如电商系统里出现"火箭发射"的测试步骤——别笑，我真见过）
- 这类必须直接剔除，绝对不能混入测试套件
同时还要检查自动化脚本，看脚本是否只实现了页面操作，缺少结果断言，缺少异常捕获，缺少环境兼容适配，这类脚本跑通也没有任何测试意义，必须整改。
这一步的关键是 “不迷信 AI 产出”，用人工的专业判断筛选出真正有价值的内容，避免无效用例占用测试资源。
第三层：多维度量化校验，不靠感觉，靠数据
判断 AI 测试用例可不可靠，不能凭肉眼感觉，要有量化标准。
首先，核对需求覆盖率，对照需求文档每一个功能点，检查有没有遗漏、未覆盖的模块。
其次，统计反向用例、边界用例、异常用例的占比。正常业务不能只有正向用例，没有反向和异常兜底。然后排查重复用例率、逻辑错误率、高危场景遗漏率。
结合项目历史缺陷库，校验 AI 有没有覆盖过往线上出过的同类 bug
具体供参考：
| 校验维度 | 具体做法 | 合格线 |
|---|---|---|
| 需求覆盖率 | 对照需求文档逐条映射，看每个功能点有没有对应用例 | ≥95% |
| 反向用例占比 | 反向/异常用例占总用例比例 | ≥30% |
| 边界用例数量 | 每个数值型字段至少 2 个边界值（最小、最大） | 100% 覆盖 |
| 重复用例率 | 语义重复的用例占比 | ≤10% |
| 逻辑错误率 | 业务逻辑错误或无法执行的用例占比 | ≤5% |
| 高危场景遗漏率 | 权限/并发/弱网/非法输入/参数篡改等场景 | 0% |
| 历史缺陷覆盖率 | 过去 3 个版本的线上 Bug，AI 用例能否覆盖 | ≥80% |
除此之外，还要重点核对 AI 最容易忽略的高危场景，比如
- 权限互斥：越权访问、角色切换后的权限残留
- 并发场景：同一用户多设备登录、秒杀抢购
- 弱网环境：2G 网络、网络切换、飞行模式
- 非法输入：SQL 注入、XSS、路径遍历、特殊字符
- 接口安全：参数加密、签名验证、重放攻击
这些是 AI 最容易忽略，但最容易引发线上故障的点，用数据做校验，才是专业测试的做事方式。
第四层：三级审核，用人工经验兜底，守住核心风险
AI 永远替代不了人的业务经验，核心场景必须层层把关，所以这里，我建议的做法是，建立 “初审 + 复核 + 终审” 的三级审核机制：
- 初审：用自动化工具批量过滤重复用例、格式错误、逻辑冲突的内容，节省人工时间；
- 复核：由资深测试工程师负责，逐行校验核心业务的边界、极值、异常流程，尤其是支付、权限这类高危模块，比如核对自动化脚本是否有断言、异常捕获、环境适配逻辑；
- 终审：由业务负责人或测试总监确认，重点把关隐性需求和特殊业务规则，比如电商订单的 “跨平台退款规则”“节假日支付限额” 等 AI 无法理解的业务细节。
三道关卡层层过滤，能从根本上杜绝 AI 的错漏内容流入执行阶段，这也是规避线上故障的关键。
第五层：复盘沉淀，让 AI 越用越 “懂” 业务，形成闭环
AI 测试不是一次性行为，一定要做长期沉淀优化。
建议在每次项目结束后，记录三类信息：
1、AI 翻车案例库
- 哪类场景 AI 容易漏测？
- 哪类业务 AI 容易编造规则？
- 哪类脚本容易出现断言缺失？
2、优质模板库
- 提示词模板（不同业务类型的标准 Prompt）
- 用例模板（正向/反向/边界的标准格式）
- 脚本规范模板（断言、异常处理、日志的代码规范）
3、训练数据集
- 把历史优质用例、业务规则、负面案例投喂给 AI
- 让 AI 越来越贴合团队业务，生成内容越来越精准
形成完整闭环：
需求拆解 → AI 生成 → 分类筛选 → 量化校验 → 三级审核 → 落地执行 → 复盘沉淀 → 优化提示词 → 下一轮复用
graph TD
A["需求拆解"] --> B["AI生成"]
B --> C["分类筛选"]
C --> D["量化校验"]
D --> E["三级审核"]
E --> F["落地执行"]
F --> G["复盘沉淀"]
G --> H["优化提示词"]
H --> I["下一轮复用"]
I --> A
这才是成熟的 AI 测试工作模式。
为什么有人用 AI 效率翻倍，有人越用越漏测？
说到底，AI 测试的核心不是 “会不会用 AI 写用例、出脚本”，而是 “能不能用人的专业能力约束 AI、校验 AI、优化 AI”，这也是前段时间 AI 圈大火的Harness Engineering所提倡的思想。
很多人觉得 AI 测试 “越用越坑”，本质是把本该自己把控的质量责任甩给了 AI；而真正能把 AI 用出效率的人，是把 AI 当成 “高效的工具”，而非 “甩锅的借口”。
最后想问问大家：你们在工作中用 AI 生成测试用例时，有没有踩过类似的坑？AI 有没有漏过让你后怕的边界场景？欢迎在评论区交流，我尽量每条都回复。