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