试述软件缺陷的严重性与优先级

1、试述软件缺陷的严重性与优先级缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大 小，这种破坏既包括缺陷对被测系统的影响程度， 也包括缺陷妨 碍系统使用的程度。 在软件测试中， 判断缺陷的严重性应该从软 件最终用户的角度出发， 评估缺陷给用户造成的恶劣后果和产生 的损失。缺陷的优先级是指处理和修正软件缺陷先后顺序的指标， 即 哪些缺陷需要优先修正， 哪些缺陷可以稍后修正。 确定软件缺陷 优先级， 更多的是站在软件开发工程师的角度考虑问题， 因为缺 陷的修正顺序是个复杂的过程， 不纯粹是技术问题， 而且开发人 员更熟悉软件代码， 能够比测试工程师更清楚修正缺陷的难度和 风险。1 四种错误和轻重缓急

2、1.1 判断缺陷的 4 种错误正确处理和区分缺陷的严重性和优先级， 是包括软件测试人 员和开发人员在内的全体项目组成员的一件大事， 对于经验不很 丰富的项目组成员来说，经常会犯下述 4 种错误： 把低严重性的缺陷当作高严重性来处理。 把高严重性的缺陷当作低严重性来处理。 把低优先级的缺陷当作高优先级来处理。 把高优先级的缺陷当作低优先级来处理。在此，可以将这 4 种错误归结为 2 类，在测试工作中，犯了 前 2 种错误说明在缺陷的判断上“不分轻重”， 出现后 2 种错误 则表示在缺陷的判断上“不分缓急”。 如果要在测试工作中准确 判断缺陷的严重性与优先级， 应该合理区分轻重缓急， 这既是保 证

3、软件质量的重要环节，也是项目组成员能力与经验的最好体 现。1.2 何为缺陷的轻重缓急 现代管理学之父彼得 ?德鲁克说过：“做事情必须分清轻重 缓急。最糟糕的是什么事都做，这必将一事无成。”。测试工作 也正是如此， 要避免在缺陷的严重性和优先级上判断失误， 必须 分清缺陷的轻重缓急。“轻”，指的是相对重要但不紧急的缺陷；“重”，是指最 重要也是最紧急的缺陷； “缓”，指的是不重要也不紧急的缺陷； “急”， 则是指不是最重要但却最为紧急的缺陷。 理清这种关系 之后，就算同时测试许多不同类型的缺陷， 也会很快弄清楚哪些 缺陷是必须马上完成的， 哪些缺陷可以暂时缓一缓， 这样也就不 会被堆积如山的 B

4、ug 所压垮，缺陷修复和回归测试的效率自然也 会得到很大的提高。 当然，要做到这一点必须明白严重性与优先 级的等级划分和其间的关联性， 并借助相关的评估技术工具才能 实现。2 如何划分严重性和优先级的等级 将缺陷的严重性和优先级作等级分类，对于 IT 企业来说是 一项非常重要的任务， 因为有了等级分类才能协调企业各部门处 理事务的排程。 销售、 客服和项目经理都需要知道缺陷发生时对 交货期的影响，QA也需要知道软件目前的品质状况。确定严重性和优先级的等级必须全面了解和深刻的体会缺 陷的特征， 要从用户和开发人员以及市场等因素综合考虑。 从项 目组分工来看， 应由软件测试人员确定缺陷的严重性，

5、由软件开 发人员确定缺陷的优先级。 往往在实际测试中， 通常都是由软件 测试人员在缺陷报告中同时确定严重性和优先级。2.1 缺陷的严重性级别划分 缺陷的严重性和优先级通常按照级别划分， 不同的公司或不同的项目组有各自具体表示方式。 根据CMMI5中的定义规范，缺 陷严重等级可分为 3到 5个等级，所以笔者对于缺陷严重程度的 划分也分为 5 个等级。 1 为最严重，依次递降。2.2 缺陷的优先级划分对于缺陷的优先级分类在业界尚无统一的划分规范。 一般来 说，如果分级超过 4 级，则会使分类的判断尺度变得复杂，而少 于 4 级，则无法保证分类的精确性。 所以笔者通常将优先级分为 4 级。 1 为最

