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

上一篇文章我讲了这套 AI 测试技能包的七层架构，开篇提到一个核心观点：AI 做决策，机器做执行，人在回路中。

那篇文章发出去之后，后台收到最多的私信是："周周，你说的 spec 到底是什么？为什么用 Markdown？8 维矩阵又是什么？"【skills】我花半年做了套 AI 测试框架：21 个目录、133 个文档、不写一行测试代码也能跑自动化-CSDN博客

好吧，这期我就把"入料"这个环节拆开揉碎了讲。这是整套系统最核心的设计——输入决定输出。你的输入设计得不好，后面所有自动化都是空中楼阁。

先从一个真实的痛苦场景说起

去年我带团队做一个电商秒杀系统的测试，PRD 文档 56 页，业务逻辑复杂到让人头皮发麻：限时抢购、库存扣减、订单状态流转、支付超时自动取消、退款回滚……

我让两个三年经验的同学去写测试用例。一周后，我 review 他们的输出时发现了一个问题：两个人写的用例风格完全不同。

A 同学写得很细，每个接口的每个参数都拆成了独立的 case，光登录就写了 18 条。B 同学写得很粗，一个接口一条用例，"验证登录成功"就完了。我问 B 同学为什么这么写，他说："我觉得这些就够了，反正到时候手工点点也能发现 bug。"

问题不在谁对谁错，而在于没有标准。测试用例的质量完全取决于写用例的人，而不是取决于流程。团队越大，这个问题越明显。

更麻烦的是，这些写好的用例——不管好的坏的——都躺在 Word 文档里。下一次版本迭代，PRD 更新了，没有人和用例做比对，没有人知道哪些用例要新增、哪些要废弃。用例的生命周期终结于写出来的那一刻。

所以我一直在想：有没有一种方式，让测试用例的产出是标准化的、是可执行的、是可版本管理的？

为什么选 Markdown + YAML：三个理由

你可能会问：市面上的用例管理工具有很多，为什么不用它们？

原因很简单：工具锁死了你的自由度。

那些平台都有一个数据库模型：用例编号、标题、前置条件、测试步骤、预期结果。看起来挺标准对吧？但是你想加一个字段叫"关联的缺陷 ID"或者"压测关注的指标"试试？要么不支持，要么付费版才有。

Markdown + YAML 组合给了我三个好处：

第一，文本即数据。一份 spec 文件就是一个测试输入。不需要数据库、不需要 SaaS 平台、不需要登录任何系统。你用 Git 就能管理它，用 diff 就能看到每次改了什么。

第二，自然语言 + 结构化。YAML 头部用来描述机器的配置（用什么协议、鉴权方式、环境变量），Markdown 正文用来写人看的测试点。两者互不干扰。

第三，生成器与执行器分离。spec 本身不是代码，不依赖任何运行时。你把 spec 发给别人，拿 generate.sh 一跑就能出 pytest。这就实现了"配置即代码"。

一份完整的接口冒烟 spec 长这样：

--- kind: api_pytest base_url: http://your-server:5001 setup: test_init auth: type: bearer_login login_path: /api/auth/login username_env: TEST_USERNAME password_env: TEST_PASSWORD --- ## 验证登录接口 - 正常登录：POST /api/auth/login，参数 admin/admin123 - 预期：200，返回 token 和 user_id ## 验证登录后获取用户信息 - `GET /api/users/me` - 预期：200，返回数据包含 username、role、avatar 字段

这份 spec 只有 20 行，但它能生成一个包含 token 自动提取、参数化断言、setup 初始化的完整 pytest 文件。

kind：决定方向的钥匙

你可能注意到了 spec 里的kind字段。这个字段是整个生成引擎的"路由键"。

kind: api_pytest意味着 codegen 会走 API 测试的生成流水线，用 requests 库输出 pytest 脚本。

但kind不止这一种。系统目前支持这些类型：

