借配置之力淌过软件测试的“泥潭”(2)

 

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

在图2中，假设文件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，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了项目成员手动跟踪所有文件变更（见图3）。

 

 

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

 

 

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

 

 

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

 

共3页: 上一页 [1] 2 [3] 下一页

【内容导航】