6、紧急，依次递降。3 严重性与优先级的关联性 缺陷的严重性和优先级是含义不同但相互联系密切的两个 概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用 户的影响程度和处理方式。一般情况下，缺陷的严重性和优先级之间是存在密切关联 的，即严重性越高，处理优先级别越高。然而，严重性和优先级 并不总是一一对应的。 有时候严重性高的软件缺陷， 优先级不一 定高，甚至不需要处理， 而一些严重性低的缺陷却需要及时处理， 具有较高的优先级。举例说明如下。3.1 高严重性，低优先级当某个 Bug 的发生概率非常低 （如执行测试用例出现该缺陷 的几率低于 5%），或仅在极端条件下才引发该缺陷时，可能将 其优先级

7、定得很低。 这里其实包含了一个风险评估的思想， 当缺 陷具有高严重性时， 缺陷对系统造成的破坏力是很强的， 但因为 发生概率很低，开发方会认为该缺陷被用户发现的概率非常低， 在产品遇到发布压力的时候， 开发方会选择将缺陷留在下一个发 布版本之前再进行修复。例如，“当上传附件超过50G时，传输过程中出现网站崩溃现象”。 从在传输过程中出现网站崩溃的现 象上看，这是一个严重级别最高的 Bug，但触发它的条件是用户 上传了一个超过50G的附件。通常，在实际应用中很少有用户会 去刻意上传一个超过50G的文件，这种极端特殊事件发生概率是 相当低的。当一个软件版本即将发布，而又来不及修改时，可把 这个Bu

8、g设成低优先级，留到下一次版本发布前修改掉。3.2 低严重性，高优先级这类Bug通常是一些界面或文字上的问题。例如，“网站主 页上的软件Logo中出现错别字”。对于这类缺陷，为何要优先处理呢？因为这类缺陷看似“微小”， 但直接关系到产品和公司 的形象， 你无法想象一款苹果公司的产品上出现微软的标志， 这 对于任何企业而言都是无法接受的，必须立即修复。实际上，这 种缺陷也能很快地被修复。 4 严重性与优先级的评估技术工具正确评估和区分缺陷的严重性和优先级，既是确保测试顺利进行的要求， 也是保证软件质量的重要环节，应该引起测试人员和开发人员以及全体项目组人员的足够重视。这里介绍三种常用的技术工具供

9、大家参考。4.1 80/20 法则意大利经济学家柏拉图提出： 重要的少数与琐碎的多数或称 20/80 的定律。就是 80%的有效工作往往是在 20%的时间内完成 的，而 20%的工作是在 80%的时间内完成的。因此，为了提高测 试质量，把那些最严重、最紧急的 Bug 归在 20%里的缺陷集里， 项目组应投入80%精力修复这些Bug。这样就不会拣了芝麻，丢 了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生 最大的效益，把测试活动用在最有生产力的事情上。4.2 ABC 法则ABC法则是设定缺陷优先顺序重要工具之一。这 ABC工具的 关键点在于根据缺陷的重要程度决定优先顺序， 按需求目标进行

10、 量化规划。把 A 类缺陷作为测试最重要的、最有价值的、最关键 的缺陷，并保证首先把 A类缺陷先处理。其次是 B类，然后是C 类，还有其它一些不紧急也不重要的缺陷可以不处理或延后处 理。因此，应用ABC方法可更明确地确定各项测试目标，当然也 能更明确的设定缺陷的优先级。5 结语通过上述案例的阐述， 可以得知修正软件缺陷不是一件纯技 术问题， 有时需要综合考虑市场发布和质量风险等问题。 如果某 个严重的软件缺陷只在非常极端的条件下产生， 则没有必要马上 解决。另外，如果软件缺陷的严重性很低， 如界面文字拼写错误， 则必须尽快修正，因为这关系到软件和公司的市场形象。为了保证报告缺陷的严重性和优先级的一致性，QA 需要经常检查测试和开发人员对于这两个指标的分配和处理情况， 及时 发现问题，及时反馈给项目负责人，尽早解决问题。当然，比较规范的软件测试， 还需要使用软件缺陷管理工具 （如 Bugzilla 、 Quality Center 等）进行缺陷报告和处理，开 始使用前应对