acceptance-testing

验收测试

概述

由验收标准驱动的反压机制会将规范中的验收标准直接关联到测试要求，形成验证链，避免过早宣称任务已完成。系统无法作弊——除非根据规范验收标准编写的测试实际通过，否则不能声称某项功能已完成。

开始时声明：“我正在使用验收测试技能，根据规范标准进行验证。”

---

反压链

+------------+     derives      +------------+     validates    +------------+
|   SPECS    |---------------->|   TESTS    |---------------->|   CODE     |
|            |                  |            |                  |            |
| Acceptance |                  | Test cases |                  | Must pass  |
| Criteria   |                  | from AC    |                  | all tests  |
+------------+                  +------------+                  +------------+
      ^                                                              |
      |                    backpressure                               |
      +--------------------------------------------------------------+
      If tests fail, implementation must change (not the spec or test)

---

阶段 1：提取验收标准

目标： 从每个规范文件中提取所有 Given/When/Then 验收标准。

操作

1. 找出所有规范文件（specs/*.md）
2. 提取每项带有 ID 的验收标准
3. 以结构化格式记录

提取示例

## From spec: 01-color-extraction.md

### AC-1: Extract dominant colors
- Given an uploaded image (PNG, JPG, or WebP)
- When color extraction is triggered
- Then 5-10 dominant colors are returned
- And each color includes hex, RGB, and HSL representations

### AC-2: Handle invalid images
- Given a corrupted or unsupported file
- When color extraction is attempted
- Then an appropriate error is returned
- And no partial results are produced

停止 — 硬性关卡：未满足以下条件前，不得进入阶段 2：

• 已找到并阅读所有规范文件
• 已提取每项带有 ID 的验收标准
• 标准采用 Given/When/Then 格式
• 标准不存在歧义（如有歧义，请向规范作者澄清）

---

阶段 2：推导测试用例

目标： 将每项验收标准映射到至少一个测试用例。

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: Every acceptance criterion must have at least one   │
│  corresponding test. No exceptions. If a criterion has no       │
│  test, the feature is NOT complete.                             │
└─────────────────────────────────────────────────────────────────┘

可追溯性表

验收标准	测试类型	测试描述	测试文件：行
AC-1：提取主要颜色	集成	上传有效图片，验证返回 5-10 种颜色，并包含十六进制/RGB/HSL 值	test/color.test.js:15
AC-2：处理无效图片	集成	上传损坏的文件，验证报错且没有部分数据	test/color.test.js:42

决策表：验收标准的测试类型

标准类型	测试类型	理由
数据输入/输出行为	集成	测试真实的数据流
错误处理行为	集成	端到端测试错误路径
性能要求	负载测试	需要在负载下进行测量
UI 行为	E2E（Playwright）	测试真实的浏览器交互
主观质量	LLM-as-judge	无法通过确定性测试验证
安全要求	集成 + 安全测试	测试授权和输入验证

停止 — 硬性关卡：未满足以下条件前，不得进入阶段 3：

• 每项验收标准至少映射到一个测试
• 测试类型适合对应的标准类型
• 已确定测试文件的位置

---

阶段 3：先编写测试，再实现功能

目标： 编写验收测试，确保在功能正确实现之前测试会失败。

操作

此阶段与 test-driven-development 配合：

1. 根据验收标准编写测试（RED）
2. 实现功能，使测试通过（GREEN）
3. 在保持测试通过的前提下重构（REFACTOR）

聚焦行为结果

验证此项（行为）	而非此项（实现）
“返回 5-10 种颜色”	“使用 k=8 运行 K-means”
“响应时间 < 200ms”	“第二次调用时命中缓存”
“错误消息对用户友好”	“抛出 CustomError 类”
“数据在多个会话间持久保存”	“执行 PostgreSQL INSERT”
“UI 在 500ms 内更新”	“收到 WebSocket 消息”

停止 — 硬性关卡：未满足以下条件前，不得进入阶段 4：

• 已编写所有验收测试
• 实现前测试会失败（已确认 RED）
• 测试验证的是行为结果，而非实现细节

---

阶段 4：验证关卡

目标： 在宣称任何任务完成之前，必须通过所有关卡。

关卡	检查项	工具	是否必需
单元测试	全部通过	测试运行器	始终
集成测试	全部通过	测试运行器	始终
验收测试	所有基于 AC 派生的测试均通过	测试运行器	始终
构建	编译无错误	构建工具	始终
Lint	无违规项	Linter	始终
类型检查	无类型错误	类型检查器	适用时

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: ACCEPTANCE                                         │
│                                                                 │
│  Cannot claim completion without ALL acceptance tests passing.  │
│  If any acceptance test fails, the feature is NOT done.        │
│  Fix the implementation, not the spec or the test.             │
└─────────────────────────────────────────────────────────────────┘

STOP — 硬性门槛：在进入阶段 5 前，切勿继续：

• 所有验证门槛均已通过
• 验收测试通过，状态为绿色
• 未跳过任何门槛，也未将其标记为“以后再修复”

---

阶段 5：可追溯性报告

目标： 生成一份报告，将每项规范标准与对应的测试及结果关联起来。

报告模板

## Acceptance Test Report

| Spec | Criterion | Test | Status |
|------|-----------|------|--------|
| 01-color-extraction.md | AC-1: Extract dominant colors | test/color.test.js:15 | PASS |
| 01-color-extraction.md | AC-2: Handle invalid images | test/color.test.js:42 | PASS |
| 02-palette-rendering.md | AC-1: Render palette grid | test/palette.test.js:8 | PASS |

### Summary
- Total criteria: N
- Tested: N
- Passing: N
- Failing: 0
- Coverage: 100%

---

反模式 / 常见错误

反模式	错误原因	正确做法
修改规范以匹配实现	违背规范的目的	修复实现，而不是规范
跳过边缘情况标准	边缘情况会导致生产环境中的错误	为所有验收标准编写测试
测试实现细节	脆弱的测试会在重构时失效	测试可观察到的行为结果
未编写验收测试就声称“测试通过”	仅有单元测试并不足够	验收测试是单独且必需的类别
在实现后编写验收测试	测试是为了通过而设计，而非用于明确规范	在实现前编写（TDD）
将验收测试推迟到“以后”	“以后”永远不会到来	在阶段 2 编写，先于编码
将失败的测试标记为“已知问题”	掩盖了实现不完整	修复代码，直到测试通过

---

防止找借口

借口	事实
“单元测试已经覆盖了这个问题”	单元测试孤立地测试组件；验收测试则验证集成后的行为
“规范很明确，不需要正式测试”	即使规范很明确，仍然需要可验证的测试
“我们可以手动验证”	手动验证不可重复，也不可靠
“验收标准太模糊，无法测试”	澄清标准；模糊的规范会产生模糊的代码
“这只是外观上的改动”	外观上的改动也可能破坏布局、无障碍功能和用户体验

---

集成点

技能	关联
spec-writing	验收标准来自规范
test-driven-development	TDD 循环使用基于验收标准的测试
llm-as-judge	用于无法通过确定性测试的主观标准
verification-before-completion	最终验证包含验收测试检查
autonomous-loop	退出门槛要求验收测试通过
code-review	评审会检查验收测试覆盖率
planning	计划将编写验收测试列为明确任务

---

技能类型

严格 — 不得绕过反压链。每项验收标准都必须有对应的测试。验收测试未通过，不得宣告完成。修复实现，而不是规范或测试。