1、集成測試集成測試是指一個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試尤其與客戶服務器和分布式系統有關。一般集成測試以前，單元測試需要完成。集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是： 兩個已經測試過的單元組合成一個 組件，并且測試它們之間的接口。從這一層意義上講， 組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件， 而這些組件又聚合成 程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起 測試。最后，將構成進程的所有模塊一

2、起測試。此外，如果程序由多個進程組成，應該成對 測試它們，而不是同時測試所有進程。集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元并確 保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的 活動。也就是說，在集成測試之前， 單元測試應該已經完成， 集成測試中所使用的 對象應該 是已經經過單元測試的軟件單元。這一點很重要，因為如

3、果不經過單元測試，那么集成測試的效果將會受到很大影響，并且會大幅增加軟件單元代碼糾錯的代價。集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。 集成測試采用的方法是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最后，還要測試構成系統的所有模塊組合能否正常工作。集成測試所持的主要標準是 軟件概要設計 規格說明，任何不符合該說明的程序模塊行為都應該加以記載并上報。湮試階段Si野襯一嚇功能趙的各類測試所花矍 的時間統計圖所有的軟件項目都不能擺脫系統集成這個階段。不管采用什么開發模式，具體的開

4、發工作總得從一個一個的軟件單元做起，軟件單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題， 工程實踐中，幾乎不存在軟件單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試 是極不妥當的做法。集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種情況下， 集成測試的意義還在于它能間接地驗證概要設

5、計是否具有可行性。集成測試的目的是確保各單元組合在一起后能夠按既定意圖協作運行，并確保增量的行為正確。它所測試的內容包括單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能。并且對以前的集成進行回歸測試。一、集成測試過程、單元測試工作內容及其流程 A|««|Kid «*HIX噲弟也- ftUllWii «ifl誼皿稱比丹Hi壘笄s rid r < 此4冏印比理. 乂出ItM/M* r % IH J ijfh ! tKI Wmi- 畑業-RHMTJ- 4 1. J- I - >4" A >Ji fl * ADiA汕H-j

6、tfl ii-o sn<ft« MHIbi IttHW R ATifFJLjam. 険jut:三、集成測試需求獲取集成測試需求所確定的是對某一集成工作版本的測試的內容，即測試的具體對象。集成測試需求主要來源于 設計模型(Design Model)和集成 構件計劃(In tegratio nBuildPlan )。集成測試著重于集成版本的外部接口的行為。因此，測試需求須具有可觀測、可 測評性。1.集成工作版本應分析其 類協作與消息序列，從而找出該工作版本的外部接口。2 .由集成工作版本的外部接口確定集成測試用例。3 .測試用例應覆蓋工作版本每一外部接口的所有消息流序列。注意：一個

7、外部接口和測試用例的關系是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可采用重用系統測試用例技術。四、集成測試工作機制軟件集成測試工作由產品評測部擔任。需要項目組相關角色配合完成。如圖示：軟件評測部:軟件項目組:嗎-衛口M.F -C I .ftillj* v ffn.u總.槍整嚅齢護詢電二期&即艮£電.% e-fti 1- li o&- ftVllllf 屮iff.1集成測試工作內容及其流程工作流程:u wllnnLLpJUi 4i! 4 -業l 僵 >! ML曜Fl斤中2眄 A«i4fVJi -_L1 TtrtLh&

8、lt;1 A Jn I* «i ,dtr 1五、集成測試產生的工件清單1、軟件集成測試計劃2、集成測試用例3、測試過程4、測試腳本5、測試日志6、測試評估摘要六、集成測試常用方案選型集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Ba ng集成測試、三明治集成測試、核心集成測試、分層集成測試、基于使用的集成測試等。 在此, 筆者將重點討論其中一些經實踐檢驗和一些證實有效的集成測試方案。自底向上集成測試自底向上的集成(Bottom-UpIn tegrati on)方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程

9、序模塊結構中最底 層的模塊開始組裝和測試。因為模塊是自底向上進行組裝的，對于一個給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)事前已經完成組裝并經過測試，所以不再需要編制 樁模塊 （一種能模擬真實模塊， 給待測模塊提供調用接口或數據的測試用軟件模塊）。 自底 向上集成測試的步驟大致如下 :步驟一 : 按照概要設計規格說明，明確有哪些被測模塊。在熟悉被測模塊性質的基礎 上對被測模塊進行分層， 在同一層次上的測試可以并行進行， 然后排出測試活動的先后關系， 制定測試進度計劃。圖 2 給出了自底向上的集成測試過程中各測試活動的拓撲關系。利用 圖論的相關知識， 可以排出各活動之間的時間序列關系

