8.9 KiB

Raw Blame History

增强的IDE开发工作流

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

创建新分支

启动新分支

故事创建（Scrum Master）

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

故事实施（开发人员）

开始新的聊天/对话
加载开发代理
执行：*develop-story {selected-story}（运行execute-checklist任务）
审查生成的报告，位于{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：故事创建后（开发开始前）

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

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

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

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

开发人员自助质量检查：

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

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

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

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

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

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

审查期间会发生什么：

深度代码分析
- 架构模式合规性
- 代码质量和可维护性
- 安全漏洞扫描
- 性能瓶颈检测
主动重构
- 在安全的情况下直接改进代码
- 立即修复明显的问题
- 为开发人员建议复杂的重构
测试验证
- 所有级别的覆盖率（单元/集成/E2E）
- 测试质量（无不稳定测试、正确的断言）
- 回归测试的充分性
门禁决策
- 创建：docs/qa/gates/{epic}.{story}-{slug}.yml
- 添加：QA结果部分到故事文件
- 状态：PASS/CONCERNS/FAIL/WAIVED

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

修复后更新门禁状态：

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

理解门禁决策

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

基于风险的测试策略

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

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

特殊情况与最佳实践

高风险或棕地故事

# 始终运行此序列：
@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结果部分
可追溯性：保持需求到测试的映射

提交更改并推送

提交更改
推送到远程

完整的开发周期流程

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

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

快速决策指南

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

场景	开发前	开发中	开发后
简单错误修复	可选	可选	必需 `*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决策的清晰质量门禁
记录在案的技术债务风险接受
团队中一致的测试质量
通过早期风险识别实现左移测试

8.9 KiB Raw Blame History Unescape Escape