软件质量管理 第六章.pptx

《软件质量管理 第六章.pptx》由会员分享，可在线阅读，更多相关《软件质量管理 第六章.pptx（79页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、第六章第六章 软件缺陷跟踪管理软件缺陷跟踪管理目录目录1 1、 软件缺陷的概念和种类软件缺陷的概念和种类2 2、 正确面对软件缺陷正确面对软件缺陷3 3、 软件缺陷的生命周期软件缺陷的生命周期4 4、 软件缺陷的严重性和优先级软件缺陷的严重性和优先级 5 5、 报报 告告 软软 件件 缺缺 陷陷6 6、 分离和再现软件缺陷分离和再现软件缺陷7 7、 测测 试试 总总 结结 报报 告告8 8、 测测 试试 的的 评评 测测 软件测试是在软件开发的过程中，对软件产软件测试是在软件开发的过程中，对软件产品进行质量控制，目的是保证软件产品的最终质品进行质量控制，目的是保证软件产品的最终质量。一般来说软

2、件测试应严格按照软件测试流程，量。一般来说软件测试应严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，制定测试计划、测试方案、测试规范，实施测试，对测试数据进行记录，并根据测试情况撰写测试对测试数据进行记录，并根据测试情况撰写测试报告。测试报告主要是报告发现的软件缺陷。报告。测试报告主要是报告发现的软件缺陷。 测试评价主要包括覆盖评价以及质量测试评价主要包括覆盖评价以及质量和性能评价。覆盖评价是对测试完全程度和性能评价。覆盖评价是对测试完全程度的评测；质量和性能评价是对测试的软件的评测；质量和性能评价是对测试的软件对象的性能、稳定性以及可靠性的评测。对象的性能、稳定性以及可靠性

3、的评测。1、 软件缺陷的概念和种类软件缺陷的概念和种类 软件缺陷简单说就是存在于软件（文档、数软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定差，而导致软件产生的质量问题。按照一般的定义，只要符合下面义，只要符合下面5 5个规则中的一个，就叫做软件个规则中的一个，就叫做软件缺陷。缺陷。 软件未达到软件规格说明书中规定的功能；软件未达到软件规格说明书中规定的功能； 软件超出软件规格说明书中指明的范围；软件超出软件规格说明书中指明的范围； 软件未达到软件规格说明书中指出的应达到的目软

4、件未达到软件规格说明书中指出的应达到的目标；标； 软件运行出现错误；软件运行出现错误； 软件测试人员认为软件难于理解，不易使用，运软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。行速度慢，或者最终用户认为软件使用效果不好。 在软件测试过程中如何判断软件缺陷，软件在软件测试过程中如何判断软件缺陷，软件缺陷都有哪些种类？缺陷都有哪些种类？ （1 1）功能不正常）功能不正常 （2 2）软件在使用上不方便）软件在使用上不方便 （3 3）软件的结构未做良好规划）软件的结构未做良好规划 （4 4）功能不充分）功能不充分 （5 5）与软件操作者的互动不良）与软件操作者的

5、互动不良 （6 6）使用性能不佳）使用性能不佳（7 7）未做好错误处理）未做好错误处理（8 8）边界错误）边界错误（9 9）计算错误）计算错误（1010）使用一段时间所产生的错误）使用一段时间所产生的错误（1111）控制流程的错误）控制流程的错误（1212）在大数据量压力之下所产生的错误）在大数据量压力之下所产生的错误（1313）在不同硬件环境下产生的错误）在不同硬件环境下产生的错误（1414）版本控制不良所产生的错误）版本控制不良所产生的错误（1515）软件文档的错误）软件文档的错误2、正确面对软件缺陷、正确面对软件缺陷 在软件测试过程中，软件测试人员必须在软件测试过程中，软件测试人员必须确

