关闭

51Testing丛书连载:(十一)软件测试精要

发表于:2009-4-17 17:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:董杰    来源:51Testing软件测试网

上一节:Troubleshooting——51Testing丛书连载:(十)软件测试精要

  案例:一个ATM性能bug定位的故事

  当时我们搭建了一个由数十台辅助测试的发包路由器和两台专业性能测试仪器Smartbits构造压力流量的测试环境,确保设备ATM卡所能支持的所有通道数和最大带宽都达到了上限。在压力测试早期,48小时过去了,ATM卡依然正常地工作着,没有任何异常。但在第3天,我们忽然发现ATM卡重启了,ATM卡的协议开发人员和驱动人员都立刻来到了现场进行信息收集,在忙碌了三四个小时的信息收集和分析后,大家都没有在现场找到问题的原因。于是开发人员又回去分析讨论定位重现方案,最后他们在代码中新添加了一些辅助定位的打印信息,希望能在问题再现时,打印出更详细的信息以供定位。

  于是我们开始了第一次的问题重现,压力测试继续跑起来,可是让人失望的是居然在72小时内都没有重现该问题。不过,我们没有把压力测试停下来,而是继续下去。在第5天,问题终于重现了,这次来现场收集信息的人更多了,当然问题发生时各模块统计打印的信息也更多、更全。后来经过开发人员2天的会诊,最后定位到了原来是驱动层的数据转发的发送指针跑到接收指针的前面去了,发送指针的调度速度比接收指针的调度速度快了。

  之后我们开始了对该问题解决结果的验证,可奇怪的事又发生了,在测试的第2天设备又重启了。很多开发人员又跑来定位,大家都觉得不可思议。难道分析判断错了吗?大家带着极大的疑问,仔细地看完了所有的打印数据,发现这次的出错数据与上次的问题又不一样了。难道又有新问题发生了?开发人员又在代码中加入了更多的打印信息。

  第三次问题重现又开始了,这次还好在测试的第3天重现了第二个问题。开发人员看了自己第二次加入的打印信息后,感到非常迷茫,“不可能,不可能啊”是挂在他们口中的惊讶。原来他们从打印的信息中发现居然转发芯片不工作了,导致上层驱动的指针又飞了,才导致设备重启的。可转发芯片怎么不工作了呢?没办法,开发人员只好把所有现场收集到的数据拿回去分析研究。几天后,他们得出了一个自己都觉得很奇怪的结论:芯片在停止工作前,收到了错误的ATM协议报文。可是错误的ATM协议报文是从哪里来的呢?由报文的源地址来源判断,居然是我们的测试用路由器产生的。原来,由于中低端路由器本身CPU频率不高,在长时间进行数据包构造后,在某一时刻把一个没有构造完全的残缺数据包发送出来了,导致ATM卡收到了一个自己从未预料到的报文结构,ATM芯片无法处理而停止转动。后经由芯片厂商确认,证实了确实是芯片的问题。我方的开发人员只好通过软件来补救芯片解决该问题。

  第四次问题重现开始了,这次的重现既要验证发送指针跑到接收指针前面去的问题,又要同时验证补救芯片代码的实现。幸运的是,这次压力测试在经历了连续10天的测试后,ATM卡依然安然无恙。虽然中间观察到了几次瞬间复位的状态,但毕竟没有出现整个ATM卡重启或瘫痪的情况。现在看来前期发现的两个问题都应该被解决了。

  这个案例是笔者测试职业生涯早期印象特别深刻的,印象深刻的原因就在于问题出现现象的诡异性,问题出现的场景及触发条件让人很难事先预料到。这场战斗持续了近1个月的时间,让开发人员多个夜晚加班分析,那段时间在笔者的办公桌边总是有几个人陪着一起盯着屏幕上不断打印出的各种信息,心里期盼着早点看到自己想看到的信息,可是偏偏信息就是不出现,而且出现的还不是自己想看到的信息,却是一个新麻烦的开始。在这个案例中的两个bug,都不是那种只要找到逻辑就能马上复现的bug。而是那种需要在某种临界瞬时状态下才会出现的问题,也就是大家最爱说的不易重现的问题。也正是这场bug定位战斗,让笔者坚信了一个真理:“没有重现不了的bug”。所以,以后只要有新员工对笔者说“这个bug不能重现”,笔者就会马上纠正他,应该是“这个bug不易重现,世上没有不能重现的bug”。

  在以后的测试工作中,渐渐的在一次次找到“不易重现的bug”的必现原因和最小必现操作步骤后,笔者发现自己越来越自信了,越来越坚信自己的结论“没有重现不了的bug”,并且喜欢上了分析定位bug的过程,以及成功后给自己带来的成功感和业务水平上的提高。而且有时参与一个难重现和分析bug的过程,可以让测试人员把整个产品的内部实现流程和主模块实现原理全部都深入地学习一遍,其理解和感受之深刻,是看任何静态资料都无法达到的效果。如果要说在测试工作中,笔者最愿意让领导分配的工作是什么?那就是非常高兴地听到领导说:“董杰,那边又出现了一个难分析定位的bug,帮他们重现和定位一下吧。”一场战斗又打响了!

  最后总结Troubleshooting的核心是:

  ● 头脑要清晰,思维要收敛,而非发散。

  ● 与开发人员保持良好、准确的沟通。

  ● 细心、耐心。

  ● 不轻言放弃,即使开发人员也快失去了信心,你也不要放弃。

  ● 自信,有些低水平的开发人员分析定位问题的能力比测试人员要弱。

本文选自《51Testing软件测试作品系列》之四的《软件测试精要》

本站经电子工业出版社和作者的授权,近期将进行部分章节的连载,敬请期待!

版权声明:51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。

任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

相关阅读:

查看本书介绍 >>

查看本书其 他章节连载 >>

查看软件测试作品系列其 他书籍 >>

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号