risk-based-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<objective> Equal coverage across all features wastes effort on low-risk areas while leaving critical paths under-tested — a 90% coverage target on a settings page is effort stolen from checkout. This skill discovers risk, quantifies it as impact × probability, maps test density to risk zones, and keeps the assessment current as the product evolves. Output is a scored risk matrix that feeds `test-strategy` and `test-planning`. </objective>

<objective> 对所有功能采用均等测试覆盖率会导致低风险区域耗费不必要的精力，同时关键路径测试不足——比如给设置页面设定90%的覆盖率目标，会占用本该投入到结账流程的测试资源。本技能用于识别风险，通过影响×概率的方式量化风险，将测试密度映射到风险区域，并随着产品迭代持续更新评估结果。输出为带有评分的风险矩阵，可为`test-strategy`和`test-planning`提供输入。 </objective>

Quick Route

快速路径

Situation	Start at
New product, no risk model yet	Phase 1 (Identification) → run the full 6 phases
Post-incident reassessment	Phase 6 (Reassessment triggers), then re-score the affected items in Phase 2
AI/LLM feature to assess	Phase 3 (AI/LLM failure classes), score each class in Phase 2
Sprint refresh of an existing matrix	Phases 4–5 (Heatmap + Coverage alignment) on changed features
Verify an old heatmap is still true	Phase 6 signals + Anti-Pattern "Risk Theater"

场景	起始阶段
新产品，尚无风险模型	阶段1（识别）→ 完整执行6个阶段
事件后重新评估	阶段6（重新评估触发条件），然后在阶段2重新评估受影响项的评分
评估AI/LLM功能	阶段3（AI/LLM失效类别），在阶段2为每个类别评分
迭代现有矩阵的敏捷刷新	针对变更功能执行阶段4–5（热力图 + 覆盖率对齐）
验证旧热力图是否仍有效	阶段6触发信号 + 反模式“风险形式主义”

Discovery Questions

调研问题

Check

.agents/qa-project-context.md

first — if it exists, use it as the foundation and skip questions already answered there. Gather the rest from stakeholders across engineering, product, and operations.

首先查看

.agents/qa-project-context.md

——如果存在，以此为基础，跳过已回答的问题。从工程、产品和运营部门的利益相关者处收集剩余信息。

Revenue-Critical Flows

营收关键流程

Which user flows directly generate revenue? (checkout, subscription, billing, upgrades)
What is the revenue impact per hour of downtime for each flow?
Are there time-sensitive flows? (flash sales, market-hours trading, payroll deadlines)
Which flows have contractual SLAs with financial penalties?

哪些用户流程直接产生营收？（结账、订阅、计费、升级）
每个流程每小时停机的营收影响是多少？
是否存在时间敏感型流程？（限时促销、市场交易时段、薪资发放截止日）
哪些流程带有含财务处罚的合同SLA？

Recent Failures

近期故障

What broke in the last 3 releases? What escaped to production?
What were the root causes? (code defect, config error, third-party failure, data migration)
What was the blast radius of each incident? (users affected, revenue lost, reputation impact)
Were there near-misses caught late in testing that could have escaped?

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

Fragile Areas

脆弱区域

Which parts of the codebase change most frequently? (high churn = high risk)
Which modules have the lowest test coverage today?
Which areas have the most complex business logic or the most conditional branches?
Which code was written by engineers who have since left the team?

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

Third-Party Dependencies

第三方依赖

Which external services does the product depend on? (payment processors, auth providers, CDNs, APIs)
What is the historical reliability of each dependency?
What happens when each dependency goes down? (graceful degradation or hard failure?)
Are there single points of failure with no fallback?

产品依赖哪些外部服务？（支付处理器、认证提供商、CDN、API）
每个依赖的历史可靠性如何？
每个依赖宕机时会发生什么？（优雅降级还是直接故障？）
是否存在无 fallback 的单点故障？

Compliance and Data

合规与数据

What regulatory requirements apply? (GDPR, PCI-DSS, HIPAA, SOC2, SOX, EU AI Act)
What data is most sensitive? (PII, financial, health, credentials)
What are the legal consequences of a data breach or compliance violation?
Are there audit requirements that mandate specific testing evidence?

