第2章 嵌入式测试视角下的配置管理

俗话说得好“无规矩，不成方圆”，我们都知道，在工作中，缺少明确的规章制度、流程，就容易产生混乱。规矩是人类活动的前提与基础，我们总是要在规与矩形成的范围内活动。比如，一个项目从立项、需求分析、研发、测试、结项，一个产品从设计、研发、测试、发布、维护整个过程等一系列活动，都需要进行管理与控制，在整个过程中配置管理起了关键性作用。嵌入式产品的测试配置管理与传统软件的测试配置管理的目的虽然相同，但是在配置管理的细节上，由于嵌入式测试的特殊性，如对硬件的独特要求、对网络的环境要求、对嵌入式行业方面的隐性要求等条件的限制下，嵌入式产品的测试配置管理与传统软件测试相比还是有其独到性的。本章我们就站在嵌入式测试的视角，介绍一下测试配置管理相关的技术要求与规范。

2.1 无规矩，不成方圆

大家都知道，仅仅靠投入更多的人力、物力或其他资源，而没有明确的测试规程、配置管理要求，是很难做好软件测试的，软件的最终质量也很难保证。同时，在实际的工作中，我们都只有有限的时间、人力和资源。这个时候，测试配置管理就起到了关键性的作用，让我们的效率高起来。同样的，在嵌入式测试中，为了更高效地进行测试，我们应该对测试规程、测试资源、测试配置项等影响测试进度与质量的关键过程进行管理。据实际调查，缺少测试配置管理可能会带来严重的后果，在测试过程中，也会遇到很多问题，如文件频繁变更、测试环境（包括生产环境、交叉编译环境、测试环境等）变动较大等问题。

2.1.1 先谈谈测试配置管理

嵌入式测试与传统软件测试一样，都有一个过程，测试过程的管理显得犹为重要，过程管理已成为测试成功的重要保证。我们需要对测试活动的流程和方法进行约束，同时测试过程是软件过程的组成部分，明确自己的软件过程，才能明确自己的测试过程。接下来对测试过程的理念和测试配置管理的目标做进一步讲解。

1．测试过程的理念

1）尽早测试。

测试人员早期参与软件项目，及时开展测试的准备工作，包括制订测试计划、制订测试方案以及编写测试用例，尽早开展测试执行工作。

2）全面测试。

● 对产品进行全面的测试，包括需求、设计文档、代码、用户文档等等。

● 研发团队（包括研发人员、测试人员，有时也包括用户）全面参与到测试工作中。

3）全过程测试。

● 测试人员要充分关注开发过程，对开发过程的变化及时做出响应。

● 测试人员要对测试的全过程进行全程的跟踪。

4）独立的、迭代的测试。

在遵循尽早测试、全面测试、全过程测试理念的同时，应当将测试过程从开发过程中独立出来，作为一个独立的过程进行管理。时刻把握独立的、迭代测试的理念，减小因开发模型的繁杂给测试管理工作带来的不便。对于软件过程中不同阶段的产品和不同的测试类型，只要测试准备工作就绪，就可以及时开展测试工作，把握产品质量。

2．测试配置管理的目标

我们上面谈到了测试过程的理念，同时我们还要做好测试配置管理，既然测试配置管理如此重要，那么如何去实现软件测试配置管理的目标呢？实现软件测试配置管理目标需要以下四步：

● 第一步：在测试过程中控制和审计测试活动的变更。

● 第二步：在测试过程中随着测试项目的里程碑，同步建立相应的基线。

● 第三步：在测试过程中记录并且跟踪测试活动过程中的变更请求。

● 第四步：在测试过程中针对相应的软件测试活动或者产品，测试人员应将他们进行标识。

以上目标是在设定的条件限制下，尽可能发现和排除软件缺陷。测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象为测试阶段输出的文档类、测试工具及环境、测试过程记录、缺陷等内容。

对整个测试阶段实施配置管理时，需测试人员按照测试流程执行，具体执行的承诺如下所示。

● 承诺1：每个测试项目的配置管理责任明确。

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

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

● 承诺4：建立缺陷库、受控库、测试库。

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

根据上述描述的配置管理的目标和测试流程的执行承诺，需制定软件测试控制程序来控制整个测试阶段，规范测试配置管理。软件测试控制程序规定了测试本身的工作内容以及测试和研发的交互过程，在每个阶段要求输出相关的测试资料，如测试计划、测试方案、测试用例、测试报告等。配置管理主要对各个配置库的架构、人员职责等规定相关内容的规范，如缺陷库、受控库、测试库架构制定，缺陷生命流程规定等。其中，软件测试控制程序详见附录B“软件测试控制程序”。

2.1.2 测试配置管理的关键活动

2.1.2.1 配置管理的关键活动

配置管理有6个最基本的关键活动，分别为：

● 配置标识。

● 版本控制。

● 变更控制。

● 配置状态报告。

● 配置审计。

● 工作空间管理。

1．配置标识

