缺陷级别定义和优先级定义
附件一：缺陷级别定义和优先级定义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％。
当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
✓一旦标出少数几个重要的原因，就可以开始纠正引起缺陷的问题。
（当然这一步是测试人员辅助开发人员进行）
当然以上四点中除了第一第二两点以外，更多的定位应该是开发人员去定位问题，测试人员只需提供辅助信息。
（测试人员应该尽量避免陷入程序调试工作中，这即不高效――肯定没有开发人员专业，也不必要的占用了紧张的测试资源）。
软件缺陷
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等级定义？都分为那些级别缺陷等级等级名称等级定义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),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。