软件缺陷报告

知识点

• 软件缺陷的定义
• 缺陷产生的原因
• 如何编写缺陷报告
• 缺陷报告的书写准则

简介

软件测试的目的是为了发现尽可能多的缺陷，这里的缺陷是一种泛称，他可以指功能的错误，也可以指性能低下，或者易用性差等。执行软件测试这个环节，软件测试人员的主要工作就是通过测试去发现并提交软件缺陷，然后开发人员对提交的软件缺陷进行修改。这个环节是测试人员和开发人员工作频繁交互的阶段，也是最容易产生抱怨和争议的阶段。而且据统计，对于绝大多数的软件产品而言，用于测试和改错的时间占整个软件开发周期的30%左右，所以我们必须把测试的执行工作做好，不然不仅没有功劳，也没人欣赏你的苦劳，你拥有最多的是疲劳。

发现并提交软件缺陷是软件测试执行工作最为重要的内容之一。下面主要介绍软件缺陷报告的定义、缺陷产生的原因以及如何识别软件缺陷，还将进一步详细讲述如何编写一个良好的缺陷报告。

软件缺陷概念

先引用《编程之道》中的一个小故事，编程大师说“任何一个程序，无论他多么小，总存在着错误。”初学者不相信大师的话，他问：如果有小程序小的只执行一个简单的功能，那会怎样呢？这样的程序没有意义，大师说，但如果这样的程序存在的话，操作系统最后将失效，产生错误。但初学者不满足，他问：如果操作系统不失效，那会怎么样呢？

大师说：如果这样的操作系统存在的话，硬件最后将会失效，产生错误。

初学者人不满足，再问：如果硬件也不失效，那会怎样呢？大师长叹一声道：没有不失效的硬件，但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是错误的。

这个故事说明了，没有错误的程序世间难求。在实际工作中，我们经常听到来自测试人员和开发人员的抱怨：测试人员抱怨最多的就是软件缺陷怎么那么多，开发的什么东西，简直难以忍受。开发人员则抱怨这不是缺陷，这个缺陷没有，因为我的系统运行正常。他们相互抱怨的场景屡见不鲜。

软件的缺陷无疑是开发人员写出来的，因为测试人员没有写过一行代码，开发人员才是缺陷的创造者。但测试人员是“缺陷的缺陷“的创造者，所谓的”缺陷的缺陷“是指提交的缺陷并不是真正的缺陷，而是在没有正确理解需求从而进行了不合理的提交产生的，这种缺陷经常是测试人员受到职责的重要原因，为了避免这种情况的出现，读者首先要弄清楚到底什么是缺陷。

缺陷的定义

在日常口语中，常常听到大家把缺陷叫做“Bug”，这起源于第一代计算机时期的一个小故事。第一代计算机由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可是有一天这个庞大的计算机却突然无法工作了，研究人员做了很多调试都无法使设备恢复正常，费了九牛二虎之力之后，他们最终在一只真空管中发现了一只小虫子，显然是小虫子受光电的吸引而被夹扁在触点之间，他们把小虫子从真空管中取出，设备才得以正常工作。其中一位名叫格蕾丝.赫柏的人把飞蛾拍死在工作日志上，写到：就是这个 Bug，害我们今天的工作无法完成。小虫子的英文就是 Bug，所以就用 Bug 一词代表电脑系统或程序中隐藏的错误、缺陷或问题，并一直沿用到现在。

我们常把所有的软件问题都称为缺陷，笼统地定义为电脑系统或程序中隐藏的错误、缺陷或问题，这听起来也许非常简单，但并不能真正指导测试人员提交缺陷的报告。缺陷这个词必须加以详细定义，才有利于缺陷的识别。一般的，符合下面5个规则之一的才能叫做软件缺陷。

• 软件未达到产品说明书标明的功能
• 软件出现了产品说明书指明不会出现的错误
• 软件功能超出了软件产品说明书说明的范围
• 软件未达到产品说明书虽未指出但因达到的目标
• 软件测试人员认为软件难以理解、不宜使用、运行速度缓慢、或者最终用户认为不好

为了更好的理解以上每一条规则，我们以word程序作为例子来具体了解这几条规则。