配置标识是配置管理的基础，也是制定配置管理计划的重要内容。所有配置项的操作权限都应当严格管理，其基本原则是：所有基线配置项向测试人员开放读取权限；而非基线配置项向测试组长、项目经理及相关人员开放。

配置标识主要是标识测试样品、测试标准、测试工具、测试文档（包括测试用例）、测试报告等配置项的名称和类型。所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中，这样使得测试相关人员能方便地知道每个配置项的内容和状态。

2．版本控制

版本控制是配置管理的核心功能。版本控制的目的是按照一定的规则保存配置项的所有版本，统一版本命名规则，确保目标版本号的唯一性和可追踪性；避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然，如果选用的工具支持的话，这些辅助数据将能直接统计出过程数据，从而方便我们软件过程改进（Software Process Improvement, SPI）活动的进行。

对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。

3．变更控制

变更控制的目的并不是控制和限制变更的发生，而是对变更进行有效管理，确保变更有序地进行。变更管理的一般流程是：

●（获得）提出变更请求。

● 由CCB（配置控制委员会）审核并决定是否批准。

●（被接受）为修改请求分配人员，提取SCI（软件配置项），进行修改。

● 复审变化。

● 提交修改后的SCI。

● 建立测试基线并测试。

● 重建软件的适当版本。

● 复审（审计）所有SCI的变化。

● 发布新版本。

4．配置状态报告

配置状态报告就是根据配置项操作数据库中的记录，向管理者报告软件测试工作的进展情况。这样的报告应该定期进行，并尽量通过软件测试工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况。

配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能根据开发人员对配置项的操作记录来对开发团队的工作关系作一定的分析。配置状态报告应该包括以下主要内容：

● 定义配置状态报告的形式、内容和提交方式。

● 确认过程记录和跟踪问题报告、更改请求、更改次序等。

● 确定测试报告提交的时间与方式。

● 配置库的结构和相关说明。

● 开发起始基线的构成。

● 当前基线位置及状态。

● 各基线配置项集成分支的情况。

● 各私有开发分支类型的分布情况。

● 关键元素的版本演进记录。

● 其他应予报告的事项。

5．配置审计

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实地执行和实现。配置审计包括以下主要内容：

● 确定审计执行人员和执行时机。

● 确定审计的内容与方式。

● 确定发现问题的处理方法。

● 制定项目的配置计划。

● 对配置项进行标识。

● 对配置项进行版本控制。

● 对配置项进行变更控制。

● 定期进行配置审计。

● 向相关人员报告配置的状态。

6．工作空间管理

在引入了配置管理工具之后，所有开发、测试以及项目组其他人员都会被要求把工作成果存放到由配置管理工具所管理的配置库中去，或是直接工作在配置管理工具提供的环境之下。所以为了让各个开发团队能更好地分工合作，同时又互不干扰，对工作空间的管理和维护也成为了软件配置管理的一个重要的活动。

2.1.2.2 测试配置管理与配置管理的区别

测试配置管理是对整个测试过程进行管理，配置管理针对的是整个项目。测试配置管理属于配置管理的一部分，测试配置管理主要关注测试活动，按照软件测试控制流程进行管理。测试配置管理的任务主要包括：

● 制定测试配置管理计划，建立测试配置管理机构。

● 在给定时间点上对测试配置管理项进行标识。

● 系统地控制测试配置管理项的更动。

● 配置状态报告。

● 配置审计。

● 在整个软件测试期内，按规程对测试配置管理项进行存储、处理、发行管理和交付。

软件测试配置管理的活动可以归结为四个主要功能：配置识别、变更控制、配置状态统计和配置审核。其中，配置审核分为正式审核和非正式审核。在软件生命周期的关键阶段采取非正式审核，例如在开始系统设计前，一般要进行配置审核，检验需求规格配置的完整性和正确性。在软件交付客户前采取正式审核，正式审核分为功能型和物理型两种类型。功能型配置审核检验软件功能是否满足系统需求中定义的软件需求，即根据需求验证系统。物理型配置审核确定软件产品和设计文档是否符合软件合同的要求，即根据合同验证系统。

2.1.3 测试配置管理流程

嵌入式测试配置管理的流程与传统测试配置管理流程大体一致，但在细节上有特殊性。由于嵌入式测试对环境有特殊的要求，所以，嵌入式测试配置管理会对仿真测试环境、交叉编译环境、生产环境等进行过程管理。测试配置管理流程内容如下：

1）测试配置管理最重要的工作是制定测试部门测试流程。制定测试阶段的划分以及每个阶段的主要任务；制定研发和测试交互流程，方便测试管理以及与研发的沟通交流。

2）测试配置管理规范制定，主要对受控库、缺陷库、测试库的框架进行设计，并制定受控库、缺陷库和测试库的配置规范，对产品过程版本、文档资料进行严格控制。详细介绍参见附录B“配置管理规范”。

3）缺陷管理规范的制定，主要对软件缺陷的生命周期进行规定，包括缺陷如何创建与关闭、缺陷的描述、定级。目的是更好地完成产品或项目，保证测试产品的质量。

