一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。

目标

1、控制和审计测试活动的变更；

2、在测试项目的里程碑建立相应的基线；

3、纪录和跟踪测试活动变更请求；

4、相应的软件测试活动或产品(work products)被标识、控制、并是可用的

承诺执行

承诺1：每个测试项目的配制管理责任明确；

承诺2：配置管理贯穿项目的整个测试活动；

承诺3：配置管理应用于所有的测试配置项，包括支持工具；

承诺4：建立配置库和基线库(Baseline)；

承诺5：定期评审基线库内容和测试配置项活动

需要纳入配置管理的项

项目测试过程中会产生许许多多的工作成果，例如测试计划文档、测试用例以及自动化测试执行脚本和测试缺陷数据等，他们都应当被保存起来，以便查阅和修改。这些纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

要进行管理的配制项包括：

测试合同信息：《软件测试技术合同》、《软件委托测试合同》和《保密合同》；

被测软件资源如：《用户手册》、《规格说明》等；

测试文档模板以及测试过程中产生的系列文档和测试数据：

软件配置项任务：

• 指明配置项的功能特性和物理特性，编制文 档，并建立配置项的标识体制；
• 控制对这些特性的更改；
• 记录、报告更改处理以及执行状态；
• 对配置进行检查和评审等。

a. 在制定每一基线时，把基线要求受控的软件实体标识为软件配置管理项，并为每个软件配置管理项赋予唯一的标识符；

b. 要确定全部文档的格式、内容和控制机构，以便在配置管理各层次中追溯；

c. 用一种编号法提供软件配置管理项的信息，以便对全部产品文档和介质指定合适的标识号；

d. 标识方式要有利于软件配置管理项的状态控制，便于增、删和更改；

测试过程角色和活动：

测试描述性表示：（测试过程中的文档和资料）软件测试的计算机表示（测试代码/数据/结果）

软件测试需求；

软件测试角色：测试需求分析

输入： 1）软件测试的方法与规范

2）软件需求规格说明、

3）软件设计说明（概要设计说明和详细设计说明）

4）《软件用户手册》

输出：软件测试计划：

软件测试过程设计

软件测试角色：测试过程设计

输入：1）测试方法和规范；

2）软件测试计划； 输出： 软件测试说明包括： a、软件测试步骤； b、软件测试基准； c、软件测试用例。

软件测试实施

软件测试角色：软件测试实施；

输入： 1）测试方法和规范； 2）软件测试计划；

3）软件测试用例；

输出： 1）测试运行结果表示；

2）测试自动化脚本/测试数据；

3）测试日志；

4）软件问题报告

软件测试评估

测试角色：软件测试评估

输入：1）《软件用户手册》

2）软件测试文档

3）软件测试配置

4）软件测试记录

输出：软件测试报告：1) 测试结果的统计信息；

2) 测试结果的分析/评价

测试配置管理：

1）软件测试配置管理项的标识管理

2）软件测试配置管理项的存储管理

3）软件测试配置管理项的引用控制

4）软件测试配置管理项的版本控制

5）软件测试配置管理项的变更控制

测试配置项状态变迁规则：

配置项的状态有3种：“草稿”（Draft）“正式发布”（Released）和“正在修改”（changing）

草稿

评审或审批

正式发布

正在修改

自由修改

否决

通过

变更控制

测试配置项刚纳入版本控制时其状态为“草稿”，有的状态为“正式发布”，这些测试配置项通过更改评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。

配置项版本号规则：配制项的版本号与配置项的状态紧密相关

测试配置管理步骤

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、对于需要变更的元素如：测试用例、测试数据、自动化脚本，应按照配置项变迁更改规则进行： 待变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）。此时对其变更的主要步骤：

1、）变更申请

变更申请人提交变更申请，重点说明“变更内容”和“变更原因”；变更申请人员必须是测试项目的成员。在此的变更主要涉及到《软件测试计划》、《软件测试用例》、《自动化执行脚本》、以及《测试报告》。

2）审批变更请求

当对已经做了变更的配置项进行再次变更时，需要再次进行变更审批，并分析此变更对项目造成的影响。如果同意变更，则转向步骤3

3）安排变更任务

指定变更执行人、安排任务；

4）执行变更任务

变更人根据安排的任务，修改配置项。

管理员监督变更任务的执行，例如检查变更内容是否按时按量完成等。

5）对变更后的配置项重新进行技术评审

通过审批后转向步骤6 ，否则转向步骤4 （重新修改）

6）结束变更，是配置管理项成为“正式发布”或“冻结”。

当所有变更后的配置项都通过了审批，这些配置项的状态从“正在修改”变迁为“正式发布”。