word程序的产品说明书声称它能够准确无误的进行文字的显示和保存。假如你作为软件测试人员，拿到word程序后，从键盘输入文字，在硬件连接完好的情况下，word页面中什么文字内容也没显示，根据第一条规则，这是一个缺陷。加入可以正确显示，但却无法保存，根据第一条规则，这也是一个缺陷。

word程序的产品说明书中可能声称他可以保存无数个字符且不会崩溃，假如你疯狂复制粘贴文字内容到word文档中，结果却导致程序没有响应，根据第二条规则，这是一个缺陷。

假如你拿到的word文档不仅可以显示文字和保存文字，还拥有录音功能，而产品说明书并没有提到这一功能，意气风发的程序员只因为觉得这是一项了不起的功能而把它加入，那么根据第三条规则，这是一个软件缺陷。

再或者，使用word程序录入文字时按enter回车键可以起到换行作用，虽然产品说明书中并未指明这一点，，但如果程序没有达到这个要求，根据第四条规则，这也是一个软件缺陷。

关于第五条规则是主观的。这一点也是开发人员和测试人员容易发生争议的地方.或许开发人员会说，你一个测试人员，你说是缺陷就是缺陷吗？需求你来定吗？他们产生这样的疑问一点也不奇怪，毕竟对于软件好不好用

这样主观性的意见，千人千面， 各有不同。但软件测试人员是第一个真正使用软件的人，如果他们觉得不对劲，那么一定是有改进余地的。这部分的缺陷通常发现在易用性方面，这一点笔者会在《易用性测试》中详细阐述，为了减少争议的发生，要求测试人员提出的建议一定要客观且全面。当争议发生时，测试人员也可以去跟PM沟通，得到确认之后，再由开发人员进行修改。当然也并非发现所有缺陷开发人员都会进行修改，这一点我们在软件测试的原则中就有讲到。

对照以上5个定义，会让你在识别软件缺陷时有法可依。

当然，也存在一些看似是缺陷，但其实并不是缺陷的现象

比如当输入3次错误的密码后，提款机的吞卡行为，这是对用户银行卡安全的一种保护措施。但如果程序没有“输错3次密码，ATM机会吞卡”这样的提示，那么这里也算是一个缺陷。

也有现象看似正确但其实却是缺陷。

比如计算机成功安装了某个软件，该软件的功能可以正确执行，但他却破坏了操作系统的功能或者其他软件的使用。这也是一种缺陷，属于兼容性缺陷

更神奇的是，还有一些现象在不同的环境和系统中，可能是缺陷，也可能不是。

比如民用产品和军用产品对软件的精度要求就是不同的，在系统易用性方面，普通用户与专业用户对产品的要求也会存在很大的差异。

所以是否是缺陷，除了参考以上五个规则之外，还有看使用对象和使用环境，这就要求测试人员除了专业的测试知识外，还要具备一些行业知识，在本书最后一个章节我们会讲述软件测试人员所需要的知识和技能。

缺陷产生的原因

在软件开发的过程中软件缺陷的产生是不可避免的，那么软件缺陷是如何产生的？产生的缺陷的根源有很多，人本身容易犯错误，时间的压力、复杂的代码，复杂的系统架构、技术的革新以及许多系统之间的交互接口等都可能导致产生缺陷。

缺陷来源也各种各样，通过对众多从大到小的项目进行研究，我们得出了一个惊人的结论：大多数软件缺陷并非源自程序错误，而是产品说明书

上图是一个调查结果统计图，可以看出：

软件缺陷的第一大来源是产品说明书

软件需求规格说明书描述了系统应该具有哪些功能，不应该具有哪些功能，功能的操作性如何，性能如何等等具体规格，是开发初期最重要的过程文档，也是后期开发与测试的重要依据。但是在许多情况下，项目根本没有需求说明书，项目负责人仅仅再跟客户沟通之后，通过一些邮件、会谈纪录或一些零碎的未整理的话，就确信大家已经完全理解了客户的需求了。却并未形成正规的文档，这肯定会产生大量的缺陷；也可能是说明书虽然有，但是描述不清晰导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷；或者需求频繁变更，却与开发人员缺少及时沟通，导致开发人员不清楚应该做什么和不做什么的理解误差造成的

缺陷的第二来源是设计

