軟體測試－整合測試方法

我想說起整合測試來大家一定都不陌生，但是如果說起整合測試的具體測試方法大家是否瞭解呢，那我來介紹一下有關整合測試的方法，希望對新手有所協助。
    整合測試是單元測試的邏輯擴充。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的介面。從這一層意義上講，組件是指多個單元的整合彙總。在現實方案中，許多單元組合成組件，而這些組件又彙總成程式的更大部分。方法是測試片段的組合，並最終擴充進程，將您的模組與其他組的模組一起測試。最後，將構成進程的所有模組一起測試。此外，如果程式由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
   整合測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析層級。
    可以以多種方式進行整合測試，而下面是三種常用的類別：

1）自頂向下：由上而下的整合測試方法要求首先測試和整合最進階別的模組。這使進階別的邏輯和資料流可以在過程的早期階段測試，有助於最大限度地減少對驅動程式的需求。但是，對存根 （stub，也就是我們經常說的“樁”） 的需求使測試管理變得複雜，低層級的工具 + 生產力在開發週期中相對較晚的階段測試。由上而下的整合測試的另一個缺點是不能很好地支援有限功能的早期發布。

2）自底向上：由下而上的方法要求首先測試和整合最低層級的單元。這些單元常被稱為工具 + 生產力模組。通過使用這種方法，工具 + 生產力模組在開發過程的早期階段測試，最大限度地減少了對存根 （stub） 的需求。但是，不利的方面是對驅動程式的需求使測試管理變得複雜，進階別的邏輯和資料流在晚期測試。與由上而下的方法一樣，由下而上的方法也不能很好地支援有限功能的早期發布。

3）第三種方法（有時也稱為傘形方法）要求測試沿功能性資料和控制流程路徑進行。首先，函數的輸入以上面討論的由下而上的模式整合。然後，每個函數的輸出以由上而下的方式整合。這種方法的主要優點是對有限功能的早期發布的支援程度。它也有助於最大限度地減少對存根 （stub） 和驅動程式的需求。但是，這種方法的潛在缺點非常明顯，因為它的系統性可能比其他兩種方法低，會導致對迴歸測試的更大需求。