開發人員談測試

此文是應一位密友之約寫的，我並不是專業測試人員，做過的測試也不多，但此文還是值得一看，因為我最不願意乾的事情就是寫那些讓人看了入睡的文章，所以你可以把本文當作一篇散文，聽我這個落魄的開發人員談談自己的經曆和感受。

周正龍：我的虎照沒有任何bug。
網民：沒有？我看顏色就不對。
周正龍：有什麼不對？我用兩部相機拍的呢。
網民：角度也很怪異。
周正龍：我冒著生命危險拍出來的。
網民：怎麼老虎一動不動？
周正龍：保證沒有問題。
網民：那你公開其它的照片。
周正龍：不行，有著作權的。
網民：哈哈，我找到了老虎年畫。
周正龍：你們造謠，我的虎照絕對沒bug，人頭擔保！
網民：……

我認為軟體測試的痛點並不在於技術，那麼是什嗎？開發人員和測試人員永遠是一對矛盾，這才是最大的痛點。why？開發人員說：“我寫出來的東西完美無缺。”測試人員：“胡說八道，我立即找一堆bug出來！”所以如何協調開發人員和測試人員，那就真的得憑一些本事了，我並不是一個處理人際關係的專家，否則也不會淪落到今天這種只能寫一些自娛自樂無人欣賞的代碼的這種地步了，但有一點算我的經驗吧，那就是嘗試讓開發人員把測試人員看作協助自己提高軟體品質的朋友，而不是專門找茬的敵人，也嘗試讓測試人員把開發人員當作為自己提供測試遊戲的知己，而不是只會製造麻煩而又拒絕承認錯誤的痞子。和周正龍不同，開發人員一般都不是明知故犯，只不過堅持自己是對的跟周先生那種執著有點像……請勿對號入座。

某開發男：“我檢查過了，程式絕對沒問題……什嗎？測試報告？寫那麼多麻煩東西，有病！”

有些人認為：開發人員同時也可以作為測試人員，所以沒有必要僱用額外的測試人員。這個觀點我曾經同意過，但現在我是不以為然，很重要的一個原因：用同樣的方式做出來的事情就非常有可能產生同樣的錯誤，因此開發人員是很難很難發現自己的bug的。作為開發人員中的一員，我很瞭解這種心態，那就是不高興承認自己的錯誤，只要程式按照自己的方式去運行，正確了就“測試通過”了，幾乎沒有考慮太多的情況，所以在測試人員較少的公司，一種比較好的變通的辦法就是“交叉測試”，我測你的，你測我的，但這種方法能發現的問題也比較有限。僱用測試人員，還有一個也是很重要很重要的原因：絕大多數開發人員不願意寫測試文檔。其實不光是測試文檔了，凡是文檔都不太願意去寫，這不是個別，這幾乎是個通病，就算強迫開發人員把文檔寫出來，恐怕品質也是令人不敢恭維，所以我們需要測試專員，專業的測試人員是軟體品質的重要保證。微軟公司的測試人員跟開發人員的比例在2到3之間，也就是一個開發人員，就對應兩到三個測試人員，沒有那麼多測試人員，我不相信Windows能這麼流行。這也就是說：測試人員要做一些開發人員不太願意做的工作，反過來說也行啊，開發人員要做一些測試人員不願意做的工作，反正就那意思，專人專事。

某測試男：“測試報告，你的程式錯漏百出，報告完畢！”

和開發人員一樣，測試人員的水平同樣有高有低，我見過高水平的，也見過低水平的，區分他們並不難，只需要看看他們的測試報告，對程式碼精通的開發人員閱讀這些測試報告並不是一件難事，測試人員的水平能很快就看出來了，為什麼別的不看，就看測試報告？很簡單，測試報告對於測試人員來說，就相當於是開發人員的產生代碼，內行人看看不就懂了嗎？你也許見過很多優秀的測試報告，但可能你沒見過這麼差的測試報告（BTW，我有一個朋友說：“沒有最差，只有更差。”），我曾經寫過一個小型遊戲伺服器程式，負責隨機發牌這種功能，拿給測試組測試，測試好了之後，我發現只有一條bug記錄，但嚴重度為最高，這個報告這樣寫：“幾率完全不在控制中，程式錯漏百出！”我保證你沒看錯，對，這就是他的測試報告，只有一行字，看完後我差點暈倒，這行字我完全看不出我辛辛苦苦寫的程式到底出了什麼問題，換成你估計你也不行，更何況他還說“錯漏百出”呢，卻只有一條bug記錄！為什麼會有這種低水平的人從事測試工作？那就是對軟體測試不夠重視，很多公司認為會用電腦的人都能做測試，其實不是這樣的。我接觸過一個有些水平的測試人員，他有過兩年測試經驗，確實就不一樣，我把我的程式交給他，測試完之後，他給我遞交的測試報告中有十多條bug記錄，我一開始也不太相信我的程式怎麼會有那麼多問題？但後來仔細看之後確實發覺自己很多地方做得不到位，他的測試報告非常好，測試手段也比較高明，比如我的程式在運行過程中頻繁切換視窗會導致的問題，在Windows98下偶爾出現的聲音異常問題（當時開發使用Windows XP系統），程式啟動視窗位置不妥影響外觀的問題等等，他都測試了出來，除了bug記錄，還有大約七八十條測試記錄，大多數都標記為pass，每條記錄都有足夠詳細的測試步驟和環境，我認為他工作很認真，可惜後來他離開公司比較早，跟他交流也就比較有限了。當然，並不是所有的bug都是開發人員的過錯，偶爾可能是測試人員對功能的誤解，或者測試機器上的電腦確實有比較嚴重的問題，這樣經過驗證協商，我們都可以把bug記錄close掉，這都是有依據可循的，而不是一個“錯漏百出”就了事那麼簡單，如果是這樣的話，那測試這個工作也未免太容易了。

