论文部分内容阅读
摘 要：严重性和优先级是软件缺陷的两个重要属性，在软件测试过程中如果对两者的概念、划分方法和关联性理解的不够准确，不但对缺陷的统计结果、缺陷报告的质量造成影响，而且还会延误软件的正常发布期限。本文就如何正确区分和处理缺陷的严重性和优先级展开讨论，旨在提高软件质量、降低研发风险。
关键词：软件测试；缺陷；严重性；优先级
缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大小，这种破坏既包括缺陷对被测系统的影响程度，也包括缺陷妨碍系统使用的程度。在软件测试中，判断缺陷的严重性应该从软件最终用户的角度出发，评估缺陷给用户造成的恶劣后果和产生的损失。
缺陷的优先级是指处理和修正软件缺陷先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，不纯粹是技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
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时，传输过程中出现网站崩溃现象”。从在传输过程中出现网站崩溃的现象上看，这是一个严重级别最高的Bug，但触发它的条件是用户上传了一个超过50G的附件。通常，在实际应用中很少有用户会去刻意上传一个超过50G的文件，这种极端特殊事件发生概率是相当低的。当一个软件版本即将发布，而又来不及修改时，可把这个Bug设成低优先级，留到下一次版本发布前修改掉。
3.2 低严重性，高优先级
这类Bug通常是一些界面或文字上的问题。例如，“网站主页上的软件Logo中出现错别字”。对于这类缺陷，为何要优先处理呢？因为这类缺陷看似“微小”，但直接关系到产品和公司的形象，你无法想象一款苹果公司的产品上出现微软的标志，这对于任何企业而言都是无法接受的，必须立即修复。实际上，这种缺陷也能很快地被修复。 4 严重性与优先级的评估技术工具
正确评估和区分缺陷的严重性和优先级，既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该引起测试人员和开发人员以及全体项目组人员的足够重视。这里介绍三种常用的技术工具供大家参考。
4.1 80/20法则
意大利经济学家柏拉图提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，把那些最严重、最紧急的Bug归在20%里的缺陷集里，项目组应投入80%精力修复这些Bug。这样就不会拣了芝麻，丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，把测试活动用在最有生产力的事情上。
4.2 ABC法则
ABC法则是设定缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类缺陷作为测试最重要的、最有价值的、最关键的缺陷，并保证首先把A类缺陷先处理。其次是B类，然后是C类，还有其它一些不紧急也不重要的缺陷可以不处理或延后处理。因此，应用ABC方法可更明确地确定各项测试目标，当然也能更明确的设定缺陷的优先级。
5 结语
通过上述案例的阐述，可以得知修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果软件缺陷的严重性很低，如界面文字拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
为了保证报告缺陷的严重性和优先级的一致性，QA需要经常检查测试和开发人员对于这两个指标的分配和处理情况，及时发现问题，及时反馈给项目负责人，尽早解决问题。
当然，比较规范的软件测试，还需要使用软件缺陷管理工具（如Bugzilla、Quality Center等）进行缺陷报告和处理，开始使用前应对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。在测试项目进行过程中，充分利用评估技术法则统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度；统计优先级的分布情况，控制开发进度，尽快处理缺陷，使开发按照项目进度有效进行，从而达到提高软件的质量、降低风险与成本的目的。
[参考文献]
[1]张海藩，倪宁.《软件工程（第三版）》（M）.人民邮电出版社，2012.
[2]武剑洁，陈传波，肖来元.《软件测试技术基础》（M）.华中科技大学出版社，2008.
[3]朱少民.《全程软件测试》（M）.电子工业出版社，2007.
关键词：软件测试；缺陷；严重性；优先级
缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大小，这种破坏既包括缺陷对被测系统的影响程度，也包括缺陷妨碍系统使用的程度。在软件测试中，判断缺陷的严重性应该从软件最终用户的角度出发，评估缺陷给用户造成的恶劣后果和产生的损失。
缺陷的优先级是指处理和修正软件缺陷先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，不纯粹是技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
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时，传输过程中出现网站崩溃现象”。从在传输过程中出现网站崩溃的现象上看，这是一个严重级别最高的Bug，但触发它的条件是用户上传了一个超过50G的附件。通常，在实际应用中很少有用户会去刻意上传一个超过50G的文件，这种极端特殊事件发生概率是相当低的。当一个软件版本即将发布，而又来不及修改时，可把这个Bug设成低优先级，留到下一次版本发布前修改掉。
3.2 低严重性，高优先级
这类Bug通常是一些界面或文字上的问题。例如，“网站主页上的软件Logo中出现错别字”。对于这类缺陷，为何要优先处理呢？因为这类缺陷看似“微小”，但直接关系到产品和公司的形象，你无法想象一款苹果公司的产品上出现微软的标志，这对于任何企业而言都是无法接受的，必须立即修复。实际上，这种缺陷也能很快地被修复。 4 严重性与优先级的评估技术工具
正确评估和区分缺陷的严重性和优先级，既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该引起测试人员和开发人员以及全体项目组人员的足够重视。这里介绍三种常用的技术工具供大家参考。
4.1 80/20法则
意大利经济学家柏拉图提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，把那些最严重、最紧急的Bug归在20%里的缺陷集里，项目组应投入80%精力修复这些Bug。这样就不会拣了芝麻，丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，把测试活动用在最有生产力的事情上。
4.2 ABC法则
ABC法则是设定缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类缺陷作为测试最重要的、最有价值的、最关键的缺陷，并保证首先把A类缺陷先处理。其次是B类，然后是C类，还有其它一些不紧急也不重要的缺陷可以不处理或延后处理。因此，应用ABC方法可更明确地确定各项测试目标，当然也能更明确的设定缺陷的优先级。
5 结语
通过上述案例的阐述，可以得知修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果软件缺陷的严重性很低，如界面文字拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
为了保证报告缺陷的严重性和优先级的一致性，QA需要经常检查测试和开发人员对于这两个指标的分配和处理情况，及时发现问题，及时反馈给项目负责人，尽早解决问题。
当然，比较规范的软件测试，还需要使用软件缺陷管理工具（如Bugzilla、Quality Center等）进行缺陷报告和处理，开始使用前应对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。在测试项目进行过程中，充分利用评估技术法则统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度；统计优先级的分布情况，控制开发进度，尽快处理缺陷，使开发按照项目进度有效进行，从而达到提高软件的质量、降低风险与成本的目的。
[参考文献]
[1]张海藩，倪宁.《软件工程（第三版）》（M）.人民邮电出版社，2012.
[2]武剑洁，陈传波，肖来元.《软件测试技术基础》（M）.华中科技大学出版社，2008.
[3]朱少民.《全程软件测试》（M）.电子工业出版社，2007.