一個軟件測試工程師的加班經歷
寫下這段流水帳似的周末加班經歷，并不是因為無聊。只是老婆要我交待，一個“臭”（這個字眼只有很少機會享用）做軟件的，老是這么晚回來，究竟在外面做些什么。如果哪天你也被要求寫這樣的材料，你可以參考；除了這個作用以外，或許，不同的人會從中看到不同的東西吧。
背景：
我們的軟件產品需要在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。
凌晨一點的上海還是霓虹閃爍，好美。
原文鏈接：http://blog.sina.com.cn/s/blog_5dc6f3810100c1i3.html
【編輯推薦】
