很多团队在尝试 AI+测试 时，第一反应都是：
让AI生成测试用例。
但在真实项目里，这个方案往往很难落地。
我们团队也尝试过，结果遇到三个问题：
-
AI生成的用例太多
-
和原有用例重复
-
审核成本反而更高
后来我换了一种思路：
不让AI写用例，而是让AI专门找“漏测风险”。
结果反而更容易在团队推广。
今天分享一下这个实践。
一、真实团队里的三个问题
很多测试团队其实都有类似情况。
1 测试工程师已经有自己的用例风格
我们团队的测试工程师整体经验不错，用例写得也比较成熟。
每个人都有自己的写作方式：
-
有人按流程写
-
有人按场景写
-
有人按状态写
团队并没有严格统一模板。
因为 过度标准化会降低效率。
如果让AI生成完整用例，很容易出现：
-
用例重复
-
风格不一致
-
审核时间变长
反而影响效率。
2 跨模块测试容易漏测
在很多团队中：
测试通常负责自己的模块。
当需求涉及多个模块时，经常会出现：
-
不熟悉业务
-
需要时间理解逻辑
-
不容易想到全部场景
这种情况下就特别容易出现：
测试遗漏。
3 AI生成完整用例冗余严重
我们实际尝试过让AI生成测试用例。
结果通常是：
-
20条用例
-
50条用例
-
甚至100条
问题在于：
很多内容是 低价值重复用例。
最终变成：
人工审核成本更高。
团队成员自然会产生抵触。
二、后来我换了一个思路
既然生成用例不适合团队。
那AI还能做什么？
后来我把AI的角色换了一下：
不是写用例，而是检查用例。
简单来说就是：
让AI做一个“测试风险检查官”。
它只做一件事情：
扫描测试用例是否存在漏测风险。
三、AI风险补全工作流程
整个流程其实非常简单。
AI在这里扮演的角色其实很简单：
帮你检查有没有遗漏的测试点。
四、AI主要扫描五个风险维度
AI最擅长的其实是：
系统化检查。
我们给AI定义了五个检查维度。
| 维度 | 示例 |
|---|---|
| 功能路径 | 是否覆盖所有流程 |
| 边界条件 | 最大值、最小值 |
| 状态流转 | 状态切换是否验证 |
| 权限角色 | 不同角色是否测试 |
| 异常情况 | 网络异常、接口失败 |
人写用例通常是：
按思路写。
AI检查则更像：
按检查清单扫描。
五、AI发现漏测示例
假设需求如下：
需求
用户可以修改手机号，需要短信验证码验证。
已有测试用例
1 输入正确验证码修改成功 2 输入错误验证码提示失败
AI扫描结果
已覆盖
-
正确验证码流程
-
错误验证码流程
AI识别潜在漏测
边界情况
-
验证码为空
-
验证码长度错误
-
验证码过期
状态限制
-
未登录用户修改手机号
-
手机号已绑定其他账号
限制策略
-
验证码错误次数限制
-
验证码发送频率限制
异常情况
-
短信接口失败
-
网络异常
AI建议补充测试点
1 验证码为空提交
2 验证码过期提交
3 验证码错误次数限制
4 手机号已被占用
5 短信发送失败处理
原本2条用例。
AI帮你补充了 关键风险点。
但不会生成一堆冗余用例。
六、这种方式在团队里的使用方式
目前我们主要在三个场景使用。
写完用例后扫描
流程：
用例 ↓ AI扫描风险 ↓ 补充遗漏
需求评审阶段
流程：
需求评审 ↓ AI风险分析 ↓ 提前补充测试点
版本回归阶段
流程：
测试用例 ↓ AI扫描 ↓ 发现遗漏
七、为什么这种方式更容易落地
相比 AI生成测试用例。
这种方式有三个优势。
1 不改变团队习惯
测试工程师依然按自己的方式写用例。
2 审核成本很低
只需要看AI提出的风险点。
3 团队更容易接受
AI是辅助思考，而不是替代测试。
八、总结
在测试团队实践AI时，一个经验是：
不要让AI做太复杂的事情。
让AI专注做一件事：
发现测试用例的漏测风险。
这个能力：
-
实现成本低
-
团队容易接受
-
对测试质量提升明显
对于很多测试团队来说，这可能是：
AI测试最容易落地的一步。
附：AI风险补全提示词模板
可以直接使用：
角色：资深测试专家
任务：
根据需求描述和已有测试用例，分析是否存在测试遗漏。
分析维度：
1 功能路径
2 边界条件
3 状态流转
4 权限角色
5 异常场景
输出：
一、已覆盖测试点
二、可能遗漏的风险场景
三、建议补充的测试点
更详细的版本可以参考我另外一篇文章：
原文链接：https://blog.csdn.net/anyongjin/article/details/158698479
九、后续文章
后面我还会继续分享三个 AI测试助手实践：
-
AI测试用例风险补全助手
-
AI需求变更影响分析助手
-
AI回归测试范围评估助手
这三个能力组合起来，其实就是一个 AI测试决策辅助体系。
扫一扫
417
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
