Planning is everything. Plans are nothing! 這是艾森豪將軍的名言. 二次大戰期間, 艾森豪帶領同盟國聯軍, 跨越英倫海峽反敗為勝, 靠的就是縝密的情報蒐集和靈活應變.
我想大家應該都贊同這樣的理念, 專案一開始是要有計劃, 但是更重要的是要隨時隨地在規劃, 以因應各種突發狀況.
同樣地, 在測試方面也是一樣, Testing is everything, tests are nothing. 這是什麼意思呢?
很多時候, 我們要進行測試, 會先制定測試計劃, 接著再開立測試個案, 然後再去執行測試個案.
不是嗎? 大多數人不都是這樣做的嗎? 這有什麼問題呢?
不是的, 測試 (testing) 應該是一個探索 (exploratory)和學習的過程. 他要到處去看看, 去了解受測物的一切, 一邊學習, 一邊去找出問題.
哪我們現在在做的叫什麼呢? 絕大多數的狀況叫做 checking. 也就是說確認 (confirmation) 系統有沒有照 test case 上寫的的狀況運作.
例如: 要測試一個安裝程式. 你可能會開立一個測試個案, 測試以預設值的狀況來安裝是否正確. 因此你可能寫:
[步驟]
執行 setup.exe
當畫面出現時, 一切都使用系統預設值, 因此都是按下 OK 鍵, 讓 setup.exe 來安裝程式
[預期結果]
當 setup.exe 顯示安裝成功的訊息, 就代表系統已經被成功地安裝.
因此, 如果你是 checking 的方式來進行測試, 你就會照上面所寫的一步步執行. 並且照預期結果的項目來檢查. 可是 ….
是否所有 process 安裝完後都有執行起來嗎?
是否所有的 registry key 都已經建立, 並且相關初值都正確?
是否 CPU 沒有一直滿載?
…...
要確認的事情很多, 你可能要去摸索一段時間後, 才知道總共有哪些要檢查. 並且隨著學習到更多系統內部的知識, 你可能會要求做出更多的檢驗.
因此, checking 只是去確認你已經知道的東西對不對, 你只是確定以前檢查過的是否還運作正常, 你只是把上面有寫的照做一次, 沒有寫的你就沒做.
你說, 這樣能找出 bug 嗎? 很難吧, 因為最多就是第一次執行有效; 或者是重新執行去抓到某些修改的 side effect, 否則還真的不容易看到新的問題.
所以, 你的測試應該是要以 testing 的方式來進行, 而非以 checking, 即使你是用自動化的方式來進行, 也無法讓你找到更多 bug ….
因為絕大多數情況你只是在求心安, 因此在騙自己那些 case 跑完, 系統就沒問題了.
全站熱搜
留言列表
