軟體測試的商機(一)

每次我在課堂上開始介紹軟體測試的目的是要「證明程式中有某一種錯誤」，而不是要表示程式是對(註*)的時候，總是有不少學生會瞪大了眼睛，或是以為我不小心說錯了，或是認為這是一個不可思議的說法，因為這跟自己以往的直覺認知完全不同。

(註*：以目前使用的軟體開發方法而言，一個典型的軟體幾乎不可能沒有錯誤存在。)

其實，軟體測試作法(也就是證明程式中有某一種錯誤)的原理很簡單：假設我們認為一個程式裡存在著一種錯誤 e。我們特意去設計一組輸入資料 I，如果把這組資料輸入到這個程式來執行時應該得到的輸出結果是 O。然後我們真的把這組資料拿給這程式來執行，得到 O' 的輸出結果。如果 O 與 O' 不同，那就證明這個程式果然有 e 這個錯誤。

軟體測試的原理說來簡單，但要想出可能存在的錯誤種類以及設計一組可以找出這種錯誤的輸入資料，就必須有幾把刷子了。通常這就是「測試案例設計」的專業工作，先要能規劃出到底一共要設計多少個測試案例(也就是想好要找出那幾種程式設計師可能會犯的錯誤)，然後再在每一個案例中設計出一組或多組輸入資料與執行後應該得到的正確輸出結果。

依據別人設計的測試案例把資料輸入、記錄輸出結果看看與應該得到的正確結果是否相同的工作報酬，事實上與在麥當勞打工的數字是差不多的，因為不需要太多專業技能(當然還是要有基本的知識，並不是每個人都能勝任在麥當勞打工的工作的)。但是如果能夠設計好(註**)的測試案例，那就會有很顯著的報酬差異了，說不定可以多一個零。

(註**：譬如找出錯誤的機率比較高，或找出的錯誤可以大幅增進軟體品質等等。)

以往台灣的製造業多以代工為主業，產品的組態都是由下單的買主自己規範；現在台灣的製造業對自有品牌的意識越來越強，產品的組態，尤其是其中軟體部份(譬如智慧型手機的嵌入式軟體)的品質，更已成為競爭的要素。如果大多數的軟體從業人員都在寫程式的紅海裡辛苦打拼，是不是，相對地，軟體測試的藍海是另一個不錯的取捨呢？