软件测试缺陷分类（全程软件测试三十一）

软件缺陷是系统或系统部件中导致系统或部件不能实现其功能的错误。在执行中遇到某个缺陷，可能引起系统的失效。准确、有效地定义和描述软件缺陷可以使软件缺陷得以快速修复，节约软件测试项目的成本和资源，提高产品质量。

软件缺陷的基本描述

软件缺陷的描述是软件缺陷报告中测试人员问题陈述的一部分，而且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员针对一个软件问题与开发小组交流的最初且最好的机会。一个较好的描述需要使用简单、准确、专业的语言来抓住缺陷的本质，否则，它会使软件缺陷的信息含糊不清，可能会误导开发人员。

以下是软件缺陷的有效描述规则：

（1）单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷往往会导致只有其中一个软件的缺陷得到注意和修复。

（2）特定条件。许多软件功能在通常情况下没有问题产生，在某种特定的条件下才会暴露缺陷，因此软件缺陷的描述不能忽略那些看似细节但又必要的特定条件（如特定的操作系统、浏览器或某种特定的设置等），以及能够帮助开发人员找到原因的线索（如“返回功能返回跳转页面不正确”）。

（3）可以再现。提供再现这个缺陷的精确步骤，使开发人员容易看懂，便于再现并修复缺陷。

（4）短小简练。通过使用关键词可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。例如，在“界面购物车模块无法显示”中，“界面”“购物车”是关键词。

（5）完整统一。提供完整的、前后统一的软件缺陷信息，如相关图片、文件等。

（6）补充完善。从发现软件缺陷时开始，测试人员的责任就是保证此软件缺陷被正确地报告以及得到应有的重视，并继续监视该软件缺陷的修复全过程。

（7）不做评价。软件缺陷描述不要带有个人观点，不要对开发人员做出任何评价。软件缺陷报告只针对产品。

遵循软件缺陷有效描述规则的益处有以下几点：

（1）准确、清晰的软件缺陷描述可以减少开发人员返回的缺陷数量。

（2）提高软件缺陷修复的速度，使每一个小组都能有效地工作。

（3）提高开发人员对测试人员的信任度，得到开发人员对缺陷报告的积极响应。

（4）加强管理人员、开发人员、测试人员三者之间的协同工作能力，以便更有效地工作。

软件缺陷的属性

开发人员需要去修复每一个软件缺陷，但并不是每个软件缺陷都需要开发人员紧急修复。因此，测试人员需要定义软件缺陷的属性，供开发人员参考，这样才能按照优先等级、严重程度去修复软件缺陷，不至于遗漏严重的软件缺陷。测试人员则可以利用软件缺陷的属性跟踪软件缺陷，保证产品质量。

软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生的可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源。

（1）缺陷标识：标记某个缺陷的唯一标识，可以使用数字序号。

（2）缺陷类型：根据缺陷的自然属性划分的缺陷种类，如表1所示。

表1 软件缺陷类型

表1 续表

（3）缺陷严重程度：缺陷引起的故障对软件产品的影响程度，指的是在测试条件下，一个错误在系统中的绝对影响，如表2所示。

表2 软件缺陷严重程度

（4）缺陷产生的可能性：缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。

表3 软件缺陷产生的可能性（部分）

（5）缺陷优先级：缺陷必须被修复的紧急程度。优先级的衡量抓住了在严重等级中没有考虑的重要程度因素，如表4所示。

表4 软件缺陷优先级

通常情况下，缺陷严重程度和缺陷优先级的相关性很强，但是，具有低优先级和高严重等级的错误是存在的，反之亦然。例如，产品徽标丢失，这种缺陷是用户界面的产品缺陷，但是它损害产品的形象，那么它是优先级很高的软件缺陷。

（6）缺陷状态：描述缺陷修复的进展情况，如表5所示。

表5 软件缺陷状态

（7）缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段，如表6所示。

表6 软件缺陷起源

在软件生命周期中软件缺陷占的比例：需求和构架设计阶段占54%，设计阶段占25%，编码阶段占15%，其他占6%。

（8）缺陷来源：指缺陷所在的地方，如文档、代码等，如表7所示。

表7 软件缺陷来源

（9）缺陷根源：造成错误的根本因素。了解缺陷根源有助于软件开发流程的改进和管理水平的提高，如表8所示。

表8 软件缺陷根源

软件缺陷的相关信息

前面所叙述的软件缺陷属性是其基本信息，为了更好地处理软件缺陷，需要了解其他相关的信息。软件缺陷相关的信息包括软件缺陷图片、记录信息及如何再现和分离软件缺陷。针对某一个软件缺陷，测试人员应该给予相关的信息，如捕捉到软件缺陷的日志文件和图片，以保证开发人员和其他的测试人员可以分离和再现它。本篇重点介绍需要添加图片文件的情况和分离及再现软件缺陷的建议。

1.软件缺陷的图片、记录信息

软件缺陷的图片、记录信息是软件缺陷报告重要的组成部分。

一些涉及用户界面的软件缺陷可能很难用文字清楚地描述，因此软件测试人员通过附上图片能比较直观地表示缺陷发生在产品界面的位置和问题。

（1）采用图片的格式

测试人员一般采用JPG、GIF图片格式，因为这类文件占用的空间小，打开的速度快。

（2）需要附上图片的情况

通常情况下，出现在用户界面并且影响用户使用或者影响产品美观的软件缺陷附上图片比较直观。举例如下。