设计是程序员规划软件的过程，就像盖房子打地基打框架一样，系统结构越来越复杂，而程序员可能限于自身的思维局限或技术局限，无法设计出一个很好地层次结构或组件结构，导致概要设计、详细设计、数据库设计文档等存在错误或不清晰，结果出现意想不到的问题或系统维护、扩充上的困难。为软件做设计是极其重要的，需要功底深厚的架构人员去做，如果底层架构出错了，软件缺陷就会大片地出现，而且该动起来尤为复杂，牵一发而动全身

第三来源才是程序代码

任何人在编程时都可能疏忽犯错，导致程序中有缺陷。除此之外，也有可能是因为如案件太过复杂，技术文档又普遍比较糟糕，文档本身就有缺陷，导致根据文档编写的代码产生更多的缺陷，另外人们也常处于进度的压力之下，匆忙之下也容易产生缺陷，实际上也是由于产品说明书或设计方案造成的,例如需求变更了却没人及时通知那个可怜的开发人员。

第四来源是其他的一些原因

比如硬件或软件存在错误，或者把误解当成了缺陷；还有些缺陷反复多处出现，实际上是由同一个原因引起的。这种缺陷越少越好，测试工程师本身就是做质量工作的，提交的成果本身就应该质量高一些才对。当然事实上这部分缺陷只占极小的比例，不需要太过担心。

正确理解缺陷的含义，并了解产生原因的原因，可以帮助测试人员是别缺陷。软件缺陷绝大部分来自软件需求说明书，所以测试人员一定要尽早介入到软件项目中，而不能进行主要是针对程序代码的测试！

用户的需求是判断缺陷的关键，因此在识别缺陷的过程中，测试人员可以从以下几个方面入手。

• 首先，可以把参考文档作为识别和判断缺陷的辅助工具。如软件需求说明书、设计文档、用户手册及联机帮助等，这些文档反映了大量的用户需求，所以大多数测试人员在实际测试过程中广泛的使用。
• 其次，通过对软件产品的行业知识和行业标准的了解来发现被隐藏的问题，这些问题中往往隐藏着致命缺陷。
• 最后，通过沟通的方式来收集、学习和分享其他人判断缺陷的方法和经验，沟通对象比如项目经理、测试组和其他成员、客户、开发人员等

某些人天生就适合做软件测试，他们找到软件缺陷，可以准确地找出其发生的具体步骤和条件，对于其他人而言，这种技巧要经过多次实践之后才能获得，拥有这种能力是称为卓有成效的软件测试人员的前提。

编写软件缺陷报告

识别出缺陷，就需要编写软件缺陷报告，软件缺陷报告是对缺陷进行记录、分类和跟踪的文档，软件测试人员的任务之一就是书写良好的缺陷报告，提供准确、完整、简介、一致的缺陷报告是软件测试人员的专业性和高质量的主要评价标准。

通常，缺陷报告最直接的读者是软件开发人员和质量管理人员，除此之外，来自市场和技术等部分的人也可能需要查看缺陷情况。在书写缺陷报告之前，我们需要明白谁会阅读缺陷报告，了解读者最希望从缺陷报告中获得什么信息，这有助于我们编写一份良好的缺陷报告。

软件测试工程师 遵照缺陷报告的写作准则来书写内容完备的恶软件缺陷报告。虽然编写软件缺陷报告类似于写作文，没有绝对的对错，但实际项目中，经常出现一些缺陷报告描述不清楚，或者包含过少或过多的信息，而且组织混乱，难以理解的现象。

比如假如你是程序员，当你被分配了一个缺陷，看到这样的描述：无论何时在搜索文本框中输入一串随机字符，软件都会开始进行一种奇怪的动作。“

在不知道随机字符是什么，一串字符有多长，产生什么现象的前提下，从何处着手修复这个软件缺陷呢？再或者这样的描述：在word中，段落调整出后出现了不正确的行为。对段落进行怎样的吊证，出现的不正确行为又是什么呢？这常常导致开发人员不得不得疑惑地把缺陷打回给提交者，或者一遍一遍的叫过去询问详情，增加了反复沟通的时间成本，这可能会延误修改缺陷的时机，导致项目延期或者带着缺陷一起发布出去。

接下来我们就来了解一份合格的缺陷报告都包括那些内容，不同的软件测试项目对于缺陷报告的具体组成不尽相同，但对于具体的测试项目而言，缺陷的基本信息通常都是比较固定的，而缺陷属性则需要根据不同的软件项目定制不同的属性值，一个完整的软件缺陷报告通常包含如下表所示的信息。

