一秋草木

???? 可以考慮一下倘若編譯程序能夠正確地指出代碼中的所有問題，那相應(yīng)程序的錯誤情況會怎樣？這不單指語法錯誤，還包括程序中的任何問題，不管它有多么隱蔽。例如，假定程序中有“差1”錯誤，編譯程序可以采用某種方法將其查出，并給出如下的錯誤信息

-> line 23: while (i<=j)

off by one error: this should be '<'

又如，編譯程序可以發(fā)現(xiàn)算法中有下面的錯誤：

???-> line 42: int itoa(int i, char* str)

algorithm error: itoa fails when i is -32768

再如，當(dāng)出現(xiàn)了參數(shù)傳遞錯誤時，編譯程序可以給出如下的錯誤信息：

-> line 318: strCopy = memcpy(malloc(length), str, length);

Invalid argument: memcpy fails when malloc returns NULL

好了，要求編譯程序能夠做到這一程度似乎有點過分。但如編譯程序真能做到這些，可以想象編寫無錯程序會變得多么容易。那簡直是小事一樁，和當(dāng)前程序員的一般作法真沒法比。

假如在間諜衛(wèi)星上用攝像機對準(zhǔn)某個典型的軟件車間．就會看到程序員們正弓著身子趴在鍵盤上跟蹤錯誤；旁邊，測試者正在對剛作出的內(nèi)部版本發(fā)起攻擊，輪番轟炸式地輸入人量的數(shù)據(jù)以求找出新的錯誤。你還會發(fā)現(xiàn)，測試員正在檢查老版本的錯誤是否溜進了新版本。可以推想，這種查錯方法比用上面的假想編譯程序進行查錯要花費大得多的工作量、確實如此，而且它還要有點運氣。

運氣？

是的，運氣。測試者之所以能夠發(fā)現(xiàn)錯誤，不正是因為他注意到了諸如某個數(shù)不對、某個功能沒按所期望的方式工作或者程序癱瘓這些現(xiàn)象嗎？再看看上面的假想編譯程序給出的上述錯誤：程序雖然有了“差1”錯誤，但如果它仍能工作，那么測試者能看得出來嗎？就算看得出來，那么另外兩個錯誤呢？

這聽起來好象很可怕但測試人員就是這樣做的大量給程序輸入數(shù)據(jù)，希望潛在的錯誤能夠亮相。“噢，不！我們測試人員的工作可不這么簡單，我們還要使用代碼覆蓋工具、自動的測試集、隨機的“猴”程序、抽點打印或其他什么的”。也許是這樣，但還是讓我們來看看這些工具究竟做了些什么吧！覆蓋分析工具能夠指明程序中哪些部分未被測試到，測試人員可以使用這一信息派生出新的測試用例。至于其它的工具無非都是“輸入數(shù)據(jù)、觀察結(jié)果”這一策略的自動化。

??? 請不要產(chǎn)生誤解，我并不是說測試人員的所作所為都是錯誤的。我只是說利用黑箱方法所能做的只是往程序里填數(shù)據(jù)，并看它彈出什么。這就好比確定一個人是不是瘋子一樣。問一些問題，得到回答后進行判斷。但這樣還是不能確定此人是不是瘋子。因為我們沒法知道其頭腦中在想些什么。你總會這樣地問自己：“我問的問題夠嗎？我問的問題對嗎……”。