开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第30天，点击查看活动详情
01软件需求的风险
主要表现在以下的几个方面:
需求变更风险,在项目的后期用户总是不停的提出需求变更从而影响设计、代码,并且最终反映到测试中来。需求 变更后测试用例没有及时更新;更重要的是在项目的后期明频繁的需求变更会导致测试的时间不充分。
解决办法:
在项目开发过程中的每个阶段,尽量让用户看到产品已经实现见的每个阶段的功能,如果不是用户想要的东西尽早提 出来,总之要让用户参与进来。
另外对于后期用户不停的提出需求变更作为开发商来说,应该多和用户多沟通,争取更充分的研发时间和测试时 间。
02代码质量的风险
如果开发人员提交上来的代码质量不好的话,软件缺陷行很多,那么对于测试工程师来说漏测的可能性就越大。
解决办法:
对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发 工程师进行前期检查。
03测试环境的风险
测试人员在测试过程中搭建的测试环境,虽然原则上是尽尽可能模拟用户实际使用的环境。但是不可能100%完全0 用户的环境一下,这样就会存在一定的风险,因为有些轨软件的缺陷只有在特定的环境下(包括硬件、操作系统、杀 毒软件和软件的不同版本的补丁和用户实际使用的数据等等)才能出现。
解决办法:
测试部门在测试过程中搭建的测试环境的时候,尽量尽-一起可能无限制的模拟用户使用的环境(硬件、操作系统的 版本和补丁,数据库的版本和补丁)在测试的时候尽量利0用户沟通要到用户真实的数据进行测试,以减少风险。
04测试工程师对产品的业务不熟悉
对业务产品的不熟悉一般表现在以下几个方面:
测试工程师不了解用户究竟是如何操作该产品 测试工程师介入到项目测试的时间太短
解决办法:
可以找一些相关行业的专家给测试人员进行培训,当然用户也就是最好的行业专家。另外测试人员一定要在项自的 前期就介入到项目中去熟悉产品,对产品越熟悉找出的软件缺陷越有价值。
