软件测试配置管理 软件测试
一、软件测试配置管理
一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。
目标
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）测试日志； [Page]
4）软件问题报告
软件测试评估
测试角色：软件测试评估
输入：1）《软件用户手册》
2）软件测试文档
3）软件测试配置
4）软件测试记录
输出：软件测试报告：1) 测试结果的统计信息；
2) 测试结果的分析/评价
二、配置管理变更的关键路径的方法
配置管理来源于硬件系统。例如PC行业中，每一台PC由主机和显示器等构成，而主机又由CPU、主板等构成，对这些构件配置情况进行管理，就是硬件的配置管理。在软件行业，计算机软件由编译后的代码和相关的一系列文档组成。但构成软件的部件的变化是跟随软件产品的开发周期而不断变化的。就频率和程度来说，软件的变化远远大于硬件。因此，软件配置管理是一套管理软件开发和软件维护的方法和规则，其最终体现的是维护软件产品的一致性和完整性。
变更常有
笔者所在银行科技部已经建立了比较完善的项目管理体系和质量保障体系，但要应对分行或支行需求变更和相关软件版本配置管理的问题，如果没有一整套的解决措施和工具的支持，就会出现以下问题：
1)分行反映的缺陷更改不能快速响应，不能快速分配缺陷到指定的开发人员，只能依靠口头或文档的传输，缺乏一个整合开发商服务人员、产品经理(或项目经理)、开发团队领导、开发人员、分行领导的信息传递和交流的平台。
2)分行的需求变更不能快速响应。分行的需求变更和软件版本配置只能依靠手工备份，因而，自身不能快速有效地管理各系统的版本，缺乏版本基线的管理策略。
针对以上问题，可以考虑采用软件配置管理这一关键域的思路系统地解决以上问题。配置管理是整个集成软件项目正常运作的一个管理支撑平台，其目的就是将有关该项目的客户、客户服务人员、产品经理(或项目经理)、开发团队领导、开发人员、高层领导等项目干系人的工作协同起来，实现高效的沟通，及时地共享工作成果。
配置管理的基本功能包括配置标识、变更控制、配置状态发布和配置审计。变更控制是配置管理的重要内容，其目的是为了在动态中保证配置项的完整性、一致性和可回溯性，保证配置项的变更过程规范、受控、有完整记录，受影响的各方均能及时了解情况，并协调一致。
控制不可少
变更控制是通过创建产品基线，在产品的整个生存周期中控制它的发布和变更。配置控制指在配置项标识正式确定之后，对配置项特别是对已提交的代码、相关文档和数据等的变更进行系统地跟踪和控制的过程，主要包括变更的提出、确定配置项的控制等级、变更的评价、变更的处置、实施经批准的变更、对变更进行验证和结束变更。变更控制的目的是建立一套控制软件修改的机制，保证生产符合质量标准的软件和保证每个版本的软件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以确定在变更控制过程中控制什么，如何控制，谁控制变更、何时接收变更、批准和检验。
配置项级别
1)已基线化的配置项是指已完成该配置项的审核和批准，并且成为创建或修改其他配置项的输入。例如：一个设计文档已审核、通过、签发，并且成为编码活动的基础。
2)受管理和受控的配置项是指已提交审核，但还没有批准通过的配置项。例如：一个正在进行审核的设计文档。
3)受控的配置项指已置于版本控制，但项目组不能直接进行改动的配置项。例如：用户提供的软件、购买的工具、产品标准等等。
变更请求的状态
软件变更、软件优化和软件bug都是产生变更的原因。变更申请人(用户或产品经理)提出变更时，首先要对受控的配置项的修改提出一个变更请求，说明对软件变更的需求。这是因为变更控制过程是通过变更请求的流动来实现的，而且对软件的任何请求都必须和相应的变更请求对应。
变更请求的状态包括：
1)提交：变更请求提交给配置管理员；
2)拒绝：变更控制委员会拒绝变更请求；
3)接受：变更控制委员会接受变更请求；
4)挂起：变更请求被挂起，以后再作决定； [Page]
5)已验证：更改已执行和验证；
6)关闭：验证并归档配置项，更新的配置项提交给用户(例如：通过版本发布)。
变更请求的类型
1)增强型：变更请求要求对已批准的项目功能进行增强。
2)改进型：变更请求不会造成功能更改，但使配置项的维护更加有效率。
3)纠错型：变更请求对错误进行修正(诸如bug)。
变更请求的优先级
在评价变更请求的优先级时，要对请求变更的配置项进行系统的分析，确定变更影响范围和修改的程度，确定变更的级别，为确定是否有必要记录变更提供参考依据。变更请求的优先级可分为三类：
1)高：严重地影响一些用户或许多用户。
2)中：对用户造成不方便，或是可以采取相应的变通方法处理的主要问题。
3)低：小问题。
修改完后签入（Check in）
对变更的处理，要按照变更控制规程，将变更请求及其相关附件提交软件配置控制委员会审批。配置管理组根据审批意见处理变更请求。
只有配置管理员具有Check in权限。在进行Check in之前，确认下面的事项：
1)所有对配置项所做的修改被批准；
2)所有的更改都经过审核或验证；
3)所对应的变更请求已经被保存起来；
4)所有相关的审核记录被保存；
5)Check in时须注明Check in原因，如对应的变更请求。
从数据库中签出（Check out）
1)对于文档，配置管理员在更改审批人同意后，从配置库中Check out配置项，发给项目组成员修改。
2)Check out时须注明Check out原因，如将要修改的问题。
3) 配置管理员一定要在配置状态发布中跟踪被Check out出来的配置项。
文章来源于领测软件测试网 https://www.ltesting.net/
