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

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

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

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

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