6、保测试过程发现的软件缺陷得以关闭。确保测试过程发现的软件缺陷得以关闭。 测试是为了证明程序有错，而不是证测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺行测试多么努力，也不能保证所有软件缺陷发现了就能修复。陷发现了就能修复。 有些软件缺陷可能会完全被忽略，还有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。有些软件缺陷不被修复的原因如下。（1 1）没有足够的时间）没有足够的时间（2 2）不算真正的软件缺陷）不算真正的软

7、件缺陷（3 3）修复的风险太大）修复的风险太大（4 4）不值得修复）不值得修复 虽然软件测试人员需要对自己找出的软件缺虽然软件测试人员需要对自己找出的软件缺陷保持一种平常心态，但同时又必须坚持有始有陷保持一种平常心态，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。保软件缺陷得以关闭。 而缺陷是否需要修复的最终决定权在软件的而缺陷是否需要修复的最终决定权在软件的项目负责人，但使得缺陷得以关闭的责任在测试项目负责人，但使得缺陷得以关闭的责任在测试人员。人员。3、软件缺陷的生命周期、软件缺陷的生命周期 软件缺陷从被测试人

8、员发现一直到被软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现期的例子，系统地表示软件缺陷从被发现起经历的各个阶段：起经历的各个阶段： （1 1）测试人员找到并登记软件缺陷，软件）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。缺陷被移交到程序修复人员。 （2 2）程序修复人员修复软件中的软件缺陷，）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。然后移交到测试人员。 （3 3）测试人员确认软件缺陷被修复，关闭）测试

9、人员确认软件缺陷被修复，关闭软件缺陷。软件缺陷。 当软件缺陷首先被软件测试人员发现时当软件缺陷首先被软件测试人员发现时 。 在许多情况下，软件缺陷生命周期的在许多情况下，软件缺陷生命周期的复杂程度仅为软件缺陷被打开、解决和关复杂程度仅为软件缺陷被打开、解决和关闭。然而，在有些情况下，生命周期变得闭。然而，在有些情况下，生命周期变得更复杂一些，如图更复杂一些，如图5-15-1所示。所示。 发现软件缺陷 软件缺陷移交到项目管理员 测试员找到并登记软件缺陷 软件缺陷被移交到程序员 程序员认为软件缺陷微不足道 软件缺陷移交到测试员 项目管理员认为软件缺陷不重要 测试员不同意，找出 通用失败案例 软件缺

10、陷移交到项目管理员 软件缺陷移交到测试员 软件缺陷移交到程序员 测试员确认 软件缺陷得以修复 程序员修复软件缺陷 测试员关闭软件缺陷 项目管理员现在同意 软件缺陷需要修复 打开 打开 以不修复 形式解决 打开 打开 以修复 形式解决 关闭 图图5-1 复杂的软件缺陷生命周期复杂的软件缺陷生命周期 4、软件缺陷的严重性和优先级、软件缺陷的严重性和优先级 测试人员要对软件缺陷分类，以简明扼要的测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。严重性表示软件缺陷的恶划分严重性和优先级。严重性表示软件缺陷的恶劣

11、程度，反映其对产品和用户的影响；优先级表劣程度，反映其对产品和用户的影响；优先级表示修复缺陷的重要程度和应该何时修复。下面给示修复缺陷的重要程度和应该何时修复。下面给出严重性和优先级的常用划分方法，将有助于测出严重性和优先级的常用划分方法，将有助于测试人员更好地理解两者之间的差异。试人员更好地理解两者之间的差异。 严重性级别：严重性级别： 致命错误，例如，导致系统崩溃、致命错误，例如，导致系统崩溃、数据丢失、数据毁坏等；数据丢失、数据毁坏等； 一般性错误，例如，操作性错误、一般性错误，例如，操作性错误、错误结果、遗漏功能等；错误结果、遗漏功能等； 次要错误，例如，错别字、用户接次要错误，例如，

