249 lines
8.9 KiB
Markdown
249 lines
8.9 KiB
Markdown
# 增强的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决策**的清晰质量门禁
|
||
- **记录在案的技术债务风险接受**
|
||
- 团队中**一致的测试质量**
|
||
- 通过早期风险识别实现**左移测试**
|