第五章 软件测试管理（1）

一个好的软件产品离不开一个成熟的测试团队，从而一个成熟的测试团队必须有一个 的测试管理。简单地说只要有流行就需要管理。本章主要介绍软件测试的管理、包括配置管理、过程管理、需求管理、缺陷管理以及风险管理。

5.1配置管理

配置管理（Sofware Configuration Management 简称CSM)是一种标识、组织和控制修改软件的技术。它贯穿整个软件生命周期中，通过对软件生命周期中不同时间点上所产生的文件或代码进行标识，从而达到保证软件产品的完整性和可测性。

在软件整个研发过程中，配置管理参与的人员包括：项目经理、配置管理员、SQA、软件开发组、软件测试组以及变更控制委员会等。配置管理主要是对项目文档以及代码进行规范管理。

5.1.1配置管理角色与职责

1、项目经理

项目经理（Project Manager 简称PM)是整个软件研发活动的负责人，主要对配置管理的整个过程负责，主要职责有：指定配置管理计划，指定配置管理员和变更控制委员会的成员

2、配置管理员

配置管理员（Configuration Management Officer 简称 CMO)是配置管理活动的负责人，主要工作是建立和维护配置管理库，并且设置相应的访问权利，对项目的配置进行管理和维护，执行版本控制和变更控制以及备份和归档配置库。

3、软件开发工程师

软件开发工程师（Software Developer Engineer 简称SDE)主要负责依据项目管理计划和相关的规定，进行创建、修改开发相关的配置顶。

4、软件测试工程师

软件测试工程师（Software Test Engineer 简称STE)主要是依据项目配置管理计划和相关的规定、创建、修改测试相关的配置顶。

5、软件质量保证

6、变更控制委员会

变更控制委员会（Change Control Board  简称CCB)是对配置项变更进行合理性的判断并给出解决方案。CCB一般由资深的开发工程师、测试工程师、系统工程师、产品技术工程师以及软件质量保证人员组成。

5.1.2配置管理的流程

有以下几个步骤

1、标识配置库并制定配置管理计划

在项目启动后，有哦项目负责人制定CMO以及CCB成员。由CMO制定配置管理计划，将配置管理工作贯彻在软件研发的全过程，并对配置进行标识，要求每个配置项必须被唯一标识，通常配置标识包括配置顶名称和配置顶版本的标识。

2、配置库建立和维护管理

CMO根据计划建立配置库，针对不同的角色分配相应的权限，并通知项目组成员，然后对配置定期进行备份，并保证配置库中的数据能够成功恢复。

3、配置控制与状态发布

在配置项提交评审时（未基线化）,CMO将该配置纳入配置库并进行标签。此时配置顶处于受控状态，在该状态下，配置项每次的更新需要用不同的版本 来进行标识。如果配置项变更，则该配置必须重新评审后进行签发。

4、基线变更控制

任何已基线化的配置项进行变更，都需要已变更的方式进行申请变更请求。变更请求（Change Request 简称CR)可以由客户或项目组成员启动，变更控制流程图，如图501所示

5、配置设计和配置归档

一般在阶段结束会议前，有QA和CMO进行基线审计，审计主要验证配置顶的完整性、正确性、一致性和可跟踪性以及变更控制是否和配置计划一致。当项目结束后，CMO将配置库进行归档和产品配置库，并删除所有的本地的复制资料。

配置管理的好处：加强了项目特点之间的协调与沟通，增加了团队的竞争力、并规范了测试的流程，对工作量的考核进行了量化，有利于整个项目的管理。总之配置管理为项目管理提供了各种监控项目进展的视角为项目经理确切掌握项目进度提供了保证。

5.1.3配置管理工具介绍

是支持完成配置管理标识，版本控制、变化控制、审计和状态统计任务的工具。常用的配置管理工具有： 微软公司的VSS(Microsoft Visual Sourcesafe)、开源软件CVN(Concurrent Version System)和SVN(Subversion)Rationla公司（现属IBM)的ClearCase等。

1、Microsoft Visual Sourcesafe

是微软公司产品，入门级的工具。主要采用标准的Windows操作系统界面，安装和配置非常简单。容易上手，缺点：没有提供对流程的管理，由于VSS的文件夹都是提供完全共享给用户进行使用，所以安全性比较低。