測試：快來看看，我發現bug了，這怎麼回事？
開發：來了來了……哪裡？
測試：嗯？怎麼沒了？
開發：下次看清楚點再說。
……片刻……
測試：現在出現了，快來看看！
開發：好，馬上過去……哪？
測試：怎麼又沒了！
開發：……

這種情況我以前遇到太多次了，寫過程式的人都有這個體會，有些bug的出現機會是非常非常寶貴的，因為程式運行總是帶有很大的隨機性，也許這個bug在某個時間才會被觸發，或者根本就是低機率隨機，特別是用C++寫的程式，這種問題尤其多，當然隨著我經驗的不斷上升，我以前曾經寫出過的bug，現在是越來越少了，我知道如何從代碼這個層面上避免出現這種問題，（這個不在本文討論之列）但即便如此，我也難保證到了測試人員手裡一定不出現。反應測試人員水平的還有一個重要指標：就是重現bug的能力。水平高的測試人員能很好地記錄bug出現地條件，就好像每次空難的時候，黑匣子總是能很好地協助事後處理人員找出空難當時的飛機運行情況以及環境參數，以此推測，為什麼會出事。如果真的是一個很難重現的bug，就像前面說的，根本就是低機率隨機的，那怎麼辦？那就想辦法把bug描述清楚，以的形式記錄出錯現象，用清晰簡要的文字，描述清楚當時的運行情況，這是測試人員該做的事情，而不是bug“跑過去就沒了”。有些問題確實很難發現，甚至解決了都不知道其所以，我最近寫了一個程式，這個程式會載入若干個模組，從模組中調出資源，將資源存入記憶體中，按道理，這個時候我可以卸載模組了，因為我要的資源已經到位了，接下去我要使用這些資源，就是把它們轉變為流，再去調用別的介面，但出現問題了，在載入/卸載若干次之後，Allways出現一個錯誤，通過調試，這個錯誤發生在CreateWindow這個Windows API的內部，如果從表面上看，這已經是超出了我的能力範疇，但我知道，這僅僅是表面，其實質一定是在調用到CreateWindow之前，就出現了記憶體越界之類的錯誤，但我細心測試了我的程式，所有可能出錯的地方都排除了，My Code既沒有越界，也沒有泄漏，但問題最後還是解決了，很簡單，就是把卸載模組這行代碼，挪到使用完記憶體中的資源之後，就沒再出現過這個問題，按照邏輯，我一直想不通為什麼會這樣，我使用的資源是已經調入我的程式動態分配的記憶體空間中了，應該跟模組沒有什麼聯絡了，可經過大量的測試，發現這麼改之後就沒再出現過問題，我知道我還是沒法完全理解這個複雜的系統，儘管我盡了最大努力。測試人員也是這樣的，不能重現所有bug，但他們可以盡量去記錄bug發生的各種情況，對於修正bug的開發人員來說，當然是越詳細的資訊越好。

“你相不相信我的測試結果？你的程式在所有使用華碩主板的機器上會死掉，其它的就沒事。”

相信不？不相信？親眼看看後，我還真的相信了，但一直不知道原因，這個問題確實是我曾經遇到過的問題，也是我遇到過的所有問題中最怪的問題之一，這還真的被一個測試者“總結”了出來，對他來說，能總結出這個問題，非常不容易，為了驗證是否的確如此，我還找了一台華碩的膝上型電腦來測試，還真的如此！我也很想知道原因，可我現在還是不知道，而我離開那家公司很久了，我也許之後也永遠不知道了，我說這個例子，目的是想告訴大家，有時候真的沒有什麼“不可能”，所以請不要隨便懷疑測試人員總結出來的那些稀奇古怪的bug，表面上的一個bug，也許可以牽扯到非常深層次的問題。

我也不知道再談點什麼好，測試載入器，測試流程，這些我想別的地方講得太多了，但，軟體業有一條黃金法則，那就是“沒有銀彈”，再好的測試載入器，再精密嚴謹的流程，最終都是人在使用，人在執行，沒有一種足夠強大的工具來完全替代開發人員的工作，對於測試人員來說，也是這樣的！除了對工具的引進，流程的改進，更應該重視人員自身能力的提高，我想這也不光是軟體行業了。