如何提交bug

状态流程图

bug是测试工作主要的产出内容，作为一个测试，一定要清楚地知道一个bug的整个生命周期，并推动bug的修复进程。一个bug从发现到最终修复关闭，一般要经历如下流程：

图中有英文标识的，是常见的bug管理系统中bug所处于的几种状态。通过变更bug的状态，同时将bug指派给相关的负责人，这样就建立了问题修复的协作流程。需要重点强调的几点：

1、 对于发现的问题一定要先确认是否能够重现，以及重现的步骤是什么。有些测试，一遇到问题就大呼小叫地喊开发同学来看，然后开发调试两下问题没了。先问怎么出现的，——不知道；再问出现前在干嘛，——忘记了。这样的情况出现几次，开发同学没砍死你一定是真爱。发现了问题，第一要先记录怎么出现，自己刚刚干了些啥，然后尝试再重现一次，确认能够重现后再把问题报给开发同学。当然，如果你的水平够高，能够直接定位到问题出现的原因，提供修改建议，至少能给开发节省一半的时间。

2、 要准确清晰地描述问题。我自己最常用的描述bug的格式如下： 【功能模块名】—问题或现象描述，能否重现 如果现象或问题较为复杂，就备注上详细的重现步骤，比如先做什么，再做什么，最后出现了什么问题，本来应该是什么样的等等。但千言万语不如一张直观的图，所以直接把问题截图，再配上说明，会容易让人理解。还有就是要标明bug的优先级，判别的标准主要有两个维度：严重程度和影响范围，如下图：

• bug分级：紧急的bug一般是那些导致流程中断，功能不可用的，最严重就是客户端闪退，服务端宕机。重要的bug一般指的是对功能流程有影响的，或是概率性出现的严重错误，例如客户端有内存泄漏，越来越卡，或是偶尔与服务端失去连接等。普通的bug就是最常见的问题，例如界面显示错误，奖励数量错误等。而忽略的问题一般就是有一两个错别字，或者使用的是临时道具图标。我们常规的测试方法，最容易发现的问题都是『紧急』和『普通』的bug，而产品发布后如果出现事故，一般都是被忽略或未发现的『重要』问题。想要提高发布产品的质量，尽可能地在发布前发现所有问题，一般有两种手段：一种是靠管理，比如通过标准化流程来控制风险；而另一种就是常规测试基础上再做探索性测试，通过设计更严谨的测试用例或借助技术手段来发现风险。

3、 新人最常遇到的问题，就是“我发现的这个bug应该提给谁？”。即便工作多年，我也偶尔会将bug提给错误的人，有时对方会很不耐烦地说这个问题不应该找他。这里插句题外话，出来工作嘛，内心迟早得要变的坚强，才能面对未来更多的惊涛骇浪。社会中绝大部分都是好人，即便有凶神恶煞的并不是在针对你，而是大家都面临着巨大的压力，很难永远保持一个良好的情绪去面对所有人。说回bug应该提给谁，首先你得知道这个功能是哪个策划设计的，哪个程序开发的。然后介绍第一个准则：所有bug都可以先提给策划。因为负责设计功能的策划就是第一负责人，测试发现的所有问题，理论上都是策划同学验收所遗漏的，所以提给他也是让他知晓自己的功能出现了怎样的问题。从错误类型上来说，像配置表填写错误，美术资源错误这些基本都是提给策划同学，而如果是功能逻辑出现了问题，比如点击了一个按钮出现了一个错误的界面，这个一般就要找开发同学解决了。而开发一般又分为前端（即客户端）和后端（即服务端），所以第二个准则：所有的程序问题都可以先提给前端同学。测试新人发现的绝大部分的bug，主要都是在前端部分。从我们日常的bug统计来说，前端bug至少占了60~70%，这不是说前端同学编程水平差过后端，而是前端要实现和处理的细节远多于后端，而且表现更直观容易被发现错误。当然随着经验和能力的提升，当你能够清楚地知道问题出现的原因之后，基本上你就可以很准确地将bug指派给策划、前端开发或后端开发了。

4、 所有bug最好用一个bug管理系统进行记录管理，万不得已不要用excel表格或word文档。一般redmine是最常被用来作为bug管理系统的，它简单方便，扩展性高，可以添加一些插件功能。当然也可以完全自己开发，不差钱的话就直接购买。bug管理系统的意义除了记录以外，更重要是可以建立其一个高效的工作流程。开发不必时不时被测试打扰，可以更专注地写代码，然后根据自己的时间安排去集中修复bug。项目管理也可以通过查看功能剩余的bug来判断当前功能完善水平，何时能够上线。测试同学本身也可以根据bug记录，定期进行回顾和总结，统计bug类型和原因，为以后的工作量评估和预防bug积累经验。可以考虑做一个“智能bug管理系统”，自动根据bug描述来标识优先级，指派修复人，以及根据项目进度及时提醒。