软件测试的缺陷管理与分析，粉丝福利拿走不谢

本文链接：https://blog.csdn.net/myh919/article/details/120270067

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

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

缺陷报告的发展：早期并没有缺陷的概念，直到第一台计算机诞生后才有人提出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)提交日期