【skills】我花半年做了套 AI 测试框架：21 个目录、133 个文档、不写一行测试代码也能跑自动化

weixin_37899718

164人浏览 · 2026-07-08 08:29:59

weixin_37899718 · 2026-07-08 08:29:59 发布

大家好，我是测试员周周。

现在都要求AI提效，大家肯定也用过通用AI工具写测试脚本，结果它每次给的代码都不一样，同一个接口今天用 requests、明天用 httpx，断言风格也不统一。更崩溃的是，老员工一走，他积累的那些测试经验——哪个接口容易超时、哪个参数容易越界、哪个场景容易漏测——就跟着人一起走了。

你有没有在想一个问题：有没有一种方式，能把测试经验沉淀下来，让 AI 按固定流程干活，而不是让它自由发挥？

这是我的一整套skills，21 个目录、133 个文档、15 个可执行脚本，我叫它"AI 测试技能包"。这篇文章，我想跟你聊聊它的设计思路——不教你怎么装怎么用，而是讲清楚它的底层逻辑。

先说说市面上的 AI 测试，为什么总觉得不对劲

我调研过市面上几乎所有 AI+测试的方案，发现一个共同的症结。

第一种：让 AI 直接写脚本。

你跟 ChatGPT 说"写个登录接口的测试"，它唰唰给你一段代码。看着挺像回事，但你仔细一看：断言只写了 status_code==200，没校验响应体里的 token 格式；参数写死了 admin/admin123，没做参数化；异常场景一个没有。而且每次对话给的代码都不一样，你没法把它纳入版本管理。

第二种：低代码平台。

拖拖拽拽就能生成测试用例，但平台锁死了技术栈。你想加个自定义断言、想对接内部 CI 系统，发现这功能在 Pro 版里，要加钱。

第三种：纯文档规范。

团队写一堆测试规范文档，告诉大家"要按照这个标准来写用例"。但写归写，执行归执行，AI 不会主动去读你的规范文档。

这些方案的问题本质上是同一个：AI 做执行，人做决策。但 AI 做执行不可控——它每次的输出有随机性。人做决策又太累——你还是要手写脚本、手动维护。

我换了个思路：人做决策，AI 做建议，机器做执行。 把"写脚本"这件事从人手里拿掉，也从 AI 手里拿掉，交给一个确定性的生成引擎。

整个系统的核心：一个 spec 决定一切

我先说最核心的设计，理解了它，后面的所有模块就顺了。

我这套系统里，所有测试的输入都是一个 Markdown 文件加上 YAML 格式的头部信息，我叫它 spec。

一个接口冒烟测试的 spec 长这样：

---
kind: api_pytest
base_url: http://your-server:5001
auth:
  type: bearer_login
  login_path: /api/auth/login
---

## 验证登录成功后获取用户信息

- `GET /api/users/me`
- 预期：200，返回数据包含 username 字段

你看，没有任何 Python 代码。只有三段信息：kind 告诉系统"这是接口测试"，auth 告诉系统"登录鉴权的方式"，正文是自然语言描述的测试点。

然后你在终端敲一行命令：

./generate.sh api_smoke.md

系统就会自动在 output/ 目录下生成一个完整的 pytest 脚本，包含 token 获取、参数注入、断言校验。你可以直接跑，也可以把它纳入 CI。

这个 design 的核心思想是：用配置代替编码。

测试工程师不需要会 Python，只需要会写 Markdown。生成出来的 pytest 是标准化的——断言风格统一、错误处理一致、日志格式固定。而且 spec 本身可以放进 Git，每次修改都有记录。

你可能觉得"这不就是把写脚本的工作转嫁给了生成器吗？" 对，但这恰恰是价值所在。生成器是确定性的——同样的 spec 进去，出来的代码 100% 一样。AI 做不到这一点。

七层架构：从一句话到一份测试报告

有了 spec 这个核心输入，剩下的问题就是：怎么把 spec 变成可执行的测试？怎么让这个过程可管理、可扩展、可自愈？

我把整个系统分成了七层。每层只做一件事，层与层之间通过标准接口通信。

第一层：接入层。

用户怎么跟系统交互？两种方式。一种是终端命令行，跑 ./generate.sh 或者 pytest。另一种是 AI 编辑器，比如 Cursor、Windsurf，你打开技能包目录，AI 会自动读取各个模块的 SKILL.md 文件，知道怎么帮你干活。

第二层：编排层。

