测试风险直觉

识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。典型的危险信号包括：频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注概率和影响等级，并附上缓解建议。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

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

风险直觉与优先级判断

核心原则

有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型。通过风险信号雷达（变更/业务/数据/集成/技术）系统识别风险。每个风险点标注概率和影响等级，附缓解建议。

风险评估要求

关键指标：每个功能模块至少识别5个风险点

text

风险评估公式：
风险等级 = 业务影响 × 发生概率 × 技术复杂度

风险等级划分：
├─ 高风险（≥15分）：必须深测，100%覆盖
├─ 中风险（8-14分）：常规测试，80%覆盖
└─ 低风险（≤7分）：冒烟测试，50%覆盖

风险信号雷达

📖 五大风险信号雷达（变更类型/业务影响/技术复杂度/数据风险/集成风险）及风险检查清单详见 references/risk-signals.md。

加载时机：执行风险评估时由本技能按需读取，避免占用主 context。

风险评估输出格式

markdown

## 风险评估报告

### 高风险区域（必须深测）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 高 | [测试建议] |

### 中风险区域（常规测试）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 中 | [测试建议] |
### 低风险区域（冒烟测试）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 低 | [测试建议] |

风险评估矩阵

风险等级计算

text

风险等级 = 业务影响 × 发生概率 × 技术复杂度

业务影响：
- 高：5分（资金、安全、核心链路）
- 中：3分（内部管理、辅助功能）
- 低：1分（内部工具、文档）

发生概率：
- 高：5分（经常出问题）
- 中：3分（偶尔出问题）
- 低：1分（很少出问题）

技术复杂度：
- 高：5分（并发、状态、分布式）
- 中：3分（复杂规则、数据转换）
- 低：1分（简单CRUD、静态展示）

风险分数（闭区间，边界归高）：
- ≥75：高风险（必须深测）
- 25-74：中风险（常规测试）
- ≤24：低风险（冒烟测试）

风险评估表

功能模块	业务影响	发生概率	技术复杂度	风险分数	风险等级	测试深度
支付模块	5	3	5	75	高	深测
用户模块	5	5	3	75	高	深测
通知模块	1	3	1	3	低	冒烟

测试资源分配

高风险区域（深测）

text

测试策略：
- 全场景覆盖
- 边界条件深挖
- 并发场景测试
- 异常恢复测试
- 性能压力测试
- 安全渗透测试

测试用例数：充足
测试时间：充足
测试人员：资深测试

中风险区域（常规测试）

text

测试策略：
- 主路径覆盖
- 关键分支覆盖
- 常见异常覆盖
- 基础边界测试

测试用例数：适中
测试时间：适中
测试人员：初中级测试

低风险区域（冒烟测试）

text

测试策略：
- 主路径冒烟
- 关键功能验证
- 基础回归测试

测试用例数：精简
测试时间：有限
测试人员：自动化

输出示例

好示例：支付模块升级风险评估

text

✓ 变更类型：支付网关替换（高风险）
  - 业务影响：资金相关，影响所有交易（严重度=10）
  - 技术复杂度：涉及第三方SDK替换、回调接口改造（复杂度=8）
  - 数据风险：交易记录迁移、对账数据一致性（数据风险=7）
  → 风险等级=10×8×7=560 → 高风险
  → 测试策略：全量回归+专项兼容测试+灰度验证
  → 资源分配：分配2人专项测试2周，线上灰度观察3天

坏示例：支付模块升级风险评估

text

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

应用场景

用户说"评估一下这个登录功能的测试风险" → 风险信号扫描：

• 变更类型信号：密码加密算法变更（高风险）
• 业务影响信号：登录失败→用户无法使用（严重）
• 技术复杂度信号：涉及第三方认证服务（中风险）
• 数据风险信号：用户密码数据迁移（高风险） → 风险评估矩阵：高风险区域建议深测，低风险冒烟测试 → 资源分配：高风险区域分配60%测试资源

用户说"这个功能很简单，帮我测一下" → 触发风险直觉：自动启动风险信号雷达扫描，评估"简单"背后的隐藏风险

自检清单

风险评估完成后检查：

• 是否识别了所有变更类型？
• 是否评估了业务影响？
• 是否分析了数据风险？
• 是否识别了集成风险？
• 是否评估了技术复杂度？
• 风险等级是否合理？
• 测试资源分配是否恰当？

检查清单

• 五大信号雷达是否全评估？
• 高风险区域是否标注？
• 风险加权是否合理？
• 聚焦建议是否给出？
• 风险ID是否分配？