软件测试管理

一、过 程 管 理

　　软件测试过程管理在各个阶段的具体内容不同，在每个阶段，测试任务都要经过从计划、设计、执行到结果分析、总结等一系列相同步骤。

　　 软件测试过程管理主要集中在软件测试项目启动、测试计划制定、测试用例设计、测试执行、测试结果审查和分析，以及如何开发或使用测试过程管理工具。

（一）测试的组织

　　实施一个测试的首要步骤之一就是考虑测试中涉及到的人员的高级组织、他们之间的相互关系以及如何将测试过程集成到现有的业务管理结构中。

　　图10.1给出了测试过程组织的一种常见方法。

图10.1  测试过程组织

 

　　1) 测试主管

　　 测试主管有权管理测试过程日常的组织，负责保证在给定的时间、资源和费用的限制下设计测试项目产生满足所需的质量标准的产品。

　　测试主管在适当的时候也要负责与开发组进行联络，保证他们遵循在过程中引用的单元测试和集成测试方法。测试主管还要同独立测试观察员联系，接收有关没有正确遵循测试过程的测试项目的报告。

　　测试主管向公司内的高级主管或领导报告，如质量保证主管或信息技术领导。在大的公司中，尤其对于那些遵循规范的项目管理过程的公司中，测试主管可以向测试程序委员会报告，该委员会负责把握测试程序的项目管理的总体方向。

　　测试主管的职位可以是一个兼职的角色，可以由一个现有的高级主管或领导(如QA主管或IT领导)兼任。在测试涉及的人员相对较少的小公司中尤其可能出现这种情况。

 

　　2) 测试组组长

　　 测试组组长有权运作一个项目。其职责包括为测试分析员和测试者分配任务，按照预定的计划监控他们的工作进度，建立和维护测试项目文件系统，保证产生测试项目相关材料顺利完成。这些材料包括：测试计划文档、测试规范说明文档。测试组组长负责完成这些文档，也可以授权测试分析员来完成这些文档。

　　测试组组长听取一个或多个测试分析员和测试者的报告，并向测试主管汇报。测试组组长将和独立测试观察员联系(如讨论参加一个特定测试的可行性)，适当的时候还会和开发组组长联系(完成测试项目的早期计划和基本的测试设计，并确定AUT测试的有效性)。在验收测试时，测试组组长负责和用户代表、操作代表联系，以便有一个或多个用户来执行用户和操作验收测试。

 

　　3) 测试分析员

　　 测试分析员负责设计和实现用于完成AUT测试的一个或多个测试脚本以及相关的测试用例。测试分析员也可以派去协助测试组组长生成测试规格说明文档。

　　在调试测试用例的设计过程中，测试分析员需要分析AUT的需求规格说明，以便确定必须测试的特定需求。在这个过程中，测试分析员应该优先考虑测试用例，以反映被确认的特性的重要性以及在正常使用AUT中导致失败的特性的风险。可以采用给每个测试用例赋一个高、中或低的值的方法来完成这一工作。这是一项重要的工作，因为这种方法可以帮助测试组组长在时间和资源有限的情况下集中测试的人力。

　　在完成测试项目后，测试分析员负责备份和归档所有的测试文档和材料。这些材料将提交给测试组组长进行归档。测试分析员还负责完成一份测试总结报告，这份报告简要介绍该测试项目中的关键点。

　　测试分析员要向测试组组长汇报，并在开始测试AUT之前和测试者联系，向他们简单介绍测试者的任务。

 

　　4) 测试者

　　 测试者主要负责执行由测试分析员建立的测试脚本，并负责解释测试用例结果并将结果记录到文档中。

　　在执行测试脚本之前，测试者首先要建立和初始化测试环境，其中包括测试数据和测试硬件，以及其它支持测试所需的软件(加模拟器和测试辅助程序)。

　　在测试执行过程中，测试者负责填写测试结果记录表格，以便记录执行每个测试脚本时观察到的结果。测试者使用测试脚本对预期结果进行描述。

　　在完成测试以后，测试者还负责备份测试数据、模拟器或测试辅助程序以及测试中使用的硬件的说明。这些材料将提交给测试组组长归档。

 

 

（二）测试计划阶段

　　 测试计划要针对测试目的来规定测试的任务、所需的各种资源和投入、人员角色的安排、预见可能出现的问题和风险，以指导测试的执行，最终实现测试的目标，保证软件产品的质量。

　　编写测试计划的目的是：

　　(1) 为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

　　(2) 为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

　　(3) 开发有效的测试模型，能正确地验证正在开发的软件系统。

　　(4) 确定测试所需要的时间和资源，以保证其可获得性和有效性。

　　(5) 确立每个测试阶段测试完成以及测试成功的标准和要达到的目标。