模块名称
缺陷编号	发现者
发现日期	分配给谁
缺陷版本号	缺陷状态
缺陷类型	缺陷严重等级
缺陷来源	缺陷处理优先级
缺陷标题
测试环境
复现步骤
实际结果
预期结果
注释

缺陷报告的基本信息

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

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

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

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

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

编号	原始描述	错误原因	改进标题
1	英文单词的连字符不管用	描述太笼统，什么时候不起作用呢？	在行末尾换行时，不能根据英文单词长度设置连字符
2	段落调整出现错误状态	描述太笼统，错误状态是什么？	选定两个单词，启动单词“字间距”自动调整后间隔排版错误
3	警告：该命令产生了错误的结果	没有包含原因与结果信息，描述内容太长	更新位图图像保存到服务器时，警告错误
4	在鼠标点击执行每一个拷贝或复制的编辑功能之后，响应时间很长	没有指明原因与结果，而且包含了过分详细的细节信息	拷贝和复制功能执行效率低
5	插入的引号成为特殊符号	信息没有充分隔离，所有引号都如此吗？什么类型的符号？	在文档中插入一个智能引号后显示不可识别的字符串

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

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

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

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

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

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

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

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

良好的复现步骤书写方式

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

例如：

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

可以简单的合并成一步

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

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

预期结果（Expected Result）

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

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

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

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

实际结果

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

实际结果

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

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

例如

实际结果

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

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

注释

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

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

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

注释

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

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

缺陷报告的属性

前面的小结中，我们讲述了软件缺陷报告的主体内容，但软件缺陷报告还包括一些属性，比如缺陷严重程度，处理优先级、版本号、状态、缺陷来源等组成部分，这些属性的属性值都是可以根据不同的公司来制定的，接下来学习一些这些属性常见的属性值

模块名称

指缺陷发生的功能模块，可以根据项目的大纲来划分，比如登录模块、购物车模块、搜索模块等

缺陷版本号

是指发现缺陷的软件版本号，版本号通常会以数字显示，但也有不同的方式，开发人员需要知道缺陷出现的版本，才能获取一个相同的版本进行 问题的重新，并且版本的标识有助于分析和总结问题出现的集中程度，例如版本1.1出现了大量的bug，则需要分析是什么原因导致这个版本出现了大量的问题

缺陷状态

测试人员在记录缺陷、验证缺陷时，必然要判定该缺陷的状态。缺陷状态是通过跟踪修复过程的进展情况而定义的。每个公司在缺陷管理系统中定义的缺陷状态属性值可能会有稍微不同，但基本都包含以下几种状态，如下表所示。

缺陷类型

按照缺陷产生的原因，可以对软件缺陷的类型进行划分，常见的属性值如下：

功能问题

是指影响了重要的功能特性、用户界面、产品接口、硬件结构接口和全局数据结构，并且设计文档需要正式的变更，如指针循环、递归等缺陷，主要包括：功能错误，功能确实，功能超越，设计的二义性，算法错误

接口问题

是指与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷，主要包括：模块间接口，模块内接口，公共数据使用

逻辑问题

是指修改缺陷需要进行逻辑分析、进行代码修改，如循环条件等。主要包括：分支不正确，重复的逻辑，忽略极端条件，不必要的功能，误解、条件测试错误，循环不正确，错误的变量检查，计算顺序错误，逻辑顺序错误

计算问题

指等式、符号、操作符或操作数错误、精度不够，不适当的数据验证等缺陷 。主要包括：等式错误、缺少运算符、错误的操作数、括号用法不正确、精度不够、舍入错误、符号错误等

数据问题

指需要修改少量代码，如初始化或控制块、声明、重复命名、范围、限定等缺陷，主要包括初始化错误、存取错误、引用错误变量、数据应用越界、不一致的子程序参数、数据单位不正确、数据维数不正确、变量类型不正确、数据范围不正确、操作符数不正确、变量定位错误、数据覆盖、外部数据错误、输出数据错误、输入数据错误、数据检验错误

用户界面问题

指人机交互特性，比如屏幕格式、确认用户输入、功能有特性、页面排版等方面的缺陷。主要包括：界面风格不统一、屏幕上的信息不可用、屏幕上的错误信息、界面功能布局和操作不合常规

文档问题

