对程序猿来说改bug可以位列开发过程中最讨厌的事之首了，这么讲应该没有人会反对吧？因为就连Java之父詹姆斯·高斯林也很讨厌Bug。
另一方面对于测试猿来说工作职责就是尽可能多地找出bug，并确保其得以解决。所以被程序猿视为眼中钉肉中刺的bug可是测试猿的工作成果物。
那么测试猿对bug又持有怎样的态度呢？会不会像爱惜自己孩子一样热爱bug呢？
答案是：
龙生九子各有不同，测试猿眼中的bug也是分三六九等的。咱们一起来看看吧！
最折磨人的bug——无法复现的bug
每个测试猿都会遇到这种情况：偶遇了一个bug，结果转眼间就不能再现了，各种环境上各种操作下来还是无济于事。
这种心情就像你洗漱完准备上床的一瞬，看到一个脸盆大的老鼠钻到了被窝里，可是掀开被子却什么也没有，移开床、打开柜子，甚至连地板都翘起来了，结果找遍了房间的每个角落还是没找到，这时候你还敢安心睡觉吗？
作为一名严谨专业的测试猿肯定不能放任不管。
这时候我们要第一时间上报bug，并尽可能详细记录测试版本、环境、前后操作步骤等信息。但是由于开发人员可能无法再现，会将bug打回，我们也不能因为这个问题影响接下面的工作进度，等项目测试结束后再回头来处理这个没有处理的问题。
最不屑的bug——UI bug
UI bug是测试猿眼里最没有挑战性的bug，这种bug具有以下特点：
- UI bug是直观的、显而易见的；
- UI bug是相对主观的，与测试人员的审美喜好有关；
- UI bug有些情况是极端的，比如输入长度达到最大的场合是否显示得下。
由于这种bug基本不影响项目主体功能实现，所以同样也不会被开发人员重视，这种负面反馈使得测试猿加深了对UI bug的不屑，甚至会产生提出这种bug是找麻烦的负罪感。
但是UI bug确确实实会影响用户的使用体验。
作为一名专业的测试猿我们要知道用户的事无小事。每个bug都值得我们认真去对待，只是我们可以将这类bug优先级调低，等项目主体业务都调通、功能稳定后再进行处理。
最难以接受的bug——影响基础功能的bug
当软件流转到测试阶段后，测试猿摩拳擦掌准备在bug战场上披荆斩棘的时候，果然没让人失望，上场就俘获一枚又一枚bug中的战斗机，小兵都没有参战的机会。
比如：添加按钮点不了；审批流程中审批单流不到审批人那儿去，再比如页面跳转不过去……
以上屡见不鲜的情况会一次次挫败我们测试猿的热情。