4）受控库配置管理规范的制定，主要对受控库人员角色划分、受控库框架说明、权限管理以及出入库原则进行规定，目的是对研发过程中，测试与研发的交互关系、程序版本、文档资料等内容进行严格控制。

5）规定在项目或产品的整个测试活动中输出的几类文件：计划类文件、设计类文件、报告类文件，在输出这类资料过程中，都需要对这类文件进行评审，评审通过之后，方可进行下一步工作。输出的测试资料要及时归档到受控库。

6）测试资料的管理，是测试配置管理的一个重要工作。按照各自的行业标准，制定出适合本部门的测试模板。

7）测试环境和测试工具的管理，测试环境和工具要与测试项目中输出的测试文档一样，及时进行归档和保存。

2.2 嵌入式测试配置管理案例解析

在我们日常测试工作中，如何与研发人员进行交互，发现的缺陷如何反馈给研发人员，输出的文档如何进行管理，还需要制定相关的规范对其管理，本节主要介绍缺陷库、受控库、测试库的框架说明和配置规范。

2.2.1 缺陷库规范解析

1．缺陷库的创建意义

我们为了降低缺陷修复的成本，应提前做好缺陷管理和跟踪。

缺陷库主要存放测试过程中发现的bug，以供相关人员跟踪解决，目的是更好地完成产品或项目，保证测试产品的质量。我们都知道，每款软件都有其缺陷，并且不止一个，但不是所有的缺陷都需要修复。每个缺陷反映的问题是不同的，有的严重影响软件系统运行，必须马上修复；有些功能存在缺陷，但是对系统影响很小，用户基本用不到，此类缺陷可以推迟或者不修复。严重程度和优先级是软件缺陷的两个重要指标项，在实际项目中，要结合用户实际使用情况、缺陷的影响程度，把软件缺陷按缺陷类型、缺陷级别、严重程度、优先级别进行划分。详细的缺陷管理规范参见附录B“缺陷管理规范”。

2．缺陷状态

为了更好地对缺陷进行管理，我们需要先认识软件缺陷的生命周期，如图2-1所示。

在整个缺陷生命周期中，缺陷状态主要描述测试人员提交的缺陷所处于的一种状态情况，用于评估测试和产品的现状。通过图2-1缺陷生命周期可以看出，缺陷状态分为：新建、打开、已解决、已关闭、延后解决、已否决、重新打开。具体内容说明如下：

1）新建：测试人员首次提交缺陷的状态，需要标明缺陷的严重级别等要素。由测试人员改变。

2）打开：研发负责人对新建缺陷确认后，变成打开状态时，需要同时确定缺陷优先级、解决的研发人员、填写计划修复时间、计划关闭版本。由研发人员改变。

3）已否决：研发负责人认为不是缺陷、描述不清、重复、不采纳所提意见建议，或者由于测试人员提错，从而拒绝的问题。由研发负责人来设置。

4）已解决：研发人员修改问题后所标识的状态。由研发人员改变。

5）重新打开：测试人员对缺陷状态为已解决的问题进行验证后，没有验证通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。

6）已关闭：测试人员对修改的问题进行验证后通过所标志的状态。由测试人员改变。

7）延后解决：研发负责人确定是缺陷，但该缺陷不在本阶段修复或由于外部因素等情况，延后解决。由研发负责人改变。

3．人员职责划分

在缺陷生命历程途中，对缺陷操作人员职责的具体要求如下：

测试负责人：

● 定期审核测试人员提交的缺陷。

● 定期对缺陷库进行分析，描绘出曲线图等，报告现状、预测趋势。

● 对缺陷状态为已否决、延后解决等可能影响产品质量的问题，需要实时跟踪并与项目组相关人员确认。

● 在测试总结报告中给出意见。

研发负责人：

● 确认并分配状态为新建的缺陷，同时确定缺陷优先级、解决的研发人员、填写计划修复时间，计划关闭版本。

● 有否决性质和延后解决性质的缺陷可召集项目组成员（测试负责人、研发负责人、项目/产品经理）会议讨论最终状态。

● 有可能是需求的问题，分配给产品经理。

项目/产品经理：

● 把握缺陷修复的整体情况，确认研发人员所分配的缺陷修改优先级别是否准确。

● 确认已否决和延后解决的缺陷是否合理，如果有意见，可与项目组成员一起商量定夺，确定最终的缺陷优先级和处理意见。

测试人员：

● 发现并提交缺陷，提交测试过程中发现的问题，并按照规范编写报告。

● 时时跟踪自己所提交的缺陷情况，直至关闭。

● 对于缺陷更改等不清楚的问题，与测试负责人及时交流。

研发人员：

● 确认分配给自己的问题并安排时间修复。

● 修复完成后，把缺陷状态改为已解决，并在注释中添加缺陷产生原因及解决方法。

4．缺陷的类型

