37岁测试搭了一个AI测试助手——AITS,砍掉70%的重复劳动【附源码+操作手册】

写用例、对接口、改脚本、翻日志、拼报表——这些事占掉了一天里的大半时间。我把它们交给了一个AI助手，现在留给自己的，是那30%真正需要动脑的部分。

一个让我决定动手的下午

去年冬天的一个下午，我在工位上等一个回归结果。

那轮回归跑了三个多小时，失败了五条。我一条条翻日志、对截图、查历史记录，等找到第五条失败的原因时，窗外已经黑了。我靠在椅背上想了一件事：今天这一天，我到底做了多少真正需要“我”来做的事？

答案有点残酷。

看需求、写用例、对参数、改选择器、翻日志、整理表格——这些事换任何一个人来做，结果都不会差太多。真正需要经验、需要判断、需要拍板的部分，可能只占三成。

剩下那七成，是重复劳动。

我不是没想过用工具解决。但市面上的测试平台，用起来总有种“又多了一份工作”的感觉：要学它的操作逻辑，要维护它的配置，要在几个系统之间来回切换。工具是多了，活没少干。

我想要的是另一种东西。一个不用我伺候它、反而能替我分担的助手。

这个念头，最后变成了 AITS——一个我自己动手做的 AI 测试智能助手。现在它开源了。

一、先说清楚：AITS 和普通测试平台不是一回事

我把测试平台分成两类。

一类是工具箱：功能很全，按钮很多，但你要自己去用。什么时候用哪个功能，怎么组合，全靠你自己判断。工具箱越多，你要记的东西就越多。

另一类是助手：它不增加你要学的东西，而是在你干活的时候，默默把旁边那些琐碎的部分接过去。

AITS 是第二类。

举个例子。你在写用例，它不会弹一个窗口让你选模板，而是直接把你贴进来的需求变成结构化用例，边界值和异常流都补好。你在串接口流程，它不会让你一条条拖拽，而是听你说一句“我要测下单到支付完成”，就把链路给你搭出来。

区别在哪？工具箱是你去适应它，助手是它来适应你。

下面这张表，是我做 AITS 时反复对照的一张清单。左边是测试工程师每天在干的事，右边是 AITS 能接过去的部分。

这张表里的每一行，都是我过去几年真实花过时间的地方。

二、四个测试环节，我一个个把重复的部分拿掉

AITS 覆盖 API、Web、App、性能四个测试环节。我不打算把每个功能都讲一遍，只说每个环节里，我到底砍掉了什么。

2.1 接口测试：砍掉“手动串流程”

以前：接口文档一更新，我得对着 Swagger 一条条核对参数，看哪些用例要补、哪些要改。遇到多接口业务流，比如下单到支付完成，得把涉及的接口一个个拖进场景里，配好参数依赖，调通执行顺序。

这套流程本身不难，但很碎。碎到你一天只能串两三条链路。

现在：Swagger 导进来，接口定义自动解析。我只需要告诉 AI 我要测哪条业务链路，它把接口串好，生成可执行的场景用例。

我砍掉的是“搬运”这个动作。接口之间怎么连、参数怎么传，这些有规律可循的事，交给 AI 去做。

2.2 Web 测试：砍掉“改选择器”

以前：页面一改版，脚本挂一片。最怕的不是挂，是不知道为什么挂。选择器散在几十个脚本里，一个一个找、一个一个改，改完还要重跑验证。

有段时间我一听到“UI 改版”就头疼。

现在：元素统一放在元素库里维护，脚本引用的是元素库里的对象。页面变了，改元素库一处，所有引用它的脚本自动适配。

我砍掉的是“重复修改”这个动作。同一个选择器改几十遍，这件事本身就不该由人来做。

2.3 App 测试：砍掉“一台台设备轮着跑”

以前：移动端测试最烦的是设备多、页面变、脚本脆。一套脚本在这台设备上能跑，换一台就挂。页面稍微调整，断言就失效。

现在：POM 智能解析把移动端页面对象自动提取出来，UI 智能体负责交互和断言。页面变了，它自己适应。多设备并行，一套脚本多端跑。

我砍掉的是“适配”这个动作。设备差异、页面变更带来的重复调整，本来就不该占那么多时间。

