软件缺陷是软件开发过程中的副产品，通常缺陷会导致软件产品在某种程度上不能满足客户需求。因此，妥善处理软件中的缺陷是关系到软件产品质量的根本。可遗憾的是，并非所有的软件团队都知道如何有效地管理在测试中发现的缺陷。

　　对于软件测试人员而言，在测试中不能正确表示缺陷的严重程度和优先级，这将会影响到软件缺陷管理的质量，不仅不利于有效的处理软件缺陷，还可能影响到软件缺陷的处理时机。特别在软件测试的后期，将影响软件是否能够按期发布与否。近期我在一个测试项目中，由于对缺陷严重程度和优先级缺乏有效处理，最终导致软件验收发布被迫延后。

　　什么是缺陷严重程度和优先级？

　　（1）什么是缺陷的严重程度和优先级

　　软件缺陷是指在软件系统中会导致系统不能实现其功能的缺陷（包括Defect或Bug）。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。

　　其中缺陷严重程度是指软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将会对软件的功能和性能产生怎样的影响。优先级是指表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

　　（2）正确评估严重程度和优先级的作用

　　缺陷管理的目标在于：当在软件测试过程中发现缺陷后，能正确评估缺陷并执行及修正系统质量，以创造一个合乎需求的软件产品。因此，软件产品质量很大程度上取决于在测试中发现的缺陷的管理能力。其中软件缺陷严重程度和优先级的正确评估和描述是软件缺陷管理的基础部分，也是测试人员与开发小组交流的基础。一个好的严重程度和优先级评估会用简单的、准确的、专业的语言来反映缺陷的本质。否则，如果评估和描述信息含糊不清，就可能会误导开发人员。因为清晰准确的软件缺陷评估可以提高软件缺陷修复的速度，也可以加强开发人员、测试人员和管理人员的协同工作。

　　因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。为了保证正确评估缺陷的严重程度和优先级，质量保证人员需要经常检查测试人员和开发人员对于这两个指标的评估和处理情况，一发现有问题及时反馈给项目负责人解决。

　　（3）缺陷的严重程度和优先级的级别划分

　　缺陷的严重程度和优先级通常可按级别划分，各个公司对不同项目的具体表示方式有所不同，具体的级别划分需要软件测试前达成一致。常用的缺陷严重程度可分为：致命、严重、一般、较小。致命是指系统任何一个主要功能完全丧失，或用户数据受到破坏，造成系统崩溃、悬挂、死机或者危机人身安全；严重是指系统的主要功能部分丧失，或数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般是指系统的次要功能没有完全实现，但不影响用户的正常使用；较小是指使操作者不方便或遇到麻烦，但它不影响功能的操作和执行的一些小问题。

　　常用的缺陷的优先级表示方法可分为：立即解决、高优先级、正常排队、低优先级。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。

　　（4）缺陷严重程度和优先级的关系

　　严重程度高说明缺陷对软件造成的质量危害性大，是需要优先处理，而严重程度低的缺陷可能只是软件不太尽善尽美，可以稍后处理。因此，缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们是从不同的侧面描述了软件缺陷对软件质量的影响程度和处理方式。

　　一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。

　　如何评估缺陷严重程度和优先级？

　　（1）明确用户需求，设定软件质量标准

　　我们常常听到许多自称测试专家的人在大谈特谈缺陷严重程度和优先级的标准，例如什么系统死机就一定是高级别，界面错误则是低级别之类。但事情上，对于不同的软件因为应用场合的不一样，即使是同一类型的缺陷但也可能其严重程度和优先级是不一样的。

　　一般来说，软件程序并不需要十全十美，因为尽善尽美意味着成本巨大，但软件产品必须迎合和满足目标用户的需求和期望。因此，对于一个软件产品, 应该从客户角度来建立缺陷严重程度和解决优先级。了解对用户来说什么是最重要的，而不只是根据经验和常识来制定缺陷的严重程度和优先级。

  （2）实事求是的确定缺陷严重程度和优先级

　　通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。但实际上，优先级和严重程度是有联系也有区别。严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。

