大家好我是测试员周周。上一篇文章我讲了这套 AI 测试技能包的七层架构开篇提到一个核心观点AI 做决策机器做执行人在回路中。那篇文章发出去之后后台收到最多的私信是周周你说的 spec 到底是什么为什么用 Markdown8 维矩阵又是什么【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 pytestkind: ui_playwright—— 浏览器 UI 测试Playwrightkind: perf_k6—— k6 性能压测脚本kind: perf_jmeter—— JMeter 压测脚本kind: perf_locust—— Locust 压测脚本kind: appium—— 移动端测试每个 kind 背后对应一套独立的生成器模板。你不需要知道 requests 怎么写、Playwright 怎么用只需要在 YAML 头部声明你要做什么类型的测试。这就是声明式的本质你关注测什么机器关注怎么测。8 维用例矩阵比等价类边界值多了什么好spec 有了kind 选好了接下来要回答的问题是到底测什么做测试的人都知道等价类划分和边界值分析。这两个方法对付简单的输入验证还行但面对复杂的业务逻辑、多接口协作的场景它们就远远不够了。我在这套系统里用的是一个叫8 维用例矩阵的方法论。8 个维度分别是NNormal正常场景—— 最核心的业务流程用户最常走的路径BBoundary边界场景—— 参数的上限、下限、临界值TType类型场景—— 参数类型错误、格式错误、编码问题EException异常场景—— 网络超时、服务不可用、数据不存在AAuthority权限场景—— 未登录、越权、权限不足DDependency依赖场景—— 前置条件缺失、数据依赖断裂IIdempotency幂等场景—— 重复提交、重放攻击SSecurity安全场景—— SQL 注入、XSS、敏感信息泄露你可能会说这不就是测试理论课上讲的那些吗 对都是老概念。但区别在于这些维度被固化成了 AI 的思考框架。传统做法是你培训测试同学你要从这些维度去想用例他听的时候觉得懂了写的时候还是只写了正常场景。而在这套系统里AI 在生成用例时会被要求按 8 个维度逐一展开。系统甚至会从 RAG 知识库里检索每个维度对应的历史 case 作为参考。拿登录接口举例AI 生成的用例会覆盖N正确账号密码登录B用户名最大长度、密码最短长度、连续登录失败 5 次后还能不能登录T邮箱格式的用户名、手机号格式的用户名、纯数字密码E用户不存在、密码错误、账号被锁定、服务器返回 500A未登录访问需要认证的接口、使用已注销的 tokenD依赖的认证服务不可用时I同一个 token 重复发送登录请求SSQL 注入尝试、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、失败了怎么回灌知识库。零件网上都能找产线只有跑通过才知道哪里卡。一个小总结写到这里我把整个入料环节的逻辑串起来spec 是核心输入Markdown YAML自然语言 结构化配置kind 决定生成方向API、UI、压测、移动端一个 spec 搞定8 维矩阵保证用例覆盖AI 按框架思考不会遗漏step6 门禁做可执行校验问题暴露在生成阶段人审核 一键生成人在回路中把关机器做重复劳动你可以把 8 维矩阵、声明式 spec 这些思路带回自己团队试——它们本身就有价值。但如果想要「PRD 进来、用例出来、spec 一键变 pytest、和后面自愈/缺陷/知识库自动咬合」这一整条链靠零散拼装很难一次跑通。我这套技能包就是把这条产线固化成了 133 份互相引用的文档和 15 个可执行脚本拿来就能在 AI 编辑器里按流程跑。下一篇我会讲两个模块——RAG 知识库和接口自动化自愈。怎么让团队踩过的坑不再踩第二次怎么写接口自动化脚本才能不被 token 过期和服务器波动搞崩心态我们下一篇见。如果你团队正在做 AI测试、想落地整套流程欢迎评论区交流或私信我。