bug的提交,优先级.严重程度等.docVIP

bug的提交 不管做什么，我们都希望能有个规范，能尽量按规范来，但是这常常是事与愿违，对软件测试也一样，很多时候不是我们不想规范，而是各个方面的限制，我们不能做到很规范。这点对于还处于发展期的公司来说，尤为明显。这种情况下，就要讲究策略。这里我仅对bug的提交进行我的个人观点的阐述。 以psm为例讲解如何进行bug的提交。 截图所示：PSM的创建bug图示。 如上图，红色圈圈中条目，一般是我们在提交bug时会进行填写的条目，即：所属项目，影响版本，当前指派，Bug标题，重现步骤，类型/严重程度，附件(偶尔)。其它的条目很多时候，因为时间等各个方面的原因，我们都忽略不填了。而这几个条目中，我重点要说的是Bug的标题，重现步骤，类型/严重程度。 Bug标题： 第一：顺藤摸瓜：见到标题就知道bug属于哪个模块的 第二：见名知意：见到标题就知道bug描述的是什么 综合这两点：我给的建议书写格式：大模块(-子模块)-问题描述，如上图 重现步骤： 数据和逻辑分离，如上图 好处： 第一：逻辑清晰，易读易懂，因为bug是给别人看的。 第二：不因为数据失效而失效。如果数据和逻辑混合: 1.打开数据分析-数据库审计查询 2.输入时间范围：1012-12-22 00：00：00到2012-12-22 59：59：59,10.4.0.6，点击查询 问题：是不是只有这天的ip数据，这个特定的ip才会出现bug呢？？[测试验证bug，开发验证bug，回归验证bug]，是不是很难说呀 分类/严重程度： 第一：分轻重：事分轻重缓急，同样，bug是给别人看的，别人更在乎重点，所以建议不要随便给个数字【我们可以把数字和自己定义的严重程度进行对应，在整理测试报告的bug列表时就可以直接按这个数字给个严重程度】 另外： 一个bug只描述一个或同一类的问题 以下参考网络： bug的优先级 优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。 为什么这么说呢？ 因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。 一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！ 这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。 其实，这在微软内部就叫做“基于风险的测试”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。 话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！ 当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。 下面某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我们所说的Enhancement。 缺陷严重级别定义: o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等. o 紧急---事件非常重要,并且需要马上给予关注. o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决. o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决. o 低级---事件不重要,可以在时间和资源允许的情况下再解决. o 建议性缺陷. 更为详细的划分如下: A类——严重错误，包括： o 由于程序所引起的死机,非法退出 o 死循环 o 导致数据库发生死锁 o 数据通讯错误 o 严重的数值计算错误 B类——较严