• kind: api_pytest—— 接口测试（requests + pytest）
• kind: ui_playwright—— 浏览器 UI 测试（Playwright）
• kind: perf_k6—— k6 性能压测脚本
• kind: perf_jmeter—— JMeter 压测脚本
• kind: perf_locust—— Locust 压测脚本
• kind: appium—— 移动端测试

每个 kind 背后对应一套独立的生成器模板。你不需要知道 requests 怎么写、Playwright 怎么用，只需要在 YAML 头部声明你要做什么类型的测试。

这就是"声明式"的本质：你关注"测什么"，机器关注"怎么测"。

8 维用例矩阵：比等价类边界值多了什么

好，spec 有了，kind 选好了，接下来要回答的问题是：到底测什么？

做测试的人都知道等价类划分和边界值分析。这两个方法对付简单的输入验证还行，但面对复杂的业务逻辑、多接口协作的场景，它们就远远不够了。

我在这套系统里用的是一个叫8 维用例矩阵的方法论。

8 个维度分别是：

• N（Normal）正常场景—— 最核心的业务流程，用户最常走的路径
• B（Boundary）边界场景—— 参数的上限、下限、临界值
• T（Type）类型场景—— 参数类型错误、格式错误、编码问题
• E（Exception）异常场景—— 网络超时、服务不可用、数据不存在
• A（Authority）权限场景—— 未登录、越权、权限不足
• D（Dependency）依赖场景—— 前置条件缺失、数据依赖断裂
• I（Idempotency）幂等场景—— 重复提交、重放攻击
• S（Security）安全场景—— SQL 注入、XSS、敏感信息泄露

你可能会说："这不就是测试理论课上讲的那些吗？" 对，都是老概念。但区别在于：这些维度被固化成了 AI 的思考框架。

传统做法是，你培训测试同学"你要从这些维度去想用例"，他听的时候觉得懂了，写的时候还是只写了正常场景。

而在这套系统里，AI 在生成用例时会被要求按 8 个维度逐一展开。系统甚至会从 RAG 知识库里检索每个维度对应的历史 case 作为参考。

拿登录接口举例，AI 生成的用例会覆盖：

• N：正确账号密码登录
• B：用户名最大长度、密码最短长度、连续登录失败 5 次后还能不能登录
• T：邮箱格式的用户名、手机号格式的用户名、纯数字密码
• E：用户不存在、密码错误、账号被锁定、服务器返回 500
• A：未登录访问需要认证的接口、使用已注销的 token
• D：依赖的认证服务不可用时
• I：同一个 token 重复发送登录请求
• S：SQL 注入尝试、XSS payload 注入、密码明文传输

一份 8 维矩阵覆盖下来，光是登录这个接口就能生成 30-50 条用例。而且每次生成的风格一致、覆盖维度完整，不会因人而异。

从 PRD 到 spec 再到 pytest：完整链路

现在我们把这些环节串起来，看看从一份 PRD 文档到可执行的 pytest 脚本，中间经历了什么。

第一步：需求建模。

AI 先读 PRD 文档，锁定测试范围。这一步解决的是"测什么、不测什么"的问题。PRD 里写着"支持微信支付"和"支持支付宝支付"，但没写"支持银联支付"，那"银联支付"就不在测试范围内。看起来是废话，但很多项目的测试范围失控，就是因为在"测不测"这个问题上没对齐。

第二步：按 8 维矩阵生成用例。

AI 把需求建模的结果作为输入，按 N/B/T/E/A/D/I/S 八个维度，给每个功能点生成测试用例。输出是一份结构化的测试用例文档，标注了优先级、前置条件、预期结果。

第三步：人工评审。

这是整个流程中人必须参与的一步。你 review AI 生成的用例，调整优先级，补充 AI 遗漏的场景，删除不必要的重复。确认没问题后，用例文档进入下一阶段。

第四步：用例转 spec。

这一步可以是自动的，也可以是手动的。简单场景（比如接口冒烟）可以直接从用例自动生成 spec。复杂场景（比如带业务规则的状态流转）需要人工整理 spec 的依赖关系。

第五步：generate + pytest。

