risk-based-testing

对所有功能进行同等覆盖会在低风险区域浪费精力，同时让关键路径测试不足——设置页面达到 90% 的覆盖率，耗费的精力本可用于结账流程。此技能可识别风险，将其量化为影响 × 概率，把测试密度映射到风险区域，并随着产品演进持续更新评估结果。输出的风险矩阵经过评分，可供 `test-strategy` 和 `test-planning` 使用。

快速导航

情况	从这里开始
新产品，尚无风险模型	阶段 1（识别）→ 运行完整的 6 个阶段
事故后重新评估	阶段 6（重新评估触发条件），然后在阶段 2 中重新评估受影响的项目
评估 AI/LLM 功能	阶段 3（AI/LLM 故障类别），在阶段 2 中为各类别评分
刷新现有矩阵的迭代周期	针对变更功能执行阶段 4–5（热图 + 覆盖对齐）
验证旧热图是否仍然准确	阶段 6 的信号 + 反模式“风险作秀”

---

发现问题

先检查 .agents/qa-project-context.md——如果文件存在，则以其为基础，并跳过其中已有答案的问题。向工程、产品和运营团队的利益相关者收集其余信息。

收入关键流程

• 哪些用户流程会直接产生收入？（结账、订阅、账单、升级）
• 每个流程每停机一小时会造成多少收入影响？
• 是否存在有时限要求的流程？（限时抢购、市场交易时段、发薪截止日期）
• 哪些流程有附带财务处罚的合同 SLA？

近期故障

• 最近 3 个版本中有哪些功能出过问题？有哪些问题流入了生产环境？
• 根本原因是什么？（代码缺陷、配置错误、第三方故障、数据迁移）
• 每起事故的影响范围有多大？（受影响用户、收入损失、声誉影响）
• 测试中是否有过险些漏过、到后期才发现的问题？

脆弱区域

• 代码库中哪些部分变更最频繁？（高变更率 = 高风险）
• 哪些模块当前测试覆盖率最低？
• 哪些区域的业务逻辑最复杂，或条件分支最多？
• 哪些代码由已离开团队的工程师编写？

第三方依赖

• 产品依赖哪些外部服务？（支付处理商、身份验证提供商、CDN、API）
• 各项依赖的历史可靠性如何？
• 各项依赖发生故障时会怎样？（平稳降级还是直接失败？）
• 是否存在没有备用方案的单点故障？

合规与数据

• 适用哪些监管要求？（GDPR、PCI-DSS、HIPAA、SOC2、SOX、EU AI Act）
• 哪些数据最敏感？（个人身份信息、财务信息、健康信息、凭据）
• 数据泄露或违反合规要求会造成哪些法律后果？
• 是否有审计要求，必须提供特定的测试证据？

---

核心原则

1. 并非所有功能都同等重要。 结账流程中的错误可能导致用户无法购买，而设置页面上的图标错位则截然不同。各处都采用相同的覆盖率，会在低风险区域浪费资源，同时让关键路径缺乏充分测试。
2. 风险 = 影响 × 概率。 风险不是凭直觉判断的。它由两个独立评分的维度相乘得出：如果发生故障，后果有多严重（影响）；发生故障的可能性有多大（概率）。在整个产品中采用一致的标准为两者评分，然后相乘。
3. 风险评估需要持续进行。 创建后从不更新的风险模型会带来虚假的信心。产品、依赖项或团队发生变化，以及每次生产事故发生后，风险都会变化。将重新评估纳入日常节奏。
4. 险些发生的事故也是数据。 在预发布环境中拦截严重错误并不值得庆祝——这表明模型低估了该区域的风险。像追踪生产事故一样严谨地追踪险些发生的事故。
5. 风险决定覆盖率，而不是反过来。 不要从“我们需要各处都达到 80% 的覆盖率”开始，而要先问“哪些故障的危害最大？”，再让模型决定各模块的覆盖率目标。

---

工作流

1. Identify → 2. Classify → 3. Analyze → 4. Heatmap → 5. Coverage → 6. Reassess → (repeat)
                                 ↑
                       score ≥ 10 only; skip to 4 if no items reach threshold