　　(6) 识别出测试活动中的各种风险，并消除可能存在的风险，降低那些不可能消除的风险所带来的损失。

 

　　1．测试策略的制定

　　 测试策略描述当前测试的目标和所采用的测试方法。这个目标不是上述测试计划的目标，而是针对某个应用软件系统或程序的。具体的测试任务要达到的预期结果，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面要得到确认。测试策略还要描述测试不同阶段(单元测试、集成测试、系统测试)的测试对象、范围和方法以及每个阶段内所要进行的测试类型(功能测试、性能测试、压力测试等)。

 

　　2．测试计划过程

　　 测试计划经过计划初期、起草、讨论、审查等不同阶段，最终生成。测试计划过程如下所示：

　　(1) 计划初期是收集整体项目计划、需求分析、功能设计、系统原型、用例报告等文档或信息，理解用户的真正需求，了解技术难点、弱点或新的技术，和其余项目相关人员交流，在各个主要方面达到一致的理解。

　　(2) 测试计划最关键的一步就是确定测试需求、测试层次。将软件分解成单元，对各个单元写成测试需求，测试需求也是测试设计和开发测试用例的基础，是用来衡量测试覆盖率的重要指标。

　　(3) 计划起草。根据计划初期所掌握的各种信息、知识，确定测试策略，设计测试方法，完成测试计划的框架。

　　(4) 内部审查。在提供给其它部门讨论之前，先在测试小组或部门内部进行审查。

　　(5) 计划讨论和修改。召开有需求分析、设计、开发人员参加的计划讨论会议，测试组长将测试计划设计的思想、策略做较详细的介绍，并听取大家对测试计划中各个部分的意见，进行讨论交流。

　　(6) 测试计划的多方审查。项目中的每个人(即市场人员、开发人员、技术支持人员及测试人员)都应当参与审查。

　　(7) 测试计划的定稿和批准。在计划讨论、审查的基础上，综合各方面的意见，就可以完成测试计划书，然后报给测试经理或 QA 经理，得到批准，方可执行。

 

　　3．测试计划的要点

　　 软件测试计划的内容主要包括：产品基本情况、测试需求说明、测试策略说明、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。除了产品基本情况、测试需求说明、测试策略等，测试计划的焦点集中在：

　　(1) 计划的目的：项目的范围和目标，各阶段的测试范围、技术约束和管理特点。

　　(2) 项目估算：使用的历史数据，使用的评估技术，工作量、成本、时间估算依据。

　　(3) 风险计划：测试可能存在的风险的分析、识别，以及风险的回避、监控、管理。

　　(4) 日程：项目工作分解结构，并采用时限图、甘特图等方法制定时间/资源表。

　　(5) 项目资源：人员、硬件和软件等资源的组织和分配，人力资源是重点，日程安排是核心。

　　(6) 跟踪和控制机制：质量保证和控制，变更管理和控制等。测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织，为每一个阶段制定一个计划书，也可以为每个测试任务/目的(安全性测试、性能测试、可靠性测试等)制定特别的计划书。

 

　　4．测试计划的编写内容

　　 测试计划内容有被测软件的背景信息、测试目标、测试步骤、测试数据整理以及评估准则。它包括：

　　(1) 测试环境。在不同的条件下进行测试，所得到的结果是不同的。在测试计划中测试环境指用户使用环境或业务运行环境。

　　(2) 测试基本原理和策略。

　　(3) 测试计划阶段划分。

　　(4) 测试计划要点。

　　(5) 功能描述和功能覆盖说明。

　　(6) 测试用例清单。说明每个测试用例所测试的内容。

　　(7) 测试开始准则和退出准则。

　　每个测试用例的序言至少包括下列信息：

　　(1) 测试用例说明和用途。

　　(2) 设置需求(输入、输出)。

　　(3) 运行测试用例的操作命令。

　　(4) 正常和异常信息。

　　(5) 编写测试用例的作者。

 

（三） 软件测试设计和开发

　　当测试计划完成之后，测试过程就要进入软件测试设计和开发阶段。 软件测试设计是建立在测试计划书的基础上的。认真理解测试计划的测试大纲、测试内容及测试的通过准则，通过测试用例来完成测试内容与程序逻辑的转换，作为测试实施的依据，以实现所确定的测试目标。软件设计是将软件需求转换成为软件表示的过程，主要描绘出系统结构、详细的处理过程和数据库模式；软件测试设计则是将测试需求转换成测试用例的过程，它要描述测试环境、测试执行的范围、层次和用户的使用场景以及测试输入和预期的测试输出等。所以软件测试设计和开发是软件测试过程中一个技术深、要求高的关键阶段。

　　软件测试设计和开发的主要内容有：

　　 (1) 制定测试的技术方案，确认各个测试阶段要采用的测试技术、测试环境和平台，以及选择什么样的测试工具。系统测试中的安全性、可靠性、稳定性、有效性等测试技术方案是这部分工作内容的重点。

