作为一名软件测试人，必须要面对其中一个是Bug，Bug有很多方面，细说下我眼中的Bug：

　　Bug的提交：如何提交Bug是很有学问的，比如以前我曾经遇到过这样的情况，一个页面上的几个样式问题提了几个Bug，遭到批判说，可以提交一个Bug，被教育说并不是Bug越多越好云云，其实我不是这样的意思，因为之前遇到过把几个类似的Bug提到一个里面，结果只改一处把Bug fixed了，因为Bug没有修复完整，那么我只能reopen了它，但是这样又导致了高的reopen率，我好为难！怎样提交Bug才能把这两个方面平衡到呢？我后来采用的方式，提了一个Bug，在备注中说明，共有*个问题，请仔细修复后再fixed。因为现在要求每个开发在修复Bug后一定要填写备注，他在填写时必定会看到我写的内容，如果仍有其他情况发生，那么也没有办法了，以后只能再提交多个Bug来杜绝此事。

　　Bug的严重程度及发现难度：因为这两个字段可能会影响到开发的KPI，一个季度或半年中，某个开发同学的严重Bug率及容易发现的Bug率是多少，会多多少少影响到开发的KPI，所以当我们选择这些时要慎重，原则是公平，是是，不是不是，不要带有私人情感，比如我跟某某开发关系不错，还是不要这样选择了类似的，这样会对其他同学很不公平，而且这样是纵容，纵容的结果是ta的质量越来越烂，辛苦的还是测试。

　　Bug的流转：某些情况下，我们的Bug并不会很顺利的关闭，验证之后没有修复的reopen掉；提交之后开发无法重现的，会later掉；由于一些配置等情况的可能会产生一些无效Bug；多人测试时又可能是重复的Bug；林林总总的情况，导致我们提交Bug时也要非常小心，毕竟测试产生过多的无效Bug也是一种测试技能的缺失，无法重现或很难重现的也算是测试在提交Bug时未能找到规律导致的，也是要避免的；那么说到Bug流转，需要关注的是流转到later状态的Bug，本来later意味着本次项目中不修复，以后再修复，但是很多时候会忘记掉还有这样一个Bug在，等到出了问题才又想起来，这个是很坏的一种情况，好的做法是在项目之后及时梳理later的Bug，提早安排在后续工作中修复。

　　Bug的根因：以往提交Bug，提交时描述现象OK了，等着验证。但是我倒是希望不管是新手还是老手，能分析Bug的根因是很重要的，从某个方面可以看出来你所对应的开发在开发习惯上会有哪些陋习，一般会有规律可循，再有是寻找Bug的根因对理解系统实现是非常有帮助的，或许对大部分测试同学来讲可能会比较困难，我会建议大家从简单的分析入手，了解了程序结构和实现后，慢慢深入，肯定会大用帮助。我也一直会努力去这样做。

　　Bug的统计和分析：不管是做项目也好，季度总结也好，一个里程碑上对Bug进行统计分析是非常必要的，从几个方面讲：一是将Bug归类，总体哪个类型的Bug比较多，Bug归类可以从多方面（比如按功能模块分，或者按开发人员分，按测试人员分），你需要考虑的角度不同可以进行不同的统计。二是提炼某类Bug可以找出解决此类Bug的方案，以保证后续中不再发生这样的Bug，可能更多需要从开发的角度去做这件事情。三是找到发现某类Bug的统一解决方案，比如我写怎样一个小工具可以批量找出这样的Bug等等。个人认为Bug统计是可以提高后续质量很重要的手段。

　　后一点是我们要一直去思考的问题：如何发现一些隐藏深的Bug呢？需要对测试技能和业务、程序实现的熟悉程度，越是在这几方面掌握的多，越是可以通过各种手段综合发现较深程度的Bug。比如web测试，你是否关注了每次请求和返回信息？页面反应正确时，数据库是否正确？我们曾发现过，页面什么问题都没有，但是数据库存储的参数却多了很多重复的为问题。各类测试方法和技术在不同领域的测试不尽相同，大家可根据自己的经验进行总结，去外部进行学习，多多益善。