软件测试之测试过程中的配置管理

7. 上线的源码版本为未经测试的版本

　　除了上线的源码版本组合是未经测试的版本组合这种质量陷阱外，在发布流程中，还可能存在另一种质量陷阱。

　　在图二中，假设文件 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）是未经过测试的版本，这潜在的质量陷阱也可能导致发布时系统运行失效的情况。

　　解决方案

　　为了避免上述的问题的产生，笔者从以下七点出发给出测试过程中配置管理问题的解决方案。

1. 选取合适的配置管理工具
2. 整理配置项，明确相应管理流程
3. 将配置项作为一个整体进行配置管理
4. 增加发布前验收测试环节
5. 采用并行开发方式区分不同的开发活动
6. 定制文件开发方式
7. 明确角色与职责

　　选取合适的配置管理工具

　　为了能让开发人员不用手工记录和追踪缺陷修改的源码，我们引入 IBM Rational ClearCase。通过使用 ClearCase 的 UCM 模式，我们实现了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。UCM（统一变更管理）是 IBM Rational 提出的用于管理软件开发过程（包括从需求到版本发布）中所有变更的“最佳实践”流程。UCM 通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。通过 UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了项目成员手动跟踪所有文件变更（见图三）。

文章来源于领测软件测试网 https://www.ltesting.net/