软件测试-缺陷报告

缺陷报告的基本信息

上表中粗体部分就是缺陷报告的基本信息，即：缺陷标题、测试环境、复现步骤、实际结果、预期结果、注释。实际上，书写软件缺陷报告最容易出现问题的也是这些地方，为了重点突出，我们针对这几项“事故多发地带”先进行具体讲解。

缺陷标题（或者叫缺陷摘要，Summary）

标题应该提供缺陷的本质信息，简明扼要地说明即可，能让人一眼看明白缺陷发生的概要。良好的缺陷标题应该按照下列方式书写：

• 避免使用模糊不清的词语，例如“功能不正确”、“功能中断”等。应该使用具体文字说明功能如何不正确，如何中断。
• 标题要便于搜索和查询，可以在标题中使用关键字。
• 为了便于他人理解，标题要清晰、简洁，避免描述过于具体的测试细节。
• 尽量按照缺陷发生的原因与结果的方式书写。比如“执行完 A 后，发生 B”，或者“发生 B，当 A 执行完后”。

下表中列出了有一些有问题的缺陷报告标题，并给出了错误原因和改进的标题：

通过上述的几个例子，可见，使用“在……以后……”、“在……时候……”、“在……期间……”等连接词有助于描述缺陷的原因和结果，例如：

• 在数字字段栏中输入任意字母以后应用程序崩溃。
• 在关闭应用程序时发生内部错误。
• 发送电子邮件期间应用程序被暂停。

操作步骤（也叫复现步骤，Reproducible Steps）

复现步骤是指如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

但是实际软件测试过程中，总是存在一些不良的缺陷报告。

不良的缺陷报告主要表现在以下几个方面：

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

为了避免出现这些问题，良好的复现步骤应该包含本质的信息，并按照一定的方式书写。

良好的复现步骤书写方式：

• 提供测试的前提条件和测试环境。许多软件功能只是在特定条件下才会出现问题，所以在描述缺陷的时候一定不能忽视这些看似细节但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“网站在 IE7.0 和 IE8.0 的兼容问题”。
• 如果有多种方法触发该缺陷，请在步骤中包含这些方法。同样地，如果某些路径不触发该缺陷，也要在步骤中指明。
• 简单地一步一步地引导复现该缺陷。每一个步骤尽量只记录一个操作，而且在每个操作前使用数字进行编号。
• 尽量使用短语和短句，避免复杂句型和句式。
• 复现的操作步骤要完整、准确、简短。
• 只记录各个操作步骤是什么，不要包含每个操作步骤执行后的结果。
• 将常见的步骤合并为较少的步骤。

例如：

1.新建一个文本框；

2.添加文字。

可以简单的合并成一步：

1.新建一个文本框并添加文字。

需要引起注意的是，缺陷报告的读者可能对软件测试的细节所知有限，但对技术可能会有基本的了解。因此，一方面，我们没有必要在缺陷报告中描述“启动软件”或者“双击打开一个文件”等简单操作方法。另一方面，也不要包含软件测试过分详细的技术细节，除非这些是缺陷至关重要的信息。

预期结果（Expected Result）

预期结果是根据复现步骤，应该产生的正确结果，是需求规格说明书或客户希望得到的结果。为了更清楚地理解良好的预期结果的描述，请看下面的例子：

预期结果： 选中的文本应该高亮突出显示。如果用户想改变文本内容，必须选中内容高亮突出显示后才能操作。（在 Mac Os 10.x 和 Windows 操作系统中。）

这个例子很好，它包含了如下内容：

• 应该产生的正确现象：选中的文本应该高亮突出显示。
• 产生的原因：如果用户想改变文本内容，必须选中内容高亮突出显示后才能操作。
• 给出了具体的参考对象：Mac Os 10.x 和 Windows 操作系统中。

实际结果（Actual Result）

实际结果是执行软件的复现步骤后出现的实际现象。实际结果的描述应该与预期结果的描述方式相一致。实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。如果一个动作产生多个不同的缺陷结果，为了易于阅读，这些结果应该使用数字列表分割开来。例如：

实际结果：

1. 显示“命令代码行……错误”的提示；
2. 显示“并且终止……服务”。

有时，一个动作将产生一个结果，而这个结果又产生另一个结果。这种情况可能难以清晰、简洁的总结，可以把缺陷分解成多个缺陷报告，或者在实际结果部分，仅列出缺陷的一到两个表现特征，然后将随后的表现特征移到注释部分。因为重要的信息几乎总是包含在第一断言或错误描述里，其他的错误都是第一个错误的变种和后续现象。例如：

实际结果：

1. 显示“命令代码行……错误”的提示； 注释：
2. 当取消这个错误提示时，应用程序仍然运行，但是文本内容显示为乱码；
3. 在选择乱码的文本内容后，使用更新功能，文本内容恢复正常显示。

另外，在实际结果中，为了确保导致软件缺陷的全部细节是可见的，可以使用截图的方式；如果描述的是一个变化的流程缺陷的话，也可以使用 gif 动图；或者更直接地使用手机或电脑录制视频，这将给开发人员定位问题提供很大的帮助。

注释（Notes）

注释是对操作步骤和实际结果的补充，可以包括复现步骤中可能引起混乱的补充信息，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。注释部分可以包含以下各方面的内容：

• 截取缺陷特征图像文件（Screenshots）
• 测试过程需要使用的测试文件
• 测试附加的打印机驱动程序
• 缺陷出现过程中的日志文件
• 再次指明该缺陷是否在前一版本已经存在
• 多个平台之间是否具有不同表现
• 注释包含缺陷的隔离信息，指出缺陷的具体影响范围

除了“实际结果 2”中列出的注释的例子之外，请查看下面这几个注释的例子：

注释：

1. 能在 Windows 2000 和 Windows XP 文本框中显示文本内容，但不支持 Windows98；
2. 刷新屏幕后，某某现象会消失；
3. 使用二进制文件，不存在该错误；
4. 参见附加的使用说明书和测试文件。

以上五项是对缺陷报告的主体部分进行的解释说明，这部分的编写是考验测试人员的语言组织功底，希望能引起读者注意。

进入下一章节