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类型的划分转载⼀严重程度致命：系统⽆法正常运⾏严重：很明显的错误性的bug较重：相对明显的错误性的bug⼀般：常见的bug建议类：（暂时保留，可能去掉）⼆优先级说明：紧急相当于执⾏前的准备⼯作，重要相当于后续的⼯作重要且紧急：优先级最⾼，⼀定要做的重要不紧急：暂时可以先缓⼀缓但⼀定要做的紧急不重要：可以先准备下，随时准备做的不紧急不重要：可忽略不计的三 bug类型：功能错误：功能上的错误性bug代码错误：⼀般很少出现，通常在⾃测时出现（对⽩盒测试、⾃测的⽐较适合）内容相关：业务逻辑⽅⾯以及业务描述等相关问题表单相关：表单逻辑、样式、内容问题⽤户界⾯：UI表现，包括对话框样式和⽂字描述问题需求变动：原有的需求基础上的更改新增需求：会议上提出的新需求，⾮正式会议提出的不属于该项设计⽂档：数据库设计⽂档、概要/详细设计⽂档建议：功能已满⾜但待改善，属于改良性建议配置相关：如web服务器或者数据库服务器配置等问题安装部署：项⽬部署时出现的错误，可能不是程序本⾝的问题⽽是⼯具本⾝和⼈为因素引起安全相关：加密和⽔印等安全信息性能压⼒：负载、压⼒测试标准规范：根据国际标准或者公司内部制定的某标准测试脚本：如⽤⼯具LR编写并执⾏脚本进⾏测试事务跟踪：产品缺陷/bug跟踪（Defect/bug Tracking）⼯作任务跟踪（Task Tracking）问题解决过程跟踪（Problem Tracking）产品需求管理（Request Management）客户服务过程跟踪（Customer Support TrackingBad Case：和⽤例没有关联起来，所以暂时不⽤其他：尽量避免⽤该项，不便于统计但仍保留。

BUG严重等级和优先级区别一、 Bug的严重等级定义：1、 Blocker即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

•严重花屏•内存泄漏•用户数据丢失或破坏•系统崩溃/死机/冻结•模块无法启动或异常退出•严重的数值计算错误•功能设计与需求严重不符•其它导致无法测试的错误, 如服务器500错误2、 Critical 即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

•功能未实现•功能错误•系统刷新错误•数据通讯错误•轻微的数值计算错误•影响功能及界面的错误字或拼写错误•安全性问题3、Major 即界面、性能缺陷、兼容性。

•操作界面错误（包括数据窗口内列名定义、含义是否一致）•边界条件下错误•提示信息错误（包括未给出信息、信息提示错误等）•长时间操作无进度提示•系统未优化（性能问题）•光标跳转设置不好，鼠标（光标）定位错误•兼容性问题4、 Minor 即易用性及建议性问题。

•界面格式等不规范•辅助说明描述不清楚•操作时未给用户提示•可输入区域和只读区域没有明显的区分标志•个别不影响产品理解的错别字•文字排列不整齐等一些小问题二、 Bug的优先等级1. Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

2. Urgent即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

3. High即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。

4. Normal即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。

5. Low即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

备注：严重性和优先级并不总是一一对应。

有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

BUG类型缺陷
S级bug，优先级最高
致命缺陷：
1、代码存在巨大缺陷（代码结构有巨大问题）
2、数据库存在巨大隐患（如恶意攻击造成的账户私密信息泄露）
3、充值存在问题（如金钱计算错误、充值不到账）
4、具体功能未实现
5、系统不稳定等（如常规操作会引发系统崩溃、死机、死循环）
A级bug，优先级次高
严重缺陷：
1、重要功能未实现（例如：更新的功能为实现，功能设计与需求严重不符）
2、功能操作影响多个其他功能
3、代码有错误（非常规操作会导致的崩溃、死机、死循环等）
4、UI界面存在影响功能实现的问题（封面图片的失真、压缩、完全变形等）
5、前端的安全问题等（密码明文显示等）
B级bug，优先级一般
一般缺陷：
1、次要功能不能正常实现
2、操作UI显示错误（增删改查等）
3、部分操作未给出提示（例如：删除、修改等）
4、UI兼容性问题等
建议修改类型缺陷
优化建议，优先级最低（建议修改）
程序在一些显示上不美观，不符合用户习惯，用户体验不佳或者是一些文字的错误
1、界面格数等不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误等等
需求
测试过程中发现的一些为实现功能，但不属于本次版本内容，下个版本增加的内容，缺陷记录为：需求。

