# 增强的IDE开发工作流

这是一个简单的分步指南，可帮助您使用BMad方法高效地管理开发工作流。该工作流在整个开发生命周期中集成了测试架构师（QA代理），以确保质量、防止回归并保持高标准。有关此处未涵盖的任何场景，请参阅**[<ins>用户指南</ins>](user-guide.md)**。

## 创建新分支

1.  **启动新分支**

## 故事创建（Scrum Master）

1.  **开始新的聊天/对话**
2.  **加载SM代理**
3.  **执行**：`*draft`（运行create-next-story任务）
4.  **审查生成的故事**，位于`docs/stories/`
5.  **更新状态**：将状态从“草稿”更改为“已批准”

## 故事实施（开发人员）

1.  **开始新的聊天/对话**
2.  **加载开发代理**
3.  **执行**：`*develop-story {selected-story}`（运行execute-checklist任务）
4.  **审查生成的报告**，位于`{selected-story}`

## 在整个工作流中集成测试架构师

测试架构师（Quinn）在整个开发生命周期中提供全面的质量保证。以下是如何在适当的时候利用每项功能。

**命令别名：** 文档使用简写形式（`*risk`, `*design`, `*nfr`, `*trace`）来表示完整命令（`*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`）。

### 快速命令参考

| **阶段** | **命令** | **目的** | **输出** | **优先级** |
| --- | --- | --- | --- | --- |
| **故事批准后** | `*risk` | 识别集成和回归风险 | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` | 对于复杂/棕地项目为高 |
| | `*design` | 为开发创建测试策略 | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` | 对于新功能为高 |
| **开发期间** | `*trace` | 验证测试覆盖率 | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` | 中 |
| | `*nfr` | 验证质量属性 | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` | 对于关键功能为高 |
| **开发后** | `*review` | 全面评估 | 故事中的QA结果 + `docs/qa/gates/{epic}.{story}-{slug}.yml` | **必需** |
| **审查后** | `*gate` | 更新质量决策 | 更新的 `docs/qa/gates/{epic}.{story}-{slug}.yml` | 根据需要 |

### 阶段1：故事创建后（开发开始前）

**推荐 - 为开发人员的成功做好准备：**

```bash
# 1. 风险评估（对于复杂的故事首先运行）
@qa *risk {approved-story}
# 识别：
#   - 技术债务影响
#   - 集成复杂性
#   - 回归可能性（1-9评分）
#   - 缓解策略
# 对于以下情况至关重要：棕地、API更改、数据迁移

# 2. 测试设计（其次运行以指导实施）
@qa *design {approved-story}
# 提供：
#   - 每个验收标准的测试场景
#   - 测试级别建议（单元/集成/E2E）
#   - 基于风险的优先级（P0/P1/P2）
#   - 测试数据要求
# 与开发人员共享：包含在故事评论中或附加到工单
```

### 阶段2：开发期间（实施中期检查点）

**开发人员自助质量检查：**

```bash
# 3. 需求跟踪（在开发中期验证覆盖率）
@qa *trace {story-in-progress}
# 验证：
#   - 所有验收标准都有测试
#   - 没有遗漏的测试场景
#   - 适当的测试级别
#   - Given-When-Then文档的清晰度
# 运行时机：编写初始测试后

# 4. NFR验证（检查质量属性）
@qa *nfr {story-in-progress}
# 评估：
#   - 安全性：身份验证、授权、数据保护
#   - 性能：响应时间、资源使用
#   - 可靠性：错误处理、恢复
#   - 可维护性：代码质量、文档
# 运行时机：标记“准备审查”之前
```

### 阶段3：故事审查（质量门评估）

**必需 - 全面的测试架构审查：**

**先决条件：** 所有测试在本地通过；lint和类型检查通过。

```bash
# 5. 全面审查（标准审查流程）
@qa *review {completed-story}
```

**审查期间会发生什么：**

1.  **深度代码分析**
    -   架构模式合规性
    -   代码质量和可维护性
    -   安全漏洞扫描
    -   性能瓶颈检测

2.  **主动重构**
    -   在安全的情况下直接改进代码
    -   立即修复明显的问题
    -   为开发人员建议复杂的重构

3.  **测试验证**
    -   所有级别的覆盖率（单元/集成/E2E）
    -   测试质量（无不稳定测试、正确的断言）
    -   回归测试的充分性

4.  **门禁决策**
    -   创建：`docs/qa/gates/{epic}.{story}-{slug}.yml`
    -   添加：QA结果部分到故事文件
    -   状态：PASS/CONCERNS/FAIL/WAIVED

### 阶段4：审查后（解决问题后）

**修复后更新门禁状态：**

```bash
# 6. 门禁更新（记录最终决策）
@qa *gate {reviewed-story}
# 更新：带有新状态的质量门禁
# 使用时机：解决审查反馈后
# 记录：修复了什么，豁免了什么
```

