糟糕的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报告。