給我測試案例，其他免談(三)

對於軟體開發人員而言，好的測試案例應該是很有價值的東西，因為如果一個軟體在依據一個測試案例進行測試執行時無法得到正確的預期結果，就知道有某個特定的錯誤存在；而如果這個軟體能在依據所有的測試案例進行測試執行時都得到預期的正確結果，那就不會有人可以說什麼話了，乖乖地付錢給寫程式的人吧。(當然，這必須是針對所謂「好的測試案例」才有意義，否則隨便寫兩、三個測試案例，寫程式的人也可以隨便寫幾行程式就應付自如，只是程式還是無法使用，自欺欺人而已。)

從這個角度來看，會設計「好的測試案例」的人應該在軟體開發團隊裡是有其一定地位的，這種人與一般寫程式的人在心態上就不一樣，大多是以「防禦性」或「預防性」的方式來處理程式邏輯；譬如從來不假設所有可使用的資源(如記憶體)是永遠不會有問題的，因此只要需要任何資源都會先確定這個資源的取得沒有問題才開始動作，否則就進入特殊狀況處理程序。這種人設計的測試案例非常細緻，專門找平常不容易出現的錯誤。(正常狀況都無法得到正確結果的實在不夠資格稱為軟體，真的。)

經驗豐富的軟體從業朋友在工作時是很有樂趣的，旁人只見到高來高去的溝通，而且非常有效率，一點都不八股，同時生產力與品質都有一定的水準(agility?)。在這種環境之下，似乎需求說明文件或需求規格都可以抽象化，文件規模大量減少，幾頁的文圖就可以描述一個應用系統，尤其是不太需要人機介面的核心模組。這些文件原有內容跑到那裡去了？答案是測試案例，那些細緻的、正常狀況下都不會發生的可能預防作為描述，都在測試案例說明裡面。

專家們相信，測試案例與需求規格兩者很可能是相同的東西，就像是拓樸學裡介紹的梅比烏斯帶子(Mobius Strip)，沒有裡面或外面之分；而測試案例比需求規格略佔優勢的地方是，測試案例的描述一般比較明確，需求規格的描述則會弱一些。對軟體開發階段與轉換程序而言，越是明確的描述，越能讓轉換所得的軟體堅實(solid)。這個觀點目前應該是還沒有方法來證明，所以只在提出與討論的階段；雖然有可能是亂想一通(研究的過程之一)，但感覺上似乎不離譜。

你的看法如何呢？難道只是又把需求分析的工作藏到測試案例設計去了？