一個軟件測試工程師的加班經歷
2019-11-18 11:51:24
供稿：網友
背景：
我們的軟件產品需要在A、B、C三種硬件平臺（理論上對我們的軟件影響是不大的）上工作，早些時候已經成功在A上工作了，但在B、C上還有些問題，加班的那天是一個deadline，需要保證在B、C上也能夠工作。這個產品由X、Y、Z三個部分組成，分別由三個team負責，基本的關系是：X和用戶打交道，X調用Y，Y是數(shù)據(jù)進數(shù)據(jù)出，Y調用Z，Z和硬件打交道。
其中，X和Y都是新寫的程序，而且早些時候，在X上發(fā)現(xiàn)了較多BUG，Y基本上沒發(fā)現(xiàn)問題。Z的代碼在以前的產品中就有，相對已經比較穩(wěn)定。由于項目的時間壓力，這三個部分沒有時間做分別的測試，只是程序員簡單測一下自己的代碼后，就要集成和測試了（這就是我的具體工作）。除了三個team的leader留下外，X的程序員都留下了；Y的leader檢查了team members的工作后，認為沒什么問題就放他們回家了；Z的leader最“無辜”，目送所有手下下班后，自己不得不留下。
都是指針惹的禍：
一開始要加班是因為X的工作還沒有完成，于是大家就一邊等，一邊“催”（X的leader聲稱要到12點才能完成，真是烏鴉嘴），一邊各忙各的（我在上網看新聞）。事實上，X到7點多就完成了，但一測試發(fā)現(xiàn)有明顯的內存訪問問題。于是X就調試，由于X在內存訪問問題上已經“臭名昭著”了，所以大家（至少我）相信是以前類似的問題，或者是以前的修改沒有徹底。
但很快，X發(fā)現(xiàn)問題是：Y傳了一個空指針給X；很快，Y也證實了X的說法。大家責問Y，為什么程序員自己測試時沒有發(fā)現(xiàn)？其實很簡單，程序員的單元測試程序會檢查是否是空指針，假如空就打印空行。于是，X和Y開始“踢球”，互相要對方加上空指針的錯誤處理代碼；但踢了一會后，新的疑問出現(xiàn)了，Y照理不應該出現(xiàn)空指針，所以要么Y的代碼有問題，要么Y要證實自己沒錯。
找一個BUG好難：
于是Y的leader也加入了調試隊伍，因為Y的代碼都有具體的Log，所以很快就定位到了他的一個team member的代碼里。不幸的是，Y learder的開發(fā)機器在要害時刻down掉了。好在我們初步實施了軟件配置治理，Y leader很快在別人的機器上重新搭建好了調試環(huán)境。
Y作了些修改（事實上，他改的這些代碼都是無關緊要的），經我測試后，發(fā)現(xiàn)還是不行。以我的職業(yè)感覺，我覺得X也有問題（后來知道是歪打正著）。但X寧可上sina看“北京某景區(qū)有人裸泳”也不肯檢查一下自己的代碼。Y經過艱苦的調試（其實絕大部分時間我想是在理解這些不屬于他的代碼），發(fā)現(xiàn)是因為某個數(shù)據(jù)沒有取得而導致了空指針的出現(xiàn)，但照理，Z應該總是把這項數(shù)據(jù)傳送給Y的。但Y對Z的“指控”很快被證實是無效的，因為Z leader向大家“展示”了她從硬件取得的數(shù)據(jù)是好好的。
于是，Z leader繼續(xù)吃餅干；Y leader繼續(xù)調試；X一干人等繼續(xù)“研究”我國風景區(qū)的治理問題。而我也終于無聊到了極點，開始“友情贊助”，檢查Y的問題代碼。代碼很少注釋，寫得也很隨意，甚至縮進的格式都顯林亂；但好在代碼不長，邏輯也不復雜。我重點檢查了內存的操作，但沒有發(fā)現(xiàn)問題。
正在我納悶同樣一段代碼，為什么其他數(shù)據(jù)都可以取得，偏偏這項數(shù)據(jù)取不到的時候，傳來了Y learder的叫聲。雖然聽起來很像絕望后的慘叫，但我敢肯定，這的確是找到真正問題后的歡呼（和慘叫相似也是情理之中，究竟都是在身心及其疲憊后發(fā)出的）。果然，他發(fā)現(xiàn)了：這項取不到的數(shù)據(jù)的名稱寫錯了，應該是Status，但寫成了State。（Y向Z要數(shù)據(jù)時，要傳給Z一個數(shù)據(jù)的名稱，然后Z就從硬件取得，并返回給Y。這些數(shù)據(jù)的名稱是Z定義的）那么，怎么會發(fā)生這種低級錯誤的呢？原來，出錯的代碼Y的那個程序員從另外一處Copy來的，其他數(shù)據(jù)項的名稱都是相同的，偏偏這項數(shù)據(jù)的名稱不同。
有多少Code可以重來：
Y leader忙著改C文件和H文件，因為這個數(shù)據(jù)項的名稱出現(xiàn)在多處，所以Y leader改得很仔細，也很辛勞；我想他心里一定在臭罵他的這個team member，為什么不定義一個常量或者宏。在Y leader改代碼的時候，我也在想，這簡直就像Z在故意制造陷阱：這兩組數(shù)據(jù)這么類似，而且其他數(shù)據(jù)項的名稱都相同，為什么偏偏這項數(shù)據(jù)，一個叫State，另一個叫Status，真是有空，真TMD。
Y leader終于確認改正了所有該改的State。但用他的team member的單元測試程序一測發(fā)現(xiàn)還是有老問題。你可以想象到我們當時的感覺，就像吃了一噸廣告上那個很夸張的“涼”得透頂?shù)臐櫤硖恰?br />
但是！ Y leader大叫：單元測試程序里的State也要改成Status。在無數(shù)雙眼睛的注視下，Y leader顫抖著replace all，save，F(xiàn)5。終于，當大家看到計算機上的一串字符后，每個人都舒心的笑了。（當然，假如沒有剛才的虛驚一場，可能不是每個人都在快工作到午夜的時候還能笑得動的）。我想，此時此刻，此情此景，在Y leader的眼里，一定滾動著些東西，除了眼屎。
現(xiàn)在，又輪到我上場了。Build時發(fā)現(xiàn)X的代碼中也需要把一些State改成Status。（假如當初他們也檢查一下就好了）。X的程序員也沒有定義常量或者宏的習慣，所以我Build了多次，他們才把所有要改的State改掉。
一個QA的出色：
后來發(fā)生的事可以用一個“峰回路轉”來形容，在無數(shù)雙眼睛的注視下（我的手沒有顫抖，因為人已經麻木了，或者說一切都習慣了），我啟動了我們的軟件，連接到B平臺上，檢查所有的數(shù)據(jù)，全部OK；連接到C平臺上，檢查所有的數(shù)據(jù)，全部OK。搞定了！
“回家，回家，回家的感覺是多么多么……”，我想，當時，也許每個人的心里都在回蕩著王杰的這首老歌（假如知道這首歌的話），包括陪我們加班到深夜的可憐的老板。
當其他人已打算轉身時，我的思想在激勵的斗爭著?？粗聜兊哪?，包括老板滄桑的臉和幾張幼稚卻不顯年輕的程序員的臉，想著家里一天沒能見到老爸的孩子，我想回家，但是，我是QA。我默默的連上了A平臺，然后發(fā)現(xiàn)什么數(shù)據(jù)都沒有。（假如把這個場景定格或者淡出，我怎么想都覺得象好萊塢預示續(xù)集的結尾）。
當我喊住大家時，我不知道該如何描述自己的感受。
無聲，無聲，又見無聲！忽然，老板告訴大家：今天的deadline搞定B和C平臺就可以了，A平臺下個禮拜再說。管他是真是假，老板發(fā)話就可以了，還不開溜。3分鐘后（其中半分鐘是給CVS打上Tag），我坐上了回家的Taxi。
凌晨一點的上海還是霓虹閃爍，好美。
