各種測試方法的問題
在 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, 會導致測試程式師小的情況太多, 錯誤時都需要人腦介入, 一一來跟蹤.
- 可是手動測試很慢, 無法反覆使用, 測試步驟可能不一定有規律, 也不一定都能重複.
留言列表