### 理解门禁决策

| **状态** | **含义** | **所需操作** | **可以继续吗？** |
| --- | --- | --- | --- |
| **PASS** | 所有关键要求均已满足 | 无 | ✅ 是 |
| **CONCERNS** | 发现非关键问题 | 建议团队审查 | ⚠️ 谨慎 |
| **FAIL** | 关键问题（安全、缺少P0测试） | 必须修复 | ❌ 否 |
| **WAIVED** | 问题已确认并接受 | 记录理由 | ✅ 经批准 |

### 基于风险的测试策略

测试架构师使用风险评分来确定测试的优先级：

| **风险评分** | **计算** | **测试优先级** | **门禁影响** |
| --- | --- | --- | --- |
| **9** | 高概率 × 高影响 | P0 - 必须彻底测试 | 如果未测试则FAIL |
| **6** | 中高组合 | P1 - 应充分测试 | 如果有差距则CONCERNS |
| **4** | 中等组合 | P1 - 应测试 | 如果有显著差距则CONCERNS |
| **2-3** | 中低组合 | P2 - 最好有 | 在审查中注明 |
| **1** | 风险极小 | P2 - 最低限度 | 在审查中注明 |

### 特殊情况与最佳实践

#### 高风险或棕地故事

```bash
# 始终运行此序列：
@qa *risk {story}    # 首先 - 识别危险
@qa *design {story}  # 其次 - 规划防御
# 然后在开发期间：
@qa *trace {story}   # 验证回归覆盖率
@qa *nfr {story}     # 检查性能影响
# 最后：
@qa *review {story}  # 深度集成分析
```

#### 复杂集成

-   在开发期间多次运行`*trace`
-   关注集成测试覆盖率
-   使用`*nfr`验证跨系统性能
-   在审查时特别关注API合约

#### 性能关键功能

-   尽早并经常运行`*nfr`（不仅仅是在审查时）
-   在更改前建立性能基线
-   记录可接受的性能下降
-   在`*design`中考虑负载测试要求

### 强制执行的测试质量标准

Quinn确保所有测试都符合这些标准：

-   **无不稳定测试**：正确的异步处理、明确的等待
-   **无硬等待**：仅使用动态策略（轮询、事件）
-   **无状态**：测试独立并行运行
-   **自清理**：测试管理自己的测试数据
-   **适当的级别**：单元测试用于逻辑，集成测试用于交互，E2E测试用于流程
-   **清晰的断言**：将断言保留在测试中，而不是埋在辅助函数里

### 文档与审计跟踪

所有测试架构师的活动都会创建永久记录：

-   **评估报告**：位于`docs/qa/assessments/`的带时间戳的分析
-   **门禁文件**：位于`docs/qa/gates/`的决策记录
-   **故事更新**：故事文件中的QA结果部分
-   **可追溯性**：保持需求到测试的映射

## 提交更改并推送

1.  **提交更改**
2.  **推送到远程**

## 完整的开发周期流程

### 带有测试架构师的完整工作流

1.  **SM**：创建下一个故事 → 审查 → 批准
2.  **QA（可选）**：风险评估（`*risk`）→ 测试设计（`*design`）
3.  **开发**：实施故事 → 编写测试 → 完成
4.  **QA（可选）**：开发中期检查（`*trace`, `*nfr`）
5.  **开发**：标记为准备审查
6.  **QA（必需）**：审查故事（`*review`）→ 门禁决策
7.  **开发（如果需要）**：解决问题
8.  **QA（如果需要）**：更新门禁（`*gate`）
9.  **提交**：所有更改
10. **推送**：到远程
11. **继续**：直到所有功能实施完毕

### 快速决策指南

**我应该运行测试架构师命令吗？**

| **场景** | **开发前** | **开发中** | **开发后** |
| --- | --- | --- | --- |
| **简单错误修复** | 可选 | 可选 | 必需 `*review` |
| **新功能** | 推荐 `*risk`, `*design` | 可选 `*trace` | 必需 `*review` |
| **棕地更改** | **必需** `*risk`, `*design` | 推荐 `*trace`, `*nfr` | 必需 `*review` |
| **API修改** | **必需** `*risk`, `*design` | **必需** `*trace` | 必需 `*review` |
| **性能关键** | 推荐 `*design` | **必需** `*nfr` | 必需 `*review` |
| **数据迁移** | **必需** `*risk`, `*design` | **必需** `*trace` | 必需 `*review` + `*gate` |

### 成功指标

测试架构师有助于实现：

-   生产中**零回归缺陷**
-   **100%需求覆盖率**的测试
-   用于**go/no-go决策**的清晰质量门禁
-   **记录在案的技术债务风险接受**
-   团队中**一致的测试质量**
-   通过早期风险识别实现**左移测试**