如何编写高质量的缺陷报告

来源:互联网 发布:汽车模型设计软件 编辑:程序博客网 时间:2024/04/30 01:46
在书写软件缺陷报告之前,需要明白谁是缺陷报告的读者对象,知道读者最希望从缺陷报告中获得什么信息。通常,缺陷报告的直接读者是软件开发人员和质量管理人员,除此之外,来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外,他们不是软件测试人员,可能对于具体软件测试的细节了解不多。

  概括起来,缺陷报告的读者最希望获得的信息包括:

  • 易于搜索软件测试报告的缺陷;
  • 报告的软件缺陷进行了必要的隔离,报告的缺陷信息更具体、准确;
  • 软件开发人员希望获得缺陷的本质特征和复现步骤;
  • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。

  软件测试人员的任务之一就是需要针对读者的上述要求,书写良好的软件缺陷报告。

  1. 缺陷报告的写作准则

  书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。 它也减少了工程师以及其它质量保证人员的后续工作
    一个良好的缺陷报告应该有以下一个特征:  

   1、唯一性。一个bug说明一个问题,如果有能力的话,一个bug说明一类问题,这一类问题一定要能判断出是一条代码错误引起。

  2、可重现。提供这个bug的精确步骤,使开发人员容易看懂。

  3、一致性。bug描述及所有信息要前后一致,不可有歧义。

  4、完整性。最好能抓图,一目了然;测试环境和特定条件一定要描述清楚,许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。

  5、简洁性。通过使用关键词,可以使软件缺陷的标题描述短小简练,又能准确解释产生缺陷的现象。

  6、跟踪性。也许随着版本的变化,或者测试的深入,对bug有了新的认识或者新的判断,及时补充相关信息,能够提供给开发更有用的信息。

  7、客观性。软件缺陷描述不要带有个人观点,不要对开发人员进行评价,软件缺陷报告是针对产品的。

  2. 缺陷报告的组织结构

  尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同,但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成:

  • 缺陷的标题;
  • 缺陷的基本信息;
    • 测试的软件和硬件环境;
    • 测试的软件版本;
    • 缺陷的类型;
    • 缺陷的严重程度;
    • 缺陷的处理优先级。
  • 复现缺陷的操作步骤;
  • 缺陷的实际结果描述;
  • 期望的正确结果描述;
  • 注释文字和截取的缺陷图像。

  对于具体测试项目而言,缺陷的基本信息通常是比较固定的,也是很容易描述的。实际书写软件缺陷报告容易出现问题的地方就是标题、操作步骤、实际结果、期望结果和注释部分。

  2.1 标题

  标题应该保持简短、准确,提供缺陷的本质信息,便于开发人员通过标题了解bug发生的模块及大致情况,并且便于读者搜索查寻。

  良好的缺陷标题应该按照下列方式书写:

  • 尽量按缺陷发生的原因与结果的方式书写(“执行完A后,发生B,”或者“发生B,当A执行完后”);
  • 避免使用模糊不清的词语,例如“功能中断,功能不正确,行为不起作用,”等。应该使用具体文字说明功能如何中断,如何不正确,或如何不起作用;
  • 为了方便搜索和查询,请使用关键字;
  • 为了便于他人理解,避免使术语、俚语或过分具体的测试细节。

    2.2 复现步骤

   复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求,复现步骤的信息必须是完整的、准确的、简明的、可复现的。但是实际软件测试过程中,总是存在一些不良的缺陷报告,主要的问题在于以下三个方面:

  • 复现步骤包含了过多的多余步骤,而且句子结构混乱,可读性很差,难于理解;
  • 复现步骤包含了过少的信息,丢失操作的必要步骤。由于提供的步骤不完整,开发人员经常需要种种猜测,努力尝试复现的步骤,浪费了大量时间。由于缺少关键步骤,这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员;
  • 测试人员没有对软件缺陷发生的条件和影响区域进行隔离,软件开发人员无法判断该缺陷影响的软件部分,不能进行彻底修正。

为了避免出现这些问题,良好的复现步骤应该包含本质的信息,并按照下列方式书写:

  • 提供测试的预备步骤和信息;
    • 环境变量。例如,如果默认项或预设、调试版本或发布版本等存在问题,请指明使用的操作系统和应用程序的环境变量;
    • 设置变量:指明哪种打印机、字体或驱动程序是复现Bug所必需的信息;
    • 复现路径。如果有多种方法触发该缺陷,请在步骤中包含这些方法。同样地,如果某些路径不触发该缺陷,也要包含这些路径。
  • 简单地一步一步地引导复现该缺陷;
  • 每一个步骤尽量只记录一个操作;
  • 每一个步骤前使用数字对步骤编号;
  • 尽量使用短语和短句,避免复杂句型和句式;
  • 复现的操作步骤要完整,准确,简短;
  • 没有缺漏任何操作步骤;
  • 每个步骤都是准确无误的;
  • 没有任何多余的步骤;
  • 将常见步骤合并为较少步骤;
  • 只记录各个操作步骤是什么,不要包括每个操作步骤执行后的结果

    2.3 实际结果

   实际结果是执行复现步骤后软件的现象和产生的行为。

    实际结果的描述很像缺陷的标题,是标题信息的再次强调,要列出具体的表现行为,而不是简单的指出“不正确”或“不起作用”。

  • 尽可能将缺陷分解成多个缺陷报告,并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试,缩小产生缺陷的范围,查看是否产生多个缺陷;
  • 在实际结果部分,仅列出缺陷的一到两个表现特征。使用注释(Notes)部分列出缺陷的其它问题;
  • 在缺陷的第一个表现特征后,将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里,其它错误都是第一个错误的变种。

    2.4 期望结果

    期望结果的描述应该与实际结果的描述方式相同。通常需要列出期望结果的应该是什么,并且给出期望结果的原因,可能是引用的规格说明书、前一版本的表现行为、客户一般需求、排除杂乱信息的需要等等。

   2.5 注释

     注释应该包括复现步骤中可能引起混乱的补充信息,是对操作步骤的进一步描述,这些补充信息是复现缺陷或隔离缺陷的更详细的内容。

注释部分可以包含以下各方面的内容:

  • 截取缺陷特征图像文件(Screenshots);
  • 测试过程需要使用的测试文件;
  • 测试附加的打印机驱动程序;
  • 再次描述重点,避免开发人员将缺陷退回给测试人员补充更多信息;
  • 再次指明该缺陷是否在前一版本已经存在;
  • 多个平台之间是否具有不同表现;
  • 注释包含缺陷的隔离信息,指出缺陷的具体影响范围。
原创粉丝点击