　　 (2) 设计测试用例。根据产品需求分析、系统设计等规格说明书，在测试技术选择的方案基础上，设计具体的测试用例。

　　 (3) 设计测试用例特定的集合，满足一些特定的测试目的和任务，即根据测试目标、测试用例的特性和属性(优先级、层次、模块等)来选择不同的测试用例，构成执行某个特定测试任务的测试用例集合(组)，如基本测试用例组、专用测试用例组、性能测试用例组、其它测试用例组等。

　　 (4) 测试开发。根据所选择的测试工具，将所有可以进行自动化测试的测试用例转换为测试脚本的过程。

　　 (5) 测试环境的设计。根据所选择的测试平台以及测试用例所要求的特定环境，进行服务器、网络等测试环境的设计。

 

　 　1. 测试用例设计的方法和管理

　　软件测试用例设计的方法有“白盒”测试和“黑盒”测试相对应的设计方法。“黑盒”测试的用例设计，采用等价类划分、因果图法、边值分析、用户界面测试、配置测试、安装选项验证等方法，适用于功能测试和验收测试。“白盒”测试的用例设计有以下方法：

　　(1) 采用逻辑覆盖(包括程序代码的语句覆盖、条件覆盖、分支覆盖)的结构测试用例的设计方法。

　　(2) 基于程序结构的域测试用例设计方法。“域”是指程序的输入空间，域测试正是在分析输入空间的基础上，完成域的分类、定义和验证，从而对各种不同的域选择适当的测试点(用例)进行测试。

　　(3) 数据流测试用例设计的方法，是通过程序的控制流，从建立的数据目标状态的序列中发现异常的结构测试方法。

　　(4) 根据对象状态或等待状态变化来设计测试用例，也是比较常见的方法。

　　(5) 基于程序错误的变异来设计测试用例，可以有效地发现程序中某些特定的错误。

　　(6) 基于代数运算符号的测试用例设计方法，受分支问题、二义性问题和大程序问题的困扰，使用较少。

 

　 　2. 测试开发

　　根据所选择的测试工具脚本语言，编写测试脚本，将所有可以进行自动化测试的测试用例转化为测试脚本。其输入就是基于测试需求的测试用例，输出是测试脚本和与之相对应的期望结果，这种期望结果一般存储在数据库中或特定的格式化文件中。

　　测试开发的步骤如下：

　　首先要设立测试脚本开发环境，安装测试工具软件，设置管理服务器和具有代理的客户端，建立项目的共享路径、目录，并能连接到脚本存储库和被测软件等。

　　然后执行录制测试的初始化过程、独立模块过程、导航过程和其它操作过程。结合已经建立的测试用例，将录制的测试脚本进行组织、调试和修改，构造成一个有效的测试脚本体系，并建立外部数据集合。

 

 

（四）测试执行阶段

　　当测试用例的设计和测试脚本的开发完成之后，就开始执行测试。测试的执行有手工测试和自动化测试两种。手工测试指在合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数据，对系统进行操作，比较实际结果和测试用例所描述的期望结果，以确定系统是否正常运行或正常表现。自动化测试是通过测试工具，运行测试脚本，并自动记录下测试结果。

　　针对每个测试阶段(代码审查、单元测试、集成测试、功能测试、系统测试、验收测试和安装测试等)的结果进行分析，保证每个阶段的测试任务得到执行，达到阶段性目标。

 

 

（五）测试执行结束和测试总结

　　测试执行全部完成，并不意味着测试项目的结束。测试项目结束的阶段性标志是将测试报告或质量报告发出去后，得到测试经理或项目经理的认可。除了测试报告或质量报告的写作之外，还要对测试计划、测试设计和测试执行等进行检查、分析，完成项目的总结，编写“测试总结报告”。

 

 

（六）测试过程改进

　　软件测试过程改进主要着眼于合理调整各项测试活动的时序关系，优化各项测试活动的资源配置以及实现各项测试活动效果的最优化。在软件测试过程中，过程改进被赋予了举足轻重的地位，在测试计划、实施、检查、改进的循环中，过程改进既是一次质量活动的终点，又是下次质量活动的原点，起着承上启下的作用。

 

　　1．软件测试过程改进的概念

　　测试过程的改进对象应该包括三个方面：组织、技术和人员。测试过程改进需要对组织给予特别关注，因为过程都是基于特定的组织架构建设的，而且组织设置是否合理对过程的好坏有决定性的影响。软件测试组织的不良架构通常表现在：

　　(1) 没有恰当的角色追踪项目进展。

　　(2) 没有恰当的角色进行缺陷控制、变更和版本追踪。

　　(3) 项目在测试阶段效率低下、过程混乱。