指影响发布和维护，包括注释等缺陷。主要包括：描述含糊、描述不完善、描述不正确、缺少或多余、不能验证，不能完成，不符合标准，与需求不一致，文字排版错误，文档信息错误，注释缺陷

性能问题

是指不满足系统可测量的属性值。如响应时间、事物处理速率、点击率等缺陷

配置问题

是指由于配置库、变更管理或版本控制引起的错误。主要包括：配置管理问题、编译打包缺陷、变更缺陷、纠错缺陷。

标准问题

是指不符合各种标准的要求，如编码标准，设计符号等缺陷，主要包括，不符合编码标准，不符合软件标准，设计、编译环境

环境问题

是指由于设计、编译和运行环境引起的问题，主要包括：设计、编译环境和运行环境

兼容问题

是指软件之间不能正确地交互作用和共享信息的缺陷。比如：操作平台不兼容、浏览器不兼容、分辨率不兼容等问题。

其它问题

除以上12种类型的其他缺陷

缺陷严重等级

缺陷的严重等级是指因缺陷引起的故障对使用产品的影响程度。缺陷生来就不是平等的，有一些导致系统奔溃或死机的缺陷很明显比软件界面不友好更影响用户的使用。按照 CMM5 中定义的规范，缺陷的严重等级可分为 3~5 个等级，但也有的公司列到 10 个等级，而有的公司只有 3 个等级。这里我以 5 级为例来详细讲述，缺陷的严重等级是缺陷的一个非常重要的属性，故在每个等级中分别举一个例子来帮助读者理解。

致命缺陷是指系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全的缺陷。或者系统所提供的功能或服务受到明显的限制，不能执行正常工作流程或实现重要功能。包括：

• 可能有灾难性的后果，如造成系统崩溃，造成事故的缺陷等；
• 数据库错误，如数据丢失、数据毁坏等；
• 安全性被破坏。

例如，一个导致死机的缺陷描述如下

问题摘要：通过地址簿填写多个收信人时导致所有程序无法响应。操作步骤

1. 建立新邮件，单击收信人按钮，查找电子邮件地址
2. 双击添加多个联系人地址；预期结果：成功通过地址簿添加多个联系人地址。实际结果：程序无法响应，同时也无法执行其他应用程序，必须重新启动机器

2-严重缺陷（Critical）

指可能导致系统不稳定，运行时好时坏，严重影响系统要求或基本功能实现的缺陷。比如：

• 造成数据库不稳定的错误；
• 在说明中的需求未在最终系统中实现；
• 程序无法运行，系统意外退出；
• 业务流程不正确等。

例如，一个异常退出的缺陷描述如下

问题摘要：编辑邮件回复时系统异常退出。操作步骤：1.打开收件箱中的人以邮件，选择编辑a选中所有文字。2.点击回复 预期结果：成功打开邮件编辑页面，并连带回复的内容。 实际结果：系统异常退出。备注：直接点击新建按钮，创建新邮件也会出现同样的问题

3-重要缺陷

指系统的次要共没有完全实现，但不影响用户的正常使用，不会影响系统稳定性的缺陷。比如

• 提示信息不太准确或用户界面差、操作时间长等一些问题
• 过程调用或其他脚本错误
• 系统刷新错误
• 产生错误结果，如计算错误，数据不一致等
• 功能的实现有问题，如在系统实现的界面上，一些可接受输入的空间带你点击后无作用，对数据库的操作不能正确实现
• 编码时数据类型、长度定义错误
• 虽然正确性、功能不受影响，但是系统性能和响应时间受影响

例如，一个数据处理错误，但对系统的影响不大的缺陷描述如下

问题摘要：查询发件箱邮件数量统计结果不正确 操作步骤

1.进入蓝桥企业邮箱a发件箱

2.设置查询条件，点击查询按钮。预期结果：查询后的统计结果正确显示。实际结果：查询后的统计结果比实际结果少一条记录

4.一般缺陷

是指使操作者不方便或遇到麻烦，但他不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题，重点指系统的ui问题

• 系统的提示语不明确，不简单明了
• 滚动条无效
• 可编辑区域和不可编辑区域不明显
• 光标跳转设置不好，鼠标定位错误
• 上下翻页，首尾页定位错误
• 界面不一致，或界面不正确
• 日期或时间初始值错误（起止日期，时间没有限定）
• 出现错别字，标点符号错误，拼写错误，以及不正确的大小写等