适用哪些监管要求？（GDPR、PCI-DSS、HIPAA、SOC2、SOX、欧盟AI法案）
哪些数据最敏感？（PII、财务数据、健康数据、凭证）
数据泄露或合规违规的法律后果是什么？
是否存在要求特定测试证据的审计要求？

Core Principles

核心原则

Not all features are equal. A bug in checkout that blocks purchases is categorically different from a misaligned icon on a settings page. Equal coverage everywhere wastes resources on low-risk areas while leaving critical paths under-tested.
Risk = Impact × Probability. Risk is not a gut feeling. It is a product of two dimensions scored independently: how bad if this fails (impact), and how likely to fail (probability). Score both consistently across the product, then multiply.
Risk assessment is continuous. A risk model created once and never updated creates false confidence. Risk changes when the product changes, when dependencies change, when the team changes, and after every production incident. Build reassessment into the rhythm.
Near-misses are data. A catastrophic bug caught in staging is not a success story — it is a signal that the model underestimated that area. Track near-misses with the same rigor as production incidents.
Risk informs coverage, not the other way around. Do not start with "we need 80% coverage everywhere." Start with "where would a failure hurt most?" and let the model drive coverage targets per module.

并非所有功能都同等重要。结账流程中阻止用户下单的bug，与设置页面图标对齐错误的bug完全不同。对所有区域采用均等覆盖率会浪费资源在低风险区域，同时导致关键路径测试不足。
风险=影响×概率。风险不是直觉判断，而是两个独立评分维度的乘积：故障的严重程度（影响），以及故障发生的可能性（概率）。在全产品范围内统一对两者评分，再相乘得到风险值。
风险评估是持续的。一次性创建后从未更新的风险模型会带来虚假的安全感。当产品、依赖、团队发生变化，或每次生产事件后，风险都会改变。需将重新评估纳入团队工作节奏。
险些发生的故障也是数据。在预发环境发现的严重bug不是成功案例——这是模型低估了该区域风险的信号。需像跟踪生产事件一样严格跟踪险些发生的故障。
风险决定覆盖率，而非反之。不要从“我们需要所有区域达到80%覆盖率”开始，而是从“故障影响最大的区域在哪里？”入手，让模型驱动各模块的覆盖率目标。

Workflow

工作流程

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. 识别 → 2. 分类 → 3. 分析 → 4. 热力图 → 5. 覆盖率 → 6. 重新评估 → (重复)
                                 ↑
                       仅评分≥10的项执行；若无项达到阈值则跳过至第4步

Phase 1: Risk Identification

阶段1：风险识别

Enumerate everything that could go wrong. Cast a wide net. Sources include:

Stakeholder interviews: Product managers know business-critical flows. Engineers know fragile code. Support knows recurring user complaints.
Incident history: Past failures predict future failures. Review post-mortems from the last 6–12 months.
Dependency mapping: List every external service, database, message queue, and third-party API. Each is a risk vector.
Change analysis: Areas with frequent code changes have higher defect probability. Use the ranked churn command in Phase 6 to find them;
```
git log --stat <file>
```
is for per-commit inspection of a specific suspect, not for ranking.
Architecture review: Shared databases, single points of failure, synchronous chains, and tightly coupled modules amplify blast radius.

Use HTSM v6.3 (Heuristic Test Strategy Model, Bach) as a Phase-1 lens — its state-based and boundary heuristics surface risks a pure feature-list misses. Download: https://www.satisfice.com/download/heuristic-test-strategy-model

Output: a raw list of risk items, each describing what could fail and what the consequence would be.

列举所有可能出现的故障，尽可能全面。信息来源包括：

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

使用HTSM v6.3（启发式测试策略模型，Bach）作为阶段1的分析框架——其基于状态和边界的启发式方法能发现纯功能列表遗漏的风险。下载地址：https://www.satisfice.com/download/heuristic-test-strategy-model

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

Phase 2: Risk Classification

阶段2：风险分类

Categorize each risk item along two axes.

Impact categories (how bad is it):

