7.9 KiB

Raw Blame History

风险概况

使用概率×影响分析，为故事实施生成全面的风险评估矩阵。

输入

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: 运营风险

技术风险 (TECH)
- 架构复杂性
- 集成挑战
- 技术债务
- 可扩展性问题
- 系统依赖
安全风险 (SEC)
- 认证/授权缺陷
- 数据泄露漏洞
- 注入攻击
- 会话管理问题
- 加密弱点
性能风险 (PERF)
- 响应时间下降
- 吞吐量瓶颈
- 资源耗尽
- 数据库查询优化
- 缓存失败
数据风险 (DATA)
- 数据丢失的可能性
- 数据损坏
- 侵犯隐私
- 合规性问题
- 备份/恢复差距
业务风险 (BUS)
- 功能不符合用户需求
- 收入影响
- 声誉损害
- 法规不合规
- 市场时机
运营风险 (OPS)
- 部署失败
- 监控差距
- 事件响应准备情况
- 文档不足
- 知识转移问题

风险分析流程

1. 风险识别

为每个类别识别具体风险：

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. 风险优先级排序

创建风险矩阵：

## 风险矩阵

| 风险ID | 描述 | 概率 | 影响 | 评分 | 优先级 |
| --- | --- | --- | --- | --- | --- |
| SEC-001 | XSS漏洞 | 高 (3) | 高 (3) | 9 | 严重 |
| PERF-001 | 仪表板查询缓慢 | 中 (2) | 中 (2) | 4 | 中 |
| DATA-001 | 备份失败 | 低 (1) | 高 (3) | 3 | 低 |

4. 风险缓解策略

为每个已识别的风险提供缓解措施：

mitigation:
  risk_id: 'SEC-001'
  strategy: '预防性' # 预防性|检测性|纠正性
  actions:
    - '实施输入验证库（例如，validator.js）'
    - '添加CSP头以防止XSS执行'
    - '在存储前清理所有用户输入'
    - '在模板中对所有输出进行转义'
  testing_requirements:
    - '使用OWASP ZAP进行安全测试'
    - '对表单进行手动渗透测试'
    - '验证函数的单元测试'
  residual_risk: '低 - 可能仍存在一些零日漏洞'
  owner: 'dev'
  timeline: '部署前'

输出

输出1：门禁YAML块

生成用于粘贴到门禁文件的risk_summary下的内容：

输出规则：

仅包括评估的风险；不要输出占位符
在输出最高风险和任何表格列表时，按分数（降序）对风险进行排序
如果没有风险：总数全为零，省略最高风险，保持建议数组为空

# 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

# 风险概况：故事 {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

## 风险审查触发器

在以下情况下审查和更新风险概况：

-   架构发生重大变化
-   添加了新的集成
-   发现了安全漏洞
-   报告了性能问题
-   法规要求变更

风险评分算法

计算总体故事风险评分：

基础分 = 100
对于每个风险：
  - 严重 (9)：扣20分
  - 高 (6)：扣10分
  - 中 (4)：扣5分
  - 低 (2-3)：扣2分

最低分 = 0（极度危险）
最高分 = 100（风险极小）

基于风险的建议

根据风险概况，建议：

测试优先级
- 首先运行哪些测试
- 需要哪些额外的测试类型
- 测试环境要求
开发重点
- 代码审查重点领域
- 需要额外的验证
- 要实施的安全控制
部署策略
- 对高风险更改进行分阶段推出
- 对有风险的功能使用功能标志
- 回滚程序
监控设置
- 要跟踪的指标
- 要配置的警报
- 仪表板要求

与质量门的集成

确定性门映射：

任何风险评分≥9 → 门 = 失败（除非豁免）
否则，如果任何评分≥6 → 门 = 关注
否则 → 门 = 通过
未缓解的风险 → 在门中记录

输出3：故事钩子行

打印此行以供审查任务引用：

风险概况：qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md

关键原则

尽早并系统地识别风险
使用一致的概率×影响评分
提供可操作的缓解策略
将风险与具体的测试要求联系起来
跟踪缓解后的剩余风险
随着故事的发展更新风险概况

7.9 KiB Raw Blame History Unescape Escape