12、错别字、用户接口布局、罕见故障等。口布局、罕见故障等。缺陷优先级：缺陷优先级： 最高优先级，指的是一些关键性错误，必最高优先级，指的是一些关键性错误，必须立即修复；须立即修复； 高优先级，在产品发布之前必须修复；高优先级，在产品发布之前必须修复； 中优先级，如果时间允许应该修复；中优先级，如果时间允许应该修复； 低优先级，可能会修复，但是也能发布软低优先级，可能会修复，但是也能发布软件。件。5、报、报 告告 软软 件件 缺缺 陷陷报告软件缺陷的基本原则：报告软件缺陷的基本原则： 在软件测试过程中，对于发现的大多数软件缺陷，在软件测试过程中，对于发现的大多数软件缺陷，要求测试人员简捷、清晰地把发

13、现的问题报告给要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。部信息，然后才能决定怎么做。 报告软件缺陷的基本原则如下：报告软件缺陷的基本原则如下：1尽快报告软件缺陷2有效地描述软件缺陷 有效的软件缺陷描述要求如下：有效的软件缺陷描述要求如下：（1 1）简单与短小）简单与短小（2 2）明确指明错误类型）明确指明错误类型（3 3）单一）单一（4 4）使用）使用ITIT业界惯用的表达术语和表达方业界惯用的表达术语和表达方法法 3 3在报告软件缺陷时不做任何评价在报告软件缺陷时不做任何评价4 4

14、补充和完善软件缺陷报告补充和完善软件缺陷报告 以上概括了报告测试错误的规范要求，测试以上概括了报告测试错误的规范要求，测试人员应该牢记上面这些关于报告软件缺陷的原则。人员应该牢记上面这些关于报告软件缺陷的原则。这些原则几乎可以运用到任何交流活动中，尽管这些原则几乎可以运用到任何交流活动中，尽管有时难以做到，然而，如果希望有效地报告软件有时难以做到，然而，如果希望有效地报告软件缺陷，并使其得以修复，这些是测试人员要遵循缺陷，并使其得以修复，这些是测试人员要遵循的基本原则。的基本原则。 随着软件的测试要求不同，测试者积累了相随着软件的测试要求不同，测试者积累了相应的测试经验会，将会逐渐养成良好的专

15、业习惯，应的测试经验会，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断以前的测试错误报告进行对比和思考，可以不断提高技巧。提高技巧。IEEE软件缺陷报告模板软件缺陷报告模板 ANS/IEEE8291998 ANS/IEEE8291998标准定义了一个标准定义了一个称为软件缺陷报告的文档，用于报告称为软件缺陷报告的文档，用于报告“在在测试期间发生的任何异常事件测试期间发生的任何异常事件”。简言之，。简言之，

16、就是用于登记软件缺陷。模板标准如图就是用于登记软件缺陷。模板标准如图5-5-3 3所示。所示。图图5-3 IEEE5-3 IEEE软件缺陷报告模板软件缺陷报告模板 IEEE8291998软件测试文档编制标准 软件缺陷报告模板 目录 1软件缺陷报告标识符 2软件缺陷总结 3软件缺陷描述 3.1 输入 3.2 期望得到的结果 3.3 实际结果 3.4 异常情况 3.5 日期和时间 3.6 软件缺陷发生步骤 3.7 测试环境 3.8 再现测试 3.9 测试人员 3.10 见证人 4影响 软件缺陷数据库跟踪系统软件缺陷数据库跟踪系统 至此，我们了解到软件缺陷报告过程是很至此，我们了解到软件缺陷报告过程

17、是很复杂的，需要大量信息、详尽的细节和很好的复杂的，需要大量信息、详尽的细节和很好的组织工作，才能有所成效。在实际软件测试工组织工作，才能有所成效。在实际软件测试工作中，为了更高效地记录发现的软件缺陷，并作中，为了更高效地记录发现的软件缺陷，并在软件缺陷的整个生命周期中对其进行监控，在软件缺陷的整个生命周期中对其进行监控，常常运用软件缺陷跟踪系统。图常常运用软件缺陷跟踪系统。图5-45-4所示的是一所示的是一个软件缺陷数据库跟踪系统。个软件缺陷数据库跟踪系统。图图 软件缺陷数据库跟踪系统软件缺陷数据库跟踪系统 软件缺陷跟踪数据库最常用的功能，除了输入软件缺陷跟踪数据库最常用的功能，除了输入软件

