在测试策略制定前用风险矩阵量化功能失效影响与概率…

当需要评估「什么可能出问题」、识别关键路径与失效模式、决定测试重点分配时，用影响×概率打分并映射测试密度。

适用场景

解决思路

1. 先检查 `.agents/qa-project-context.md` 是否存在，若存在则以其为基础，跳过其中已回答的问题，其余信息从工程、产品、运维等干系人处收集。
2. 通过干系人访谈收集发现性问题：收入关键流程（结账、订阅、计费、升级）、每小时的停机收入影响、时间敏感流程（闪购、交易时段、发薪截止）、带财务罚则的 SLA 流程。
3. 回顾最近失败：最近 3 个版本坏了什么、逃逸到生产的问题、根因（代码缺陷、配置错误、第三方故障、数据迁移）、每次事故的爆炸半径、以及测试后期才被发现的近失事件。
4. 识别脆弱区域：代码变更最频繁的部分（高 churn = 高风险）、当前测试覆盖最低的模块、业务逻辑最复杂或条件分支最多的区域、原作者已离职的代码。
5. 梳理第三方依赖：外部服务（支付处理、认证、CDN、API）、各依赖的历史可靠性、依赖宕机时的表现（优雅降级还是硬失败）、是否存在无回退的单点故障。
6. 梳理合规与数据：适用法规（GDPR、PCI-DSS、HIPAA、SOC2、SOX、EU AI Act）、最敏感数据（PII、财务、健康、凭证）、数据泄露或违规的法律后果、要求特定测试证据的审计要求。
7. 遵循核心原则：功能并非等价；风险 = 影响 × 概率；风险评估是持续性的；近失事件是数据；风险驱动覆盖而非相反。
8. Phase 1 风险识别：广泛枚举可能出错的事项，来源包括干系人访谈、事故历史（回顾过去 6–12 个月的事后复盘）、依赖映射、变更分析、架构评审（共享数据库、单点故障、同步链、紧耦合模块会放大爆炸半径）。
9. Phase 1 使用 HTSM v6.3（Heuristic Test Strategy Model, Bach）作为透镜，其基于状态和边界的启发式能发现纯功能清单遗漏的风险；下载：https://www.satisfice.com/download/heuristic-test-strategy-model。
10. Phase 1 输出：一份原始风险项清单，每项描述可能失败什么以及后果是什么。
11. Phase 2 风险分类：按影响轴打分——5 灾难性（收入损失、数据泄露、法律诉讼、用户安全）、4 重大（显著用户影响、SLA 违规、主要功能损坏）、3 中等（工作流中断、存在变通方案）、2 轻微（外观或轻微 UX 问题）、1 可忽略（无用户影响、仅内部）。
12. Phase 2 按概率轴打分——5 频繁（多数版本中预期发生；高 churn、无测试、复杂逻辑）、4 可能（一个季度内可能发生；近期变更、部分覆盖、已知技术债）、3 有可能（可能发生且曾发生过；中等复杂度、部分覆盖）、2 不太可能（概率低但非不可能；稳定代码、良好覆盖、简单逻辑）、1 罕见（需异常情况；测试充分、极少变更、简单）。
13. Phase 2 计算复合分 = 影响 × 概率；频繁变更代表缺陷概率，因此中等影响（3）但高 churn 的功能概率为 5 → 风险分 15 → CRITICAL 区，复合分而非仅影响驱动优先级。
14. Phase 3 失效模式分析：对每个高风险项（分数 ≥ 10）填写模板——Feature/Component、Risk Score、每个 Failure Mode 的 Trigger（触发原因）、Blast Radius（受影响用户/系统/数据）、Detection Method（如何发现：监控、用户报告、测试）、Current Mitigation（现有测试、监控、功能开关、回退）、Gap（当前缓解措施缺失什么）。
15. Phase 3 对 AI/LLM 功能按 CT-GenAI 类分类并独立打分：幻觉/推理错误（影响中到重大，无显式 prompt-eval 覆盖时概率高，用 golden-dataset evals 与事实核查断言检测）、偏见（在金融/医疗/招聘等受监管行业影响灾难性，概率取决于数据集，用反事实评估与人口统计均等检查检测）、prompt 注入/越狱（影响重大，任何对外 LLM 功能概率高，用 Garak、PyRIT、Promptfoo redteam 检测）、隐私泄露（GDPR/CCPA/EU AI Act 下影响灾难性，概率取决于数据集，用训练数据与 prompt 的 PII 扫描检测）、AI Act/监管不合规（影响灾难性，面向欧盟的 AI 功能概率高，见 compliance-testing）。
16. Phase 3 注意工具时效（2026 年中）：PyRIT 现位于 microsoft/PyRIT，旧 Azure 托管仓库已于 2026 年 3 月归档，新 redteam 工作不要指向旧 Azure 路径；Promptfoo 于 2026 年 3 月被 OpenAI 收购但仍为 MIT 许可；Garak 仍为当前且未变。
17. Phase 3 参考框架：CT-GenAI v1.1（ISTQB，2026 年 4 月 27 日生效）将上述 AI/LLM 类成文；WQR 2025-26（Capgemini，第 17 版，2025 年 11 月）给出 AI 风险规划的采用阶段框架。
18. Phase 4 风险热力图：将所有风险项绘制到 5×5 矩阵（影响 1–5 × 概率 1–5）以沟通优先级并驱动覆盖决策。
19. Phase 4 区域边界与行动映射：CRITICAL 15-25（红）——完全自动化 + 生产监控 + 负载测试 + 手动探索；HIGH 10-14（橙）——完全自动化 + 定期手动评审；MEDIUM 5-9（黄）——自动化 happy path + 关键错误用例；LOW 1-4（绿）——发布时手动测试或直接跳过。
20. Phase 5 测试覆盖对齐：按风险区规定测试密度——CRITICAL：单元 90%+ 分支覆盖、所有服务边界集成测试、完整用户旅程 + 错误路径 E2E、每次发布探索性测试、实时告警与合成检查；HIGH：单元 80%+ 分支覆盖、关键交互集成、happy path + 前 3 个错误路径 E2E、抽查、仪表盘 + 每日评审；MEDIUM：单元 70%+ 分支覆盖、仅 happy path 集成、仅 happy path E2E、重大变更时手动、每周评审；LOW：基本 happy path 单元、无需集成、无需 E2E、初次构建时手动、无需监控。
21. Phase 5 用 Gap Analysis Worksheet 对比当前覆盖与所需覆盖：记录 Feature、Risk Zone、Risk Score、Unit/Integration/E2E/Monitoring 的 Required、Current、Gap，以及 Priority（P0-P3）、Estimated Effort、Owner、Target Sprint。
22. Phase 5 当 churn 信号出现时强制打开该工作表：例如某模块 3 个月内变更 47 次（概率 → 5）但分支覆盖仅 40% 且无集成测试，则区域跃升（如 MEDIUM → HIGH），新覆盖目标由 churn 证明而非随意选取。
23. Phase 6 设定重评触发条件：每次生产事故后 48 小时内重评受影响项、检查依赖健康、重跑 Phase-5 差距分析以暴露事故揭示的覆盖缺口；引入新功能区域时；关键依赖变更时（API 版本、供应商切换）；团队构成显著变化时；至少每季度一次，即使无触发。
24. Phase 6 持续监控风险信号：用 `git log --since="3 months ago" --name-only --format= | grep -v '^$' | sort | uniq -c | sort -rn | head -20` 获取按模块的代码 churn 排名；用 issue 标签跟踪缺陷聚集（哪些模块产生最多 bug）；近失频率（staging/QA 多久阻止一次生产事故）；依赖健康（监控关键第三方服务的状态页与正常运行时间）；覆盖趋势（高风险区域的覆盖在升还是在降）。
25. 避免反模式：不要对所有功能同等测试（统一 90% 目标会浪费本应给支付或认证的精力）；不要一次性风险评估（6 个月前的模型已过时，需安排并强制执行重评）；不要忽视近失事件（staging 捕获的关键 bug 说明自动化安全网有缺口）；不要风险表演（填矩阵画热力图却不改变测试分配，需每季度验证对齐）；不要锚定历史风险（过度加权过去事故而低估新向量）；不要混淆严重性与优先级（用复合分而非仅影响）。
26. 验证矩阵真实且对齐：`git ls-files | grep -E 'risk-matrix|qa-project-context'` 返回文件（未跟踪的草稿不算风险模型）；grep 产物中缺少影响或概率数字的行（有名字无分数是缺口而非低风险）；每个 ≥ 10 的项都有含全部五个字段（Trigger、Blast Radius、Detection Method、Current Mitigation、Gap）的失效模式块（Gap 为空说明未真正分析）；对每个 CRITICAL/HIGH 功能确认 Phase-5 表规定的覆盖确实存在（运行套件、对照目标检查覆盖率报告的按模块数字）；重跑 Phase-6 churn 命令，前 10 中任何未评为概率 ≥ 4 的模块说明模型已偏离现实。
27. 完成标准：存在已跟踪的打分风险矩阵（`.agents/qa-project-context.md` 风险段或提交的 `risk-matrix.md`），每个在范围内功能都按影响（1-5）与概率（1-5）打分；每个功能的复合分落入命名区域（CRITICAL、HIGH、MEDIUM、LOW）并分配对应测试行动；每个 ≥ 10 的功能都有完整失效模式分析；按区域的覆盖要求已对照当前覆盖映射，每个缺口分配 Priority（P0-P3）、Owner、Target Sprint；重评触发条件与节奏记录在同一产物中（至少每季度，外加任何生产事故后 48 小时内）。

适用边界 · 注意事项

• 不要用于制定多季度 QA 方向——那用 test-strategy。
• 不要用于单个 sprint/发布的测试计划——那用 test-planning。
• 不要用于动手的基于会话的缺陷挖掘——那用 exploratory-testing。