如何有效的管理测试产品与开发产品之间的密切关系

发布时间:2021-06-24 来源: 万汇智联 浏览次数:

软件测试中的配置管理

在软件测试工作中,我们经常会遇到以下三个问题:

  1. 缺陷只能在测试环境出现,但是在开发环境中无法重现;
  2. 已经修复的缺陷在测试时又重现;
  3. 发布程序在内部确认测试中测试通过,但是发布时却发生系统运行失效的情况。

以上三个问题主要是由以下七个原因造成的:

1.测试环境配置复杂度

由于不同(版本)操作系统、不同(版本)数据库、不同(版本)Web服务器、应用服务器,以及不同的系统架构,需要搭建的软件测试环境多种多样,不胜枚举;而现在随着软件运行环境的多样化,配置各种相关参数的“大工程”,以及测试软件的兼容性,构建软件测试环境的工作变得更加复杂和频繁,软件测试环境是否合理、稳定和具有代表性将直接影响测试结果的真实性、可靠性和正确性。在笔者曾经做过的一个项目中,因为测试环境使用了与开发系统不同版本的JDK(测试环境使用JDK1.8,开发环境为JDK1.7),测试出现在开发环境中不会出现的缺陷。

2.测试产品和开发产品的密切关系

在一个项目的软件测试过程中,会产生大量的“产品”,如文档(包括测试计划、测试用例、测试报告、日常管理文档等)、数据、脚本等软件测试的一个独特之处在于他的产品是基于开发的产品(如源代码、文档、安装文件等)进行生产和更改的。开发出来的产品以“信息”的形式存储在计算机中。因此,与硬件相比,开发的产品更容易修改和改变。一旦开发产品发生变化,测试产品也需要相应的变化。如何有效地管理测试产品,维护测试产品与开发产品之间的关系,成为测试过程中的一个棘手问题。

3.开发人员在处理新的开发任务时修复了缺陷

由于缺乏工具支持,开发人员无法获得详细准确的测试提交缺陷,涉及修改的源代码。因此,在某些项目组中,在每次测试时,开发人员都会将自己开发的所有源代码提交给测试。人员,测试人员会以完全覆盖的方式更新测试环境。但是,由于开发者的工作环境还在处理新变化、新特性或缺陷,在修改新变化、新特性或缺陷的同时,很容易将原有缺陷一起修复。这可能会导致测试环境中出现无法在开发环境中重现的缺陷。

4.Developer 未提交待测试的源代码

假设项目组意识到完全覆盖方法不合理,要求开发者只提交修改缺陷或变更对应的源代码进行测试。但是,由于缺乏工具支持,开发者只能手动记录和跟踪修改后的源代码对应的变化和缺陷。这种方法一方面是记录跟踪工作量大,另一方面是容易漏源代码。由于开发者没有提交源代码,很容易出现测试环境的缺陷在开发环境中无法重现或者已经修复的缺陷再次出现的情况。

5.公共参数/基础数据/配置文件未配置管理

一些项目组没有将公共参数/基本数据/配置文件等全局文件纳入配置管理。由于它不包含在配置管理中,因此对全局文件这部分的更改也不受更改管理的约束。当这些全局文件发生变化时,很容易在测试环境、开发环境甚至生产环境的配置上出现不一致。一旦发生这种情况,即使发布程序在内部确认测试中通过了测试,但系统部署到生产环境后,也难免会出现故障。这其实是配置项缺失导致的问题。

很多人可能不认为公共参数或基础数据应该作为配置项包含在配置管理中。事实上,这种想法是错误的。假设这些公共参数等信息不包括在配置管理中,那么想象一下,如果有一天系统意外崩溃,我们用什么来恢复生产环境?因此,系统运行所支持的所有内容(包括基础数据、配置文件等)都需要包含在配置库中进行配置管理。

曾经有过这样一个案例:某个审批系统的公司组织信息是通过数据库维护的。项目组在处理某个需求变更时需要相应地修改公司的组织信息,但项目组并没有将组织变更作为单独的变更提出,测试团队也没有意识到这种潜在变更的存在。系统测试通过后,系统按计划部署上线,上线后审批流程节点出现错误。如果项目团队将这些组织信息作为配置项纳入到配置数据库中,并且其变更也受变更管理的约束,这怎么可能发生?