第4章　软件测试过程与管理

4．1　软件测试过程

一、简介

开发过程的质量决定了软件的质量，测试过程的质量决定了软件测试的质量和有效性。软件测试过程的管理是保证测试过程质量、控制测试风险的重要活动。软件测试遵循软件工程的原理，有自己的生命周期。软件测试的过程管理是测试成功的重要保证。

二、说明

（1）软件的测试过程通常分为测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。对各阶段的任务、输入和输出都有明确的规定，有利于对整个测试过程进行质量控制和配置管理。

（2）软件测试过程是一种遵循GB/T18905（ISO14598.5）中定义软件评价过程的抽象的模型，是国际上共同遵守的软件评测过程标准，是软件测试过程管理的精髓。标准定义分析各类软件产品的评测需求，规定、设计、实施、评审以及对评测做出结论所需的各种活动。

4．2　评价过程的特性

一、可重复性

由同一评价者按同一评价规格说明对同一产品进行重复地评价，应产生同一种可接受的结果。

二、可再现性

由不同评价者按同一评价规格说明对同一产品进行评价，应产生同一种可接受的结果。

三、公正性

评价应不偏向任何特殊的结果。

四、客观性

评价结果应是客观事实，即不带有评价者的感情色彩或主观意见。

4．3　评价过程

一、评价活动

评价过程由五个活动组成：

1．确立软件评价需求

2．编制评价规格说明

根据请求者提供的评价需求和产品描述编制。

3．制定评价计划

在评价规格说明的基础上设计评价，需考虑要测软件的部件和评价者建议的评价方法。

4．评价执行计划

（1）按照评价计划对产品及其部件进行检查、建模、测量和评价；

（2）可以用软件工具（通常由评价者提供）来实施；

（3）记录评价者的执行动作，所得的结果被记入评价报告草案。

5．作评价结论

交付评价报告和评价者对评价产品所做的处理。

二、评价过程的输入

请求者提供其需求，并作为评价需求的最初版本。

1．请求者提供的评价过程的输入

（1）软件的说明书；

（2）软件的部件。

软件的说明书标识的软件产品以及供评价的部件。

2．评价者提供的评价过程的输入

（1）预先确定的评价规格说明；

（2）评价方法；

（3）评价工具。

三、评价过程的输出

在评价期间，评价者提供下列输出产品：

1．评价记录

评价记录包括评价计划和评价动作的记录。

2．评价报告草案

评价报告草案包括评价需求，评价规格说明和综合的评价结果。

3．经过评审的评价报告

四、评价过程文档

评价需求、评价规格说明和评价计划是评价过程的中间产品。评价记录和评价报告是评价过程的最终产品。

1．评价需求

描述评价的目标，特别是描述了产品的质量需求。

2．评价规格说明

确定对软件及其部件实行的所有分析和测量，标识要分析和测量的软件部件。

3．评价计划

描述评价规格，说明需实施的操作规程；描述评价需用到的方法和工具。

4．评价记录

评价执行计划时详细记载的动作组成；记录由评价者保留。

5．评价报告

执行测量和分析的结果，以及能被重复和重新评价的必要信息。评价报告首先作为评审草案来发布，其最终版本将交给请求者。

如图4-1所示，图中给出了软件测试过程的概述，标识了各活动之间的信息流。

图4-1　软件测试过程

4．4　评价与生存周期的关系

评价软件产品可以在任何软件生存周期过程的范围内进行。特别是，评价能在软件获取、供应、开发、运行或维护过程中进行。在软件开发过程中可尽早决定是否执行软件产品的评价，以保证软件最大可能地满足有关评价结果的需求，从而降低额外风险和未预料的成本。

当请求者也是软件的开发者时，应及早与评价者联系，讨论提交一个产品用于评价，有助于开发者预见评价者可能提出的任何特殊的要求。可能有某些（或全部）评价动作必须在现场实施，为保证结果公正，这些动作仍受评价者的控制。对于大而复杂的软件项目，在整个产品的开发期间，开发者与评价者应不断密切合作，以减少评价过程的成本和时间。但这种合作应不降低评价者的公正性。

4．5　评价过程的要求

一、一般要求

1．组织和质量体系

为满足评价结果的可重复性、可再现性、公正性及客观性，评价者应立足于一个组织。该组织为使其活动达到充分的质量要求提供所有必要保证。为满足该需求，评价组织可按照ISO/IEC17025中规定的要求建立质量管理体系。

2．评价请求者的职责

（1）为进行评价，对软件产品确立必要的合法权利；

（2）为标识和描述产品提供必要的信息；

（3）阐述最初的评价需求，并与评价者协商，确定实际的评价需求，这些评价需求宜遵守相关的法规和标准；

