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

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