缺陷的优先级和严重定义性

缺陷的优先级和严重性定义

我们可以简单地将软件缺陷的严重性划分为4个等级，如表11-1所示。

1.严重性（Severity）

严重性说明

1 严重缺陷。系统无法满足基本的商业要求且没有便捷可用的工作区。性能、功能或使用方面严重不达标

2 一般缺陷。系统能够满足商业要求。有快捷方便的工作区可供使用。性能、功能或使用方面并不是严重不达标

3 微小缺陷。微小修改，希望提出建议，最好能够修正，但不是必需的。在发布准确性或实用性方面不会产生重大影响

2．优先级（Priority）

小组中使用的主观对任务和工作项排定优先次序评级。与严重性结合在一起来评定可见度、变更、风险修复等。（A "subjective" rating used by groups to prioritize tasks and work items.

A combination of Severity with the visibility, workarounds, fix risk, etc... subjective importance）（1）优先级0（Priority 0）

⏹这类软件缺陷必须在24小时之内被解决（These bugs need to be resolved within 24

hours）：

⏹问题导致了中断或者阻止了产品的正常版本编译（Issues that break or prevent a

product build）

⏹问题导致了阻止了BVT和其他测试自动化的运行（Issues that prevent BVTs and

other test automation）

⏹问题导致了无法成功构建国内和全球文档（Issues that keep production from

successfully building Domestic and International Doc Builds）

⏹由于粗心丢失内容，如文档文件、命名空间（Unintentionally dropped out content, e.g.

doc file, namespace）

（2）优先级1（Priority 1）

⏹这类软件缺陷必须修复然后才能发布产品或者才能达到用户体验所包含的最主要

目标（Bugs that must be fixed in order to ship the product or achieve UE's top/main

goals）：

⏹高法律风险；地域相关；版权，商标，准许法令（High Legal risk; Geopolitical,

Copyright, Trademark, Consent Decree）

⏹高风险编码实践（High risk security coding practices）

⏹问题导致了对客户和/或本公司的重大影响（Issues with significant impact on

customers and/or the company）

⏹对用户/产品关键的用于描述场景的新文档和/或新特性（New documentation for

scenarios and/or new features that are crucial to customers and/or the product）

⏹辅助访问主题的元数据的变更；搜索，属性F1和索引问题（Metadata changes to help

access topics; search, attributes, F1 and indexing issues）

⏹在目标命名空间中的代码样例/代码片段（Code samples/snippets in targeted

namespaces）

⏹过多从参考文档到概念性文档的引用（More linking of reference docs to conceptual

docs ）

⏹在顶层页面/节点发现的问题，例如在首页，门户上发现的问题（Issue found on top

level pages/node,e.g., homepage, portal）

⏹在大标题上存在的问题（Issue appears in a large number of topics through out the doc

set）

⏹技术性的不正确的内容（Technically incorrect content）

（3）优先级2（Priority 2）

⏹软件缺陷应该被修复（Bugs that should be fixed）：

⏹对客户和产品不是那么关键性的场景或者特性（Scenarios or features that are not

crucial to customers or the product）

⏹从先前版本来的内容修复（Fixing content from previous releases）

⏹非目标命名空间中代码样例/代码片段（Code samples/snippets in non targeted

namespaces）

⏹在中等级页面/节点中发现的缺陷（Bug found in mid level pages/nodes）

⏹在小标题上存在的问题（Bug appears in a significant number of topics through out the

doc set）

（4）优先级3（Priority 3）

⏹如果修复这个缺陷会比较好（Bugs that would be good to fix）：

⏹目录问题（Table of Contents issues）

⏹先前版本中未完成的文档（Incomplete documentation from previous releases）

⏹重写或重新格式化原本正确的文档，为了让它更清晰，更容易阅读（Rewriting or

reformatting correct content to make it clearer, easier to read）

⏹在视觉上影响到用户但是但不影响阅读（Issues that visually impacts the customer but

won't affect the readability or use of the topic）

⏹最佳实践修复（Best practice fixes）

⏹代码样例/代码片段（Code samples/snippets）

⏹在低级的页面中/节点中发现的问题（Issues found in low level pages/nodes）

⏹被阅读很少的主题（Issues found in a small number of topics）

（5）优先级4（Priority 4）

⏹如果修复这个缺陷我们的工作就算是达到精细的程度，这种问题比较细小，可以被推迟

处理（Bugs that would be nice to fix, are trivial and can be postponed）：

⏹在文档中藏得比较深的问题（Issues buried in the docs）

⏹仅在一个话题中有的问题（Issues found in only one topic ）

⏹对用户影响比较小的问题（Issues with low to no customer impact）

⏹如果要修复这个问题导致的本地化的投入要比对用户的获益高得多（Issues with a high

localization cost versus customer gain）

⏹Severity（严重性）与Priority（优先级）之间的区别是什么？

⏹软件里的Bug所产生的效果不会自动的与修复它的优先级相关联。一个严重的Bug可

能是那种对1%的用户来说也是不太会发生的使软件崩溃的bug。那它的优先级也比那些误操作导致的需要对每个用户每次需要重新键入一部分输入的Bug的优先级要低。

⏹因此：需要分别跟踪Bug优先级和严重性，然后进行适当的修复。Bug的重要性是由