我眼中的bug管理
作为一名测试人，必须要面对其中一个是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测试，你是否关注了每次请求和返回信息?页面反应正确时，数据库是否正确?我们曾发现过，页面什么问题都没有，但是数据库存储的参数却多了很多重复的为问题。各类测试方法和技术在不同领域的测试不尽相同，大家可根据自己的经验进行总结，去外部进行学习，多多益善。
简单的是只如下：
1、测试人员可以利用Bug管理系统提交自己发现的bug，提交的信息一般包括测试环境(操作系统、语言等)、使用的测试产品版本号，bug类型，bug严重程度，bug重现步骤，期望行为/实际行为，附加描述信息，附件，屏幕截图或录像。测试人员提交这些信息的目的是尽可能地帮助开发人员重现bug以便调试;
2、测试人员可以把bug直接提交给负责相关模块的开发人员，也可以提交给开发组长由其将bug分发到相关开发人员。
3、开发人员收到bug系统发来的bug分配通知后，可以登录系统查看bug详情。在对bug进行修改后，可以将bug重新提交回测试人员。
4、开发人员提交的bug修改代码，在团队编译系统将其编入新版本后，自动将改bug信息中的修改版本号更新，然后通知测试人员可获取新版本进行验证。
5、测试人员如验证无误，可关闭bug;否则可重新返回开发人员修改。
