SDD（规范驱动开发）

SDD（Specification-Driven Development，规范驱动开发） 在测试域的核心价值在于：将“规范”转化为可执行、可验证的“活文档”，让测试不再是开发完成后的“补课”，而是与规范同步生成的“第一道质量闸门”。

下面我结合真实项目（优惠券系统）以及你之前提到的 OpenSpec 和 Spec Kit 两种风格，给出 SDD 在测试侧的具体落地 6 步法。

第 0 步：选型决策（测试视角的权衡）

在开始前，测试团队需根据项目特征选择 SDD 工具风格：

测试专家的铁律：无论选哪种，规范都必须包含 “可验证的验收标准”（Given-When-Then 或 OCL 约束），否则 SDD 只是空谈。

第 1 步：将业务规范转化为“可执行验收标准”

这是测试介入的第一个动作，在开发写任何代码之前。

动作 1.1：评审规范的可测试性

• 每个用户故事必须带有 验收标准，且满足 SMART（Specific, Measurable, Achievable, Relevant, Testable）。
• 反例：“系统应快速响应” ❌
  正例：“领券接口在100并发下，P99响应时间 ≤200ms” ✅

动作 1.2：用规范生成自动化测试骨架（AI辅助）

以 OpenSpec 的 proposal.md 为例，其中包含 delta spec。测试专家可以要求 AI：

根据以下规范（Given-When-Then），生成对应的 Gherkin 特征文件，并标注每个场景的测试级别（单元/集成/E2E）和优先级。

示例输入（来自需求文档）：

Scenario: 用户领取满减券成功
  Given 用户已登录
  And 券库存=10
  And 用户未领过该券（限领1张）
  When 用户点击领券
  Then 券数量+1，库存=9
  And 返回“领取成功”

AI 输出（features/coupon_claim.feature）：

@P0 @integration
Scenario: 用户领取满减券成功
  Given 用户“test_user”已登录
  And 券“FULL100_10”库存为10
  And 用户领取记录中无该券
  When 用户发起领取请求
  Then 响应状态码为200
  And 响应body中coupon_count=1
  And 数据库coupon_stock=9

测试专家要做的事：

• 补充边界场景（如库存=0，用户已领过）
• 标注幂等性校验（防止并发超领）
• 将 feature 文件提交到代码仓库，与规范同步版本。

第 2 步：建立“规范↔测试”的双向可追溯矩阵

SDD 的核心要求：每条规范条目都能对应到至少一个自动化测试用例，反之亦然。

实施方法

使用测试管理工具（如 Xray, TestRail）或直接在代码中通过注释关联：

@Test
@Requirement("US-01: 用户领券限领1张")
@SpecRef("specs/coupon_management.md#R-02")
public void testUserCanClaimOnlyOnce() { ... }

如果是 OpenSpec 风格：
每个 proposal 必须包含一个 test-impact.md，列出受影响的现有测试用例以及需要新增的测试用例。
测试专家在归档前检查：该 proposal 对应的测试覆盖是否达到阈值（例如行覆盖 ≥85%，场景覆盖 100%）。

第 3 步：将规范作为“测试造数”的源头

规范中定义的数据约束（如优惠券类型、金额范围、有效期）可以直接驱动测试数据工厂。

实战操作

从规范中的字段定义表（见之前 PRD 标准格式）自动生成测试数据构造器：

规范定义：coupon.amount 为 int，范围 [1, 10000]，单位分。
测试数据工厂自动生成：

• 边界值：1, 10000, 0(非法), 10001(非法)
• 等价类：100, 5000

工具链推荐：

• 使用 JSON Schema + Faker 库，从规范生成随机但合法的测试数据。
• 对 OpenSpec：每个变更的 specs/*.md 中若有数据字段变更，CI 会自动更新测试数据 schema 并运行冒烟测试。

第 4 步：实施“规范即测试断言”（合同测试）

在 SDD 中，规范不仅是文档，更是运行时合同。测试专家应推动团队实现以下机制：

4.1 API 规范自动校验

• 使用 OpenAPI/Swagger 规范，在每个 API 测试中自动断言：响应体是否符合 schema、枚举值是否在定义范围内、错误码是否与规范一致。
• 工具：Dredd, Schemathesis, Pact（消费者驱动合同）。

4.2 业务规则引擎测试

如果规范中有复杂的规则表（如优惠券叠加规则），可以将规则翻译成 决策表 或 规则引擎断言：

规范：优惠券与满减活动不可叠加，取优惠较大者。
测试：组合所有可能的券和活动，枚举预期结果，与规范对比。

AI 辅助：
测试专家可以要求 AI 生成规则组合的笛卡尔积，并自动标记矛盾（例如规范中说“可叠加”又说“不可叠加”）。

第 5 步：将规范变更驱动回归测试（重点针对 OpenSpec）

OpenSpec 的 proposal 机制天然适合精准回归。测试专家的落地步骤：

1. 解析变更影响范围：
   从 proposal.md 中提取修改的规范文件路径（如 specs/coupon/claim.spec.md）。
   通过代码仓库的历史映射，找到所有关联的测试文件（例如 test_coupon_claim.py）。

2. 自动执行受影响测试：
   在 CI 中，OpenSpec 变更触发的 pipeline 只运行：

   • 新 proposal 对应的新增测试
   • 被修改规范所关联的测试（通过追溯矩阵）
   • 核心冒烟测试（全局 P0 用例）

3. 归档时强制测试通过：
   openspec archive 命令在合并前必须检查：关联测试的通过率 = 100%，且新增代码覆盖率不低于基线。

第 6 步：建立规范质量度量体系（测试专家 KPI）

为了持续改进 SDD 的效果，测试团队应定期度量：

工具落地：
使用 Markdown lint 检查规范是否包含“验收标准”章节；
在 PR 中自动运行 spec-to-test-coverage 脚本，不达标则阻止合并。

真实项目案例：优惠券系统 SDD 测试落地（浓缩版）

总结：测试专家给团队的 3 条铁律

1. 没有可执行验收标准的规范，等于没写 —— 测试团队有权打回 PRD。
2. 规范与测试代码必须同版本、同仓库、同生命周期 —— 禁止离线 Word 文档。
3. 每次规范变更，必须附带“测试影响分析” —— 尤其是 OpenSpec 风格的增量提案，否则归档不通过。

SDD 对于测试的最大红利，就是让测试左移到需求成型的那一刻。做到上述 6 步，你的团队就能真正实现“规范即测试，测试即文档”。