1、引言

　　測試設計遵循與軟體設計相同的工程原則。好的軟體設計包含幾個對測試設計進行精心描述的階段。這些階段是：

　　● 測試策略

　　● 測試計劃

　　● 測試描述

　　● 測試過程

　　上述四個測試設計階段適用於從單元測試到系統測試各個層面的測試。

　　測試設計由軟體設計說明所驅動。單元測試用於驗證模組單元實現了模組設計中定義的規格。一個完整的單元測試說明應該包含正面測試（Positive Testing）和負面的測試（Negative Testing）。正面測試驗證程式應該執行的工作，負面測試驗證程式不應該執行的工作。

　　設計富有創造性的測試用例是測試設計的關鍵。本文件介紹了測試說明的一般設計過程，描述了一些結構化程式設計單元測試中採用的用例設計技術，同時也增加了面向物件程式設計中對類進行單元測試所採用的測試用例設計技術，這些可作為軟體測試人員的參考閱讀資料。

2、設計單元測試說明

　　一旦模組單元設計完畢，下一個開發階段就是設計單元測試。值得注意的是，如果在書寫程式碼之前設計測試，測試設計就會顯得更加靈活。一旦程式碼完成，對軟體的測試可能會傾向於測試該段程式碼在做什麼（這根本不是真正的測試），而不是測試其應該做什麼。單元測試說明實際上由一系列單元測試用例組成，每個測試用例應該包含4 個關鍵元素：

　　被測單元模組初始狀態宣告，即測試用例的開始狀態（僅適用於被測單元維持了呼叫間狀態的情況）；

　　被測單元的輸入，包含由被測單元讀入的任何外部資料值；

　　該測試用例實際測試的程式碼，用被測單元的功能和測試用例設計中使用的分析來說明，如：單元中哪一個決策條件被測試；

　　測試用例的期望輸出結果，測試用例的期望輸出結果總是應該在測試進行之前在測試說明中定義。

　　以下描述進行測試用例設計，書寫測試說明的7步通用過程。

2.1 測試用例設計步驟

2.1.1 步驟1：首先使被測單元執行

　　任何單元測試說明的第一個測試用例應該是以一種可能的簡單方法執行被測單元。看到被測單元第一個測試用例的執行成功可以增強人的自信心。如果不能正確執行，最好選擇一個儘可能簡單的輸入對被測單元進行測試/除錯。

　　這個階段適合的技術有：

　　● 模組設計匯出的測試

　　● 對等區間劃分

2.1.2 步驟2：正面測試(Positive Testing)

　　正面測試的測試用例用於驗證被測單元能夠執行應該完成的工作。測試設計者應該查閱相關的設計說明；每個測試用例應該測試模組設計說明中一項或多項陳述。如果涉及多個設計說明，最好使測試用例的序列對應一個模組單元的主設計說明。

　　適合的技術：

　　● 設計說明匯出的測試

　　● 對等區間劃分

　　● 狀態轉換測試

2.1.3 步驟3：負面測試(Negative Testing)

　　負面測試用於驗證軟體不執行其不應該完成的工作。這一步驟主要依賴於錯誤猜測，需要依靠測試設計者的經驗判斷可能出現問題的位置。

　　適合的技術有：

　　● 錯誤猜測

　　● 邊界值分析

　　● 內部邊界值測試

　　● 狀態轉換測試

2.1.4 步驟4：設計需求中其它測試特性用例設計

　　如果需要，應該針對性能、餘量、安全需要、保密需求等設計測試用例。

　　在有安全保密需求的情況下，重視安全保密分析和驗證是方便的。針對安全保密問題的測試用例應該在測試說明中進行標註。同時應該加入更多的測試用例測試所有的保密和安全冒險問題。

　　適合的技術：設計說明匯出的測試

2.1.5 步驟5：覆蓋率測試用例設計

　　應該或已有測試用例所達到的程式碼覆蓋率。應該增加更多的測試用例到單元測試說明中以達到特定測試的覆蓋率目標。一旦覆蓋測試設計好，就可以構造測試過程和執行測試。覆蓋率測試一般要求語句覆蓋率和判斷覆蓋率。

