Bug管理工具有很多，jira、禅道、git、mantis等等，有些公司，甚至会用Word、Excel等来记录Bug，不论是工具或者文档，只要能记录问题，都是可以的
那么如何报一个Bug才对呢，首先来看什么是漂亮的Bug：
1、根据Bug步骤能重现bug
2、其他人看到你的Bug，心情没有变糟糕，要记住，你报的Bug，阅读对象可能是其他测试、开发、产品经理、甚至可能是你的领导
3、开发看到你的Bug后，基本上95%知道问题出在什么地方了
一个好的Bug包括了简洁的标题，详细的步骤，明了的截图等
标题（摘要）：
力求精简，表达清楚，避免出现写作文似的标题，一个好的标题应该尽量不超过50个字
优先级：
在时间不够的情况下，开发会根据优先级来修复Bug，标好优先级，方便开发处理问题，提高整个团队的效率，原则上，在上线之前所有提交的Bug都应该被修复，最次也要达到Major及以上级别的Bug都被修复
较通用标准：
Blocker（P0）：整个模块功能不能用、准入没有通过、测试无法继续工作；
Critical（P1）：崩溃、闪退等、主要功能无法实现、实现与需求严重不符、数据丢失；
Major（P2）：操作界面错误、次要功能无法实现或实现与需求不符、边界条件出现的错误、提示信息错误；
Minor（P3）：错别字、产品建议、不影响使用的易用性问题；
环境：
发生bug的环境是什么，比如浏览器是Chrome60.0.0.1、360 8.1、Android4.0 小米4、ios11 iPhone8等，标明了Bug发生的环境，更能帮助开发在特定的环境快速定位问题
账号：
Bug是否发生在特定的账号里，想复现Bug是否需要非常复杂的步骤，如果是，给出复现的账号吧，开发只要登录，找到对应的位置，就可以轻松复现解决
描述：
一个好的Bug描述，决定了其他人拿到这个Bug之后，是否能准确复现Bug，不要漏掉任何一个步骤
操作步骤：
步骤1：xxxxx
步骤2：xxxxx
实际结果：
比如：实际结果：删除文件失败。对于实际现象表现较复杂的，可以分子项来写，比如：实际结果：a.xxx；b.xxx
期望结果：
比如：期望结果：删除文件成功。期望信息较多的也可以分子项来写，力求信息全面，表达清楚。
附件：
贴上Bug的截图，开发就会很明了，不会在去重复询问，有的时候，一张图更能传达bug的意，问题不好用文字描述，使用录屏可以让开发很好的理解并重现Bug
log：
客户端崩溃了，客户端发生了一个不能重复的Bug，贴上崩溃的Crash，发生问题时候的log，开发一看就很明了
不要对一个程序员说：你的代码有Bug。
他的第一反应是：1，你的环境有问题吧；2，傻逼你会用吗。
如果你委婉地说：你这个程序和预期的有点不一致，你看看是不是我的使用方法有问题。
他本能地会想：操，是不是出Bug了！