18、缺陷之外，就是通过执行查询来获得需要的软件缺陷之外，就是通过执行查询来获得需要的软件缺陷清单。软件缺陷清单。 通过使用软件缺陷跟踪数据库，不但可以进通过使用软件缺陷跟踪数据库，不但可以进行查询，还可以找出发现的软件缺陷类型，发现行查询，还可以找出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了软件缺陷的速度，以及多少软件缺陷已经得到了修复，能够提取各种实用和关心的数据，可以显修复，能够提取各种实用和关心的数据，可以显示测试工作的成效和项目的进展情况。示测试工作的成效和项目的进展情况。 测试人员或者项目管理员可以看出数据中是测试人员或者项目管理员可以看出数据中是否有趋势显示需要

19、增加测试的区域，或者测试工否有趋势显示需要增加测试的区域，或者测试工作是否符合预先所制定的测试计划的进程等。作是否符合预先所制定的测试计划的进程等。手工报告和跟踪软件缺陷手工报告和跟踪软件缺陷 显然，在软件测试工作中，每个测试用例的显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷数据库结果都必须进行记录。如果使用软件缺陷数据库跟踪系统，那么测试工具将自动记录软件缺陷的跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在缺陷，那么有关软件缺陷的信息可以直接

20、记录在相应的文档中。图相应的文档中。图5-55-5所示的是根据所示的是根据ANS/IEEE8291998ANS/IEEE8291998标准设计的软件缺陷报告文档。标准设计的软件缺陷报告文档。 图图5-5 5-5 软件缺陷报告文档软件缺陷报告文档 6、分离和再现软件缺陷、分离和再现软件缺陷 测试人员要想有效报告软件缺陷，就要对软测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。件缺陷以明显、通用和再现的形式进行描述。 分离和再现软件缺陷是考验软件测试人员专分离和再现软件缺陷是考验软件测试人员专业技能的地方，测试人员应该设法找出缩小问题业技能的地方，测试人员应该设法找出

21、缩小问题范围的具体步骤。对测试人员有利的情况是，若范围的具体步骤。对测试人员有利的情况是，若建立起绝对相同的输入条件时，软件缺陷就会再建立起绝对相同的输入条件时，软件缺陷就会再次出现，不存在随机的软件缺陷。次出现，不存在随机的软件缺陷。 如果找到的软件缺陷要采取繁杂的步骤才能如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷。实践证明取如下的方法来分离和再现软件缺陷。实践证明这些方法对测试人员是有所帮助的。这些方法对测试人员是有所帮助的。（1）不要想当然地接受任何假设（2）注意时间和运行条件

22、上的因素（3）注意软件的边界条件、内存容量和数据溢出的问题（4）注意事件发生次序导致的软件缺陷（5）考虑资源依赖性和内存、网络、硬件共享的相互作用（6）不要忽视硬件7、测、测 试试 总总 结结 报报 告告 测试总结报告的目的是总结测试活动的结果，测试总结报告的目的是总结测试活动的结果，并根据这些结果对测试进行评价。这种报告是测并根据这些结果对测试进行评价。这种报告是测试人员对测试工作进行总结，并识别出软件的局试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。在测试执行阶段的末限性和发生失效的可能性。在测试执行阶段的末期，应该为每个测试计划准备一份相应的测试总期，应该为每个测试计

