介绍
我想一份糟糕的BUG报告和很多人都有着或多或少的关联，或是客户支持的工作人员， 用户的反馈报告、开发人员、测试人员或一级技术支持，一份糟糕的BUG报告给他们带来时间上的开销。除了一些（大多数）开源项目，人们花费了宝贵时间，但是这也意味着他们花费了金钱。
我将通过这篇文章告诉你一份糟糕的BUG报告怎样浪费你宝贵的时间和金钱的，同时也会告诉你如何才能做的更好。下面开始从一个简短的解释来告诉你们一份糟糕的BUG报告到底长什么样子。
糟糕的BUG报告是什么样子的?
当我想到糟糕BUG报告的时候，我的脑海里它是这样的:
“我试着执行 sendMsg(“hello world!”)但是没有成功.”
相当不错的一个例子对吧? 这个报告只告诉我们它无法正常执行工作，但是并没有告诉我们任何其他详细的信息, 开发人员会打开程序的一部分代码检查，我保证大部分都会正常的工作。所以，什么样的BUG报告才算是标准的呢？ 这里有几个例子，我认为是比较重要。
1.缺少细节就想上面的例子当中，你很难去发现到底哪里出现了错误，因为这份BUG报告没有提供任何细节。
2.且少日志/错误消息错误消息的出现, 日志的写入、但是不知为何有些人总是忘记把他们写出到BUG报告中去。
3.一份报告中多种BUG的组合为此为曾花费了大量的时间. 人们找到各种各样的BUG 但是没有全部都写入到一份报告中去。
这里还有更多类似的情况，但是这些我认为是最重要的，下面我继续看看如果你提交这样的一份糟糕的BUG报告会有什么后果。
糟糕的BUG报告浪费时间和金钱
另外一个例子: 比如说你提交了一个联系人系统的一份很差的BUG报告：
“我尝试添加新的联系人，但是没有添加成功！”
现在在另外一边的票务系统会发生什么？ 其他人在他们的机器上执行同样的程序，设置添加联系人并且成功了。现在至少有两件事情会发生:
1.你肯定会马上把票据拿回来，然后客户会问你发生了什么？（至少我肯定会这么问你）
2.有人可能会尝试着寻找一切可能造成这个BUG报告的原因: 这个联系人不能被添加. 没人知道是不是哪里有错误消息, 或者根本没有执行. 或者这个BUG出现是因为点击了添加联系人的按钮又或者是保存数据的时候出错. 大多数情况这个人是没有办法找到原因的所在, 所以最终你只能拿回票据并且被不停的追问到底发生了什么.
退回发票继续时间的浪费
无论售后人员和技术支持作何反应都会加大时间的开销.首先有人需要对这个问题做基本的分析. 由于你没有提供详细的BUG描述，这会让他们只能猜想哪里出了问题. 技术支持会一直找问题的原因直到最终来问你。 也有可能他们会把这张票据直接给你，因为你没有提供任何可供参考的BUG描述。
不管怎样都会到你这里, 因为除了你没人直到发生这个BUG的原因，因此他们可能会让你对BUG增加一些更详细的解释 (他们为什么自己就不能搞定这个问题呢？你心里一定这么想) 时间一天一天的过去，就是因为你提交了一个这样糟糕的BUG报考. 但是你需要提供一些信息, 否则其他技术售后无法重现BUG，无所修复这个BUG. 那么你现在会怎么做呢？我想你应该会打开那个票务系统尝试在你的机器上操作，你猜怎么着？它很可能这次不会出任何问题. 就因为你没有对BUG做一个良好的处理，对软件公司造成了时间上的流失，时间就是金钱。
但是让我们假设一下你可以重现这个BUG, 你打开这个票务系统，这次你添加了一些对BUG的描述. 然后技术售后看到这个问题，但是这一次你提供了一些BUG描述，然后他们通过你你提供的错误报告极有可能马上就可以修复这个BUG. 但是大部分的时候他们还是无法修复这个BUG. 然后他们有找到你让你在编写代码的时候 写入更多对BUG的处理信息.然后没完没了 ….
时间就是金钱，不要浪费金钱。
这张票据来回折腾浪费了很多时间. 每当有一个技术售后的一个人拿到这样的一张有问题的票据, 他或者她每次都需要想办法重新BUG，找出问题。技术售后同时还有其他的事情需要做，原本他们可以一周做更多的事情，但是现在他们需要花更多的时间来处理票据的问题，对于软件公司来说，时间就是金钱，你就是在浪费公司的钱。
那你呢？他们每次来问你关于这个BUG的时候，你每次都需要重新检查问题出在哪里然后再告诉他们解决方案. 如果你是自由职业者或者在做生意, 你可以用这些时间做其他的事情. 就好比赚钱，你可以用这些时间赚钱，而不是花更多时间而一分钱挣不到. 当然你是程序员你是被雇佣的，你会拿到工资, 但是浪费了在这个项目上的时间，就是浪费了公司的钱，试着想一下，如果你能处理好这个问题你的工资会更多呢？
现在你看到了一份BUG报告的影响有多大. 你和技术售后肯定都已经烦了. 除此之外 每个人都在失去金钱. 但是我们不想浪费时间和金钱, 所以让我们来看看怎么避免这样的情况。
一份良好的BUG报告应该长什么样?
在此之前，我想说有很多的方法可以写出好的BUG报告. 这取决于你要提交BUG报告的产品, 有一些BUG报告的模板. 如果是这样的话, 下面这些模板提供了详细的BUG信息。
如果没有模板遵循的时候，至少你要学会提供 at least (!) 这样的信息:
1.如果可以的话: 这里添加BUG的版本号. 有些时候你修复过的BUG会再出现另外的BUG，这个时候你需要用BUG版本号来区分。
2.怎么重现 提供一个详细的步骤告诉别人怎么够能够重现你遇到的情况
3.预期行为 提供多种可能引起这个BUG的可能性，例如：1、可能是您那里操作错误了。2、可能是提供的参数错误。3、可能是XXX ，像这样多种的可能性。
4.观察行为 描述一个程序应该发生的行为和预期的行为. 这里你就可以解释为什么会有这个BUG报告，哪里出错了。因为这里发生的行为是和预期行为里的某一项是一样的。
5.如果可以的话: 包含一份日志 这个取决于产品的类型. 如果你知道日志在哪里的话直接使用它们并且发送出来就可以，对于某些类型的产品，它可以让你得到一些详细的信息，找到一个日志文件. 也有一些你没有办法访问日志文件,这样的话他们也就不会问你要日志。
当然，你总是可以提供更多的信息，如截图和代码示例 (如果是框架或者库), 总之尽量去添加多重可能性，2-5个，这样可以为你节省大把的时间。
总结
今天你学到了
●糟糕的BUG报告。
●它对于时间和金钱的开销很大。
●如果写一个良好的BUG报告。
几个星期前，我在Twitter上看到一个话题是关于糟糕BUG报告的,但是具体是谁发起我记不太清楚了。 但是我想分下分享里面的一句话，一直停留在我脑海里的。 原话：
Bug reports are handled with the same effort you put in writing them.
译：
大概意思就是，多少努力多少回报，你在BUG上下了多少工夫，那么它给你带来的受益也成正比的。
也许你会记住今天学到的，或许你改天会创建一个这样的票务系统。我肯定会这么做的。
PS: 如果你知道这是谁说的，我一定会很感谢他/她
我希望这篇文章能够让你了解BUG报告的重要性，也希望在以后你在对BUG的处理上多少有些帮助。
