「單元測試理論與技術」上課心得

課程定位

在軟體開發過程中，從需求分析à設計à實作每個階段都有對應的測試工作，「需求分析」對應「驗收測試」(UAT)，「設計」對應「整合測試」(SIT)，「實作」對應「單元測試」，此即所謂的V-Model，而本課程著重在「單元測試」一塊，其它部分則安排在資策會的另一堂18小時的「測試技術理論」課程(98/12/13)中介紹。

課程簡述

講師是來自台北科大資工系的郭忠義老師，課程內容分「測試流程及工具」、「白箱測試」、「黑箱測試」、「物件導向測試」4個單元。早上介紹了「測試流程及工具」，測試流程為V Model，工具為JUnit，由於V Model與軟體工程息息相關，有了CMMI基礎下頗能理解背後的原理，而由於上課現場還有其他Java初學者(準備轉業)，因此講師也花了些時間介紹「軟體資訊業」的生態。

由於還有「白箱測試」、「黑箱測試」、「物件導向測試」3個單元要講，下午講師開始在趕進度了，其中一些講的不夠清楚或還來不及理解的也因為時間關係，最後也只能傖促教完，這些課程中較不理想之處。

白箱測試

白箱測試是等程式撰寫完畢後，依據程式撰寫結果推導出測試案例。主要分以下幾種覆蓋度:
1) Statements Coverage
2) Branches Coverage

3) Condition Coverage

4) Multiple-condition Coverage

5) All-Paths Coverage

依據對程式碼要求的嚴謹度來決定採用那種覆蓋度，覆蓋度越高，成本越高，一般只要做到Statements Coverage就夠了。所有測試案例是透過分析code得出，譬如用了一個 if…else，要做到 statements coverage，必須設計2個測試案例，一個跑 if 一個跑else，可以想像，code要是寫得很亂，用了巢狀再巢狀的if…，白箱測試一定會很苦!

由於白箱測試成本極高，一般只會用在跟生命有相關的飛航系統、核電廠…等，或跟安全交易有關的金融交易系統，對著重於企業需求面的ERP，使用「需求導向」的黑箱測試就已很足夠了。

黑箱測試

黑箱測試是將系統視為黑箱，只管input,output，完全「需求導向」，有以下技術:

1)    等價劃分

2)    邊界值分析

3)    基於決策表分析

「等價劃分」是依據商業邏輯中指定的範圍，設計出「合法」及「非法」的測試案例。例如允許輸入值x，其允許輸入範圍是 4，依等價劃分原則，我們需設計3組測試案例，即 3,5,12，2個非法1個合法數值。

等價劃分其實對稍有經驗的SA來說是很常用的測試方法，自己以前做過的「加班津貼」計算方式即屬此類，加班前2小時津貼費率為時薪的1.33倍，2小時以後的則為1.5倍，這樣「等價劃分」的「合法測試範圍」應為1小時、3小時，及非法的 -1小時。

	加班津貼費率範圍

 

                                               

「邊界值分析」需與「等價劃分」搭配，以同樣例子 4，其邊界為 4，10，因此測試數據必須是邊界值附近，即 3,4,5及9,10,11，套用上述的加班津貼費率例子，邊界值則為0.5小時，1.5小時，2.5小時。以這些原則得出測試案例的輸入資料後，再依需求算出「期望值」，這樣一對的「輸入值」及「期望值」就是測試案例了。

「基於決策表分析」

決策表分析是將所有的因果關係列出，針對所有的可能性都設計測試案例。例如

正式員工記小過扣年薪4%，記大過扣年薪8%; 約聘員工記小過扣月薪6%，記大過扣月薪10%。像這樣的需求，總共可列出16種排列組合，其中有意義的只有4種組合，因此完整的測試案例需提供12種非法資料及4種合法測試資料，看來這麼簡單的邏輯要做到完整的測試，真的很耗人力，若套用到真正的ERP系統真不敢想像。

物件導向測試

物件導向測試是針對以OO分析設計來打造的測試方法，比較接近UML的思路，若已熟悉OO分析設計就很容易接受這種測試方法，主要包含:

1)    狀態機導向測試

2)    情節導向測試 (即以use case為基底)

3)    繼承

4)    多型

狀態機是針對UML的狀態圖中的所有「狀態移轉」、「移轉限制」所設計的案例。

目前我們已有設計一套專門處理「狀態機」的公用元件，AP只須套用此元件即可，對應的測試案例應可減少。

情節導向則是針對use case的所有基本路徑、替代路徑賦予實質數據設計測試案例，是以user立場看待系統的測試方法，為目前design team主要的測試案例設計方法。個人是傾向這方法，只有一切以user立場思考時，才可能「做得最少，獲得最多」。

繼承、多型的測試則較像「uml 的白箱測試」，將uml圖攤開後，透過分析裡面的結構找出測試案例，與白箱測試有相同的困惱，即「成本太高、受限於系統設計技巧」，因此在ERP的領域裡個人較不建議使用。

總結

課程雖然有包括理論與實務部分，但也許講師來自學校，對實務之應用情境、經驗都較缺乏，無法具體介紹理論如何套用到實務。另外課程花不少時間介紹JUnit之使用，對已很熟悉的我們來說是有點入門了些。

真正有收穫之處應屬「正統的測試理論」部分，這部分提供測試案設計原則，讓我們對「測試案例的完整性」有個驗證準則，對QA SDS的單元測試案例時幫助蠻大的。

上完課後讓職有個感想，要完整的測試一個系統所有案例似乎是不可能的，雖說全部都測能保證最好的品質，但其所花費成本亦相當高，我們必須有能力衡量該做到甚麼程度，才有最好的投報率。所以回歸到最原點還是需求，只有具備堅實的業務知識，才知道「那些地方是系統要害」，只有這樣才能事半功倍。