例如，一个界面显示的缺陷描述如下：

问题摘要：删除附件后界面显示不正确 操作步骤：

1. 进入“案件办理 à 代办案件”，选择一条案件，点击“办理”进入案件信息页面；
2. 点击“删除附件”删除案件原有的附件。 预期结果： 成功删除所选附件。 实际结果： 删除最后一个附件后，页面仍旧显示附件的说明信息，重新刷新后页面显示正确。

（5）5-改进意见（Enhancement）

是系统中值得改良的问题。比如容易给用户错误和歧义的提示；界面需要改进的；某个控件没有对齐等；测试人员可以对有疑虑的部分，提出修改建议。

例如，一个测试人员的建议描述如下：

1. 使用系统管理员账号登录系统，进入权限管理 à 基本信息维护 à 用户信息维护；
2. 执行增加功能，添加用户“test123”，保存；
3. 执行删除操作，删除用户“test123”；
4. 再次增加用户“test123”。 预期结果： 建议系统再次成功添加该用户。 实际结果： 系统提示“创建失败！数据库错误，请和管理员联系”，建议系统可以增加已删除的用户。

缺陷处理优先级(Priority)

在实际项目中，测试时间总是不足的，这是一种常态。那么除了在执行测试用例时选取优先级别比较高的先执行之外，修改软件缺陷也需要有所取舍，测试人员需要决定哪些缺陷需要优先解决，哪些缺陷可以在以后的版本中解决。

缺陷处理优先级表示开发人员修复缺陷的重要程度和紧迫程度，不同的项目可以划分成不同的级别，比如分成 2 级~~5 级。这里我以划分为 4 个等级为例，讲述不同优先级的定义描述，如下表所示。

缺陷处理优先级(Priority)

在实际项目中，测试时间总是不足的，这是一种常态。那么除了在执行测试用例时选取优先级别比较高的先执行之外，修改软件缺陷也需要有所取舍，测试人员需要决定哪些缺陷需要优先解决，哪些缺陷可以在以后的版本中解决。

缺陷处理优先级表示开发人员修复缺陷的重要程度和紧迫程度，不同的项目可以划分成不同的级别，比如分成 2 级~~5 级。这里我以划分为 4 个等级为例，讲述不同优先级的定义描述，如下表所示。

缺陷处理优先级	描述
2-高优先级（High Priority）	比较严重，影响测试，需要优先考虑的缺陷。
3-正常排队（Normal Queue）	需要正常排队等待修复的缺陷。
4-低优先级（Low Priority）	可以在开发人员有空余时间的时候被修正的缺陷。
1-立即解决（Resolve Immediately）	导致系统几乎不能使用或测试不能继续，需要立即修复的缺陷。

一般地，严重程度级别高的软件缺陷具有较高的处理优先级，但这并不是绝对的。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理；而一些严重程度低的缺陷却需要及时处理，反而具有更高的处理优先级。比如：

• 只要一启动，程序就崩溃这样的缺陷其严重级别是 1 级-致命缺陷，优先级别也是 1 级-立即解决；
• 某按钮位置摆放不合理，其严重级别是 4 级-一般缺陷，优先级别也是 4 级-低优先级；
• 极少发生的数据毁坏缺陷严重级别为 1 级-致命缺陷，但优先级应该是 3 级-正常排队；
• 而导致用户求助的安装说明中的错别字这样的缺陷，严重级别是 4 级-一般缺陷，但优先级应该是 2 级-高优先级；
• 再比如如果公司的名字和 logo 被误用了，这样的缺陷严重级别应该是 4 级-一般缺陷，但处理优先级应该是 2 级-高优先级。

通常，功能性缺陷一般较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般比较低，优先级也较低。但这也不是绝对的。

比如在一款财务系统软件中，影响数字准确度的功能逻辑缺陷比较严重，具有较高的优先级；软件界面类缺陷优先级则比较低。但在一款游戏软件中，影响界面美观和执行速度的缺陷，则拥有较高的处理优先级。

当然，软件缺陷的优先级在项目期间也不是一成不变的，有时候也会发生变化。==原来标记为高优先级的缺陷随着项目时间的流逝，可能变为优先级 4。==但不管如何变动，作为发现该缺陷的测试人员，都需要继续监视缺陷的状态，确保自己能够同意对其所做的变动，并进一步提供测试数据，或者想办法说服开发人员去修复缺陷。

