36岁测试大佬搭了一个AI智能测试助手AITS,测试效率提高200倍!(附代码和使用手册)

以前我改一个断言，平均要花四分钟。 打开文件，找到那行assert status_code == 200，改成assert response.json()["code"] == 0，保存，跑一遍，确认通过。一个接口四分钟，一个模块四十个接口，一百六十分钟。 后来我把这个动作交给了AITS。现在改一个断言，四秒。

我36岁，做了十年测试。搭这个助手之前，我每天花在写脚本、改断言、调接口、整理报告上的时间，占了我工时的七成。真正用来思考“测什么”“怎么测”“风险在哪”的时间，不到三成。 现在反过来了。

很多人一听AI测试助手，第一反应是：不就是把需求贴给ChatGPT，让它生成用例吗？ 不是。 AITS是一个完整的AI驱动智能测试平台。 它有六大测试域：API自动化、Web自动化、App自动化、性能测试、AI智能技能、缺陷管理。每个域都有独立的工作区，独立的配置，独立的知识库。 打开浏览器，左侧栏是功能入口。最上面是“智能驾驶舱”，下面是“API测试”“Web测试”“App测试”“性能测试”。每个入口对应一个固定任务，有专属的表单和输出模板。

二、向量知识库：让AI“懂业务”而不是“瞎猜”

AITS最底层的东西，不是大模型，是向量知识库。 什么意思？就是把你项目的业务逻辑流程、UI元素定位、接口规范文档，全部向量化到数据库里。AI生成用例的时候，不是凭空编，是从知识库里检索。 这个设计解决了AI测试最大的问题：准确率。 以前让AI写用例，它给你生成“用户登录后添加购物车商品”——听着没问题，但它不知道你们项目的登录按钮叫“立即登录”还是“Sign In”，不知道加购按钮的CSS选择器是什么。

这意味着什么？意味着AI写的用例，用的是你项目真实的元素定位、真实的接口参数、真实的业务规则。不是“大概是这样”，是“就是这样的”。 而且知识库支持人工反哺。AI生成的用例经测试工程师审核后，修正过的优质用例和定位信息回流到知识库，形成一个闭环优化的机制。用得越久，知识库越准，AI越懂你的项目。

API测试是AITS最成熟的模块。 传统流程是什么？打开Swagger，看接口文档，手动写请求方法、URL、headers、body，然后写断言。一个接口写完，再写异常场景、鉴权场景、幂等场景。一个模块写完，大半天。 AITS的流程是：把接口文档丢进去，它自动生成完整的测试脚本。 不是只测200。它测200、400、401、403、重复提交、空参数、超长参数。不是只检查HTTP状态码，它把业务code和关键字段一起纳入断言。 而且它支持业务流程编排。什么意思？就是它能理解接口之间的调用顺序和数据依赖关系。登录接口返回的token，自动传到后续的订单接口做鉴权。多个接口串起来，形成端到端的业务测试流程。 以前配一个带参数化、带断言、带关联提取的接口测试，加上调通，两个小时。现在生成初版两分钟，微调五分钟，直接进回归集。

四、Web自动化：自然语言驱动，不用写选择器

Web测试是AITS最让我惊喜的模块。 传统UI自动化最大的痛是什么？选择器。你写page.click('#submit-btn')，前端把class名一改，用例就挂。修一次两小时，修完第二周又挂。 AITS的做法是：用自然语言驱动。 你输入“用户登录后添加购物车商品”，系统通过大模型解析意图，分解成一系列原子操作——输入用户名、输入密码、点击登录按钮、点击加购按钮。 但这还不够稳定。大模型实时生成的选择器可能不准确。 所以AITS在知识库里预置了精确的元素定位信息。当大模型解析存在歧义时，系统自动调用预定义的定位策略。这叫“智能解析+精准定位”双重保障。 意图理解层和执行层被隔离开了。 大模型负责“想做什么”，知识库负责“具体怎么点”。这比纯靠大模型实时生成选择器稳定得多。

而且AITS有POM元素库。每个Web项目独立管理元素定位，项目之间互不干扰。一个前端应用一个元素库，结构清晰。

五、知识库：把团队经验变成可复用的资产

这是AITS最被低估的功能。 每个工作区都有一个知识库入口。你可以把被测项目的业务文档、数据库设计文档、规格需求说明书、原型图，全部上传到系统里。这些物料会被向量化到向量数据库，AI完成任务的时候会自动调用作为上下文。 这意味着什么？ 以前新来的测试同学，写用例全凭感觉，风格五花八门。老员工的经验在脑子里，说不出来，教不会。 现在你把老员工的用例设计思路、业务规则、元素定位经验，全部写进知识库。新人入职，直接把PRD丢给AI，出来的用例结构、颗粒度，跟老员工写的几乎一模一样。 个人经验变成了团队资产。

六、AI智能技能：把你的操作手册变成Agent的“肌肉记忆”

AITS有一个“AI智能技能”模块。你可以把它理解成一套“操作说明书”——告诉AI在这个项目里，登录用哪个测试账号、下单走哪个环境、断言检查哪些字段。

你把团队那些“只可意会不可言传”的经验，写成了Markdown文档。Agent拿着这份文档，就能自己看文档、跑命令、操作浏览器。 比如你写一个“回归测试”Skill，里面写清楚：打开staging环境，登录test_user_01账号，按V2.3回归清单跑核心交易链路，遇到异常自动截图，最后生成报告。 Agent收到指令，自动调起浏览器，从登录到支付全程自动跑，遇到异常自动截图留证。你只需要在旁边盯着监控屏喝茶。 这不是“取代”，这是“指挥”。

我说一个上个月的场景。 产品丢过来一个PRD，改了支付回调的处理逻辑。按以前的流程，我先读PRD，手动设计用例，写测试脚本，跑，整理报告。半天起步。 现在，我把PRD丢进AITS的“需求完备性评测”模块。系统自动解析需求，从知识库里召回相关的业务规则和接口规范，生成覆盖正常流、异常流、边界流的测试用例。我花十分钟审核调整。 点“执行”，用例在隔离环境中跑完。三条失败。 进入“缺陷管理”，报告显示：两条是元素定位失效（知识库自动匹配了备选选择器，重试后通过），一条是断言不匹配——订单状态更新延迟超过了阈值，建议人工复核。 我把这份报告甩给开发。开发看了五分钟，确认是一个MQ消息重试机制的Bug，当场修了。

省下来的时间，我在设计下一轮的覆盖策略，在跟产品对需求边界，在思考哪些场景的自动化投入产出比最高。

九、写在最后

那天新来的同学问我：哥，你搭这个助手，花了多久？ 我说，搭起来花了两周，但想清楚“该怎么搭”花了半年。 那半年里我最大的收获不是技术，是想明白了一件事：测试工程师的核心价值，不是“会写多少脚本”，而是“知道该测什么、不该测什么”。 脚本可以AI生成，执行可以自动驱动，报告可以模板化。但“哪些场景必须覆盖”“哪些断言真正有价值”“失败之后该修脚本还是提Bug”——这些判断，只能人来做。 AITS的作用，是把你从“写脚本”“调接口”“整理报告”这些事情里捞出来。你把时间省下来，去做覆盖策略设计、风险判断、质量决策——这些才是测试工程师真正值钱的地方。 工具越强，判断越贵。 以前你是“脚本工人”，现在你是“测试流程的设计者”。你定规则，AI执行。