23、划准备一份相应的测试总结报告。本质上讲，测试总结报告是测试计划的结报告。本质上讲，测试总结报告是测试计划的扩展，起着对测试计划扩展，起着对测试计划“封闭回路封闭回路”的作用。的作用。 图图5-65-6所示的是符合所示的是符合IEEEIEEE标准标准82919988291998软件软件测试文档编制标准的测试总结报告模板。测试文档编制标准的测试总结报告模板。 IEEE 标准 8291998 软件测试文档编制标准 测试总结报告模板 目录 1测试总结报告标识符 2总结 3差异 4综合评估 5结果总结 5.1 已解决的意外事件 5.2 未解决的意外事件 6评价 7建议 8活动总结 9审批 图图5-6 5

24、-6 测试总结报告模板测试总结报告模板 8、测、测 试试 的的 评评 测测 测试的评测主要方法包括覆盖评测和质量评测试的评测主要方法包括覆盖评测和质量评测。测试覆盖评测是对测试完全程度的评测，它测。测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复

25、的分析基础上。试过程中确定的缺陷及缺陷修复的分析基础上。8.1 覆盖评测覆盖评测 覆盖评测指标是用来度量软件测试的完全覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计对需求（基于需求的）或代码的设计/ /实施标准实施标准（基于代码的）而言的完全程度评测。（基于代码的）而言的完全程度评测。1 1）基于需求的测试覆盖）基于需求的测试覆盖 基于

26、需求的测试覆盖在测试过程中要评测多次，并在基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。的测试覆盖等。 基于需求的测试覆盖率通过以下公式计算：基于需求的测试覆盖率通过以下公式计算： 测试覆盖率测试覆盖率= =T T (p,i,x,s) (p,i,x,s) / / Rf T Rf T % % 在制定测试计划活动中，将计算计划的测在制定测试计划活动中，将计算计划的测试覆盖，其计算方法

27、如下：试覆盖，其计算方法如下： 计划的测试覆盖率计划的测试覆盖率= =T T p p / / Rf T Rf T % % 其中：其中：T T p p是用测试过程或测试用例表示的是用测试过程或测试用例表示的计划测试需求数。计划测试需求数。RfRfT T是测试需求的总数。是测试需求的总数。 在实施测试过程中，计算测试覆盖时使用以在实施测试过程中，计算测试覆盖时使用以下公式：下公式： 已执行的测试覆盖率已执行的测试覆盖率= =T T i i / / Rf T Rf T % % 其中：其中：T Ti i是用测试过程或测试用例表示是用测试过程或测试用例表示的已执行的测试需求数。的已执行的测试需求数。Rf

28、TRfT是测试需求的是测试需求的总数。总数。 在执行测试活动中，确定成功的测试覆盖率（即在执行测试活动中，确定成功的测试覆盖率（即执行时未出现失败的测试，如没有出现缺陷或意执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）评测通过以下公式计算：外结果的测试）评测通过以下公式计算： 成功的测试覆盖率成功的测试覆盖率= =T Ts s/ /RfT RfT % % 其中：其中：T T s s是用完全成功、没有缺陷的测试过程或是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数。测试用例表示的已执行测试需求数。RfTRfT是测试需是测试需求的总数。求的总数。 在执行测试过程中，经常使

29、用两个测试覆盖在执行测试过程中，经常使用两个测试覆盖度量指标，一个是确定已执行的测试覆盖率，另度量指标，一个是确定已执行的测试覆盖率，另一个是确定成功的测试覆盖率，即执行时未出现一个是确定成功的测试覆盖率，即执行时未出现失败的测试覆盖率。失败的测试覆盖率。 2 2）基于代码的测试覆盖）基于代码的测试覆盖 基于代码的测试覆盖评测是测试过程中已经执行的代码的基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少多少，与之相对应的是将要执行测试的剩余代码的多少。 许多测试专家认为，一个测试小组在测试工许多测试专家认为，一个测试小组在测试工作中所要做的最为重