在缺陷汇报时，我们首先要弄清楚不同的缺陷都属于什么类型。一般软件缺陷类型包括以下内容：需求缺陷、设计缺陷、结构缺陷、系统结构缺陷、测试设计与测试执行缺陷、功能类缺陷、性能类缺陷、系统/模块接口类缺陷、用户界面类缺陷、数据处理类缺陷、流程类缺陷、提示信息类缺陷、软件包类缺陷、建议类缺陷、常识类缺陷、文档缺陷。

● 需求缺陷包括：需求有误、需求逻辑错误、需求不完备、需求文档描述问题和需求更改，这些问题会导致软件出现缺陷。

● 设计缺陷包括：设计不合理、设计文档描述问题、设计变更等带来的问题。

● 结构缺陷包括：控制流和控制流顺序错、处理错。

● 系统结构错误包括：操作系统引用或使用错误、软件结构错误、恢复错误、执行错误、诊断错误、分割覆盖错误、引用环境错误。

● 测试设计和测试执行错误包括：测试设计错误、测试执行错误、测试文档有误、测试用例不充分、其他测试错误，在测试设计出现错误会影响软件整个测试过程的思路，会导致严重问题被遗漏，给软件带来比较严重的损失。

● 功能缺陷包括：影响各种系统功能、逻辑的缺陷；冗余的功能、所实现的功能与实际要求不符、功能使用性、方便性、易用性不够。

● 性能缺陷包括：不满足系统可测量的属性值、事物处理速率、并发量、响应时间。

● 系统模块接口缺陷包括：与其他组件、模块或设备驱动程序的接口不对应的问题。

● 用户界面缺陷包括：影响用户界面、人机交互特性、用户输入灵活性、界面不美观、格式不统一等缺陷。

● 数据的处理类缺陷包括：数据有效性检测不合理、数据来源不正确、数据处理过程不正确。

● 软件业务流程类缺陷包括：业务流程控制不符合要求、业务流程实现不完整。

● 提示信息类缺陷包括：提示信息重复或不合理、提示信息格式不符合要求、提示框返回焦点停留位置不合理。

● 软件包类缺陷包括：软件配置库、变更管理和版本控制引起的错误。

● 建议类缺陷包括：功能性建议、操作建议、说明建议。

● 文档类缺陷包括：影响发布和维护的缺陷，包括注释、用户手册、设计文档。

5．缺陷严重程度

严重程度，顾名思义就是软件缺陷对软件质量的破坏程度，即：此软件缺陷的存在将对软件的功能和性能产生影响的程度。

在软件测试中，软件缺陷的严重程度应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。按照缺陷引起的故障对软件产品的影响程度，缺陷的严重级别大体别分为：紧急、高、中、低四个级别。

紧急级别缺陷是由于致命错误导致无法进行测试，或导致测试严重受阻的缺陷，如：

● 系统崩溃或死机。

● 数据库发生死锁。

● 安装卸载问题，如安装包安装不成功，无法正常使用。

● 应用模块无法启动或异常退出，如某模块启动失败，导致整个模块不可测试。

● 内存泄露。

● 严重花屏导致无法测试。

● 导致用户数据丢失或破坏。

● 功能设计与需求严重不符。

● 系统不稳定，如一定条件下系统重启、关闭等。

● 系统进程反复重启或异常退出。

高级别缺陷是较严重错误，必须立刻通知研发人员，但对其他用例的执行影响不太大，如：

● 主要功能错误但可以运行，如次要界面503错误；次要界面跳转错误；无法修改密码。

● 数据通信错误，如传输大文件时连接中断；数据传输时丢包率严重；多个应用协议同时传输时导致某个协议中断；或大量策略导致无法通信；较严重的安全性问题，如DDos攻击时其他业务无法正常使用。

● 业务流程错误或不完整。

● 关键性能不达标。

● 兼容性问题，如浏览器支持问题，驱动不兼容问题。

● 程序接口错误。

● 数据库的表、业务规则、缺省值未加完整性等约束条件。

中级别缺陷是次要功能未实现或与需求不符，不影响业务继续开展，但造成使用障碍，如：

● 模块部分功能点有缺陷，但不影响使用，如一些插件未添加开关功能；修改密码后没有相应提示。

● 初始化未满足客户要求或初始化错误，如打上升级包后程序版本没有相应更新；默认情况下日志没有关闭。

● 日志记录不正确或应记录而未记录。

低级别缺陷是装饰性或易用性问题，如：

● 个别不影响产品理解的错别字。

● 操作时未给用户提示。

● 辅助说明描述不清楚。

● 文字排列不整齐等。

6．缺陷的优先级别

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多情况是站在软件研发人员的角度，该级别建议由研发人员自己定义。因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

优先级别划分由研发负责人在分配新建缺陷时指定，产品（项目）负责人或经理可参与定夺。由于软件行业不同，还需根据每个行业的特点来定义缺陷优先级。通常优先级别的定义参考该缺陷的严重程度，如：

