正在修改
自由修改
否决
通过
变更控制
测试配置项刚纳入版本控制时其状态为“草稿”，有的状态为“正式发布”，这些测试配置项通过更改评审(或审批)后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审(或审批)时，其状态又变为“正式发布”，如此循环。
配置项版本号规则：配制项的版本号与配置项的状态紧密相关
测试配置管理步骤
1、识别软件测试所需的过程及其应用，即测试需求、测试设计、测试实施、测试评估，并根据这一测试流程让配置管理员(项目经理)创建相应的配置库，并为每个项目用户分配操作权限。一般地，项目用户拥有Add、Checkin/Checkout、等权限。但是不能拥有“删除”权限。随后由配置管理员制定并执行更改申请程序流程、文档更改程序流程，实施配置控制，将相应的配制管理项添加到管理工具中进行管理，此时
1)测试项目组成员根据自己的权限操作配置库，例如Add、Checkin/Checkout、等对配置管理相进行操作。
2)配置管理员根据“基线计划”创建与维护基线，“冻结配置项”，控制变更。
3)配置管理员定期清除配置库里的垃圾文件。
4)配置管理员定期备份配置库。
5)配置管理员为每一配置项指定相应的标识。
6)制定基线计划：配置管理员确定每个基线的名称(标识符)以及主要配置项，估计每个基线建立和提升、推荐的时间。
2、 确定配置过程所需的准则和方法，制订这些过程形成文件的程序，以及监视、测量和控制的准则和方法;
3、对于加入配置管理的文档、数据，项目组成员使用配置管理软件Checkout/Checkin功能，可以自由修改处于“草稿”状态的配置项(不受变更控制约束)，并指定其版本号。当项目组成员进行检出/检入(Checkout、Checkin)操作时，必须为每一次的操作做一注释，以方便其他人员对此文档或者数据的操作。如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理的审批。如果配置项通过了技术评审或领导审批则配置管理员或项目组成员应予以标示。例如在ClearCase LT中Check-out一个文件时，ClearCase就会在视图中创建该文件的一个可编辑的版本，可以对该文件进行修改;Check-in一个文件时，ClearCase就在VOB中创建该文件的一个新的永久的版本，本地视图中对应的文件就会变成只读属性，无法修改。Check out 时有两种类型的检出操作：保留型检出和非保留型检出。保留型检出操作意味着检出动作者能够被保证第一个做检入操作。非保留型检出并不保证你是下一个检入操作者。对于同一文件，可以存在任意个数的非保留型检出。
4、对于需要变更的元素如：测试用例、测试数据、自动化脚本，应按照配置项变迁更改规则进行： 待变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分(即被“冻结”)。此时对其变更的主要步骤：
文章来源于领测软件测试网 https://www.ltesting.net/