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

缺陷的优先级和严重性定义我们可以简单地将软件缺陷的严重性划分为4个等级，如表11-1所示。1.严重性（Severity）严重性说明1严重缺陷。系统无法满足基本的商业要求且没有便捷可用的工作区。性能、功能或使用万面严重不达标2一般缺陷。系统能够满足商业要求。有快捷方便的工作区可供使用。性能、功能或使用方面并不是严重不达标3微小缺陷。微小修改，希望提出建议，最好能够修正，但不是必需的。在发布准确性或实用性方面不会产生重大影响2.优先级(Priority)小组中使用的主观对任务和工作项排定优先次序评级。与严重性结合在一起来评定可见度、变更、风险修复等。(A"subjective"ratingusedbygroupstoprioritizetasksandworkitems.AcombinationofSeveritywiththevisibility,workarounds,fixrisk,etc...subjectiveimportance)优先级0(Priority0)这类软件缺陷必须在24小时之内被解决(Thesebugsneedtoberesolvedwithin24hours):问题导致了中断或者阻止了产品的正常版本编译(Issuesthatbreakorpreventaproductbuild)问题导致了阻止了BVT和其他测试自动化的运行(IssuesthatpreventBVTsandothertestautomation)问题导致了无法成功构建国内和全球文档(IssuesthatkeepproductionfromsuccessfullybuildingDomesticandInternationalDocBuilds)由于粗心丢失内容，如文档文件、命名空间(Unintentionallydroppedoutcontent,e.g.docfile,namespace)优先级1(Priority1)这类软件缺陷必须修复然后才能发布产品或者才能达到用户体验所包含的最主要目标(BugsthatmustbefixedinordertoshiptheproductorachieveUE'stop/maingoals)：高法律风险；地域相关；版权，商标，准许法令(HighLegalrisk;Geopolitical,Copyright,Trademark,ConsentDecree)高风险编码实践(Highrisksecuritycodingpractices)问题导致了对客户和/或本公司的重大影响(Issueswithsignificantimpactoncustomersand/orthecompany)对用户/产品关键的用于描述场景的新文档和/或新特性(Newdocumentationforscenariosand/ornewfeaturesthatarecrucialtocustomersand/ortheproduct)辅助访问主题的元数据的变更；搜索，属性F1和索引问题(Metadatachangestohelpaccesstopics;search,attributes,F1andindexingissues)在目标命名空间中的代码样例/代码片段(Codesamples/snippetsintargetednamespaces)过多从参考文档到概念性文档的引用(Morelinkingofreferencedocstoconceptualdocs)在顶层页面/节点发现的问题，例如在首页，门户上发现的问题(Issuefoundontoplevelpages/node,e.g.,homepage,portal)在大标题上存在的问题(Issueappearsinalargenumberoftopicsthroughoutthedocset)技术性的不正确的内容(Technicallyincorrectcontent)优先级2(Priority2)软件缺陷应该被修复(Bugsthatshouldbefixed):对客户和产品不是那么关键性的场景或者特性(Scenariosorfeaturesthatarenotcrucialtocustomersortheproduct)从先前版本来的内容修复(Fixingcontentfrompreviousreleases)非目标命名空间中代码样例/代码片段(Codesamples/snippetsinnontargetednamespaces)在中等级页面/节点中发现的缺陷(Bugfoundinmidlevelpages/nodes)在小标题上存在的问题(Bugappearsinasignificantnumberoftopicsthroughoutthedocset)优先级3(Priority3)如果修复这个缺陷会比较好(Bugsthatwouldbegoodtofix)：目录问题(TableofContentsissues)先前版本中未完成的文档(Incompletedocumentationfrompreviousreleases)重写或重新格式化原本正确的文档，为了让它更清晰，更容易阅读(Rewritingorreformattingcorrectcontenttomakeitclearer,easiertoread)在视觉上影响到用户但是但不影响阅读(Issuesthatvisuallyimpactsthecustomerbutwon'taffectthereadabilityoruseofthetopic)最佳实践修复(Bestpracticefixes)代码样例/代码片段(Codesamples/snippets)在低级的页面中/节点中发现的问题(Issuesfoundinlowlevelpages/nodes)被阅读很少的主题(Issuesfoundinasmallnumberoftopics)优先级4(Priority4)■如果修复这个缺陷我们的工作就算是达到精细的程度，这种问题比较细小，可以被推迟处理(Bugsthatwouldbenicetofix,aretrivialandcanbepostponed)：■在文档中藏得比较深的问题(Issuesburiedinthedocs)■仅在一个话题中有的问题(Issuesfoundinonlyonetopic)■对用户影响比较小的问题(Issueswithlowtonocustomerimpact)■如果要修复这个问题导致的本地化的投入要比对用户的获益高得多(Issueswithahighlocalizationcostversuscustomergain)■Severity(严重性)与Priority(优先级)之间的区别是什么？■软件里的Bug所产生的效果不会自动的与修复它的优先级相关联。一个严重的Bug可能是那种对1%的用户来说也是不太会发生的使软件崩溃的bug。那它的优先级也比那些误操作导致的需要对每个用户每次需要重新键入一部分输入的Bug的优先级要低。■因此：需要分别跟踪Bug优先级和严重性，然后进行适当的修复。Bug的重要性是由项目来决定的，不同于客户对Bug的感知。某些情况下，分别跟踪急迫的或是按照客户观点定义的Bug也是很有意义的。优先级与项目日程相关，严重性与标准相关。优先级表示需要优先考虑和注意的对象;由重要性顺序构建成优先级；严重性暗示需要严格遵照标准或者是高层原则，比如，一个严重的代码行为。优先级和严重性这2个词出现在Bug跟