　　那么，怎么样才能使得一个包含缺陷的软件产品却看起来性能优良呢?具体说很大程度上是根据公司和客户需求来决定的。简单说，就是缺陷对客户影响严重程度（主要、次要、不严重），就是对软件产品的影响严重程度；缺陷客户的优先级（紧急、普通、不急）就是项目的优先级。所以，并非所有的缺陷都是一样的重要，也并非根据以往的项目经验就能确定软件缺陷的严重程度和优先级。判断的依据应该是从软件最终用户的观点来做出判断，即判断缺陷的严重程度是先考虑用户的利益，例如此类缺陷是否会对用户使用造成恶劣后果的严重程度。因此，根据用户需求和期望，是分析和评估缺陷严重程度至关重要的一步。

　　但缺陷优先级却不只是依据客户需求来判断的，缺陷优先级还必须要根据开发角度和资源投入来进行划分和评估优先次序。一般来说，测试比较规范的团队，会由测试经理、项目经理等部门根据技术角度和公司资源来制订一份优先级的标准文档。因为缺陷的修正顺序是个复杂的过程，不单是纯粹技术问题，除了要站在开发的角度去考虑问题外，更多的还要考虑抢占市场先机和公司资源分配的情况。

　　另外，为了确保软件缺陷的有效管理，在一定环境和条件下缺陷应该可以改变优先次序，如升级和降级。就是说随着项目进度，可能会重新划分严重程度和优先级别。因此，确定和评估缺陷严重程度和优先级要全面了解和深刻体会缺陷的特征，要从用户需求、开发角度以及市场的因素综合考虑。

　　（3）避免两种常见的误区

　　正确评估缺陷的严重程度和优先级不是件容易的事情，对于经验不是很丰富的测试人员而言，经常犯的错误有两种情形：一是将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，不但影响到对软件质量的正确评估，而且也耗费了开发人员辨别和处理缺陷的时间。二是将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。结果到项目后期才发现还有很多由于不正确评估优先级造成的严重缺陷，将会需要投入更多人力和时间进行修正，影响软件的正常发布；或者这些严重的缺陷成了漏网之鱼，随软件一起发布出去可能会造成软件质量事故。

　　巧用评估技术工具，分清轻重缓急

　　因此，正确评估和区分缺陷的严重性和优先级，是测试人员和开发人员以及全体项目组人员的一件大事。这既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该要引起足够的重视。这里介绍三种常用的技术工具供大家参考。

　　（1）20/80原则

　　管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些缺陷是最重要的，哪些缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则---分清轻重缓急，把测试活动用在最有生产力的事情上。

　　（2）ABC法则

　　古人云：事有先后，用有缓急。测试工作其实也是如此，分清缺陷的轻重缓急，不但做处理缺陷来井井有条，完成后的效果也是不同凡响。因此，我们在测试工作中要时时记住一点，手边的缺陷并不一定就具有第一优先处理的重要性。只有正确的判断，才可将测试活动效率增加数倍。

　　ABC法则是设定缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类缺陷作为测试最重要的最有价值的最关键的缺陷，并保证首先把A类缺陷先处理。其次是B类，然后是C类，然后是其它的，还有一些不紧急不重要的缺陷根本没有必要去做。因此，应用ABC方法可更明确地确定各项测试目标，当然也能更明确把要处理的缺陷和它们的优先次序确定。

　　（3）四象限原则，把缺陷进行分类

　　在处理测试缺陷中，常会遇到千头万绪、问题繁多的情况，有些测试人员会被测试出来众多的缺陷所压垮，有些人则是悠然自得、高效完成。到底是什么原因造成这种区别呢？原因在于对缺陷分类是否合理。

　　那么，我们该如何对缺陷进行合理的分类呢？其实很简单，在一张坐标纸上，先划分好四个象限，然后只需记住四个字就行，那就是"轻重缓急"。" 轻"，指的是相对重要但不紧急的缺陷；"重"，是指最重要也是最紧急的缺陷；"缓"，指的是不重要也不紧急的缺陷；"急"，则是指不是最重要但却最为紧急的缺陷。理清这种关系之后，就算同时测试许多不同类型的缺陷，也会很快清楚哪些缺陷是必须马上完成，哪些缺陷是可以暂时缓一缓，这样也就不会被堆积如山的缺陷所压垮，测试效率自然也会得到很大的提高。