Coding
识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。典型的危险信号包括：频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注概率和影响等级，并附上缓解建议。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。典型的危险信号包括：频繁变更的模块、第三方依赖、资金/安全相关功能、历史Bug多发区域。每一个识别出的风险点都需要标注概率和影响等级，并附上缓解建议。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型。通过风险信号雷达（变更/业务/数据/集成/技术）系统识别风险。每个风险点标注概率和影响等级，附缓解建议。
关键指标：每个功能模块至少识别5个风险点
风险评估公式：
风险等级 = 业务影响 × 发生概率 × 技术复杂度
风险等级划分：
├─ 高风险（≥15分）：必须深测，100%覆盖
├─ 中风险（8-14分）：常规测试，80%覆盖
└─ 低风险（≤7分）：冒烟测试，50%覆盖
📖 五大风险信号雷达（变更类型/业务影响/技术复杂度/数据风险/集成风险）及风险检查清单详见
references/risk-signals.md。加载时机：执行风险评估时由本技能按需读取，避免占用主 context。
## 风险评估报告
### 高风险区域（必须深测）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 高 | [测试建议] |
### 中风险区域（常规测试）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 中 | [测试建议] |
### 低风险区域（冒烟测试）
| 风险点 | 风险类型 | 风险等级 | 测试建议 |
|--------|---------|---------|---------|
| [风险描述] | 业务/技术/变更 | 低 | [测试建议] |
风险等级 = 业务影响 × 发生概率 × 技术复杂度
业务影响：
- 高：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 | 低 | 冒烟 |
测试策略：
- 全场景覆盖
- 边界条件深挖
- 并发场景测试
- 异常恢复测试
- 性能压力测试
- 安全渗透测试
测试用例数：充足
测试时间：充足
测试人员：资深测试
测试策略：
- 主路径覆盖
- 关键分支覆盖
- 常见异常覆盖
- 基础边界测试
测试用例数：适中
测试时间：适中
测试人员：初中级测试
测试策略：
- 主路径冒烟
- 关键功能验证
- 基础回归测试
测试用例数：精简
测试时间：有限
测试人员：自动化
好示例：支付模块升级风险评估
✓ 变更类型：支付网关替换（高风险）
- 业务影响：资金相关，影响所有交易（严重度=10）
- 技术复杂度：涉及第三方SDK替换、回调接口改造（复杂度=8）
- 数据风险：交易记录迁移、对账数据一致性（数据风险=7）
→ 风险等级=10×8×7=560 → 高风险
→ 测试策略：全量回归+专项兼容测试+灰度验证
→ 资源分配：分配2人专项测试2周，线上灰度观察3天
坏示例：支付模块升级风险评估
✗ 风险不大，简单测测就行了
- 没说替换了多少接口，没评估影响范围
- 没考虑资金安全，没考虑第三方不可用
- 没区分"灰度验证"和"全量上线"
→ 结果：上线后才发现新网关回调格式不一致，导致订单状态不同步
用户说"评估一下这个登录功能的测试风险" → 风险信号扫描：
用户说"这个功能很简单，帮我测一下" → 触发风险直觉：自动启动风险信号雷达扫描，评估"简单"背后的隐藏风险
风险评估完成后检查：
当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险（变更范围/影响面/回退成本），设计灰度发布策略（按用户/区域/流量比例），制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了，我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当开发提了 PR、代码变更需要确定测试范围、或者想通过分析代码来预测可能出 Bug 的区域时使用此技能。从测试视角分析代码变更的影响范围、识别高危模式和典型风险区域。不要看完整代码逻辑——你只需要关注变更类型（新增/修改/删除/重构）、影响范围（接口定义/数据库字段/业务逻辑）和相关依赖，据此确定最小回归测试范围。输出代码变更影响分析报告。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"。输出包含风险矩阵、分级测试方案的测试策略文档。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当测试发现"这个功能测不了"、"加个日志就能定位"、"这个模块没法 Mock"时使用此技能。从可控性（能否控制测试条件）、可观察性（能否看到内部状态）、可隔离性（能否独立测试）、自动化性和可诊断性五个维度评估系统的可测试性水平，给出具体的系统改进建议和推动策略。可测试性差的系统一定质量差——不是因为系统本身不好，是因为你根本测不透它。输出可测试性评估报告和各维度的改造建议。 ⚠️ 本技能含废弃测试清理建议，执行前请确认非关键数据。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当需要挑战已有假设、挖掘隐含约束、发现"所有人都没想过"的测试场景时使用此技能。测试中最常犯的错误是接受了需求文档里的隐含假设——比如"用户一定会有网络"、"输入一定有内容"、"操作顺序一定正确"。用「如果不呢」的深度质疑方式反向思考，暴露那些被默认为"正常"的异常场景。每一个测试场景都应该走一遍"如果这个假设不成立呢"的质疑流程。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策：冒烟回归（P0核心流程）、核心回归（高影响区域）、全量回归（有余力时）。基于变更分析和风险评估选择最省时的回归策略，而不是盲目全量回归。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills