任何环境下的项目开发，都会存在风险。几乎不存在没有风险的项目，也没有不存在风险的环境。因此，如何在一个风险的环境里降低风险，找到项目存在的漏洞，消除可能会对项目造成消极影响的因素，是每一个测试人都应该尽力去做的事情。 

风险可以定义为事件、危险、威胁或情况等发生的 、威胁或情况等发生的可能性以及由此产生不可预料的后果，即一个潜在的问题！

风险级别由出现不确定事件的可能性和出现后所产生的影响（即：事件引发的不好的结果）两个方面来决定！

01

风险控制的原则

1）针对有些可以避免的风险，例如测试用例执行率未达到 10 0 %，可以通过制定测试规范，要求测试人员严格按照测试用例执行测试，并记录用例执行情况，来避免该类风险；

2）有些不可避免的风险，采取措施降低风险，尤其是等级较高的风险，将其转化为不会引起严重后果的等级较低的风险；

3）凡事预则立，事先做好风险管理计划，当风险成为现实时，可以更好的避免、转移或减低风险；

4）对风险的处理制定应急、高效的解决方案。

02

造成的原因有

1. 软件需求不清晰、不完善，或者对产品的需求特性理解不准确，多次反复评审挤占时间。

2. 中、后期需求变更频繁，或者更新需求，以至于测试用例没有及时更新，导致资源分散，测试时间不充分。

3. BUG修复速度慢或者修复困难，以及部分功能的更新，阻碍了新功能的测试以及后面的回归测试。

4. 测试工作人员的技术不足，比如测试的思维定势，有些问题的地方测试不到位。

5. 开发自测不充分，版本不高，质量不高，影响正常的测试计划。

03

可以优化的方案有：

1. 制定测试包的可接受标准，对于接收到的文档认真阅读，与开发负责人积极沟通，完善测试前所必备的文档和数据，提高自测质量。

2. 在进行测试任务量评估时，预留十天左右的时间，用于应对需求变更和临时新增需求，及时更新测试用例。

3. 优化测试用例设计，减少无效的测试用例，抓准重要功能的测试，多一些深层次的逻辑、边界条件、用户场景等，同时提高自动化脚本覆盖率。

4. 与开发负责人沟通明确BUG修复要求，预留一个月或半个月的修复时间。在某些模块里出现阻碍性缺陷时，可以略过，先测试其他模块。

测试的目的是为了把软件缺陷率降到很低，而这一过程同样存在着风险，因此风险管理也是整个测试工作中不可或缺的环节，在实际工作中逐步推进。这就要求我们做好风险管理工作，建立合适的管理方式，树立防患于未然的管理意识，并结合实际工作不断分析遇到的风险，既要评估可能存在的问题，又要对可能出现的问题做好应对措施。