　　(4) 只有测试经理了解项目，项目成了个人的项目，而不是组织的项目。

　　(5) 关心进度，而忘记了项目的另外两个要素—质量和成本。

　　上述问题可从组织上找出原因。因此在测试过程改进中可以先将测试从开发活动中分离出来，把缺陷控制、版本管理和变更管理从项目管理中分离出来。此外，需要给测试经理赋予明确的职责和目标。技术的改进包括对流程、方法和工具的改进，它包括组织或者项目对流程进行明确的定义，引入统一的管理方法，并使用标准的经过组织认可的工具和模板。人员的改进主要是指对企业文化的改进，它将促使建立高效率的团队和组织。

　　由于测试过程改进是一项长期的、没有终点的活动，而且要获得改进过程的收益也是长期的过程，因此在起步实施测试过程改进时，要充分考虑战略，并根据公司的战略目标确定测试部门的战略，描绘远景。将测试过程改进与公司战略目标相联系，是改进成功实施的必要条件，也是各公司在实施测试过程改进中获得的最佳实践。

 

　　2. 软件测试过程改进的具体方法

　　过程改进在软件测试过程中占有举足轻重的位置，因此为了更好地保证软件质量，测试过程改进是测试人员经常要做的事情。下面列出了一些软件测试过程改进的具体方法：

　　(1) 调整测试活动的时序关系。在软件测试过程的测试计划中，不恰当的测试时序会引起误工和测试进度失控。例如，具体到某个工程实践中，有些测试活动是可以并行的，有些测试活动是可以归并完成的，有些测试活动在时间上存在线性关系等。所有这些一定要区分清楚并且要做最优化调整，否则会对测试进度产生不必要的影响。

　　(2) 优化测试活动资源配置。在软件测试过程中，必然会涉及到人力、设备、场地、软件环境与经费等资源。那么如何合理地调配各项资源给相关的测试活动是非常值得斟酌的，否则会引起误工和测试进度的失控。在测试资源配置中最常见的是人力资源的调配，测试部门如果能深入了解员工的专长与兴趣所在，在进行人员分配时，根据各自的特点进行分配，就能对测试活动的开展起到事半功倍的效果。

　　(3) 提高测试计划的指导性。测试计划的指导性是指测试计划的执行能力。在软件测试过程中，很多时候实际的测试和测试计划是脱节的，或者说很大程度上没有按照测试计划去执行。测试计划的完成不仅仅是起草测试大纲，而且是为了确保测试大纲中计划的内容能真正被执行、真正用于指导测试工作，为了更好地完成测试活动，保证软件的质量。

　　(4) 确立合理的度量模型和标准。在测试过程改进中，测试过程改进小组应根据企业与项目的实际情况制定适合自己公司的质量度量模型和标准，做出符合自己公司发展策略的投入。但是质量度量模型和标准的确立不是马上就可以进行的，而是测试过程改进小组随着测试过程的进行不断实践、不断总结、不断改进的。

　　(5) 提高覆盖率。覆盖率越高，表明测试的质量越高。覆盖率包括内容覆盖和技术覆盖。内容覆盖指的是起草测试计划、设计测试用例、执行测试用例和跟踪软件缺陷。内容覆盖率越高，就越能避免故障被遗漏的情况。技术覆盖指一项技术指标要尽可能地做到测试技术的覆盖，采用科学的方法来验证某项指标，可以更好地保证产品的质量。

 

 

 

 

 

二、需 求 管 理

（一） 需求管理概述

　　Standish Group从1994年到2001年的CHAOS Reports证实，导致项目失败的最重要的原因与需求有关。2001年，Standish Group 的CHAOS Reports报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，即这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是“变更用户需求”。

 

（二）软件测试中的需求分析

　　1．熟悉需求背景及商业目标

　　(1) 了解清楚项目发起的原因是为了解决用户的什么问题。

　　(2) 清楚当前的解决方案是不是最优的以及为什么会这样做。

 

　　2．业务模型法

　　(1) 考虑本项目与外部系统的交互，划分系统边界(除了本项目的需求中要求做的事情，其它的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界)。可以参考系统分析说明书。

   　(2) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

 

　　3．业务场景法

　　(1) 考虑用例的调用者，考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。(一般和外部有交互的用例出错的概率比较大，需要重点关注。具体被哪些外部调用，每个产品线都需要自己整理添加。)

　　(2) 考虑系统内部各个用例之间的交互(有可能PD划分用例的粒度不同，我们暂时考虑用户一次提交并且系统的状态及数据发生变化的功能是一个用例)，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，设计出各种业务流程图。

 

　　4．功能分解法

　　(1) 业务功能：与用户实际业务直接相关的功能或细节。

　　(2) 辅助功能：辅助完成业务功能的一些功能或细节，比如设置过滤条件。