（4）阐述对评价提交的信息的保密性需求；

（5）必要时在开发者和评价者之间起中介作用；

（6）必要时向评价者提供对用于开发和操作使用软件产品的计算机和其他设备；

（7）必要时对评价者提供必要的支持，包括培训和走访；

（8）必要时确保及时提供软件、产品说明书和部件，包括文档及其他资料；

（9）必要时告知评价者可能导致评价结果无效的原因。

3．评价者的职责

（1）检查请求者对要评价执行的软件产品是否有充分合法的权利；

（2）按规定对请求者提供信息保密承诺，包括评价的软件、评价记录和评价报告；

（3）提供有资格的和经过培训的人员，以便实施评价；

（4）提供评价工具和技术；

（5）按照评价需求实施测试；

（6）保留评价期间影响评价结果的所有工作记录；

（7）保证及时向请求者提交评价报告。

二、评价需求确立

1．评价需求确立的目的

评价需求确立的目的是描述评价目标。这些目标关系到软件产品的预期用途和相关风险。可能要从几种不同软件用户角度，如从软件的需方、供方、开发者、操作者或维护者等出发。

2．评价需求分析

（1）组成

分析评价需求的活动由以下5个子活动组成：

①请求者提出评价需求建议；

②请求者说明评价覆盖范围；

③评价者分析评价原因和描述评价需求来响应请求者；

④评价者解释评价的保密范围和严格程度；

⑤评价者同意评价需求。

（2）需要考虑的问题

进行评价需求分析时，要考虑供评价的产品的应用领域和用途，还须考虑一些关键问题。在请求者的需求中，请求者应表明评价覆盖范围。同时评价者应保证评价非常严格的，足以提供软件产品质量方面的真实证据。故请求者与评价者应对评价需求达成一致，作为继续评价过程的前提条件。

3．评价需求内容

（1）评价需求应包含对评价产品应用领域的描述，以及产品用途的描述；

（2）评价需求应由GB/T16260中定义为“质量特性”的一系列质量需求组成，还可能用到一些子特性；

（3）评价需求中的每项需求，都应提供要评价软件及部件的规格说明信息。

4．认可与报告

（1）评价需求应作为请求者与评价者联合评审的结果而予以承认；

（2）评价需求应包括在评价报告和评价记录中。

三、评价规格说明

1．评价规格说明的目的

定义评价范围和供评价产品及各种部件执行的测量。评价规格说明应详细到以此能确保评价的可重复性和可再现性。

2．评价规格说明编制

（1）组成

编制评价规格说明的活动由以下3个子活动组成：

①分析产品的描述；

②规定对产品及部件执行的测量；

③按照评价需求验证编制的规格说明。

（2）产品说明分析

①提交产品说明的目的

a．以此定义评价的范围，即标识出哪些作为软件一部分的部件，以便了解接触软件的情况；

b．将供评价的产品部件的标识交给评价者，以便评价者了解其结构，并弄清提供的信息及如何访问产品部件。

②产品说明资料应给清单中的部件、文档提供的信息

产品说明资料应包含为评价而实际提交的产品部件清单、有关产品结构的基本原理和与产品有关的文档清单。对列在清单中的每个部件和与产品有关的文档，应提供如下信息：

a．部件性质的描述；

b．部件中用到的形式化信息；

c．有关部件规模的信息；

d．与其他部件的关系；

e．对评价者有用的产品部件信息。

评价者应检查产品描述是否与上述提及的需求一致，并分析提供的原理及部件的说明，以便标识在评价需求中确定的各部件间的关系。

（3）测量规定

评价者应把评价需求分配给产品本身和产品描述中标识的各种部件，使评价需求被分解为数个子特性。对所供测试的不同部件，分解结果不同。然后，测试者应规定对产品和所选部件的特性、子特性及属性进行评估的测量标准。测试规格说明书应明确对以下几项进行说明：

①用于度量软件或一组标识的部件的形式化的规格说明，以及评价报告中测量结果的表现形式的说明；

②引用的产品部件中规定将要验证的软件需求，以及引用验证这些需求的规程的说明；

③在软件需求文档中被遗漏的，或需要更详细解释的软件产品的需求规格说明，以及用来验证这一需求的规程的说明。

对上述这些声明，应引用要测量或验证的部件的性质和所用的形式。

（4）评价规格说明验证

①评价者应按照评价需求来验证评价规格说明；

②评价者应按照评价需求检查列在产品描述中的部件是否提供了评价执行的所有必要信息；

③评价者还应验证规定的测量和验证是否充分满足评价需求所表示的评价目标。

3．评价规格说明的内容

（1）评价范围，涉及在产品说明中标识的产品部件；

