缺陷级别定义和优先级定义
软件缺陷
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
常用的软件缺陷的优先级表示方法可分为：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。
软件缺陷的三种基本状态：
（1）激活状态(Active或
Open)。
（2）已修正状态(Fixed或Resolved)。
（3）关闭或非激活状态(Close或Inactive)。
三、软件缺陷分析产生原因及分类
（6）软件实现了需求未提到的功能。
二、软件缺陷的级别、优先级及状态
软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。
A类—致命的软件缺陷(Fatal): 造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
（1）20/80原则
管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些软件缺陷是最重要的，哪些软件缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则---分清轻重缓急，把测试活动用在最有生产力的事情上。
bug严重性和优先级的定义
BUG定义Building 7, 439 Chun Xiao Road Zhangjiang High Technology Park Shanghai, China 201203 Tel: +86-21-50803377 Fax: +86-21-50275100 一.严重性分类●Critical1．系统上电后，播放Video文件就会无声音/无图象/死机/花屏/黑屏/严重打顿/马赛克的现象。
2．系统上电后，播放Audio文件时出现无声音/噪声/爆音，声音失真现象，声音打顿。
3．系统上电后，播放Picture会出现花屏，图片显示不完整，或图片颜色失真。
4．在播放时操作遥控器无响应的现象。
5．不能识别设备/热插拔死机现象。
6．通过设备不能播放VIDEO/MUSIC/JPEG文件。
7．播放VIDEO文件时声音和图像不同步。
8．不能连接AP，连接AP/Server时死机。
9．不能连接BT设备，连接时出现死机现象。
10．平台连PC后不能识别平台上的Memory Card和Nand。
11．拷贝/删除/打印过程中出现死机现象。
12．OSD/ICON刷新过程中或刷新后死机。
13．无法升级或升级死机,或升完级无法正常工作。
14．煲机死机。
●Major1．播放单个文件时出现死机/黑屏/花屏等现象。
2．个别的卡和USB设备不能识别的问题。
3．个别的蓝牙手机连接的兼容性问题。
4．Wifi平台连接个别AP或多个Wifi平台连到一个AP上出现的问题。
5．在多个卡槽上同时插卡或USB口同时都插上USB设备，相互影响后一部分设备不能识别，或文件列表显示乱码。
6．打印机连接平台后不识别。
7．文件系统的问题（如长文件名或繁体中文的文件名的文件可以识别但不能播放）8．播放中出现图像和声音干扰。
9．无开机画面或开机画面错误。
10．开机画面显示时间大于10S。
11．开机画面彩色明显失真。
12．开机画面与正常机比较明显偏亮或过暗。
13．开机画面残缺不全或画面上有干扰亮点、亮条、亮纹或其它干扰缺陷。
缺陷BUG等级定义？都分为那些级别
缺陷BUG等级定义？都分为那些级别缺陷等级等级名称等级定义P1 严重缺陷应⽤系统崩溃或系统资源使⽤严重不⾜：1、系统停机（含软件、硬件）或⾮法退出，且⽆法通过重启恢复；2、系统死循环；3、数据库发⽣死锁或程序原因导致数据库断连；4、系统关键性能不达标。
5、数据通讯错误或接⼝不通6、错误操作导致程序中断P2 较严重缺陷系统因软件严重缺陷导致下列问题：1、重要交易⽆法正常使⽤、功能不符合⽤户需求；2、重要计算错误；3、业务流程错误或不完整；4、使⽤某交易导致业务数据紊乱或丢失；5、业务数据保存不完整或⽆法保存到数据库。
6、周边接⼝出现故障（需考虑接⼝时效/数量等综合情况）；7、服务程序频繁需要重启（每天2次或以上）；8、批处理报错中断导致业务⽆法正常开展。
9、前端未合理控制并发或连续点击动作，导致后台服务⽆法及时响应。
10、在产品声明⽀持的不同平台下，出现部分重要交易⽆法使⽤或错误。
P3 ⼀般性缺陷系统因软件⼀般缺陷导致下列问题：1、部分交易使⽤存在问题，不影响业务继续开展，但造成使⽤障碍。
2、初始化未满⾜客户要求或初始化错误3、功能点能实现，但结果错误；4、数据长度不⼀致；5、⽆数据有效性检查或检查不合理；6、数据来源不正确；7、显⽰/打印的内容或格式错误；8、删除操作不给提⽰；9、个别交易系统反应时间超出正常合理时间范围10、⽇志记录信息不正确或应记录⽽未记录11、在产品声明⽀持的不同平台下，出现部分⼀般交易⽆法使⽤或错误。
P4 较⼩缺陷系统因软件操作不便⽅⾯缺陷：1、系统某些查询、打印等实时性要求不⾼的辅助功能⽆法正常使⽤；2、界⾯错误3、菜单布局错误或不合理4、焦点控制不合理或不全⾯；5、光标,滚动条定位错误；6、辅助说明描述不准确或不清楚；7、提⽰窗⼝描述不准确或不清楚；8、⽇志信息不够完整或不清晰，影响问题诊断或分析的；P5 其他缺陷系统辅助功能缺陷：1、缺少产品使⽤、帮助⽂档、系统安装或配置⽅⾯需要信息；2、联机帮助、脱机⼿册与实际系统不匹配3、系统版本说明不正确；4、长时间操作未给⽤户进度提⽰；5、提⽰说明未采⽤⾏业规范语⾔；6、显⽰格式不规范7、界⾯不整齐8、软件界⾯、菜单位置、⼯具条位置、相应提⽰不美观，但不影响使⽤P6 建议、优化类建议优化类分享给朋友：。
缺陷等级划分规定
缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。
缺陷的优先级和严重定义性
缺陷的优先级和严重定义性缺陷的优先级和严重性定义我们可以简单地将软件缺陷的严重性划分为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 24hours）：问题导致了中断或者阻止了产品的正常版本编译（Issues that break or prevent aproduct build）问题导致了阻止了BVT和其他测试自动化的运行（Issues that prevent BVTs andother test automation）问题导致了无法成功构建国内和全球文档（Issues that keep production fromsuccessfully 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/maingoals）：高法律风险；地域相关；版权，商标，准许法令（High Legal risk; Geopolitical,Copyright, Trademark, Consent Decree）高风险编码实践（High risk security coding practices）问题导致了对客户和/或本公司的重大影响（Issues with significant impact oncustomers and/or the company）对用户/产品关键的用于描述场景的新文档和/或新特性（New documentation forscenarios and/or new features that are crucial to customers and/or the product）辅助访问主题的元数据的变更；搜索，属性F1和索引问题（Metadata changes to helpaccess topics; search, attributes, F1 and indexing issues）在目标命名空间中的代码样例/代码片段（Code samples/snippets in targetednamespaces）过多从参考文档到概念性文档的引用（More linking of reference docs to conceptualdocs ）在顶层页面/节点发现的问题，例如在首页，门户上发现的问题（Issue found on toplevel pages/node,e.g., homepage, portal）在大标题上存在的问题（Issue appears in a large number of topics through out the docset）技术性的不正确的内容（Technically incorrect content）（3）优先级2（Priority 2）软件缺陷应该被修复（Bugs that should be fixed）：对客户和产品不是那么关键性的场景或者特性（Scenarios or features that are notcrucial to customers or the product）从先前版本来的内容修复（Fixing content from previous releases）非目标命名空间中代码样例/代码片段（Code samples/snippets in non targetednamespaces）在中等级页面/节点中发现的缺陷（Bug found in mid level pages/nodes）在小标题上存在的问题（Bug appears in a significant number of topics through out thedoc set）（4）优先级3（Priority 3）如果修复这个缺陷会比较好（Bugs that would be good to fix）：目录问题（Table of Contents issues）先前版本中未完成的文档（Incomplete documentation from previous releases）重写或重新格式化原本正确的文档，为了让它更清晰，更容易阅读（Rewriting orreformatting correct content to make it clearer, easier to read）在视觉上影响到用户但是但不影响阅读（Issues that visually impacts the customer butwon'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 highlocalization cost versus customer gain）Severity（严重性）与Priority（优先级）之间的区别是什么？软件里的Bug所产生的效果不会自动的与修复它的优先级相关联。
测试文档二 bug严重程度和优先级(缺陷管理)
bug严重级别和优先级别定义Bug严重级别：是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
如下：最高级(1类)-- 致命级别阻止对后续功能的测试，通常适用于以下情况1 模块无法启动或异常退出2界面/功能Crash 导致一系列测试不能运行3严重花屏4数据丢失（用户数据，服务器数据）5系统崩溃/死机/冻结6 业务逻辑错误（数据计算错误：例如支付错误，业务流程缺失或者走错）7功能设计和需求严重不符8服务器400，500等错误9 影响流程问题，升级失败10 业务逻辑流程中断跳转到其他页面次最高级（2类）- 严重级别在当前发布版本中必须修复，即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性1 Bug 的出现导致软件没有完成用户的需求2 系统刷新错误3数值计算错误4影响功能及界面的错误字或拼写错误5 安全性问题6 兼容性问题（用户群体大，影响严重）7 数据不准，建单据报错8 引发性新BUG（说明此单BUG是由于前面修改BUG或做的新需求导致其它模块出现新的错误。
一般（3类）一般级别-- 在时间许可的范围内修复，即界面、性能缺陷1 只有在极端条件下才会重现的Bug2 在特定配置情况下不会出现的Bug3 操作界面错误（包括数据窗口内列名定义、含义是否一致）4 边界条件下错误5 提示信息错误6系统未优化，性能问题7 兼容性问题（有一定用户群体，影响较大）低（4类）轻微-- 不影响当前发布，可以推迟到下一个发布中修复，即易用性及建设性问题1 不能稳定重现的Bug2 因为电脑上装有其他干扰软件产生的Bug3 非功能性Bug, 如日志，错误回复等4 界面规格不规范5 辅助说明描述不清6 操作时未给用户提示信息7 个别不影响产品功能的错别字8 文字排列不整齐9兼容性问题（用户群体不大，影响相对较小）10 错误提示信息不准确有歧义Priority（优先级）1 Immediate（紧急，一类）即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
缺陷等级划分
缺陷严重级别定义:o最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.o紧急---事件非常重要,并且需要马上给予关注.o高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.o低级---事件不重要,可以在时间和资源允许的情况下再解决.o建议性缺陷.更为详细的划分如下:A类——严重错误，包括：o由于程序所引起的死机,非法退出o死循环o导致数据库发生死锁o数据通讯错误o严重的数值计算错误B类——较严重错误，包括：o功能不符o数据流错误o程序接口错误o轻微的数值计算错误C类——一般性错误，包括：o界面错误(详细文档)o打印内容、格式错误o简单的输入限制未放在前台进行控制o删除操作未给出提示D类——较小错误，包括：o辅助说明描述不清楚o显示格式不规范o长时间操作未给用户进度提示o提示窗口文字未采用行业术语o可输入区域和只读区域没有明显的区分标志o系统处理未优化E类——测试建议（非缺陷）软件公司对软件缺陷级别的定义不尽相同，一般可以分为4种：1.致命（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失2.严重（critical）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明3.一般的（major）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等4.微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等Bug严重程度定义：致命(Critical)BUG：测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。
软件缺陷的严重性和优先级
D类——较小错误
1、界面不规范 2、辅助说明描述不清楚 3、输入输出不规范 4、长操作未给用户提示 5、提示窗口文字未采用行业术语 6、可输入区域和只读区域没有明显的区分标 志
软件缺陷的优先级列表
缺陷优先级县级 立即解决 高优先级 正常排队 低优先级 描述 缺陷导致系统几乎不能使用，需立即修复 缺陷严重，影响测试，需优先考虑 缺陷需要正常排队等待修复 缺陷可以在开发人员有时间的时候被纠正
软件缺陷的严重性和优先级
软件缺陷的描述
• 软件缺陷，也就是我们平常在编程过程中遇到的所谓的bug。详细 的说就是导致计算机软件或者程序不能够正常运行的一些语法问 题、符号问题、参数问题、错误或者一些隐藏的功能缺陷。软件 缺陷会导致客户在使用过程中不能实现客户想要完成的功能，所 以在软件测试的过程中，我们要尽早的发现软件的缺陷并竭尽所 能的改善它，使软件变的完美。
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺 陷需要优先修正，哪些缺陷可以稍后修正。
软件缺陷严重性的等级划分
A类——致命错误 B类——严重错误 C类——一般性错误 D类——较小错误
A类——致பைடு நூலகம்错误
1、由于程序所引起的死机，非法退出。 2、死循环 3、数据库发生死锁 4、因错误操作导致的程序中断 5、功能错误 6、与数据库链接错误 7、数据通讯错误
处理严重性和优先级常见的错误
第一、常常将比较轻微的缺陷报告成较为严重的缺陷和 较高的优先级。夸大了缺陷的程度。这样会消耗开发人 员辨别和处理缺陷的时间。 第二、与第一个错误刚好相反，常常把较大的缺陷报告 成较小的缺陷和较低的优先级，这样就掩盖了很多严重 的缺陷，给软件带来很多麻烦，也造成了很多漏网之鱼 。 因此，正确处理和区分缺陷的严重性和优先级，是软件 测试人员和开发人员，以及全体项目组人员的一件大事 。处理严重性和优先级，既是一种经验技术，也是保证 软件质量的重要环节，应该引起足够的重视。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
附件一：缺陷级别定义和优先级定义1、缺陷级别定义
2、缺陷优先级定义
注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high 和view high。
3、缺陷报告规范
✓在项目执行阶段，发现的所有问题都需要提交缺陷管理库－CQ中相应的Project库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等方
面的内容；
✓缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3...形式提交，且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过
于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以
附件形式提交；
✓对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题的严重级别对回归的结果做相应的描述。
●具体的缺陷提交流程如下(针对测试人员)
在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权Rejected/Suspend，同时对于达成共识的Rejected缺陷一定要将意见写入CQ库中的comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间和条件下在处理等信息。
在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在：Closed、经过确认并达成共识的Rejected/Suspend。
4、缺陷跟踪
测试人员对其发现的缺陷有义务和责任进行全程的跟踪。
从缺陷的提交一直到缺陷的关闭，在这一整套的过程中，测试人员应该一丝不苟的进行把关，不要让错
误轻易的从手边遛走。
要定期的向开发组通报缺陷状态，同时及时的更新缺陷库中
缺陷的状态。
在一定的条件和时间内，还要对以关闭的缺陷做回归测试。
制定有效
而可行的回归测试时间表，尽可能的减少由回归测试间隙产生的测试逃逸。
5、缺陷分析
对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布等状态做统计分析。
为开发组提供一些必要的信息。
对测试人员而言，统计包括以下步骤：
✓收集和分类缺陷信息。
✓尝试对每个缺陷的形成原因（例如，不符合规约、设计错误、违背标准、与客户通信不利等）进行追溯。
（此方面的最终定位需要与相关的开发人员进行确
认。
）
✓使用Pareto规则（80％的缺陷的20％成因有可能可以追溯到），将这20％（少数重要的）分离出来。
简单而言，Pareto原则暗示着测试发现的错误中的80%
很可能起源与程序模块中的20％。
当然，问题在于如何孤立这些有疑点的模
块并进行彻底的测试。
✓一旦标出少数几个重要的原因，就可以开始纠正引起缺陷的问题。
（当然这一步是测试人员辅助开发人员进行）
当然以上四点中除了第一第二两点以外，更多的定位应该是开发人员去定位问题，测试人员只需提供辅助信息。
（测试人员应该尽量避免陷入程序调试工作中，这即不高效――肯定没有开发人员专业，也不必要的占用了紧张的测试资源）。