　　(3) 数据约束：主要用于控制在执行功能时，数据的显示范围、数据之间的关系等。

　　(4) 易用性需求：产品中必须提供便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。

　　(5) 编辑约束：在功能执行时，对输入数据项目设定一些约束性条件，比如只能输入数字。

　　(6) 参数需求：在功能中，需要根据参数设置不同，进行不同处理的细节。

　　(7) 权限需求：这里的权限是指在功能的执行过程中，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限。

　　(8) 性能约束：执行功能时，必须满足的性能要求目前基本不涉及。

 

 

 

 

 

三、 软件配置管理

（一）软件配置管理概述

　　软件配置管理(Software Configuration Management，SCM)是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。

　　软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括：

　　(1) 软件配置管理的各项工作是有计划进行的。

　　(2) 被选择的项目产品得到识别、控制并且可以被相关人员获取。

　　(3) 已识别出的项目产品的更改得到控制。

　　(4) 使相关组别和个人及时了解软件基准的状态和内容。

　　为了达到上述目标，如下的方针应该得到贯彻执行：

　　(1) 技术部门经理和具体项目主管应该使用和遵循XSSC的OSSP中所描述的软件配置管理的工作过程。

　　(2) 施行软件配置管理的职责应被明确分配。相关人员得到软件配置管理方面的培训。

　　(3) 技术部门经理和具体项目主管应该明确他们在相关项目中所担负的软件配置管理方面的责任。

　　(4) 软件配置管理工作应该享有足够的资金支持，这需要在客户、技术部门经理和具体项目主管之间协商。

　　(5) 软件配置管理应该实施于如下产品：对外交付的软件产品以及那些被选定的在项目中使用的支持类工具等。

　　(6) 软件配置的整体性在整个项目生命周期中得到控制。

　　(7) 软件质量保证人员应该定期审核各类软件基准以及软件配置管理工作。

　　(8) 软件基准的状态和内容能够及时通知给相关组别和个人。

 

（二）  软件配置管理角色职责

　　对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义。特别是在引入了软件配置管理的工具之后，比较理想的状态就是：组织内的所有人员按照不同的角色要求，根据系统赋予的权限来执行相应的动作。因此，在本文所介绍的这个软件配置管理过程中主要涉及下列的角色和分工。

　　1) 项目经理

　　项目经理(Project Manager，PM)是整个软件研发活动的负责人，他根据软件配置控制委员会的建议，批准配置管理的各项活动并控制它们的进程。其具体职责为以下几项：

　　(1) 制定和修改项目的组织结构和配置管理策略。

　　(2) 批准、发布配置管理计划。

　　(3) 决定项目起始基线和开发里程碑。

　　(4) 接受并审阅配置控制委员会的报告。

 

　　2) 配置控制委员会

　　(1) 配置控制委员会(Configuration Control Board，CCB)负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项：定制开发子系统；定制访问控制；制定常用策略。

　　(2) 建立、更改基线的设置，审核变更申请。

　　(3) 根据配置管理员的报告决定相应的对策。

 

　　3) 配置管理员

　　配置管理员(Configuration Management Officer，CMO)根据配置管理计划执行各项管理任务，定期向CCB提交报告并列席CCB的例会。其具体职责为以下几项：

　　(1) 软件配置管理工具的日常管理与维护。

　　(2) 提交配置管理计划。

　　(3) 各配置项的管理与维护。

　　(4) 执行版本控制和变更控制方案。

　　(5) 完成配置审计并提交报告。　

　　(6) 对开发人员进行相关的培训。

　　(7) 识别软件开发过程中存在的问题并拟就解决方案。

 

　　4) 系统集成员

　　系统集成员(System Integration Officer，SIO)负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：

　　(1) 集成修改。

　　(2) 构建系统。

　　(3) 完成对版本的日常维护。

　　(4) 建立外部发布版本。

 

　　5) 开发人员

　　开发人员(Developer，DEV)的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。

 

 

 

（三）软件配置管理过程描述

　　1．项目计划阶段

　　一个项目设立之初，PM首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以开展了。

　　在软件配置管理计划的制定过程中，它的主要流程如下：

　　(1) CCB根据项目的开发计划确定各个里程碑和开发策略。

　　(2) CMO根据CCB的规划，制定详细的配置管理计划，交CCB审核。

　　(3) CCB通过配置管理计划后交项目经理批准，发布实施。

 

　　2．项目开发和维护阶段

　　这一阶段是项目研发的主要阶段。在这一阶段中，软件配置管理活动主要分为三个层面：

　　(1) 主要由CMO完成的管理和维护工作。

　　(2) 由SIO和DEV具体执行软件配置管理策略。

　　(3) 变更流程。

　　这三个层面是彼此之间既独立又互相联系的有机的整体。

　　在这个软件配置管理过程中，它的核心流程应该是这样的：

