前天面试了一个有着五年经验的测试工程师。
简历上写得挺漂亮：熟练使用AI生成测试用例，用AI实现自动化测试。我心想，这哥们儿应该有点东西，就抛了一个真实的项目问题过去。
没想到，他的回答把我惊呆了。
题目是这样的：
你用AI做测试，需求文档是完整的电商订单流程。AI生成了120条测试用例，3000 行UI自动化脚本，覆盖了正向下单、支付、退款流程。结果上线后一小时，大量用户反馈无法完成订单支付。
排查发现两个核心问题：
- AI生成的用例漏了订单金额为0.01元的边界值、支付时网络中断重试这两个关键场景
- 自动化脚本只实现了点击操作，没有断言支付成功后订单状态变为待发货，也没有处理支付超时的异常场景，导致测试时没发现问题，上线后直接引发生产故障。
我接着追问了三个问题，每一个都是面试必问：
第一，你在审核AI生成的订单支付用例时，怎么判断AI有没有漏测边界值异常场景？
第二，自动脚本跑通就代表没问题吗？你会具体检查脚本的哪些细节，如何避免没有断言、没有异常处理的情况。
第三，这次故障后，你会怎么优化AI测试的流程，保证下次不再出现漏测脚本无效的问题？
没想到，他张口就来：
"我就把AI生成的用例大致扫了一遍，看步骤完整、没有明显错误就够了。"
"脚本能跑通就行，没必要查那么细。"
"故障后……下次让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理解的就是"输入金额→确认支付→扣款成功"。但它不会知道：
正确的做法是先人工拆解需求，梳理出几大模块：
把这几大模块的结构化清单、历史Bug案例、业务禁止规则，一起喂给AI，限定生成范围，限定覆盖维度。让AI在你划定的框架内产出，而不是任由它随意编造业务逻辑。
尤其是支付、订单、用户权限、数据隐私、资金流转这类核心模块，
必须提前做场景锁定，强制 AI 全覆盖，绝不让它随意编造业务逻辑。这一步的核心是 “人主导、AI 辅助”，用人工的业务理解弥补 AI 的认知盲区。
AI产出的测试用例，从来不是全部可用的。而是要学会快速分类筛选：
第一类：标准正向用例
第二类：待修改用例
第三类：直接废弃用例
同时还要检查自动化脚本，看脚本是否只实现了页面操作，缺少结果断言，缺少异常捕获，缺少环境兼容适配，这类脚本跑通也没有任何测试意义，必须整改。
这一步的关键是 “不迷信 AI 产出”，用人工的专业判断筛选出真正有价值的内容，避免无效用例占用测试资源。
判断AI测试用例可不可靠，不能凭肉眼感觉，要有量化标准。
首先，核对需求覆盖率，对照需求文档每一个功能点，检查有没有遗漏、未覆盖的模块。
其次，统计反向用例、边界用例、异常用例的占比。正常业务不能只有正向用例，没有反向和异常兜底。然后排查重复用例率、逻辑错误率、高危场景遗漏率。
结合项目历史缺陷库，校验AI有没有覆盖过往线上出过的同类bug
具体供参考：
| 校验维度 | 具体做法 | 合格线 |
|---|---|---|
| 需求覆盖率 | 对照需求文档逐条映射，看每个功能点有没有对应用例 | ≥95% |
| 反向用例占比 | 反向/异常用例占总用例比例 | ≥30% |
| 边界用例数量 | 每个数值型字段至少2个边界值（最小、最大） | 100%覆盖 |
| 重复用例率 | 语义重复的用例占比 | ≤10% |
| 逻辑错误率 | 业务逻辑错误或无法执行的用例占比 | ≤5% |
| 高危场景遗漏率 | 权限/并发/弱网/非法输入/参数篡改等场景 | 0% |
| 历史缺陷覆盖率 | 过去3个版本的线上Bug，AI用例能否覆盖 | ≥80% |
除此之外，还要重点核对AI最容易忽略的高危场景，比如
这些是 AI 最容易忽略，但最容易引发线上故障的点，用数据做校验，才是专业测试的做事方式。
AI 永远替代不了人的业务经验，核心场景必须层层把关，所以这里，我建议的做法是，建立 “初审 + 复核 + 终审” 的三级审核机制：
三道关卡层层过滤，能从根本上杜绝 AI 的错漏内容流入执行阶段，这也是规避线上故障的关键。
AI 测试不是一次性行为，一定要做长期沉淀优化。
建议在每次项目结束后，记录三类信息：
1、AI翻车案例库
2、优质模板库
3、训练数据集
形成完整闭环：
需求拆解 → 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 圈大火的Harness Engineering 所提倡的思想。
很多人觉得 AI 测试 “越用越坑”，本质是把本该自己把控的质量责任甩给了 AI；而真正能把 AI 用出效率的人，是把 AI 当成 “高效的工具”，而非 “甩锅的借口”。
从 “甩手掌柜式用 AI” 到 “系统化管控 AI”，需要建立完整的思维体系和落地方法 —— 这也是我为什么想推荐大家加入「AI 进化社」的原因。在这里，我们不会只讲 “AI 如何生成测试用例”，而是从测试全流程出发，结合真实的项目实战案例，拆解 AI 测试的管控体系，分享踩过的坑、沉淀的模板、量化的标准，还有资深质量总监的审核思路和复盘方法。
无论是想应对面试中 “AI 测试落地” 的高频问题，还是想在实际工作中真正用 AI 提效、规避线上故障，「AI 进化社」都能给到可落地的方法和实战案例。与其自己摸索踩坑，不如跟着有实战经验的团队，建立系统化的 AI 测试思维，让 AI 真正成为测试提效的利器，而非埋雷的隐患。
感兴趣的同学可以了解一下，「AI进化社」目前开放报名，具体信息可以私信我（wx: 762357658）。
最后想问问大家：你们在工作中用AI生成测试用例时，有没有踩过类似的坑？AI有没有漏过让你后怕的边界场景？欢迎在评论区交流，我尽量每条都回复。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。