● 紧急级别缺陷应阻止相关研发人员的进一步开发活动，立即进行本缺陷的修复工作。例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。

● 高级别缺陷应在本次迭代周期内修改完成。例如，影响软件功能和性能的一般缺陷。

● 中级别缺陷需要在本次迭代周期内修改完成，但不排除放到下一周期内解决，但需要项目组讨论决定。例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。

● 低级别缺陷是项目完成前修改，或根据实际项目情况，择时修改。例如，对软件的质量影响非常轻微或出现几率很低的缺陷。

缺陷生命历程中，操作人员职责确定之后，还要制定缺陷库的相关配置规范，具体规范如下：

1）根据现有项目，配置管理员创建缺陷库，并设置项目用户和权限。

2）设置缺陷库的相关属性。根据现有缺陷库工具，设定出合理的缺陷属性。

3）规定测试人员提交缺陷的书写格式。Bug的详细描述要达到让研发人员清楚这是一个什么问题，看了以后能够自己复现的程度，所以要详细但要避免冗余。缺陷的编写规范要包含以下几点：

● 测试配置：主要是产品或相关测试要件的配置。

● 测试环境：测试所搭建的软件、硬件、数据环境。

● 测试步骤：这是比较关键的，目的是帮助研发人员重现缺陷，需要列出1、2、3等步骤项，或者指明对应的测试用例。

● 预期结果和实际结果：将这些结果写到描述中，不但能够做对比，而且能够有效证明这确实是一个bug。

除了上述描述外还应注意如下事项：

● 一个缺陷记录只能描述一个bug。

● Bug的唯一性：在提交bug之前，要确认这个bug是否已经被其他人发现并报告（搜索功能）。

● 重现：有些bug很容易就重现，有些就很难。如果你能重现一个bug，应该准确地解释必要的条件。应该列出所有的步骤，包括精确的组合、文件名以及你碰到或重现这个问题的操作顺序。如果你能够确认这个问题在任何文件、任何操作顺序等条件下都会发生，那也最好能够给出一个明确的示例来帮助研发人员重现。如果发现一个不能重现的bug，就尽可能多地提供有效的信息给研发人员。截图、日志、抓包等对捕获这个bug有帮助的信息可以包含在你的bug报告中。

● 定位：对于一个测试人员来说，应该做一些有效的事情来帮助定位问题。要多想会不会是外部的什么特殊原因引起的这个问题？会不会是因为网络的原因导致的问题？或者是应用软件配置错误导致的问题？如果实在不能定位问题原因，是否可以想办法缩小出错的范围？尽量避免是由于测试人员的问题导致误报了bug。测试人员定位bug的能力，一定程度上是测试人员附加值的体现，能够节省项目组相关人员的时间，缩短回归bug的时间。

● 报告bug时要使用中性语言，不要带有感情色彩。不要带有幽默也不要带有任何不满情绪。

4）为了防止缺陷库遭到未经授权的访问和操作，可以将缺陷库成员分配到指定的用户组，用户组权限设置如表2-1所示。

2.2.2 受控库规范解析

创建受控库的目的是对研发过程中，测试与研发的交互关系、程序版本、文档资料等内容进行严格控制。接下来将从受控库框架、权限管理、受控库出入库原则、产品归档与备份、研发和测试交互流程以及人员角色分配来说明受控库的管理和实施。受控库的管理规范详见附录B“受控库配置管理规范”。

1．受控库框架说明

受控库框架如图2-2所示。

框架图说明：

1）受控库以产品或者项目为单位进行管理，使用SVN软件对受控库进行搭建。

2）install-package：此处提交安装包，提交时，以安装包产品版本标识命名的方式创建文件夹；每次版本提交都应该提供框架图中的几类内容，如安装包、安装说明文档、更新说明（新增功能、修复的问题或BugID、遗留问题、文件MD5值）、自测报告，如需要，则提供该版本有关风险评估的说明或在更新说明中附加。

● 安装包：安装包的打包按照公司发布的相关版本命名规范进行命名，不得随意命名。

● 安装说明文档：对于提交的安装包需提供对应的安装方法说明文档，此文档作为检验安装过程的一部分。

● 更新说明：新增功能，对于新产品主要说明此次实现的功能，对于迭代产品主要说明此次变更的功能项或计划实现而未实现的功能点。修复的问题或BugID，主要面向迭代产品或二次开发产品继承的缺陷进行修复说明。遗留问题，上一次迭代提交的缺陷而此次未修改或延后处理的缺陷的说明文档。文件MD5值，提交文件的MD5值必须记录到更新说明中，以便对文件进行校验。

● 自测报告：研发人员对提交版本安装包功能的自测说明。

● 风险评估：研发人员对此次提交安装包可能存在的风险的说明，提示缺陷重点区域或注意事项。

3）update-package：指每一个小版本的升级，此处提交升级包，提交时，以升级包产品版本标识命名的方式创建文件夹；每次版本提交都应该提供框架图中的几类内容，如升级包、升级包安装说明文档、更新说明（新增功能、修复的问题或bugID、遗留问题、文件MD5值）、自测文档，如需要，需提供该版本有关风险评估的说明或在更新说明中附加。