（2）评价执行所需的信息，在产品说明中列出的软件部件及其他相关文档之间的相互引用；

（3）要执行的测量和验证的规格说明，以及对要评价的产品部件的引用；

（4）测量和验证的规格说明与评价需求之间，与引用标准或所列的每个测量或验证的理由之间的映射。

4．认可和报告

（1）评价规格说明应作为请求者和测试者之间联合评审的结果而予以认可；

（2）评价规格说明应包含在评价报告和评价记录中，对评价需求的任何修改均应在评价记录中予以报告。

四、评价设计

1．评价设计目的

评价设计应把评价者使用的测量规程编成文档，以便评价执行规格说明中规定的测量。评价者应制定评价计划来描述执行指定的评价时所需的资源和执行各种动作时对这些资源的分配。评价计划应详细到能确保用令人满意的方式执行这些动作。

2．制定评价计划

（1）组成

制定评价计划的活动由以下3个子活动组成：

①把评价方法编成文档，起草计划；

②优化评价计划；

③根据可用资源安排评价动作的进度。

（2）编制评价方法文档和起草计划

①概述

把规定的测量或验证与要评价的各种产品部件的形式组合起来，以便把对部件实施的测量或验证的详细方法编成文档。评价者应分析评价规格说明中规定的有关测量或验证的技术约束条件。这些约束条件可能包括以下内容：

a．软件部件所用的形式；

b．软件部件说明的电子或书面形式；

c．预定义评价方法；

d．支持评价技术的工具的可用性；

e．软件部件的规模。

②注意事项

评价规格说明中规定的每种测量或验证，评价者都应把有关的评价方法编成文档。当描述的评价方法是基于使用软件工具的时候，应在评价计划中标识该工具。该标识应至少包括工具的名称、版本标识和其来源（如：供方）。对评价的产品执行程序时，也应说明运行环境以及实际工作中可用的条款。

（3）测量的优化

每个基本评价方法都计划应用在供评价的各个软件部件上，也会出现将不同的基本评价方法用于同一软件部件的情况。应对评价计划草案进行评审，以避免评价者的重复劳动，减少错误风险和降低计划的评价者的工作量。

（4）安排评价动作的进度

安排评价动作的进度的注意事项：

①评价者安排计划动作进度，应考虑人员、软件工具、计算机等资源的可用性；

②应就软件及部件的交付进度与请求者达成一致；

③应规定软件部件的交付介质、形式以及拷贝数量；

④应标识评价过程中满足的需求；

⑤当请求者不是软件产品的开发者时，应标识评价者和开发者之间的关系；

⑥应规定开发者需要的支持（包括培训、非正式的讨论或办公场所等）；

⑦必要时，应对开发和运行场所的访问与所需资源一起规定。

（5）评价计划的内容

评价计划应由两部分组成：评价方法文档和评价者采取评价动作的时间表。评价计划中某些评价方法的文档可能包括对评价者个人材料的引用。在该情况下，评价者应能判断该方法与相应评价规格说明元素的针对性，以及在应用该方法时，其自身的能力。

3．认可和报告

（1）评价计划应作为请求者和评价者之间联合评审的结果而予以认可。

（2）评价计划应包含在评价记录中。评价方法的文档，对方法的引用，以及对要应用该评价方法的产品部件的标识都应在评价报告中体现。

五、评价执行

1．评价执行目的

评价执行目的是根据评价需求，按照评价规格说明中的规定和评价计划，从对软件产品的测量和验证中获得结果，执行这些动作并完成评价报告和评价记录的草稿。

2．评价执行者的动作

（1）对评价执行者的要求

为了执行计划的评价，评价者应做到以下几点：

①管理请求者提供的产品部件；

②管理评价动作所产生的数据（包括报告和记录）；

③管理评价执行动作的工具；

④管理在评价者的承诺之外执行的评价动作；

⑤管理使用特定评价技术所隐含的要求。

（2）内容

①软件部件的管理

评价请求者应根据评价计划中定义的进度向评价者交付软件部件和与软件相关的文档。

评价者应登记全部软件部件和软件的相关文档。在证实软件的规模和复杂程度之后，应使用正式的配置管理。

软件样品登记的信息应至少包括：

a．部件或文档的唯一标识符；

b．部件的名称或文档标题；

c．文档的状态（包括物理状态或变异状态）；

d．请求者提供样品的版本、配置和日期信息；

e．接收的日期。

除非请求者有另外的许可，否则，评价者将保守全部产品部件和相关文档的秘密。

②评价数据管理

评价执行动作通常是测量产品和其部件，获得并解释中间数据，将产生的结果记入测试报告。

