8.3 缺陷报告

缺陷报告单是缺陷跟踪的交付物，也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

8.3.1 缺陷报告的属性

• 缺陷编号：类似于用例的编号编制规则。
• 缺陷标题：用一句话精准描述清楚问题。
• 缺陷所属模块：缺陷来源于被测软件的哪个模块。
• 缺陷种类：按照测试方法分类，例如功能缺陷，性能缺陷，界面缺陷等。
• 缺陷严重性：软件缺陷对软件质量的破坏程度。
• 缺陷优先级：处理和修正软件缺陷的先后顺序。
• 缺陷状态：缺陷在生命周期中所处的状态。
• 缺陷描述：描述问题的基本环境，使用最少步骤去重现测试工程师的操作步骤和使用的数据。
• 可再现性：缺陷能否再现，或者如果是随机缺陷，要给出缺陷出现的概率。
• 缺陷发现人：缺陷的发现人。
• 缺陷发现时间：缺陷的发现时间。
• 缺陷发现阶段：缺陷发现的阶段，即单元测试阶段，集成测试阶段，系统测试阶段等。
• 缺陷所属版本：缺陷发现的软件版本。
• 缺陷引入阶段：缺陷可能在哪个阶段引入的。
• 缺陷引入原因：缺陷可能的引发原因。
• 附件：其他有利于完善缺陷报告的文件，例如缺陷发生时的截图，系统的日志文件等。

8.3.2 严重性和优先级

严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布。

严重性（Severity）顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷严重性的判断应该从软件最终用户的观点出发，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成后果的严重性。

• 致命：软件的意外退出甚至操作系统崩溃，造成数据丢失。

• 严重：由于单功能失效导致多个相关功能均失效。

• 一般：软件的单个功能失效；

• 提示：软件界面的细微缺陷，某个控件没有对齐，某个标点符号丢失等。

优先级（priority）是表示处理和修正软件缺陷先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。 优先级由开发工程师确定，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件质量造成的危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

8.3.3 有效记录缺陷

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。

缺陷报告的基本准则：

• 准确：每个组成部分的描述准确，不会引起误解。
• 清晰：每个组成部分的描述清晰，易于理解。
• 简洁：只包含必不可少的信息，不包括任何多余的内容。
• 完整：包含复现该缺陷的完整步骤和其他本质信息。
• 一致：按照一致的格式书写全部缺陷报告。

软件缺陷的有效描述规则：

1.保证重现缺陷

缺陷报告的作用就是为了让软件开发人员能够及时准确地了解软件存在的缺陷，它是测试人员和开发人员沟通的重要手段。因此必须保证软件缺陷报告能够清晰描述缺陷，保证开发人员可以根据缺陷报告描述步骤的引导百分之百地重现缺陷。

2.分析故障，使用最少步骤重现缺陷

用过于复杂的步骤描述软件缺陷会降低软件缺陷被修复的可能性。一方面，复杂的重现步骤和大量的文字可能没有真正提炼出重现缺陷的关键，但是却占用开发人员很多宝贵的时间，久而久之会引起阅读者反感，从而降低提交这类缺陷报告人员的受信度；另一方面，如果重现缺陷的过程过于复杂，则会给开发人员重现缺陷带来很大的困难，同时这一缺陷的严重程度也会大打折扣。

3.包含所有重现缺陷的必要步骤

之所以要求缺陷报告必须包含所有重现缺陷的必要步骤，是因为重现缺陷是缺陷报告最基本的功能需要。

4.方便阅读

分步骤描述重现缺陷的步骤，要对操作过程进行编号，在书写格式上要求每一个步骤独占一行。在报告软件缺陷时不做评价，既然是软件缺陷报告，就应该正对的是产品。报告的标题部分要简洁明了，并且能够突出报告的主要内容。

5.尽量简单，一个缺陷一个报告

缺陷报告应尽可能的简单；不要在一个报告中合并多个缺陷。当缺陷报告中包含一个以上的缺陷时，通常只有第一个缺陷最会引起注意和修复，而其他软件缺陷则会被忘记或者忽视。并且修了其中一个缺陷而其他的未修复，此时缺陷报告的状态都无法合适的设置。

6.注意自己的语气

缺陷报告中带有责备或居高临下的语气是百害而无一利的，测试本来就是一个需要充分交流和沟通的工作，由此带来的不愉快就会引发对立。所以，在写报告的时候要严格的遵守一个原则，即对事不对人，特别要注意报告使用的语气，不要把情绪带到缺陷报告当中去。

7.其他良好经验

永远都要报告不可重现的错误。
永远不要假设明显的软件缺陷已经被报告。
不要夸大缺陷。
报告小缺陷。
及时报告缺陷。
引用他人的报告要小心。可以补充评论，但不能编辑他人的材料。任何在缺陷报告，特别是其他人的报告中做补充的时候，都要注明自己的姓名和日期。
通过空行提高报告的可读性。
使用简短的句子。
说明预期结果和实际结果。
如果认为程序员可能会忽视这一缺陷，则可在报告中详细解释认为严重的原因。
适当添加有益的注释，以便于程序员分析问题及自己今后的返测。
对于复杂的缺陷，可以在报告开头对这一缺陷进行小结，然后给出操作细节。

8.3.4 缺陷报告的处理流程

缺陷报告从提交开始，一直到处理结束被关闭，中间会经历各种处理方法和状态，这称为缺陷的生命周期。

缺陷报告首先由测试人员提交，经过确认之后，将由开发或者测试负责人进行分配，根据缺陷所属的模块分配到模块的开发者；然后开发人员对缺陷进行处理；如果修复了代码解决了问题，则反馈给测试人员，测试人员在下一个版本中进行返测，如果验证缺陷已经修复，则关闭缺陷报告；如果缺陷没有修复则返回给开发人员继续处理。

除了基本的由开发人员修复代码解决问题之外，也可能有如下几种处理方法：

• 推迟修改：由于现有的技术，时间和需求等限制，暂时不修改此缺陷。
• 拒绝修改：对于新提交的缺陷，开发人员认为不是程序问题，或者需求本来就是这样的结果，可以拒绝缺陷。
• 重复缺陷：对于新提交的缺陷，发现与已经提交的缺陷重复，需要标注与哪个缺陷重复，然后关闭。

同时已经关闭的缺陷也可能在后续的版本中，通过回归测试再次出现。