阶段 1：识别风险

列出所有可能出错的情况。尽可能全面。信息来源包括：

• 利益相关方访谈： 产品经理了解对业务至关重要的流程。工程师了解脆弱的代码。支持团队了解用户反复提出的投诉。
• 事故历史： 过去的故障可以预测未来的故障。回顾过去 6–12 个月的事后分析报告。
• 依赖关系映射： 列出每个外部服务、数据库、消息队列和第三方 API。每一项都是一个风险向量。
• 变更分析： 代码变更频繁的区域，缺陷概率更高。使用阶段 6 中按变更频率排序的命令找出这些区域；git log --stat <file> 用于检查特定可疑文件的单次提交，而不是用于排序。
• 架构审查： 共享数据库、单点故障、同步调用链和紧密耦合的模块都会扩大影响范围。

使用 HTSM v6.3（Heuristic Test Strategy Model，Bach）作为阶段 1 的分析视角——其基于状态和边界的启发式方法可以发现仅凭功能列表无法察觉的风险。下载：https://www.satisfice.com/download/heuristic-test-strategy-model

输出：一份原始风险项列表，每项描述可能发生的故障及其后果。

阶段 2：风险分类

从两个维度对每项风险进行分类。

影响类别（影响有多严重）：

分数	等级	定义	示例
5	灾难性	收入损失、数据泄露、法律诉讼、用户安全问题	支付处理失败、个人身份信息（PII）泄露
4	重大	对用户造成显著影响、违反 SLA、主要功能故障	部分用户无法登录、数据损坏
3	中等	工作流受阻，但有替代方法	搜索返回错误结果、导出失败
2	轻微	视觉问题或轻微的用户体验问题	对齐错误、非关键页面加载缓慢
1	可忽略	不影响用户，仅限内部	管理员提示文本错误、日志格式问题

概率类别（可能性有多大）：

分数	等级	定义	指标
5	频繁	预计大多数版本中都会发生	代码变更频繁、没有测试、逻辑复杂
4	很可能	可能在一个季度内发生	近期有变更、测试覆盖不完整、存在已知技术债
3	可能	可能发生，且过去发生过	复杂度适中、有一定测试覆盖
2	不太可能	几率很低，但并非不可能	代码稳定、测试覆盖良好、逻辑简单
1	极少	需要特殊情况才会发生	测试充分、极少变更、逻辑简单

综合分数 = 影响 × 概率。频繁变更意味着缺陷概率较高，因此，在频繁变更下的中等影响（3）功能，其概率为 5 → 风险分数：15 → 严重区域，尽管其影响“仅为”中等。优先级由综合分数决定，而非仅由影响决定。

阶段 3：失效模式分析

对每项高风险内容（分数 ≥ 10）进行详细的失效模式分析。

Feature/Component: [name]
Risk Score: [impact × probability]

Failure Mode 1: [what specifically can fail]
  Trigger:            [what causes this failure]
  Blast Radius:       [users affected, systems affected, data affected]
  Detection Method:   [how would we know -- monitoring, user report, test]
  Current Mitigation: [existing tests, monitoring, feature flags, fallbacks]
  Gap:                [what is missing from current mitigation]

Failure Mode 2: ...

示例——电子商务结账（风险分数 20，影响 5 × 概率 4）：

Failure Mode 1: Payment charge succeeds but order not recorded
  Trigger:            Race condition between payment API callback and order write
  Blast Radius:       Individual users; money charged but no order confirmation
  Detection Method:   Payment reconciliation job (runs hourly), user complaint
  Current Mitigation: Idempotency key on payment, retry on order write
  Gap:                No automated test for the race condition; reconciliation delay is 1 hour

Failure Mode 2: Discount code applies incorrect amount
  Trigger:            Percentage discount on already-discounted item
  Blast Radius:       All users with stacked discounts; revenue leakage
  Detection Method:   Margin monitoring alert (>5% deviation)
  Current Mitigation: Unit tests for single discounts
  Gap:                No tests for discount stacking; no tests for rounding edge cases