● 升级包：升级包的封包按照公司发布的相关版本命名规范进行命名。

● 升级包安装说明文档：说明升级包的升级方式或方法。

● 更新说明：新增功能，对于新产品主要说明此次实现的功能，对于迭代产品主要说明此次变更的功能项或计划实现而未实现的功能点。修复的问题或BugID，主要面向迭代产品或二次开发产品继承的缺陷进行修复说明。遗留问题，上一次迭代提交的缺陷而此次未修改或延后处理的缺陷的说明文档。文件MD5值，提交文件的MD5值必须记录到更新说明中，以便对文件进行校验。

● 自测报告：研发人员对提交版本升级包功能的自测说明。

● 风险评估：研发人员对此次提交升级包可能存在的风险的说明，提示缺陷重点区域或注意事项。

4）需求规格说明书。明确的产品需求，是研发和测试的依据文档之一，该文档需放置在项目或产品的根目录下。

2．受控库权限管理

受控库的主要参与人员为配置管理员、普通研发人员、研发接口人员、测试人员、产品/项目经理、质量人员、临时人员（短期权限），表2-2根据某一项目库中各角色的权限进行说明。

3．受控库出入库原则

入库原则：

1）由项目经理或负责人邮件告知配置管理员需要创建的项目名称或项目简称（必须为英文）和项目成员组成，并说明研发接口人，由配置管理人员创建相应的库和分配相应的读写权限。

2）研发提交文件应由接口人进行，严禁普通研发人员或其他个人随意提交。

3）研发接口人提交文件需符合公司相关的产品版本标识说明和受控库框架说明中的要求，提交资料明细如表2-3所示。

4）对于上表中必须提交的文件，研发接口人提交入库申请时，发送给配置管理员的邮件中必须包含要提交的文件清单。

5）研发接口人提交的文件缺失“必要”文件时，必须在邮件中说明文件缺失原因并告知项目组成员、公司领导或技术委员会领导，配置管理员根据实际情况记入“月度受控库管理报告”中。

6）研发接口人提交错误的文件，对项目工作没有影响的进行保留，对项目工作有影响的，可邮件通知配置管理员及相关人员，待评估确认后，由配置管理员删除该文件。

7）研发接口人提交文件时，必须输入日志信息（Linux下为 -m参数，Windows下有输入日志信息窗口弹出）；配置管理员根据SVN日志信息进行管理审查工作和归纳记入“月度受控库管理报告”中。

出库原则（一般性原则，可根据实际情况适当更改）：

● 出库只能由产品经理提交“出库申请说明”，否则不予审批。

● 产品或项目文件的出库申请单需要写明出库的文件及版本。

● 出库（接口对象为产品库）要有记录（电子版），出库版本要与产品入库版本有对应关系。

4．产品归档与备份

受控库中项目或产品在项目结项、发布、暂停和终止后，配置管理员可以把相应的项目或产品库做归档工作，归档后，该项目或产品库对外只提供“只读”权限，不允许任何修改。对于归档的项目或产品，配置管理员对此进行整库备份。

5．研发和测试交互流程

在具体实施过程中，研发和测试要严格按照受控库相关的配置说明以及出入库规范去执行，具体的交互流程如下：

1）当研发工作进行到程序可发布测试阶段时，发送测试通知邮件给项目/产品组，并提交相关的文件放置到受控库。

2）测试人员提取受控库中相应文件，展开测试。

3）测试过程中，把发现的问题及时提交缺陷库。

4）根据测试结果，协商是否需要下一轮的迭代测试。如需要测试，研发人员提交安装包或升级包，重复1）～3）步骤。

6．角色分配

在整个受控过程中，各人员角色分配如表2-4所示。

2.2.3 测试库规范解析

测试库主要对测试过程中，输出的测试资料进行管理，目的保证文档的完整性和可追溯性。测试库主要存放计划类文档、用例类文档、报告类文档。接下来将对测试库的框架和配置规范进行讲解。

1．测试库框架说明

测试库框架说明如图2-3所示。

框架图说明

1）测试库以项目或产品为单元进行管理，使用SVN软件对测试库进行搭建。

2）测试报告主要放置如下文件：各阶段的迭代测试报告、性能测试报告、验收报告、各类文档的评审报告等。

3）测试用例主要放置如下文件：界面测试用例、功能测试用例、性能测试用例等。

4）过程文档主要放置如下文件：测试计划、测试方案、验收大纲、操作手册以及与项目相关的文档（如立项申请表、项目周报等）。

2．配置规范

项目成立需测试负责人创建测试库。

测试库分为过程文档、测试用例、测试报告。

输出的文件需放置在不同位置。

3．角色分配

在整个受控过程中，各人员角色分配如表2-5所示。

2.3 配置管理工具操作说明

