agentleFS
Sign inStart free
KokxiKokxi/qa-test-skills/skills/qa-risk-intuition/SKILL.md

qa-risk-intuition

Skill31 starsChanged 48 days agoMITView on GitHub

识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型：变更/业务/技术/数据/集成五大风险信号雷达，量化打分后按等级分配测试深度与资源。每个风险点带唯一 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.

The file

Create a free account to mount
Files
SKILL.md

⚠️ 本技能单独使用效果有限，建议配合完整技能集（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支付/并发回调555125高深测
RISK-PAY-STOCK-001支付/库存扣减53575高深测
RISK-ORDER-EXPORT-005订单/导出33327中常规
RISK-NOTIFY-PUSH-004通知/推送1313低冒烟

风险类型：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%"绝对化表述

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free