3、一般

　　（1）这个Bug在将来是严重的，但比主要问题要轻。

　　（2）可以有一个比较简单的绕过Bug的解决方案

　　（3）存在不明确或不完整的错误信息提示，但对产品使用影响较小

　　（4）容错性方面存在不足

　　（5）由于精度问题造成数据不一致

　　4、轻微

　　（1）不可能被用户发现的Bug

　　（2）某个控件没有对齐，某个标点符号丢失等低级错误

　　（3）尚无法满足的新需求

　　四、如何划分bug的优先级别

　　Bug的优先级是指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，同时需要考虑问题修改的成本与时间。

　　1、高

　　这类Bug对产品影响非常大，造成产品不能移交。

　　2、较高

　　这类Bug对产品影响比较大，如果产品带着Bug发布给用户将会产生麻烦。

　　3、一般

　　这类Bug对产品影响一般，如果Bug被fix，产品会更好；或者是这类Bug对产品影响一般，如果fix bug 不影响产品的交付期，一定要fix。

　　4、低

　　这类Bug对影响较小，只有在其它所有Bug已经被fix后，再fix这类Bug

　　一般来说，严重级别高的bug具有较高的优先处理级别，但是严重级别和优先级并不总是一一对应。有时候严重级别高的Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。例如，如果某个严重的bug只在非常极端的条件下产生而通过配置或人为注意可以避免，则可以稍后解决。另一方面，如果软件缺陷的严重性很低，例如，提示错误，但是提示信息很容易造成别人的误解，则必须尽快修改。

　　五、如何进行Bug描述

　　1、简明扼要的bug描述

　　一些比较简单的Bug，可以使用一两句话把问题准确描述，比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

　　2、严重的程序缺陷bug描述

　　比较严重或复杂的Bug，应该在bug报告中进行详细的说明。对于产品的程序缺陷，也就是测试的时候发现的问题，此时作为Bug的详细描述，应该包括（根据实际情况选择）：

　　（1）测试要点：测试用例的测试要点

　　（2）测试配置：如果有特殊的配置，需要在Bug描述中说明