2026年4月13日 · 阅读 —
AI 测试不是不会写脚本，是你不敢信：Leapwork 调研把真相讲透了
图片资源未同步：未命名图片
AI 测试不是不会写脚本，是你不敢信：Leapwork 调研把真相讲透了
原文（InfoQ）：https://www.infoq.com/news/2026/02/leapwork-ai-testing/
先说结论：
测试团队对 AI 的热情已经到位了，真正卡住规模化落地的，是“可靠性”和“维护成本”。AI 能生成用例、能写脚本都不稀奇；你不敢把它接进发布流水线，才是现实。
下面是对原文的中文翻译+开发者向解读（保留所有关键数据点，不编新结论）。
1）调研核心发现（翻译）
Leapwork 发布了一项新调研：尽管大家对“AI 驱动的软件测试”信心在快速增长，但准确性、稳定性、以及持续的人工维护，仍然是决定团队敢不敢信任自动化的关键因素。
这份研究基于全球 300+ 位软件工程师、QA 负责人、IT 决策者的反馈。结论很清楚：
- 组织普遍认为 AI 会成为测试未来的一部分
- 但前提是：结果得可靠、可维护
2）数据一口气摆出来（原文百分比，别靠感觉）
| 指标 | 调研结果 |
|---|---|
| AI 已成为测试策略优先级 | 88% |
| 认为未来 2 年 AI 会对测试带来正向影响 | 80% |
| 已在使用或探索 AI（覆盖部分测试活动） | 65% |
| 已把 AI 用到关键测试工作流（覆盖核心链路） | 12.6% |
| 认为“质量/可靠性担忧”在阻碍 AI 更广泛使用 | 54% |
| 更新关键系统变更后的测试需要 ≥3 天 | 45% |
| 当前平均自动化覆盖率 | 41% |
| 认为“创建测试”是最大瓶颈 | 71% |
| 认为“维护测试”是主要瓶颈 | 56% |
| 认为“缺少时间”是自动化的主要障碍 | 54% |
表后解读（开发者视角）：
- 88%/80% 这种高值，说明“买账”不难；12.6% 这种低值，说明真正难的是进核心链路。
- 45% 更新测试要 3 天以上，本质是维护成本压垮信任：只要一次迭代把回归拖成泥潭，团队就会对“更多自动化/更多 AI”瞬间冷静。
- 41% 自动化覆盖率对很多团队其实是“真实世界的天花板”：不是不会写，是写了也扛不住变化。
3）阻力来自哪里（翻译）
阻力主要集中在三类问题：
- 准确性与测试稳定性
超过一半（54%）的人说，质量与可靠性担忧在阻碍更广泛使用。
- 端到端自动化难
团队提到：测试脆弱、跨系统端到端流程难自动化、更新测试太耗时。
- 手工维护仍是大头
平均只有 41% 自动化，最大瓶颈是创建（71%）和维护（56%）。
4）Leapwork CEO 的原话（翻译）
Kenneth Ziegler（Leapwork CEO）说：
问题不再是测试团队会不会用 agentic 能力，而是他们能多“有信心且可预测地”依赖它。团队想要 AI 帮他们提速、扩大覆盖、降低成本，但准确性是底线。真正的机会在于把 AI 跟稳定的自动化结合，让团队在不牺牲结果可信度的前提下获得速度和规模。
这句话说白了：
- AI 不是来替代自动化
- AI 是来“抬高自动化的 ROI”，但必须踩在可靠性地基上
5）行业其它调研也在说同一件事
InfoQ 原文把 Leapwork 的结论放进更大的行业背景里，对照了几份常见报告：
- Puppet 的 DevOps 报告：高绩效团队更愿意投自动化、稳定性、快速反馈；但前提是测试可靠、易维护。flaky tests 一直是阻塞点。
- GitLab 年度调研：多数人相信 AI 会改变开发（含测试），但深度进入生产工作流的仍是少数；担忧集中在信任、可解释性、与现有工具链的集成。
- Tricentis World Quality Report：自动化覆盖率通常在 30–50%，维护成本、不稳定测试、资源不足是老大难；AI 辅助生成受关注，但“完全替代人工验证”大家仍谨慎。
- DORA：强自动化、可观测性、故障恢复实践更强的团队整体指标更优；AI 工具的采用往往伴随更多的验证与观测投入。
- IDC：企业 AI 试点多、规模化落地少；原因是治理风险、人才缺口、运维复杂度。
6）开发者自己的经验想法：AI 测试要变成“可交付系统”，得补 3 个基建
这里不讲“更会写用例”。讲“更能上线”。
6.1 基建一：把 flaky tests 当 P0
AI 再强，建立在 flaky 的回归上也会变成噪声放大器。 优先顺序建议：
- 先把不稳定来源打掉（环境、依赖、数据、等待条件）
- 再谈生成更多用例
6.2 基建二：把维护成本做成指标（不然永远被 3 天更新拖死）
原文 45% 的“三天+”是一个很狠的信号。 建议把“维护”量化：
- 测试变更 lead time
- 失败原因分布（环境/数据/断言/页面元素/接口兼容）
- 每次发布的回归返工时长
6.3 基建三：把 AI 放在“稳定自动化旁边”，不是放在上面
AI 最适合的落点：
- 帮你找覆盖缺口、写初稿、补断言、做分类与归因
- 但关键链路要有稳定的执行与验收机制（尤其是 release gate）
7）结合 OpenClaw：把“AI + 自动化”变成可审计的流水线
如果用 OpenClaw 的思路去做，会更像工程系统，而不是“买个工具就完事”。
建议三件事：
- 把测试任务做成 skills
- 例如：收集失败用例、归因分类、生成修复建议、生成回归清单
- 把证据链落盘（日志/输入/输出/工单链接）
- 这样才能从“感觉 AI 不靠谱”变成“知道它在哪不靠谱”
- 用回归集做灰度验证
- 不要拿生产发布当第一手实验
#软件测试 #测试自动化 #QA #AI测试 #DevOps #可靠性 #回归测试 #工程效率 #OpenClaw #Agent