軟件測試規范(5)

　　在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：

　　誤解或用錯了算符優先級;

　　混合類型運算;

　　變數初值錯;

　　精度不夠;

　　表達式符號錯。

　　比較判斷與控制流常常緊密相關，測試用例還應致力于發現下列錯誤：

　　不同數據類型的對象之間進行比較;

　　錯誤地使用邏輯運算符或優先級;

　　因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等;

　　比較運算或變量出錯;

　　循環終止條件或不可能出現;

　　迭代發散時不能退出;

　　錯誤地修改了循環變量。

　　一個好的設計應能預見各種出錯條件，并預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：

　　輸出的出錯信息難以理解;

　　記錄的錯誤與實際遇到的錯誤不相符;

　　在程序自定義的出錯處理段運行之前，系統已介入;

　　異常處理不當;

　　錯誤陳述中未能提供足夠的定位出錯信息。

　　邊界條件測試是單元測試中最后，也是最重要的一項任務。眾的周知，軟件經常在邊界上失效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

　　單元測試過程

　　一般認為單元測試應緊接在編碼之后，當源程序編制完成并通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。

　　應為測試模塊開發一個驅動模塊(driver)和(或)若干個樁模塊(stub),下圖顯示了一般單元測試的環境。驅動模塊在大多數場合稱為“主程序”，它接收測試數據并將這些數據傳遞到被測試模塊，被測試模塊被調用后，“主程序”打印“進入-退出”消息。

　　驅動模塊和樁模塊是測試使用的軟件，而不是軟件產品的組成部分，但它需要一定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能采用下面討論的綜合測試方法。

　　提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。

　　3.2 集成測試

　　在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮：

　　在把各個模塊連接起來的時侯，穿越模塊接口的數據是否會丟失;

　　一個模塊的功能是否會對另一個模塊的功能產生不利的影響;

　　各個子功能組合起來，能否達到預期要求的父功能;

　　全局數據結構是否有問題;

　　單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。

　　單個模塊的錯誤是否會導致數據庫錯誤。

　　選擇什么方式把模塊組裝起來形成一個可運行的系統，直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號的次序和測試的次序、以及生成測試用例的費用和調試的費用。通常，把模塊組裝成為系統的方式有兩種方式：

　?、?一次性集成方式

　　它是一種非增殖式集成方式。也叫做整體拼裝。使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。

　　由于程序中不可避免地存在涉及模塊間接口、全局數據結構等方面的問題，所以一次試運行成功的可能性并不很大。

　?、?增殖式集成方式

　　又稱漸增式集成方式。首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統，在組裝的過程中邊連接邊測試，以發現連接過程中產生的問題。最后通過增殖逐步組裝成為要求的軟件系統。

　　自頂向下的增殖方式：將模塊按系統程序結構，沿控制層次自頂向下進行集成。由于這種增殖方式在測試過程中較早地驗證了主要的控制和判斷點。在一個功能劃分合理的程序結構中，判斷常出現在較高的層次，較早就能遇到。如果主要控制有問題，盡早發現它能夠減少以后的返工。

原文轉自：http://www.uml.org.cn/Test/201511262.asp