上周接了个活，一个电商中台系统的接口回归测试。需求文档87页，涉及用户、订单、支付、库存四个模块，前后端分离，接口文档挂在Swagger上，但有些字段的校验规则只写在PRD的表格注释里。

按老规矩，我得先花一天啃文档，再花一天写接口用例，UI自动化那块如果时间够就补几页，不够就手工点。测试报告？等跑完再说。

这次我换了个路子。把PRD和Swagger文件一起丢进工作区，配好执行环境，剩下的交给流程跑。从上传文档到拿到测试报告，总共花了不到两小时。 这篇文章把完整操作流程拆出来，包括哪些步骤是真正自动的、哪些地方需要人工介入、以及出问题时怎么排查。

一、先搞清楚这套流程由哪几块拼成

不是单一工具能搞定的事。完整链路是三层：

第一层：文档解析层。 负责读PRD和接口文档，提取功能模块、API端点、业务规则、边界条件。这一层用的是大模型加结构化提取提示词，输出一份机器可读的测试需求清单。

第二层：用例生成层。 基于解析结果，分别生成接口测试用例和UI测试用例。接口用例走HTTP真实请求，UI用例基于Playwright做浏览器操作。

第三层：执行与报告层。 跑用例、收集结果、生成结构化报告。失败的用例要做缺陷分析，通过的要统计覆盖率。

我用的是一套开源方案（项目基于Harness Engineering思想，把AI当“挽具”里的主力，人做监督和决策），底层是FastAPI + httpx + Playwright，前端是原生HTML面板。你也可以用QAgent或WHartTest，逻辑大同小异。

二、准备阶段：文档要求比你想象的高

这一步决定了后面80%的生成质量。

我丢进去的PRD是Markdown格式，不是Word。为什么强调这个？因为AI解析PDF表格时容易丢结构，Word的嵌套列表也经常被压平。Markdown的标题层级天然就是功能模块的树形结构，模型读起来最省事。

Swagger文档我导出了JSON，直接放在同级目录。如果你的接口文档是手写的Excel，建议先转成OpenAPI 3.0格式，不然字段类型和必填标记经常识别错。

有个坑得提前说：PRD里写“系统应返回友好提示”这种话，AI没法生成可验证的断言。 它只能按自己的理解补一个，结果就是用例跑通了但断言跟实际不符。所以文档里凡是涉及返回内容的描述，尽量写具体：状态码、响应字段名、错误码范围。

三、需求解析：看AI从文档里抽出了什么

上传后第一件事是跑需求解析。我用的这套平台会自动输出一份结构化分析，包括功能模块列表、API端点清单、业务规则分类（验证/安全/流程/约束）、边界条件分类（值/格式/长度/数量/时间）。

我那份文档的实际输出：

• 功能模块：7个
• API端点：11个
• 业务规则：9条
• 边界条件：6个

这里要人工过一遍。 我那次发现两个问题：一是支付模块的“超时重试次数上限”被归到了“约束”类，实际应该算“流程”规则，不影响生成但影响后续用例分类；二是有个接口的amount字段在Swagger里标记为number，但PRD注释里写了“最小单位0.01”，模型没把这条边界条件关联到该字段上。手动补一条映射关系就行。

四、接口测试用例生成与执行

解析确认后，一键生成接口用例。平台同步生成了47条接口测试用例，覆盖正常流、缺参异常、空值边界、超长边界、无认证测试。

执行环节是真正的HTTP请求，不是Mock。 每个用例跑之前会重置测试数据状态，确保用例之间不互相污染。这点比很多Mock方案靠谱，Mock只能验证逻辑，真实请求才能暴露序列化、编码、Header处理这些实际问题。

47条接口用例跑完，通过率100%。覆盖率72.7%——没到100%是因为有些接口需要第三方支付网关的回调，Mock环境没法触发，这部分得单独做集成测试。

接口测试报告里每条用例都有：请求方法、URL、请求体、响应状态码、响应体、断言结果。失败的用例会标红，附带错误摘要。

五、UI自动化：Playwright驱动真实浏览器

接口层跑完后，接着生成UI测试用例。平台基于Playwright做了页面探索，自动识别了主要页面和交互元素，生成了22条UI用例，覆盖页面加载、端到端流程、异常处理。

