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 中。

　　定制文件开发方式

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

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

　　明确角色与职责

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

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

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

　　总结

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