如何写一个清晰明了的Bug报告？
作为一名程序猿，平时撕逼最多的就是产品经理，其次就是测试妹子了。这里不说产品经理，只说测试妹子。普通公司技术部门一般有如下工种：后端、运维、客户端（Android和iOS）、H5前端、测试。鄙视链貌似是这样子的：后端鄙视客户端，客户端鄙视H5前端，H5前端鄙视测试。好像把运维同学给忘了？是的，就是忘了。个人认为这种鄙视链应该是从技术的广度和深度来讲的，合不合理不重要，且做笑话听了。
那么为何程序员除了撕逼产品经理还有测试同学呢？个人认为有以下几点原因：
沟通问题测试妹子：“你这个功能有问题，产生的数据和预期不一致”。
程序猿：“什么呀，是不是你操作的姿势不对啊，你怎么操作的我看看”
测试A巴拉巴拉又操作了一遍，问题重现了，程序猿方才极不情愿的去查看自己那优秀的一塌糊涂的代码。
如果换种方式呢？
测试妹子：“麻烦你帮我看看我这是不是使用姿势不对？为什么没有出现和预期一致的数据”
程序猿：“卧槽，是不是我写的代码有问题，等我检查一遍代码”
bug报告不清晰测试妹子提了一个bug到jira，和你关系好会口头通知一声，不熟的程序员就得自己发现了或者依赖插件通知。首先程序员看到jira上莫名多了一个bug，他心底是不爽的，再如果这个bug还描述的不知道在说什么，这就产生矛盾了。
报告描述的bug无法重现对于这种无法重现的bug，大多数的程序猿（不负责任的程序猿）处理方式都是：“测试妹子，等你重现了再来找我吧”，然后就没有然后了，等着线上出问题吧~线上出问题，作为功能开发者以及质量保证者肯定是责无旁贷的吧？程序猿心里想着：“沙比测试，啥问题测不出来”，测试妹子心里想着：“屌丝，写的代码都是bug”。
如何写一个清晰明了的bug报告让程序猿死心塌地的解决问题呢？
图文结合个人认为一个bug报告要包含：“我在什么场景下进行了什么样的操作产生了什么样的结果”，“我的预期结果是什么”，“实际得到的结果是什么”，然后一定要带上操作的图片，图片表示你的操作步骤，有图有真相。
采用优秀的bug报告工具想要产出一份清晰的bug报告是需要花费一些精力的，而借助优秀的bug跟踪工具则可以大大提高bug报告效率。常用的工具有
Confluence JIRA
Bugzilla
禅道
提高测试水平提高测试人员的技术水平，让开发同学能够认可、信服测试团队的测试质量和报告。这点是最重要的，否则开发同学始终带着不认可的态度去看你们的bug报告始终不是一个好的开始。
以上是个人认为一名专业的测试人员如何给出一份清晰明了的bug报告的几点意见。欢迎大家讨论交流，批评指正~
