軟件測試之集成測試的組成以及流程

　集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層  意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，  將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。

　　集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。

　　集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指  標及要求的活動。也就是說，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟件單元。這一點很重要，因為如果不  經過單元測試，那么集成測試的效果將會受到很大影響，并且會大幅增加軟件單元代碼糾錯的代價。

　　集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。集成測  試采用的方法是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最后，還要測試構成系統的所有模塊組合能否正常工作。集成測試所持  的主要標準是《軟件概要設計規格說明》，任何不符合該說明的程序模塊行為都應該加以記載并上報。

　　

　　所有的軟件項目都不能擺脫系統集成這個階段。不管采用什么開發模式，具體的開發工作總得從一個一個的軟件單元做起，軟件單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中，幾乎不存在軟件單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。

　　集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種情況下，集成測試的意義還在于它能間接地驗證概要設計是否具有可行性。

　　集成測試的目的是確保各單元組合在一起后能夠按既定意圖協作運行，并確保增量的行為正確。它所測試的內容包括單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能。并且對以前的集成進行回歸測試。

一、集成測試過程         

　　

二、單元測試工作內容及其流程

　　

三、集成測試需求獲取

　　集成測試需求所確定的是對某一集成工作版本的測試的內容，即測試的具體對象。集成測試需求主要來源于設計模型（Design  Model）和集成構件計劃（Integration Build  Plan）。集成測試著重于集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。

1． 集成工作版本應分析其類協作與消息序列，從而找出該工作版本的外部接口。

2． 由集成工作版本的外部接口確定集成測試用例。

3． 測試用例應覆蓋工作版本每一外部接口的所有消息流序列。

　　注意：一個外部接口和測試用例的關系是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可采用重用系統測試用例技術。

四、集成測試工作機制

　　軟件集成測試工作由產品評測部擔任。需要項目組相關角色配合完成。如圖示：

　　軟件評測部：

　　

　　軟件項目組：

　　

　　集成測試工作內容及其流程工作流程：

　　

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