2、开源软件CVN

是开发源代码的配置管理工具，也是入门级的工具。是基于Unix/Linux的版本控制，使用者需要对Unix/Linux的系统有所了解。功能除了具有VSS的所有功能外，主要采用C/S体系，代码、文档的各种版本都存储在服务器端，需要进行各种命令操作。CVS的权限设置比较单一、只能通过对CVSROOT的password、readers、writers文件进行权限设置，无法完成复杂的权限控制。

3、开源软件SVN

是在CVS的基础上诞生的开发源代码的配置软件工具。继承了基本功能，还提供了对流程的关联。客户图也更加方便简洁，服务端是采用压缩形式存放文档和代码、资的利用率比较高，还提供了自定协议加密的规则。使得配置管理变得更加安全、可靠、是一种比较通用的配置管理工具。

4、ClearCase

是ClearCase公司的产品，是一款商业级的配置管理工具，提供VSS/CVS所支持的功能，但不提供变更管理的功能。后台的数据库是专有的结构，所以对权限设置更加灵活，并擅长设置复杂的开发过程，安全级别也非常高。

5.3需求管理

软件的需求管理包含多个层次，不同层次的需求反映不同程度的细节问题。

5.2.1什么是需求

指人们在欲望驱动下的一种有条件的、可行的、有时最优的选择，这种选择使欲望达到有限的最大满足，即人们总是选择能负担的最佳物品。在软件产品中，需求主要是指软件产品必须符合的条件或具备的功能。

在IEEE软件工程标准术语中对需求的定义为：

1）用户解决问题或达到目标所需的条件或权能

2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的无条件或权能。部件包含通常意义上的产品功能，而且还包含行业规范中定义的标准。

5.2.2需求的类型

需求的类型包含：业务需求、用户需求、系统需求、功能需求、其他非功能需求以及标准规则等，如图5-2所示

1、业务需求

表示组织或客户对系统高层次的目标，通常来自投资人、实际用户的管理者、市场营销部门以及产品策划部门。主要反映了组织为什么要开发该系统，也就是系统达到的目标，通常在使用前景和范围文档来记录业务需求。

2、用户需求

是用户的目标或用户要求系统必须完成的任务，也就是说用户需求描述额用户能使用系统来做些什么。

3、系统需求

用于描述包含多个子系统的产品（即系统） 的需求，系统可以是纯软件系统、也可以是软、硬结合的系统。

4、功能需求

定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。简单地说就是描述了开发人员需要实现什么。

5、约束准则

描述了系统必须满足企业方针、政府条例、工业标准、计算方法、行业的规范标准和约束条件等。

6、软件需求规格说明

说明功能需求充分描述了软件系统所应具有的外部行为。它在开发、测试、质量保证、项目管理以及相关功能中起了重要的作用。也可以说是为了使用户和软件开发者双方对该软件的初始规定有一个共同理解的说明文档，也是这个开发工作的基础。

5.3.3需求工程

划分为两大部分：需求开发和需求管理

5.2.4需求开发

是由需求分析人员与用户接触、交流、并对市场需求进行分析的一系列活动。需求开发主要包含：需求获取、分析、定义和验证。

1、需求获取

是通过与用户交流、对现有的系统的观察以及对任务进行分析、从而人开发、捕获、和修订用户的需求，它是需求工程的主体。

通常获取需求的方法有：

1）从用户提供的信息中获取需求

2）通过对市场进行调研来获取需求

3）选择用户群体进行问卷调查获取需求

4）从现有产品中获取需求

5）从竞争对手产品中获取需求

6）从系统业务流程分析中获取需求

7）通过访谈、交流、一起工作获取需求。

2、需求分析

也称为软件需求分析、系统需求分析或需求分析过程等，是开发人员经过细致的调研和分析、准确理解用户的项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为需求定义，从而确定系统必须做什么的过程。需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，主要是分析系统在功能上需要“实现什么”而不是考虑“?实现”

