一个软件测试工程师"悲惨"的加班经历
作者:管理员 发布时间:[ 2010/1/28 ] 推荐标签:
写下这段流水帐似的加班经历,并不是因为无聊。只是老婆要我交待,一个“臭”(这个字眼只有很少机会享用)做软件的,老是这么晚回来,究竟在外面做些什么。如果哪天你也被要求写这样的材料,你可以参考;除了这个作用以外,或许,不同的人会从中看到不同的东西吧。
背景:
我们的软件产品需要在A、B、C三种硬件平台(理论上对我们的软件影响是不大的)上工作,早些时候已经成功在A上工作了,但在B、C上还有些问题,加班的那天是一个deadline,需要保证在B、C上也能够工作。这个产品由X、Y、Z三个部分组成,分别由三个team负责,基本的关系是:X和用户打交道,X调用Y,Y是数据进数据出,Y调用Z,Z和硬件打交道。
其中,X和Y都是新写的程序,而且早些时候,在X上发现了较多BUG,Y基本上没发现问题。Z的代码在以前的产品中有,相对已经比较稳定。由于项目的时间压力,这三个部分没有时间做分别的测试,只是程序员简单测一下自己的代码后,要集成和测试了(这是我的具体工作)。除了三个team的leader留下外,X的程序员都留下了;Y的leader检查了team members的工作后,认为没什么问题放他们回家了;Z的leader“无辜”,目送所有手下下班后,自己不得不留下。
都是指针惹的祸:
一开始要加班是因为X的工作还没有完成,于是大家一边等,一边“催”(X的leader声称要到12点才能完成,真是乌鸦嘴),一边各忙各的(我在上网看新闻)。事实上,X到7点多完成了,但一测试发现有明显的内存访问问题。于是X调试,由于X在内存访问问题上已经“臭名昭著”了,所以大家(至少我)相信是以前类似的问题,或者是以前的修改没有彻底。
但很快,X发现问题是:Y传了一个空指针给X;很快,Y也证实了X的说法。大家责问Y,为什么程序员自己测试时没有发现?其实很简单,程序员的单元测试程序会检查是否是空指针,如果空打印空行。于是,X和Y开始“踢球”,互相要对方加上空指针的错误处理代码;但踢了一会后,新的疑问出现了,Y照理不应该出现空指针,所以要么Y的代码有问题,要么Y要证明自己没错。
找一个BUG好难:
于是Y的leader也加入了调试队伍,因为Y的代码都有详细的Log,所以很快定位到了他的一个team member的代码里。不幸的是,Y learder的开发机器在关键时刻down掉了。好在我们初步实施了软件配置管理,Y leader很快在别人的机器上重新搭建好了调试环境。
Y作了些修改(事实上,他改的这些代码都是无关紧要的),经我测试后,发现还是不行。以我的职业感觉,我觉得X也有问题(后来知道是歪打正着)。但X宁可上sina看“北京某景区有人裸泳”也不肯检查一下自己的代码。Y经过艰苦的调试(其实绝大部分时间我想是在理解这些不属于他的代码),发现是因为某个数据没有取得而导致了空指针的出现,但照理,Z应该总是把这项数据传送给Y的。但Y对Z的“指控”很快被证明是无效的,因为Z leader向大家“展示”了她从硬件取得的数据是好好的。
于是,Z leader继续吃饼干;Y leader继续调试;X一干人等继续“研究”我国风景区的管理问题。而我也终于无聊到了极点,开始“友情赞助”,检查Y的问题代码。代码很少注释,写得也很随意,甚至缩进的格式都显林乱;但好在代码不长,逻辑也不复杂。我重点检查了内存的操作,但没有发现问题。
正在我纳闷同样一段代码,为什么其他数据都可以取得,偏偏这项数据取不到的时候,传来了Y learder的叫声。虽然听起来很像绝望后的惨叫,但我敢肯定,这的确是找到真正问题后的欢呼(和惨叫相似也是情理之中,毕竟都是在身心及其疲惫后发出的)。果然,他发现了:这项取不到的数据的名称写错了,应该是Status,但写成了State。(Y向Z要数据时,要传给Z一个数据的名称,然后Z从硬件取得,并返回给Y。这些数据的名称是Z定义的)那么,怎么会发生这种低级错误的呢?原来,出错的代码Y的那个程序员从另外一处Copy来的,其他数据项的名称都是相同的,偏偏这项数据的名称不同。
有多少Code可以重来: Y leader忙着改C文件和H文件,因为这个数据项的名称出现在多处,所以Y leader改得很仔细,也很辛苦;我想他心里一定在臭骂他的这个team member,为什么不定义一个常量或者宏。在Y leader改代码的时候,我也在想,这简直像Z在故意制造陷阱:这两组数据这么类似,而且其他数据项的名称都相同,为什么偏偏这项数据,一个叫State,另一个叫Status,真是有空,真TMD。
Y leader终于确认改正了所有该改的State。但用他的team member的单元测试程序一测发现还是有老问题。你可以想象到我们当时的感觉,像吃了一吨广告上那个很夸张的“凉”得透顶的润喉糖。
但是!Y leader大叫:单元测试程序里的State也要改成Status。在无数双眼睛的注视下,Y leader颤抖着replace all,save,F5。终于,当大家看到计算机上的一串字符后,每个人都舒心的笑了。(当然,如果没有刚才的虚惊一场,可能不是每个人都在快工作到午夜的时候还能笑得动的)。我想,此时此刻,此情此景,在Y leader的眼里,一定滚动着些东西,除了眼屎。
现在,又轮到我上场了。Build时发现X的代码中也需要把一些State改成Status。(如果当初他们也检查一下好了)。X的程序员也没有定义常量或者宏的习惯,所以我Build了多次,他们才把所有要改的State改掉。
一个QA的精彩:
后来发生的事可以用一个“峰回路转”来形容,在无数双眼睛的注视下(我的手没有颤抖,因为人已经麻木了,或者说一切都习惯了),我启动了我们的软件,连接到B平台上,检查所有的数据,全部OK;连接到C平台上,检查所有的数据,全部OK。搞定了!
“回家,回家,回家的感觉是多么多么……”,我想,当时,也许每个人的心里都在回荡着王杰的这首老歌(如果知道这首歌的话),包括陪我们加班到深夜的可怜的老板。
当其他人已打算转身时,我的思想在激励的斗争着。看着同事们的脸,包括老板沧桑的脸和几张幼稚却不显年轻的程序员的脸,想着家里没能见到老爸的孩子,我想回家,但是,我是QA。我默默的连上了A平台,然后发现什么数据都没有。(如果把这个场景定格或者淡出,我怎么想都觉得象好莱坞预示续集的结尾)。
当我喊住大家时,我不知道该如何描述自己的感受。
无声,无声,又见无声!突然,老板告诉大家:的deadline搞定B和C平台可以了,A平台下个礼拜再说。管他是真是假,老板发话可以了,还不开溜。3分钟后(其中半分钟是给CVS打上Tag),我坐上了回家的Taxi。
凌晨一点的上海还是霓虹闪烁,好美。
后记:
本文纯属虚构,如有雷同,实属巧合。
(事实上,本文99.99%是真实的,除了一些艺术加工,如果算得上“艺术”的话。我只是不想我的可爱的可敬的同事们发现我在背后骂他们乌鸦嘴和TMD)
背景:
我们的软件产品需要在A、B、C三种硬件平台(理论上对我们的软件影响是不大的)上工作,早些时候已经成功在A上工作了,但在B、C上还有些问题,加班的那天是一个deadline,需要保证在B、C上也能够工作。这个产品由X、Y、Z三个部分组成,分别由三个team负责,基本的关系是:X和用户打交道,X调用Y,Y是数据进数据出,Y调用Z,Z和硬件打交道。
其中,X和Y都是新写的程序,而且早些时候,在X上发现了较多BUG,Y基本上没发现问题。Z的代码在以前的产品中有,相对已经比较稳定。由于项目的时间压力,这三个部分没有时间做分别的测试,只是程序员简单测一下自己的代码后,要集成和测试了(这是我的具体工作)。除了三个team的leader留下外,X的程序员都留下了;Y的leader检查了team members的工作后,认为没什么问题放他们回家了;Z的leader“无辜”,目送所有手下下班后,自己不得不留下。
都是指针惹的祸:
一开始要加班是因为X的工作还没有完成,于是大家一边等,一边“催”(X的leader声称要到12点才能完成,真是乌鸦嘴),一边各忙各的(我在上网看新闻)。事实上,X到7点多完成了,但一测试发现有明显的内存访问问题。于是X调试,由于X在内存访问问题上已经“臭名昭著”了,所以大家(至少我)相信是以前类似的问题,或者是以前的修改没有彻底。
但很快,X发现问题是:Y传了一个空指针给X;很快,Y也证实了X的说法。大家责问Y,为什么程序员自己测试时没有发现?其实很简单,程序员的单元测试程序会检查是否是空指针,如果空打印空行。于是,X和Y开始“踢球”,互相要对方加上空指针的错误处理代码;但踢了一会后,新的疑问出现了,Y照理不应该出现空指针,所以要么Y的代码有问题,要么Y要证明自己没错。
找一个BUG好难:
于是Y的leader也加入了调试队伍,因为Y的代码都有详细的Log,所以很快定位到了他的一个team member的代码里。不幸的是,Y learder的开发机器在关键时刻down掉了。好在我们初步实施了软件配置管理,Y leader很快在别人的机器上重新搭建好了调试环境。
Y作了些修改(事实上,他改的这些代码都是无关紧要的),经我测试后,发现还是不行。以我的职业感觉,我觉得X也有问题(后来知道是歪打正着)。但X宁可上sina看“北京某景区有人裸泳”也不肯检查一下自己的代码。Y经过艰苦的调试(其实绝大部分时间我想是在理解这些不属于他的代码),发现是因为某个数据没有取得而导致了空指针的出现,但照理,Z应该总是把这项数据传送给Y的。但Y对Z的“指控”很快被证明是无效的,因为Z leader向大家“展示”了她从硬件取得的数据是好好的。
于是,Z leader继续吃饼干;Y leader继续调试;X一干人等继续“研究”我国风景区的管理问题。而我也终于无聊到了极点,开始“友情赞助”,检查Y的问题代码。代码很少注释,写得也很随意,甚至缩进的格式都显林乱;但好在代码不长,逻辑也不复杂。我重点检查了内存的操作,但没有发现问题。
正在我纳闷同样一段代码,为什么其他数据都可以取得,偏偏这项数据取不到的时候,传来了Y learder的叫声。虽然听起来很像绝望后的惨叫,但我敢肯定,这的确是找到真正问题后的欢呼(和惨叫相似也是情理之中,毕竟都是在身心及其疲惫后发出的)。果然,他发现了:这项取不到的数据的名称写错了,应该是Status,但写成了State。(Y向Z要数据时,要传给Z一个数据的名称,然后Z从硬件取得,并返回给Y。这些数据的名称是Z定义的)那么,怎么会发生这种低级错误的呢?原来,出错的代码Y的那个程序员从另外一处Copy来的,其他数据项的名称都是相同的,偏偏这项数据的名称不同。
有多少Code可以重来: Y leader忙着改C文件和H文件,因为这个数据项的名称出现在多处,所以Y leader改得很仔细,也很辛苦;我想他心里一定在臭骂他的这个team member,为什么不定义一个常量或者宏。在Y leader改代码的时候,我也在想,这简直像Z在故意制造陷阱:这两组数据这么类似,而且其他数据项的名称都相同,为什么偏偏这项数据,一个叫State,另一个叫Status,真是有空,真TMD。
Y leader终于确认改正了所有该改的State。但用他的team member的单元测试程序一测发现还是有老问题。你可以想象到我们当时的感觉,像吃了一吨广告上那个很夸张的“凉”得透顶的润喉糖。
但是!Y leader大叫:单元测试程序里的State也要改成Status。在无数双眼睛的注视下,Y leader颤抖着replace all,save,F5。终于,当大家看到计算机上的一串字符后,每个人都舒心的笑了。(当然,如果没有刚才的虚惊一场,可能不是每个人都在快工作到午夜的时候还能笑得动的)。我想,此时此刻,此情此景,在Y leader的眼里,一定滚动着些东西,除了眼屎。
现在,又轮到我上场了。Build时发现X的代码中也需要把一些State改成Status。(如果当初他们也检查一下好了)。X的程序员也没有定义常量或者宏的习惯,所以我Build了多次,他们才把所有要改的State改掉。
一个QA的精彩:
后来发生的事可以用一个“峰回路转”来形容,在无数双眼睛的注视下(我的手没有颤抖,因为人已经麻木了,或者说一切都习惯了),我启动了我们的软件,连接到B平台上,检查所有的数据,全部OK;连接到C平台上,检查所有的数据,全部OK。搞定了!
“回家,回家,回家的感觉是多么多么……”,我想,当时,也许每个人的心里都在回荡着王杰的这首老歌(如果知道这首歌的话),包括陪我们加班到深夜的可怜的老板。
当其他人已打算转身时,我的思想在激励的斗争着。看着同事们的脸,包括老板沧桑的脸和几张幼稚却不显年轻的程序员的脸,想着家里没能见到老爸的孩子,我想回家,但是,我是QA。我默默的连上了A平台,然后发现什么数据都没有。(如果把这个场景定格或者淡出,我怎么想都觉得象好莱坞预示续集的结尾)。
当我喊住大家时,我不知道该如何描述自己的感受。
无声,无声,又见无声!突然,老板告诉大家:的deadline搞定B和C平台可以了,A平台下个礼拜再说。管他是真是假,老板发话可以了,还不开溜。3分钟后(其中半分钟是给CVS打上Tag),我坐上了回家的Taxi。
凌晨一点的上海还是霓虹闪烁,好美。
后记:
本文纯属虚构,如有雷同,实属巧合。
(事实上,本文99.99%是真实的,除了一些艺术加工,如果算得上“艺术”的话。我只是不想我的可爱的可敬的同事们发现我在背后骂他们乌鸦嘴和TMD)
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南