　　(1)  CCB设定研发活动的初始基线。

　　(2)  CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备。

　　(3) 开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作。

　　(4)  SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进。

　　在这个软件配置管理过程中，它的核心流程应该是这样的：

　　(1)  CCB设定研发活动的初始基线。

　　(2)  CMO根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备。

　　(3) 开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作。

　　(4)  SIO按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进。

 

图10.2  软件配置管理基本流程

 

 

（四）软件配置管理的关键活动

　　1．配置项(Software Configuration Item，SCI)识别　　Pressman对于SCI给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别：

① 计算机程序(源代码和可执行程序)。

② 描述计算机程序的文档(针对技术开发者和用户)。

③ 数据(包含在程序内部或外部)。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。”

　　软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下控制变化，软件配置管理引入了“基线(Base Line)”这一概念。IEEE对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”

　　软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类。

 

　　2．工作空间管理

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

　　一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，然后再根据需要把它划分为个人(私有)、团队(集成)和全组(公共)这三类工作空间(分支)，从而更好地支持将来可能出现的并行开发的需求。

　　每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作空间上。例如：对于私有开发空间而言，开发人员根据任务分工获得对相应配置项的操作许可之后，即在自己的私有开发分支上工作，其所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；而集成分支对应的是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作空间，则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的标准版本，并作为整个组织的知识库。

 

　　3．版本控制

　　版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段，还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并对软件过程的度量做好准备。

 

　　4．变更控制

　　基线与变更控制紧密相连，在对各个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保证它们在复杂多变的开发过程中真正地处于受控的状态，并在任何情况下都能迅速地恢复到任一历史状态就成为了软件配置管理的另一重要任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制。　　变更控制的对象主要指配置库中的各基线配置项，变更管理的一般流程如下：

　　(1) (获得)提出变更请求。

　　(2) 由CCB审核并决定是否批准。

　　(3) (被接受)修改请求分配人员，提取SCI，进行修改。

　　(4) 复审变化。

　　(5) 提交修改后的SCI。

　　(6) 建立测试基线并测试。

　　(7) 重建软件的适当版本。

　　(8) 复审(审计)所有SCI的变化。

　　(9) 发布新版本。　

 

　　5．配置状态报告

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

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

 

　　6．配置审计

　　配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。

 

 

 

 

四、缺 陷 管 理

（一） 缺陷跟踪管理系统概述

　　缺陷跟踪管理系统(Defect Tracking System)是用于集中管理软件测试过程中发现的缺陷的数据库程序，可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。

　　1) 缺陷跟踪管理系统的作用

　　(1) 便于缺陷的查找和跟踪。对于大中型软件的测试过程而言，报告的缺陷总数可能多达成千上万个，如果没有缺陷跟踪管理系统的支持，要求查找某个错误，其难度和效率可想而知。

　　(2) 便于协同工作。缺陷跟踪管理系统可以作为测试人员、开发人员、项目负责人、缺陷评审人员协同工作的平台。

　　(3) 保证测试工作的有效性。避免测试人员重复报错，同时也便于及时掌握各缺陷的当前状态，进而完成对应状态的测试工作。

　　(4) 便于跟踪和监控错误的处理过程和方法。可以方便地检查处理方法是否正确，跟踪处理者的姓名和处理时间，作为工作量的统计和业绩考核的参考。

 

　　2) 缺陷跟踪管理系统的实现原理

　　缺陷跟踪管理系统在实现技术层面上看是一个数据库应用程序。它包括前台用户界面、后台缺陷数据库以及中间数据处理层。

　　这类系统的用户界面所显示的信息一般应根据用户的角色不同(测试人员、开发人员、项目负责人、缺陷评审员等)而略有差异，因为各个角色使用该系统完成的任务各不相同，如测试人员用于报告缺陷或确认缺陷是否可以关闭，开发人员用于了解哪些缺陷需要他去处理以及缺陷经过处理后是否被关闭，而项目负责人需要及时了解当前有哪些新的缺陷，哪些必须及时修正等等。另外，不同角色所拥有的数据操作权限也不尽相同。例如开发人员无权通过其用户界面往数据库中填写新的缺陷信息，也无权关闭某个已知缺陷；而测试人员无权决定分配谁去修正某个已知缺陷，无权决定是否要修正某个缺陷。

 

（二） 软件缺陷内容

　　软件缺陷包括如下内容：

　　(1) 可追踪信息。如给每个缺陷分配一个缺陷编号，则每个编号必须是唯一的，可以根据该编号搜索、查看该缺陷的处理情况。

　　(2) 缺陷的基本信息。通常缺陷的基本信息包括缺陷状态、缺陷标题、缺陷严重程度、缺陷紧急程度、缺陷提交人、缺陷提交日期、缺陷所属、缺陷解决人、缺陷解决时间、缺陷解决结果、缺陷处理人、缺陷处理最终时间、缺陷处理结果、缺陷确认人、缺陷确认时间、缺陷确认结果等等。

