0
Posted on Saturday, February 18, 2012 by 醉·醉·鱼 and labeled under
想记录一下所谓的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么?一个简单的截图搞定;如果说,你的开发团队就在你的身边,简单口述/重现一下问题给他,胜过文字的冷冷冰冰;
    如果说你的开发团队在地球另外一边,那你还是老老实实写那么多东西吧!一来一回真的很折腾!

0
Posted on Saturday, February 18, 2012 by 醉·醉·鱼 and labeled under
这一篇旧文,原文写于2011/11/8,记录在evernote里面,直到今天才翻出来。翻出来的时候,还是感觉诸多不爽:对自己语文不好的不爽;对测试现状的不爽。现在努力去发现一条能够很明了看清楚整个项目进度,状态的方法。

51testing和淘宝测试团队一起,在软件测试行业里面都很出名。前者以BBS为平台,分享、讨论测试信息;后者是淘宝测试团队的官方博客,显得比较专业、务实。

吐槽开始:
  1. 我现在所在的测试团队还算不错的。
    以前我一直以为自己所在的团队比较糟糕,但是没有想到还有比我们还糟糕的团队,所以,我还是算庆幸的了。当我自己发现别个还在纠结的问题,我们已经做到并且在考虑其他问题的时候,一种莫名的优越感油然而生(好吧,我都被自己给恶心死了。。。)
    比如,当我听说别个还在纠结"0缺陷"的时候,我自己只能够表示同情加吐槽一番。对于一个还在纠结"0缺陷"的公司、测试经理来说,我都比较万分的恐惧。犹如我们不可能进行100%的测试一样,我们也不可能很肯定地说这里没有bug。即使说,我们真的把所有的bug找出来了,由于时间,人员,资金等等问题,迫使你不可能将所有的bug修掉。"0缺陷",是个梦,现实还是残酷的。
    当然,我们自己还是有不好的地方,比如说,现在大家都还在纠结测试用例,尤其在用了TestLink之后。
  2. 对于0缺陷的"老大",我心存敬畏。
    这样的完美主义会毁掉一家公司的!处理bug泄漏率还是有很多办法的,不是不可泄露,但是不能泄露严重的bug出去。在对测试团队的评估上,有一个硬性度量叫"缺陷泄漏率"。但,这个不是简单的将泄露的bug数量统计出来,而是将这个值进行加权以后拿出来衡量的。比如,我泄露了4个不严重的bug出去,加权以后数值为1(4*0.25)。而如果我泄露一个很严重的bug出去,加权以后数值为4(1*4),那么,测试团队需要在这次泄露以后做分析了。
  3. 没有需求分析员居然成为理所当然。
    在这样的氛围下,"借鉴"别人的成为了理所当然!为什么中国团队在不停的抄袭,未曾超越。将需求分析员独立出去,而不是拉入测试或者开发团队。且需求分析员先于测试和开发编写文档,以保证需求文档的及时性。
    无论是国内的单独某家公司还是国内的整体情况,都是如此。比如,腾讯游戏,抄袭可谓无所不及了。(好吧,魔兽世界他还是没有办法抄袭的!)又比如,国内的各种微博,SNS,视频网站,在国外都能够找到鼻祖。没有看到中国特色且自己喜欢的网站,除了豆瓣。但是豆瓣网站还是处在如此纠结的地方,开发出来的新产品,却一点都不考虑用户的体验,好几个产品弄得一塌糊涂,�惶得很。
  4. 关于招聘。
    对于招聘的时候,NB的人要价很高。本来就是,物以稀为贵。此外,能够帮你解决一堆问题的人,你为何要吝啬你那几个钱?而且,按照Joel的理论,一个优秀的程序员能够顶替3个一般的程序员,已经不再是所谓的"三个臭皮匠,顶个诸葛亮"的世界了。按照这样的计算,3倍工资也不为过。而且,3个程序员带来的价值并不是简单1+1+1=3,而是小于3的。
  5. 英语很重要,沟通很重要。
    邀请外援过来培训,效果不是很理想,结果不怪自己不行,在吐槽如何如何听不懂。无论你描述的多么凄惨,多么可笑,无法掩饰你自己能力不行的事实。
  6. 测试的跨度很大
    测试的跨度很大,有相通之处,却很难从IT瞬间转移到IC行业。可能说,管理上面,有些类似之处,但是底层/前线人员,却是很难很难。会上测试人员分布从软件到硬件,从敏捷模式到V模式,都有,显得很杂、很乱。
  7. 变更管理和监测是很重要的。
    基于变更的测试才是快,狠,准的。基于自动化工具,快速定位regression测试范围,即基于变更进行相应的测试。
吐槽完毕。
0
Posted on Saturday, February 11, 2012 by 醉·醉·鱼 and labeled under