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

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

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

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

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