什么是BUG
只有在规格说明存在并且正确的前提下，程序与规格说明不匹配之处才是错误（BUG）。
如何描述一个BUG
我们在描述一个BUG时，应当说明以下几点：
1、发现问题的版本（在哪儿发生的）
2、问题出现的环境（在怎样的环境下发生的）
3、错误重现的步骤（怎么操作会产生这样的错误）
4、预期行为的描述（本来我们是想得到怎样的结果）
5、错误行为的描述（结果却出现了什么样的结果）
6、其他（错误的优先级，错误的分类）
BUG分类
大体分为：崩溃（Blocker）、严重（Critical）、一般（Major）、次要（Minor）。具体看公司的划分标准。
崩溃（Blocker）：该类BUG一旦产生，将会阻碍开发或者测试的工作。可能是造成了系统的崩溃，死机，死循环，数据库数据丢失，与数据库连接错误，主要功能或基本模块的缺失等这些问题。比如：代码错误，死循环等
严重（Critical）：系统的主要功能部分缺失，用户数据丢失，一级功能无法使用（但不影响其他功能模块的测试工作），功能的设计与需求不符合，模块无法启动或调用，自动重启，安全问题，稳定性等。比如：用户要求的功能部分没有实现，数值上的计算、统计、存储错误。
一般（Major）：功能没有完全实现但是不影响我们的使用，某些功能存在一定的不足但不会影响到系统的稳定性。比如：删除没有确认框，操作、查询时间长，边界条件错误等。
次要（Minor）：性能方面的优化，建议类的问题，都不会影响到操作功能的执行。比如：错别字，排版问题，描述不清楚，没有提示语。
常说，软件测试就是找Bug。那么我们找到一个Bug之后怎么办呢？？？
下面就来学习一下缺陷的管理流程。
从图中我们可以看到一个BUG的生命周期大体有以下7个状态：
New：新发现的BUG
Open：确认是BUG，就打开
Fixed：确认是需要修改的BUG，进行修改
Rejected：认为不是BUG，拒绝修改
Delay：认为暂时不需要修改，延时修改
Closed：修改之后，测试人员进行回归测试，回归测试通过后关闭BUG
Reopen：修改完成经验证BUG依旧存在，则重新打开，再次进行修改