中间数据的种类多种多样。对中间数据的保密应与原来对部件和文档的保密方法一样。评价者应尽力防止这些数据被意外或恶意地修改。评价者应把所有中间数据记入评价记录，以便依据它们进行解释。同时，在解释过程中所作的决定也应被记入评价记录。

③工具使用的管理

评价执行动作需要使用工具软件来收集原始数据，或解释中间数据。

a．使用工具来评价执行动作时，应在评价报告中记录对工具的引用。该引用应由工具的标识、供方和版本信息组成。

b．对所用工具的更详细的引用信息应记录在评价记录中，包括工具配置的详细信息和为得到相同的中间结果而重复评价动作所需的任何相关信息。

c．评价者应尽最大努力保证工具按照所期望的方式进行工作，保留在评价过程中承诺合法使用工具的记录。

④现场评价

有时，不能在评价者假定的场所评价执行动作。这时，评价者应控制所有执行的评价动作，特别是应避免任何使评价结果无效的情况发生。评价者应尽最大努力保证评价结果和中间结果的保密性。

⑤特定评价技术的需求

当评价计划要求评价产品的可执行程序时，应精确记录评价的配置和评价的环境。当评价动作要求检查文档时，建议使用检查表。

⑥评审和报告

在评价执行过程中会产生中间评价结果和最终评价结果。为达到最大的客观性，每个评价动作应由不同的评价执行动作的评价者来检查。应评审全部评价结果，其目的取决于所考虑的评价动作的实质。应至少有一个不直接涉及评价动作的人员参加评审。评审报告应包括在评价记录中。一旦评审通过，应按评价规格说明中的规定，把评价结果记入到评价报告中。此外，当评价计划也是这样规定时，某些中间结果或解释决定也应记入评价报告。

六、评价结论

1．评价结论的目的

评论结论的目的包括评价报告的评审和评价数据的处理。

2．评价报告的联合评审

评价报告的草稿应交付给评价的请求者。应组织评价者和请求者之间的联合评审。请求者应有机会对评价报告提出意见。之后，应把该评价报告交给请求者。

3．评价数据和文档的处置

将评价报告正式交付给请求者之后，评价者应处理与评价有关的数据。可以根据数据的类型使用以下方法进行：

（1）供评价的文档应归还给请求者，或存档一个规定的期限，或者以安全的方式销毁。

（2）评价报告和评价记录应存档到一个规定的期限。

（3）所有其他数据应存档一个规定的期限或以安全的方式销毁。

当某些数据的规定存档期限到期时，应将其再次保存一个规定的期限或以安全的方式销毁。只要请求者明确表示同意，评价者就可以使用中间评价结果，以便研究评价技术和软件的度量。

4．6　配置管理

一、概述

通常，软件测试配置管理包括以下4个最基本的活动：

（1）配置项标识；

（2）配置项控制（变更控制）；

（3）配置状态报告；

（4）配置审计。

二、配置项标识

（1）标识测试样品、标准、工具、文档（包括测试用例）、报告等配置项的名称和类型；

（2）指出何时基准化配置项（置于基线控制之下）；

（3）标识各配置项的所有者及储存位置。

三、配置项控制

1．规定测试基线

对每个基线必须描述以下内容：

（1）每个基线的项（包括文档、样品和工具）；

（2）与每个基线有关的评审、批准事项以及验收标准。规定何时何人创立新的基线，如何创立。

2．确定变更控制委员会的人员组成、职能（包括变更授权、确认与批准）、工作程序

3．确定变更请求的处理程序和终止条件

4．确定变更请求的处理过程中各测试人员执行变更的职能和变更请求和所产生结果的对应机制

5．确定配置项提取和存入的控制机制与方式

四、配置状态报告

（1）定义配置状态报告形式、内容和提交方式；

（2）确认过程记录和跟踪问题报告，更改请求，更改次序等；

（3）确定测试报告提交的时间与方式。

五、配置审计

（1）确定审计执行人员和执行时机。

（2）确定审计的内容与方式。

（3）确定发现问题的处理方法。

配置管理是管理和调整变更的关键（如图4-2所示），对一参与人员较多、变更较大的项目，其至关重要。软件测试配置管理概念的实际操作十分复杂。其用于测试工具、用例，且对于测试过程中的所有文档非常重要，也可用于测试样本和数据。

图4-2　配置管理原理图

4．7　测试的组织与人员

一、概念

组织是指一个系统将材料、知识和方法组合起来，把各种不同的输入转换成有价值的输出。组织结构是指用一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。

二、组织结构设计因素

测试组织结构的设计因素包括如下六个方面：

1．垂直还是平缓

垂直的组织结构是在首席管理者与低级测试人员之间设立了许多层次，平缓的垂直组织结构设立很少的几个层次。平缓的组织结构的测试工作效率较高。

2．市场还是产品

