原创内容，未获授权禁止转载、转发、抄袭。

最近 AI 测试工具越来越多，很多同学一上来就问：

“能不能直接让 AI 帮我把测试用例写完？”

“能不能直接生成自动化脚本？”

“是不是以后测试都不用点页面了？”

我的感受是：AI 确实能提效，但它不是来替你做判断的，而是帮你把重复劳动压缩掉。

这一期先聊最关键的第一步：怎么用 AI 从需求里拆出可靠测试点，而不是只生成一堆看起来完整的用例。

---

一、本篇解决什么问题

很多团队尝试 AI 测试时，第一步就跑偏了：

• 直接让 AI 写用例
• 直接让 AI 生成脚本
• 直接把 AI 输出复制进用例库
• 结果看起来很完整，真正执行时发现业务风险没覆盖

所以本篇重点不是讲工具怎么用，而是讲：

AI 生成的是初稿，测试人员要补的是业务风险。

---

二、AI 测试不是替代测试，而是重构测试流程

更靠谱的做法是：把 AI 放在测试流程中最耗时间、但判断门槛相对可控的位置。

测试环节	传统方式	AI 可以做什么	是否建议交给 AI
需求分析	人工阅读 PRD	提取功能点、边界条件、异常场景	建议辅助
用例设计	人工编写用例	生成初版用例、补充反向场景	建议辅助
自动化脚本	手写定位和断言	生成 Playwright/API 测试脚本	建议辅助
执行结果分析	人工看日志截图	总结失败原因、归类缺陷	建议辅助
发布判断	测试负责人决策	提供风险摘要	不能完全交给 AI

一句话：

AI 可以当测试助手、脚本助手、分析助手，但不要直接当质量负责人。

---

三、一套可落地的 AI 测试闭环

我更推荐的流程是：

这个流程里有一个关键点：

AI 生成的东西都要经过人工确认，但人工不再从 0 开始。

---

四、工具怎么选？不要迷信单一工具

工具/方向	适合做什么	不适合做什么
Claude Code / Cursor / Trae	生成脚本、解释代码、重构测试工程	直接判断业务是否正确
Playwright	稳定执行 Web 自动化测试	完全靠自然语言理解复杂业务
Midscene.js	视觉驱动、自然语言操作 UI	大规模稳定回归还要谨慎
TestSprite	从代码/页面生成测试计划、测试报告	复杂业务规则仍需人工补充
接口自动化框架	核心链路回归、数据校验	替代 UI 体验测试

我的理解是：

Playwright 负责稳定执行，AI 工具负责降低编写和维护成本。

不要为了 AI 而 AI。

如果一个登录流程用 Playwright 写 20 行就很稳定，就没必要强行上复杂工具。

---

五、实战场景：以“订单提交”流程为例

假设我们有一个常见需求：

用户选择商品后加入购物车，确认收货地址，提交订单。若库存不足、地址为空、优惠券不可用，需要给出明确提示。

可以先让 AI 帮我们拆第一版测试点。

你是一名资深测试工程师，请根据下面需求拆解测试点。

要求：
1. 按功能场景、异常场景、边界场景、安全场景分类
2. 每个测试点给出测试目标、前置条件、测试步骤、预期结果
3. 补充容易遗漏的风险点
4. 输出 Markdown 表格

需求内容：
用户选择商品后加入购物车，确认收货地址，提交订单。
若库存不足、地址为空、优惠券不可用，需要给出明确提示。

AI 生成后，不要直接复制进用例库。

建议重点检查这些内容：

检查项	说明
主流程	正常加入购物车、提交订单成功
反向场景	库存不足、地址为空、优惠券失效
边界值	商品数量为 0、1、库存上限、超过库存
幂等性	重复点击提交订单是否重复生成订单
数据一致性	订单金额、优惠金额、库存扣减是否一致
权限问题	是否能提交他人购物车或地址
异常恢复	支付失败、接口超时后订单状态是否正确

这里最容易漏的是：

重复提交、库存扣减、金额一致性、越权访问。

这些才是测试人员真正要盯住的地方。

---

六、AI 生成用例后，测试人员要补什么

AI 生成的用例通常有一个特点：

看起来很完整，但容易偏通用。

比如它会写：

• 验证提交订单成功
• 验证库存不足提示
• 验证地址为空提示
• 验证优惠券不可用提示

这些没问题，但还不够。

订单场景至少要继续补这些风险：

风险点	测试关注点
重复点击提交	是否生成重复订单
库存临界值	最后一件库存是否会被超卖
优惠券抵扣	金额计算是否准确
地址归属	是否能使用别人的地址
订单状态	创建、待支付、取消、支付失败状态是否正确
接口超时	前端是否重复提交，后端是否幂等
支付失败	库存是否回滚，优惠券是否恢复

所以我的建议是：

AI 负责生成初稿，测试人员负责补业务风险。

---

七、总结

这一期主要讲 AI 自动化测试的第一步：从需求到测试点。

核心结论：

1. AI 测试不是替代测试，而是重构测试流程
2. AI 适合做需求拆解、用例初稿、异常场景补充
3. 测试人员不能直接相信 AI 生成的用例
4. 真正有价值的是把业务风险补进去
5. 用例设计阶段打好基础，后面的自动化才不会变成花架子

下一期继续讲：

如何把 AI 生成的测试用例，真正落到 Playwright 自动化脚本里。