摘要：随着CNAS CL45-2013的发布，第三方软件测评实验室将配置管理正式纳入管理体系。相对于软件开发过程的配置管理，软件测试过程的配置管理有其自身的特点。本文从软件测评机构的立场出发，阐述了测试项目的配置管理过程及其活动。
1、适用范围
本文所指的配置管理适用于软件测评机构的所有测试项目。
2、术语及定义
（1）配置管理：Configuration Management，简称CM，是采用技术手段和行政手段进行管理和监督的一套规范化方法。它包括对配置项的功能特性和物理特性加以标识，并将其文件化；控制这些配置项特性的变更；记录和报告配置项的状态和变更实施情况；保证配置项的完整性、正确性和与需求的一致性；控制配置项的储存、装载和交付。
（2）配置项：Configuration Item，简称CI，指配置管理中受控制的对象，是软件生命周期中创建的信息，包括各类管理文档、评审记录和文档、软件文档、源码及其可执行码、运行所需的系统软件和支持软件以及各种有关数据等。配置项是配置管理的最小单元。
（3）配置项标识：Configuration Item Identification，能保证配置项的可追溯性和唯一性的名称。
（4）开发库：Development Library，用于存放项目期间处于开发状态的相关文档和代码，以及存放项目组工作期间的相关沟通记录等，并为变更实施提供工作空间。项目配置管理员不对其中的内容进行控制，其中存放的内容由项目负责人负责。
（5）受控库：Controlled Library，建立以用来存放项目中通过评审形成基线的配置项的库。项目配置管理员对其中存放的内容负责。
（6）产品库：Product Library，建立以用来存放最终发布产品的库。组织级配置管理员对其中存放的内容负责。
（7）基线（Baseline），也称为里程碑(milestone)，是已经正式通过审核批准的某规约或产品，可作为进一步开发的基础，并且只能通过正式的变更控制过程改变。
（8）变更管理：Change Management，是软件配置管理的一个要素，由评估、协调、批准或不批准以及对正式构造配置标识的配置项实施变更等活动组成。
（9）配置审计：Configuration Audit，指在配置标识、配置控制、配置状态记录的基础上对所有配置项的功能及内容进行审查，以保证软件配置项的可跟踪性。
......
3.3、配置项版本号规则
版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种："草稿"（Draft）、"正式发布"(Released)、"正在修改"(Changing)。
配置项的版本号规则与配置项的状态相关。
（1）处于"草稿"状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
（2）处于"正式"状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为"正式"文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，……。当附件的变动积累到一定程度时，配置项豹Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。一般，控制库中配置项变更时，X不便，Y值适量增加；产品库中的配置项变更时，直接增大X值。
（3）处于"修改"状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为"正式"时，将Z值设置为0，增加X.Y值。参见上述规则（2）。
3.4、配置库目录
配置库一般分为开发库、受控库、产品库三个物理配置库。开发库、受控库、产品库之间的关系如图1所示。其中，开发库存放测试产生的相关数据，包括测试数据和测试记录等；发布只针对产品库而言；产品库为组织级别的，由组织级的配置管理员管理，项目的配置管理员不参与管理。
图1 配置库间的关系
为更好的进行配置管理活动，软件测评机构可以规定使用统一的配置库结构、基线名称、配置项。项目实施过程中，允许根据项目实际定义的基线进行裁剪。项目的配置库目录结构须在《配置管理计划》中说明。
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