组织结构的设置可以是面向不同的市场或不同的产品。

3．集中还是分散

组织可以是集中的，也可以是分散的。这对于测试组织是比较关键的，为保证测试的独立性，一般测试组织要相对集中。

4．分级还是分散

可将组织按权力和级别一层层分级，也可分散排列开。在软件开发小组内的测试常使用分散方式，测试小组在开发小组内，可以是专职测试人员，或者以测试角色的形式组成。

5．专业人员还是工作人员

测试组织应拥有一定比例的专业测试人员和工作人员。

6．功能还是项目

测试组织可以面向功能或项目。

三、独立测试组织

测试组织是一种或一系列的资源，专门从事测试活动。只有不持偏见的人才能提供不持偏见的度量，测试度量软件质量才真正有效，测试必须独立进行。Bill Hetzel在《软件测试指南大全》中指出独立的测试组织的重要性，原因如下：

（1）没有这样的一个组织，建立系统就不会理想；

（2）有效的度量对于产品质量控制是十分重要的；

（2）测试协调需要全职、专门的人员投入。

四、测试组织管理者

测试管理是很困难的，测试组织的管理者必须具备以下能力：

（1）理解与评价软件测试政策、标准、过程、工具、培训和度量的能力；

（2）领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范没有偏见；

（3）吸引并留住杰出测试专业人才的能力；

（4）领导、沟通、支持和控制的能力；

（5）测试时间、质量和成本控制的能力。

五、集中管理的测试组织

结合组织的基本设计因素，可以构成许多不同的测试组织结构。在软件企业中，与独立测试有关的集中管理的一种测试组织形式，如图4-3所示。

图4-3　集中管理的测试组织

该方式的优点为，软件立项后，由独立的测试组织提供资源与软件开发人员并肩作战，与合作伙伴一块行动，可减少软件开发人员与测试人员合作时的不利因素。

六、选择合理的组织方案

组织设计因素可以组成不同的组织方案，在实际中软件开发机构和测试机构也都建立了不同结构的测试组织形式。选择合理高效的测试组织结构方案的准则如下：

（1）提供软件测试的快速决策能力；

（2）利于合作，尤其是产品开发与测试开发之间的合作；

（3）能够独立、规范、不带偏见地运作并具有精干的人员配置；

（4）有利于协调测试与质量管理的关系；

（5）有利于满足软件测试过程管理要求；

（6）有利于为测试技术提供专有技术；

（7）充分利用现有测试资源，特别是人；

（8）对测试者的职业道德和事业产生积极的影响。

七、测试人员

1．测试人员的选择

测试人员的能力包括以下几项：

（1）一般能力

一般能力包括表达、交流、协调、管理、质量意识、过程方法、软件工程等。

（2）测试技能及方法

测试技能及方法包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等。

（3）测试规划能力

测试规划能力包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等。

（4）测试执行能力

测试执行能力包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具。

（5）测试分析、报告和改进能力

测试分析、报告和改进能力包括测试度量、统计技术、测试报告、过程监测及持续改进。

2．测试人员的激励

（1）X理论＋Y理论

①X理论：胡萝卜＋大棒——迫使人们工作。

②Y理论：经理的职能不是督促人们工作，而是使人们有可能工作。

（2）需要的层次（Maslow模型）

①生存需要——工作职位、工资奖金、休息时间；

②安全需要——公正待遇、应付工作的能力和信心；

③社会需要——团队归属感，互相认同、理解和支持；

④自尊需要——具有受人尊重/赏识的能力或/和业绩；

⑤自我实现需要——成为自己期望的人物。

（3）人员激励的关键点

①管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；

②过多使用权力、资金或处罚手段很可能导致项目失败；

③行业领先企业采取卓有成效的非货币形式的激励措施；

④在项目进行过程中，而不仅是在项目结束时实施激励措施；

⑤对人员的工作表现出真诚的兴趣是对其最好的奖励；

⑥奖励应该在工作获得认同后尽快兑现；

⑦激励因素是因人而异、因时而异的。

已经满足的需要很可能不再成为激励因素。

（4）人员自我激励

测试工作的快乐哲学：选择积极的态度，把工作当作游戏，让别人快乐，全身心投入工作。

注意测试工作的7条效率原则：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）：先理解人，后被人理解；寻求双赢；互相合作，追求1＋1＞2；终生学习，自我更新，不断进步。

3．测试职业发展

国际推荐的软件测试职业发展计划如下：

（1）1～2年，测试技能

①熟悉整个测试过程及产品业务领域，学习和掌握自动测试工具，学习测试自动化编程技术；

②开发和执行测试脚本，承担系统测试实施任务；

③掌握编程语言、操作系统、网络与数据库方面的技能。

（2）3～4年，测试过程