Score	Level	Definition	Examples
5	Catastrophic	Revenue loss, data breach, legal action, user safety	Payment processing fails, PII exposed
4	Major	Significant user impact, SLA violation, major feature broken	Login broken for segment, data corruption
3	Moderate	Workflow disrupted, workaround exists	Search returns wrong results, export fails
2	Minor	Cosmetic or minor UX issue	Alignment bug, slow non-critical page
1	Negligible	No user impact, internal only	Admin tooltip wrong, log format issue

Probability categories (how likely is it):

Score	Level	Definition	Indicators
5	Frequent	Expected in most releases	High code churn, no tests, complex logic
4	Likely	Will probably happen within a quarter	Recent changes, partial coverage, known tech debt
3	Possible	Could happen, has happened before	Moderate complexity, some coverage
2	Unlikely	Improbable but not impossible	Stable code, good coverage, simple logic
1	Rare	Requires exceptional circumstances	Well-tested, rarely changed, simple

Composite score = Impact × Probability. Frequent changes indicate defect probability, so a Moderate-impact (3) feature under heavy churn scores Probability 5 → Risk score: 15 → CRITICAL zone, despite "only" moderate impact. The composite score drives priority, not impact alone.

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

影响类别（故障严重程度）：

评分	级别	定义	示例
5	灾难性	营收损失、数据泄露、法律诉讼、用户安全问题	支付处理失败、PII泄露
4	重大	严重用户影响、SLA违规、核心功能故障	特定用户群体登录失败、数据损坏
3	中等	工作流程中断，但存在替代方案	搜索返回错误结果、导出功能失败
2	轻微	界面美观或次要UX问题	对齐bug、非关键页面加载缓慢
1	可忽略	无用户影响，仅内部可见	管理端提示错误、日志格式问题

概率类别（故障发生可能性）：

评分	级别	定义	指标
5	频繁	大多数版本中都会出现	代码变更率高、无测试、逻辑复杂
4	可能	大概率在一个季度内发生	近期变更、部分覆盖、已知技术债务
3	有可能	可能发生，且之前发生过	中等复杂度、有一定覆盖率
2	unlikely	不太可能但并非完全不可能	代码稳定、覆盖率良好、逻辑简单
1	罕见	需要特殊条件才会发生	测试充分、极少变更、逻辑简单

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

Phase 3: Failure Mode Analysis

阶段3：失效模式分析

For each high-risk item (score ≥ 10), perform a detailed failure mode analysis.

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: ...

