软件测试—缺陷管理与分析

　　软件测试过程中提交缺陷是测试工程师最常做的一件事，也是开发工程师解决问题的依据，所以需要对缺陷进行管理和分析。缺陷管理主要是管理从提交缺陷到解决缺陷这一系列的过程，包括流程中角色的变换。缺陷分析主要对测试过程中所发现的缺陷进行分类分析，分析缺陷分布的情况，并对缺陷产生的原因进行归纳分类，为改善研发和测试过程提供依据。本章节我们先讲解“缺陷管理与分析”的内容。

　　缺陷报告的发展：早期并没有缺陷的概念，直到第一台计算机诞生后才有人提出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)相关硬件信息更多的是用于嵌入式系统的描述上，在纯软件的系统中一般不需要描述此项内容，对于嵌入式的测试应该描述清楚主板、电源板、接口板等其他硬件的版本信息。

　　缺陷报告应该遵循以下几个原则：

1. 　　Correct(准确)：每个组成部分的描述应该准确无误，不会引起误解。

2. 　　Clear(清晰)：每个组成部分的描述应该清晰，易于理解。

3. 　　Concise(简洁)：只包含必不可少的信息，不包括任何冗余的内容。

4. 　　Complete(完整)：包含修改该缺陷的完整步骤和其他本质信息。

5. 　　Consistent(一致)：按照一致的格式书写全部缺陷报告。

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