缺陷的优先级和严重定义性缺陷的优先级和严重性定义我们可以简单地将软件缺陷的严重性划分为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相对于其他BUG对于公司的影响，解决的及时性。

分类标准紧急² 系统⽆法⼯作² 测试⽆法继续正常⼯作² 特殊情况：如重要客户（项⽬重要性）⾼² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 关联性错误² 前后模块不⼀致² 链接错误² 特殊性的程度性能低下² 程序引起的安全问题注：涉及所有关于数据流的错误中² 页⾯格式错误² 兼容性问题² 校检错误² 图⽚错误² ⽂案错误² 程序性能低下² 缺少容错性处理² 功能易⽤程度低² 配置问题注：涉及的所有关于⽂本的错误低² 遗留问题² 暂时⽆法实现技术问题² 合理建议依据严重程度分类标准定义严重程度：指⼀个BUG对于⽤户造成的影响，风险和可视性。

分类标准紧急² 程序⽆法运⾏的错误² 测试⽆法执⾏的错误⾮常⾼² 链接错误² 前后模块不⼀致² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 程序性能低下² 程序引起的安全问题⾼² 页⾯格式错误² ⽂案错误² 图⽚错误² 兼容性错误² 校检错误中² 关联性错误² 配置问题² 功能易⽤程度低低² 合理建议² 遗留问题² 暂时⽆法实现技术问题注意事项1) ⼀些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。

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（紧急，一类）即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

bug优先级定义标准Bug优先级定义标准是一个用于确定和组织软件缺陷修复顺序的系统。

这个标准可以根据缺陷的严重程度、影响范围和紧急性进行评估和排序。

通过定义和遵循一套统一的标准，团队可以更好地管理和解决各种缺陷，确保关键问题得到及时解决，同时也能够更好地分配资源和时间。

一般来说，一个完善的Bug优先级定义标准应包括以下几个关键要素：1. 严重程度（Severity）：指的是缺陷对系统功能或性能的重大影响程度。

常见的严重程度分级可以是致命（Critical）、严重（Major）、一般（Minor）和轻微（Trivial）等。

这些级别通常是根据缺陷对用户体验、系统稳定性和关键功能的影响程度来定义的。

2. 优先级（Priority）：指的是修复该缺陷的紧急程度。

通常使用高、中、低等级别来表示。

优先级的确定可以考虑到缺陷对用户的影响、缺陷的复现频率、工作量以及项目进度等因素。

3. 影响范围（Impact）：指的是缺陷对系统其他功能或模块的影响程度。

评估缺陷的影响范围可以帮助团队更好地理解和评估修复该缺陷的优先级。

4. 复现频率（Reproducibility）：缺陷的复现频率可以作为评估优先级的参考因素之一。

如果一个缺陷容易被复现，可能会被赋予更高的优先级，因为它对用户和系统的影响更大。

5. 解决时限（Deadlines）：指定某些缺陷需要在特定时间内得到解决的情况。

根据项目的需求和进度，团队可以设定不同的修复时限来确定优先级。

通过以上要素的评估和综合考虑，团队可以为每个缺陷确定一个准确的优先级，从而能够更好地管理和解决系统中的问题。

举个例子，假设有一个软件中存在一个导致系统崩溃的缺陷，这个缺陷导致用户无法完成关键操作。

在这种情况下，这个缺陷在严重程度上应该被定义为致命（Critical），因为它会导致系统不可用，直接影响用户体验和业务流程。

在优先级上，这个缺陷应该被赋予高优先级，尽快解决并发布修复版本。