需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、星期与规范的文档，确定软件需要实现那些功能、完成那些工作等。此外软件的一些非功能性需求（性能、可靠性、安全性、易用性等）软件设计的约束条件以及运行时与其他软件的关系等也是软件需求分析的目标。

进行需求分析时，特别需要关注原始需求背后的隐形需求。主要说一下用例建模的需求分析法：首先找到系统中的活动者，也就是角色，其次从这些角色入手，分析可能所有活动以及这些活动之间的关系，并将这些活动的流程用状态图细化；最后根据状态图对需求分析分析。

3、需求定义

就是将需求分析的结构形成书面文档（软件需求规格说明书）

常见的软件需规格说明书内容如下

通常一个完整的软件需要说明规格书包含以下7大特征

1）完整性：每一项需求必须将所有实现的功能描述清楚，便于开发人员获得设计与实现这些功能所需的所有必要信息。

2）正确性：每一项需求都必须准确地称述其开发的功能。通常需求正确性需要用户参与。

3）可行性：每一项需求都必须在已知系统和环境的限制范围内可以实施的。为避免不可行的需求，通常需求需求分析人员考虑市场人员一起探讨，来负责检查技术的可行性。

4）必须性：每一项需求都应把客户与真正所需要的和最终系统所遵循的标准记录下来。也可以理解为每项需求都必须追述到用户的输入。

5）划分优先级

6）无二义性：每一项需求有，且只能有一个统一的解释，需求需要简洁明了的语言表达出来。避免二义性的有效方法就是对需求文档进行评审。

7）可验证性：每一项需求必须通过设计测试用例或其他方法进行验证。

5.2.4需求管理

是一种获取、组织和记录需求的系统化方法，并使客户和项目团队在系统需求变更上保持一致的过程。需求管理指明了系统开发所要做的和必须做的每一件事，还指明了所有设计应该提供的功能和必须受到的制约。

需求管理有：需求分配、需求评审、需求基线、变更控制以及需求跟踪。

1、需求分配

需求本身是由层次的，当一个系统的需求非常多，并且不可能由一个项目组完成时，需要考虑将项目分成若干个子项目，或根据需求优先级来划分目前项目开发的需求和候选版本的项目。如项目比较小就不需要分配了。进行需求分配意外着基本架构已经完成。

2、需求评审

需求评审是一项进益求精的技术，必须通过正式评审。在需求评审中农需要注意的地方有：、

1）对每一项需求的描述是否易于理解，是否存在二义性

2）需求中对特殊含义的术语是否给予了定义

3）每个特征是否用唯一的术语进行了描述。

4）需求中的条件和结果是不是合理，有没有遗漏一些异常的描述

5）需求中不能包含不确定性描述，如大约、可能等、

6）环境搭建是否存在困难

总之在需求评审中，要使客户、产品、研发以及测试人员在理解上必须达到一致。

3、需求基线

技术将配置项在生命周期不同的时间点上通过则是评审而进入一种受控的状态，这个过程被称为“基线化”建立基线化的好处有

1）重现性：可以技术返回并重现生成软件系统给定发布版本的能力，简单书就是当项目版本更新出现不稳定的状态时，可以及时取消变更、回溯版本。

2）可追踪性：建立项目工作之间的前后继承关系，目的就是确保设计满足要求、代码实施设计以及正确代码编译可执行文件。

3）版本隔离：基线为了项目研发的各个环节提供了一个定点和快照，新的项目可以从基线提供的定点中建立。

需求基线管理的流程是：首先将需求评审后的相关文档提交到配置库；其次确认这些文件的版本并建立基线标志；最后发布基线，通知项目组的所有成员即相关人员，基线文档采暖费的位置和标志。如果需求变更、则需要基线重新建立并通知。

4、需求变更

为了更好地控制项目的研发，应建立需求变更控制的流程，如图5-3所示。

5、需求跟踪

是指跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。为我们提供了由需求到产品实现整个过程范围的明确查阅能力。

需求跟踪的目的是建立与维护“需求、设计、代码、测试” 之间的一致性确保符合用户需求。

为了实现可需求跟踪的能力，必须对每一个需求进行统一的不是并建立需求跟踪矩形阵（Requirrement Tracking Matrix 简称RTM)

RTM的跟踪过程：原始需求