القائمة
测试时间有限要分优先级时使用。适用于版本测试规划、紧急修复验证、跨模块风险评估。融合概率×影响矩阵、Bach Heuristic Risk-Based Testing、HAZOP。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill risk-based-testingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | risk-based-testing |
| description | 测试时间有限要分优先级时使用。适用于版本测试规划、紧急修复验证、跨模块风险评估。融合概率×影响矩阵、Bach Heuristic Risk-Based Testing、HAZOP。 |
参考来源：Hans Schaefer《Risk-Based Testing》、James Bach《Heuristic Risk-Based Testing》、ISTQB Advanced Test Manager。
1. 不能测所有东西
接受这个事实是 RBT 的起点
2. 测试是为了"暴露风险"
不是验证开发对，是验证"它会出错的地方"
3. 风险 = 概率 × 影响
两个维度都要量化，不能拍脑袋
4. 风险随时间和变更动态变化
每次迭代重新评估
5. 沟通比矩阵更重要
矩阵是工具，目标是和团队对齐"什么风险可接受"
影响 ↑
5 │ M H H C C
4 │ L M H H C
3 │ L M M H H
2 │ L L M M H
1 │ L L L M M
└──────────────→ 概率
1 2 3 4 5
L 低风险（接受）
M 中风险（监控）
H 高风险（必须测试 / 缓解）
C 关键风险（不测就不上）
| 等级 | 用户影响 | 业务影响 | 修复成本 |
|---|---|---|---|
| 5 关键 | 全用户阻塞、数据丢失 | 资金损失、合规 | 紧急回滚 + 加班修复 |
| 4 严重 | 部分用户阻塞 | 客诉、SLA 违约 | 当天热修 |
| 3 中等 | 功能不可用但有 workaround | 体验下降 | 下版本修 |
| 2 轻微 | 偶发 / UI 问题 | 几乎无 | 排期修 |
| 1 极小 | 边缘场景 | 无 | 可以不修 |
| 等级 | 触发条件 | 历史数据 |
|---|---|---|
| 5 极高 | 主路径必触发 | 上版本同模块出过 Bug |
| 4 高 | 常用路径会触发 | 同类业务出过 |
| 3 中 | 部分用户触发 | 偶发记录 |
| 2 低 | 少见组合触发 | 无历史 |
| 1 极低 | 极端边缘场景 | 理论可能 |
1. 识别风险点（用上面 Checklist）
↓
2. 给每个风险打分
- 概率 P (1~5)
- 影响 I (1~5)
↓
3. 排序
按 P × I 倒序
↓
4. 分级处理
- C（关键）→ 必测 + 多种方法 + 评审
- H（高）→ 必测 + 标准方法
- M（中）→ 选测 + 单一方法
- L（低）→ 接受 / 不测 / 监控
↓
5. 与 PM / Tech Lead 评审
- 哪些可以"不测"
- 哪些需要额外资源
- 哪些需要灰度 / 监控兜底
↓
6. 输出风险登记表
| ID | 风险描述 | 概率 | 影响 | 等级 | 测试策略 | 缓解措施 | 责任人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| R1 | 支付幂等失效导致重复扣款 | 4 | 5 | C | 全路径 + 并发测试 | 灰度 5% + 监控 | QA + Dev | ✅ 已测 |
| R2 | 大订单分页超时 | 3 | 4 | H | 性能测试 1 万订单 | 索引 + 分页优化 | DBA | ⏳ 进行中 |
| R3 | 移动端 iOS 18 兼容 | 2 | 3 | M | 主路径手测 | 客诉监控 | QA | 接受 |
80% 时间 → 关键和高风险（C + H）
- 完整用例 + 多角度方法
- 自动化优先
15% 时间 → 中风险（M）
- 主路径用例
- 选测，时间充裕再补
5% 时间 → 低风险（L）
- 抽样 / 探索式 / 监控
- 显式记录"接受"
| 触发条件 | 动作 |
|---|---|
| C 级风险 + 时间不够 | 推迟上线 / 砍范围 / 申请加资源 |
| H 级风险 + 测试发现 Bug | 升级为 C，重新评估上线 |
| M 级风险 + 历史出过事 | 升级为 H |
| 多个 H 风险叠加 | 整体升级为 C 处理 |
+ test-strategy：测试范围按风险分配
+ test-case-design：高风险路径多种方法覆盖
+ exploratory-testing：高风险区域 charter
+ regression-testing：高风险点纳入回归核心
+ quality-gate：C/H 级风险必须 0，否则不放行
□ 每个风险都有概率 × 影响打分
□ 打分有依据，不是拍脑袋
□ C 级风险有缓解措施（不只是测试）
□ 风险登记表与 PM/Tech Lead 评审过
□ "不测"的低风险有显式记录和接受
□ 时间分配按 80/15/5
□ 历史 Bug 转化为风险点
□ 灰度 / 监控作为风险兜底（不只是测试兜底）
templates/risk-register-template.md — 风险登记表 + 概率影响矩阵 + 缓解措施跟踪上游：
test-strategy → 提供测试范围
历史 field-journal → 提供历史风险
下游：
test-case-design → 高风险用例细化
exploratory-testing → 高风险区域 charter
regression-testing → 风险点入回归
quality-gate → 风险等级转化为放行条件
test-report → 风险结论作为最终判断