UI用例的生成质量取决于页面结构。 我测的这个中台前端用的是Ant Design，DOM结构规整，data-testid属性虽然有缺失但class命名比较规范，定位准确率还行。如果是那种十年前的jQuery老系统，class名全是div_1、div_2，定位会很吃力，需要手动补XPath。

22条UI用例跑完，UI覆盖率统计是100%。这里的“覆盖率”指的是生成了用例的页面/功能点占已识别页面/功能点的比例，不是代码覆盖率，别混淆。

UI执行过程中有个细节值得提：Playwright跑的是无头浏览器，截图和网络日志自动保存。有一条“提交订单时快速双击”的用例失败了，报告里直接能看到第二次点击时按钮还没进入disabled状态的截图，定位问题比手工复现快得多。

六、测试报告：自动生成，但需要人看一眼

全部跑完后，平台自动生成测试报告。报告包含质量评分、覆盖率可视化、缺陷分析和改进建议。

我那次的评分是91.8/100（等级A），计算逻辑是：通过率×50% + API覆盖率×30% + UI覆盖率×20%。

报告里最有价值的部分是缺陷分析。 失败的用例不只是标红，AI会给出失败原因的推断和修复建议。比如有一条接口用例断言失败，AI分析后指出响应中expire_time字段的格式是yyyy-MM-dd HH:mm:ss，但断言预期写的是ISO 8601，建议修改断言而非认为接口有Bug。

但AI的缺陷分析不能全信。 有一次它把接口的401响应判定为“安全规则未生效”，实际上那条用例故意不带Token，401是预期行为——用例本身的设计问题，不是接口问题。所以报告出来后，失败用例还是得人工过一遍，AI给的是线索，不是结论。

七、这套流程的真实短板

第一，文档质量决定上限。 PRD写得含糊，生成的用例就含糊。我试过拿一份口述转文字的PRD跑，生成出来的用例有一半需要重写。

第二，UI自动化对页面结构的依赖没消失。 只是从“手写定位符”变成了“AI尝试定位 + 人工修正定位”。页面结构简单的项目收益大，遗留系统收益有限。

第三，多环境切换需要额外配置。 我用的是单环境跑通，如果需要在dev/staging/prod之间切换，环境变量和测试数据的隔离策略得自己配。

第四，复杂业务规则的验证仍然吃力。 简单CRUD接口的用例生成很准，但涉及状态机、审批链、权限矩阵这类多条件交叉的业务，AI生成的用例经常漏掉组合场景。这类还是得靠有经验的测试工程师补。

八、适合谁用，不适合谁用

适合： 有相对规范PRD和接口文档的团队；以接口测试为主的回归场景；UI页面结构规整的新建系统；需要快速产出测试报告给上级或客户的项目。

不太适合： 文档全靠口口相传的老系统；强依赖人工探索经验的复杂业务测试；需要与已有测试管理平台深度集成的企业环境（开源方案的API对接能力有限）。

如果你只是想验证这套流程能不能用，建议先拿一个模块的PRD试。不要一上来就全量跑，先跑通一条链路，确认生成质量和执行环境都没问题，再铺开。

九、给想动手的人的几条实操建议

1. PRD用Markdown写。 标题层级用##和###，功能点用列表，表格保留。模型对Markdown的结构理解最准。

2. 接口文档导出OpenAPI JSON。 Swagger UI里可以直接导出，不要截图给模型看。

3. 执行环境先跑通再生成用例。 接口的Base URL、认证Token、数据库连接先配好，不然生成完用例跑不动。

4. 第一次生成后不要直接跑全量。 抽10条用例手动核对，确认生成逻辑符合预期，再批量执行。

5. 报告里的缺陷分析当线索看。 确认之后再更新用例或提Bug，不要直接把AI的分析贴到缺陷系统里。

这套流程不是“完全无人值守”，但把测试工程师从“写用例、跑用例、整理报告”的循环里拉出来了。省下来的时间可以放在文档质量提升、复杂场景补充和缺陷深度分析上。对个人来说，是工具使用方式的升级；对团队来说，是测试资产沉淀方式的改变。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。