Example — E-commerce Checkout (Risk Score 20, Impact 5 × Probability 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

对每个高风险项（评分≥10）执行详细的失效模式分析。

功能/组件: [名称]
风险评分: [影响×概率]

失效模式1: [具体故障表现]
  触发条件:            [导致故障的原因]
  影响范围:       [受影响用户、系统、数据]
  检测方式:   [如何发现——监控、用户反馈、测试]
  当前缓解措施: [现有测试、监控、功能开关、 fallback]
  缺口:                [当前缓解措施缺失的部分]

失效模式2: ...

示例——电商结账流程（风险评分20，影响5×概率4）：

失效模式1: 支付扣费成功但订单未记录
  触发条件:            支付API回调与订单写入之间的竞态条件
  影响范围:       单个用户；已扣费但无订单确认
  检测方式:   支付对账任务（每小时运行）、用户投诉
  当前缓解措施: 支付请求的幂等键、订单写入重试机制
  缺口:                无针对该竞态条件的自动化测试；对账延迟1小时

失效模式2: 折扣码计算金额错误
  触发条件:            已打折商品叠加百分比折扣
  影响范围:       所有使用叠加折扣的用户；营收流失
  检测方式:   利润率监控警报（偏差>5%）
  当前缓解措施: 单一折扣的单元测试
  缺口:                无叠加折扣测试；无 rounding 边界用例测试

失效模式3: 结账时未预留库存
  触发条件:            最后一件商品被同时下单
  影响范围:       超卖商品、履约失败、用户信任受损
  检测方式:   履约团队在打包时发现
  当前缓解措施: 订单创建时数据库级库存检查
  缺口:                无模拟并发抢购最后一件商品的负载测试

AI/LLM failure classes

AI/LLM失效类别

For AI/LLM features, classify against these CT-GenAI classes and score Impact and Probability independently like any other risk. The mitigation is the existence of an automated eval suite, not a single manual test.

AI/LLM-specific failure classes (from ISTQB CT-GenAI v1.1, effective 27 April 2026):
Hallucination / reasoning error — Impact: moderate to major; Probability: high without explicit prompt-eval coverage. Detection: golden-dataset evals, fact-check assertions (see
ai-system-testing
).
Bias — Impact: catastrophic in regulated industries (finance, healthcare, hiring). Probability: dataset-dependent. Detection: counterfactual evals, demographic-parity checks.

Prompt injection / jailbreak — Impact: major (data exfiltration, prompt extraction). Probability: high for any externally-facing LLM feature. Detection: Garak, PyRIT, Promptfoo redteam.

Privacy leak — Impact: catastrophic under GDPR/CCPA/EU AI Act. Probability: dataset-dependent. Detection: PII scanning of training data and prompts.
AI Act / regulatory non-compliance — Impact: catastrophic (fines, ban). Probability: high for EU-facing AI features. Detection: see
compliance-testing
.
Tool freshness (mid-2026): PyRIT now lives at microsoft/PyRIT — the old Azure-hosted repo was archived March 2026, so do not point new redteam work at the legacy Azure path. Promptfoo was acquired by OpenAI (March 2026) but remains MIT-licensed. Garak is current and unchanged.

Reference frameworks: CT-GenAI v1.1 (ISTQB, effective 27 April 2026) codifies the AI/LLM classes above. WQR 2025-26 (Capgemini, 17th edition, Nov 2025) gives the adoption-stage framing for AI risk planning.

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

AI/LLM特定失效类别（来自ISTQB CT-GenAI v1.1，2026年4月27日生效）：
幻觉/推理错误 — 影响：中等至重大；概率：若无明确提示评估覆盖则较高。检测：黄金数据集评估、事实核查断言（参见
ai-system-testing
）。
偏见 — 影响：在受监管行业（金融、医疗、招聘）中为灾难性。概率：取决于数据集。检测：反事实评估、人口平等检查。

提示注入/越狱 — 影响：重大（数据泄露、提示提取）。概率：任何面向外部的LLM功能概率都较高。检测：Garak、PyRIT、Promptfoo红队工具。

隐私泄露 — 影响：在GDPR/CCPA/欧盟AI法案下为灾难性。概率：取决于数据集。检测：训练数据和提示的PII扫描。
AI法案/合规违规 — 影响：灾难性（罚款、禁令）。概率：面向欧盟的AI功能概率较高。检测：参见
compliance-testing
。
工具更新（2026年中）：PyRIT现托管于microsoft/PyRIT——旧Azure托管仓库已于2026年3月归档，请勿将新红队工作指向旧Azure路径。Promptfoo于2026年3月被OpenAI收购，但仍保持MIT许可证。Garak当前无变化。

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

Phase 4: Risk Heatmap

阶段4：风险热力图

Plot all risk items on a 5×5 matrix to communicate priorities and drive coverage decisions.

                    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   |
                   +----------+-----------+-----------+----------+-----------+

Zone boundaries and action mapping:

Zone	Score Range	Color	Testing Action
CRITICAL	15-25	Red	Automate fully + monitor in production + load test + manual exploratory
HIGH	10-14	Orange	Automate fully + periodic manual review
MEDIUM	5-9	Yellow	Automate happy path + key error cases
LOW	1-4	Green	Manual testing on release or skip entirely

Populated example (where each named risk lands):

                    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×5矩阵上，以传达优先级并指导覆盖率决策。

                    概率
                    罕见(1)   不太可能(2)  有可能(3)  可能(4)   频繁(5)
                   +----------+-----------+-----------+----------+-----------+
  灾难性(5)  |  5  中等  | 10  高  | 15  关键  | 20 关键  | 25  关键  |
                   +----------+-----------+-----------+----------+-----------+
  重大(4)         |  4  低  |  8  中等   | 12  高  | 16 关键  | 20  关键  |
影                  +----------+-----------+-----------+----------+-----------+
响  中等(3)     |  3  低  |  6  中等   |  9  中等   | 12 高  | 15  关键  |
                  +----------+-----------+-----------+----------+-----------+
  轻微(2)        |  2  低  |  4  低   |  6  中等   |  8 中等   | 10  高  |
                  +----------+-----------+-----------+----------+-----------+
  可忽略(1)   |  1  低  |  2  低   |  3  低   |  4 低   |  5  中等   |
                   +----------+-----------+-----------+----------+-----------+

区域边界与行动映射：

区域	评分范围	颜色	测试行动
关键	15-25	红色	全自动化测试 + 生产环境监控 + 负载测试 + 手动探索性测试
高	10-14	橙色	全自动化测试 + 定期手动评审
中等	5-9	黄色	自动化主流程 + 关键错误场景
低	1-4	绿色	版本发布时手动测试或完全跳过

填充示例（各风险项的位置）：

                    罕见(1)   不太可能(2)  有可能(3)  可能(4)   频繁(5)
  灾难性(5)             认证绕过   支付失败  结账崩溃
  重大(4)                                  数据导出    搜索失效  用户上传
  中等(3)                  报告格式    邮件投递  资料编辑
  轻微(2)         页脚链接  提示文本  主题切换
  可忽略(1)    管理端标签

Phase 5: Test Coverage Alignment

阶段5：测试覆盖率对齐

Map test density to risk level. Every zone gets a prescribed approach.

Risk Zone	Unit Tests	Integration Tests	E2E Tests	Manual Testing	Monitoring
CRITICAL (15-25)	90%+ branch coverage	All service boundaries	Full user journey + error paths	Exploratory each release	Real-time alerts, synthetic checks
HIGH (10-14)	80%+ branch coverage	Key interactions	Happy path + top 3 error paths	Spot checks	Dashboard + daily review
MEDIUM (5-9)	70%+ branch coverage	Happy path only	Happy path only	On major changes	Weekly review
LOW (1-4)	Basic happy path	None required	None required	On initial build	None required

将测试密度与风险等级映射，每个区域对应特定的测试方法。

风险区域	单元测试	集成测试	E2E测试	手动测试	监控
关键（15-25）	分支覆盖率90%+	覆盖所有服务边界	完整用户旅程 + 错误路径	每个版本执行探索性测试	实时告警、 synthetic checks
高（10-14）	分支覆盖率80%+	关键交互覆盖	主流程 + 前3个错误路径	抽查	仪表盘 + 每日评审
中等（5-9）	分支覆盖率70%+	仅主流程	仅主流程	重大变更时测试	每周评审
低（1-4）	基础主流程	无需	无需	初始构建时测试	无需

Gap Analysis Worksheet

缺口分析工作表

Compare current coverage against required coverage per risk zone:

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]

