软件测试过程中的配置管理[5]

        软件测试过程中的配置管理[5]   软件测试　

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

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

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

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

　　增加发布前验收测试环节

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

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

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

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

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