每天早上到公司，我做的第一件事是打开浏览器。不是刷新闻，是开标签页。

API测试平台一个，看接口通过率。Web自动化平台一个，看UI用例执行情况。性能监控一个，看昨晚压测结果。Jira一个，看新提的Bug。Jenkins一个，看CI跑没跑完。最后再打开Excel，把数据粘进去，拼成周报。

六个标签页，六个系统，六个密码。每天重复，每天切换。

直到我把这六个标签页收进了一个界面。现在早上到公司，只开一个页面。通过率、执行数、AI用例占比、高频报错用例、质量趋势，全在一张驾驶舱里。

这个东西叫 AITS。API + Web + App + 性能四大测试域，加 AI 引擎，加统一驾驶舱。

但今天不只讲 AITS。还要讲另一个东西，测试用例生成 Skill。它做的事更聚焦，把 PRD 变成结构化用例，2 分钟出活。

一个管全局，一个管单点。两个配齐，测试效率提升不止一个量级。

源码和手册放在文末，照抄就能用。

一、先说清楚，为什么你的 AI 测试工具用不起来

很多团队试过 AI 测试。结果呢？

第一种，只做了个对话框。生成用例问它，分析 Bug 问它，查日志问它，写报告还问它。所有人把所有问题都往一个输入框里丢，AI 输出越来越乱，格式每次不一样，根本没法复用。

第二种，工具堆了一堆。API 测试一个平台，UI 一个平台，性能一个平台，App 再一个。每个平台单独用还行，合在一起就是六个标签页来回切。数据不互通，格式不统一，管理者想看质量全貌，得手动拼。

第三种，有工具但没有方法论。AI 能写用例，但写出来的用例分不清哪些有需求依据、哪些是 AI 脑补的。你能生成一百条，但不知道覆盖了哪些、漏了哪些。

问题出在哪？不是 AI 不行，是没有把 AI 能力装进一个完整的测试工作流里。

AITS 做的事情，就是把四大测试域、AI 引擎、统一驾驶舱全部打通。而测试用例生成 Skill，是把单点能力做到极致。

先讲 AITS，再讲 Skill。

二、AITS 全景，四大测试域 + AI 引擎 + 统一驾驶舱

AITS 分五层。

不同角色有不同阅读路径。

刚入职的测试工程师，先建账号、熟悉全局，再深入日常使用最多的测试域。

测试负责人 / TL，先掌握质量大盘，再按优先级逐个落地。

项目经理 / 质量经理，聚焦结果与趋势，看驾驶舱即可。

平台管理员 / 运维，先通基础设施，再确保各测试域环境正常。

不是每个人都需要学所有功能。你是什么角色，就看什么章节。

三、统一驾驶舱，10 秒看清全局风险

测试负责人最怕什么？面对一堆孤立报告，答不上来「今天到底能不能发版」。

AITS 的驾驶舱把散落的数据收在一起。

核心指标卡片，今日通过率、执行数、AI 用例占比。

自动化执行态势图，近 7 日通过 / 失败趋势。

高频报错用例 Top 5，反复失败的钉子户用例，AI 自动抓取。

自定义布局，拖拽编辑，卡片位置持久化。

配合项目切换器和业务快捷入口，10 秒就能决定今天的测试重心。

四、四大测试域，每个都有 AI 能力加持

（一）API 测试，从 Swagger 到完整测试矩阵

传统接口测试依赖手工编写。AITS 通过 Swagger / OpenAPI 导入与自动解析，直接把规范变成用例来源。

核心亮点是智能场景生成器，AI 自动编排多接口业务流。登录接口返回的 token，自动传到后续订单接口做鉴权。多个接口串起来，形成端到端业务测试流程。

三级树结构（模块 → 接口 → 用例），场景用例可视化拖拽排序。

（二）Web 测试，自然语言驱动 UI 自动化

UI 自动化最大的痛点是「编写慢、维护难、稳定性差」。AITS 的 AI 脚本实验室基于 Playwright 智能录制与脚本生成，AI 用例生成智能体根据页面上下文批量生成用例。

结合元素管理（Page Object 集中维护与复用），前端 UI 变动时只需维护 POM 层，大大降低脚本废弃率。

（三）App 测试，一套脚本多端跑

碎片化设备、频繁页面变更，是移动端测试的两座大山。AITS 引入 POM 智能解析，自动提取移动端页面对象模型，配合 UI 智能体（AI 驱动的智能交互与断言）。

页面变了，AI 自适应。

（四）性能测试，压得动、看得清、治得好

AITS 构建了「压测场景、发压配置、实时监控、AI 智能诊断」四位一体闭环。

