---
name: qa-risk-intuition
description: >-
  识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型：变更/业务/技术/数据/集成五大风险信号雷达，量化打分后按等级分配测试深度与资源。每个风险点带唯一 ID（RISK-{模块}-{风险类型}-{序号}）。
  触发场景：风险评估、优先级、哪里风险高、风险信号、测试重点、资源分配、高优测试、需要判断测试重点、测试资源有限需要聚焦时。 Use when the user asks about: identifying high-risk areas that look simple — frequently changed modules, third-party dependencies, money and security paths, and historical defect hotspots.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "Risk Intuition"
  version: "1.8.0"
  when-to-use: "用户说\"风险评估\"、\"优先级\"、\"哪里风险高\"、\"风险信号\"、\"测试重点\"、\"资源分配\"、\"高优测试\"、需要判断测试重点、测试资源有限需要聚焦时"
  related-skills: "{\"upstream\":[\"qa-req-deconstruction\"],\"downstream\":[\"qa-test-estimation\",\"qa-test-strategy-design\",\"qa-req-deconstruction\",\"qa-ai-context-engineering\",\"qa-agent-testing\",\"qa-api-testing\",\"qa-mobile-testing\",\"qa-bug-lifecycle\",\"qa-release-risk-governance\",\"qa-test-env-data\",\"qa-test-data-engineering\",\"qa-expert-review\"]}"
  references: "[\"references/risk-signals.md\",\"assets/risk-matrix.md\"]"
  input-format: "{\"required\":[{\"name\":\"功能模块\",\"type\":\"string\",\"description\":\"待评估的功能或变更范围\"}],\"optional\":[{\"name\":\"变更说明\",\"type\":\"string\",\"description\":\"本次变更内容（触发变更信号雷达）\"},{\"name\":\"历史缺陷\",\"type\":\"array\",\"description\":\"同类功能的历史缺陷模式\"}]}"
  output-format: "{\"traceability\":[\"每个风险点带唯一ID：RISK-{模块缩写}-{风险类型}-{三位序号}\",\"风险类型取自 docs/standards.md：STOCK/CALC/CONC/TIME/DATA/SEC/PERF/VAL/PAY\",\"关联需求ID：REQ-{需求模块缩写}-{序号}\"],\"structure\":[{\"risk_matrix\":\"风险评估表：风险ID|功能模块|业务影响|发生概率|技术复杂度|风险分数|风险等级|测试深度\"},{\"risk_report\":\"风险评估报告：按高/中/低三组列出风险点 + 资源分配建议\"},\"评分：业务影响 × 发生概率 × 技术复杂度，三因子各取 1/3/5，取值域 1-125\",\"阈值：≥45 高（深测）/ 15-44 中（常规）/ ≤14 低（冒烟）——全项目唯一定义，见 assets/risk-matrix.md\",\"本技能不产出 9 列用例表 —— 风险点转换为用例由 qa-test-case-design 完成\",\"覆盖率：标注口径（基于当前评估范围），禁止\\\"全覆盖/100%\\\"绝对化表述\"]}"
  error-recovery-guidance: "{\"on_failure\":\"风险信号扫描遗漏维度时回退到需求解构补充上下文\",\"retry_behavior\":\"补充上下文后重新扫描风险信号\"}"
  categories: "[\"Development\",\"Testing\"]"
  depth-requirement: "{\"reference_value\":\"每个功能模块至少识别 5 个风险点\",\"minimum\":\"五大信号雷达（变更/业务/技术/数据/集成）全部扫过；未覆盖的信号维度必须标注原因\"}"
---

> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

# 测试风险直觉

## 核心原则

有经验的测试看到某些变更会本能地警觉——**这不是玄学，是可以结构化的信号模型**。

信号雷达扫出风险点 → 量化打分 → 按等级分配测试深度与资源。

## 1. 五大风险信号（速查）

| 信号 | 问什么 | 典型高危特征 |
|------|--------|-------------|
| **变更信号** | 改了什么？多久改一次？ | 频繁变更的模块、核心链路上的改动 |
| **业务影响** | 出问题谁受损？ | 资金、安全、核心链路 |
| **技术复杂度** | 实现有多难？ | 并发、状态流转、分布式 |
| **数据风险** | 数据会怎样错？ | 迁移、对账、一致性、精度 |
| **集成风险** | 依赖谁？ | 第三方服务、外部支付/消息队列 |

> 五大信号的全量子项与检查清单见 `references/risk-signals.md`。
> **每个功能模块至少识别 5 个风险点**。

