产品质量是正在由流程生产的产品的质量。在软件开发中，产品是许多工件的聚合，其中包括：

·                       已部署的可执行代码（应用程序、系统等），这可能是最显而易见的工件，因为项目通常是由于该工件才存在的。也就是说，它是为客户（最终用户、股东、涉众等）提供价值的首要产品。

·                       已部署的不可执行工件，包括用户手册和教程资料等工件。

·                       未部署的可执行工件，如工件的实施集，包括已创建用于支持实施的测试脚本和开发工具。

·                       未部署的不可执行工件，如实施计划、测试计划和各种模型。

由于很多工件都建立在其他工件的基础上，所以在某种程度上，所有工件的质量都是相关的。因此，对每个工件的质量都应该评测和评估。

测试脚本是自动执行测试过程（或部分测试过程）的计算机可读指令。测试脚本可以被创建（记录）或使用测试自动化工具自动生成，或用编程语言编程来完成，也可综合前三种方法来完成。

1.1可执行工件的产品质量（部署的和未部署的）：

可执行工件是通过其需求来描述的，并表述为用例或补充需求（如销售、性能等）。

要评测并达到质量要求，必须了解这些需求并以清楚、简明和可核实（可测试）的方式陈述这些需求。对于软件来说，测试角色不会将所有需求当作测试对象（如市场渗透或销售收益）。对于那些将成为测试对象的需求来说，测试设计员必须能够指定一种方法来核实是否满足需求（正如已指定的）、没有偏离既定意图并且没有缺陷。

产品质量是通过评测以下质量维度和评测产品是否满足这些维度的要求来决定的：

·                       可靠性：已部署的代码在执行过程中的防故障（崩溃、挂起、内存丢失等）能力。

·                       功能：已部署的代码按既定意图执行所需的用例。

·                       性能：在实际的操作特征（如负载、强度和长时间运行）条件下，已部署的代码以及时和可接受的方式执行和响应，并以可接受的方式继续运行。

对于每一维度，在测试的一个或多个不同阶段，应该实施和执行一种或多种测试类型。

此外，还可通过评测每一工件新版本的可执行工件中所作的变更数量和类型来评估产品质量。

（注解）质量维度

可靠性：软件坚固性和可靠性（防故障能力，如防止崩溃、内存丢失等能力）、资源利用率和代码完整性以及结构（语言和语法的技术兼容性）。

功能：按照既定意图和要求，执行指定用例的能力。

性能：测试对象的计时配置文件和操作特征。计时配置文件包括代码的执行流、数据访问、函数调用和系统调用。性能的操作特征包括与作业负载相关的特征，如响应时间、操作可靠性 (MTTF)； 以及与操作限制相关的特征，如负载容量或强度。

1.2不可执行工件的产品质量（已部署的或未部署的）：

不可执行工件的产品质量通过工件的目的、目标和结构来描述，并通过确保工件符合以下各项要求来评估：

·                       工件内部和工件之间的一致性（语言的使用、术语或语义等）。

·                       指南、标准和合同需求（语言的使用、术语、语义、格式或内容等）的兼容性

此外，还可以通过工件版本之间所作变更的数量和类型来评估不可执行工件的产品质量。

为了帮助评估 RUP 中工件的产品质量,我们在 RUP 中包括了以下针对大多数工件的信息类型：

·                       工件指南和检查点：有关如何开发、评估和使用工件的信息。

·                       模板：工件的“模型”或原型，为内容提供结构和指导。

1.3测试的生命周期

在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。该方法表明它将导致在整个流程中重复进行测试，就象修订软件本身一样。这里没有一成不变的软件规约，也没有一成不变的测试。

（iteration—重复，反复，重述－跌代）

该迭代方法非常注重回归测试。迭代 X 中的大多数测试在迭代 X+1 中都用作回归测试。在迭代 X+2 中，将使用迭代 X 和迭代 X+1 中的大多数测试作为回归测试，后续迭代中采用的原则与此相同。因为相同的测试要重复多次，所以投入一些精力将测试自动化将会获益良多。此外，也有必要有效地自动执行测试，来满足完工期限的要求。 

在同一张图中，观察不具有项目其余部分的测试的生命周期。图中展示了不同测试活动在非迭代视图中相互联系的方式：

测试的生命周期。

Coverage——范围，Defect——缺陷，Specification说明书，详细设计书， Implement——工具,Execute——实现，执行,Integration——完成，积分法,Evaluate——评估

该生命周期必须与迭代方法结合起来，这意味着每个迭代都将具有遵循该模式的测试周期。

 

执行测试既是新测试的执行，又是使用先前测试的回归测试。