A churn signal forces this worksheet open: a module that changed 47 times in 3 months (Probability → 5) with only 40% branch coverage and no integration tests jumps zones (e.g. MEDIUM → HIGH), and the new coverage target is justified by the churn, not picked arbitrarily.

See

references/examples.md

for four fully-scored examples (checkout, media platform, third-party API, auth) showing the path from risk score to prescribed coverage.

对比当前覆盖率与各风险区域的要求覆盖率：

功能: [名称]
风险区域: [关键 / 高 / 中等 / 低]      风险评分: [数值]

要求覆盖率:
  单元测试:        [目标百分比]     当前: [实际百分比]     缺口: [差值]
  集成测试: [是否需要]    当前: [是否存在? 是/否]  缺口: [缺失场景]
  E2E测试:         [是否需要]    当前: [是否存在? 是/否]  缺口: [缺失流程]
  监控:  [是否需要]    当前: [是否存在? 是/否]  缺口: [缺失告警]

优先级: [P0 / P1 / P2 / P3]
预估工作量: [小时 / 故事点]
负责人: [姓名]                目标迭代: [迭代编号]

变更率信号会触发此工作表：3个月内变更47次的模块（概率→5），仅40%分支覆盖率且无集成测试，会提升风险等级（例如从中等→高），新的覆盖率目标由变更率证明合理，而非随意设定。

查看

references/examples.md

获取四个完整评分示例（结账、媒体平台、第三方API、认证），展示从风险评分到指定覆盖率的全过程。

Phase 6: Monitoring and Reassessment

阶段6：监控与重新评估

Risk assessment is not a one-time activity. Build reassessment into the team's rhythm.

