HoneyHoney

想记录一下所谓的bug report了。两年半的时间，我报了1300个bug。在这1300个bug里面，学到了很多东西。我个人比较喜欢什么都喜欢去尝试，什么都要弄一个极致的想法和做法：如果报了1000个bug，那又会怎么样呢？

1. Bug report是门技术活，和写作有关
   不要以为bug report只是简单的描述复现步骤，如果是如此简单，那么谁都可以当测试人员了。即使在测试团队里面，大家有时候还是会去讨论bug report描述不清楚，看不懂，缺少信息等等。为什么会出现这样的情况？
   好了，我在这里就不吐槽国内语文教学如何如何"坑爹"的了。或者，你可以告诉我，中文是一门语境高的语言。可是我的bug report用不到那么高的语境，我需要的只是需要把一个事情描述清楚而已。
   正如大家说，英语学不好，多半是由于语文没有学好。同样，语文没有学好，bug report也写不好。同样一个bug，在不同人的眼里，可以有不同版本的bug report。但是，总有那么一个report，是最简单的，最有效的。有点像设计中的一个理念："总有那么一个最简单，最有效的解决方案！"努力提高自己的写作能力，对于bug report是很有帮助的。
   
2. 如何提高bug report质量
   问题太广，方法太多，需一条一条细数（下面一条一条整理）。但是，如果说没有相应的经历，我估计总是有人不能够理解下面的内容，正如我现在依旧看不懂很多电影。《程序员修炼之道》里面也提到，没有经过几十万行代码的锤炼，是很难达到高手的境界的，也就很难理解高手所说的信息。（额，我不是想说我是高手，只是想说，有过相应的经历以后，再来看这些，会产生一些共鸣。）
3. 多看，多想，多练。
   关于这个，有一个题外话。一般而言，技能提升的方法有2种：外部环境和内心驱动，即外部提供足够的环境促使个人发展和内部驱使自己的个人发展。就我而言，我还是内心驱动那种，结果就是，有时候别人 忽悠我，我生硬地点点头，回头继续干自己的，直到撞到南墙才反省。
   "多看，多想，多练"这个是我刚进公司的时候，上面的manager给我的一个tip。
   1. 多看。刚进公司那会儿不知道如何报bug，或者报的bug太龊，几乎每次都要被师傅给呵斥一顿。后来的方法是看别人报的bug。这个渐渐成了自己每天都会做的一件事，读读别人报的bug，然后试着自己去重现一下。这样，既对产品了解了，知道哪里容易出bug，又能够学习别人报bug的风格。
   2. 多想。在看了那么多bug以后，思考的是：如果这个bug丢给我，该如何去报？动动脑子是一件好事。在想不出比别人更好的描述之前，就会拿当前的描述作为最好的模范，直到有一天你会博采众家之长。
   3. 多练。动手与否，效果很不一样。有时候，我们想了很多，等到做的时候又老是忘记写上重要的信息，或者发现了之前思考不足/遗漏的地方。无论如何，这些是好事，促使自己报出更好的bug。
4. Bug Summary
   我们的测试经理曾经说过，好的bug summary是成功的一半（其实，我也说过，比如在这里 :) ）。怎么说呢？如果bug summary写得足够好，那么别人几乎不需要再仔细看里面的内容，就知道你所描述的bug是怎么回事了。就开发而言，看完summary，再回想一下当初自己是如何设计的，就能够分析出这个问题是如何出现的，该如何去修；就需求分析员/测试经理而言，从summary里面能够读出这个bug的严重性和优先级，尤其是在bug triage的时候，可以节省很多时间。
   好吧。那我把bug summary写得老长老长，将所有想说的都写进去吧！额。。。那这不是bug summary了。既然是summary，那么ta应该是简洁的，优雅的。所以，一般而言，写bug summary的时候，需要思考两个问题：1. 能不能够再短些？2. 有没有歧义？如果说既短又没有歧义，那么，恭喜你，成功一半了。