30、要的事情之一就是度量代码作中所要做的最为重要的事情之一就是度量代码的覆盖情况。的覆盖情况。 基于代码的测试覆盖率通过以下公式计算：基于代码的测试覆盖率通过以下公式计算： 基于代码的测试覆盖率基于代码的测试覆盖率= =I Ie e / / TIicTIic% % 其中：其中：I Ie e是用代码语句、代码分支、代码路是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行径、数据状态判定点或数据元素名表示的已执行代码数。代码数。TIicTIic是代码的总数。是代码的总数。 很明显，在软件测试工作中，进行基于代码很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，

31、因为任何未的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。在一般经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级（例如情况下，代码覆盖运用于较低的测试等级（例如单元和集成级）时最为有效。单元和集成级）时最为有效。 但是，仅仅凭借执行了所有的代码，并不能但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能担保代码是按照码都在测试中得到执行，并不能担保代码是按照客户需求和设计的要求去做了。客户需求和设计的要求去做了。由于软件运行对资源的依赖，

32、也难以保证软件运行期的错误。8.2 质量评测质量评测 测试覆盖的评测提供了对测试完全程度的评测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。最佳的软件质量指标。 常用的测试有效性度量是围绕缺陷分析来构常用的测试有效性度量是围绕缺陷分析来构造的。缺陷分析就是分析缺陷在与缺陷相关联的造的。缺陷分析就是分析缺陷在与缺陷相关联的一个或者多个参数值上的分布。一个或者多个参数值上的分布。 缺陷分析提供了一个软件可靠性指标，这些缺陷分析提供了一个软件可靠性指标，这些分析为揭示软件可靠性的缺陷趋势或缺陷分布提分析为揭

33、示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。供了判断依据。 对于缺陷分析，常用的主要缺陷参数有以下对于缺陷分析，常用的主要缺陷参数有以下4 4个。个。 状态：缺陷的当前状态（打开的、正在修复的或状态：缺陷的当前状态（打开的、正在修复的或关闭的等）。关闭的等）。 优先级：表示修复缺陷的重要程度和应该何时修优先级：表示修复缺陷的重要程度和应该何时修复。复。 严重性：表示软件缺陷的恶劣程度，反映其对产严重性：表示软件缺陷的恶劣程度，反映其对产品和用户的影响等。品和用户的影响等。 起源：导致缺陷的原因及其位置，或排除该缺陷起源：导致缺陷的原因及其位置，或排除该缺陷需要修复的构件。需要修复的构件。

34、缺陷分析通常用以下缺陷分析通常用以下3 3类形式的度量提供缺陷评类形式的度量提供缺陷评测：测： 缺陷发现率；缺陷发现率； 缺陷潜伏期；缺陷潜伏期； 缺陷密度。缺陷密度。1 1缺陷发现率缺陷发现率 缺陷发现率是将发现的缺陷数量作为时间缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图，如图的函数来评测，即创建缺陷趋势图，如图5-75-7所示。所示。 2 2缺陷潜伏期缺陷潜伏期 测试有效性的另外一个有用的度量是缺陷潜测试有效性的另外一个有用的度量是缺陷潜伏期，通常也称为阶段潜伏期。缺陷潜伏期是一伏期，通常也称为阶段潜伏期。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，种

35、特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。表越大，修复这个缺陷所耗费的成本就越多。表5-15-1显示了一个项目的缺陷潜伏期的度量。显示了一个项目的缺陷潜伏期的度量。 表5-1 一个项目的缺陷潜伏期的度量 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行 产品 发布 产品 需求 0 1 2 3 4 5 6 7 8 9 总体设计 0 1 2 3 4 5 6 7 8 详细设计 0 1 2 3 4 5 6 7