①深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；

②进一步了解产品业务领域，改进测试自动化编程技术；

③能指导初级测试工程师；

④加强编程语言、操作系统、网络与数据库方面的技能。

（3）4～5年，测试组织工作

①管理1～3名测试工程师，担任任务估算、管理及进度控制；

②进一步培养在软件项目管理及支持工具方面的技能。

（4）5～6年，技术管理

①管理4～8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；

②研究测试的技术手段，保持使用项目管理及支持工具的技能；

③用大量时间为其他测试工程师提供技术及过程方面的指导；

④开始与客户打交道并做演示推介。

（5）6～12年，测试管理

①管理8名以上测试工程师，负责一个或多个项目的测试工作；

②与客户打交道并做演示推介；

③保持使用项目管理及支持工具的技能。

4．人员的培训

（1）软件测试培训内容分类

①测试基础知识和技能培训；

②测试设计培训、测试工具培训；

③测试对象——软件产品培训；

④测试过程培训；

⑤测试管理培训。

（2）制定测试人员培训计划

①是测试计划的一个重要组成部分；

②需要管理层的重视，在时间和资源上予以保证；

③认真调查和分析测试人员的培训需求；

④将培训活动安排在测试任务开始前；

⑤“边干边学”模式很可能牺牲质量和效率；

⑥软件测试实习活动在整个培训中占较大比例；

⑦鼓励合作学习，团队演练；

⑧对培训效果要及时评价，发现不足要进行改进。

4．8　软件测试风险分析

一、软件测试与商业风险

软件测试是一种用来尽可能降低软件风险的控制措施，是检测软件开发是否符合计划，是否达到预期的结果的测试。如果检测表明软件的实现没有按照计划执行或与预期目标不符，就要采取必要的改进行动。软件测试人员必须明白他们的任务之一就是通过测试来评估产品的商业风险，并将结果报告给公司管理者。

二、软件风险的定义

软件风险是指开发不成功引起损失的可能性，这种不成功事件会导致公司商业上的失败。

三、软件风险分析

风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。

1．风险分析的组成部分

（1）发生的可能性——发生问题的可能性有多大；

（2）影响严重性——如果问题发生了会有什么后果。

2．风险分析的组成步骤

（1）首先列出潜在问题；

（2）然后对标识的每个潜在问题发生的可能性和影响严重性赋值，进行风险测定；

（3）测试人员根据测试分析结果的排列，关注潜在问题，设计与选择测试用例。

3．风险分析采用的方法

（1）表格分析法

通用风险分析表包括以下几项内容：

①风险标识（ID）——表示风险事件的唯一标识；

②风险问题——问题发生现象的简要描述；

③发生的可能性——可能性值从1（低）～10（高）；

④影响的严重性——严重性值从1（低）～10（高）；

⑤风险预测值——发生可能性和影响严重性的乘积；

⑥风险优先级——风险预测值从高到低的排序。

软件风险分析表如表4-1所示。

表4-1　软件风险分析表

可能性与严重性的乘积产生的风险预测值，决定了风险优先级的排序。预测值越高，优先级别越高，针对该问题的测试就越重要。根据表4-1的计算结果风险问题的排列为B、A、D、C、E。在风险计算过程中，可能出现具有相同预测值的情况，有的测试机构可以通过将可能性和严重性分别加权计算来进行进一步的分析。

（2）风险矩阵

测试人员可根据需要对风险潜在问题的可能性和严重性采用高（1）、中（2）、低（3）三个等级来表示，形成一个二维风险矩阵，而风险优先级可用二者值之和表示。这样，可能存在五个风险等级（即6、5、4、3、2，如图4-4所示）。

图4-4　软件风险分析矩阵

总之，风险优先级是由软件潜在问题影响的严重性决定的，是个相对值，而潜在问题的影响严重性是根据问题的可能性来评定的。如图4-4所示，风险优先级的确定是使用可能性和严重性等级值相加，但是如果使用两者值相乘，将会扩大有风险的区域。

4．风险分析的目的

软件风险分析的目的是确定测试对象、测试优先级以及测试的深度。有时还包括确定可忽略的测试对象。在测试计划阶段，可以用风险分析的结果来确定软件测试的优先级。对各测试项和测试用例赋予优先级代码，将测试分为高、中和低的优先级类型，这样可以在有限的资源和时间条件下，合理安排测试的覆盖度与深度。

5．工作组成

软件风险分析工作应由各部门的专家组成，通常包括：项目经理、开发人员、测试人员、用户、客户以及销售人员。

6．注意事项

（1）对所有的软件项目都应进行风险分析。如果软件本身的缺陷与错误能够导致灾难性后果，那么这样的软件称为安全性重要软件，它在开发过程的各个阶段都应进行安全性分析。

