测试过程中的配置管理

测试过程中的配置管理

作者: 沈雪芳    来源: IBM

　　软件测试需要进行充分的测试准备，需要科学的，规范的测试过程管理。有效的配置管理对跟踪和提高测试质量和效率起到十分重要的作用。测试过程中的配置管理工作不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本。但是在实际软件测试工作中，配置管理并没有得到相应的重视。

　　软件测试的“泥潭”

　　可能有读者会觉得奇怪，软件测试就是发现软件中隐藏的缺陷，和配置管理有啥关系呢。但是，不知道大家在实际工作中有没有发现，我们在软件测试工作中碰到的一些问题，实际上就是由于配置管理工作没做好而产生的。

　　在软件测试工作中，我们经常碰到以下三个问题：

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

　　产生原因

　　不考虑缺陷报告描述不清楚这种情况，究其原因，上述三个问题的产生主要有以下七点原因：

测试环境配置的复杂性
　　由于不同（版本）的操作系统、不同（版本）的数据库，不同（版本）的网络服务器、应用服务器，再加上不同的系统架构等组合，使得要构建的软件测试环境多种多样、不胜枚举；而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要，使得构建软件测试环境的工作变得较为复杂和频繁，而软件测试环境的构建是否合理、稳定和具有代表性，将直接影响到测试结果的真实性、可靠性和正确性。在笔者曾经做过的一个项目中，由于测试环境使用了和开发系统不同版本的 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，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了项目成员手动跟踪所有文件变更（见图三）。

图三：活动变更集图
 
ClearCase 管理员利用 ClearCase 提供的命令进行二次开发，可实现获取某个指定活动或一批活动变更集包含的源码集合（见图四），这为开发人员提交开发活动变更集包含的源码集合，测试人员 / 配置管理员增量更新测试环境、生产环境提供了方便。

图四：获得活动包含变更集图
 

　　整理配置项，明确相应管理流程

　　为了避免因配置项缺失导致开发环境、测试环境和生产环境的不一致，我们需要对系统中所有的配置项（如公共参数 / 基础数据 / 配置信息等）进行整理，明确各种类型配置项的存放方式、控制流程。例如：某项目的 SQL 建表文件、UNIX 操作系统的配置参数文件属于系统的全局文件，其存放方式为文本文件。根据项目测试与配置管理要求，项目相关负责人针对全局文件定义了相应的控制流程（见图五）。

图五：某项目全局文件控制流程图
 

　　同样的，对于源码这类文件，我们也需要规范相应的管理流程。通过使用 ClearCase UCM 方式，开发人员在修改源码时，可以使用 ClearCase 的“处理活动”功能，快速切换当前处理的活动，使他们可以选择正确的活动进行源码修改。采用 UCM 方式的好处之一，就是项目成员对于配置库的修改必须有活动关联，如果没有分配给操作用户的活动，用户就无法对配置库进行任何修改。这对于正在运行的系统而言，源码的修改获得批准是非常重要的。

　　将配置项作为一个整理进行配置管理

　　配置管理工作是整个软件开发过程的生命线，对于测试人员来讲，由于测试产品与开发产品之间的密切关系（参见“产生原因”一节），测试人员必须得到自己关心的程序的任意一个测试版本，以便可以在正确的版本上执行正确的测试用例。

　　由于上述原因，我们需要将配置项作为一个整体进行配置管理，方便进行测试版本的回溯。我们可以通过 ClearCase 的基线来实现这个功能。UCM 将项目活动嵌入到各个基线中，这样测试人员可以确切地知道他们将测试什么，而开发人员则确切地知道其他开发人员做了什么。在其他一些配置管理工具中，基线只是一个文件版本的快照，并没有将该快照关联修改这些文件对应的活动。

　　增加发布前验收测试环节

　　由于缺少独立的发布前的确认测试环节，而将程序潜在的质量陷阱（见图一和图二）遗留到在生产环境部署后才爆发。为了避免这种风险的发生，笔者建议在项目的配置管理流程中增加发布前验收测试环节。所有上线的发布包，必须将上线包在发布前验收测试环境中进行验收测试。待验收测试通过后，方可在生产环境部署（见图六）。

图六：某项目变更与发布流程图
 

　　采用并行开发方式区分不同的开发活动

　　在项目实际开发中，开发人员会面临不同类型的开发活动，如变更、缺陷、新增特性等。而不同类型的开发活动，它的紧急程度不一样，如果将这些开发活动混在一起工作，那么可能因为版本间的依赖影响项目的上线进度。另外，这种工作方式也会影响项目测试工作的开展。由于上线计划可能只包含部分开发活动，导致测试环境有不同上线阶段的开发活动需要测试，这种方式无形中增加了运行在生产环境的源码组合为未经测试的版本组合（见图一）和未测试的版本（见图二）的几率。

