文/秋之川
这是《落叶》文集里第 329 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第十四章 按过程维度去识别风险会不会清晰一些？
我想着这可是第一次独立去管测试项目，得考虑的全面细致一些，我依据对风险特性的理解，将风险识别划分为不同的过程维度：
评审阶段
- 需求评审
- 定义不清晰
- 描述的二义性
- 验收标准不明确
- 设计评审
- 逻辑设计与需求不一致
- 部署评审
- 发布组件依赖关系不清晰
设计阶段
- 工作量评估
- 估算不准确，偏差较大
- 用例设计
- 广度覆盖不足
- 深度挖掘不足
- 测试环境
- 环境一致性
执行阶段
- 用例执行
- 执行遗漏
- 缺陷漏测
- 人员变动
- 工作态度
- Bug 验证
- 修复速度
- 回归测试
- 主观经验
- 需求变更
- 开发后期变更需求
- 测试后期变更需求
软件测试风险识别表示例
| 序号 | 风险阶段 | 风险描述 | 可能性 | 影响 | 严重性 | 应对措施 |
|---|---|---|---|---|---|---|
| 1 | 需求评审 | 因为需求描述不清楚，导致对需求的理解偏差太大 | 中 | 测试阶段产生争议 | 严重 | 重视需求测试，检查功能逻辑的描述，保证无二义性 |
《告诉你如何从执行测试到管理测试》带你迈出第（14）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论