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 用例設計的一般原則
注意到前面產生測試說明步驟可以用下面的方法完成：
通常應該避免依賴先前測試用例的輸出，測試用例的執行序列早期發現的錯誤可能導致其他的錯誤而減少測試執行時實際測試的代碼量；
測試用例設計過程中，包括作為試驗執行這些測試用例時，常?？梢栽谲浖嫿ㄇ熬桶l現BUG。還有可能在測試設計階段比測試執行階段發現更多的BUG。
在整個單元測試設計中，主要的輸入應該是被測單元的設計文檔。在某些情況下，
需要將試驗實際代碼作為測試設計過程的輸入，測試設計者必須意識到不是在測試代碼本身。從代碼構建出來的測試說明只能證明代碼執行代碼完成的工作，而不是代碼應該完成的工作。
3、測試用例設計技術
廣義地分為兩類：
黑盒測試：使用單元接口和功能描述，不需了解被測單元的內部結構
白盒測試：使用被測單元內部如何工作的信息
灰盒測試：借助于源代碼和測試工具等手段，通過黑盒和白盒測試相結合的方法進行測試的技術。
測試設計最重要的因素是經驗和常識。測試設計者不應該讓某種測試技術阻礙經驗和常識的運用。
白盒測試用例設計：使用程序設計的控制結構導出測試用例。
采用白盒測試的目的主要是:保證一個模塊中的所有獨立路徑至少被執行一次；對所有的邏輯值均需要測試真、假兩個分支；在上下邊界及可操作范圍內運行所有循環；檢查內部數據結構以確保其有效性。
黑盒測試用例設計：使用詳細設計導出測試用例。
采用黑盒測試的目的主要是：檢查功能是否實現或遺漏；檢查人機界戶是否錯誤；數據結構或外部數據庫訪問錯誤；性能等其它特性要求是否滿足；初始化盒終止錯誤。