测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：
质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。
前面三种风险是可以避免的，而4）至7）的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
针对上述软件测试的风险，有一些有效的测试风险控制方法，如：
测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；
有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；
有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；
为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：
在做资源、时间、成本等估算时，要留有余地，不要用到100%；
在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；
对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去；
制定文档标准，并建立一种机制，保证文档及时产生；
对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；
对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。
要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。
补充材料： 关于风险管理的方法
风险管理，一般可以分成5个步骤，即风险识别、风险分析、风险计划、风险控制以及风险跟踪。
1. 风险识别
风险识别是试图用系统化的方法来确定威胁项目计划的因素。识别方法包括风险检查表、头脑风暴会议、流程图分析以及与项目人员面谈等。前两种方法是比较常用的。风险检查表建立在以前开发类似的项目中曾经遇到的风险基础上，比如开发时利用了某种技术，那么有过这种技术开发经验的个人或者项目组就能指出他们在利用这种技术时遇到过的问题；头脑风暴会议可以围绕项目中有可能会出现哪些范围、进度、成本和质量方面的问题这一议题展开，讨论和列举出项目可能出现的风险。对不同的项目应该具体问题具体分析，识别出真正可能发生在该项目上的风险事件。
2. 风险分析
风险分析可以分为定性风险分析和定量风险分析。定性风险分析是评估已识别风险的影响和可能性的过程，以根据风险对项目目标可能的影响对风险进行排序。它在明确特定风险和指导风险应对方面十分重要。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。
不同的风险发生后对项目造成的影响各不相同，主要有以下3个方面需要考虑：
风险的性质，即风险发生时可能产生的问题；
风险的范围，即风险的严重性及其总的分布；
风险的时间，即何时能感受到风险及风险维持多长时间。
据此确定风险估计的加权系数，得到项目的风险估计。然后通过对风险进行量化、选择和排序，可以知道哪些风险是必须要应对，哪些是可以接受，哪些是可以忽略。进行风险管理应该把主要精力集中在那些影响力大、影响范围广、概率高以及可能发生的阶段性的风险上。
3. 风险计划
制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对措施、结果、负责人。建立示警的阈值是风险计划过程中的主要活动之一，阈值与项目中的量化目标紧密结合，定义了该目标的警告级别。
该阶段涉及到参考计划、基准计划和应急计划等不同类型的计划。
参考计划是用来与当前建议进行比较的参考点。
基准计划是建议的计划编制基础，是提出的项目实施的起始位置。
应急计划是建立在基准计划基础上的建议补充计划，包括启动意外情况应对措施的触发点。
在这一阶段有巩固与解释、选择与细化、支持与说服等特定的任务。
4. 风险控制方法
主要采用的应对方法有风险避免、风险弱化、风险承担和风险转移等。
风险避免：通过变更软件项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，采用更熟悉更成熟的技术、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等。
风险弱化：将风险事件的概率或结果降低到一个可以接受的程度，当然降低概率更为有效。例如，选择更简单的开发流程、进行更多的系统测试、开发软件原型系统、增加备份设计等。
风险承担：表示接受风险，不改变项目计划(或没有合适的策略应付风险)，而考虑发生后如何应对。例如制定应急计划、风险应变程序，甚至仅仅进行应急储备和监控，发生紧急情况时随机应变。在实际中，如软件项目正在进行中，有一些人要离开项目组，可以制定应急计划，保障有后备人员可用，同时确定项目组成员离开的程序，以及交接的程序。
风险转移：不去消除风险，而是将软件项目风险的结果连同应对的权力转移给第三方(第三方应知晓有风险并有承受能力)。这也是一种事前的应对策略，例如签订不同种类的合同，或签订补偿性合同等。
5. 风险跟踪
在风险受到控制以后，我们要及时进行跟踪，做好风险跟踪：
监视风险的状况，例如风险是已经发生、仍然存在还是已经消失；
检查风险的对策是否有效、跟踪机制是否在运行；
不断识别新的风险并制定对策。
可以通过以下几种方法进行有效的风险跟踪：
风险审计：项目管理员应帮助项目组检查监控机制是否得到执行。项目经理应定期进行风险审核，尤其在项目关键处进行事件跟踪和主要风险因素跟踪．以进行
风险的再评估；对没有预计到的风险制定新的应对计划。
偏差分析：项目经理应定期与基准计划比较，分析成本和时间上的偏差。例如，未能按期完工、超出预算等都是潜在的问题。
技术指标分析：技术指标分析主要是比较原定技术指标和实际技术指标差异，例如，测试未能达到性能要求等。
版权所有，软件测试演义® ——系列讨论的目录，见：