用户进来可能说一句话："帮我测一下登录模块。"这句话很模糊——是测接口还是测页面？是生成用例还是直接执行？编排层的意图路由模块负责做这件事：它维护了一个映射表，把用户常见的说法映射到具体的技能路径。你说"测登录"，它知道该走 api-skills 的 "执行" 路径。

第三层：知识层。

这是经验沉淀的地方。RAG 引擎把团队的历史缺陷、测试用例、踩坑记录向量化存储。当系统要生成一个新的测试方案时，会先到知识库里检索相关的历史经验，把之前踩过的坑作为上下文注入到生成过程中。

第四层：技能矩阵层。

这是 21 个技能目录组成的核心能力层。API 测试、UI 测试、移动端测试、用例设计、数据工厂、性能压测、缺陷分析……每个技能目录下面都有完整的 SKILL.md 文档，告诉 AI "这个场景下你应该按什么流程干活"。

第五层：引擎层。

spec 生成代码的逻辑全在这里。codegen 目录下的 run_spec.py 是核心引擎，它读 spec 的 YAML 头，根据 kind 字段选择对应的生成器——api_pytest 走 requests 路线、ui_playwright 走 Playwright 路线、perf_k6 走 k6 脚本路线。生成器还内置了变量池和依赖图推断功能，接口之间的参数传递不需要人操心。

第六层：治理层。

测试跑完了，结果怎么把关？CI 门禁模块提供了四维度的质量关卡：P95 响应时间、安全漏洞、代码覆盖率、测试通过率。不同环境阈值不同——开发环境宽松点、生产环境严格点。不达标直接阻断发布，不是发告警邮件了事。

第七层：产出层 · output/

前面六层跑完，最终要交付什么？全部沉淀在 output/ 目录——可交付的测试资产与报告。pytest 脚本在 output/*.py，可直接执行或接入 CI；用例文档以 *.md 或 xmind 形式留存，方便评审与归档；测试报告输出 HTML，失败 case 自动生成缺陷草稿。这一层是整条流水线的出口，把中间过程变成团队真正能用、能管、能追溯的交付物。

为什么 AI 只做决策，不写代码

说到这里你可能注意到了：在这套系统里，AI 从不直接生成可执行代码。

AI 做的事情是：

分析 PRD 文档，理解业务逻辑
根据历史经验，判断哪些场景要测
按 8 维用例矩阵（正常、边界、类型、异常、权限、依赖、幂等、安全）规划测试点
生成 spec 的 YAML 头部和 markdown 正文

生成代码这件事，交给 codegen 引擎。 因为 codegen 是确定性的，它不出幺蛾子。

这个决策背后的逻辑是：AI 擅长的是"模糊的正确"，不是"精确的执行"。 让 AI 写代码，它可能 80% 的时候写对，但 20% 的时候写错，而这 20% 的错误可能恰好是你上线前最需要的那几个测试用例。但让 AI 写 spec，错了大不了 regenerate 一次——因为 spec 是自然语言，你看一眼就知道有没有问题。

我见过太多团队在 AI 写脚本这条路上走到黑，最后发现维护 AI 生成的脚本比手写还累。AI 的价值不是替代你工作，而是帮你做决策——决策错了容易发现，代码错了很难排查。

自愈循环：不让环境波动变成测试失败

测试自动化最让人崩溃的是什么？不是脚本写不出来，是脚本今天能跑明天就挂了。

接口加了个 token 校验？你的登录用例全挂了。页面的按钮改了个 class 名？你的 Playwright 脚本找不到元素了。服务器压力大了返回 429？你的压测脚本报错了。

传统做法是等人发现、等人修。我这套系统的做法是：让测试自己修自己。

接口层有 5 类自愈策略。遇到 401 就自动重新登录、刷新 token；遇到 500 或 429 就指数退避重试；遇到超时就调整超时时间再试；遇到连接失败也一样退避重试。所有策略都有重试次数上限，不会死循环。

UI 层更复杂。Playwright 的定位器经常因为前端改版而失效。我设计了七层降级链：优先用 data-testid，找不到就试 role+name，再找不到就试 label、placeholder、id、text，最后用 CSS 选择器兜底。七层都找不到怎么办？还有 L2 的 DOM 推断——根据元素的上下文关系、邻近元素的特征做模糊匹配。

这套自愈机制不是说它能解决所有问题，而是它能把环境波动和真实回归失败区分开。如果自愈重试通过了，那就是环境问题，不需要报 bug；如果自愈用尽所有策略还是失败，那才是真正的回归失败，系统自动生成缺陷草稿。