软件质量管理 第六章

第六章软件缺陷跟踪管理目录1、软件缺陷的概念和种类2、正确面对软件缺陷3、软件缺陷的生命周期4、软件缺陷的严重性和优先级5、报告软件缺陷6、分离和再现软件缺陷7、测试总结报告8、测试的评测软件测试是在软件开发的过程中，对软件产品进行质量控制，目的是保证软件产品的最终质量。一般来说软件测试应严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试数据进行记录，并根据测试情况撰写测试报告。测试报告主要是报告发现的软件缺陷。测试评价主要包括覆盖评价以及质量和性能评价。覆盖评价是对测试完全程度的评测；质量和性能评价是对测试的软件对象的性能、稳定性以及可靠性的评测。1、软件缺陷的概念和种类软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷。软件未达到软件规格说明书中规定的功能；软件超出软件规格说明书中指明的范围；软件未达到软件规格说明书中指出的应达到的目标；软件运行出现错误；软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。在软件测试过程中如何判断软件缺陷，软件缺陷都有哪些种类？（1）功能不正常（2）软件在使用上不方便（3）软件的结构未做良好规划（4）功能不充分（5）与软件操作者的互动不良（6）使用性能不佳（7）未做好错误处理（8）边界错误（9）计算错误（10）使用一段时间所产生的错误（11）控制流程的错误（12）在大数据量压力之下所产生的错误（13）在不同硬件环境下产生的错误（14）版本控制不良所产生的错误（15）软件文档的错误2、正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭。测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复虽然软件测试人员需要对自己找出的软件缺陷保持一种平常心态，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。而缺陷是否需要修复的最终决定权在软件的项目负责人，但使得缺陷得以关闭的责任在测试人员。3、软件缺陷的生命周期软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段：（1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。（2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。（3）测试人员确认软件缺陷被修复，关闭软件缺陷。当软件缺陷首先被软件测试人员发现时。在许多情况下，软件缺陷生命周期的复杂程度仅为软件缺陷被打开、解决和关闭。然而，在有些情况下，生命周期变得更复杂一些，如图5-1所示。发现软件缺陷软件缺陷移交到项目管理员测试员找到并登记软件缺陷软件缺陷被移交到程序员程序员认为软件缺陷微不足道软件缺陷移交到测试员项目管理员认为软件缺陷不重要测试员不同意，找出通用失败案例软件缺陷移交到项目管理员软件缺陷移交到测试员软件缺陷移交到程序员测试员确认软件缺陷得以修复程序员修复软件缺陷测试员关闭软件缺陷项目管理员现在同意软件缺陷需要修复打开打开以不修复形式解决打开打开以修复形式解决关闭图5-1复杂的软件缺陷生命周期4、软件缺陷的严重性和优先级测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响；优先级表示修复缺陷的重要程度和应该何时修复。下面给出严重性和优先级的常用划分方法，将有助于测试人员更好地理解两者之间的差异。严重性级别：①致命错误，例如，导致系统崩溃、数据丢失、数据毁坏等；②一般性错误，例如，操作性错误、错误结果、遗漏功能等；③次要错误，例如，错别字、用户接口布局、罕见故障等。缺陷优先级：①最高优先级，指的是一些关键性错误，必须立即修复；②高优先级，在产品发布之前必须修复；③中优先级，如果时间允许应该修复；④低优先级，可能会修复，但是也能发布软件。5、报告软件缺陷报告软件缺陷的基本原则：在软件测试过程中，对于发现的大多数软件缺陷，要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。报告软件缺陷的基本原则如下：1．尽快报告软件缺陷2．有效地描述软件缺陷有效的软件缺陷描述要求如下：（1）简单与短小（2）明确指明错误类型（3）单一（4）使用IT业界惯用的表达术语和表达方法3．在报告软件缺陷时不做任何评价4．补充和完善软件缺陷报告以上概括了报告测试错误的规范要求，测试人员应该牢记上面这些关于报告软件缺陷的原则。这些原则几乎可以运用到任何交流活动中，尽管有时难以做到，然而，如果希望有效地报告软件缺陷，并使其得以修复，这些是测试人员要遵循的基本原则。随着软件的测试要求不同，测试者积累了相应的测试经验会，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。IEEE软件缺陷报告模板ANS/IEEE829—1998标准定义了一个称为软件缺陷报告的文档，用于报告“在测试期间发生的任何异常事件”。简言之，就是用于登记软件缺陷。模板标准如图5-3所示。图5-3IEEE软件缺陷报告模板IEEE829－1998软件测试文档编制标准软件缺陷报告模板目录1．软件缺陷报告标识符2．软件缺陷总结3．软件缺陷描述3.1输入3.2期望得到的结果3.3实际结果3.4异常情况3.5日期和时间3.6软件缺陷发生步骤3.7测试环境3.8再现测试3.9测试人员3.10见证人4．影响软件缺陷数据库跟踪系统至此，我们了解到软件缺陷报告过程是很复杂的，需要大量信息、详尽的细节和很好的组织工作，才能有所成效。在实际软件测试工作中，为了更高效地记录发现的软件缺陷，并在软件缺陷的整个生命周期中对其进行监控，常常运用软件缺陷跟踪系统。图5-4所示的是一个软件缺陷数据库跟踪系统。图软件缺陷数据库跟踪系统软件缺陷跟踪数据库最常用的功能，除了输入软件缺陷之外，就是通过执行查询来获得需要的软件缺陷清单。通过使用软件缺陷跟踪数据库，不但可以进行查询，还可以找出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复，能够提取各种实用和关心的数据，可以显示测试工作的成效和项目的进展情况。测试人员或者项目管理员可以看出数据中是否有趋势显示需要增加测试的区域，或者测试工作是否符合预先所制定的测试计划的进程等。手工报告和跟踪软件缺陷显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷数据库跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。图5-5所示的是根据ANS/IEEE829—1998标准设计的软件缺陷报告文档。图5-5软件缺陷报告文档6、分离和再现软件缺陷测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。分离和再现软件缺陷是考验软件测试人员专业技能的地方，测试人员应该设法找出缩小问题范围的具体步骤。对测试人员有利的情况是，若建立起绝对相同的输入条件时，软件缺陷就会再次出现，不存在随机的软件缺陷。如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷。实践证明这些方法对测试人员是有所帮助的。（1）不要想当然地接受任何假设（2）注意时间和运行条件上的因素（3）注意软件的边界条件、内存容量和数据溢出的问题（4）注意事件发生次序导致的软件缺陷（5）考虑资源依赖性和内存、网络、硬件共享的相互作用（6）不要忽视硬件7、测试总结报告测试总结报告的目的是总结测试活动的结果，并根据这些结果对测试进行评价。这种报告是测试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。在测试执行阶段的末期，应该为每个测试计划准备一份相应的测试总结报告。本质上讲，测试总结报告是测试计划的扩展，起着对测试计划“封闭回路”的作用。图5-6所示的是符合IEEE标准829—1998软件测试文档编制标准的测试总结报告模板。IEEE标准829－1998软件测试文档编制标准测试总结报告模板目录1．测试总结报告标识符2．总结3．差异4．综合评估5．结果总结5.1已解决的意外事件5.2未解决的意外事件6．评价7．建议8．活动总结9．审批图5-6测试总结报告模板8、测试的评测测试的评测主要方法包括覆盖评测和质量评测。测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。8.1覆盖评测覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。1）基于需求的测试覆盖基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。基于需求的测试覆盖率通过以下公式计算：测试覆盖率=T(p,i,x,s)/RfT%在制定测试计划活动中，将计算计划的测试覆盖，其计算方法如下：计划的测试覆盖率=Tp/RfT%其中：Tp是用测试过程或测试用例表示的计划测试需求数。Rf T是测试需求的总数。在实施测试过程中，计算测试覆盖时使用以下公式：已执行的测试覆盖率=Ti/RfT%其中：Ti是用测试过程或测试用例表示的已执行的测试需求数。RfT是测试需求的总数。在执行测试活动中，确定成功的测试覆盖率（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）评测通过以下公式计算：成功的测试覆盖率=Ts/RfT%其中：Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数。RfT是测试需求的总数。在执行测试过程中，经常使用两个测试覆盖度量指标，一个是确定已执行的测试覆盖率，另一个是确定成功的测试覆盖率，即执行时未出现失败的测试覆盖率。2）基于代码的测试覆盖基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少。许多测试专家认为，一个测试小组在测试工作中所要做的最为重要的事情之一就是度量代码的覆盖情况。基于代码的测试覆盖率通过以下公式计算：基于代码的测试覆盖率=Ie/TIic%其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic是代码的总数。很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级（例如单元和集成级）时最为有效。但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能担保代码是按照客户需求和设计的要求去做了。由于软件运行对资源的依赖，也难以保证软件运行期的错误。8.2质量评测测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。常用的测试有效性度量是围绕缺陷分析来构造的。缺陷分析就是分析缺陷在与缺陷相关联的一个或者多个参数值上的分布。缺陷分析提供了一个软件可靠性指标，这些分析为揭示软件可