TTokenySpace
返回 Skills 列表

Qa Risk Intuition

识别那些"看起来很简单但实际风险很高"的测试区域,帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时,应当使用此技能。典型的危险信号包括:频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注...

#中文
0

安装到 Tokeny(自动)

下载 ZIP
安装"qa-risk-intuition"技能
技能信息:
- 名称: Qa Risk Intuition
- 标识: qa-risk-intuition
- 描述: 识别那些"看起来很简单但实际风险很高"的测试区域,帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时,应当使用此技能。典型的危险信号包括:频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注...
- 版本: 1.0.0
下载地址:
https://www.tokeny.space/api/skills/qa-risk-intuition/download
继续

复制上方内容到 Tokeny 客户端并在会话中发送即可自动安装;也可直接 下载 ZIP并拖动到技能窗口安装。

SKILL.md

风险直觉与优先级判断

核心原则

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

风险评估要求

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

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

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

风险信号雷达

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

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

风险评估输出格式

## 风险评估报告

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

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

风险评估矩阵

风险等级计算

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

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

发生概率:
- 高:5分(经常出问题)
- 中:3分(偶尔出问题)
- 低:1分(很少出问题)

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

风险分数:
- 75-125:高风险(必须深测)
- 25-74:中风险(常规测试)
- 1-24:低风险(冒烟测试)

风险评估表

功能模块业务影响发生概率技术复杂度风险分数风险等级测试深度
支付模块53575深测
用户模块55375深测
通知模块1313冒烟

测试资源分配

高风险区域(深测)

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

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

中风险区域(常规测试)

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

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

低风险区域(冒烟测试)

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

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

输出示例

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

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

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

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

应用场景

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

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

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

自检清单

风险评估完成后检查:

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

检查清单

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

评论

加载中…