即使是非重要软件，在项目的初期进行风险分析，有助于识别潜在的问题。这些问题可能会引发严重的后果，因此项目经理和开发人员在开发中要特别注意，以便预防风险。

（3）测试人员可利用风险分析的结果选择最关键的测试，大部分的测试资源应该用在控制最高级别的商业风险上，而最低级别的商业风险应该占用尽可能少的测试资源。只有这样，软件测试人员才能制定合理的策略，控制软件开发的风险。

四、软件测试风险

1．概念

软件测试风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，导致测试的补充以及结果的不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，将会带来很大的商业风险。

2．测试计划的风险

（1）概念

测试计划的风险一般指测试进度滞后或出现非计划事件，即针对计划好的测试工作造成消极影响的所有因素，对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。一些常见的计划风险包括：交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、劣质组件、测试工具等。

（2）交付日期

交付日期的风险是主要风险之一。测试未按计划完成，发布日期推迟，影响对客户提交产品的承诺，管理的可信度和公司的信誉都要受到考验，同时也受到竞争对手的威胁。交付日期的滞后，也可能是已经耗尽了所有的资源。

（3）计划风险分析的工作重点

计划风险分析的工作重点应放在提前制定应急措施来应对风险发生。当测试计划风险发生时，可能采用的应急措施有：缩小范围、增加资源、减少过程等措施。

例如：用户在软件开发接近尾声时，提出重要需求变动。

①应急措施1：增加资源。请求用户团队为测试工作提供更多的用户支持；

②应急措施2：缩小范围。决定在进行后续发布中实现较低优先级的特性；

③应急措施3：减少质量过程。在风险分析过程中确定某些风险级别低的特征测试或少测试。

上述列举的应急措施涉及到有关方面的妥协：如果没有测试计划风险分析和应急措施处理风险，开发者和测试人员采取的措施比较匆忙，不利于将风险的损失控制到最小。因此，软件风险分析和测试计划风险分析与应急措施相辅相成。综上所述，计划风险、软件风险、重点测试、不测试，甚至整个软件的测试与应急措施都是围绕“用风险来确定测试工作优先级”原则来构造的。

4．9　软件测试的成本管理

一、测试费用有效性

测试费用的有效性，可以用测试费用—质量曲线（如图4-5所示）来表示。随着测试费用的增加，发现的缺陷也会越多，两线相交的地方是过多测试开始的地方，这时，排除缺陷的测试费用超过了缺陷给系统造成的损失费用。

图4-5　测试费用质量曲线

二、测试成本控制

测试的成本控制目标是使测试开发成本、测试实施成本和测试维护成本最小化。在软件产品开发过程中，作为产品发布每一新版本而进行的重复性的测试所需的成本是主要考虑的问题。测试实施成本组成部分包括：测试准备成本、测试执行成本和测试结束成本。

1．测试准备成本控制

测试准备成本控制的目标是使时间消耗总量、劳动力总量，尤其是准备工作所需的熟练劳动力总量最小化。准备工作一般包括：硬件配置、软件配置、测试环境建立，以及测试环境的确定等。

2．测试执行成本控制

测试执行成本控制的目标是使总执行时间和所需的测试专用设备尽可能地减少。执行时间要求操作和用户进行手工操作执行测试的时间应尽量减少，同时对劳动力和所需的技能也尽量减少。如需重新测试，不同选择会有不同的成本控制效果，重新测试的决策是在成本与风险的矛盾中进行的。

（1）完全重新测试

将测试全部重新执行一遍，将风险降至最低，但加大了测试执行的成本。

（2）部分重新测试

有选择地重新执行部分测试，能减少执行成本，但加大了风险。对部分重新测试进行合理选择，将风险降至最低，而成本会很高，必须将其与测试执行成本进行比较，权衡利弊。利用测试自动化，进行重新测试，其成本效益较好。部分重新测试选择方法有以下两种：

①对由于程序变化而受到影响的每一部分进行重新测试。

②对与变化有密切和直接关系的部分进行重新测试。

注意：第一种办法风险要小，而第二种是一种主观制定的办法，是建立在对软件产品十分了解的基础上的。一般地，选择重新测试的策略建立在软件测试错误的多少（即软件风险的大小）与测试的时间、人力、资源投入成本的大小之间的折衷基础上。

3．测试结束成本控制

进行测试结果分析和测试报告编制、测试环境的清除与恢复原环境所需的成本，使所需的时间和熟练劳动力总量减少到最低限度。

4．降低测试实施成本

（1）测试环境应建立在固定的测试专用硬软件及网络环境中，尽可能使用软件和测试环境配置自动化。

（2）测试实施尽可能采用自动化的测试工具，减少手工辅助测试。