Failure Mode 3: Inventory not reserved during checkout
  Trigger:            Concurrent purchases of last-stock item
  Blast Radius:       Oversold items, fulfillment failure, customer trust
  Detection Method:   Fulfillment team discovers during packing
  Current Mitigation: Database-level stock check on order creation
  Gap:                No load test simulating concurrent last-item purchases

AI/LLM 失效类别

对于 AI/LLM 功能，按照以下 CT-GenAI 类别进行分类，并像评估其他风险一样独立评估影响和概率。缓解措施是建立自动化评测套件，而非单次手动测试。

AI/LLM 专属失效类别（来自 ISTQB CT-GenAI v1.1，于 2026 年 4 月 27 日生效）：

• 幻觉 / 推理错误——影响：中等至重大；如果没有明确的提示词评测覆盖，概率较高。检测方式：黄金数据集评测、事实核查断言（参见 ai-system-testing）。
• 偏见——在受监管行业（金融、医疗保健、招聘）中影响为灾难性。概率取决于数据集。检测方式：反事实评测、人口统计公平性检查。
• 提示词注入 / 越狱——影响：重大（数据泄露、提示词提取）。对于任何面向外部的 LLM 功能，概率都较高。检测方式：Garak、PyRIT、Promptfoo redteam。
• 隐私泄露——根据 GDPR/CCPA/EU AI Act，影响为灾难性。概率取决于数据集。检测方式：扫描训练数据和提示词中的个人身份信息（PII）。
• 不符合 AI Act / 监管要求——影响：灾难性（罚款、禁令）。对于面向欧盟的 AI 功能，概率较高。检测方式：参见 compliance-testing。

工具最新状态（2026 年年中）：PyRIT 现已迁至 microsoft/PyRIT——旧的 Azure 托管仓库已于 2026 年 3 月归档，因此新的红队测试工作不要再使用旧版 Azure 路径。Promptfoo 已被 OpenAI 收购（2026 年 3 月），但仍采用 MIT 许可证。Garak 仍在维护，且没有变化。

参考框架： CT-GenAI v1.1（ISTQB，于 2026 年 4 月 27 日生效）将上述 AI/LLM 类别编纂为标准。WQR 2025-26（Capgemini，第 17 版，2025 年 11 月）提供了用于 AI 风险规划的采用阶段框架。

阶段 4：风险热力图

将所有风险项绘制在 5×5 矩阵上，以传达优先级并指导覆盖率决策。

                    PROBABILITY
                    Rare(1)   Unlikely(2)  Possible(3)  Likely(4)   Frequent(5)
                   +----------+-----------+-----------+----------+-----------+
  Catastrophic(5)  |  5  MED  | 10  HIGH  | 15  CRIT  | 20 CRIT  | 25  CRIT  |
                   +----------+-----------+-----------+----------+-----------+
  Major(4)         |  4  LOW  |  8  MED   | 12  HIGH  | 16 CRIT  | 20  CRIT  |
I                  +----------+-----------+-----------+----------+-----------+
M  Moderate(3)     |  3  LOW  |  6  MED   |  9  MED   | 12 HIGH  | 15  CRIT  |
P                  +----------+-----------+-----------+----------+-----------+
A  Minor(2)        |  2  LOW  |  4  LOW   |  6  MED   |  8 MED   | 10  HIGH  |
C                  +----------+-----------+-----------+----------+-----------+
T  Negligible(1)   |  1  LOW  |  2  LOW   |  3  LOW   |  4 LOW   |  5  MED   |
                   +----------+-----------+-----------+----------+-----------+

区域边界和行动映射：

区域	分数范围	颜色	测试行动
严重	15-25	红色	全面自动化 + 在生产环境中监控 + 负载测试 + 手动探索式测试
高	10-14	橙色	全面自动化 + 定期人工审查
中	5-9	黄色	自动化覆盖顺利路径 + 关键错误情况
低	1-4	绿色	发布时进行手动测试，或完全跳过