测试的生命周期是软件生命周期的一部分；它们应该同时开始。测试的设计开发过程与正在构建的应用程序一样复杂和艰巨。如果未能尽早开始，测试或者不够完善，或者会导致需要在开发时间表上附加一个长时间的测试和错误修正时间表，这将有违迭代开发的初衷。此外，测试计划和设计活动可以揭示应用程序定义中的故障和缺陷。这些问题越早得以解决，对整个时间表造成的影响就越小。评价过程中发现的问题可以在本次迭代解决，也可以留待下次迭代解决。通过核实已经实施的需求来评测迭代的完全程度，是评价的主要任务之一。迭代之间始终存在着某种“需求蠕变”，您需要意识到其存在并能够对其加以管理。

执行测试的方式取决于多种因素：您的应用领域、预算、公司策略和风险承受能力以及职员。对于测试的投资多少取决于在具体环境中评价质量和承受风险的方式。

1.4测试的主要评测方式

1.4.1简介

测试的主要评测方法包括覆盖和质量。

覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。

1.4.2覆盖评测

覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

1.4.2.1基于需求的测试覆盖

基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

·                       测试覆盖通过以下公式计算：

测试覆盖 = T^(p,i,x,s) / RfT

其中：
T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。

RfT 是测试需求 (Requirement for Test) 的总数。

·                       在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

测试覆盖（已计划的） = T^p / RfT

其中：
T^p 是用测试过程或测试用例表示的已计划测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

·                       在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：

测试覆盖（已实施的） = Tⁱ / RfT

其中：
Tⁱ 是用测试过程或测试用例表示的已实施的测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

·                       在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。

这些覆盖评测通过以下公式计算：

测试覆盖（已执行的） = T^x / RfT

其中：
T^x 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

 

成功的测试覆盖（已执行的） = T^s / RfT

其中：
T^s 是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

 

如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：

x% 的测试用例（上述公式中的 T^(p,i,x,s)）已经覆盖，成功率为 y%

这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

1.4.2.2基于代码的测试覆盖

基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

基于代码的测试覆盖通过以下公式计算：

测试覆盖 = I^e / TIic

其中：
I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。

TIic (Total number of Items in the code) 是代码中的项目总数。

如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：

x% 的测试用例（上述公式中的 I）已经覆盖，成功率为 y%

这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

1.4.3质量评测

测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

缺陷分析就是分析缺陷在与缺陷关联的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

对于缺陷分析，常用的主要缺陷参数有四个：

·                       状态：缺陷的当前状态（打开的、正在修复或关闭的等）。

·                       优先级：必须处理和解决缺陷的相对重要性。

·                       严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。

·                       起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。

1.4.4缺陷报告

Rational Unified Process 以三类形式的报告提供缺陷评估：

·                       缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。

·                       缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。

·                       缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。

·                       测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。

许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。

要有效生成此类报告，一般需要工具支持。

1.4.4.1缺陷密度报告

1.4.4.1.1缺陷状态与优先级

应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：

1.        立即解决

2.        高优先级

3.        正常排队

4.        低优先级

一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个。

1.4.4.1.2缺陷状态与严重性

缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。

1.4.4.1.3缺陷状态与在实施模型中的位置

缺陷起源报告显示缺陷在实施模型元素上的分布情况。

1.4.4.2缺陷龄期报告

缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。

1.4.4.3缺陷趋势报告

趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。

 

 

要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。

这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。

该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。

如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。

当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。

1.4.5性能评测

评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。

主要的性能评测包括：

• 动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。
• 响应时间/吞吐量 -测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。
• 百分位报告 - 数据已收集值的百分位评测/计算。
• 比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。
• 追踪报告-主角（测试脚本）和测试对象之间的消息/会话详细信息。

1.4.5.1动态监测

动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试脚本正在执行的进度来监测或评估性能测试执行情况。

例如，在以上柱状图中，有 80 个测试脚本正在执行相同的用例。图中显示，有 14 个测试脚本处于空闲状态，12 个处于查询状态，34 个处于 SQL 执行状态，4 个处于 SQL 连接状态，16 个处于其他状态。随着测试的进行，我们将看到各状态脚本的数量会发生变化。显示的输出将是正常执行且正在执行中的典型测试执行。但是，如果在测试执行过程中，测试脚本始终保持一种状态或没有显示任何变化，则表明测试执行发生问题或者需要实施或执行其他性能评测。

1.4.5.2响应时间/吞吐量报告

正如其名称的含义一样，响应时间/吞吐量报告评测并计算与时间和/或吞吐量（处理的事务数）相关的性能行为。这些报告通常用曲线图显示，响应时间（或事务数）在“y”轴上，而事件数在“x”轴上。