Reassessment triggers:

After every production incident (within 48 hours): re-score the affected items, check dependency health, and re-run the Phase-5 gap analysis to expose any coverage gap the incident revealed
When a new feature area is introduced
When a critical dependency changes (API version, provider switch)
When team composition changes significantly
Quarterly at minimum, even without triggers

Continuous risk signals to monitor:

Code churn by module (ranked frequency table):

bash

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

Defect clustering: Which modules produce the most bugs? Track with issue labels.
Near-miss frequency: How often do staging/QA catches prevent production incidents?
Dependency health: Monitor status pages and uptime of critical third-party services.
Coverage trends: Is coverage increasing or decreasing in high-risk areas?

风险评估不是一次性活动，需将重新评估纳入团队工作节奏。

重新评估触发条件：

每次生产事件后（48小时内）：重新评估受影响项的评分，检查依赖健康状况，重新执行阶段5的缺口分析，暴露事件揭示的任何覆盖率缺口
引入新功能区域时
关键依赖变更时（API版本、提供商切换）
团队组成发生重大变化时
至少每季度一次，即使无触发条件

需持续监控的风险信号：

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

bash

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

缺陷聚类：哪些模块产生的bug最多？通过issue标签跟踪。
险些发生的故障频率：预发/QA环境多少次阻止了生产事件？
依赖健康状况：监控关键第三方服务的状态页面和可用性。
覆盖率趋势：高风险区域的覆盖率是上升还是下降？

Anti-Patterns

反模式

Testing everything equally

均等测试所有功能

Applying the same coverage target to every feature regardless of risk. A 90% target on a settings page wastes effort that should go to payments or auth. Let the risk model drive allocation.

不考虑风险，对所有功能应用相同的覆盖率目标。给设置页面设定90%的目标会浪费本该投入到支付或认证流程的精力。应由风险模型决定资源分配。

One-time risk assessment

一次性风险评估

Creating a matrix during planning and never updating it. The product, team, and dependencies all change. A model from 6 months ago is outdated and out of date the moment a dependency, feature, or incident shifts the picture — it does not reflect today. Schedule reassessment and enforce it.

规划阶段创建矩阵后从未更新。产品、团队和依赖都会变化。6个月前的模型在依赖、功能或事件发生变化的那一刻就已过时——无法反映当前情况。需安排重新评估并强制执行。

Ignoring near-misses

忽略险些发生的故障

Treating bugs caught in staging as pure successes. If a critical bug was caught only by manual testing, the automated safety net has a gap. Document near-misses and adjust the model.

将预发环境发现的bug视为纯粹的成功。如果严重bug仅通过手动测试发现，说明自动化安全网存在缺口。需记录险些发生的故障并调整模型。

Risk theater

风险形式主义

Going through the motions (filling matrices, drawing heatmaps) without changing test allocation. If the heatmap exists but coverage does not align to it, the exercise was wasted. Verify alignment quarterly. Bolton's "Quality Engineering Is Not Testing" (2026-04-20) warns of exactly this — building a heatmap and calling it "QE done." Reference: https://developsense.com/blog/2026/04/quality-engineering-is-not-testing

走流程（填写矩阵、绘制热力图）但不改变测试资源分配。如果热力图存在但覆盖率未与之对齐，那么这项工作就是浪费。需每季度验证对齐情况。Bolton在《Quality Engineering Is Not Testing》（2026-04-20）中专门警告了这种情况——绘制热力图就宣称“QE完成”。参考链接：https://developsense.com/blog/2026/04/quality-engineering-is-not-testing

Anchoring on historical risk

锚定历史风险

Over-weighting past incidents and under-weighting new vectors. A module that failed 2 years ago and was since rewritten may no longer be high risk; a brand-new third-party integration has unknown risk that deserves attention.

过度重视过去的事件，而低估新的风险因素。2年前故障但已重写的模块可能不再是高风险；全新的第三方集成存在未知风险，值得关注。

Confusing severity with priority

将严重程度与优先级混淆

Severity is how bad a failure is; priority is how urgently to test it. A catastrophic-but-rare failure (earthquake destroys data center) can be lower priority than a moderate-but-frequent one (search occasionally wrong). Use the composite score, not impact alone.

