代码还没写，测试用例已经定了：MumuSpec 13 测试策略 + 14 追溯矩阵到底管什么

在 MumuSpec 体系里，13 回答"怎样算通过"，14 回答"有没有遗漏"。开发启动前，这两份文档已经决定了发布的门槛——不是"测够了吗"，而是"怎么才算够"。

一、一个真实的困局

项目上线前夜，测试群里出现这样的对话：

测试："P0 用例全绿了，发吧？" Leader："等一下——昨天的变更改了一个接口字段，影响范围看过了吗？" 测试："我手动回归了主流程……" Leader："那怎么确认没有遗漏？有没有一张表能告诉我所有需求都有对应测试？"

答不上来。因为没有。

这就是大多数项目的真实状态：测试用例写了一堆，但没人能回答"够不够"。因为测试用例是边开发边补的，需求变了几轮，测试用例有没有跟着变？不知道。某条 P0 需求是不是一条测试都没覆盖？不知道。

在 MumuSpec 体系里，有两个文档专门解决这个问题：

• 13 测试策略与质量门禁——定义"怎样算通过"
• 14 需求追踪矩阵——拉一张表回答"有没有遗漏"

它们配合使用：13 写测试用例，14 用一张矩阵验证全覆盖。13 是"做事"，14 是"对账"。

二、13 测试策略：不是归档用例，是定义"通过的标准"

很多人对 13 的第一反应是"写测试用例的文档"。不对。

13 的核心问题不是"测什么"，而是"怎样算通过"。

2.1 测试分层：每层验什么

每一层回答不同的问题。L1 说"函数没崩"，L2 说"接口返回了"，L3 说"返回的字段名和类型和 09 一致"，L4 说"用户在页面上真的能走完全流程"。

缺任何一层，你都不知道问题出在哪。只跑 L2 可能发现"接口 200 了"，但字段类型不对——L3 才能捕获。

2.2 用例拆分原则：数"可独立失败的点"

写 TC 的时候不要"一条用例测所有"，而是每个可能失败的原因拆成一条：

这样做的价值：失败时不看代码就知道哪里坏了。

拿 TC-M01-002 为例：

这条失败了，不需要 debug，直接知道"POST /ask 的空 query 校验出了问题"。

2.3 质量门禁：哪些必须卡住合并

13 不只是写测试用例，它还要定义什么条件才算"门禁通过"：

G-AC 是关键：它要求 05 用户故事里所有 P0 的 AC 都有对应测试用例。如果某条 P0 的 AC 在 13 里找不到 TC → 门禁直接打回。

2.4 TDD 适用场景：不是所有代码都要 TDD

很多团队对 TDD 有执念。13 给出了务实的判断标准：

核心理念：逻辑越复杂，越应该先写测试再写代码。

三、14 需求追踪矩阵：发布前最后一关

如果说 13 是"写用例"，那 14 就是"对账"。

14 只有一张表，但解决的问题是项目里最头疼的：

"我怎么知道没有遗漏？"

3.1 正向追溯：从需求出发，查测试覆盖

阅读方向：需求 → 用户故事 → API 端点 → 测试用例

一眼就能看出谁没测。不需要翻代码，不需要问测试"这个测了没"——矩阵上写得清清楚楚。

3.2 反向追溯：从测试用例查回需求

阅读方向：每条测试用例 → 它保证哪条需求

反过来查也一样清楚：这条测试用例为什么要写？因为它保证了某条需求。

3.3 API 端点 → TC 映射：没有端点是"没主的"

每个 API 端点至少有一条测试。这是 14 的一条底线规则。如果发现某个端点在 14 里"待补"，说明上线前必须补上。

3.4 覆盖率分析：不猜数字，拉表看

发布前用 14 查"有没有需求没测试、有没有 API 没 owner"。这是最后一道防线。

四、13 和 14 怎么配合

两个文档的分工很清楚：

写作顺序：

05 UserStory（含 AC）   ↓09 API 字段定义   ↓13 写 TC，每条 TC 注明关联的 REQ 和 AC   ↓14 拉全量矩阵，逐行核对覆盖状态   ↓发现"待补" → 回到 13 补 TC → 回到 14 更新状态

13 是"做事"，14 是"对账"。没有 13，14 是一张空表；没有 14，13 是一堆用例但没人知道够不够。

五、AI 怎么消费 13 和 14

很多人认为"AI Coding 不需要写测试用例了，让 AI 自己测"。这是误解。

AI 生成代码后，测试是唯一告诉你"代码对不对"的客观依据。但前提是测试用例必须先于代码定义好。

AI 读 13 做什么

• 知道每个端点的正常和异常路径
• 知道每个字段的类型约束
• 知道门禁条件——生成代码时主动规避"会被门禁卡住"的写法

AI 读 14 做什么

• 从 14 的端点→TC 映射知道哪些端点还没测试覆盖
• 从 14 的覆盖率分析知道当前风险集中在哪里
• 变更代码时，从 14 找到受影响的 TC，知道需要回归哪些用例

六、13+14 落地三步走

第一步：AC 写清楚之前，不写 TC

13 的测试用例来自 05 的 AC。如果 AC 写得模糊（"用户能正常使用"），13 就没办法写精确的断言。AC 是什么断言，TC 就是什么断言。

第二步：TC 写完之前，不写 14

14 的矩阵依赖 13 的 TC-ID。先有 TC，再有矩阵。不能先画矩阵再补 TC——矩阵必须反映真实覆盖。

第三步：14 所有行"待补"清空之前，不发布

这是 14 作为"发布前对账表"的硬性要求。P0 行有 ❌ → 不能上线。

13 和 14 是 MumuSpec 体系里最"无聊"的两个文档——没有炫酷的架构图，没有令人兴奋的新功能描述。它们只是表：一张定义通过标准的表，一张核对有没有遗漏的表。

但项目上线前夜，你最需要的就是这两张表。

13 + 14 合在一起回答了一个问题：

"你说的都做完了，怎么证明？"