175 lines
3.5 KiB
Markdown
175 lines
3.5 KiB
Markdown
<!-- 由 BMAD™ Core 驱动 -->
|
||
|
||
# 测试优先级矩阵
|
||
|
||
根据风险、重要性和业务影响来确定测试场景优先级的指南。
|
||
|
||
## 优先级
|
||
|
||
### P0 - 关键（必须测试）
|
||
|
||
**标准：**
|
||
|
||
- 影响收入的功能
|
||
- 安全关键路径
|
||
- 数据完整性操作
|
||
- 法规遵从性要求
|
||
- 先前损坏的功能（回归预防）
|
||
|
||
**示例：**
|
||
|
||
- 支付处理
|
||
- 认证/授权
|
||
- 用户数据创建/删除
|
||
- 财务计算
|
||
- GDPR/隐私合规
|
||
|
||
**测试要求：**
|
||
|
||
- 各级别的全面覆盖
|
||
- 正常路径和异常路径
|
||
- 边缘情况和错误场景
|
||
- 负载下的性能
|
||
|
||
### P1 - 高（应该测试）
|
||
|
||
**标准：**
|
||
|
||
- 核心用户旅程
|
||
- 常用功能
|
||
- 逻辑复杂的功能
|
||
- 系统之间的集成点
|
||
- 影响用户体验的功能
|
||
|
||
**示例：**
|
||
|
||
- 用户注册流程
|
||
- 搜索功能
|
||
- 数据导入/导出
|
||
- 通知系统
|
||
- 仪表板显示
|
||
|
||
**测试要求：**
|
||
|
||
- 需要主要的正常路径
|
||
- 关键错误场景
|
||
- 关键边缘情况
|
||
- 基本性能验证
|
||
|
||
### P2 - 中（最好测试）
|
||
|
||
**标准：**
|
||
|
||
- 次要功能
|
||
- 管理功能
|
||
- 报告功能
|
||
- 配置选项
|
||
- UI润色和美学
|
||
|
||
**示例：**
|
||
|
||
- 管理设置面板
|
||
- 报告生成
|
||
- 主题定制
|
||
- 帮助文档
|
||
- 分析跟踪
|
||
|
||
**测试要求：**
|
||
|
||
- 正常路径覆盖
|
||
- 基本错误处理
|
||
- 可以推迟边缘情况
|
||
|
||
### P3 - 低（时间允许则测试）
|
||
|
||
**标准：**
|
||
|
||
- 很少使用的功能
|
||
- 锦上添花的功能
|
||
- 外观问题
|
||
- 非关键优化
|
||
|
||
**示例：**
|
||
|
||
- 高级首选项
|
||
- 旧功能支持
|
||
- 实验性功能
|
||
- 调试工具
|
||
|
||
**测试要求：**
|
||
|
||
- 仅冒烟测试
|
||
- 可以依赖手动测试
|
||
- 记录已知限制
|
||
|
||
## 基于风险的优先级调整
|
||
|
||
### 何时提高优先级：
|
||
|
||
- 高用户影响（影响>50%的用户）
|
||
- 高财务影响（>1万美元的潜在损失）
|
||
- 潜在的安全漏洞
|
||
- 合规/法律要求
|
||
- 客户报告的问题
|
||
- 复杂实现（>500行代码）
|
||
- 多个系统依赖
|
||
|
||
### 何时降低优先级：
|
||
|
||
- 受功能标志保护
|
||
- 计划逐步推出
|
||
- 有强大的监控
|
||
- 易于回滚
|
||
- 低使用率指标
|
||
- 简单实现
|
||
- 良好隔离的组件
|
||
|
||
## 按优先级划分的测试覆盖率
|
||
|
||
| 优先级 | 单元覆盖率 | 集成覆盖率 | 端到端覆盖率 |
|
||
| --- | --- | --- | --- |
|
||
| P0 | >90% | >80% | 所有关键路径 |
|
||
| P1 | >80% | >60% | 主要正常路径 |
|
||
| P2 | >60% | >40% | 冒烟测试 |
|
||
| P3 | 尽力而为 | 尽力而为 | 仅手动 |
|
||
|
||
## 优先级分配规则
|
||
|
||
1. **从业务影响开始** - 如果失败会怎样？
|
||
2. **考虑概率** - 失败的可能性有多大？
|
||
3. **考虑可检测性** - 如果失败了我们能知道吗？
|
||
4. **考虑可恢复性** - 我们能快速修复吗？
|
||
|
||
## 优先级决策树
|
||
|
||
```
|
||
是否对收入至关重要？
|
||
├─ 是 → P0
|
||
└─ 否 → 是否影响核心用户旅程？
|
||
├─ 是 → 风险高吗？
|
||
│ ├─ 是 → P0
|
||
│ └─ 否 → P1
|
||
└─ 否 → 是否经常使用？
|
||
├─ 是 → P1
|
||
└─ 否 → 是否面向客户？
|
||
├─ 是 → P2
|
||
└─ 否 → P3
|
||
```
|
||
|
||
## 测试执行顺序
|
||
|
||
1. 首先执行P0测试（在关键问题上快速失败）
|
||
2. 其次执行P1测试（核心功能）
|
||
3. 如果时间允许，执行P2测试
|
||
4. 仅在完整回归周期中执行P3测试
|
||
|
||
## 持续调整
|
||
|
||
根据以下情况审查和调整优先级：
|
||
|
||
- 生产事故模式
|
||
- 用户反馈和投诉
|
||
- 使用情况分析
|
||
- 测试失败历史
|
||
- 业务优先级变更
|