【缺陷管理】缺陷管理之缺陷的优先级和严重级别 - 翩然雪海间 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
[唐僧团队]
唐僧是一个好领导，他知道孙悟空要管紧，所以要会念紧箍咒；猪八戒小毛病多，但不会犯大错，偶尔批评批评就可以；沙僧则需要经常鼓励一番。这样，一个明星团队就形成了。做测试工作也是这样，一个人强，不代表整个团队都强，团队合作才是根本~誓死把软件测试进行到底!&--&如果您觉得字体比较小的话，请按住键盘上的Ctrl键并滑动鼠标滚轮以改变字体的大小，谢谢！&--&欢迎交流~~~
【缺陷管理】缺陷管理之缺陷的优先级和严重级别
& 15:19:32
/ 个人分类：
&&& 今天看到论坛里一个学员在问“到底应该是谁把状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的来告诉大家“看，老外都是这么做的”。&&&& 我觉得有必要给大家解释透这两个概念，这样不至于在日后的中做错。&&& 以下粉红色部分是对那篇英文的引用，后面则是我的回答（结合的实际例子给大家说明）。QUOTE:原帖由rivermen于
09:12 发表c) The tester then selects the priority of the defect:Critical - fatal errorHigh - require immediate attentionMedium - needs to be resolved as soon as possible but not a showstopperLow - cosmetic error&&&从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。&&& 优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过的工作或者过项目管理的知识。为什么这么说呢？&&& 因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。&&& 一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。&&& 其实，这在微软内部就叫做“基于风险的”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。Bug跟踪过程　 在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：　 1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。　 2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。&&63被浏览13416分享邀请回答61 条评论分享收藏感谢收起41 条评论分享收藏感谢收起查看更多回答Bug重现环境
这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。
这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。
对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。
不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。
其它（这个“其它”非常重要）
对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。
对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。
根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。
JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。）
Bug : 测试过程、维护过程发现影响系统运行的缺陷。（这就是一般测试人员所提交的bug）
New Feature : 对系统提出的新功能。（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。）
Task : 需要完成的一任务。（开发或测试任务指派。）
Improvement : 对现有系统功能的改进。（一般产品经理或产品体验师做的事）
当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。
这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。
下面看一些常见的分类：
划分方式一：
　　* 代码错误
　　* 设计缺陷
　　* 界面优化
　　* 配置相关
　　* 安装部署
* 性能问题
　　* 标准规范
　　* 测试代码
　　* 其它
划分方式二：
　　* 功能类（function）
　　* 性能类（performance）
　　* 界面类（UI）
　　* 易用性类（usability）
　　* 兼容性类（compatibility）
　　* 其它（else）
这个分类当然是可以自定义的，具我接触的缺陷管理都是可以自定义的，既然是对问题的管理，那么你当然可以拿来做特定环境下的系统来使用，或我就想用这个系统来指派任务，那么我的自定义类型为前端任务、后端任务、测试任务、配置部署…
缺陷等级，这个划分也比较灵活，有分三级或四级，也有分五级的。
一招毙命的缺陷，使你的系统无法运行，有造成数据泄漏的安全性问题。
可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。
指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷
增加用户使用体验的建议性问题。（一般情况下，建议也为做为缺陷的一种。这个跟系统的类型与需求有关）
缺陷优先级（priority）
当问题处理人员在面对许多问题需要处理进，就需要问题进行优先级排序。我们做事情的安排，操作系统有处理进程等都在使用着优先级。
优先级的划分：
低——&中——&高——&紧急
延迟处理——&正常排队——&优先处理——&紧急处理
Bug的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。
一般地，严重程序高的软件缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的危害性大，需要优先处理，而来严重程序低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
严重程度高优先级不一定高：
如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上处理。
如果某一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
严重程度优先级不一定低
如果是软件名称或公司名称的拼写错误，虽然说其属于界面错误，严重程度不高，但其关系到软件和公司的市场开解，必须尽快修正。
对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。
打开： 表示问题被提交等待有人处理。
重新指派 ： 问题被重新指派给某人处理。
处理 ： 问题在处理中，尚未完成。
固定 ： 确认此问题存在，但暂时不进行处理。
回归 ： 对已经修复的问题进行回归确认。
关闭 ： 问题的最后一个状态。
一个bug的生命周期
下面通过一个比较完整的bug的处理流程图，更深刻的理解bug的状态以一个bug的生命周期。
提交（打开）缺陷
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
最后，“状态”和“指派人”的对应关系如果更加细化，对项目而言是有益的：
阅读(...) 评论()如何写一个强大的bug测试报告_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
如何写一个强大的bug测试报告
阅读已结束，下载文档到电脑
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢BUG级别（优先级、严重级）定义
一、主要分类
BUG类型标准主要分两类：
?&依据优先级分类。
?&依据严重程度分类。
二、主要内容
依据优先级分类标准
优先级：指一个BUG相对于其他BUG对于公司的影响，解决的及时性。
?&系统无法工作
?&测试无法继续正常工作
?&特殊情况：如重要客户（项目重要性）
?&需求问题
?&实现与需求不符
?&出现调试代码
?&功能性错误
?&关联性错误
?&前后模块不一致
?&链接错误
?&特殊性的程度性能低下
?&程序引起的安全问题
注：涉及所有关于数据流的错误
?&页面格式错误
?&兼容性问题
?&校检错误
?&图片错误
?&文案错误
?&程序性能低下
?&缺少容错性处理
?&功能易用程度低
?&配置问题
注：涉及的所有关于文本的错误
?&遗留问题
?&暂时无法实现技术问题
?&合理建议
依据严重程度分类标准
严重程度：指一个BUG对于用户造成的影响，风险和可视性。
?&程序无法运行的错误
?&测试无法执行的错误
?&链接错误
?&前后模块不一致
?&需求问题
?&实现与需求不符
?&出现调试代码
?&功能性错误
?&程序性能低下
?&程序引起的安全问题
?&页面格式错误
?&文案错误
?&图片错误
?&兼容性错误
?&校检错误
?&关联性错误
?&配置问题
?&功能易用程度低
?&合理建议
?&遗留问题
?&暂时无法实现技术问题
1)&&&&&&&&一些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。
2)&&&&&&&&为了错误数量的准确性，测试人员提交的每一条BUG报告中只记录一个错误
3)& & & 如果有各个模块中有同类错误的问题，作为多个模块的记录提交，即需要提交多条相同的错误记录，而不是一条记录。
三、错误分类具体说明条例
?&出现错误文字
?&出现错别字
?&出现图片地址的错误
?&图片不能正常显示
?&页面缺图
“Dr信用牛牛”让你远离信用污点
国内首家信用健康管理平台免费为你提供信用修复方案