10、， 處于同一層次的測試活動可以同時 進行，而不會相互影響。步驟二 : 在步驟一的基礎上，按時間線序關系，將軟件單元集成為模塊，并測試在集 成過程中出現的問題。 這里，可能需要測試人員開發一些驅動模塊來驅動集成活動中形成的 被測模塊。 對于比較大的模塊， 可以先將其中的某幾個軟件單元集成為子模塊， 然后再集成 為一個較大的模塊。步驟三 : 將各軟件模塊集成為子系統 （或分系統） 。檢測各自子系統是否能正常工作。 同樣，可能需要測試人員開發少量的驅動模塊來驅動被測子系統。步驟四 : 將各子系統集成為最終用戶系統，測試是否存在各分系統能否在最終用戶系 統中正常工作。方案點評 : 自底向上的集成測試方

11、案是工程實踐中最常用的測試方法。相關技術也較 為成熟。 它的優點很明顯 : 管理方便、 測試人員能較好地鎖定軟件故障所在位置。 但它對于 某些開發模式不適用， 如使用 XP 開發方法， 它會要求測試人員在全部軟件單元實現之前完 成核心軟件部件的集成測試。 盡管如此， 自底向上的集成測試方法仍不失為一個可供參考的 集成測試方案。核心系統先行集成測試核心系統先行集成測試法的思想是先對核心軟件部件進行集成測試，在測試通過的基 礎上再按各外圍軟件部件的重要程度逐個集成到核心系統中。 每次加入一個外圍軟件部件都 產生一個產品 基線 ，直至最后形成穩定的軟件產品。 核心系統先行集成測試法對應的集成過 程是

12、一個逐漸趨于閉合的螺旋形曲線，代表產品逐步定型的過程。其步驟如下 :步驟一 : 對核心系統中的每個模塊進行單獨的、充分的測試，必要時使用驅動模塊和 樁模塊 ;步驟二 : 對于核心系統中的所有模塊一次性集合到被測系統中，解決集成中出現的各 類問題。 在核心系統規模相對較大的情況下， 也可以按照自底向上的步驟， 集成核心系統的 各組成模塊。步驟三 : 按照各外圍軟件部件的重要程度以及模塊間的相互制約關系，擬定外圍軟件 部件集成到核心系統中的順序方案。方案經評審以后，即可進行外圍軟件部件的集成。步驟四 : 在外圍軟件部件添加到核心系統以前，外圍軟件部件應先完成內部的模塊級 集成測試。步驟五 : 按順

13、序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現的問題，形成 最終的用戶系統。方案點評 : 該集成測試方法對于快速 軟件開發 很有效果， 適合較復雜系統的集成測試， 能保證一些重要的功能和服務的實現。 缺點是采用此法的系統一般應能明確區分核心軟件部 件和外圍軟件部件， 核心軟件部件應具有較高的耦合度， 外圍軟件部件內部也應具有較高的 耦合度，但各外圍軟件部件之間應具有較低的耦合度。高頻集成測試高頻集成測試是指同步于軟件開發過程，每隔一段時間對開發團隊 的現有代碼進行一次集成測試。 如某些自動化集成測試工具能實現每日深夜對開發團隊的現有代碼進行一次集 成測試， 然后將測試結果發到各開發人員的電

14、子郵箱中。 該集成測試方法頻繁地將新代碼加 入到一個已經穩定的基線中， 以免集成故障難以發現， 同時控制可能出現的基線偏差。 使用 高頻集成測試需要具備一定的條件 : 可以持續獲得一個穩定的增量， 并且該增量內部已被驗 證沒有問題 ; 大部分有意義的功能增加可以在一個相對穩定的時間間隔 （如每個工作日） 內 獲得; 測試包和代碼的開發工作必須是并行進行的， 并且需要 版本控制 工具來保證始終維護 的是測試腳本和代碼的最新版本 ; 必須借助于使用自動化工具來完成。 高頻集成一個顯著的 特點就是集成次數頻繁，顯然，人工的方法是不勝任的。高頻集成測試一般采用如下步驟來完成 :步驟一 : 選擇集成測試

15、自動化工具。如很多 Java 項目采用 Junit+Ant 方案來實現集 成測試的自動化，也有一些商業集成測試工具可供選擇。步驟二 : 設置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。 如使用 CVS 進行版本控制。步驟三 : 測試人員和開發人員負責編寫對應程序代碼的測試腳本。步驟四 : 設置自動化集成測試工具，每隔一段時間對 配置管理 庫的新添加的代碼進行 自動化的集成測試，并將測試報告匯報給開發人員和測試人員。步驟五 : 測試人員監督代碼開發人員及時關閉不合格項。按照步驟三至步驟五不斷循環，直至形成最終軟件產品。方案點評 : 該測試方案能在開發過程中及時發現代碼錯誤，能直觀地看到開發團隊的 有效工程進度。 在此方案中， 開發