　　(3) 缺陷的详细描述，即对缺陷的特征应做详细的描述。例如程序代码中的错误，应详细描述错误发生的软硬件环境、相关输入输出数据、出错时程序的状态等等，以方便编码人员进行错误复现和错误定位。又如设计规格说明中的错误，应指明它与高层软件开发文档(如需求规格说明)中哪些条款相违背，为什么判为违背，都需要描述清楚，以方便设计人员进一步核实。

　　(4) 必要的附件。有时，某些缺陷可能无法用语言文字表达清楚，如用户界面出现的一些缺陷，光用语言文字难以表述清楚。这时，就需要借助于屏幕拷贝等方式来进一步描述缺陷。

 

（三）软件跟踪缺陷处理的一般流程

　　软件跟踪管理确保每个被发现的缺陷都能被解决。解决可能是指缺陷被修正，也可能是指项目组成员达成一致的处理意见(如不作处理)。

　　软件跟踪缺陷处理的流程如图10.3所示。

图10.3  缺陷处理流程

 

 

 

五、 风 险 管 理

（一）风险管理概述

　　近几年来软件开发技术、工具都有了很大的进步，但是软件项目开发超时、超支，甚至不能满足用户需求而根本没有得到实际使用的情况仍然比比皆是。软件项目开发和管理中一直存在着种种不确定性，严重影响着项目的顺利完成和提交。但这些软件风险并未得到充分的重视和系统的研究。直到20世纪80年代，Boehm比较详细地对软件开发中的风险进行了论述,并提出软件风险管理的方法。Boehm认为,软件风险管理指的是“试图以一种可行的原则和实践，规范化地控制影响项目成功的风险”，其目的是“辨识、描述和消除风险因素，以免它们威胁软件的成功运作”。

 

（二）软件项目风险管理

　　风险管理涉及的主要过程包括风险识别、风险量化、风险应对计划制定和风险监控，如图10.4所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。

图10.4  风险管理过程

 

 

 

（三）软件项目中的风险

　　软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IT项目开发中常见的风险有如下几类：

　　1) 需求风险

　　(1) 需求已经成为项目基准，但需求还在继续变化；

　　(2) 需求定义欠佳，而进一步的定义会扩展项目范畴；

　　(3) 添加额外的需求；

　　(4) 产品定义含混的部分比预期需要更多的时间；

　　(5) 在做需求时客户参与不够；

　　(6) 缺少有效的需求变化管理过程。

 

　　2) 计划编制风险

　　(1) 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；

　　(2) 计划是优化的，是“最佳状态”，但计划不现实，只能算是“期望状态”；

　　(3) 计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；

　　(4) 产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；

　　(5) 完成目标日期提前，但没有相应地调整产品范围或可用资源；

　　(6) 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

 

　　3) 组织和管理风险

　　(1) 仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；

　　(2) 低效的项目组结构降低生产率；

　　(3) 管理层审查决策的周期比预期的时间长；

　　(4) 预算削减，打乱项目计划；

　　(5) 管理层作出了打击项目组积极性的决定；

　　(6) 缺乏必要的规范，导致工作失误与重复工作；

　　(7) 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。　

 

　　4) 人员风险

　　(1) 作为先决条件的任务(如培训及其它项目)不能按时完成；

　　(2) 开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；

　　(3) 缺乏激励措施，士气低下，降低了生产能力；

　　(4) 某些人员需要更多的时间适应还不熟悉的软件工具和环境；

　　(5) 项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；

　　(6) 由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；

　　(7) 不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；

　　(8) 没有找到项目急需的具有特定技能的人。

 

　　5) 开发环境风险

　　(1) 设施未及时到位；

　　(2) 设施虽到位，但不配套，如没有电话、网线、办公用品等；

　　(3) 设施拥挤、杂乱或者破损；

　　(4) 开发工具未及时到位；

　　(5) 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；

　　(6) 新的开发工具的学习期比预期的长，内容繁多。

 

　　6) 客户风险

　　(1) 客户对于最后交付的产品不满意，要求重新设计和重做；

　　(2) 客户的意见未被采纳，造成产品最终无法满足用户要求必须重做；

　　(3) 客户对规划、原型和规格的审核决策周期比预期的要长；

　　(4) 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；

　　(5) 客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；

　　(6) 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

 

　　7) 产品风险

　　(1) 矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；

　　(2) 开发额外的不需要的功能，延长了计划进度；

　　(3) 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

　　(4) 要求与其它系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；

　　(5) 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；

　　(6) 开发一种全新的模块将比预期花费更长的时间；

