一个软件测试工程师的加班经历
　

---

和所有正在做测试的、或将要做测试的兄弟姐妹们分享

一个软件测试工程师的加班经历

转自于PMT Community。PMT致力于软件技术和管理的研究与实践，旨在鼓励并促进软件从业人员的交流、合作和职业化。欢迎访问 http://www.pmtsolution.net

写下这段流水帐似的周末加班经历，并不是因为无聊。只是老婆要我交待，一个“臭”（这个字眼只有很少机会享用）做软件的，老是这么晚回来，究竟在外面做些什么。如果哪天你也被要求写这样的材料，你可以参考；除了这个作用以外，或许，不同的人会从中看到不同的东西吧。

（此处删除了向老婆表忠心的500字）

背景：

我们的软件产品需要在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。）


　

而且水平如此低的程序员应该立刻fire掉，或者重新培训。
写完模块应该立刻由至少两个人阅读并单步调试。

好的设计与好的CODE习惯对质量很重要

大家能想到什么呢?

 回复: 一个软件测试工程师的加班经历
　

---

我也深受其苦，那些人真TMD！

 好的设计与好的CODE习惯是软件公司的一大财富
　

---

现在随着OO实践的深入,从做一个质量过硬的软件产品的角度出发,不知不觉养成一些习惯(吃力不讨BOSS的好,CODER也反感的习惯)
1.定义整个系统的错误代码,供全体开发人员使用(增加设计工作量,BOSS反对)
2.在业务类中定义了不得Check(),Check**()之类的方法(增加代码量CODER反对)
3.在方法中尽量用TRY...CATCH的形式,接受参数时用条件语句判定合法性(啰里八唆CODER反对)
写可控性安全性的代码JAVA,C#程序员易接受,而C/C++程序员不是很习惯,假如" 一个软件测试工程师的加班经历"文中的开发人员都有以上习惯,测试维护的代价也许会少好多