软件测试的风险分析与解决办法



软件测试是一项存在风险的工作，它是不可避免的，总是存在的。作为一名测试管理人员必须在平时的工作中，分析这些风险的类别，并且找出对策尽最大程度的降低这些风险。
一：软件需求的风险主要表现在以下的几个方面：
1.软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差，这样导致最终开发的产品功能可能不是用户真正想要的功能。
2.需求变更风险，在项目的后期用户总是不停的提出需求变更，从而影响设计、代码，并且最终反映到测试中来。需求变更后，测试用例没有及时更新；更重要的是在项目的后期频繁的需求会导致测试的时间不充分。
解决办法：
1.在项目开发过程中的每一个阶段，尽量让有决策权的核心用户看到产品已经实现的每个阶段的功能，如果不是用户想要的东西尽早提出来，总之要让用户参与进来。
2.另外对于后期用户不停的提出需求变更作为开发商来说，应该多和有决策权的核心用户多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现。

二：人员的风险
人员的风险常常表现在以下等方面：
1.核心测试人员的请假、离职
2.测试人员的工作态度不端正、工作状态差
3.测试人员的测试技术不足，比如说产生测试的思维定势，有些有问题的地方始终测试不到位
解决办法：
1.对于核心的测试人员可能离职而延误测试的情况，作为测试管理者可以在平时给这些核心人员配置一些可以候补的测试人员来向他们学习，以避免这些核心人的请假、离职的时候，可以立即补充上来。
另外，对于一些关键的业务和技术一定要有文档。

2.另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况，看看其工作态度是不是尽心尽力符合目前的项目测试工作，如果发现不符合的话，测试管理者可以找其单独谈话督促其改正。
3.每个测试工程师的思维方式肯定有差别，所以测试管理者多让这些工程师在测试每一轮后，在进行不同模块的交叉测试。

三：代码质量的风险
如果开发人员提交上来的代码质量很差、很烂的话，软件缺陷很多，那么对于测试工程师来说漏测的可能性就越大。
解决办法：对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发工程师进行前期检查

四：测试环境的风险
测试人员在测试过程中搭建的测试环境，虽然原则上是尽可能模拟用户实际使用的环境。但是不可能100%完全和用户的环境一样，这样就会存在一定的风险，因为有些软件的缺陷只有在特定的环境下（包括硬件、操作系统、杀毒软件和软件的不同版本的补丁和用户实际使用的数据等）才能出现。
解决办法：测试部门在测试过程中搭建的测试环境的时候，尽量尽一切可能无限制的模拟用户使用的环境（硬件、操作系统的版本和补丁，数据库的版本和补丁）在测试的时候尽量和用户沟通要到用户真实的数据进行测试。以减少风险。

五：测试工程师对产品的业务不熟悉
对业务产品的不熟悉一般表现在以下几个方面：
测试工程师不了解用户究竟是如何操作该产品和用户的操作习惯
测试工程师介入到项目测试的时间太短

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

六：测试深度和广度的风险
1.测试的广度，用户的操作肯定是千变万化的，测试工程师在测试的时候肯定不能100%覆盖到这些千变万化的操作。有些极端的情况容易被遗漏、测试不到。
2.测试的深度，比如有些软件只有在特定的情况下，比如多用户并发的情况下使用的过程中才会产生软件的缺陷bug，但是测试工程师在测试的时候忽略了这种情况，只有某几个测试工程师在测试使用这些功能。
解决办法：测试工程师在写测试用例的时候尽量提高测试用例的覆盖率（在测试用例完成后组织进行测试用例的评审工作），如果测试用例能覆盖不同的用户千变万化的操作最好。特别是一些边界值、深层次的逻辑关系等。以及用户实际使用环境下的场景（比如大用户量的并发操作等）。

七：测试工具本身可能产生误差
1.测试工具能模拟用户的手工操作，但是这种工具本身就存在误差、或者使用者操作不当产生的误差，比如：在项目后期的回归测试的时候使用自动化功能测试工具QTP进行回归测试的时候，由于修改了某些脚步导致QTP每次测试都能通过，但是到用户现场的话有可能会最简单的功能都通不过。
2.在进行性能测试工具的时候大家常常使用Webload、Jemeter、Loadrrunner等，但是这些工具并不能100%模拟用户的并发操作；比如用工具模拟500个用户同时并发登录系统，但是这些并发都是从1台或者某几台测试机器上发出请求的。但是在用户实际使用环境的情况下这500个用户可能来自全国或全世界的各个地方。

解决办法：
1.对于自动化的测试工具，一定要选择一些知名大企业比较成熟的测试工具，比如：HP公司的Loadrunner，QTP或者IBM的系列测试工具
2. 测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值，比如：进行了5次的大用户的并发测试，其中有一次的测试结果与另外4次的测试结果偏差较大，那么测试工程师就可以排除这1次偏差较大的测试（因为这1次测试结果可能受到一些其他因素的影响而导致不准确，比如受到网络因素的影响等）。
3.另外测试工具仅仅是提高测试效率的，由于测试工程师在使用测试工具的过程中某些参数设置不合理而导致测试结果不准确。所以不要过分的相信测试工具，最后一定要进行人工的审核和检查才可靠。
4.另外可以用不同的测试工具运行相同的测试场景，如果不同的测试工具运行相同的测试场景的测试结果相近的话，可以认为这种测试是有效的。

八：测试资源的不充分
测试资源的不充足表现在很多方面，比如：
1.硬件资源不够，国内的很多小型的软件企业开发和测试居然使用同一个环境，这样肯定会影响测试效果的。
2.软件资源不充分，比如在项目的后期进行回归测试的工作量很大，但是测试的人手不够。
3.测试的时间不充足，在企业实际的研发过程中，研发人员由于各种原因（如用户提出修改或者新增某些功能、甚至研发人员的技术水平等）导致提交到测试部门的延迟，这样无形中减少了测试人员的测试，测试时间不充足会影响到测试的效果的。

解决办法：作为一名测试管理者有义务向公司里申请更多的测试资源，如购置独立的测试服务器把测试环境和研发环境分开；要求招聘更多的测试人员；测试管理者应当做好测试风险的预估，比如：在制定测试计划的时候要预留一定的多余时间以应对临时变化的一些特殊情况。

原文：http://www.hezongedu.cn/269.html；