qa-risk-intuition

该技能用变更、业务、技术、数据、集成五大风险信号扫描功能模块或变更，按业务影响、发生概率、技术复杂度三因子评分，划分高/中/低风险并分配测试深度与资源。输出带 RISK ID 的风险评估表和按等级分组的报告。

kokxi

热度 59.99

最近更新 2026-09-29 12:29:44

分类：开发依赖：读写文件应用场景：报告撰写 / 任务管理 / 模板 / 工作流

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add qa-risk-intuition

Metadata

displayName: 测试风险直觉
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: {"slug":"qa-risk-intuition","display-name":"测试风险直觉","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`
写风险评估表或按等级分组的报告	`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 坏示例

好：支付网关替换

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

坏：支付网关替换

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

6. 交付前自检

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