（3）若测试执行需要人工，最好是请初级技术人员，而不是测试工程师，测试工程师一般是作为测试项目经理。

（4）测试结束编制测试报告时，测试结果与预期结果的比较采用自动化方法，以降低分析比较成本。

（5）测试自动化的方法主要有：使用测试工具；测试用例的自动化执行；测试文档编制的模板自动化生成。

5．降低测试维护成本

降低测试维护成本，同软件开发过程，加强软件测试的配置管理，所有测试的软件样品、测试文档（测试计划、测试说明、测试用例、测试记录、测试报告）都应置于配置管理系统控制之下。

（1）降低测试维护工作成本主要考虑的因素

①对于测试中出现的偏差要增加测试。

②采用渐进式测试以适应新变化的测试。

③定期检查维护所有测试用例，以获得测试效果的连续性。

（2）重要措施

保持测试用例效果的连续性是重要的措施，有以下几个方面：

①每个测试用例都是可执行的，即被测产品，功能上不应有任何变化。

②基于需求和功能的测试都应是适合的，若产品需求和功能发生较小的变化，不应使测试用例无效。

③每个测试用例不断增加使用价值，即每个测试用例不应是完全冗余的，连续使用应是成本效益高的。

三、质量成本

1．质量成本要素

（1）一致性成本（Costof Conformance）

一致性成本指用于保证软件质量的支出，包括预防成本（preventioncost）和测试预算，如测试计划、测试开发、测试实施费用。测试预算被称为审查费（appraisalcost）

（2）非一致性成本（Costof Nonconformance）

非一致成本由出现的软件错误和测试过程故障（如延期、劣质的测试发布）引起。这些问题会导致测试返工、补测、延迟。追加测试时间和资金就是一种由于内部故障引起的非一致成本。还包括外部故障（软件遗留错误影响客户）引起部分。这些成本还包括技术支持小组预算，错误修正花费、产品收回、赔偿和销售成本。

注意：通常，外部故障非一致成本要大于一致性成本与内部故障非一致成本之和。

即

2．质量成本计算

质量成本＝一致性成本＋非一致性成本

即

四、缺陷探测率（DDP）

缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。

1．参数

（1）Bugs tester：测试者发现的错误数。

（2）Bugs customer：客户发现并反馈技术支持人员进行修复的错误数。

2．注意

缺陷探测率越高，即测试者发现的错误越多，发布后客户发现的错误就越少，降低了外部故障不一致成本，达到了节约总成本的目的，可获得较高的测试投资回报率（ROI）。故缺陷探测率是衡量测试投资回报的一个重要指标。

五、测试投资回报举例

1．案例介绍

假设对一开发的客户管理软件CRM进行测试。质量预防方面的一致性成本只考虑软件测试的投资，把发布前后发现及修改的错误看成非一致性成本，假设发现的错误为300个，故障成本已知，测试过程的估算如下。各阶段花费在发现及修改错误的成本假设如下：

（1）在开发过程单元测试阶段，软件开发人员发现及修改一个错误需要50元。

（2）建立独立的测试进行集成和系统测试，测试人员发现错误，开发人员修改后，测试人员再确认，一个错误需要300元。

（3）在产品发布后，由客户发现，报告技术支持人员、相关开发人员修改，测试组再进行回归测试，一个错误需要2000元。

2．各种情况

（1）第1种情况

开发单位未建立独立测试队伍，由开发人员进行测试，发现100个错误，而产品发布后客户发现错误200个，只存在故障成本构成的总成本为405000元，缺陷探测率为33.30%。

（2）第2种情况

开发单位建立了独立测试队伍，进行手工测试。投资预算人员费用为60000元，测试环境使用费为8000元，测试投资（一致性成本）为68000元；除了开发过程中开发人员发现并修改100个错误外，测试过程中测试人员发现错误150个，而产品发布后客户发现50个错误。总质量成本下降到218000元（如表4-2所示），手工测试总质量成本节约了187000元，即为利润。投资回报率（ROI）为275%，缺陷探测率为83.3%。

表4-2　测试投资回报分析

（3）第3种情况

开发单位在独立测试中，采用自动化测试工具，投资中增加10000元的工具使用费，测试投资为（一致性成本）78000元。由于使用测试工具，测试人员在测试中发现错误增加到190个，在产品发布后，客户发现错误下降到10个。总质量成本下降到160000元，比未建立独立测试前节约了245000元。投资回报率为314%，缺陷探测率为96.7%。

综上所述，建立独立的软件测试队伍，选择好的测试方案，不但提高了软件缺陷的探测率，有效地控制软件的风险，提高软件质量，而且降低了软件的质量成本，测试的投资回报率也将随着明显提高。