填充后的示例（每项具名风险的落点）：

                    Rare(1)   Unlikely(2)  Possible(3)  Likely(4)   Frequent(5)
  Catastrophic(5)             Auth bypass   Payments fail  Checkout crash
  Major(4)                                  Data export    Search broken  User upload
  Moderate(3)                  Report fmt    Email deliver  Profile edit
  Minor(2)         Footer link Tooltip text  Theme switch
  Negligible(1)    Admin label

阶段 5：测试覆盖对齐

根据风险等级匹配测试密度。每个区域都有规定的处理方法。

风险区域	单元测试	集成测试	E2E 测试	手动测试	监控
严重（15-25）	90%+ 分支覆盖率	所有服务边界	完整用户流程 + 错误路径	每次发布进行探索式测试	实时警报、合成检查
高（10-14）	80%+ 分支覆盖率	关键交互	顺利路径 + 最常见的 3 种错误路径	抽查	仪表板 + 每日审查
中（5-9）	70%+ 分支覆盖率	仅顺利路径	仅顺利路径	重大变更时	每周审查
低（1-4）	基本顺利路径	无需	无需	初始构建时	无需

差距分析工作表

对比各风险区域当前的覆盖率与所需覆盖率：

Feature: [name]
Risk Zone: [CRITICAL / HIGH / MEDIUM / LOW]      Risk Score: [number]

Required Coverage:
  Unit:        [target %]     Current: [actual %]     Gap: [delta]
  Integration: [required?]    Current: [exists? y/n]  Gap: [missing scenarios]
  E2E:         [required?]    Current: [exists? y/n]  Gap: [missing flows]
  Monitoring:  [required?]    Current: [exists? y/n]  Gap: [missing alerts]

Priority: [P0 / P1 / P2 / P3]
Estimated Effort: [hours / story points]
Owner: [name]                Target Sprint: [sprint number]

变更频繁这一信号会促使团队打开此工作表：某个模块在 3 个月内变更了 47 次（概率 → 5），但分支覆盖率仅为 40%，且没有集成测试，因此会跃升到更高的区域（例如，中 → 高）；新的覆盖率目标有变更频繁这一事实作为依据，而不是随意选定。

参见 references/examples.md，其中有四个完整评分示例（结账、媒体平台、第三方 API、身份验证），展示从风险评分到规定覆盖率的全过程。

阶段 6：监控与重新评估

风险评估不是一次性活动。将重新评估纳入团队的日常节奏。

重新评估触发条件：

• 每次生产事故后（48 小时内）：重新评估受影响项目的分数，检查依赖项的健康状况，并重新运行阶段 5 的差距分析，以揭示事故暴露出的任何覆盖差距
• 引入新的功能领域时
• 关键依赖项发生变化时（API 版本、服务提供方切换）
• 团队构成发生重大变化时
• 至少每季度一次，即使没有触发条件也要进行

要持续监控的风险信号：

• 按模块统计代码变更频率（按频率排序的表格）：

  git log --since="3 months ago" --name-only --format= | grep -v '^$' | sort | uniq -c | sort -rn | head -20
  

• **缺陷聚集情况：**哪些模块产生的 Bug 最多？使用问题标签进行跟踪。
• **险些发生事故的频率：**分阶段测试/QA 捕获问题、防止生产事故的情况有多频繁？
• **依赖项健康状况：**监控关键第三方服务的状态页和正常运行时间。
• **覆盖率趋势：**高风险区域的覆盖率是在增加还是减少？

---

反模式

对所有内容一视同仁地测试

无论风险如何，都对每项功能应用相同的覆盖率目标。在设置页面上设定 90% 的目标会浪费本应投入支付或身份验证的精力。让风险模型指导资源分配。

一次性风险评估

在规划期间创建矩阵，之后便不再更新。产品、团队和依赖项都会变化。6 个月前的模型早已过时；依赖项、功能或事故一旦改变了整体情况，模型就无法反映当前状况。安排重新评估并确保执行。

忽视险些发生的事故

