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

试述软件缺陷的严重性与优先级 摘 要：严重性和优先级是软件缺陷的两个重要属性，在软件测试过程中如果对两者的概念、划分方法和关联性理解的不够准确，不但对缺陷的统计结果、缺陷报告的质量造成影响，而且还会延误软件的正常发布期限。本文就如何正确区分和处理缺陷的严重性和优先级展开讨论，旨在提高软件质量、降低研发风险。 关键词：软件测试；缺陷；严重性；优先级 缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大小，这种破坏既包括缺陷对被测系统的影响程度，也包括缺陷妨碍系统使用的程度。在软件测试中，判断缺陷的严重性应该从软件最终用户的角度出发，评估缺陷给用户造成的恶劣后果和产生的损失。 缺陷的优先级是指处理和修正软件缺陷先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，不纯粹是技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。 1 四种错误和轻重缓急 1.1 判断缺陷的4种错误 正确处理和区分缺陷的严重性和优先级，是包括软件测试人员和开发人员在内的全体项目组成员的一件大事，对于经验不很丰富的项目组成员来说，经常会犯下述4种错误： ①把低严重性的缺陷当作高严重性来处理。 ②把高严重性的缺陷当作低严重性来处理。 ③把低优先级的缺陷当作高优先级来处理。 ④把高优先级的缺陷当作低优先级来处理。 在此，可以将这4种错误归结为2类，在测试工作中，犯了前2种错误说明在缺陷的判断上“不分轻重”，出现后2种错误则表示在缺陷的判断上“不分缓急”。如果要在测试工作中准确判断缺陷的严重性与优先级，应该合理区分轻重缓急，这既是保证软件质量的重要环节，也是项目组成员能力与经验的最好体现。 1.2 何为缺陷的轻重缓急 现代管理学之父彼得?德鲁克说过：“做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。”。测试工作也正是如此，要避免在缺陷的严重性和优先级上判断失误，必须分清缺陷的轻重缓急。 “轻”，指的是相对重要但不紧急的缺陷；“重”，是指最重要也是最紧急的缺陷；“缓”，指的是不重要也不紧急的缺陷；“急”，则是指不是最重要但却最为紧急的缺陷。理清这种关系之后，就算同时测试许多不同类型的缺陷，也会很快弄清楚哪些缺陷是必须马上完成的，哪些缺陷可以暂时缓一缓，这样也就不会被堆积如山的Bug所压垮，缺陷修复和回归测试的效率自然也会得到很大的提高。当然，要做到这一点必须明白严重性与优先级的等级划分和其间的关联性，并借助相关的评估技术工具才能实现。 2 如何划分严重性和优先级的等级 将缺陷的严重性和优先级作等级分类，对于IT企业来说是一项非常重要的任务，因为有了等级分类才能协调企业各部门处理事务的排程。销售、客服和项目经理都需要知道缺陷发生时对交货期的影响，QA也需要知道软件目前的品质状况。 确定严重性和优先级的等级必须全面了解和深刻的体会缺陷的特征，要从用户和开发人员以及市场等因素综合考虑。从项目组分工来看，应由软件测试人员确定缺陷的严重性，由软件开发人员确定缺陷的优先级。往往在实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。 2.1 缺陷的严重性级别划分 缺陷的严重性和优先级通常按照级别划分，不同的公司或不同的项目组有各自具体表示方式。根据CMMI5中的定义规范，缺陷严重等级可分为3到5个等级，所以笔者对于缺陷严重程度的划分也分为5个等级。1为最严重，依次递降。 2.2 缺陷的优先级划分 对于缺陷的优先级分类在业界尚无统一的划分规范。一般来说，如果分级超过4级，则会使分类的判断尺度变得复杂，而少于4级，则无法保证分类的精确性。所以笔者通常将优先级分为4级。1为最紧急，依次递降。 3 严重性与优先级的关联性 缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。 一般情况下，缺陷的严重性和优先级之间是存在密切关联的，即严重性越高，处理优先级别越高。然而，严重性和优先级并不总是一一对应的。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。举例说明如下。 3.1 高严重性，低优先级 当某个Bug的发生概率非常低（如执行测试用例出现该缺陷的几率低于5%），或仅在极端条件下才引发该缺陷时，可能将其优先级定得很低。这里其实包含了一个风险评估的思想，当缺陷具有高严重性时，缺陷对系统造成的破坏力是很强的，但因为发生概率很低，开发方会认为该缺陷被用户发现的概率非常低，在产品遇到发布压力的时候，开发方会选择将缺陷留在下一个发布版本之前再进行修复。例如，“当上传附件超过50G时，传输过程中出现网站