软件测试猿和bug的爱恨情仇

对程序猿来说改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中的战斗机，小兵都没有参战的机会。

比如：添加按钮点不了；审批流程中审批单流不到审批人那儿去，再比如页面跳转不过去……

以上屡见不鲜的情况会一次次挫败我们测试猿的热情。

想学习却无从下手，该如何学习？

这里我准备了对应上面的每个知识点的学习资料、可以自学神器，已经项目练手。

最后送上一句话：
世界的模样取决于你凝视它的目光，自己的价值取决于你的追求和心态，一切美好的愿望，不在等待中拥有，而是在奋斗中争取。
如果我的博客对你有帮助、如果你喜欢我的文章内容，请 “点赞” “评论” “收藏” 一键三连哦！

• « 上一篇：Unix/Linux编程：UDS 流（Stream）
• » 下一篇：@KafkaListener注解解密