36、编码 0 1 2 3 4 5 6 总计 表表5-25-2显示了一个项目的缺陷分布情况（按显示了一个项目的缺陷分布情况（按缺陷造成阶段和缺陷发现阶段）。缺陷造成阶段和缺陷发现阶段）。 表5-2 一个项目的缺陷分布情况 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行产品 发布 产品 缺陷总量 需求 0 8 4 1 0 0 5 6 2 1 27 总体设计 0 9 3 0 1 3 1 2 1 20 详细设计 0 15 3 4 0 0 1 8 31 编码 0 62 16 6 2 3 20 109 总计 0 8 13 19 65 2

37、1 14 9 8 30 187 按照缺陷产生阶段和缺陷发现阶段统计了一按照缺陷产生阶段和缺陷发现阶段统计了一个项目的缺陷分布情况后，根据软件开发生命周个项目的缺陷分布情况后，根据软件开发生命周期的各个阶段缺陷潜伏期度量的加权值，可以对期的各个阶段缺陷潜伏期度量的加权值，可以对缺陷的发现过程有效性和修复软件缺陷所耗费的缺陷的发现过程有效性和修复软件缺陷所耗费的成本等进行评测。这里采用了一个缺陷损耗的概成本等进行评测。这里采用了一个缺陷损耗的概念，缺陷损耗是使用阶段潜伏期和缺陷分布来度念，缺陷损耗是使用阶段潜伏期和缺陷分布来度量缺陷消除活动的有效性的一种度量。量缺陷消除活动的有效性的一种度量。 缺

38、陷消耗可使用下面公式计算：缺陷消耗可使用下面公式计算： 表表5-35-3显示了一个项目的各个缺陷损耗值，它们依据显示了一个项目的各个缺陷损耗值，它们依据的是经过缺陷潜伏期加权的已发现的缺陷数。的是经过缺陷潜伏期加权的已发现的缺陷数。 这样，在这样，在验收测试期间发现的需求缺陷的加权数值为验收测试期间发现的需求缺陷的加权数值为4242（即（即6 67=427=42）。）。缺陷总量值发现的阶段潜伏期加权缺陷数量缺陷消耗表5-3 一个项目的各个缺陷损耗值 发 现 阶 段 缺陷造成阶段 需求 总体 设计 详细 设计 编码 单元 测试 集成 测试 系统 测试 验收 测试 试运行产品 发布 产品 缺陷损耗

39、 需求 0 8 8 3 0 0 30 42 16 9 4.3 总体设计 0 9 6 0 4 15 6 14 8 2.1 详细设计 0 15 6 12 0 0 6 42 2.6 编码 0 62 32 18 8 15 120 2.7 总计 2.7 一般而言，缺陷损耗的数值越低，说明缺陷一般而言，缺陷损耗的数值越低，说明缺陷的发现过程越有效（最理想的数值应该为的发现过程越有效（最理想的数值应该为1 1）。作）。作为一个绝对值，缺陷损耗几乎没有任何意义，但为一个绝对值，缺陷损耗几乎没有任何意义，但是当用缺陷损耗来度量测试有效性的长期趋势时，是当用缺陷损耗来度量测试有效性的长期趋势时，它就会显示出自己的

40、价值。它就会显示出自己的价值。3 3缺陷密度缺陷密度 软件缺陷密度是一种以平均值估算法来计算出软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的：为单位的，软件缺陷密度是用下面公式计算的：代码行或功能点的数量软件缺陷数量软件缺陷密度 图图5-85-8显示了一个项目的各个模块中每千行代码的缺陷密度。显示了一个项目的各个模块中每千行代码的缺陷密度。 图5-8 各个模块中每千行代码的缺陷密度 但是，在实际评测中，缺陷密度这种度量方但是，在实际评测中，缺陷密度这种度量方法是极不完善的，度量

41、本身是不充分的。这里边法是极不完善的，度量本身是不充分的。这里边存在的主要问题是：所有的缺陷并不都是均等构存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度，及其对产品和造的。各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程用户的影响的严重程度，以及修复缺陷的重要程度有很大差别，有必要对缺陷进行度有很大差别，有必要对缺陷进行“分级、加权分级、加权”处理，给出软件缺陷在各严重性级别或优先级上处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，这样将使这种评测更加充的分布作为补充度量，这样将使这种评测更加充分，更有实际应用价值。分，更有实