了解了软件测试过程中配置管理的目标和阶段，就可以根据公司流程，选择配置管理工具。由于嵌入式测试配置管理与传统配置管理大体一致，所以我们在选择配置管理工具时，一定要考虑到所选择的工具是否适用于公司的配置管理流程。有的管理工具费用较高，花费大量的金钱去购买，由于操作太麻烦而被放弃使用；有的管理工具可以免费使用，由于某些条件限制，不能更好地进行配置管理。所以，在进行配置管理时，要选择合适的配置管理工具。接下来将对受控库管理工具SVN和缺陷管理工具QC进行实例分析。

2.3.1 受控库管理工具使用说明——SVN

SVN是由Subversion（服务端器）+TortoiseSVN（客户端）组成，在使用之前，要先搭建SVN服务器，然后安装SVN客户端。由于每个公司配置管理的规定是不同的，所以在使用配置管理工具时，还需结合公司相关配置管理规定去创建项目库以及划分权限。本节主要介绍Windows下VisualSVN服务器和客户端的安装与使用。

2.3.1.1 创建仓库

【实例2-1】在SVN Server上创建仓库，仓库名：test。具体步骤如下：

1）在安装SVN服务器的设备上，打开SVN Server。

2）在SVN Server界面，右击“Repositories”，点击“Create New Repository”，输入“test”，创建“test”库，如图2-4所示。

3）创建成功，即可查看新创建的“test”库。

2.3.1.2 添加仓库访问用户

【实例2-2】“test”库添加用户，用户1为test1，用户2为test2。

用户test1具有只读权限，用户test2具有读写权限，具体步骤如下：

1）在SVN Server上，右击“Users”，点击“Create User”，在弹出的“Create New User”窗口，输入用户名：test1，密码和确认密码：123（自定义该密码），如图2-5所示。

2）用户添加成功之后，在SVN Server上，选择 “test”仓库，右击“test”，点击“properties”，在弹出的“properties for /SVN/test”窗口中，设置用户test1为只读权限，用户test2为读写权限。

注意：No Access：没有访问权限。

Read Only：只读权限。

Read/Write：读写权限。

2.3.1.3 客户端的使用

SVN库创建完成后，通过SVN客户端来上传和获取相应资源。

1．浏览版本库

1）选择“TortoiseSVN”→ “版本库浏览器”。在弹出的URL输入框中输入要访问的路径，如图2-6所示。

2）在URL窗口点击确定，输入用户名和密码，显示此路径下的所有内容，就可以对文件进行操作，如图2-7所示。

2．检出文件

具体步骤如下：

1）在本地任意位置右击并选择“TortoiseSVN”→ “SVN检出”，在“版本库URL”中输入要检出的版本库路径，在“检出至目录”中输入检出到的本地目录，如图2-8所示。

2）点击确定后，下载版本库中的文件到本地，下载完毕后文件夹显示为如图2-9所示。

3．提交文件

【实例2-3】在检出文件夹，提交文件，提交文件是：test.docx。

具体步骤如下：

1）在检出的test文件夹，创建test.docx，如图2-10所示。

2）在test文件夹右击，选择“SVN提交”，在弹出的信息框中输入本次操作的注释，如图2-11所示。

3）点击确定后，系统弹出上传成功的信息框，可通过版本库浏览器查看文件是否提交。

4．更新文件

当从版本库检出文件到本地目录后，他人对服务器上的内容做了修改，需要再次获取改动的内容，此过程称为更新。步骤如下：

1）选中要更新的库，右击并选择“SVN更新”，点击更新后，会弹出窗口显示更新进度。

2）若上述框中有文件出现亮红，说明来自版本库的内容与你本地修改的内容在更新时出现了冲突，找到具体文件可根据实际情况解决。

5．删除文件

1）在test库中，选中要删除的文件如“test.docx”，右击并选择“TortoiseSVN”→“删除”，如图2-12所示。

2）删除文件后，只是在本地删除，选择SVN更新后，文件还会从服务器上更新到本地，如果不想更新成功，删除文件后，右击并选择“SVN提交”。

6．修改文件

修改文件与删除文件的过程相同，修改完成后，如果不选择“SVN提交”，修改的内容只会在本地保留，不会上传到服务器。如果服务器上的文件发生了变化，本地文件更新时，会出现冲突的现象。

2.3.2 缺陷库管理工具使用说明——QC

Quality Center（简称：QC）是一基于Web的测试管理工具。它功能强大，结合缺陷管理、需求管理和用例管理等功能，还具备自定义设置项的功能。本节重点讲解QC的站点管理和自定义项目说明。

2.3.2.1 创建新项目设置

在立项之后，就需要建立相关的缺陷库。操作步骤如下：

1）进入QC管理界面，如图2-13所示。然后点击“站点管理”。输入站点管理的用户名和密码，登录站点管理界面。

2）登录站点管理界面后，在“站点项目”页面，创建域，如图2-14所示。

3）在指定的域中创建项目，如图2-15所示。然后点击“下一步”。

