软件测试的“泥潭”
可能有读者会觉得奇怪,软件测试就是发现软件中隐藏的缺陷,和配置管理有啥关系呢。但是,不知道大家在实际工作中有没有发现,我们在软件测试工作中碰到的一些问题,实际上就是由于配置管理工作没做好而产生的。
在软件测试工作中,我们经常碰到以下三个问题:
产生原因
不考虑缺陷报告描述不清楚这种情况,究其原因,上述三个问题的产生主要有以下七点原因:
- 测试环境配置的复杂性
由于不同(版本)的操作系统、不同(版本)的数据库,不同(版本)的网络服务器、应用服务器,再加上不同的系统架构等组合,使得要构建的软件测试环境多种多样、不胜枚举;而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要,使得构建软件测试环境的工作变得较为复杂和频繁,而软件测试环境的构建是否合理、稳定和具有代表性,将直接影响到测试结果的真实性、可靠性和正确性。在笔者曾经做过的一个项目中,由于测试环境使用了和开发系统不同版本的 JDK(测试环境使用 JDK1.5,而开发环境为 JDK1.4),导致测试中出现了在开发环境不会出现的缺陷。
- 测试产品与开发产品之间的密切关系
在一个项目的软件测试过程中,会有大量的“产品”产生,典型的如文档(包括测试计划、测试用例、测试报告、日常管理文档等)、数据、脚本等。软件测试的一个独特的特征,就是他的产品都是基于开发产品(如源代码、文档、安装文件等)产生和变化的。而开发产品都是以“信息”的形式存放在计算机中,因此,较硬件而言,开发产品比较容易被修改和变化。一旦开发产品发生改变,测试产品也需要相应发生改变。如何有效的管理测试产品,维护测试产品与开发产品之间的关系成为测试过程中的一个棘手的问题。
- 开发人员在处理新的开发任务时间接修复了缺陷
由于缺少工具的支撑,开发人员不能详细的、准确的获取提交测试的缺陷涉及修改的源码,所以在有些项目组中,每次测试时,开发人员将个人开发的所有源码提交给测试人员,由测试人员采用完全覆盖的方式更新测试环境。但是由于开发人员的工作环境仍在进行新变更、新功能或缺陷的处理,而修改新变更、新功能或缺陷的同时,很容易将原来存在的缺陷一并修复。这就可能导致测试环境中存在的缺陷在开发环境中无法重现问题的发生。
文章来源于领测软件测试网 https://www.ltesting.net/