AI 测试用例生成：工作量占比与实际差距

虽然 AI 能够自动完成大部分测试用例的生成，但团队仍需投入大量的工程时间进行人工审查和基础设施维护。有人称其 AI 能完成 80% 的测试用例编写，而实际这 80% 仅仅是打字工作，而非 80% 的工程任务。剩下的 20% 才是真正需要投入精力的地方，且这 20% 所需工作量并非 2%，而是接近 30%，这一差距决定了流水线的交付情况。本文将探讨这一差距。

六阶段智能流水线的构建与运行

作为一个关于大语言模型（LLM）增强测试方法的独立研究项目，构建了一个六阶段的智能流水线，它可以读取 Figma 中的设计，并通过模型上下文协议（Model Context Protocol，MCP）端到端地在 WebDriverIO 中生成可运行的测试用例。该流水线运行良好且实用，但出现问题的部分出乎预料。

如何通过一个协议搭建六阶段流水线

这条流水线按顺序运行六个阶段，每个阶段由不同的智能体负责，每次交接都通过 MCP 完成。六阶段智能测试流水线包括：设计捕获→需求编写→工单创建→代码生成→测试用例编写→自动化生成。每个阶段都有 MCP 交接和来源标记，端到端的跟踪可以将拉取请求追溯到 Jira 工单、需求文档和 Figma 设计框，每个工件都会标记生成它的智能体、使用的模型以及输入数据。

MCP 让整个流程得以运转，常被说为“AI 的 USB - C”，即一个开放协议可适配任何工具，这个说法大概有 80% 是对的。无需为智能体要交互的每个系统编写定制适配器，每个工具配备一个 MCP 服务器，所有智能体都以相同的方式与其通信。智能体之间的类型化交接是自行设计的架构，构建在 MCP 之上。每个智能体生成一个类型化的工件供下一个智能体读取，每次交接都会记录来源信息，当第六阶段出现问题时可重现整个流程。若没有这种规范，多智能体流水线调试会很困难，有了规范就能准确指出问题阶段及输入数据。这个模式有一个遵循 MIT 许可的公开参考实现。

所谓的 16 分钟是营销数字，从 Figma 输入到自动化测试套件输出，整个流程端到端运行大约需要 16 分钟，但这是最没参考价值的部分，而之后人工审查每个交接环节所花费的时间，才是真正的工作所在。

生产环境运行中实际出现的问题

让流水线停滞的故障很少是预期的那些。预期会出现幻觉 API、“输入简略、输出简略”情况、定位器漂移等，智能体也继承了这些问题。但没想到真正让流水线长时间停滞的是基础设施问题，如模型后端在负载下超时、丢失凭证、共享长轮询 API 端点冲突、智能体内部未处理异常导致调度器中止等。解决办法是在阶段之间设置类似断路器的审查检查点以及“四重防护原则”，包括微服务中的隔离模式、纯数据回退机制、设置单一所有者租约、每个智能体在开始工作前生成已知正确的响应。这些防护措施是在新边界上应用的经典稳定性模式。

你看不到的 20% 以及何时不适合使用这种流水线

演示视频往往忽略即使流水线运行正常，每个阶段的人工时间也不会降为零。在五个流水线阶段中，人工审查时间分别为：代码审查 60 - 180 分钟，自动化审查和修复不稳定测试的循环 30 - 90 分钟，工单架构和排序 30 - 60 分钟，测试数据和环境准备 15 - 30 分钟，需求审查 20 - 30 分钟。总体而言，人工仍需投入原始工作量的 20 - 30%，且几乎都是用于审查而非创建。

这条流水线能节省 70 - 80% 的工作量，而非 98%，陷阱在于没有为节省不了的 20 - 30% 工作量做好预算。当 Figma 设计有丰富注释且验收标准明确，团队有足够审查能力，技术栈在训练数据中有良好体现，功能是全新开发时，这种流水线比较合适；当设计只存在于白板上，集成涉及旧代码，流程受监管或对安全要求高，没有资深审查人员，工作是探索性的时，不适合使用这种流水线。成功使用智能体流水线的团队会为返工工作做好预算，而遇到困难的团队则相反。正确的衡量标准是“80/20 返工规则”，能够正确估算返工量的团队，其 AI 投资才能产生复利效应。

本文是 Foundry 专家贡献者网络的一部分。想加入吗？人工智能、开发工具、软件开发、开发方法。