AI 测试生成:QA 的未来

AI 测试生成与自愈测试，是把 AI 用到测试用例设计、脚本生成、自动化执行、失败归因和脚本维护里。

它不是让测试工程师消失，而是让测试工程师从重复维护脚本，转向设计质量策略和判断风险。

AI 在测试里能做什么

AI 测试不是单点工具，而是覆盖测试生命周期。

测试生成不等于测试充分

AI 很会生成用例，但也可能生成很多看起来合理、实际价值不高的用例。

好的测试生成要基于：

• • 需求。
• • 用户路径。
• • 风险等级。
• • 历史缺陷。
• • 线上反馈。
• • 业务规则。
• • 数据边界。

不要只让 AI “生成 100 条测试用例”。数量不等于覆盖。

Playwright MCP 给了什么启发

Microsoft Playwright MCP 是一个 MCP Server，让 LLM 可以通过 Playwright 和网页交互。

其 README 提到，它通过结构化 accessibility snapshot 与页面交互，而不是只依赖截图；它适用于探索式自动化、自愈测试、长时间自动化流程等场景。

这说明浏览器自动化正在从“写死脚本”走向“AI 能理解页面结构并操作页面”。

什么是自愈测试

传统 UI 自动化最痛苦的是定位器坏。

比如原来按钮是：

button#submit

后来前端改成：

button[data-testid="save"]

测试脚本失败，但功能可能没坏。

自愈测试会尝试根据文本、角色、布局、历史定位器和页面结构，自动找到新的元素。

但要注意：

自愈不是自动把失败吞掉
自愈必须证明它找的是正确元素

失败归因很有价值

自动化失败常见原因：

AI 可以帮忙读取日志、截图、trace、最近代码变更，给出初步归因。

一个 AI 测试工作流

读取需求
  -> 生成测试点
  -> 人工评审
  -> 生成自动化脚本
  -> 执行测试
  -> 分析失败
  -> 建议修复脚本或创建缺陷
  -> 更新回归集

重点是：AI 生成后要有人审，AI 分析后要有证据。

AI 测试生成的质量怎么评估

AI 生成的测试也要测试。

一个测试用例示例

case_id: ai_test_gen_001
requirement: "用户可以修改手机号，需短信验证码验证"
expected_generated_cases:
  - "正常修改手机号"
  - "验证码错误"
  - "验证码过期"
  - "手机号已被占用"
  - "未登录访问"
  - "频繁发送验证码限制"
forbidden_behavior:
  - "只生成 happy path"
  - "没有权限和安全用例"
  - "生成无法执行的步骤"

自愈测试要怎么控风险

自愈建议分级：

自愈只应该修脚本脆弱点，不应该掩盖产品缺陷。

常见坑

第一个坑：AI 生成用例没人评审。

AI 可能漏高风险场景，也可能编造不存在功能。

第二个坑：自愈把 Bug 修没了。

测试失败可能是真 Bug，不能自动改脚本让它通过。

第三个坑：只测 UI，不测接口和数据。

AI 测试也要分层：单元、接口、UI、端到端。

第四个坑：脚本依赖视觉猜测。

优先使用可访问性树、稳定 test id、语义定位器。

实践清单

• • 选一个需求，让 AI 先生成测试点。
• • 人工评审后再生成脚本。
• • 脚本优先使用稳定定位器和语义定位。
• • 执行后让 AI 分析失败原因，但要求证据。
• • 自愈修改必须记录 diff 和原因。
• • 高风险断言失败不能自动自愈。
• • 把真实缺陷和误报结果回流优化提示和规则。

小结

AI 会让测试工程效率提高，尤其是在用例草拟、脚本生成、失败分析和报告总结方面。

但测试的判断权不能完全交给 AI。真正重要的是风险理解、覆盖策略、缺陷判断和质量门禁。

对算法测试工程师来说，AI 测试工具不是威胁，而是放大器。会用它的人，能把更多精力放在高价值质量分析上。