将分阶段测试中捕获的 Bug 视为纯粹的成功。如果一个严重 Bug 仅靠手动测试才被发现，就说明自动化安全网存在缺口。记录险些发生的事故，并调整模型。

风险作秀

走过场（填写矩阵、绘制热力图），却不调整测试分配。如果热力图已经绘制，但覆盖情况与之不符，那么这项工作就白做了。每季度验证一次一致性。Bolton 的《Quality Engineering Is Not Testing》（2026-04-20）警示的正是这种情况——绘制热力图，然后就说“QE 完成了”。参考：https://developsense.com/blog/2026/04/quality-engineering-is-not-testing

锚定历史风险

过度看重过去的事故，却低估新的风险向量。一个 2 年前出过问题、之后已重写的模块，可能不再是高风险；一个全新的第三方集成风险未知，值得重点关注。

混淆严重性与优先级

严重性指故障后果有多严重；优先级指测试的紧迫程度。灾难性但罕见的故障（地震摧毁数据中心）优先级可能低于中等但频繁的故障（搜索偶尔出错）。使用综合评分，而非只看影响程度。

---

验证

在宣布完成前，证明矩阵确实存在且与实际情况一致——先做最小检查：

• 制品存在且已纳入版本控制： git ls-files | grep -E 'risk-matrix|qa-project-context' 返回该文件。某人笔记本上的未跟踪草稿不算风险模型。
• 每项范围内功能都已评分： 在制品中搜索缺少影响或概率分值的行。只有名称、没有评分的功能属于缺口，而不是低风险。
• 高分项已完成故障模式分析： 每项评分 ≥ 10 的条目都包含一个填写了全部五个字段的区块（触发条件、影响范围、检测方法、当前缓解措施、缺口）。故障模式中的“缺口”一栏为空，说明并未真正完成分析。
• 覆盖情况与热力图一致： 对每项 CRITICAL/HIGH 功能，确认 Phase-5 表格规定的覆盖确实存在（运行测试套件，并将覆盖率报告中的各模块数据与目标对照）。如果热力图标为 CRITICAL，但模块的分支覆盖率只有 40% 且没有 E2E 测试，那么这就是风险作秀。
• 变更频率信号是最新的： 重新运行 Phase-6 的变更频率命令；排名前 10 的任何模块如果 Probability 评分未达到 4 或以上，都说明模型已偏离实际情况。

完成标准

• 存在已评分的风险矩阵，并作为制品纳入版本控制（.agents/qa-project-context.md 的风险部分或已提交的 risk-matrix.md）；每项范围内功能都已按影响程度（1-5）和概率（1-5）评分
• 每项功能的综合评分都对应一个命名区域（CRITICAL、HIGH、MEDIUM 或 LOW），并分配了相应的测试行动
• 每项评分 ≥ 10 的功能都已完成故障模式分析，并记录触发条件、影响范围、检测方法、当前缓解措施和缺口
• 按区域划分的覆盖要求已与当前覆盖情况对照，每个缺口都分配了 Priority（P0-P3）、Owner 和 Target Sprint
• 在同一制品中记录了重新评估的触发条件和频率（至少每季度一次，并且在任何生产事故发生后 48 小时内重新评估）

参考文件（位于 references/ 中）

• examples.md — 四个完整评分的示例（结账、媒体平台、第三方 API、身份验证）：风险概况 → 故障模式 → 规定的覆盖。

相关技能

• test-strategy — 本风险矩阵所支撑的多季度 QA 策略；风险评估是整体策略的一项输入。
• test-planning — 单个冲刺/版本规划会使用风险优先级，决定本轮测试内容。
• release-readiness — 是否发布的决策会参考热力图，确认关键区域已覆盖。
• qa-metrics — 缺陷逃逸率和缺陷聚集情况会反馈到风险重新评估中。
• ai-system-testing — 构建评估套件，以缓解 Phase-3 中的 AI/LLM 故障类别。
• qa-project-context — 记录此技能所需的关键流程、脆弱区域和依赖项，并将风险矩阵写回其中。