01 软件需求的风险

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

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

解决办法：

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

另外对于后期用户不停的提出需求变更作为开发商来说，应该多和用户多沟通，争取更充分的研发时间和测试时间。

02 代码质量的风险

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

解决办法：

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

03 测试环境的风险

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

解决办法：

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

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

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

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

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

解决办法：

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

05 测试工具本身可能产生误差

测试工具能模拟用户的手工操作，但是这种工具本身就存在误差、或者使用者操作不当产生的误差，比如：在项目后期的回归测试的时候使用自动化功能测试工具QTP进行回归测试的时候，由于修改了某些脚本导致QTP每次测试都能通过，但是到用户现场的话有可能会最简单的功能都通不过。

在进行性能测试工具的时候大家常常使用Webload、Jemeter、Loadrunnner等，但是这些工具并不能100%模拟用户的并发操作：比如用工具模拟500个用户同时并发登录系统，但是这些并发都是从1台或者某几台测试机器上发出请求的。但是在用户实际使用环境的情况喜爱这500个用户可能来自全国或者全世界的各个地方。

解决办法：

对于自动化的测试工具，一定要选择一些知名大企业比较成熟的测试工具，比如：HP公司的Loadrunnner，QTP或者IBM的系列测试工具。

测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值，比如：进行了5次的大用户的并发测试，其中有1次的测试结果与另外4次的测试结果偏差较大，那么测试工程师就可以排除这1次偏差较大的测试（因为这1次测试结果可能受到一些其他因素的影响而导致不准确，比如受到网络因素的影响等）

测试工具仅仅是提高测试效率的，由于测试工程师在使用测试工具的过程中某些参数设置不合理而导致测试结果不准确。所以不要过分的相信测试工具，最后一定要进行人工的审核和检查才可靠。

可以用不同的测试工具运行相同的测试场景，如果不同的测试工具运行相同的测试场景的测试结果相近的话，可以认为这种测试时有效的。

06 测试资源的不充分

测试资源的不充足：

硬件资源不够，国内的很多小型的软件企业开发和测试居然使用同一个环境，这样肯定肯定会影响测试效果的。

软件资源不充分，比如在项目的后期进行回归测试的工作量很大，但是测试的人手不够。

测试的时间不充足，在企业实际的研发过程中，研发人员由于各种原因（如用户提出修改或者新增某些功能、甚至研发人员的技术水平等）导致提交到测试部门的延迟，这样无形中减少了测试人员的测试时间，测试时间不充足会影响到测试的效果的。

解决办法：

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

作者：测试界的飘柔

原文链接：https://blog.csdn.net/m0_67695717/article/details/127450211