　　针对这种情况，笔者建议将不同类型的开发活动按照紧急性或类型将工作区分开来，这就涉及多个版本的并行开发，如项目 V1.0 的缺陷修复、V1.0 的新增功能版本 V1.1、新版本 V2.0。IBM Rational ClearCase 可以很好的支持这种并行开发模式。在 ClearCase 中，我们可以在项目 V1.0 的发布基线（V1.0_rel01_20071101）的基础上分别创建针对三种版本（V1.0_bugfix、V1.1、V2.0）的开发项目（见图七）。在 ClearCase 管理下，这三种版本位于不同的分支下，他们的开发是独立的，互不影响，并且版本 V1.0_bugfix 中的缺陷修复可以及时的合并到版本 V1.1 和 V2.0 中，版本 V1.1 的新增功能也可以在需要的时候合并到版本 V2.0 中。

图七：ClearCase 实现并行开发模式图
 

　　定制文件开发方式

　　在项目实际开发中，通常需要对文件进行并行开发，因此存在因为多人同时修改同一个文件而需要对文件进行合并的情况。对于大部分格式的源码，配置管理工具都提供不同程度的自动合并功能。但是对于不能合并的二进制文件或不允许合并的文本文件（例如通过第三方开发工具导出的文本文件，ClearQuest 模式文件等），就不适合使用并行开发方式。因为这些文件或者不能合并，或者是不能通过简单的合并来实现版本的合并。对于这类文件如果处理不当，就会导致测试时使用了错误内容的版本，导致测试不通过。

　　但是，在项目实际开发中又不能因为存在这类特定类型的文件，而限制使用并行开发方式。串行开发与并行开发是矛盾的，如何解决这个问题是存在这类文件的项目在开发和测试过程中很头痛的一个问题。IBM Rational ClearCase 可以很好的解决这个问题。我们可以利用 ClearCase 提供的强大的二次开发功能，为这些不能进行合并的二进制文件或不允许合并的文件创建特定的文件类型。在执行检出操作时，判断该文件是否属于已定义的特定类型文件。如果是，则判断该文件是否已经被检出。如果已经被检出则不允许执行检出操作。通过这种方式，我们既可以保证大部分的源码可以进行并行开发，又能解决这类特定类型文件的串行开发问题。

　　明确角色与职责

　　在整个测试过程与配置管理过程中，要非常清晰项目的角色划分，及角色对应的职责，并要求相关角色人员严格履行各自的职责。某个大型已上线系统在进行升级时就有过一次因角色与职责混淆的教训。在这次升级上线手册中有“检查四个参数 A、B、C、D”这么一个步骤，测试人员在测试时发现测试环境因没有这四个参数而导致了测试失败，于是测试人员联系开发人员，得知创建这四个参数的方法，以及需要设置的参数值。然后测试人员在测试环境自行创建了这四个参数。由于正确设置了这四个参数后，此次升级测试通过。当该升级包提交运维组部署到生产环境时，运维组按照上线手册要求检查了生产环境，发现生产环境有这四个参数（但不是开发人员期望设置的值），并且有测试组提供的测试报告，于是他们将升级包按照上线手册步骤部署到生产环境。但是上线后由于这四个参数设置了错误的值，导致系统停产 40 多分钟。

　　在这个事故中，开发人员与开发人员都有责任。测试人员未按照上线手册要求完成他的工作（只是“检查”，而不是“创建”），这本身就是一个违规操作。另外，他没有将实际情况与上线手册的不一致向开发组提出并由开发组更新上线手册，在开发组提交更新后的上线手册后，测试组重新检查测试环境并测试。开发人员则未在上线手册写明参数具体设置的值，上线手册存在不明确信息。

　　所以在项目的各个过程，包括软件测试过程和配置管理过程中，一定需要明确各角色相应的职责及工作范围，避免类似事故的发生。

　　总结

　　配置管理贯穿于项目所有过程中，本文主要从软件测试的角度分析了测试中经常碰到的问题，阐述了软件测试和配置管理之间的密切关系。为了解决测试中存在的配置管理问题，笔者针对测试过程常见问题产生的原因，从配置管理角度给出了相应的解决方案。笔者希望通过本文，能够改变软件测试工作中不需要关注配置管理的错误思想。

原文转自：http://www.ltesting.net