① 当产品中有一段文字没有显示完全，为了明确标识这段文字的位置，测试人员必须贴上图片。

② 在测试外国语言版本时，当发现产品中有一段文字没有翻译，测试人员需要贴上图片标识没有翻译的文字。

③ 在测试外国语言版本时，当发现产品中有一段外国文字显示乱码，测试人员必须贴上图片标识出现乱码的外国文字。

④ 产品中的语法错误、标点符号使用不当等软件缺陷，测试人员应贴上图片告知开发人员缺陷的位置。

⑤ 在产品中运用错误的公司标志和重要的图片没有显示等软件缺陷，也需要附上图片。

测试人员需要注意，有必要在图片上用颜色标注缺陷的位置，让开发人员一目了然，使得软件缺陷尽快修复。

2.分离和再现软件缺陷

要想有效地分离软件缺陷，需要清楚、准确地描述再现软件缺陷的具体步骤和条件。在某些情况下只要具备特定的测试用例，软件缺陷就会再次出现；但某些情况下，再现、验证软件缺陷的条件、环境、技术等要求都非常高，而且非常浪费资源。

（1）分离和再现软件缺陷的步骤

为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法。虽然有时个别缺陷很难再现，或者根本无法再现。

下面介绍分离和再现缺陷的一些常用方法和技巧。

① 注意压力与负荷、内存与数据溢出相关的边界条件。执行某个测试可能会导致产生缺陷的数据被覆盖掉，而只有在试图使用该条数据的时候缺陷才会再现。在重启计算机后软件缺陷消失，执行完其他测试之后又出现类似的软件缺陷，此时需要注意某些软件缺陷有可能是在无意中产生的。

② 保证所有的步骤全部被记录。所做的每一件事、每一个步骤、每一个停顿必须记录下来。少一个步骤或多出一个步骤，都可能导致无法再现软件缺陷。在尝试运行测试用例时，可以利用录制工具准确地记录执行的每一个步骤，目的是确保暴露缺陷所需的全部细节都是可见的。

③ 不可忽视硬件设备。与软件不同，硬件不会按照预定的方式去工作，CPU 过热、内存条损坏、板卡松动都可能导致软件的运行失败。设法在不同硬件设备上再现软件缺陷，判断该软件缺陷是在一个系统上还是在多个系统上产生，这在执行配置或兼容性测试时非常重要。

④ 考虑资源依赖性，包括内存、网络和硬件共享的相互作用。软件缺陷是否只在运行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终被证实跟网络资源、硬件资源有相互作用，分析这些影响有利于分离和再现软件缺陷。

⑤ 注意特定的条件和时间。软件缺陷是否仅在特定时刻、特定条件下产生？产生软件缺陷时网络是否出问题？在较好和较差的硬件设备上运行测试用例是否会产生不同的测试结果？

有时开发人员也可根据比较简单的错误信息找出问题所在。因为开发人员熟悉代码，看到症状、测试用例的步骤和分离问题的过程，可能会得到查找软件缺陷的线索。一个软件缺陷的分离和再现有时需要大家的共同努力。如果测试人员尽全力去分离软件缺陷，最后还是无法准确表达该缺陷的再现步骤，那么仍需记录和报告软件缺陷。

（2）分离和调试软件缺陷之间的区别

研究分离与调试软件缺陷二者之间的区别，其实就是为了分清测试人员与开发人员各自的责任，提高二者之间界限的清晰度与测试资源控制能力。在面对一个软件缺陷时，开发人员与测试人员为了修复该缺陷，会逐步提出一系列疑问。

① 最少通过多少步再现软件的缺陷？这些步骤能否成功再现缺陷？

② 软件缺陷是否真的存在？缺陷的产生是因为测试因素或者测试人员自身的错误，还是影响顾客需求的、系统真正的故障？

③ 产生软件缺陷的外部因素是什么？

④ 产生软件缺陷的内部因素是什么？

⑤ 如何在不产生新缺陷的条件下修复已发现的软件缺陷？

⑥ 缺陷的修复是否经过调试？是否做过单元测试？

⑦ 产生缺陷的问题是否解决？是否通过了确认和回归测试，确定系统的其余部分仍能正常工作？

第①步是为了证明该软件缺陷并不是意外产生的，并精简操作步骤；第②③步分离了这个软件缺陷；第④⑥步是调试任务；第⑦步做确认和回归测试。在整个过程中，缺陷从测试阶段（第①到③步）进入开发阶段（第④到⑥步），然后再回到测试阶段（第⑦步）。虽然看似简要，但其边界并不是很清晰，特别是第③④步会产生一些资源重叠和不必要的精力浪费。

如果软件缺陷描述非常清楚，包含第①②③步中问题的答案，意味着在分离与调试之间清楚地画上一条界线，测试人员就能专注于测试过程，而不受开发人员的影响。如果测试人员不能清楚描述出缺陷的特征，导致再现和错误种类的不确定性，继而无法将其分离，测试人员和开发人员就可能不得不一起进行调试。但是，测试人员还有很多其他的工作需要完成，不应该被卷入调试工作。开发人员向测试人员询问情况是调试工作的一部分，这是开发人员的职责，而测试人员只需在软件缺陷描述的基础上回答开发人员的问题。否则，测试人员可能会花费大量的时间和精力去解答开发人员所提出的问题。

,