自己寫程式往往有兩個盲點:測試資源不夠,因而難以全盤瞭解用戶使用情形的全貌;另一個則是只有自己跟自己對話時,往往難以做出正確的判斷和決定。無論個人或團隊開發,都有各自的優缺點。
複雜程式的不確定性
懂得電腦運作原理的人都知道,它的運作是一種「決定性」(deterministic)的機制。簡單的說,程式碼一但寫成,就決定了運作的順序;原則上只要給定同樣的參數,不管重複運作幾次,順序和結果都會是一樣的。
那這裡為什麼會提到不確定性呢?
雖然運作的本質沒變,但是當外部環境的輸入有變化時,程式碼的運作途徑 (execution paths)就會大不相同;所以在全部的程式碼中,實際真正會運算到的比例(或從另一個角度來說,就是「可以被人為測試到的」),就稱為「覆蓋率」(code coverage)。
舉微軟的Word為例子,它的覆蓋率約略只有30%左右。問題的核心是我們開發者並不知道:
在終端使用者的環境當中,倒底是哪30%會被用到,這就是不確定的所在。
最近寫的程式也面臨了同一個問題:由於使用者操作介面的複雜度超高,有各種各樣的邊界條件要處裡,而我的測試資源非常有限(就是我一個人而已),那麼我應該把重兵放在哪裡?
本文已獲作者授權並經本站重新編輯,未經書面許可禁止轉載。本站文章提供付費授權轉載或出版,請參閱
授權說明、或來信
ask@tuna.to 洽詢。如果您喜歡這篇文章,請按「喜愛」圖像、也歡迎分享到社群網站上!