软件测试是一项高风险的工作，它是不可避免的，总是存在的。作为一名测试管理人员必须在平时的工作中，分析这些风险的类别，并且想出对策尽最大程度的降低这些风险。

　　1、软件需求的风险

　　主要表现在以下的几个方面：

　　■ 需求变更风险，在项目的后期用户总是不停的提出需求变更从而影响设计、代码，并且最终反映到测试中来。需求变更后测试用例没有及时更新；更重要的是在项目的后期频繁的需求变更会导致测试的时间不充分。

　　■ 软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差，这样导致最终开发的产品功能可能不是用户真正想要的功能

　　对策：在项目开发过程中的每个阶段，尽量让用户看到产品已经实现的每个阶段的功能，如果不是用户想要的东西尽早提出来，总之要让用户参与进来。

　　另外对于后期用户不停的提出需求变更做为开发商来说，应该多和用户多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现。

　　2、人员的风险

　　人员的风险常常表现在以下等方面，

　　■ 核心测试人员的请假、离职

　　■ 测试人员的工作态度不端正、工作状态差

　　■ 测试人员的测试技术不足，比如说产生测试的思维定势，有些有问题的地方始终测试不到位

　　对策：对于核心的测试人员可能离职而延误测试的情况，做为测试管理者可以在平时给这些核心人员配置一些可以候补的测试人员来向他们学习，以避免这些核心人员的请假、离职的时候，可以立即补充上来。

　　另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况，看看其工作状态是不是尽心尽力符合目前的项目测试工作，如果发现不符合的话，测试管理者可以找其单独谈话督促其改正。

　　每个测试工程师测试的思维方式肯定有差别，所以测试管理者多让这些工程师在测试每一轮后，再进行不同模块的交叉测试。

　　3、代码质量的风险

　　如果开发人员提交上来的代码质量很差、很烂的话，软件缺陷很多，那么对于测试工程师来说漏测的可能性就越大。

　　解决办法：对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发工程师进行前期检查。

　　4、测试环境的风险

　　测试人员在测试过程中搭建的测试环境，虽然原则上是尽可能模拟用户实际使用的环境。但是不可能100%完全和用户的环境一下，这样就会存在一定的风险，因为有些软件的缺陷只有在特定的环境下（包括硬件、操作系统、杀毒软件和软件的不同版本的补丁和用户实际使用的数据等）才能出现。

　　对策：测试部门在测试过程中搭建的测试环境的时候，尽量尽一起可能无限制的模拟用户使用的环境（硬件、操作系统的版本和补丁，数据库的版本和补丁）在测试的时候尽量和用户沟通要到用户真实的数据进行测试。以减少风险。

　　5、测试工程师对产品的业务不熟悉

　　对业务产品的不熟悉一般表现在以下几个方面：

　　■ 测试工程师不了解用户究竟是如何操作该产品

　　■ 测试工程师介入到项目测试的时间太短

　　对策：可以找一些相关行业的专家给测试人员进行培训，当然用户也就是最好的行业专家。另外测试人员一定要在项目的前期就介入到项目中去熟悉产品，对产品越熟悉找出的软件缺陷越有价值。

　　6、测试深度和广度的风险

　　■ 测试的广度，用户的操作肯定是千变万化的，测试工程师在测试的时候肯定不能100%覆盖到这些千变万化得操作。有些极端的情况容易被遗漏、测试不到。

　　■ 测试的深度，比如有些软件只有在特定的情况下，比如多用户并发的情况下使用的过程中才会产生软件的缺陷Bug，但是测试工程师在测试的时候忽略了这种情况，只有某几个测试工程师在测试使用这些功能。

　　对策：测试工程师在写测试用例的时候尽量提高测试用例的覆盖率，如果测试用例能涵盖不同的用户千变万化的操作最好。特别是一些边界值、深层次的逻辑关系等。以及用户实际使用环境下的场景（比如大用户量的并发操作等）。