　　適合的技術：

　　● 分支測試

　　● 條件測試

　　● 資料定義－使用測試

　　● 狀態轉換測試

2.1.6 步驟6：測試執行

　　使用上述5個步驟設計的測試說明在大多少情況下可以實現一個比較完整的單元測試。

　　到這一步，就可以使用測試說明構造實際的測試過程和用於執行測試的測試過程。該測試過程可能是特定測試工具的一個測試指令碼。

　　測試過程的執行可以查出模組單元的錯誤，然後進行修復和重新測試。在測試過程中的動態分析可以產生程式碼覆蓋率測量值，以指示覆蓋目標已經達到。因此需要在測試設計說明中需要增加一個完善程式碼覆蓋率的步驟。

2.1.7 步驟7：完善程式碼覆蓋

　　由於模組單元的設計文件規範不一，測試設計中可能引入人為的錯誤，測試執行後，複雜的決策條件、迴圈和分支的覆蓋率目標可能並沒有達到，這時需要進行分析找出原因，導致一些重要執行路徑沒有被覆蓋的可能原因有：

　　不可行路徑或條件——應該標註測試說明證明該路徑或條件沒有測試的原因。

不可到達或冗餘程式碼——正確處理方法是刪除這種程式碼。這種分析容易出錯，特別是使用防衛式程式設計技術（Defensive Programming Techniques）時，如有疑義，這些防衛性程式程式碼就不要刪除。

　　測試用例不足——應該重新提煉測試用例，設計更多的測試用例新增到測試說明中以覆蓋沒有執行過的路徑

　　理想情況下，覆蓋完善階段應該在不閱讀實際程式碼的情況下進行。然而，實際上，為達到覆蓋率目標，看一下實際程式碼也是需要的。覆蓋完善步驟的重要程度相對小一些。最有效的測試來自於分析和說明，而不是來自於試驗，依賴覆蓋完善步驟補充一份不好的測試設計。

　　適合的技術：

　　● 分支測試

　　● 條件測試

　　● 設計定義——試驗測試

　　● 狀態轉換測試

2.2 用例設計的一般原則

　　注意到前面產生測試說明步驟可以用下面的方法完成：

　　通常應該避免依賴先前測試用例的輸出，測試用例的執行序列早期發現的錯誤可能導致其他的錯誤而減少測試執行時實際測試的程式碼量；

　　測試用例設計過程中，包括作為試驗執行這些測試用例時，常常可以在軟體構建前就發現BUG。還有可能在測試設計階段比測試執行階段發現更多的BUG。

　　在整個單元測試設計中，主要的輸入應該是被測單元的設計文件。在某些情況下，需要將試驗實際程式碼作為測試設計過程的輸入，測試設計者必須意識到不是在測試程式碼本身。從程式碼構建出來的測試說明只能證明程式碼執行程式碼完成的工作，而不是程式碼應該完成的工作。

3、測試用例設計技術

　　廣義地分為3類：

　　黑盒測試：使用單元介面和功能描述，不需瞭解被測單元的內部結構

　　白盒測試：使用被測單元內部如何工作的資訊

　　灰盒測試：藉助於原始碼和測試工具等手段，通過黑盒和白盒測試相結合的方法進行測試的技術。

　　測試設計最重要的因素是經驗和常識。測試設計者不應該讓某種測試技術阻礙經驗和常識的運用。

　　白盒測試用例設計：使用程式設計的控制結構匯出測試用例。

　　採用白盒測試的目的主要是:保證一個模組中的所有獨立路徑至少被執行一次；對所有的邏輯值均需要測試真、假兩個分支；在上下邊界及可操作範圍內執行所有迴圈；檢查內部資料結構以確保其有效性。

　　黑盒測試用例設計：使用詳細設計匯出測試用例。

　　採用黑盒測試的目的主要是：檢查功能是否實現或遺漏；檢查人機界戶是否錯誤；資料結構或外部資料庫訪問錯誤；效能等其它特性要求是否滿足；初始化盒終止錯誤。

&n