42、际应用价值。 因为在测试工作中，大多数的缺陷都记录了因为在测试工作中，大多数的缺陷都记录了它的严重程度的等级和优先级，所以这个问题通它的严重程度的等级和优先级，所以这个问题通常都能够很好解决。例如，图常都能够很好解决。例如，图5-95-9所示的缺陷分所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布布图表示软件缺陷在各优先级上所应体现的分布方式。方式。 图5-9 各优先级上软件缺陷分布图 8.3 性能评测性能评测 主要的性能评测包括以下几点。主要的性能评测包括以下几点。 动态监测：在测试执行过程中，实时获取并显示正在动态监测：在测试执行过程中，实时获取并显示正在执行的各测试用例的状态。执行

43、的各测试用例的状态。 响应时间和吞吐量：测试对象针对特定测试用例的响响应时间和吞吐量：测试对象针对特定测试用例的响应时间或吞吐量的评测。应时间或吞吐量的评测。 百分比报告：数据已收集值的百分比计算与评测。百分比报告：数据已收集值的百分比计算与评测。 比较报告：代表不同测试执行情况的两个（或多个）比较报告：代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。数据集之间的差异或趋势。 追踪和配置文件报告：测试用例和测试对象之间的消追踪和配置文件报告：测试用例和测试对象之间的消息和会话详细信息。息和会话详细信息。 1 1动态监测动态监测 动态监测通常以柱状图或曲线图的形式提供动态监测通常以柱

44、状图或曲线图的形式提供实时显示实时显示/ /报告。该报告用于在测试执行过程中，报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试用例正在执行通过显示当前的情况、状态以及测试用例正在执行的进度来监测或评估性能测试执行情况。的进度来监测或评估性能测试执行情况。 例如，在图例如，在图5-105-10所示柱状图中所示柱状图中 。2 2响应时间和吞吐量响应时间和吞吐量 响应时间和吞吐量是评测并计算与时响应时间和吞吐量是评测并计算与时间和吞吐量相关的性能行为。这些报告通常间和吞吐量相关的性能行为。这些报告通常用曲线图显示，如图用曲线图显示，如图5-115-11所示。响应时间和所示。响应时间

45、和吞吐量在吞吐量在“y y”轴上，而事件数在轴上，而事件数在“x x”轴上。轴上。图图5-11 5-11 响应时间曲线响应时间曲线 3 3百分比报告百分比报告 百分比报告通过显示已收集数据类型百分比报告通过显示已收集数据类型的各种百分比值，提供了另一种性能统计计的各种百分比值，提供了另一种性能统计计算方法，如图算方法，如图5-125-12所示。所示。图图5-12 5-12 数据类型的各种百分比值数据类型的各种百分比值 4. 4. 比较报告比较报告 比较不同性能测试的结果，以评估测试执行比较不同性能测试的结果，以评估测试执行过程中所作的变更对性能行为的影响，这种做法过程中所作的变更对性能行为的影

46、响，这种做法是非常必要的。比较报告应该用于显示两个数据是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势。个测试执行之间的趋势。5. 5. 追踪和配置文件报告追踪和配置文件报告 当性能行为可以接受时，或性能监测表明存当性能行为可以接受时，或性能监测表明存在可能的瓶颈时（如当测试用例保持给定状态的在可能的瓶颈时（如当测试用例保持给定状态的时间过长），追踪报告可能是最有价值的报告。时间过长），追踪报告可能是最有价值的报告。追踪和配置文件报告显示低级信息。该信息包括追踪和配置文件报告显示低级信息。该信息包括主角与测试对象之间的消息、执行流、数据访问主角与测试对象之间的消息、执行流、数据访问以及函数和系统调用。以及函数和系统调用。Thank you!