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