356 lines
7.9 KiB
Markdown
356 lines
7.9 KiB
Markdown
<!-- 由 BMAD™ Core 驱动 -->
|
||
|
||
# 风险概况
|
||
|
||
使用概率×影响分析，为故事实施生成全面的风险评估矩阵。
|
||
|
||
## 输入
|
||
|
||
```yaml
|
||
required:
|
||
- story_id: '{epic}.{story}' # 例如, "1.3"
|
||
- story_path: 'docs/stories/{epic}.{story}.*.md'
|
||
- story_title: '{title}' # 如果缺少，则从故事文件的H1派生
|
||
- story_slug: '{slug}' # 如果缺少，则从标题派生（小写，连字符连接）
|
||
```
|
||
|
||
## 目的
|
||
|
||
识别、评估和优先处理故事实施中的风险。根据风险级别提供风险缓解策略和测试重点领域。
|
||
|
||
## 风险评估框架
|
||
|
||
### 风险类别
|
||
|
||
**类别前缀：**
|
||
|
||
- `TECH`: 技术风险
|
||
- `SEC`: 安全风险
|
||
- `PERF`: 性能风险
|
||
- `DATA`: 数据风险
|
||
- `BUS`: 业务风险
|
||
- `OPS`: 运营风险
|
||
|
||
1. **技术风险 (TECH)**
|
||
- 架构复杂性
|
||
- 集成挑战
|
||
- 技术债务
|
||
- 可扩展性问题
|
||
- 系统依赖
|
||
|
||
2. **安全风险 (SEC)**
|
||
- 认证/授权缺陷
|
||
- 数据泄露漏洞
|
||
- 注入攻击
|
||
- 会话管理问题
|
||
- 加密弱点
|
||
|
||
3. **性能风险 (PERF)**
|
||
- 响应时间下降
|
||
- 吞吐量瓶颈
|
||
- 资源耗尽
|
||
- 数据库查询优化
|
||
- 缓存失败
|
||
|
||
4. **数据风险 (DATA)**
|
||
- 数据丢失的可能性
|
||
- 数据损坏
|
||
- 侵犯隐私
|
||
- 合规性问题
|
||
- 备份/恢复差距
|
||
|
||
5. **业务风险 (BUS)**
|
||
- 功能不符合用户需求
|
||
- 收入影响
|
||
- 声誉损害
|
||
- 法规不合规
|
||
- 市场时机
|
||
|
||
6. **运营风险 (OPS)**
|
||
- 部署失败
|
||
- 监控差距
|
||
- 事件响应准备情况
|
||
- 文档不足
|
||
- 知识转移问题
|
||
|
||
## 风险分析流程
|
||
|
||
### 1. 风险识别
|
||
|
||
为每个类别识别具体风险：
|
||
|
||
```yaml
|
||
risk:
|
||
id: 'SEC-001' # 使用前缀：SEC, PERF, DATA, BUS, OPS, TECH
|
||
category: security
|
||
title: '用户表单输入验证不足'
|
||
description: '表单输入未正确清理可能导致XSS攻击'
|
||
affected_components:
|
||
- 'UserRegistrationForm'
|
||
- 'ProfileUpdateForm'
|
||
detection_method: '代码审查发现缺少验证'
|
||
```
|
||
|
||
### 2. 风险评估
|
||
|
||
使用概率×影响评估每个风险：
|
||
|
||
**概率级别：**
|
||
|
||
- `高 (3)`: 很可能发生 (>70%的几率)
|
||
- `中 (2)`: 可能发生 (30-70%的几率)
|
||
- `低 (1)`: 不太可能发生 (<30%的几率)
|
||
|
||
**影响级别：**
|
||
|
||
- `高 (3)`: 严重后果（数据泄露、系统宕机、重大财务损失）
|
||
- `中 (2)`: 中等后果（性能下降、轻微数据问题）
|
||
- `低 (1)`: 轻微后果（外观问题、轻微不便）
|
||
|
||
### 风险评分 = 概率 × 影响
|
||
|
||
- 9: 严重风险 (红色)
|
||
- 6: 高风险 (橙色)
|
||
- 4: 中风险 (黄色)
|
||
- 2-3: 低风险 (绿色)
|
||
- 1: 极小风险 (蓝色)
|
||
|
||
### 3. 风险优先级排序
|
||
|
||
创建风险矩阵：
|
||
|
||
```markdown
|
||
## 风险矩阵
|
||
|
||
| 风险ID | 描述 | 概率 | 影响 | 评分 | 优先级 |
|
||
| --- | --- | --- | --- | --- | --- |
|
||
| SEC-001 | XSS漏洞 | 高 (3) | 高 (3) | 9 | 严重 |
|
||
| PERF-001 | 仪表板查询缓慢 | 中 (2) | 中 (2) | 4 | 中 |
|
||
| DATA-001 | 备份失败 | 低 (1) | 高 (3) | 3 | 低 |
|
||
```
|
||
|
||
### 4. 风险缓解策略
|
||
|
||
为每个已识别的风险提供缓解措施：
|
||
|
||
```yaml
|
||
mitigation:
|
||
risk_id: 'SEC-001'
|
||
strategy: '预防性' # 预防性|检测性|纠正性
|
||
actions:
|
||
- '实施输入验证库（例如，validator.js）'
|
||
- '添加CSP头以防止XSS执行'
|
||
- '在存储前清理所有用户输入'
|
||
- '在模板中对所有输出进行转义'
|
||
testing_requirements:
|
||
- '使用OWASP ZAP进行安全测试'
|
||
- '对表单进行手动渗透测试'
|
||
- '验证函数的单元测试'
|
||
residual_risk: '低 - 可能仍存在一些零日漏洞'
|
||
owner: 'dev'
|
||
timeline: '部署前'
|
||
```
|
||
|
||
## 输出
|
||
|
||
### 输出1：门禁YAML块
|
||
|
||
生成用于粘贴到门禁文件的`risk_summary`下的内容：
|
||
|
||
**输出规则：**
|
||
|
||
- 仅包括评估的风险；不要输出占位符
|
||
- 在输出最高风险和任何表格列表时，按分数（降序）对风险进行排序
|
||
- 如果没有风险：总数全为零，省略最高风险，保持建议数组为空
|
||
|
||
```yaml
|
||
# risk_summary（粘贴到门禁文件）：
|
||
risk_summary:
|
||
totals:
|
||
critical: X # 评分 9
|
||
high: Y # 评分 6
|
||
medium: Z # 评分 4
|
||
low: W # 评分 2-3
|
||
highest:
|
||
id: SEC-001
|
||
score: 9
|
||
title: '个人资料表单上的XSS'
|
||
recommendations:
|
||
must_fix:
|
||
- '添加入口清理和CSP'
|
||
monitor:
|
||
- '为认证端点添加安全警报'
|
||
```
|
||
|
||
### 输出2：Markdown报告
|
||
|
||
**保存到：** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
|
||
|
||
```markdown
|
||
# 风险概况：故事 {epic}.{story}
|
||
|
||
日期：{date}
|
||
审查员：Quinn（测试架构师）
|
||
|
||
## 执行摘要
|
||
|
||
- 已识别风险总数：X
|
||
- 严重风险：Y
|
||
- 高风险：Z
|
||
- 风险评分：XX/100（已计算）
|
||
|
||
## 需要立即关注的严重风险
|
||
|
||
### 1. [ID]：风险标题
|
||
|
||
**评分：9（严重）**
|
||
**概率**：高 - 详细理由
|
||
**影响**：高 - 潜在后果
|
||
**缓解**：
|
||
|
||
- 需要立即采取行动
|
||
- 要采取的具体步骤
|
||
**测试重点**：需要的具体测试场景
|
||
|
||
## 风险分布
|
||
|
||
### 按类别
|
||
|
||
- 安全性：X个风险（Y个严重）
|
||
- 性能：X个风险（Y个严重）
|
||
- 数据：X个风险（Y个严重）
|
||
- 业务：X个风险（Y个严重）
|
||
- 运营：X个风险（Y个严重）
|
||
|
||
### 按组件
|
||
|
||
- 前端：X个风险
|
||
- 后端：X个风险
|
||
- 数据库：X个风险
|
||
- 基础设施：X个风险
|
||
|
||
## 详细风险登记册
|
||
|
||
[包含所有风险、评分和缓解措施的完整表格]
|
||
|
||
## 基于风险的测试策略
|
||
|
||
### 优先级1：严重风险测试
|
||
|
||
- 严重风险的测试场景
|
||
- 所需的测试类型（安全、负载、混沌）
|
||
- 测试数据要求
|
||
|
||
### 优先级2：高风险测试
|
||
|
||
- 集成测试场景
|
||
- 边缘情况覆盖
|
||
|
||
### 优先级3：中/低风险测试
|
||
|
||
- 标准功能测试
|
||
- 回归测试套件
|
||
|
||
## 风险接受标准
|
||
|
||
### 生产前必须修复
|
||
|
||
- 所有严重风险（评分9）
|
||
- 影响安全/数据的高风险
|
||
|
||
### 可以在有缓解措施的情况下部署
|
||
|
||
- 有补偿控制的中等风险
|
||
- 有监控的低风险
|
||
|
||
### 已接受的风险
|
||
|
||
- 记录团队接受的任何风险
|
||
- 包括适当授权的签字
|
||
|
||
## 监控要求
|
||
|
||
部署后监控：
|
||
|
||
- PERF风险的性能指标
|
||
- SEC风险的安全警报
|
||
- 运营风险的错误率
|
||
- 业务风险的业务KPI
|
||
|
||
## 风险审查触发器
|
||
|
||
在以下情况下审查和更新风险概况：
|
||
|
||
- 架构发生重大变化
|
||
- 添加了新的集成
|
||
- 发现了安全漏洞
|
||
- 报告了性能问题
|
||
- 法规要求变更
|
||
```
|
||
|
||
## 风险评分算法
|
||
|
||
计算总体故事风险评分：
|
||
|
||
```text
|
||
基础分 = 100
|
||
对于每个风险：
|
||
- 严重 (9)：扣20分
|
||
- 高 (6)：扣10分
|
||
- 中 (4)：扣5分
|
||
- 低 (2-3)：扣2分
|
||
|
||
最低分 = 0（极度危险）
|
||
最高分 = 100（风险极小）
|
||
```
|
||
|
||
## 基于风险的建议
|
||
|
||
根据风险概况，建议：
|
||
|
||
1. **测试优先级**
|
||
- 首先运行哪些测试
|
||
- 需要哪些额外的测试类型
|
||
- 测试环境要求
|
||
|
||
2. **开发重点**
|
||
- 代码审查重点领域
|
||
- 需要额外的验证
|
||
- 要实施的安全控制
|
||
|
||
3. **部署策略**
|
||
- 对高风险更改进行分阶段推出
|
||
- 对有风险的功能使用功能标志
|
||
- 回滚程序
|
||
|
||
4. **监控设置**
|
||
- 要跟踪的指标
|
||
- 要配置的警报
|
||
- 仪表板要求
|
||
|
||
## 与质量门的集成
|
||
|
||
**确定性门映射：**
|
||
|
||
- 任何风险评分≥9 → 门 = 失败（除非豁免）
|
||
- 否则，如果任何评分≥6 → 门 = 关注
|
||
- 否则 → 门 = 通过
|
||
- 未缓解的风险 → 在门中记录
|
||
|
||
### 输出3：故事钩子行
|
||
|
||
**打印此行以供审查任务引用：**
|
||
|
||
```text
|
||
风险概况：qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
|
||
```
|
||
|
||
## 关键原则
|
||
|
||
- 尽早并系统地识别风险
|
||
- 使用一致的概率×影响评分
|
||
- 提供可操作的缓解策略
|
||
- 将风险与具体的测试要求联系起来
|
||
- 跟踪缓解后的剩余风险
|
||
- 随着故事的发展更新风险概况
|