缺陷级别定义和优先级定义
软件缺陷
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、数据通讯错误
处理严重性和优先级常见的错误
第一、常常将比较轻微的缺陷报告成较为严重的缺陷和 较高的优先级。夸大了缺陷的程度。这样会消耗开发人 员辨别和处理缺陷的时间。 第二、与第一个错误刚好相反，常常把较大的缺陷报告 成较小的缺陷和较低的优先级，这样就掩盖了很多严重 的缺陷，给软件带来很多麻烦，也造成了很多漏网之鱼 。 因此，正确处理和区分缺陷的严重性和优先级，是软件 测试人员和开发人员，以及全体项目组人员的一件大事 。处理严重性和优先级，既是一种经验技术，也是保证 软件质量的重要环节，应该引起足够的重视。
缺陷严重级程度与优先级别
7.负载测试、压力测试结果和用户需求不符
严重
缺陷导致失去系统主要功能,基本功能不能完整使用，例如：
1.功能不符
2.程序接口错误
3.数据流错误
4.轻微数据计算错误等
高
1.快捷方式不正确，如能够回车直接进入下一步的设计成了空格直接进入下一步
2.严重的逻辑错误
3.常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA)
4.常用浏览器不能正常使用（IE6.0/IE7.0/FireFox）浏览页面
7.给客户演示等过程中客户重点指出的，严重级别却不是很高的BUG,建议级别定义至少是非常高
低
1.提示信息不明确，不正确或不合理
2.界面设计存在缺陷、凌乱或不友好
3.整体风格不统一
4.虽有不尽人意之处，但不影响用户操作或用户使用频率较低，并且不会造成错误
5.局部界面不够美观
建议
建议,不影响使用的瑕疵或更好的实现等对软件各方面提出的更好的改进性的意见。
一般
操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现，例如：
1.界面错误（附详细说明）
2.打印内容、格式错误
3.简单的输入限制未放在前台进行控制
4.删除操作未给出提示
5.数据输入没有边界值限定或不合理
中
1.提示信息不明确，并且非常容易误导用户做出错误操作或判断。
2.软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断
3.Cookies没有正常保存
4.服务器和客户端的脚本修改未被记录和
5.非法操作等Urgent程度的bug，如果不具有普遍性而是在极端环境下出现，例如特定的操作环境。建议级别定义为High。
问题严重程度和优先级定义
一、缺陷的等级
缺陷等级主要从两个方便进行划分：缺陷的优先级（p）、缺陷的严重程度（级别） 缺陷的优先级分为四类： 1- Immediate 、2- Urgent 、3- High 、4- Normal 1、Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。 2、Urgent即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。 3、High即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实 现。 4、Normal即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方 面，比如页面调用出错，调用了错误的等。即问题在系统发布以前必须确认解决或确认可以不予解决。 缺陷的严重程度分为四类：1-Blocker、2-Critical、3-Major 、4-Minor 1、 Blocker即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成 系统不稳定。 2、Critical 即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 3、3、 Major 即界面、性能缺陷、兼容性。 4、 Minor 即易用性及建议性问题。
二、严重级别的细化
1-Blocker
严重花屏
2-Critical
功能未实现
3-Mቤተ መጻሕፍቲ ባይዱjor
操作界面错误（包括数据窗 口内列名定义、含义是否一 致）
边界条件下错误 提示信息错误（包括未给出 信息、信息提示错误等） 长时间操作无进度提示 系统未优化（性能问题） 光标跳转设置不好，鼠标 （光标）定位错误
4-Minor
界面格式等不规范
内存泄漏 用户数据丢失或破坏 系统崩溃/死机/冻结 模块无法启动或异常退出 严重的数值计算错误
用英文描述软件bug (defect, 缺陷)++
一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。
机组缺陷分级管理制度
机组缺陷分级管理制度一、前言机组是一个涉及多种设备、工艺和人员协作的综合系统，机组缺陷可能会对设备运行和生产安全造成影响。
因此，建立科学合理的机组缺陷分级管理制度，对于维护设备安全运行，提高生产效率，确保生产安全具有重要意义。
二、机组缺陷的定义机组缺陷是指各种设备设施或环境条件的异常或不正常状态，可能对工艺流程和设备运行产生不利影响的情况。
机组缺陷包括但不限于设备损坏、性能不稳定、工艺参数超标等各种异常情况。
三、机组缺陷的分类机组缺陷可根据其对设备和生产的影响程度进行分类，主要分为三个级别：1. 一级缺陷：一级缺陷是指对设备和生产安全造成重大威胁的缺陷，可能导致事故发生或生产受到严重影响，需要立即处理。
2. 二级缺陷：二级缺陷是指对设备和生产造成一定影响，但不会导致重大事故的缺陷，需要及时处理。
3. 三级缺陷：三级缺陷是指对设备和生产安全影响较小的缺陷，可以在合适的时间进行处理。
四、机组缺陷管理流程1. 缺陷发现：机组缺陷可以由设备操作人员、维修人员、巡检人员或其他相关人员发现。
发现缺陷的人员需要及时向相关负责人报告。
2. 缺陷记录：对于已经发现的缺陷，应当进行详细记录，包括缺陷的具体情况、发现时间、发现人员等信息。
3. 缺陷评估：对于不同级别的缺陷，需要进行评估，确定其对设备和生产的影响程度，以确定处理优先级。
4. 缺陷处理：根据缺陷的级别和影响程度，制定具体的处理方案，并指定负责人进行处理。
一级缺陷需要立即处理，二级缺陷需要在短时间内处理，三级缺陷可以在适当的时间内进行处理。
5. 缺陷跟踪：对于已经处理的缺陷，需要进行跟踪，确保处理效果符合要求，消除后遗症。
6. 缺陷总结：定期对机组缺陷进行统计和总结，分析缺陷的原因和处理情况，提出改进措施，以减少缺陷发生的可能性。
五、机组缺陷管理制度的建立和实施1. 建立机组缺陷管理制度：按照上述机组缺陷管理流程，建立机组缺陷分级管理制度，明确各级缺陷的处理要求和责任。
缺陷级别定义和优先级定义
附件一：缺陷级别定义和优先级定义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、缺陷分析对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布等状态做统计分析。
缺陷等级分类
1.1bug定义表缺陷等级详细含义：一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。
系统崩溃或挂起等导致系统不能继续运行。
包括以下各种错误：1.由于程序所引起的死机,非法退出2.死循环3.数据库发生死锁4.因错误操作导致的程序中断5.重大功能错误6.与数据库连接错误7.数据通讯错误二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。
使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。
包括以下各种错误：1.程序接口错误2.因错误操作迫使程序中断3. 系统可被执行，但操作功能无法执行（含指令）4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的）5. 在功能项的某些项目（选项）使用无效（对系统非致命的）6.业务流程不正确7.功能实现不完整，如删除时没有考虑数据关联8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。
系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。
包括以下各种错误：1.操作界面错误（包括数据窗口内列名定义、含义是否一致）2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）3.简单的输入限制未放在前台进行控制4.删除操作未给出提示5.虽然正确性不受影响，但系统性能和响应时间受到影响6.不能定位焦点或定位有误，影响功能实现7. 显示不正确但输出正确8. 增删改功能，在本界面不能实现，但在另一界面可以补充实现。
四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
bug缺陷严重与优先性定义
bug缺陷严重与优先性定义缺陷严重等级对照表Bug Severity List缺陷状态Status此栏位表明缺陷现在状态，允许值包含：This field in dicates the curre nt bug status. The permissible values in clude:新缺陷：标示一个缺陷状态刚发现。
New: status in dicates a bug that is being reviewed and fixed by developme nt.审核中：标示一个缺陷状态正进行经由审核与修复。
Un der Review: status in dicates a bug that is being reviewed and fixed.测试进行中：标示一个缺陷状态正进行重测，但将花时间或正等待一些标准在重测前。
Test ing In Progress: status in dicates a bug that is being re-tested, but will take time需要重测：标示一个缺陷状态已经修复和正等待重测。
Needs Re-Test: status in dicates a bug that has bee n fixed and is wait ing re-testi ng.重审核：标示一个缺陷状态修复，重测但仍发现有错误。
Re-Review: status in dicates a bug that was fixed, re-tested, and found to still contain the error.关闭：标示一个缺陷状态已经修复，重测和通过确认，缺陷修正。
Closed: status in dicates a bug that has bee n fixed, re-tested and pass verificati on. The bug is fixed.暂时递延：标示一个缺陷状态已经递延到补丁发布等。
缺陷划分规划
缺陷划分规划为了在各项目中后期能对各项目质量做比较全面合理的评估，本次缺陷管理过程中定义了比较充分的质量评估考察点，将缺陷进行了多角度划分，下面将各划分方法一一列出。
1.1缺陷（defect）与错误的严重级别（severity）定义问题性质QC中级别概要描述详细描述致命性问题5-Urgent（紧急）引起系统数据错误、操作不能继续进行、死机、系统崩溃等问题；系统崩溃造成系统宕机应用系统停止工作导致程序异常退出的错误4-Very High（非常高）应用程序不能正常运行\窗口打开异常\死循环\数据被破坏资源泄露严重性明显功能性问题3-High（高）功能不能正常完成或完成有误的问题主要功能未正常实现功能执行错误弹出系统异常告警性问题2-Medium（中）功能完成正常，但由于非正常操作而引起系统提示警告，属于系统健壮性问题；系统容错处理异常输入框没有按照约定进行数据约束窗口没有按照既定规定处理没有合理弹出应用异常处理（正常提示）建议性问题1-Low（低）不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议；界面文字拼音错误；不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议；1.2缺陷（defect）的状态（status）定义优先级别描述New（新建）测试中新报告的软件缺陷Open（打开）被确认并分配给相关开发人员处理Fixed（已修复）开发人员已完成修正，等待测试人员验证Reopen（重新打开）对开发人员已修复的缺陷，经回归测试后发现问题仍然存在Rejected（已否决）拒绝修改此缺陷，但要说明拒绝理由Postponed（延迟修改）不在当前版本修复的错误，下一版修复Closed（已关闭）缺陷已被成功修复1.3缺陷（defect）的优先级（priority）定义优先级别描述5-Urgent（紧急）高优先级，马上响应，对于紧急需要处理的问题。
一般要求2小时内必须要求开发组做出响应。
简述缺陷报告的内容
简述缺陷报告的内容引言缺陷报告是一个项目团队在软件开发或系统维护过程中不可或缺的一部分。
它记录了在软件或系统中发现的缺陷和问题，是团队成员间沟通、解决问题和改进工作的重要依据。
本文将简述缺陷报告的内容，以帮助读者更好地了解和应用缺陷报告。
缺陷报告的基本要素缺陷报告包含了以下几个基本要素：缺陷描述缺陷描述是缺陷报告的核心部分，它详细描述了发现的缺陷或问题。
缺陷描述应该准确、清晰地阐述问题的现象、影响和原因，以便后续团队成员能够快速理解并分析问题。
缺陷描述通常包括以下几个方面的内容：问题现象描述问题在何种情况下出现，例如软件运行的特定场景或用户的操作步骤。
问题影响描述问题对软件或系统的影响，例如导致程序崩溃、功能无法正常使用或性能下降等。
问题原因描述问题产生的原因，可以是程序Bug、设计缺陷、配置错误等。
缺陷分类缺陷分类为问题的归类提供了依据，方便团队成员整理和分析缺陷。
常见的缺陷分类包括功能缺陷、性能缺陷、界面缺陷、安全缺陷等。
对于每个分类，可以再进一步细分为不同的类型，以便更好地归档和处理。
缺陷严重程度缺陷严重程度是指缺陷对软件或系统正常运行的影响程度。
一般可以分为严重、一般和轻微三个级别，也可以根据具体项目的需求定义更多级别。
评估缺陷严重程度时，可以综合考虑缺陷的影响范围、频率、紧急程度等因素。
缺陷优先级缺陷优先级是指解决缺陷的紧迫程度，常常与缺陷严重程度关联。
定义缺陷优先级时，可以考虑到问题的紧急性和重要性，以便合理安排资源、分配工作和制定解决方案的时限。
缺陷状态缺陷状态记录了缺陷在处理过程中的当前状态。
常见的状态有新建、确认、分配、处理中、已解决、已验证等。
通过缺陷状态的记录，可以清楚地了解缺陷的处理进度和处理责任人。
相关附件相关附件可以帮助团队成员更好地了解和分析问题。
附件可以包括日志文件、截图、录像、复现步骤等。
附件的质量和完整性对于排查和解决缺陷非常重要。
缺陷报告的撰写规范为了提高缺陷报告的可读性和可理解性，撰写缺陷报告时需要遵循一定的规范。
软件缺陷 software defect 分类标准
软件缺陷software defect 分类标准软件缺陷(software defect)是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
每一个软件组织都知道必须妥善处理软件中的缺陷。
这是关系到软件组织生存、发展的质量根本。
一、软件缺陷(software defect)分类标准1.1缺陷属性属性名称描述缺陷标识(Identifier)缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识缺陷类型(Type)缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度(Severity)缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级(Priority)缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态(Status)缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源(Origin)缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源(Source)缺陷来源指引起缺陷的起因。
缺陷根源(Root Cause)缺陷根源指发生错误的根本因素。
1.2缺陷类型(Type)缺陷类型编号缺陷类型描述10F-Function影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑，指针，循环，递归，功能等缺陷。
20A-Assignment需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷。
30I-Interface与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40C-Checking提示的错误信息，不适当的数据验证等缺陷。
50B Build/package/merge由于配置库、变更管理或版本控制引起的错误。
60D-Documentation影响发布和维护，包括注释。
70G-Algorithm算法错误。
80U-User Interface人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
缺陷严重级别的定义
个别功能使用不够方便，但是不影响用户使用的问题
1、用户界面不太友好；
2、使用不习惯；
3、好的操作建议等；
BUG优先级
解决时限
说明
P1
最高优先级，BUG必须马上修复
P2
次高优先级，必须马上修复，或在下一版本前修复
P3
按照项目正常进度解决，（建议在下一个Alpha版本前修改）
如果项目一个Build版本与Alpha版本对应，则无区分，按照项目Bug解决计划执行
1、BUG的严重级别表明BUG的破坏和影响程度；
2、BUG的优先级表明BUG解决的紧急程度；
严重级别
状态描述
举 例
Blocks
（致命）
致命错误：
a：导致运行中断(应用程序崩溃)、预期的功能没有得到实现、测试工作无法继续进行等。
b：由于程序引起的非法死机，退出，数据丢失，主要功能完全丧失，系统悬挂等错误。
3、界面显示不美观但对用户不产生影响的问题；
4、不经常出现而且用户可恢复的非严重问题，
5、辅助说明描述不清楚
6、操作时未给用户提示
7、可输入区域和只读区域没有明显的区分标志
8、个别不影响产品理解的错别字
9、文字排列不整齐等一些小问题
Trivial
（建议性）
建议性意见：
从使用者角度，提出的建议性意见。
2、客户环境本身没有问题的情况下，网络不稳，频繁断线，掉线
3、实现的功能与相关需求严重不符，
4、功能未实现
5、功能错误
6、系统刷新错误
7、语音或数据通讯错误
8、轻微的数值计算错误
9、系统所提供的功能或服务受到明显的影响
Major
（一般性错误）
- 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％。
当然，问题在于如何孤立这些有疑点的模
块并进行彻底的测试。
✓一旦标出少数几个重要的原因，就可以开始纠正引起缺陷的问题。
（当然这一步是测试人员辅助开发人员进行）
当然以上四点中除了第一第二两点以外，更多的定位应该是开发人员去定位问题，测试人员只需提供辅助信息。
（测试人员应该尽量避免陷入程序调试工作中，这即不高效――肯定没有开发人员专业，也不必要的占用了紧张的测试资源）。