软件测试的缺陷管理与分析，小白福利拿走不谢!

软件测试过程中提交缺陷是测试工程师最常做的一件事，也是开发工程师解决问题的依据，所以需要对缺陷进行管理和分析。缺陷管理主要是管理从提交缺陷到解决缺陷这一系列的过程，包括流程中角色的变换。

缺陷分析主要对测试过程中所发现的缺陷进行分类分析，分析缺陷分布的情况，并对缺陷产生的原因进行归纳分类，为改善研发和测试过程提供依据。本章节我们先讲解“缺陷管理与分析”的内容。

缺陷报告的发展：早期并没有缺陷的概念，直到第一台计算机诞生后才有人提出Bug一词。那时仅仅是将缺陷使用Bug这个词来描述，而并未真正对缺陷的产生进行详细的描述。1945 年美国的哈珀将军第一次通过报告的形式来描述缺陷。

Bug的由来

Bug一词的原意是“臭虫”或“虫子”，现在在软件测试过程中所有发现的问题，我们都喜欢使用“Bug”这个词来描述。

早期第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电子真空管发光，可能正是由于计算机运行产生的光和热，导致一只小虫子钻进了一支真空管内，使整个计算机无法工作。

研究人员花费很长时间才找到小虫子所在的真空管，将其取出后，计算机又恢复正常。后来“Bug”这个名词就沿用下来，表示计算机系统或程序中隐藏的错误、缺陷或问题。与Bug 相对应，人们将发现Bug 并加以纠正的过程称为“Debug”，即“捉虫子”或“杀虫子”。

遗憾的是，在中文中一直没有找到一个恰当的词来准确地翻译“Bug”的意思，因此就一直使用“Bug”一词来表示，所以测试中所有的问题我们都称之为“Bug”。

一份简单的缺陷报告

从计算机诞生之日起，就存在Bug。但早期并没有针对缺陷的相关报告，第一个使用缺陷报告的方式来记录Bug 的是美国海军编程员、编译器的发明者格蕾斯· 哈珀(Grace Hopper)。哈珀后来成为了美国海军的一个将军，领导了著名计算机语言Cobol 的开发。

1945年9月9日下午15点，哈珀中尉正带领着她的小组构造一个称为“马克二型”的计算机。

当时的计算机并不完全是电子计算机，还使用着大量的继电器。那时正处于第二次世界大战期间，哈珀的团队在一间第一次世界大战时建造的老建筑中工作，夏天很炎热又没有空调，所有的窗户都敞开散热，突然“马克二型”死机了，研究员想尽了办法，最后定位到第70 号继电器出现故障，仔细研究发现原来是一只飞蛾在继电器里面，当然飞蛾被继电器电死了，她小心地使用镊子将飞蛾取出来，并用透明胶布贴到记录本中，这是第一次对缺陷进行描述。

早期的缺陷报告描述是很简单的，只对缺陷的步骤进行描述，下面是一份简单的缺陷报告。

缺陷标题：Arial、Wingdings 和Symbol 字体会破坏新文件缺陷产生的步骤：

• (1)启动WordEdit 编辑器，然后创建新文件;
• (2)输入四行文本，如重复输入内容“The quick fox jumps over the lazy brown dog”;
• (3)选中所有四行文本，然后选择字体下拉菜单，并选择“Arial”字体。所有文本被转换成控制字符、数字和其他明显的随机二进制数据。

这是一份简单的缺陷报告，现在的缺陷报告所包含的元素已经丰富了很多。

一份好的缺陷报告

一份好的缺陷报告应该包含以下元素：缺陷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(一致)：按照一致的格式书写全部缺陷报告。

本章节关于“软件测试—缺陷管理与分析”的内容就学习到这里，大家觉得文章有用的话记得每天来这里和小编一起学习涨薪技能哦。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!

关注我的公众号：程序员小濠免费获取~

码字不易，文章对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。