软件测试需要进行充分的测试准备，需要科学的，规范的测试过程管理。有效的配置管理对跟踪和提高测试质量和效率起到十分重要的作用。测试过程中的配置管理工作不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本。但是在实际软件测试工作中，配置管理并没有得到相应的重视。
软件测试的“泥潭”
可能有读者会觉得奇怪，软件测试就是发现软件中隐藏的缺陷，和配置管理有啥关系呢。但是，不知道大家在实际工作中有没有发现，我们在软件测试工作中碰到的一些问题，实际上就是由于配置管理工作没做好而产生的。
在软件测试工作中，我们经常碰到以下三个问题：
缺陷只能在测试环境出现，但是在开发环境中无法重现；
已经修复的缺陷在测试时又重现；
发布程序在内部确认测试中测试通过，但是发布时却发生系统运行失效的情况。
产生原因
不考虑缺陷报告描述不清楚这种情况，究其原因，上述三个问题的产生主要有以下七点原因：
测试环境配置的复杂性
由于不同（版本）的操作系统、不同（版本）的数据库，不同（版本）的网络服务器、应用服务器，再加上不同的系统架构等组合，使得要构建的软件测试环境多种多样、不胜枚举；而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要，使得构建软件测试环境的工作变得较为复杂和频繁，而软件测试环境的构建是否合理、稳定和具有代表性，将直接影响到测试结果的真实性、可靠性和正确性。在笔者曾经做过的一个项目中，由于测试环境使用了和开发系统不同版本的 JDK（测试环境使用 JDK1.5，而开发环境为 JDK1.4），导致测试中出现了在开发环境不会出现的缺陷。
测试产品与开发产品之间的密切关系
在一个项目的软件测试过程中，会有大量的“产品”产生，典型的如文档（包括测试计划、测试用例、测试报告、日常管理文档等）、数据、脚本等。软件测试的一个独特的特征，就是他的产品都是基于开发产品（如源代码、文档、安装文件等）产生和变化的。而开发产品都是以“信息”的形式存放在计算机中，因此，较硬件而言，开发产品比较容易被修改和变化。一旦开发产品发生改变，测试产品也需要相应发生改变。如何有效的管理测试产品，维护测试产品与开发产品之间的关系成为测试过程中的一个棘手的问题。
开发人员在处理新的开发任务时间接修复了缺陷
由于缺少工具的支撑，开发人员不能详细的、准确的获取提交测试的缺陷涉及修改的源码，所以在有些项目组中，每次测试时，开发人员将个人开发的所有源码提交给测试人员，由测试人员采用完全覆盖的方式更新测试环境。但是由于开发人员的工作环境仍在进行新变更、新功能或缺陷的处理，而修改新变更、新功能或缺陷的同时，很容易将原来存在的缺陷一并修复。这就可能导致测试环境中存在的缺陷在开发环境中无法重现问题的发生。
开发人员漏提交待测试的源码
假设项目组意识到完全覆盖方式的不合理，要求开发人员只能提交修改缺陷或变更对应的源码供测试。可是由于缺少工具的支撑，开发人员只能手工记录、追踪变更和缺陷对应修改的源码，这种方式一是记录和追踪的工作量大，二是很容易漏提交源码。由于开发人员漏提交源码，就很容易发生测试环境的缺陷在开发环境无法重现或者已经修复的缺陷又重现的情况。
公共参数 / 基础数据 / 配置文件未进行配置管理
一些项目组未将公共参数 / 基础数据 / 配置文件等全局文件纳入配置管理。由于没有将其纳入配置管理，所以这部分全局文件的变更也同样的未进行变更管理。当这些全局文件发生变更时，很容易出现测试环境、开发环境，甚至包括生产环境配置不一致的情况。一旦出现这种情况，那么即使发布程序在内部确认测试时测试通过，但是部署到生产环境后系统运行失效的情况就在所难免。这实际上是因配置项缺失而带来的问题。
很多人可能不认为公共参数或者基础数据应该作为配置项纳入配置管理，实际上这种想法是错误的。假设没有将这些公共参数等信息纳入配置管理，那么试想一下，假设有一天系统意外崩溃，我们拿什么去恢复生产环境？所以说，系统运行支撑的所有内容（包括基础数据、配置文件等）都需要纳入配置库进行配置管理。
曾经有这样一个案例：某审批系统的公司组织机构信息是通过数据库进行维护的。项目组在处理某个需求变更时，需要相应修改公司组织机构信息，但是项目组未将组织机构的修改作为一个变更单独提出，测试组也不知道有这个潜在变更的存在。系统测试通过后如期部署上线，但是上线后发生审批流程节点出错的问题。假如项目组将这个组织机构信息作为配置项纳入配置库，它的变更也经过变更管理，那么怎么可能发生这种情况呢？
上线的源码版本组合为未经测试的版本组合
在项目已定义的发布流程中，可能因为一些看似合理的步骤，导致系统部署到生产环境后出现系统运行失效的情况。
在图一中，假设 F1 和文件 F2 在修改之前的版本都是 1，在实现了需求 1 和缺陷 1 后，版本均变为版本 2，表示为 F1（v2），F2（v2）。在测试环境测试时，测试的源码版本均为 F1 和 F2 的版本 2，但是需求 1 没有通过测试，最后只部署了缺陷 1 这个活动对应的源码到生产环境。那么部署到生产系统的版本将是 F1（v1）和 F2（v2）。F1（v1）是原来生产系统的版本，F2（v2）是包含了缺陷 1 所对应的版本。但是，和 F1（v1）匹配的版本组合应该是 F2（v1），和 F2（v2）匹配的版本组合应是 F1（v2）。这时上线带来的结果是在生产系统上运行的是未经测试的版本组合。这潜在的质量陷阱可能导致发布时系统运行失效的情况。
图一：未经测试的版本组合示意图
上线的源码版本为未经测试的版本
除了上线的源码版本组合是未经测试的版本组合这种质量陷阱外，在发布流程中，还可能存在另一种质量陷阱。
在图二中，假设文件 F1 和文件 F2 在修改之前的版本都是 1，在实现了需求 1 后 F1 的版本变成了 2，F2 的版本为 3。开发任务 1 在需求 1 修改的基础上进行了开发，生成 F2（v4）。在测试环境测试的源码版本为 F1（v2）和 F2（v4）。但是开发任务 1 没有通过测试，最后部署到生产系统的版本将是 F1（v2）和 F2（v3），F1（v2）和 F2（v3）是包含了需求 1 所对应的版本。但是，F2（v3）是未经过测试的版本，这潜在的质量陷阱也可能导致发布时系统运行失效的情况。
图二：未经测试的版本示意图
为了避免上述的问题的产生，笔者从以下七点出发给出测试过程中配置管理问题的解决方案。
选取合适的配置管理工具
整理配置项，明确相应管理流程
将配置项作为一个整体进行配置管理
增加发布前验收测试环节
采用并行开发方式区分不同的开发活动
定制文件开发方式
明确角色与职责
选取合适的配置管理工具
为了能让开发人员不用手工记录和追踪缺陷修改的源码，我们引入 IBM Rational ClearCase。通过使用 ClearCase 的 UCM 模式，我们实现了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。UCM（统一变更管理）是 IBM Rational 提出的用于管理软件开发过程（包括从需求到版本发布）中所有变更的“最佳实践”流程。UCM 通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。通过 UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了项目成员手动跟踪所有文件变更（见图三）。
图三：活动变更集图
文章来源于领测软件测试网 https://www.ltesting.net/