搜索
第5章软件缺陷管理与测试报告5.1软件缺陷的概念和种类5.2正确面对软件缺陷5.3软件缺陷的生命周期5.4软件缺陷的严重性和优先级5.5报告软件缺陷5.6分离和再现软件缺陷5.7测试总结报告5.8测试的评测软件测试是在软件开发的过程中，对软件产品进行质量控制，目的是保证软件产品的最终质量。一般来说软件测试应严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试数据进行记录，并根据测试情况撰写测试报告。测试报告主要是报告发现的软件缺陷。测试评价主要包括覆盖评价以及质量和性能评价。覆盖评价是对测试完全程度的评测；质量和性能评价是对测试的软件对象的性能、稳定性以及可靠性的评测。5.1软件缺陷的概念和种类软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷。软件未达到软件规格说明书中规定的功能；软件超出软件规格说明书中指明的范围；软件未达到软件规格说明书中指出的应达到的目标；软件运行出现错误；软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。在软件测试过程中如何判断软件缺陷，软件缺陷都有哪些种类？（1）功能不正常（2）软件在使用上不方便（3）软件的结构未做良好规划（4）功能不充分（5）与软件操作者的互动不良（6）使用性能不佳（7）未做好错误处理（8）边界错误（9）计算错误（10）使用一段时间所产生的错误（11）控制流程的错误（12）在大数据量压力之下所产生的错误（13）在不同硬件环境下产生的错误（14）版本控制不良所产生的错误（15）软件文档的错误5.2正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭。测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复虽然软件测试人员需要对自己找出的软件缺陷保持一种平常心态，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。而缺陷是否需要修复的最终决定权在软件的项目负责人，但使得缺陷得以关闭的责任在测试人员。5.3软件缺陷的生命周期软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段：（1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。（2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。（3）测试人员确认软件缺陷被修复，关闭软件缺陷。在许多情况下，软件缺陷生命周期的复杂程度仅为软件缺陷被打开、解决和关闭。然而，在有些情况下，生命周期变得更复杂一些，如图5-1所示。发现软件缺陷软件缺陷移交到项目管理员测试员找到并登记软件缺陷软件缺陷被移交到程序员程序员认为软件缺陷微不足道软件缺陷移交到测试员项目管理员认为软件缺陷不重要测试员不同意，找出通用失败案例软件缺陷移交到项目管理员软件缺陷移交到测试员软件缺陷移交到程序员测试员确认软件缺陷得以修复程序员修复软件缺陷测试员关闭软件缺陷项目管理员现在同意软件缺陷需要修复打开打开以不修复形式解决打开打开以修复形式解决关闭图5-1复杂的软件缺陷生命周期缺陷状态的描述（Status）1.已提交（Submitted）已提交的缺陷2.打开（Open）确认“提交的缺陷”，等待处理3.已拒绝（Rejected）拒绝“提交的缺陷”，不需要修复或不是缺陷4.已解决（Resolved）缺陷被修复5.已关闭（Closed）确认被修复的缺陷，将其关闭6.重新提交（ReSubmitted）已被拒绝的缺陷重新提交Bug跟踪系统工作流程图Bug提交者负责人研发人员提交bug报告(Unconfirmed)分配bug报告(Assigned)修改完毕(Resloved)返测完毕(Verified)归档(Closed)移除（Moved）问题未解决(Reopened)数据库测试人员技术支持其他客服经理测试主管修改完毕(Fixed)不是问题(Navlid)不修改(Wontfix)以后解决(Later)保留(Remind)不重现(Workforme)再分配(Reassign)重复提交(Duplicat)市场开发与测试管理5.4软件缺陷的严重性和优先级测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响；优先级表示修复缺陷的重要程度和应该何时修复。下面给出严重性和优先级的常用划分方法，将有助于测试人员更好地理解两者之间的差异。5.4.1缺陷严重程度#缺陷严重等级描述1严重缺陷（Critical）不能执行正常工作功能或重要功能。或者危及人身安全2较大缺陷（Major）严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）3较小缺陷（Minor）严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）4轻微缺陷（Cosmetic）使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。5其他缺陷（Other）其它错误也有的公司分别称之为A/B/C/D/E类错误。5.4.2解决优先级（Priority）#解决优先级描述1立即解决（ResolveImmediately）缺陷必须被立即解决。2正常排队（NormalQueue）缺陷需要正常排队等待修复或列入软件发布清单。3不紧急（NotUrgent）缺陷可以在方便时被纠正。5.5报告软件缺陷5.5.1报告软件缺陷的基本原则在软件测试过程中，对于发现的大多数软件缺陷，要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。报告软件缺陷的基本原则如下。1．尽快报告软件缺陷2．有效地描述软件缺陷有效的软件缺陷描述要求如下。（1）简单与短小（2）明确指明错误类型（3）单一（4）使用IT业界惯用的表达术语和表达方法3．在报告软件缺陷时不做任何评价4．补充和完善软件缺陷报告以上概括了报告测试错误的规范要求，测试人员应该牢记上面这些关于报告软件缺陷的原则。这些原则几乎可以运用到任何交流活动中，尽管有时难以做到，然而，如果希望有效地报告软件缺陷，并使其得以修复，这些是测试人员要遵循的基本原则。随着软件的测试要求不同，测试者积累了相应的测试经验会，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。5.5.2IEEE软件缺陷报告模板ANS/IEEE829—1998标准定义了一个称为软件缺陷报告的文档，用于报告“在测试期间发生的任何异常事件”。简言之，就是用于登记软件缺陷。模板标准如图5-3所示。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-3IEEE软件缺陷报告模板5.5.3软件缺陷数据库跟踪系统至此，我们了解到软件缺陷报告过程是很复杂的，需要大量信息、详尽的细节和很好的组织工作，才能有所成效。在实际软件测试工作中，为了更高效地记录发现的软件缺陷，并在软件缺陷的整个生命周期中对其进行监控，常常运用软件缺陷跟踪系统。图5-4所示的是一个软件缺陷数据库跟踪系统。图5-4软件缺陷数据库跟踪系统软件缺陷跟踪数据库最常用的功能，除了输入软件缺陷之外，就是通过执行查询来获得需要的软件缺陷清单。通过使用软件缺陷跟踪数据库，不但可以进行查询，还可以找出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复，能够提取各种实用和关心的数据，可以显示测试工作的成效和项目的进展情况。测试人员或者项目管理员可以看出数据中是否有趋势显示需要增加测试的区域，或者测试工作是否符合预先所制定的测试计划的进程等。缺陷管理工具常用的缺陷管理工具有下列几种：1.可以采用TD作为缺陷管理工具。2.可以采用RationalClearQuest作为缺陷管理的工具。3.可以采用BUGZILLA作为缺陷管理工具。5.5.4手工报告和跟踪软件缺陷显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷数据库跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。图5-5所示的是根据ANS/IEEE829—1998标准设计的软件缺陷报告文档。图5-5软件缺陷报告文档5.6分离和再现软件缺陷测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。分离和再现软件缺陷是考验软件测试人员专业技能的地方，测试人员应该设法找出缩小问题范围的具体步骤。对测试人员有利的情况是，若建立起绝对相同的输入条件时，软件缺陷就会再次出现，不存在随机的软件缺陷。如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷。实践证明这些方法对测试人员是有所帮助的。（1）不要想当然地接受任何假设（2）注意时间和运行条件上的因素（3）注意软件的边界条件、内存容量和数据溢出的问题（4）注意事件发生次序导致的软件缺陷（5）考虑资源依赖性和内存、网络、硬件共享的相互作用（6）不要忽视硬件5.7测试总结报告测试总结报告的目的是总结测试活动的结果，并根据这些结果对测试进行评价。这种报告是测试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。在测试执行阶段的末期，应该为每个测试计划准备一份相应的测试总结报告。本质上讲，测试总结报告是测试计划的扩展，起着对测试计划“封闭回路”的作用。图5-6所示的是符合IEEE标准829—1998软件测试文档编制标准的测试总结报告模板。IEEE标准829－1998软件测试文档编制标准测试总结报告模板目录1．测试总结报告标识符2．总结3．差异4．综合评估5．结果总结5.1已解决的意外事件5.2未解决的意外事件6．评价7．建议8．活动总结9．审批图5-6测试总结报告模板5.8测试的评测测试的评测主要方法包括覆盖评测和质量评测。测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。5.8.1覆盖评测覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。1．基于需求的测试覆盖基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。基于需求的测试覆盖率通过以下公式计算：测试覆盖率=T(p,i,x,s)/RfT%在制定测试计划活动中，将计算计划的测试覆盖，其计算方法如下：计划的测试覆盖率=Tp/RfT%其中：Tp是用测试过程或测试用例表示的计划测试需求数。Rf T是测试需求的总数。在实施测试过程中，计算测试覆盖时使用以下公式：已执行的测试覆盖率=Ti/RfT%其中：Ti是用测试过程