　　(7) 依赖正在开发中的技术将延长计划进度。

 

　　8) 设计和实现风险

　　(1) 设计质量低下，导致重复设计；

　　(2) 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；

　　(3) 代码和库质量低下，导致需要进行额外的测试，修正错误或重新制作；

　　(4) 过高估计了增强型工具对计划进度的节省量；

　　(5) 分别开发的模块无法有效集成，需要重新设计或制作。

 

　　9) 过程风险

　　(1) 大量的纸面工作导致进程比预期的慢；

　　(2) 前期的质量保证行为不真实，导致后期的重复工作；

　　(3) 太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需要重新开发；

　　(4) 过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；

　　(5) 向管理层撰写进程报告占用开发人员的时间比预期的多；

　　(6) 风险管理粗心，导致未能发现重大的项目风险。

 

 

（四）软件风险管理模型

　　1．Boehm模型

　　Boehm用公式RE=P(UO)*L(UO)对风险进行定义，其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。在风险管理步骤上，Boehm基本沿袭了传统的项目风险管理理论，指出风险管理由风险评估和风险控制两大部分组成，风险评估又可分为识别、分析、设置优先级3个子步骤，风险控制则包括制定管理计划、解决和监督风险3步。

　　Boehm思想的核心是10大风险因素列表，其中包括人员短缺、不合理的进度安排和预算、不断的需求变动等。针对每个风险因素，Boehm都给出了一系列的风险管理策略。在实际操作时，以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。

　　10大风险列表的思想可以将管理层的注意力有效地集中在高风险、高权重、严重影响项目成功的关键因素上，而不需要考虑众多的低优先级的细节问题。而且，这个列表是通过对美国几个大型航空或国防系统软件项目的深入调查，编辑整理而成的，因此有一定的普遍性和实际性。

 

　　2．CRM模型

　　SEI提出了持续风险管理模型(Continuous Risk Management，CRM)。

　　SEI的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处理的风险；实现控制风险的策略；评测并确保风险策略实施的有效性。

　　CRM模型要求在项目生命期的所有阶段都关注风险识别和管理。它将风险管理划分为5个步骤：风险识别、分析、计划、跟踪、控制。图10.5所示的框架显示了应用CRM的基础活动及其之间的交互关系，强调了这是一个在项目开发过程中反复持续进行的活动序列。每个风险因素开展的不同活动可以是并发的或者交替的。

 

图10.5  SET风险管理范例

 

　　图10.5中的箭头标识了信息的逻辑流，而沟通则是信息流的核心和手段。其中，风险识别依靠问卷完成，问卷覆盖了大概200个问题，共涉及13个主要领域。风险分析侧重于理解每个风险在该项目中的发生几率和后果严重性，从而产生最严重的10大风险问题。风险计划是将如下内容文档化：风险管理步骤的描述、负责人及其职责、行为执行和完结的时间，并且确定风险处理的优先级，制定整体的管理计划。风险跟踪是获取、整理并汇报10大风险问题当前的状态，其目的是收集精确的、及时的和相关的信息，并将它们表达成容易理解的方式提交给负责人。风险控制是为了根据风险及其缓解计划进行及时而有效的决策，具体操作包括分析风险跟踪阶段产生的风险状态信息，明确地决定采取什么行动并实现它们。而处于核心地位的沟通则强调其有效性和针对性，要注意将合适的信息传达给合适的组织层次以得到最有效的分析和管理，这些层次包括开发方和用户方双方的组织结构。

 

　　3．Leavitt模型

　　SEI和Boehm模型都以风险管理的过程为主体，研究每个步骤所需的参考信息及其操作。而Aalborg大学提出的思路则是以Leavitt模型为基础，着重从导致软件开发风险的不同角度出发探讨风险管理。

　　1964年提出的Leavitt模型将形成各种系统的组织划分为4个有趣的组成部分：任务、结构、角色和技术。这4个组成部分和软件开发的各因素很好地对应起来：角色覆盖了所有的项目参与者，例如软件用户、项目经理和设计人员等；结构表示项目组织和其它制度上的安排；技术则包括开发工具、方法、硬件软件平台；任务描述了项目的目标和预期结果。Leavitt模型的关键思路是：模型的各个组成部分是密切相关的，一个组成部分的变化会影响其它的组成部分。如果一个组成部分的状态和其它的状态不一致，就会造成比较严重的后果，并可能降低整个系统的性能。

 

 

思 考 与 习 题

---

 

　　1. 简述软件测试管理过程及其主要功能。

　　2. 软件风险分析的目的是什么？

　　3.  IEEE软件测试计划文档模板规定了哪些测试方面的相关内容？

　　4. 测试管理的主要内容是什么？

 　　5. 需求管理是什么？

　　6. 配置管理具有哪些关键活动？

　　7. 如何认识软件缺陷管理？