AI 协助接口自动化从生成到维护

今天这篇分享比前几篇稍微干一点，讲一下接口自动化测试的事情。

不少方案都会让 Agent 去执行接口、调用数据库、分析日志，甚至实时决定下一步操作，这件事情在接口自动化上没有那么重要，接口自动化，特别是用来门禁的用例，更需要稳定执行。接口自动化最大的价值，是确定性：同一份代码，在任何时间、任何环境执行，结果应该一致；失败时能够复现，成功时能够追溯。

但是 AI 不干最后一公里，可以负责前面和后面的九成工作。

一、让 AI 生成自动化资产

帮我生成这个接口的 pytest。

还在这样用的话太小看 AI 的能力了，而且不能很好地完成完整的测试目的。

场景用例的话大家不同业务差别比较大，我们来先聊单接口用例，想想自己古法是怎么写的，其实重要的就是要找：

• 这个接口依赖哪些前置接口？
• Token 怎么获取？
• 哪几个参数有关联？
• 哪些字段需要断言？
• 有没有幂等要求？
• 有没有数据库校验？
• 有没有缓存刷新？

这些信息散落在各种文档，但最底层就是落到了开发代码仓库里。

其次就是要找有没有什么历史依赖/包袱，来分析要不要加断言来兜，这个一般就是靠历史用例、历史需求甚至线上 bug 历史来找，相信大家的这些 RAG 也都在建设中。

但我这边提一个效果最好的，就是开发过程中落的 Spec 文档。现在开发团队普遍都在 AI Coding 了，这么久过去，也形成了比较稳定的 Spec，Spec 和代码实现的对应这件事要开发团队来做，他们自己也肯定有这样的要求，测试团队不必把手伸得过长。通过 Spec 文档，AI 能够快速梳理功能和代码之间的关系，效果非常好。如果不提供 Spec，生成的代码的可读性、模块划分都会容易出问题。

我目前就是让 AI 同时阅读 Spec + 服务端代码，它其实已经能够推导出完整的调用关系。

最终形成的，是一个结构化的自动化测试仓库，而不是20个函数。需要让公共方法、参数分离、模块划分等等都井井有条，咱们测试团队也要 Vibe Coding 起来。

二、AI 最擅长做那些"没人愿意写"的工作

应该不会只有我不愿意做这些繁琐工作吧：

• 详细日志
• 复杂 Assert
• 错误提示
• 参数单独维护
• ……

像请求快照、耗时统计这种倒还好，可以用公共方法来统一做，但像详细日志、复杂 Assert 这种，是真烦人。人工写这些内容，投入和收益不成正比。再加上日积月累的维护，最后相当一部分测试代码变成：

assert resp.status_code == 200

失败以后：

AssertionError

跑失败了就开始享福吧，蹭蹭找日志。

而 AI 不一样。对于它来说，增加二十条日志，增加二十个 Assert，增加二十个异常提示，几乎没有额外成本，很多细节 AI 可以轻松补齐。

我觉得，很多人谈 AI，都喜欢讨论"质变"。但这种"量变"同样重要。

这个大标题下再提一点，就是每个 test 里额外让 AI 额外写一个这条用例的描述，这其实类似 Spec 的作用，对于失败排查和后续的改动、引入新用例都是很有帮助的。

三、让 AI 成为自动化资产的维护者

接口自动化最昂贵的是维护。

CI 每天都会产生大量结果，出现失败后，人工开始：

• 查看日志
• 判断是不是环境问题
• 看是不是接口变更
• 提交 Bug
• 通知负责人

这些流程其实非常适合 AI。用 hook 或者其他方式，CI 完成后，AI 自动：

• 分析失败 Case
• 判断是否属于环境异常
• 判断是否接口变更
• 判断是否断言失效
• 输出分析报告

可以利用企微、飞书的所谓"数字员工"或者其他通讯方式与负责人沟通，进行快速的测试代码修改，或者缺陷单创建。

如此，测试人员更多是在关键节点做确认，而不是重复搬运信息，让测试人员可以几乎从自动化用例维护中解放出来，干其他事情，即使出现执行失败，也是尽可能不打断测试人员的上下文，只偶尔做一个确认的操作。

四、让自动化左移

这个大标题我想说的是关于时间点的变化。

以前为什么自动化覆盖率低？因为测试结束了、版本上线了，大家才开始补自动化，结果下一版又来了，于是自动化永远追不上业务。

那如果写一个接口自动化的成本已经非常低，自动化是不是就可以提前？在测试阶段刚开始，甚至开发阶段末期，就可以介入。因为在测试阶段开始之前，很多主流程、经典异常流程、经典并发场景、经典边界 case 已经存在了。测试阶段的主要任务在于补充业务场景、完善断言、执行回归，而不是从零开始写。

当这些能反复执行的 case 在开发阶段末期就已经就绪的时候，测试阶段的回归就非常方便，大大减少了修复 bug 碰坏主要功能的可能。

这样，自动化真正提前到成为研发流程的一部分，而非测试结束后的"补作业"。

写在最后

接口自动化耗费人工时间的，是生产、维护和运营。

生成用例、补充断言、完善日志、维护仓库、分析失败、修复脚本、生成报告、创建缺陷……这些工作既重复又琐碎，却占据了大量测试工程师的精力。

如果把这些环节交给 AI，而把真正的执行继续交给稳定、可重复、可审计的自动化框架，我们得到的并不是一个"会测试的 AI"，而是一套AI 驱动的接口自动化生产体系。

也许接口自动化与产品代码是一样的，正在从"Code Driven"走向"Knowledge Driven"，未来，更重要的资产会是 Spec、业务知识、Skill、Prompt、测试策略和组织沉淀。