一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
    二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
    三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
    四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
    五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
    六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
    七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
    八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

    前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
    针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

   ·测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查； 
   ·有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险； 
   ·有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

    为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

   ·在做资源、时间、成本等估算时，要留有余地，不要用到100%； 
   ·在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中； 
   ·对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，    项目不会受到严重影响，仍能可以继续下去； 
   ·制定文档标准，并建立一种机制，保证文档及时产生； 
   ·对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换； 
   ·对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

    要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。