缺陷生命周期(3)

　　重复(Duplicated)：缺陷评审委员会认为该缺陷和某个已经提交的缺陷描述的是同一个问题，可以将该缺陷状态设置为重复。

　　延期(Deferred)：缺陷不在当前版本解决。

　　无计划(Unplanned)：在用户需求中没有要求或计划。

　　(3)严重程度

　　缺陷的严重程度指的是假如缺陷没有修复时，软件缺陷对软件质量的破坏程度，即此软件缺陷的存在对软件功能特性和非功能特性产生的影响。缺陷的严重程度关注的是缺陷引发的问题对客户的影响程度。在给缺陷确定严重程度的时候，应该从软件最终用户的角度进行判断，即根据缺陷会对用户使用造成的影响程度来确定。软件缺陷的严重程度和缺陷发生的可能性没有直接的关系。一般而言，缺陷的影响越大，缺陷的严重程度越高。下面是该项目的缺陷严重程度的分类，缺陷的严重程度被分为四个等级。

　　严重程度1(致命的)：产品在正常的运行环境下无法给用户提供服务，并且没有其他的工作方式可以补救;或者软件失效会造成人身伤害或危及人身安全，例如：

　　问题会自发地影响系统的数据传输。

　　用户使用正常的操作步骤就会影响系统提供的服务。

　　软件的操作系统崩溃，造成数据丢失。

　　无法提供系统的主要功能。

　　可能会造成人身伤害。

　　严重程度2(严重的)：极大地影响系统提供给用户的服务，或者严重影响系统要求或者基本功能的实现，例如：

　　系统中的一些硬件单板会自动重启，但没有影响它们所提供的传输性能。

　　用户使用正常的命令会导致系统重启或挂起，但不影响系统的数据传输。

　　软件的某个子菜单不起作用，或者会产生错误的结果。

　　严重程度3(一般的)：系统功能需要增强或存在缺陷，但有相应的补救方法解决这个缺陷，例如：

　　系统的一块硬件单板失效了，但系统没有上报相应的告警。

　　功能特征设计不符合系统的需求，不影响系统的业务，并且有相应的补救方法。

　　本地化软件的某些字符没有翻译或者翻译错误。

　　严重程度4(轻微的)：细小的问题，不需要补救方法或对功能进行增强;或者操作不方便，容易使用户误操作，例如：

　　上报的信息不符合系统的需求，描述不精确或可能对用户有些误导。

　　GUI界面问题，不精确或可能产生歧义。

　　(4)优先级

　　优先级是处理软件缺陷的先后顺序的指标。确定缺陷的优先级更多的是站在软件开发和软件测试的角度来进行考虑。确定缺陷的优先级有时候可能并不是纯技术的问题，还需要考虑修复缺陷的难度和存在的风险，因此，缺陷优先级的确定是一个复杂的过程。同时，优先级的确定也需要考虑缺陷发生的频率和对目标用户的影响。该项目中，缺陷的优先级被分为四个等级：

　　优先级1(立即)：用户的业务或工作过程受阻，或运行中的测试无法继续。该问题需要立即修复，或必要的话采取临时措施(如：打补丁的方式)。

　　优先级2(下次发布)：在下次常规的产品发布或下次(内部)测试对象版本交付时实施修正。

　　优先级3(必要时)：在受影响的系统部件应当进行修订时进行修正。

　　优先级4(未决)：尚无修正计划。

　　缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同方面描述了软件缺陷对软件质量、用户、开发过程的影响程度和处理方式。一般来说，严重程度高的缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件的瑕疵，可以稍后处理。但是优先级和严重程度并不总是一一对应的，也存在优先级低但严重程度高的缺陷，或者优先级高但严重程度低的软件缺陷。

　　修改软件缺陷并不是纯技术的问题，有时候需要考虑软件版本发布和质量风险等因素。下面是关于缺陷严重程度和优先级设置方面的一些建议：

　　如果某个严重的缺陷只在非常极端的条件下产生，则可以将缺陷的优先级设置得比较低。

　　如果修正一个软件缺陷需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且市场要求尽快发布软件版本，那么即使这个缺陷严重程度很高，也需要仔细考虑是否需要修改。

原文转自：http://www.uml.org.cn/Test/201405223.asp