前言：

　　这篇文章是基于Android系统定制和维护而写的，所以里面的内容与Android相关也就是说系统是Android，语言是Java，特点就是没有明确的需求行为规格定义，只有代码，很多行为也比较诡异，代码架构不是很完美，崩溃，异常比较常见（RuntimeExceptions）。虽然是基于Android的，但是方法是通用的。

　　什么是Bug

　　首先要明白什么是Bug，这点可能不同的人（测试和开发）有不同的理解，不同的公司也会有不同的标准。但是通俗的来讲，Bug就是指未预期的行为（unexpected behaviors），比如系统崩溃（Crashes），发生异常（Exceptions），或功能失常（Malfunctions），比如说点击了保存，但实际上没有保存，点击了发送却没有发送成功。

　　那什么又是预期行为（Expected behaviors）呢？预期行为通常是指需求说明书中规定的行为，但是很多系统（比如Android）完全没有需求或规格说明书，所以更多的时候判断的标准就是常识和经验，或与其他软件系统进行对比。比如说虽然没有需求规格书，但是通常意义上保存应该能把文件或用户所编辑的内容写进磁盘文件，如果没有成功，那行就可以认定为Bug。所以说Bug也是受主观因素影响的。

　　与Bug打交道的人

　　软件的理想情况是程序员所写的程序（算法）都是正常的，但是有理论证明这是不可能的，没有任何一个算法是完全正确的，另外只要是人就是犯错误。所以现代大多数的软件都这样来保证它的正确性，开发人员交给测试人员软件，测试人员来保证它的质量，通过测试Bug，当软件的Bug在一定的允许的范围内（小于10个）就可以认定软件已达到预期了，能正常工作并且可以发布。

　　在这一过程中涉及三组人：一个是开发人员，一个是测试人员，另外就是管理层。很多大公司的开发人员与测试人员都分属不同的部门。开发人员负责开发出可测试的软件版本，测试人员对软件进行测试，测试出Bug后提交给开发人员，开发人员再解决Bug。通常他们都有来自管理层的压力和绩效考核的压力，也就是说管理层对测试人员说：你要尽可能多的提交Bug，无论用什么方法，或者你每天必须提交3个Bug；另外测试人员的绩效也与其所提交的Bug数量直接相关。管理层也会对开发人员说：你要在Milestone前把所有的Bug都解掉，上个星期的Bug怎么还没解掉，你想不想干了？另外开发人员的绩效也会与Bug数量有关，如果有Open的Bug会扣新水或奖金等。

　　这样一来，原本比较简单清纯的关系变的就有些复杂了，无论是测试人员还是开发人员会把人的本性加进来，把政治和功利也带了进来，像测试提交了不是Bug的Bug，或是开发人员强行关闭Bug都是常有的事儿。因此，测试与开发人员便有些战争：

　　开发：你这不是Bug，这个行为就是这样设计的？

　　测试：但是这样设计很不合理！

　　开发：那这个要去找UX设计的人？对于行为的修改我们不能做主

　　测试：我不管那么多，我只管测试

　　开发：#%^@&$...

　　....

　　测试：你为会么关我的Bug

　　开发：因为它无法复现

　　测试：但当时我的确是遇到了

　　开发：那你再复现出来吧

　　测试：@#$%^...

　　Bug的常见分类

　　如前所说Bug就是未预期的行为。所以Bug常见的类型有：崩溃（Crashes），异常（Exceptions），功能失常（Malfunctions），差劲的用户体验（Bad user experiences），未实现的行为和功能。