Keep Thinking! My Yahoo ID-silvercheng2006@yahoo.com

发现误报defect时

上一篇 / 下一篇  2009-01-17 11:11:48 / 个人分类:测试心得

测试中,测试用例失败并不都是因为s/w的designer出错的,有时是因为测试人员的过失所造成的,从而也和designer之间弄出一些尴尬的事情,例如发现report给design的根本不是defect,而是自家的错误。我本人也不例外,在此我说一下我自己测试中碰到的事,还有我自己的一些的做法,也欢迎大虾们指点一二。。。eh。。

1 背景。

我是做交换机的performance、traffic测试,一般都是用模拟器(simulator)模拟用户和其他资源,而被测试对象(SUT)肯定就是交换机了,而且每种resource在交换机和模拟器中都是对应的并且规定了各自的工作范围。有一次在配置环境的时候,我在调试用来跑performance test的脚本的时候。不小心写错了脚本的资源名字,上面已经说过,每一个resouce都定义了它的工作范围;比如把resouce A1 写成了A2,而在交换机如果收到A1上的消息,会发消息给模拟器的B1,如果收到A2的消息,就会发消息给模拟器的B2:

A1-->  SUT -->B1, A2-->  SUT -->B2,

而我本来是想选资源A1,B1的,谁知道错误的写成了A2,B1,无疑会导致了模拟器路由消息发生错误,脚本跑了两次都failed掉;因为当时真的没发现自己犯了这个低级错误,同时因为我没有修改过交换机的配置,也没有去考证交换机的log(如果当时分析过交换机的log,是可以发现我这个低级错误的),我还兴冲冲的以为发现了模拟器中的一个bug,就马上抓了log,定位问题,上午就开了个优先级也挺高的case给模拟器的designer去fix。。。

2 糗事出来啦~~~

那位无辜的同事下午告诉我他在模拟器的code中找不出错误啦,估计他当时也挺无奈的,因为他可能对交换机处理不大熟悉,而我还铁铮铮地告诉他交换机的处理是正确的,问题就是出自模拟器,所以他还得继续找。。。汗~现在想起来还是觉得对不起人家啊!忙完了白天的活,晚上回到家里,我心里还是想着那事,老是觉得不对劲,然后我就重新跑了一遍,打开了很多个窗口去收不同的log,然后逐个分析,发现交换机发出来的消息不是给B1的,而是给B2的。。难道是交换机被人改过啦?我又查了一遍交换机相应的配置,发现没改动过;然后我再回头看我的脚本,发现了我居然写错了资源,把资源改过来后,脚本passed了。。。最后的root cause居然是我的错误,天大的冤情的~恨自己“无良心”啊~~~

3 立刻道歉

意识到自己的错误,我当晚就写信致歉,并打电话留言给designer,告诉他那个脚本的错误源头是我~~明天一早回到公司,收到那个designer也回信了说没事;我还是打电话过去亲口和他道歉,说明一切,也感谢他的帮忙,他说,“没事,解决了就好”,简单而大度的句子!!

4 感想

犯了错误就要马上坦诚的承认,及时的沟通,无论是开发人员还是测试人员都一样,大家都是为同一个公司工作,都是在改善着同一个产品的功能和质量;千万不要对自己的过失羞于出口,就让design折腾一翻算啦,千万不要有这幼稚想法,因为这样不但会导致别的同事浪费更多的精力折腾在不必要的地方,而且到头来别人终会发觉那是你个人的错误,别以为会蒙过去,到时候就不是一句道歉了,别人会瞧不起你的为人!我们做测试的就是要发现错误并如实报告错误,弄清错误所在之处,和开发人员一起努力保证产品的质量,减少cost的消耗。对于自己的错误更是要认真严格对待,这样自己才会对自己的工作更负责任,减少错误!连自己的质量都不能过关,那出来的产品也是一陀没人要的垃圾!

Silver

written @11:00 AM 2009-01-17


TAG: 测试心得

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

我的栏目

日历

« 2020-09-27  
  12345
6789101112
13141516171819
20212223242526
27282930   

数据统计

  • 访问量: 3090
  • 日志数: 8
  • 建立时间: 2009-01-16
  • 更新时间: 2009-02-02

RSS订阅

Open Toolbar