5. Versions
   应该说很多团队都会在bug report里面包含这些信息。比如，浏览器(Firefox 10.0, Chrome 18.0), 操作系统(Ubuntu 11.04, Windows 7), Flash player version, Build version. Version info可以很好的指出这个问题在哪个版本上面会有这个问题，什么时候出来的，什么时候在哪个版本上修好的。
6. STR (Steps to Reproduce)
   终于到STR了。好吧，这里要详细描述问题是如何出现的。但是，先等等。你的第一步可以执行不？如果说别人第一步都找不到入口，那后面如何执行下去。要保证第一步是可以执行的。但是这样有可能导致另外一个情况：步骤很多，20多个步骤。好吧，你写得绝望，开发也看得绝望。如何解决？在STR之前插入pre-condition，也就是说，在做第一步操作之前的一些准备工作。或者，提供测试环境上面的数据给开发作为reference。
   关键步骤的时候，尽量用'华丽的分割线'将其标出来。要不，开发没有留意到你这里是这么写的，直接说"不能够重现"，那一来一往又多几分折腾。
7. Screenshot, Video
   截图和视频是"必杀技"。对于界面上的issue，一个简单的截图超过千言万语；对于复杂的操作，一段视频胜过20多行steps。对于截图有一个小提示，尽量将问题所在地方圈出来并加上注释。要不，有可能别人费老大劲在你的图上找问题所在"你妹的，到底哪里有问题啊？我怎么看都是好的呢？坑爹呢！"
8. 【进阶】Error log
   抓取错误信息并试图去读错误信息。一般来说，如果error是被代码捕获到的话，那么error log里面提示就能够很好的说明这个问题为啥会出现了。（应该大部分开发都会这么做吧！）至于没有被代码捕获的error log，那么error log里面的哪个文件多少行哪个方法的时候抛错，也是很有意义的。这对于开发，是好事。对于测试人员来说，如果对代码有兴趣的话，还可以从log里面看到后台是如何实现的。一般而言，后台里面有很多debug级别的信息，描述了后台是如何处理消息的，在处理什么的时候报错的。这样对于理解背后service是如何工作的很帮助。慢慢积累多了，就知道某个error为何会出现，或者根据error log分析出如何重现问题（这个是分析production环境上缺陷的很好方法）。
9. 【进阶】Comments.
   如果说，以上都有了，都很不错了，那么，一个简单的comments将为这个bug report'画龙点睛'。比如，你写到'这个缺陷只在这种条件下能够重现，其他条件下没有这个问题'，或者'这个缺陷是由于client端发送给service端的消息错误导致的'。这些，可以更好地帮助别人， 也可以为你加分。
10. Template
    按照上面的说法，建立一个适合自己/小组的bug report template将是很有用的。这样能够保证bug report里面提供足够的信息，省去到时候漏掉这个漏掉那个的。既然这么好，为什么不用呢？（其实，当初写template的缘由是自己每次都要去copy以前的bug report。后来，直接抽出里面共有的部分，建立成template。其实，开发常常干这事。）
11. 因人而异，因地制宜。
    最后来点玄乎的吧！回头来看以上的东西，真的就那么好么？一是，这只是我自己脑海里面的东西， 这些东西可能不适合你，而且，若干年以后我自己再来看这些不知道是不是会苦笑；二是，本来这些不是一成不变的，因人而异，因地制宜吧！
    如果说，简单的界面问题，你有必要写那么多steps么？一个简单的截图搞定；如果说，你的开发团队就在你的身边，简单口述/重现一下问题给他，胜过文字的冷冷冰冰； 如果说你的开发团队在地球另外一边，那你还是老老实实写那么多东西吧！一来一回真的很折腾！

这一篇旧文，原文写于2011/11/8，记录在evernote里面，直到今天才翻出来。翻出来的时候，还是感觉诸多不爽：对自己语文不好的不爽；对测试现状的不爽。现在努力去发现一条能够很明了看清楚整个项目进度，状态的方法。