集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元并確保每個單元的生存能力的測試計劃,可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。
可以以多種方式進行集成測試,而下面是三種常用的類別:
由上而下的集成測試方法要求首先測試和集成最高級別的模塊。這使高級別的邏輯和數據流可以在過程的早期階段測試,有助于最大限度地減少對驅動程序的需求。但是,對存根 (stub) 的需求使測試管理變得復雜,低級別的實用工具在開發周期中相對較晚的階段測試。由上而下的集成測試的另一個缺點是不能很好地支持有限功能的早期發布。
由下而上的方法要求首先測試和集成最低級別的單元。這些單元常被稱為實用工具模塊。通過使用這種方法,實用工具模塊在開發過程的早期階段測試,最大限度地減少了對存根 (stub) 的需求。但是,不利的方面是對驅動程序的需求使測試管理變得復雜,高級別的邏輯和數據流在晚期測試。與由上而下的方法一樣,由下而上的方法也不能很好地支持有限功能的早期發布。
第三種方法(有時也稱為傘形方法)要求測試沿功能性數據和控制流路徑進行。首先,函數的輸入以上面討論的由下而上的模式集成。然后,每個函數的輸出以由上而下的方式集成。這種方法的主要優點是對有限功能的早期發布的支持程度。它也有助于最大限度地減少對存根 (stub) 和驅動程序的需求。但是,這種方法的潛在缺點非常明顯,因為它的系統性可能比其他兩種方法低,會導致對回歸測試的更大需求。
原文轉自:http://www.anti-gravitydesign.com