缺陷来源

缺陷的来源也是缺陷的属性之一，常见的有以下几种来源，如下表所示

序号	缺陷来源	说明
1	需求 Requirement	由于需求的问题引起的缺陷
2	架构 Architecture	由于架构的问题引起的缺陷
3	设计 Design	由于设计的问题引起的缺陷
4	编码 Code	由于编码的问题引起的缺陷
5	测试 Test	由于测试的问题引起的缺陷
6	集成 Integration	由于集成的问题引起的缺陷

缺陷报告书写的准则

提高书写水平是不断积累经验，循序渐进的过程。遵循一定的准则可以让编写软件缺陷报告变得容易。那么编写软件缺陷报告有哪些书写准则呢？在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，可以避免很多不必要的错误。

遵循 5C 准则，如下图所示：

• Correct（准确）：每个组成部分的描述准确，不会引起误解和歧义，不夸大缺陷，也不要过于轻描淡写；
• Clear（清晰）：每个组成部分的描述清晰，不使用模棱两可的描述，比如出现“似乎（seem）”、“看上去可能（Possible）”等含义模糊的词汇；
• Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容。这可以通过使用关键词，使摘要的描述短小简练，又能准确解释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“及时消息”等就是关键词；
• Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息，可以使开发人员很容易看懂缺陷；
• Consistent（一致）：按照一致的格式书写全部缺陷报告。

报告随机缺陷

随机缺陷是指缺陷偶尔出现或者在测试过程中只被发现过一次，但不知道如何使其再次出现。这样的缺陷可能是时间炸弹，如果产品交付客户时还出现这样的情况，会影响客户对产品的信心。而且如果技术人员需要很长时间评估客户的数据或环境，客户则会更加厌烦。

测试人员容易纠结这个问题：随机缺陷到底要不要上报？报吧，自己无法复现，无法和开发人员说明白；不报吧，万一被客户或者项目经理发现了，就比较麻烦了。所以对于随机缺陷应当采取适当的方法处理。

• 首先，一定要及时详细的记录缺陷并提交到缺陷管理工具中，并在报告此类 Bug 时，明确说明自己不能复现这个程序错误，必要的时候要保存截图和相关日志，为开发解决 Bug 提供思维方向，并适当降低处理优先级。
• 其次，在系统中留下随机缺陷的记录之后，考虑到测试项目的整体进度，对于一时难以再现的缺陷可以暂时搁置，稍后再寻找合适的时间去尽量复现，或者等开发人员有空的时候再一起调试。以免因为一棵大树而丢掉整个森林，保证项目的正常进度。
• 最后，对随机缺陷要持续关注 3 到 5 个版本，如果在此期间从再未出现过，可以暂时关闭该缺陷，可能程序员在修改别的缺陷的时候无意中修复了这个缺陷；如果随机缺陷再次出现，可以让开发过来测试机前面现场分析。

该类问题出现的越少越好，虽然开发人员熟悉代码，也许可以很容易的从程序中获得解决软件缺陷的线索，但他们并不愿意也没有必要对发现的每一个软件缺陷都这么做。因为按道理讲，根本不存在随机缺陷这样的事，如果建立完全相同的输入和完全相同的环境条件，软件缺陷就一定会出现，无法复现也只能说明暂时还没有找到复现的步骤，因为建立完全相同的输入和完全相同的环境条件也不是一件容易的事情。

及时报告缺陷

发现一个缺陷要立即记录下来，不要在测试结束或每天结束之后，才开始一起提交，这样会遗忘一些 Bug，而且拖延的时间越长，关键细节被忘记的越多，程序错误被修改的可能性越小。

小缺陷也值得报告

被认为是很小的缺陷的情况可能包括拼写错误、小的屏幕格式问题、鼠标遗迹、小的计算错误、图形比例不准、在线帮助错误、不适当的灰掉了的菜单选项、不起作用的快捷键、不正确的错误信息，以及其他程序员认为不值得花精力去修改的缺陷。即使是一个很容易修改的小缺陷，也要及时提交到缺陷管理工具中，以免遗漏。小错误也可能会使客户感到困惑，并降低客户对产品其他部分的信心。

一个缺陷一个报告

