ttttstc 功能级黑盒验收测试
在 TDD 实现和质量门禁通过后，为已完成的功能执行黑盒验收测试。此技能独立管理自己的环境生命周期（启动 -> 测试 -> 清理），并生成 ISO/IEC/IEEE 29119 合规的测试用例文档。
启动宣告： "正在使用 vibeflow-feature-st 运行黑盒验收测试。"
黑盒测试哲学
TDD（vibeflow-tdd）已从内部验证了实现。此技能从外部验证 — 如用户或外部系统般：
- 通过真实接口输入（HTTP 端点、UI、CLI 参数）
- 通过真实接口观察输出（HTTP 响应、渲染 UI、stdout）
- 测试设计或执行期间不参考内部实现代码
规则： 如果一个测试用例需要阅读源代码才能确定预期结果，它不是黑盒测试 — 仅使用 SRS 规格重写。
服务生命周期（通过 .vibeflow/guides/services.md）
启动（首个测试用例前）
- 读取
.vibeflow/guides/services.md— 定位"启动所有服务"章节 - 检查服务是否已运行：运行健康检查
- 如未运行：执行启动命令，捕获输出，提取 PID 和端口，记录到
.vibeflow/logs/session-log.md - 启动失败则诊断根因，修正后更新
.vibeflow/guides/services.md
清理（所有测试用例完成后）— 强制
- 停止服务：按 PID 杀进程（优先）或按端口杀（备选）
- 验证已停止：端口不再响应
- 记录清理状态
为什么强制：留下运行的服务会在后续 ST 循环中造成端口冲突。
重启协议（修复-重测循环间）
- Kill -> 2. 验证死亡 -> 3. 启动（含输出捕获）-> 4. 验证存活
检查清单
1. 加载上下文
读取目标功能的所有输入工件：
- 功能对象 — feature-list.json 中的 ID、标题、描述、verification_steps、ui 标志、依赖、优先级
- SRS 章节 — 通过文档查找协议读取完整 FR-xxx
- 设计章节 — 完整 §4.N
- 任务文档 —
docs/changes/<change-id>/tasks.md - UCD 章节（仅
"ui": true） - 接口契约 — API 端点、CLI 命令、UI 入口点
- 测试结果摘要 — 来自 TDD 和质量门禁
2. 推导测试用例
对每个 verification_step，生成一个或多个测试用例。
类别分配规则：
| 类别 | 缩写 | 何时生成 |
|---|---|---|
功能 |
FUNC | 始终 — 每个功能的正常路径 + 错误路径 |
边界 |
BNDRY | 始终 — 极端情况、限制、空/最大/零值 |
UI |
UI | 仅当 "ui": true — Chrome DevTools 交互 + 视觉验证 |
安全 |
SEC | 当功能处理用户输入、认证或外部数据 |
无障碍 |
A11Y | 仅当 "ui": true — WCAG 2.1 AA 检查 |
性能 |
PERF | 仅当追溯到有性能指标的 NFR-xxx |
最低覆盖：
- 每个功能必须至少有一个 FUNC 和一个 BNDRY 测试用例
- 每个
verification_step必须映射到至少一个测试用例 - UI 功能必须至少有一个 UI 和一个 A11Y 测试用例
用例 ID 格式：
ST-{类别}-{功能ID(3位)}-{序号(3位)}
示例：ST-FUNC-005-001、ST-UI-005-002、ST-SEC-012-001
测试用例内容规则：
- 测试步骤必须具体可执行（不含模糊的"验证它能工作"）
- 预期结果必须具体可断言（不含"应该看起来正确"）
- 前置条件必须列出真实、可验证的状态
- UI 测试用例必须包含三层检测：
- Layer 1：
evaluate_script()自动错误检测 - Layer 2：EXPECT/REJECT 格式
- Layer 3：
list_console_messages控制台错误门禁
- Layer 1：
3. 编写测试用例文档
输出文件：docs/test-cases/feature-{id}-{slug}.md
文档结构：
- 头部 — 功能 ID、关联需求、日期、标准
- 摘要表 — 按类别计数
- 测试用例块 — 每个用例一块，所有必需章节
- 追溯矩阵 — 用例 ID <-> 需求 <-> verification_step <-> 自动化测试 <-> 结果
追溯矩阵的"结果"列初始为 PENDING。步骤 4 执行后更新为 PASS/FAIL。
4. 执行测试用例
硬性要求：必须逐一执行 docs/test-cases/feature-{id}-{slug}.md 中定义的测试用例
- 每个测试用例必须单独执行并记录结果
- UI 测试用例不可因任何原因跳过
- 不得合并或简化测试用例执行过程
- 按服务生命周期章节启动服务
- 非 UI 用例：通过运行测试命令或对运行中系统的手动检查验证
- UI 用例：通过 Chrome DevTools MCP 执行
- 更新追溯矩阵"结果"列
- 按服务生命周期章节停止服务
任何用例失败时：
- 通过
AskUserQuestion报告用户：失败用例 ID、步骤详情、实际 vs 预期 - 选项：修复代码并重新执行 / 修改测试用例 / 终止循环
- 失败在此阻塞功能进入审查
执行规则（硬门禁）
失败不可绕过
- 任何测试用例执行失败都阻塞功能标记为 "passing"
- ST 测试中发现的所有 bug 必须修复 — 无论是前端、后端还是集成 bug
- 不可绕过任何原因：
- "简单功能" — 仍需测试用例
- "UI 测试太复杂" — UI 测试不可跳过
- "环境暂时不可用" — 阻塞，不是跳过
集成
调用者： vibeflow-build-work（步骤 9）
依赖： 质量门禁通过
产出： docs/test-cases/feature-{id}-{slug}.md（含执行结果）
链接到： vibeflow-spec-review（通过 Work 步骤 10）