## 2. 评分与阈值（全项目唯一定义）

```
风险分数 = 业务影响 × 发生概率 × 技术复杂度
```

| 因子 | 1 分 | 3 分 | 5 分 |
|------|------|------|------|
| 业务影响 | 内部工具/文档 | 内部管理/辅助功能 | **资金/安全/核心链路** |
| 发生概率 | 很少出问题 | 偶尔出问题 | 经常出问题 |
| 技术复杂度 | 简单 CRUD/静态展示 | 复杂规则/数据转换 | **并发/状态/分布式** |

三因子各取 1/3/5，**取值域 1–125**。

| 风险分数 | 等级 | 测试深度 | 资源占比（起步） |
|---------|------|---------|----------------|
| **≥ 45** | 高 | 深测 | ~60%（资深测试） |
| **15 – 44** | 中 | 常规 | ~30%（初中级） |
| **≤ 14** | 低 | 冒烟 | ~10%（自动化） |

> **历史修正**：本技能此前同时存在 `≥15/8-14/≤7` 与 `≥75/25-74/≤24` 两套阈值，
> 输出示例还用了第三套 10 分制（`10×8×7=560`）——三者量纲不一致且互相矛盾。
> 现统一为上表一套。

## 3. 加载时机

| 什么时候读 | 读哪个 |
|-----------|--------|
| 展开五大信号的全量子项 | [`references/risk-signals.md`](references/risk-signals.md) |
| 写风险评估表或按等级分组的报告 | [`assets/risk-matrix.md`](assets/risk-matrix.md)（评分表 + 报告模板 + 填写要求 + 自检） |

## 4. 产出

**风险评估表**：

| 风险 ID | 功能模块 | 业务影响 | 发生概率 | 技术复杂度 | 风险分数 | 风险等级 | 测试深度 |
|---------|---------|---------|---------|-----------|---------|---------|---------|
| RISK-PAY-CONC-002 | 支付/并发回调 | 5 | 5 | 5 | 125 | 高 | 深测 |
| RISK-PAY-STOCK-001 | 支付/库存扣减 | 5 | 3 | 5 | 75 | 高 | 深测 |
| RISK-ORDER-EXPORT-005 | 订单/导出 | 3 | 3 | 3 | 27 | 中 | 常规 |
| RISK-NOTIFY-PUSH-004 | 通知/推送 | 1 | 3 | 1 | 3 | 低 | 冒烟 |

风险类型：`STOCK` 库存 / `CALC` 计算 / `CONC` 并发 / `TIME` 时序 / `DATA` 数据 /
`SEC` 安全 / `PERF` 性能 / `VAL` 校验 / `PAY` 支付

> 完整报告模板（按高/中/低分组 + 资源分配建议）见 `assets/risk-matrix.md`。
> **本技能不产出 9 列用例表**——风险点转用例由 `qa-test-case-design` 完成。

## 5. 好示例 vs 坏示例

**好**：支付网关替换
```text
✓ 变更类型：支付网关替换（高风险）
  - 业务影响：资金相关，影响所有交易（5）
  - 发生概率：第三方 SDK 替换，历史上回调格式出过问题（5）
  - 技术复杂度：并发回调 + 幂等（5）
  → 125 分 → 高风险
  → 测试策略：全量回归 + 专项兼容 + 灰度验证
  → 资源：2 人专项 2 周，线上灰度观察 3 天
```

**坏**：支付网关替换
```text
✗ 风险不大，简单测测就行了
  - 没说替换了多少接口，没评估影响范围
  - 没考虑资金安全，没考虑第三方不可用
  - 没区分"灰度验证"和"全量上线"
  → 结果：上线后新网关回调格式不一致，订单状态不同步
```

## 6. 交付前自检

- [ ] 五大信号雷达（变更/业务/技术/数据/集成）全部扫过
- [ ] 每个功能模块至少 5 个风险点
- [ ] 每个风险点有 `RISK-` ID，类型取自 standards.md
- [ ] 三个因子只取 1/3/5，风险分数 = 三者乘积且表中一致
- [ ] 风险等级按 §2 阈值表查得，无主观判定
- [ ] 三档测试深度不同质（不是全"深测"）
- [ ] 每个风险点的测试建议是具体动作，不是"重点关注"
- [ ] **"看起来简单"的功能也扫过雷达**——低直觉 ≠ 低风险
- [ ] 覆盖率已标注口径，无"全覆盖/100%"绝对化表述