./generate.sh spec_file.md cd output && python3 -m pytest test_file.py -v

五个步骤，人只需要在第三步把关。其他步骤——建模、生成、翻译、执行——都可以自动化。

你以为这就完了？还有 step6 门禁

我上面说了"评审完就可以进入下一阶段"，但实际上，我在这套系统里加了一个额外的关卡：step6 门禁。

为什么要有这个？因为我发现一个现象：AI 生成的用例，评审的时候大家都会点头说"可以"，但真正执行的时候才发现，有些用例根本跑不通——因为前置条件没写清楚，或者数据依赖没解决。

step6 门禁的做法是：在用例进入 spec 阶段之前，先做一次可执行性校验。系统会检查每条用例的前置条件是否明确、数据依赖是否可满足、预期结果是否可断言。校验不通过的用例会被打回，并给出修改建议。

这个设计的思想是：让问题暴露在生成阶段，而不是执行阶段。你在 generate 之前发现用例有问题，改 spec 就行。你在 pytest 跑了一半才发现用例有问题，那今天的发版就凉了。

为什么自己拼很难

读到这儿，你可能会想：概念我都懂了，找个向量库、写个 Prompt、让 AI 按 8 维出用例，好像也能做？

单点确实能做。难的是整条入料链路的咬合。

第一，用例和代码之间隔着一层约定。ChatGPT 直接写 pytest，每次库、断言风格、错误处理都不一样，根本没法做回归。我这边的做法是：AI 只产出 spec，可执行代码由确定性引擎生成——同样的 spec 进去，出来的脚本 100% 一样。这个「中间层」不是多写个 Markdown 那么简单，而是 kind 路由、鉴权注入、变量提取、依赖排序一整套解析规则，每种测试类型各有一套模板。

第二，8 维矩阵不是贴在墙上的海报。你跟 AI 说「按 8 维想想」，它听懂了，写出来还是偏正常场景。真正有用的是：维度被写进 Skill 的生成约束里，生成前先 RAG 预检索历史 case，评审后还有 step6 门禁拦一道。三步合在一起，用例质量才不靠人记、不靠人盯。

第三，spec 不是用例的复制粘贴。简单冒烟可以自动转，复杂业务流要推断接口依赖、token 传递、setup 铺底数据——这些和后面的自愈引擎、数据工厂是同一套变量池语义。你只抄 spec 格式，不抄后面的执行约定，生成出来的脚本跑不通。

我花了大半年时间，不是在发明 8 维矩阵或者 Markdown 语法——这些教科书里都有。时间花在把 21 个模块的输入输出对齐：用例怎么进 spec、spec 怎么进 codegen、失败了怎么回灌知识库。零件网上都能找，产线只有跑通过才知道哪里卡。

一个小总结

写到这里，我把整个"入料"环节的逻辑串起来：

1. spec 是核心输入，Markdown + YAML，自然语言 + 结构化配置
2. kind 决定生成方向，API、UI、压测、移动端，一个 spec 搞定
3. 8 维矩阵保证用例覆盖，AI 按框架思考，不会遗漏
4. step6 门禁做可执行校验，问题暴露在生成阶段
5. 人审核 + 一键生成，人在回路中把关，机器做重复劳动

你可以把 8 维矩阵、声明式 spec 这些思路带回自己团队试——它们本身就有价值。但如果想要「PRD 进来、用例出来、spec 一键变 pytest、和后面自愈/缺陷/知识库自动咬合」这一整条链，靠零散拼装很难一次跑通。我这套技能包就是把这条产线固化成了 133 份互相引用的文档和 15 个可执行脚本，拿来就能在 AI 编辑器里按流程跑。

下一篇，我会讲两个模块——RAG 知识库和接口自动化自愈。怎么让团队踩过的坑不再踩第二次？怎么写接口自动化脚本，才能不被 token 过期和服务器波动搞崩心态？我们下一篇见。

如果你团队正在做 AI+测试、想落地整套流程，欢迎评论区交流或私信我。