1.2 软件缺陷
在前面我们讨论软件工程和软件质量的时候，读者应该已经意识到在软件开发过程中会产生许多问题，习惯上我们称其为软件缺陷。本节我们将对软件的缺陷进行进一步说明，给出软件缺陷的定义及缺陷产生的原因，读者在学习时需要重点思考这些知识。
1.2.1 软件缺陷的定义
软件缺陷在软件开发过程中是一个高频词语，更多的时候习惯用bug替代。软件缺陷的含义十分广泛，有时候，软件缺陷是指在软件运行中因为不满足用户确定需求或者程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象；有时候，某些程序错误会造成计算机安全隐患，此时软件缺陷叫作漏洞；有时候，人们也将软件的问题、错误、故障、失效、偏差等均称为软件缺陷。IEEE 729-1983对软件缺陷有一个定义：“从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。”我国的国家标准GB/T32422-2015《软件工程 软件异常分类指南》对软件缺陷也进行了定义：“工作产品中出现的瑕疵或缺点，导致软件产品无法满足用户需求或者规格说明，需要修复或替换。”
从上面罗列的软件缺陷的定义来看，各种词汇代表的含义还是有差异的。那么在实际的软件开发过程中，我们在认定软件缺陷的时候至少要满足下列5条规则之一。
一、软件未实现需求和规格要求的功能。
二、软件出现了需求和规格指明不该出现的错误。
三、软件实现了需求和规格未提及的功能。
四、软件未实现需求和规格未明确提及但应该实现的内容。
五、软件难以理解，不易使用，运行缓慢，或者从测试人员的角度看，最终用户（估计会）认为不好。
下面我们举一个语音通话功能的例子对以上5条规则进行说明，以方便读者理解。
语音通话产品的说明书声称它能够通过搜索联系人进行语音通话。如果软件测试人员在使用该语音通话功能时发现没有搜索联系人的功能，那么根据规则一，这就是一个缺陷；或者如果选择了联系人点击语音通话没有反应，那么根据规则一，这同样是一个缺陷。
产品说明书声称不间断地拨打和挂断语音通话不会出现死机或崩溃。如果测试人员连续拨打、挂断语音通话，该软件出现了崩溃的情况，那么根据规则二，这是一个缺陷。
假如该软件除语音通话功能外，还能进行视频通话。但是该产品说明书中并没有提到该功能，是开发人员觉得视频通话这一功能了不起就添加进来了。根据规则三，这也是一个软件缺陷。这些多加进来的功能虽然使软件的功能更加全面，但是会引起更多的缺陷。
规则会让人觉得很奇怪，其目的是要检查产品需求说明书上的遗漏之处。假设在测试语音通话功能时，出现了因对方正在通话而导致通话连接不成功的现象。而产品说明书上并没有说到这一点，假设双方都是空闲时间，而开发人员在开发完成后也没有处理这种现象，那么根据规则四，这也是缺陷。
规则中提到软件测试人员需要从最终用户的使用角度来对软件产品进行判定，如果软件测试人员发现某些地方不合适，那么用户在使用时也会觉得不合适，比如测试人员觉得在进行语音通话时显示的通话时间字体太小等，根据第五条规则，这也算是缺陷。
缺陷的表现形式非常多，根据以上5条规则可以让软件测试人员对遇到的缺陷进行更好的识别。
1.2.2 软件缺陷产生的原因
软件缺陷是如何产生的呢？软件是人设计开发出来的，通常还是团队合作的成果，基于个人在理解、思维和能力方面的局限性以及团队组织、沟通、工作规范化等方面的原因，加上技术因素，软件出现缺陷的概率很高。许多人以为软件的缺陷主要是在编码阶段产生的，然而令人感到吃惊的是，大多数软件的缺陷并非源自编程错误。软件在需求分析和设计阶段同样会引起缺陷，而且比例超过编码阶段，如图1-3所示。通过对大小项目的分析，发现在需求分析阶段引入的缺陷比例最高，通常超过40%，在这个阶段缺陷的产生是因为产品需求说明书没有写明、描述不够全面、经常变更或者整个开发团队没有很好地沟通。设计阶段带来的缺陷也在30%以上，这个阶段是开发人员规划软件的过程，这个阶段产生软件缺陷的原因很有可能是开发人员对需求的理解过于随意、程序设计变更比较频繁，或者团队之间沟通不够充分等。而编码产生的缺陷低于30%，因为这个阶段的缺陷很容易被开发人员发现，通常编码错误可以归咎于软件的复杂性、文档不足、项目进度压力或者一些低级错误。
图1-3 软件缺陷产生的原因
1.2.3 软件缺陷的分类
一旦发现软件缺陷，那么绝大多数是要尽快修复的，但由于缺陷产生和发现的时机不同，因此对各个阶段缺陷的修复代码也有着巨大差异。一般而言，在软件工程活动中，缺陷从产生到发现的间隔时间越短，修复的代价就越小。软件工程活动中要努力做到缺陷早发现早排除。因此，我们可以对软件缺陷进行分类，这样一方面有助于确定缺陷产生的原因，帮助对软件过程进行改进，另一方面有利于软件的开发者、测试者、管理者、评价者以及使用者之间进行沟通和信息交换。
按照不同的标准，将缺陷划分如下。
1.按照严重程度划分
（1）致命错误：如数据丢失、死机、系统崩溃。
（2）严重错误：如功能未完成、功能完成不正确。
（3）一般错误：如功能不完善、界面问题等。
（4）建议（轻微）：测试人员认为怎么处理会更好一些的问题。
2.按照修改优先级划分
（1）立即修改。
（2）在本版本中修改。
（3）在产品发布前修改。
（4）在发布版本中可以存在的问题。
3.按照缺陷类型划分
根据缺陷的类型不同，我们把软件缺陷分为：功能缺陷、压力/负载缺陷、界面缺陷、兼容缺陷、易用缺陷、安装/卸载缺陷、安全缺陷等。
4.按照功能模块划分
根据发现缺陷的功能点和所属模块的不同，可以分为：功能模块A、功能模块B、功能模块C等。
缺陷的优先级和严重程度在不同的企业可能会因为业务场景差异有不同的定义，但是对软件缺陷的处理，均应该根据缺陷的严重程度和优先级进行。
1.2.4 软件缺陷的处理流程
在软件测试过程中，每个公司都定义了自己公司处理缺陷的流程，每个公司的流程会有所差别，但是都要经过提交缺陷、分配缺陷、确认缺陷、处理缺陷、回归验证、关闭缺陷等环节，如图1-4所示。
图1-4 软件缺陷的处理流程
关于图1-4中各个环节的具体说明如下。
（1）提交缺陷：测试人员发现缺陷之后，将缺陷提交给测试组长。
（2）分配缺陷：测试组长将收到的缺陷分配给开发人员。
（3）确认缺陷：开发人员收到缺陷后，对缺陷进行确认。
（4）拒绝处理/延期处理：如果开发人员确认是缺陷，则按照缺陷的严重程度和优先级等选择立即处理或延期处理。如果经过确认发现不是缺陷，则会拒绝修改，关闭缺陷。
（5）处理缺陷：开发人员确认是缺陷后，对缺陷进行处理。
（6）回归验证：开发人员修改好缺陷后，测试人员进行回归验证（重新测试），检查缺陷是否确实修改，如果缺陷未被修改，则重新提交缺陷。
（7）关闭缺陷：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。
1.2.5 软件缺陷管理软件
在实际的软件测试工作中，测试人员在提交软件测试结果时会按照公司规定的模板将缺陷的详细情况记录下来生成报告，提交给开发人员进行解决，也方便后期进行回归验证。每个公司规定的模板并不相同，但是一般都会包含缺陷的编号、缺陷的类型、严重程度、优先级、测试环境、重现步骤、期望结果和实际结果等。选择一个好的软件缺陷管理工具能有效地加快软件项目的进度。缺陷管理工具有很多，免费的、收费的都有，下面介绍几个比较常用的软件缺陷管理工具。
1.禅道
禅道是一款国产的开源项目管理软件，其专注研发项目管理，内置需求管理、任务管理、bug管理、用例管理、计划发布等功能，实现了软件的完整生命周期管理。禅道分企业版、旗舰版、开源版等，企业版和旗舰版是收费软件，开源版是免费软件。
2.JIRA
JIRA是Atlassian（艾特莱森）公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA配置灵活、功能全面、部署简单、扩展丰富。JIRA推出云服务和下载版，均提供30天的免费试用期。云服务无须安装可直接试用；下载版采用一键式评估安装，在用户自己的服务器上运行。