一份好的缺陷报告应该包含以下元素:缺陷 ID 号、严重等级、归属版本、归属模块、简要描 述、详细描述、附件、提交日期、提交人、当前状态、当前负责人和当前测试环境。 (1)缺陷 ID 号。缺陷 ID 号即提交 Bug 的 ID 号。一般情况下,当我们在缺陷管理系统中提 交 Bug 时,缺陷管理系统会自动生成一个 ID 号,并不需要人为的定义,当然不同的缺陷管理系统生成缺陷 ID 号的方式有所不同。 (2)严重等级。缺陷严重等级是缺陷报告中最重要的属性之一,缺陷的严重等级分为:致命、 严重、一般和建议四类,衡量缺陷的严重等级必须考虑两个维度:该功能在客户端使用的频率和缺 陷带来的影响详见 7.3.1 小节。 (3)归属版本。归属版本是指当前测试的版本,即发现该 Bug 所测试的系统版本。 (4)归属模块。归属模块是指测试哪个模块发现 Bug 的,即该 Bug 是由哪个模块引起的。 (5)简要描述。简要描述即使用一句话简要地概述该 Bug 的内容,简要描述要简单明了,最 好是一看便知道其含义,一般不超过 15 个字。 (6)详细描述。详细描述是 Bug 报告中的核心内容之一,需要通过详细的步骤来介绍发现 Bug 的过程,一般分步骤地描述,这样让读 Bug 的人更轻松、更省时且易理解。对于一些建议的 问题,在详细描述里面还应该写明建议将功能修改成什么样。 (7)附件。附件是用来辅助描述 Bug 的内容,一般包括以下几种形式:图片、日志文件、配 置文件等。对于一些操作步骤或 Bug 的结果,如果不能很准确地描述,应该借助图片来帮助描述, 图片可以让开发工程师很简单地了解 Bug 的步骤和结果;日志文件主要是将出现 Bug 时的日志文 件附带给开发工程师,这样便于分析 Bug 出现的原因;相关配置文件主要是在出现 Bug 时,将系 统的相关配置文件附带给开发工程师,便于分析 Bug 出现的原因。 (8)提交日期。提交日期是指提交 Bug 时的日期,一般情况下缺陷管理工具会自动生成。 (9)提交人。提交人是指提交该 Bug 的测试工程师。 (10)当前状态。当前状态是指 Bug 当前的状态,Bug 状态在 7.3.4 节有详细的介绍,每到一 个步骤 Bug 都有一个对应的状态,而这个状态一定要更新正确。 (11)当前负责人。当前负责人是指该 Bug 由哪些开发工程师负责修复。 (12)当前测试环境。当前测试环境是指发现该 Bug 时所处的环境,测试环境主要包括使用 的浏览器、分辨率、操作系统和相关硬件信息。
1)浏览器是指当前测试使用的是哪个厂家的浏览器及相关的版本,主要用于分析一些浏览器 兼容的问题。 2)分辨率是指当前测试时系统的分辨率。主要用于分析一些关于界面显示的问题。 3)操作系统是指当前测试时的操作系统,应该介绍是什么操作系统以及是 32 位还是 64 位。 4)相关硬件信息更多的是用于嵌入式系统的描述上,在纯软件的系统中一般不需要描述此项 内容,对于嵌入式的测试应该描述清楚主板、电源板、接口板等其他硬件的版本信息。 缺陷报告应该遵循以下几个原则: Correct(准确):每个组成部分的描述应该准确无误,不会引起误解。 Clear(清晰):每个组成部分的描述应该清晰,易于理解。 Concise(简洁):只包含必不可少的信息,不包括任何冗余的内容。 Complete(完整):包含修改该缺陷的完整步骤和其他本质信息。 Consistent(一致):按照一致的格式书写全部缺陷报告。