# Vibeflow Feature St

> 质量门禁通过后使用 — 独立管理测试环境生命周期，执行黑盒验收测试，生成 ISO/IEC/IEEE 29119 合规测试用例文档

- Skill: `ttttstc/vibeflow-feature-st` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ttttstc/vibeflow-feature-st`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ttttstc/vibeflow-feature-st/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ttttstc (https://skillmd.com/u/ttttstc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ttttstc/vibeflow-feature-st

---


# 功能级黑盒验收测试

在 TDD 实现和质量门禁通过后，为已完成的功能执行黑盒验收测试。此技能独立管理自己的环境生命周期（启动 -> 测试 -> 清理），并生成 ISO/IEC/IEEE 29119 合规的测试用例文档。

**启动宣告：** "正在使用 vibeflow-feature-st 运行黑盒验收测试。"

## 黑盒测试哲学

TDD（vibeflow-tdd）已从内部验证了实现。此技能从**外部**验证 — 如用户或外部系统般：
- 通过真实接口输入（HTTP 端点、UI、CLI 参数）
- 通过真实接口观察输出（HTTP 响应、渲染 UI、stdout）
- 测试设计或执行期间**不参考**内部实现代码

**规则：** 如果一个测试用例需要阅读源代码才能确定预期结果，它不是黑盒测试 — 仅使用 SRS 规格重写。

## 服务生命周期（通过 `.vibeflow/guides/services.md`）

### 启动（首个测试用例前）
1. 读取 `.vibeflow/guides/services.md` — 定位"启动所有服务"章节
2. 检查服务是否已运行：运行健康检查
3. 如未运行：执行启动命令，捕获输出，提取 PID 和端口，记录到 `.vibeflow/logs/session-log.md`
4. 启动失败则诊断根因，修正后更新 `.vibeflow/guides/services.md`

### 清理（所有测试用例完成后）— 强制
1. 停止服务：按 PID 杀进程（优先）或按端口杀（备选）
2. 验证已停止：端口不再响应
3. 记录清理状态

**为什么强制**：留下运行的服务会在后续 ST 循环中造成端口冲突。

### 重启协议（修复-重测循环间）
1. 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` 控制台错误门禁

### 3. 编写测试用例文档

输出文件：`docs/test-cases/feature-{id}-{slug}.md`

文档结构：
1. **头部** — 功能 ID、关联需求、日期、标准
2. **摘要表** — 按类别计数
3. **测试用例块** — 每个用例一块，所有必需章节
4. **追溯矩阵** — 用例 ID <-> 需求 <-> verification_step <-> 自动化测试 <-> 结果

追溯矩阵的"结果"列初始为 `PENDING`。步骤 4 执行后更新为 `PASS`/`FAIL`。

### 4. 执行测试用例

**硬性要求：必须逐一执行 docs/test-cases/feature-{id}-{slug}.md 中定义的测试用例**
- 每个测试用例必须单独执行并记录结果
- **UI 测试用例不可因任何原因跳过**
- 不得合并或简化测试用例执行过程

1. 按服务生命周期章节启动服务
2. 非 UI 用例：通过运行测试命令或对运行中系统的手动检查验证
3. UI 用例：通过 Chrome DevTools MCP 执行
4. 更新追溯矩阵"结果"列
5. 按服务生命周期章节停止服务

**任何用例失败时：**
- 通过 `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）