测试规范
测试规范回答四个问题：写什么测试、放在哪里、怎么运行、怎样算通过。它的输入是规约里的场景（Scenario）——用例清单应当是场景清单的镜像，规约改了，用例必须跟着改；两者脱节时，测试通过与否就不能说明任何问题。
1这一页管什么
测试的范围、组织与通过判定写在这里；断言怎么写、框架怎么用不属于这里。
- 管测试的来源、组织与通过判定。层次划分、用例来源、三类组织方式、数据隔离、一键运行、通过门槛。
- 不交由这一页。断言如何书写、框架如何使用属所选语言的通行做法；越权类用例的内容在安全开发规范页。
- 两种落法。目录、命名、通过门槛这类常驻约束写进规则；「按规范补测试」是一个按场景执行的流程，写成技能。
对应的课程知识点：测试金字塔与测试层次划分、需求到用例的可追溯矩阵（traceability matrix）、等价类划分与边界值分析、测试替身（test double）、变异测试的思想，以及持续集成中的质量门禁（quality gate）。本页是五类中唯一明确要求「规则 + 技能」配合的：规则保证放对位置，技能保证每次变更都补得上。
2规范条目
十二条，重点是数据隔离、缺陷判定口径与通过判定——这三条决定测试结果是否可以被信任。
| 条目 | 要写清什么，为什么这样规定 | 怎么检查 |
|---|---|---|
| 测试层次 | 单元测试覆盖业务规则，接口测试覆盖每条能力的正常与失败路径，端到端只覆盖主路径。层次错位会让反馈周期随规模线性变长 | 统计各层用例数量；主路径之外出现端到端用例即为层次错位 |
| 用例来源 | 每个场景至少对应一组用例，用例与场景之间可双向追溯。写不出来源的用例通常是顺手写的形状检查 | 场景清单与用例文件逐一比对 |
| 三类组织 | 用例按正常路径 / 失败路径 / 边界归组；失败路径的数量不少于规约列出的条数。边界值来自等价类划分的两端 | 目录结构与命名核对；缺一类即判未完成 |
| 数据隔离 | 测试使用独立的数据实例或模式（schema）；每条用例运行前后自行清理；不依赖执行顺序与残留数据 | 随机化执行顺序，结果应保持一致 |
| 外部依赖 | 外部服务与时钟用可注入的测试替身；不访问真实外部服务，不依赖真实时间 | 断开网络后测试仍应全部通过 |
| 一键运行 | 命令、所需环境变量、退出码、报告位置写进 README；一次命令执行完全部测试。不能被复现的执行过程无法作为验收依据 | 新成员按 README 执行一次 |
| 通过判定 | 失败即以非零退出码阻断；不得保留「已知失败」清单；跳过用例必须写明理由并登记 | 构建结果含失败用例时判定未通过；跳过用例数只减不增 |
| 断言有效性的判据 | 判据只有一句：改坏被测逻辑，这个用例会不会变红。这是变异测试思想的轻量用法——只断言形状（不报错、长度相等）的用例在缺陷面前保持沉默 | 对被测逻辑做一次等价的破坏，检查用例是否失败 |
| 缺陷判定的信号口径 | 先写明本系统用哪套信号——响应中是否有独立于 HTTP 码的业务码；有业务码时成败只看业务码，不套「失败必须 4xx」这类 HTTP 惯例；无业务码时按接口文档写明的 HTTP 码判，文档没写才用兜底表。为什么：把 HTTP 惯例当判据，会把「HTTP 200 且业务码已拒绝」的正确实现误判为不通过 | 取一条 HTTP 200 但业务已拒绝的响应，核对该用例是否被误判为不通过 |
| 缺陷的四个判定词 | 写清「被当成成功」「被放行」「被误拒」「未处理故障」各自的含义；响应中出现堆栈或「系统错误」这类无信息量的文案即算未处理故障。为什么：没有统一的判定词，「用例通过」就无法说明是否存在缺陷，评审也无从比较 | 随机抽五条不通过的用例，两人各自判定是否构成缺陷，结论应一致 |
| 响应时间阈值 | 正向用例的端到端耗时设两档——超过 50 ms 标记，超过 100 ms 判不通过（阈值按项目自定，此处为示例值）；只考核正向用例，负向用例不计入。为什么：单阈值会把「偏慢」与「不可接受」混为一谈，前者应当被看见而不是被阻断 | 每条正向用例记录耗时；落在两档之间的应被标记而不判不通过 |
| 变更要求 | 每次变更至少补写与其场景对应的用例；修复缺陷先补一条能复现该缺陷的用例 | 变更说明与新增用例对照 |
3本课先写到哪
下列四件完成，测试即可作为后续课次的回归基础。
- 最小集合三件。一键运行命令写入 README、一条能力的一组三类用例、数据隔离的基本约定。
- 先给骨架补测试。健康检查端点必须有用例——后续课次的验收都从它开始，它失效要能立刻发现。
- 定通过门槛。明确「失败即阻断」，并约定谁负责修复当天失败的用例。
- 把补测试写成技能。让 Harness 每次实现一组任务后，按技能自动补齐对应用例，避免事后补写。
覆盖率口径要写清：以「能力的失败路径是否被覆盖」为准，不以代码行数百分比为门槛——后者容易在无关处凑数，却漏掉真正会出问题的分支。