2.4 性能测试：砍掉“对着报告猜瓶颈”

以前：压测跑完，报告里一堆指标曲线。CPU、内存、响应时间、吞吐量，哪个是瓶颈？得靠经验去猜，猜完再去查，查完再验证。

这个过程很依赖人，而且很慢。

现在：告警触发 AI 诊断，直接给出瓶颈定位和排障建议。比如“瓶颈在数据库连接池，建议查慢 SQL 和连接数配置”，我拿着这个结论去验证就行。

我砍掉的是“猜”这个动作。从一堆数据里找方向，AI 比人快。

三、让这些“搭把手”成立的，是背后那层统一大脑

上面说的这些能力，如果每个环节单独对接一套 AI，维护成本会高到离谱。

所以我做了一个 AI 引擎层，把能力统一管起来：

关键在“统一”两个字。

我在接口测试里配好的模型，Web、App、性能测试直接就能用。不用每个模块重新配一遍，不用维护好几套 Key。

这也是我坚持做“助手”而不是“工具箱”的原因。工具箱是各自为战的，助手应该是统一大脑、统一调度的。否则你只是把重复劳动从手动变成了配置。

四、测试负责人最耗时的“收集信息”，也一并砍掉

如果说测试工程师的重复劳动在操作层面，那测试负责人的重复劳动就在信息收集层面。

打开接口平台看通过率，打开 Web 平台看执行情况，打开性能平台看压测报告，然后复制粘贴到 Excel 里拼图表。每天如此。

驾驶舱就是冲这件事做的：

• • 项目切换器，快速定位当前关注的项目
• • 核心指标卡片，今日通过率、执行数、AI 用例占比一屏看清
• • 近 7 日通过/失败趋势图
• • 高频报错用例 Top5，反复失败的先盯住
• • 一键跳转各测试环节
• • 卡片布局可拖拽，位置记在本地

以前要开三个系统、拼一张表，现在十秒内看清当天质量风险。

五、一次配置，四个环节都能用

环境管理、定时任务、通知接收，这三样是贯穿所有测试环节的基础设施。

• • 环境管理：多环境变量、基础地址、凭据配置
• • 定时任务：Cron 表达式、执行策略、历史记录
• • 通知接收：钉钉、企微、邮件推送策略和接收人

配置一次，四个测试环节通用。不用在 API 里配一遍，再到 Web 里配一遍。

这一点看起来不起眼，但用起来就知道省了多少重复配置的时间。重复配置本身，也是一种重复劳动。

六、36 岁做这件事，我想的是什么

我今年 36 岁，在测试行业干了十多年。

这个年纪做开源，身边有人问值不值。我的想法很简单：正因为干了十多年，才更清楚哪些时间是白花的。

写 AITS 的过程里，我反复问自己一个问题：这个东西，能不能真的让一个测试工程师的一天变得不一样？

如果只是多了一个平台，那没有意义。如果能让那些重复的操作少一点、让信息搬运少一点、让工具切换少一点，把时间还给真正需要判断的部分——那这件事就值得做。

所以我把它开源了。代码和操作手册都准备好了，你可以自己搭一套，看看能不能把属于你的那 70% 拿回来。

想要的宝子，关注本公众号，在后台留言「666」，我无偿发你代码和操作手册。

结语：那 70% 拿回来之后，才是测试工程师真正该做的事

AITS 的逻辑其实一句话就能说完：

四个测试环节 + 一层 AI 引擎 + 一层公共能力 + 一个驾驶舱 = 一个替你分担重复劳动的助手。

它不是让你多学一个工具，而是让你在写用例、串接口、改脚本、跑回归、写报告的时候，都有一个 AI 在旁边搭把手。

• • 写用例时，补边界值
• • 接口变更时，提示影响范围
• • 脚本挂了时，告诉你改哪里
• • 回归失败时，收敛排查方向
• • 汇报时，十秒给你全局视图

我搭 AITS 的初心，就是把那 70% 的重复劳动砍掉，让测试工程师的时间，花在真正需要判断的地方。

36 岁，我选择重新出发。这条路，希望有更多人一起走。

如果觉得有收获，欢迎点赞、在看、转发三连。

👇 关注，留言「666」，无偿获取代码+操作手册