在 Exploratory Software Testig 一書中， James Whittaker在第二章中，提到各種測試方法的不足:
Defect Preventation
從開發人員的角度來說，他們希望藉由 design review， code review， static analysis tool，和 unit test，來增加軟體的質量.
但是作者覺得這些方法都有些根本的問題:
(1) 開發人員通常不是個好的測試人員
- 開發人員想的是"如何才能實現這個功能"，而測試人員則是從"如何才能攻破這個功能" 來思考.
- 因此開發人員會有盲點，需要有另一組人從不同觀點來思考
- 但是不代表開發人員不用作測試，像是 formatting， data validation 和 error handling 等等都需要及時處理和驗證. 等到測試人員發現，時間會花得很長，也修正的代價也很高
(2) 靜止狀態的程式不能完全代表真的測試目標
- 有很多錯誤是和執行環境有關係，通常在開發環境這些錯誤不會發生的
(3) 缺乏客戶真正資料
- 有些錯誤是和客戶真實的資料有關，或者需要實行一段時間後，累積效果出現後才會有問題
- 可是開發人員通常沒有這些資料，並且也沒有這麼長的測試時間，所以無法找出這型別的錯誤
Defect Detection
通常分成手動測試和兩種:
自動化測試
- 測試人員不一定會是好的開發人員，有些人可以，有些人可能不行.
- 測試程式也是會有 bug，一旦出現後，測試人員需要更多時間來除錯，維護它的正確性和強固性. 所以你要花在測試的時間多，還是應該花在維護測試程式的時間多?
- 此外測試程式所在的執行環境，以及所用的測試資料，不是客戶的資料，所以效果還是有限. 並且客戶可能也沒有勇氣，讓你在他的 production 執行.
- Oracle Problem 的問題是最難處理的，也就是當你執行完測試時，你無法確認是否真的實行正確. 像是 install 完畢，甚麼叫做 install 成功，是所有 service 都啟動，是所有檔案都複製完畢，還是所有 registry 寫正確. 你可能無法列的出來， spec 也不會寫甚麼叫做功能運作正確.
手動測試
- 也是由人來進行測試，需要充分發聰明才智，設計出真實客戶環境的資料和使用狀況. 尤其是有關 business logic 更是需要人腦介入.
- 手動測試比自動化測試強的地方，是因為現實狀況有太多不確定的因素，有太多 scenario，會導致測試程式設計師小的情況太多，錯誤時都需要人腦介入，一一來跟蹤.
- 可是手動測試很慢，無法反覆使用，測試步驟可能不一定有規律，也不一定都能重複.

本文轉自：

各種測試方法的問題

相關文章