缺陷管理之缺陷的优先级和严重级别

作者：佚名

近日，加拿大达内科技公司、北京大学软件学院与亚信科技(中国)公司、精点科技(中国)公司、迪思杰科技(中国)公司、中通网络产业公司以及中关村科技园区的30多家企业达成定向人才培养计划。从2005年5月8日开始，软件测试时代为这些企业量身培养IT就业市场紧缺的百余名。经过2个多月的培训，这些软件测试工程师将直接到领测软件测试时代的签约公司就业。

　　 随着中国IT行业的发展，几乎每个中大型IT企业的产品在发布前都需要大量的质量控制、测试和文档工作。由于前些年企业对产品的测试工作重视不够，又加上没有系统地测试培训课程，因此软件测试工程师及系统测试工程师将在短期内出现严重的短缺现象。从近期的企业人才需求和薪金水平来看，测试工程师的年工资有逐年上升的明显迹象。测试工程师这个职位将成为IT就业的新亮点。

　　 测试工程师一般分为以下几个等级：测试工程师、高级测试工程师和资深测试工程师。测试工程师一般承担以下工作：利用按照测试方案和流程对产品进行功能和性能测试，检查产品是否有缺陷，性能是否稳定；高级测试工程师一般的职责是：不但能够编写测试工具，而且能够设计和维护测试系统，编写测试方案，编写测试文档、编写安装和使用手册；资深测试工程师的职责要求更高：不但能够具有初级测试工程师和高级测试工程师的能力，而且能够对测试方案可能出现的问题能够进行分析和评估。 今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的文章来告诉大家“看，老外都是这么做的”。
我觉得有必要给大家解释透这两个概念，这样不至于在日后的工作中做错。

以下粉红色部分是对那篇英文的引用，后面则是我的回答（结合微软的实际例子给大家说明）。

QUOTE:
原帖由rivermen于 2007-3-9 09:12 发表

c) The tester then selects the priority of the defect:

Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error

从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。
优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。

为什么这么说呢？
因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。
一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！
这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题xxx。
其实，这在微软内部就叫做“基于风险的测试”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。

以下是微软公司的缺陷流程（不知道现在做微软外包的公司是否也采用这套流程），给大家参考参考。
Bug跟踪过程
　 在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
　 1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
　 2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
　 4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。

话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。
我下面粘贴某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我上课所说的Enhancement。

========================
缺陷严重级别定义:
o {zgj}--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
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类——测试建议（非缺陷）