支持并发策略、梯度模型等发压配置，无缝对接 Grafana / Prometheus / SkyWalking 实时监控。

最重磅的是 AI 诊断记录，告警自动触发 AI 分析，直接输出瓶颈定位与排障建议。

五、AI 引擎，支撑整个系统的核心大脑

AITS 底层配置了 AI 实验室。

LLM 模型管理，支持 OpenAI、通义千问、DeepSeek，可本地部署。

RAG 向量数据库，业务文档、历史用例、Bug 库向量化，AI 生成时检索上下文。

MCP 工具链，连接外部工具，把浏览器操作、测试资产管理能力开放给 Agent。

这是 AITS 和其他平台的根本区别，不是「加了个 AI 按钮」，是 AI 渗透到每个测试域里。

六、单点突破，测试用例生成 Skill

AITS 解决的是「全域打通」的问题。但如果你只想要一个轻量的东西，先把「写用例」这件事搞定，那这个 Skill 更直接。

（一）它解决什么问题

产品经理指着你的用例问，「这条『验证码 5 分钟内有效』，需求文档里哪写的？」

你翻了三遍，没找到。那个「5 分钟」是你从上一家公司带过来的经验。填对了是运气，填错了是返工。

这个 Skill 做的事，把「需求里明确写的」和「我猜的」分开。

（二）核心结构

（三）Prompt 使用模板

（四）实际效果

一个登录模块的需求，2 分钟生成 12 条用例。其中 3 条标注 [待确认]，评审时直接问产品。

七、AITS + Skill，全局和单点怎么配合

AITS 管全局，四大测试域的执行、驾驶舱的监控、AI 引擎的调度。

测试用例生成 Skill 管单点，把 PRD 变成结构化用例。

配合方式如下。

用 Skill 生成用例 → 导入 AITS 的 API / Web / App 测试域

AITS 执行测试 → 驾驶舱展示结果

失败用例进入 Bug 分析 Skill → 输出结构化报告

报告回流 AITS 知识库 → 下次生成更准

单点提效，全局打通。这才是完整的测试工作流。

八、源码和手册怎么拿

AITS 的 1.0 版本已经打包好了。

包含完整源码包，四大测试域 + AI 引擎层 + 公共能力层 + 统一驾驶舱。

包含操作手册，按角色的阅读路径，覆盖新人 / TL / PM / 运维。

包含 AI 引擎配置指南，LLM 模型管理、RAG 向量数据库、MCP 工具链。

包含四大测试域实操教程，从注册登录到深度实操。

测试用例生成 Skill 的完整 SKILL.md 和 Prompt 模板也在里面。

获取方式，公众号后台回复「AITS」，我把仓库地址和手册发你。

九、几点实话

好处很明显。重复性工作少了很多。以前写用例要翻历史用例参考格式，现在 AI 自动生成。以前排查问题要切六个标签页，现在一个驾驶舱全搞定。

但也不是万能的。AI 生成的用例偶尔会遗漏边界条件，需要人工补。Bug 根因分析有时会过度推理，给出的原因看着合理但实际不对。所以我的习惯是，AI 生成初稿，我审核修改，最终产物还是人在把控。

最值钱的是知识库。用久了之后，知识库里沉淀了上百条历史 Bug 记录和几千条用例。这些资产的价值远超平台本身。新人来了，直接用平台就能上手，输入问题，AI 参考历史经验输出答案，比翻文档快得多。

源码是起点不是终点。1.0 版本是基础框架，真正好用需要根据自己团队的业务和规范去定制，调整 Prompt 模板、补充知识库内容、修改输出格式。

十、写在最后

回到开头那六个标签页。

现在我的浏览器只开一个页面。驾驶舱上显示，今日通过率 94%，执行数 1287，AI 用例占比 62%，高频报错用例 3 条。

点开高频报错用例，AI 已经给出了根因分析。点开质量趋势，近 7 日通过率平稳。点开项目切换器，跳转到下一个项目的驾驶舱。

管理者要的不是「工具很多」，是「质量全貌一张图」。

AITS 解决的是全局问题，测试用例生成 Skill 解决的是单点问题。两个配齐，测试效率提升的不是 10%、20%，是量级的变化。

工具可以固化流程，但判断只能靠人。

以前你是「工具切换者」，现在你是「质量决策者」。你定规则，系统执行。

这个转变，比学会任何一个测试框架都值钱。

如果你也在被「工具太多、数据太散、质量看不清」困扰，今天就先做一件事，把团队最常用的测试规则，整理成一份结构化的 Skill 文档。

不用全上，先跑通一个环节。

跑完一周，欢迎回来聊聊，哪一步真的省了时间、哪一步反而绕了弯路。

谢谢你看我的文章，我们，下次再见。