文/秋之川
这是《落叶》文集里第 *328 *片落叶，希望你能喜欢，不为别的，只为这份坚持。
第十三章 管理测试项目中的风险时应该关注些什么？
结合着老大给我的实例，我也自己参看了一些理论书籍，对于测试项目的风险，有几点是我应该重点关注的：
- 影响结果
（1）指的就是这类风险最终会导致的结果是什么，项目延期？发布后缺陷率上升？还是项目成本的增加？
（2）只有明确知道了最终的影响结果，我们才可以判断该风险的严重性是高还是低；
（3）只有判断出风险的严重性，我们才能决定是否有制定应对方案的必要； - 应对策略
（1）在实际的项目中，多数风险可能会发生，也可能不会发生，存在一定的概率，所以我们需要根据历史项目经验和相关的项目数据，来判断该风险发生的可能性；
（2）当项目开始了，随着时间和进度的推移，离风险可能发生的时间点越来越近，项目信息也越来越充分，那时候会更加容易地判断风险发生的可能性；
（3）降低风险所产生的影响结果是风险应对的一种手段，这个是我们最常用的，也是最容易采取的一种策略，比如说通过增加人力，优化流程来，减少需求变更等手段来将降低项目延期风险的影响；
（4）转移风险也是风险应对的一种手段，就是将可能有严重影响的风险转化为影响较小的风险，从概念上来看，觉得有些难搞，但实际上我们在项目中经常采用这种策略，我举个例子就清楚了：比如在项目的中后期，临近上线了，发现一个低概率碰到的程序 Crash Bug，要不要修复呢？
（1）如果要修复这个 bug，需要动到功能模块的底层库，测试需要做一轮 Full Regression Testing;
（2）但因为临近发布时间了，所以没有足够的时间去做，只能针对问题发生的周边范围做一轮简单地回归;
（3）这里的风险就是可能会导致较为严重的 Regression Bug 被漏到线上，这就是很严重的风险。
（4）我们一般碰到这种问题，都会怎么应对呢？肯定是将这个 Bug 延期到下个版本修复：- 首先，下个版本会有足够的时间做一轮充分的回归测试；
- 其次，本身那个 Crash Bug，用户碰到的概率就很低，这个风险就较低了；
- 应对方案
（1）应对方案的制定，我认为应该是随着项目进度的推进而从粗到细的，因为在项目刚开始时，有效的项目信息比较少，对于风险发生的可能性判断准确性比较低；
（2）项目开始时根据风险发生的可能性制定粗细不一的应对方案，等到风险清晰可见时再做一些优化和适时的调整，性价比会更高些；
最后，就我经历过的项目，我认为我们需要很清楚的认识到：绝大多数风险都是不可消除或者说避免的，如果说某个风险我们提前就知道怎么能不让它发生，那它就不应该算作风险。
风险最大的特点应该就是它的“不确定性”，而且，正因为风险的不确定性，我们才需要及时的识别并出手应对，这既是风险管理的难点所在，但也是其乐趣所在。
《告诉你如何从执行测试到管理测试》带你迈出第（13）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
