第一章  测试中缺陷的识别与描述

简介

在第一章中已讲了软件测试的目的，其中一个软件测试的目的就是要发现其存在的问题并解决它，保证软件的质量，本章就重点讲软件缺陷的相关概念、识别和描述缺陷的方法等。通过本章的学习可以了解到什么是软件缺陷，为什么会出现软件缺陷，如何去识别项目中的缺陷以及该怎样描述一个缺陷，对软件缺陷的认识和了解从本章开始。

3.1  初识软件缺陷

3.1.1  软件缺陷是什么

软件问题在软件工程或软件测试中都被称为软件缺陷或软件故障。在不引起误解的情况下，不管软件存在问题的规模和危害的大小，由于都会产生软件使用上的各种障碍，所以将这些问题统称为软件缺陷。

对于软件存在的各种问题，都用“软件缺陷”这个词，在英文中人们喜欢用一个不贴切但已经专用的词“缺陷（臭虫）”，实际和“缺陷（缺陷）”词相近的词还有很多，如：

缺点（Defect）                    偏差（Variance）

异常（Anomy )                     失败（Failure)

问题（Problem）                   矛盾（Inconsistency)

错误（Error）                     毛病（Incident）

但人们都习惯使用“软件缺陷（缺陷）”这个词，它含有一些偏差、谬误或错误的意思，更多地表现在功能上的失败（Failure）和实际需求的不一致，即矛盾（Inconsistency）。软件缺陷，即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要，在IEEE 1983 orIEEEstandard729 中对软件缺陷下了一个标准的定义。

1）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。

2）从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷就是软件产品中所存在的问题，最终表现为用户所需没有完全实现，没有满足用户的需求。

3.1.2  为什么会出现软件缺陷

通过软件测试可以发现软件产品中的缺陷，那么缺陷是怎么产生的呢?软件程序写完后都要进行测试，因为没有人能保证它所写的程序是完全正确无误的。而即使经过了严密的测试，软件仍然会或多或少存在缺陷。我们所能够做的就是尽量减少缺陷，确定缺陷发生的原因并加以修正。

给软件带来缺陷的原因有很多，这里列举几点。

Ø  人员之间的沟通交流不够，交流上有误解或者根本不进行交流。

Ø  程序设计本身有错误。

Ø  软件复杂性。

Ø  需求不断变化。

Ø  工期短，任务重，压力大。

Ø  参与人员的过度自信。

Ø  文档不完善。

Ø  软件开发工具和系统软硬件的支持不完备。

以上列举了一些软件缺陷产生的主要原因。

3.1.3  测试中怎样识别软件缺陷

在一个软件中，把所有的软件问题都称为缺陷听起来也许非常简单，但是这样做并不能真正解决问题，现在缺陷（缺陷）这个词需要加以定义。首先需要了解一下一个辅助术语：产品说明书（product specification）。产品说明书有时又简称为说明（spec）或产品说明（product spec），是软件开发小组的一个协定，它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。

在项目中，只有至少满足下列5个规则之一才称发生了一个软件缺陷（software 缺陷）：

（1）软件未实现产品说明书要求的功能。

（2）软件出现了产品说明书指明不会出现的错误。

（3）软件实现了产品说明书未提到的功能。

（4）软件未达到产品说明书虽未明确指出但应该实现的目标。

（5）软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户认为不好。

为了更好地理解每一条规则我们以计算器为例进行说明。

计算器的产品说明书声称它能够准确无误地进行加、减、乘、除运算。当你拿到计算器后按下“+”键，结果什么反应也没有，根据第（1）条规则这是一个缺陷。假如得到错误答案根据第（1）条规则这同样是一个缺陷。

若产品说明书声称计算器永远不会崩溃、锁死或者停止反应。当你任意敲键盘，计算器停止接收输人，根据第（2）条规则这是一个缺陷。

若用计算器进行测试发现除了加、减、乘、除之外它还可以求平方根，说明书中从没提到这一功能，雄心勃勃的程序员只因为觉得这是一项了不起的共鞥而把它加入，这不是功能，根据第（3）条规则，这是软件缺陷。这些预料不到的操作，虽然有了更好，但会增加测试的工作，甚至可能带来更多的缺陷。

若在测试计算器时发现电池没电会导致计算不正确，但产品说明书未指出这个问题．根据第（4）条规则，这是个缺陷。

软件测试人员是第一个真正使用软件的人，否则，客户就是第一个使用软件产品的人。如果软件测试员发现某些地方不对劲无论什么原因都要认定为缺陷。在计算器例子中，如果觉得按键太小，“=”键布置的位置极其不好按，或在明亮光下显示屏难以看清，根据第（5）条规则这些都是缺陷。

注意：每一个使用过一些软件的人都会对软件的工作方式有自己的意见和想法，要编写令所有人都满意的软件是不可能的。作为软件测试人员，在运用第（5）条规则时应记住下面这一点：要全面、最重要的是要客观评价，并非所有的测试发现的缺陷都要进行修改。

3.1.4  修复软件缺陷的代价

在一开始介绍软件测试时，曾说测试人员要从需求分析时就介入进去，问题发现得越早越好。缺陷被发现之后，要尽快修复这些被发现的缺陷。为什么要这样做呢？原因很简单，错误并不只是在编程阶段产生，需求和设计阶段同样会产生错误。也许一开始，只是一个很小范围内的潜在错误，但随着产品开发工作的进行，小错误会扩散成大错误，为了修改后期的错误所需要的工作量要大得多。缺陷发现或解决得越迟，成本就越高。

Boehm在software Engineering Economics（1981年）一书中写到：平均而言，如果在需求阶段修正1个错误的代价是l ，那么在设计阶段就是它的3~6倍，在编程阶段是它的10 倍，在内部测试阶段是它的20~40 倍，在外部测试阶段是它的30~70倍，而到了产品发布出去时，这个数字就是40~1000倍。修正错误的代价不是随着时间线性增长，而几乎是呈指数增长的。图3-1所示就是说明这样一个道理。

图3-1 软件缺陷修复成本趋势图