严重程度是故障的影响大小；优先级是测试的紧急程度。灾难性但罕见的故障（地震摧毁数据中心）优先级可能低于中等但频繁发生的故障（搜索偶尔出错）。需使用综合评分，而非仅看影响。

Verification

验证

Prove the matrix is real and aligned before calling it done — smallest check first:

Artifact exists and is tracked:
```
git ls-files | grep -E 'risk-matrix|qa-project-context'
```
returns the file. An untracked draft on someone's laptop is not a risk model.
Every in-scope feature is scored: grep the artifact for rows missing an impact or probability number. A feature with a name but no score is a gap, not a low risk.
Top items have failure mode analysis: every item scoring ≥ 10 has a block with all five fields (Trigger, Blast Radius, Detection Method, Current Mitigation, Gap). A failure mode with an empty Gap line was not actually analyzed.
Coverage aligns to the heatmap: for each CRITICAL/HIGH feature, confirm the prescribed coverage from the Phase-5 table actually exists (run the suite, check the coverage report's per-module numbers against the target). If the heatmap says CRITICAL but the module has 40% branch coverage and no E2E, the exercise was Risk Theater.
Churn signal is current: re-run the Phase-6 churn command; any module in the top 10 that is not scored ≥ Probability 4 is a model that has drifted from reality.

在完成前证明矩阵真实且对齐——从最小检查开始：

工件存在且被跟踪：
```
git ls-files | grep -E 'risk-matrix|qa-project-context'
```
返回文件。保存在某台笔记本上的未跟踪草稿不是风险模型。
所有范围内的功能都已评分：在工件中查找缺少影响或概率评分的条目。只有名称但无评分的功能是缺口，而非低风险。
高优先级项有失效模式分析：每个评分≥10的项都包含完整的五个字段（触发条件、影响范围、检测方式、当前缓解措施、缺口）。缺口字段为空的失效模式未真正完成分析。
覆盖率与热力图对齐：对每个关键/高风险功能，确认阶段5表格中指定的覆盖率实际存在（运行测试套件，检查覆盖率报告的模块级数据是否符合目标）。如果热力图显示为关键区域，但模块仅40%分支覆盖率且无E2E测试，那么这项工作就是风险形式主义。
变更率信号是最新的：重新运行阶段6的变更率命令；前10名中的任何模块如果概率评分未≥4，说明模型已偏离实际情况。

Done When

完成标准

A scored risk matrix exists as a tracked artifact (
```
.agents/qa-project-context.md
```
risk section or a committed
```
risk-matrix.md
```
), with every in-scope feature scored on impact (1-5) and probability (1-5)
Each feature's composite score places it in a named zone (CRITICAL, HIGH, MEDIUM, or LOW) with a corresponding testing action assigned
Every feature scoring ≥ 10 has a completed failure mode analysis with trigger, blast radius, detection method, current mitigation, and gap documented
Coverage requirements per zone are mapped against current coverage, with each gap assigned a Priority (P0-P3), an Owner, and a Target Sprint
Reassessment triggers and cadence are recorded in the same artifact (quarterly minimum, plus within 48 hours of any production incident)

存在作为跟踪工件的带评分风险矩阵（
```
.agents/qa-project-context.md
```
的风险部分或已提交的
```
risk-matrix.md
```
），所有范围内的功能都已按影响（1-5）和概率（1-5）评分
每个功能的综合评分将其归入指定区域（关键、高、中等或低），并分配了相应的测试行动
每个评分≥10的功能都已完成失效模式分析，记录了触发条件、影响范围、检测方式、当前缓解措施和缺口
已按区域映射覆盖率要求与当前覆盖率，每个缺口都分配了优先级（P0-P3）、负责人和目标迭代
重新评估触发条件和节奏已记录在同一工件中（至少每季度一次，加上生产事件后48小时内）

Reference Files (in

references/

)

参考文件（位于

references/

）

examples.md — Four fully-scored worked examples (checkout, media platform, third-party API, auth): risk profile → failure modes → prescribed coverage.

examples.md — 四个完整评分的示例（结账、媒体平台、第三方API、认证）：风险概况 → 失效模式 → 指定覆盖率。