測試用例設計規範

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類：

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

　　白盒測試：使用被測單元內部如何工做的信息

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

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

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

　　採用白盒測試的目的主要是:保證一個模塊中的全部獨立路徑至少被執行一次；對全部的邏輯值均須要測試真、假兩個分支；在上下邊界及可操做範圍內運行全部循環；檢查內部數據結構以確保其有效性。

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

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