不要试图把不同的程序错误合并到同一份报告中，来减轻项目经理或程序员对重复缺陷报告的不断抱怨。如果把多个缺陷写到同一份报告中，有些就可能不被注意得不到修改。虽然有时候几个缺陷可能最终查明是同一个原因，但是在修复之前是不知道的。单独报告即使有错，也比延误或者更糟糕地因为和其他缺陷混在一起而忘记修复要好。

以中性的语言描述缺陷

软件缺陷报告是针对产品，针对问题本身，将事实和现象客观地描述出来就可以了，否则开发人员和测试人员很容易形成对立关系。虽然发现很严重的缺陷是测试人员的“成绩报告单”，但却不可以喜滋滋的跑去“恭喜”那个倒霉的开发，或者使用类似“很糟糕”之类的带倾向性、个人观点和煽动性的措辞，不要对软件的质量优劣做任何主观性的批评和嘲讽。也不要使用一些带有情绪的强调符号，如黑体、全部字母大写、斜体、感叹号、问号等。

不要使用自认为比较幽默的语言，因为不同的读者其文化和观念不同，很多幽默内容在别人看来，往往难以理解，甚至可能引起误解。

少使用“我（I）”、“你（You）”等人称代词，可以直接使用动词或必要时使用“用户（User）”来代替。

引用别人的缺陷报告，不要擅自修改

引用别人的缺陷报告要小心，如果没有得到提交者的允许，可以补充评论，但不能编辑别人的材料。对于其他测试人员的缺陷报告即使很糟糕也不要擅自修改，如果需要在错误报告中做补充，要注明自己的姓名和日期。

以上技巧可以帮助测试人员提交准确简洁的，彻底校订的，精心构思的，高质量的缺陷报告。测试组长和经理应该让测试组成员清楚地认识到编写优秀的缺陷报告是一项首要且非常有意义的工作任务。

提高书写缺陷报告的水平是不断积累经验、循序渐进的过程。在正式提交缺陷报告之前，对缺陷报告的内容和格式进行自我检查，也可以避免很多不必要的错误，比如自我提问：

• 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
• 一个缺陷报告中是否只报告了一种缺陷？
• 读者是否能容易的搜索该缺陷？
• 步骤是否可以完全复现而且表达清楚吗？
• 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
• 缺陷的标题是按照原因与结果的方式书写的吗？
• 实际结果和预期结果是否描述不够清楚而容易引起歧义吗？

小结

本章主要介绍了缺陷的定义和产生的原因，重点引导读者编写一份良好的缺陷报告，包括其基本信息、属性及常见的属性值，缺陷的生命周期以及缺陷管理工具 BugFree 的使用介绍。本章重点注意事项如下：

• 缺陷的 5 种定义规则有助于测试人员识别软件缺陷；
• 软件缺陷的最大来源是产品需求说明书，而不是程序代码本身。测试人员需要在前期对产品需求说明书进行验证和推敲；
• 编写软件缺陷报告时要尽量保证缺陷可以复现，遵循 5C 准则等。
• 为了确保导致软件缺陷的全部细节是可见的，可以使用截图或录制视频的方式提交软件缺陷；
• 对于无法复现的缺陷，要及时提交，但不能全是这种缺陷，开发人员会怀疑你的测试专业度；
• 并不是每个缺陷都会被开发人员修复，对于不修复的软件缺陷测试人员也要跟踪到底；
• 软件缺陷的属性中的属性值是根据不同的项目进行定制的；
• 软件缺陷的严重级别越高，处理优先级通常越高，但这并不是绝对的；
• 软件缺陷的处理流程会由于测试项目不同而有所不同，但大同小异；
• 软件缺陷的管理工具多种多样，都是配合项目的软件缺陷的生命周期而存在的，BugFree 是一款免费开源、简单易学的缺陷管理工具。

通过本章的学习，读者可以拓展的内容主要有 2 点：

• 为了做好回归测试工作，关于风险分析，在项目管理中，有一整套标准的流程和方法，感兴趣的同学可以去学习相关知识。
• 禅道是当下比较流行的一款配合敏捷开发而生的管理工具，它基于敏捷而不限于敏捷，是一款开源免费的项目管理软件，集产品管理、项目管理、测试管理于一体，在当今很多管理工具中脱颖而出。强烈推荐读者学习并熟练掌握其操作使用。