4）在创建项目窗口，输入项目的名称（如：测试），如图2-16所示。然后点击下一步。

5）选择数据库类型为“MS-SQL”，选择服务器名、DB管理员用户和DB管理员密码，如图2-17所示。然后点击“下一步”。

6）在“添加项目管理员”窗口中，选择该项目的管理员，如图2-18所示。然后点击“下一步”。

7）创建项目窗口，点击“创建”，然后开始创建项目，直到创建成功。

2.3.2.2 站点用户配置

使用站点管理员登录站点管理界面，在站点管理界面，设置站点用户。

在站点用户窗口，根据项目实际情况添加项目组成员，添加方式如图2-19所示。

注意：在添加用户时，需要填写用户名、全名和电子邮件的地址。

设置新添加的用户所属的项目，如图2-20所示。设置完成之后，新添加的用户即可登录该缺陷库。

2.3.2.3 自定义设置说明

本章节描述的所有配置都是通过“自定义”菜单进行配置的。进入自定义设置的操作如下：

在缺陷提交界面，选择“工具”，点击“自定义”菜单，如图2-21所示。进入项目自定义配置界面。

“自定义项目实体”设置的字段可根据项目实际需求灵活添加。如果系统字段满足不了项目的需求，可以添加用户字段。基本字段设置如表2-6所示。

下面以“新建字段”、“检测版本”为例说明如何添加内容。

【实例2-4】新建字段

根据项目需求，需添加新字段为“迭代次数”，项目列表展示：第一次迭代、第二次迭代、第三次迭代。具体操作步骤如下：

1）在“自定义项目实体→缺陷→用户字段”，点击“新建字段”。即可添加除系统字段之外的字段值，如图2-22所示。在图2-22的第三步，更改需要添加的“字段标签”，字段类型选择“查找列表”。然后点击保存。

2）新建字段添加完成之后，新建项目列表，在新建项目窗口，输入“第一次迭代”，点击“确定”，如图2-23所示。

3）点击“确定”即可完成新建字段的添加。重复第2步骤，完成第二次迭代和第三次迭代的添加。

【实例2-5】添加检测于版本

根据项目需求，需在“检测于版本”字段中，添加“V1.0”版本。具体操作步骤如下：

1）在“自定义项目实体→缺陷→系统字段→检测于版本”，点击“转到表”，如图2-24所示。

2）在“自定义项目列表”窗口，输入本测试产品的版本号（如：V1.0），然后点击“确定”，如图2-25所示。

3）点击“关闭”即可完成版本的添加。

为了防止缺陷库遭到未经授权的访问和操作，可以通过QC将每个缺陷库成员分配到指定的用户组，QC包含具有默认权限的预定义组，但我们一般不直接使用这些默认的内容，可以根据公司的实际情况自定义缺陷的组别。

如下是划分的研发人员组、测试人员组、产品组，权限如表2-7所示。

【实例2-6】在设置组模块，创建研发人员组名称为：DE。

创建研发人员组（DE）的操作步骤如下：

1）在“设置组”中，点击“新建”，在弹出的“新建组”中“名称”栏输入“DE”, “基于”栏选择“Developer”。然后点击“确定”，如图2-26所示。

2）对新建的“DE”组进行权限设置，进入权限设置窗口，如图2-27所示。

3）在“权限设置DE组”窗口中，可分别点击 “需求”、“业务组件”、“测试计划”、“测试实验室”、“管理”、“缺陷”选项卡，对其权限进行分别设置。

4）在“缺陷→修改缺陷→状态”选项卡，需对研发人员“缺陷状态”进行设置，设置内容如图2-28所示。

注意：在添加状态时，需按照图2-27，设置用户组状态权限。

【实例2-7】配置QC自动发送电子邮件

通过QC，可以制定缺陷字段发生变化时使用电子邮件自动通知用户。

QC项目配置邮件涉及下列步骤：

1）在站点管理员的“项目”选项卡，选中“自动发送缺陷电子邮件”，如图2-29所示。

2）以管理员的身份登录项目，点击界面右上角的“工具→自定义”，进入“项目自定义”界面，选择配置Automail功能，指定发送邮件的字段，一般选择“状态”、“注释”即可，其他可根据项目实际需求添加，图2-30所示。

3）为用户设置发送邮件的条件（本节内容可根据实际需求灵活自定义），如图2-31所示。

2.3.2.4 缺陷分析操作方法

QC提供了缺陷报告的分析功能，根据提交的所有缺陷，生成指定的缺陷报告。

在缺陷界面，点击“分析”菜单，打开菜单“图”，如图2-32所示。

注意：在分析之前，图中显示的bugs即是需要分析的内容，所以可以提前对需要分析的bugs进行过滤。

分组方式选择“状态”, X轴选择“项目”，分析各个项目的缺陷状态，如图2-33所示。

2.3.2.5 缺陷导出操作方法

在导出之前，可以根据实际情况设置导出的内容。导出不同格式的缺陷操作如图2-34所示。