实际上，软件测试活动，本身就可以被认为是一种风险控制措施。试想一下，我们测试团队，对于一个软件进行测试，发现了缺陷进行汇报，并督促开发团队去修复和解决问题。这是不是已经直观的降低了产品的风险？这个论断显然是成立的。而测试活动通过其反馈作用，去达到过程改进的效果，也可以更进一步的帮助项目去规避风险。
那么基于风险的测试应该怎么去组织呢？我们就是用风险分析的结果报告，去指导我们测试的开展，具体而言可以有如下措施：
基于风险确定测试优先级
基于风险确定测试完备性
基于风险确定测试资源分配
这样的一些措施要基于我们测试的几个基本原则：
1. “测试是不可能穷尽的” - 既然测试不可能穷尽，那么我们就应该优先去测试风险高的部分，把低的部分放到后续去做，如果时间不允许甚至有部分低风险的部分不测。
2. “缺陷具有集群性” - 即所谓的20%的模块有80%的bug，那么我们通过将风险可能性高的部分去准备更完备的测试（比如更多的测试用例覆盖，更多的执行轮次，更多的执行时间）和更有经验的人员，就可以实现软件质量的快速上升。
最后要注意：风险分析不是一个一次性的工作，我们要通过在项目实际研发过程中得到的信息和反馈，对风险等级进行调整，比如调高和调低风险等级。一个实际的例子是：我们在项目开始时，将某一个风险项目定为了高级，因此这个风险项引起了团队的重视。从而在后续工作开展过程中，团队投入了更多的资源和力量，导致最终测试阶段可能反而在这个模块里面没有发现太多问题。
所以我们测试活动的产出和收集到的信息要用来对风险评估结果进行持续的反馈和调整更新，并根据调整后的风险等级继续指导测试。