軟件測試中的集成測試方法

我想說起集成測試來大家一定都不陌生，但是如果說起集成測試的具體測試方法大家有幾個了解呢，那我來介紹一下有關集成測試的方法，希望對新手有所幫助

　　集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
　
　　集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。
　
　　可以以多種方式進行集成測試，而下面是三種常用的類別：由上而下的集成測試方法要求首先測試和集成最高級別的模塊。這使高級別的邏輯和數據流可以在過程的早期階段測試，有助于最大限度地減少對驅動程序的需求。但是，對存根 （stub） 的需求使測試管理變得復雜，低級別的實用工具在開發周期中相對較晚的階段測試。由上而下的集成測試的另一個缺點是不能很好地支持有限功能的早期發布。
　
　　由下而上的方法要求首先測試和集成最低級別的單元。這些單元常被稱為實用工具模塊。通過使用這種方法，實用工具模塊在開發過程的早期階段測試，最大限度地減少了對存根 （stub） 的需求。但是，不利的方面是對驅動程序的需求使測試管理變得復雜，高級別的邏輯和數據流在晚期測試。與由上而下的方法一樣，由下而上的方法也不能很好地支持有限功能的早期發布。
　
　　第三種方法（有時也稱為傘形方法）要求測試沿功能性數據和控制流路徑進行。首先，函數的輸入以上面討論的由下而上的模式集成。然后，每個函數的輸出以由上而下的方式集成。這種方法的主要優點是對有限功能的早期發布的支持程度。它也有助于最大限度地減少對存根 （stub） 和驅動程序的需求。但是，這種方法的潛在缺點非常明顯，因為它的系統性可能比其他兩種方法低，會導致對回歸測試的更大需求

原文轉自：http://www.anti-gravitydesign.com