定義
從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程式的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模組與其他組的模組一起測試。最後，將構成進程的所有模組一起測試。此外，如果程式由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計畫，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。
集成測試是在單元測試的基礎上，測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模組、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那么集成測試的效果將會受到很大影響，並且會大幅增加軟體單元代碼糾錯的代價。
集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模組，而這些模組又聚合成程式的更大部分，如分系統或系統。集成測試採用的方法是測試軟體單元的組合能否正常工作，以及與其他組的模組能否集成起來工作。最後，還要測試構成系統的所有模組組合能否正常工作。集成測試所持的主要標準是《軟體概要設計規格說明》，任何不符合該說明的程式模組行為都應該加以記載並上報。
所有的軟體項目都不能擺脫系統集成這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟體單元做起，軟體單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中，幾乎不存在軟體單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。
集成測試的必要性還在於一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常工作。程式在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如疊代式開發，設計和實現是疊代進行的。在這種情況下，集成測試的意義還在於它能間接地驗證概要設計是否具有可行性。
集成測試的目的是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。它所測試的內容包括單元間的接口以及集成後的功能。使用黑盒測試方法測試集成的功能。並且對以前的集成進行回歸測試。
一、集成測試過程
二、單元測試工作內容及其流程
三、集成測試需求獲取
集成測試需求所確定的是對某一集成工作版本的測試的內容，即測試的具體對象。集成測試需求主要來源於設計模型（Design Model）和集成構件計畫（Integration Build Plan）。集成測試著重於集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。
1． 集成工作版本應分析其類協作與訊息序列，從而找出該工作版本的外部接口。
2． 由集成工作版本的外部接口確定集成測試用例。
3． 測試用例應覆蓋工作版本每一外部接口的所有訊息流序列。
注意：一個外部接口和測試用例的關係是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可採用重用系統測試用例技術。
四、集成測試工作機制
軟體集成測試工作由產品評測部擔任。需要項目組相關角色配合完成。如圖示：
軟體評測部：
軟體項目組：
集成測試工作內容及其流程工作流程：
五、集成測試產生的工件清單
1、 軟體集成測試計畫
2、 集成測試用例
3、 測試過程
4、 測試腳本
5、 測試日誌
6、 測試評估摘要
六、集成測試常用方案選型
集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基於使用的集成測試等。在此，筆者將重點討論其中一些經實踐檢驗和一些證實有效的集成測試方案。
·自底向上集成測試
自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程式模組結構中最底層的模組開始組裝和測試。因為模組是自底向上進行組裝的，對於一個給定層次的模組，它的子模組（包括子模組的所有下屬模組）事前已經完成組裝並經過測試，所以不再需要編制樁模組（一種能模擬真實模組，給待測模組提供調用接口或數據的測試用軟體模組）。自底向上集成測試的步驟大致如下:
步驟一: 按照概要設計規格說明，明確有哪些被測模組。在熟悉被測模組性質的基礎上對被測模組進行分層，在同一層次上的測試可以並行進行，然後排出測試活動的先後關係，制定測試進度計畫。圖2給出了自底向上的集成測試過程中各測試活動的拓撲關係。利用圖論的相關知識，可以排出各活動之間的時間序列關係，處於同一層次的測試活動可以同時進行，而不會相互影響。
步驟二: 在步驟一的基礎上，按時間線序關係，將軟體單元集成為模組，並測試在集成過程中出現的問題。這裡，可能需要測試人員開發一些驅動模組來驅動集成活動中形成的被測模組。對於比較大的模組，可以先將其中的某幾個軟體單元集成為子模組，然後再集成為一個較大的模組。
步驟三: 將各軟體模組集成為子系統（或分系統）。檢測各自子系統是否能正常工作。同樣，可能需要測試人員開發少量的驅動模組來驅動被測子系統。
步驟四: 將各子系統集成為最終用戶系統，測試是否存在各分系統能否在最終用戶系統中正常工作。
方案點評: 自底向上的集成測試方案是工程實踐中最常用的測試方法。相關技術也較為成熟。它的優點很明顯: 管理方便、測試人員能較好地鎖定軟體故障所在位置。但它對於某些開發模式不適用，如使用XP開發方法，它會要求測試人員在全部軟體單元實現之前完成核心軟體部件的集成測試。儘管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。
·核心繫統先行集成測試
核心繫統先行集成測試法的思想是先對核心軟體部件進行集成測試，在測試通過的基礎上再按各外圍軟體部件的重要程度逐個集成到核心繫統中。每次加入一個外圍軟體部件都產生一個產品基線，直至最後形成穩定的軟體產品。核心繫統先行集成測試法對應的集成過程是一個逐漸趨於閉合的螺鏇形曲線，代表產品逐步定型的過程。其步驟如下:
步驟一: 對核心繫統中的每個模組進行單獨的、充分的測試，必要時使用驅動模組和樁模組;
步驟二: 對於核心繫統中的所有模組一次性集合到被測系統中，解決集成中出現的各類問題。在核心繫統規模相對較大的情況下，也可以按照自底向上的步驟，集成核心繫統的各組成模組。
步驟三: 按照各外圍軟體部件的重要程度以及模組間的相互制約關係，擬定外圍軟體部件集成到核心繫統中的順序方案。方案經評審以後，即可進行外圍軟體部件的集成。
步驟四: 在外圍軟體部件添加到核心繫統以前，外圍軟體部件應先完成內部的模組級集成測試。
步驟五: 按順序不斷加入外圍軟體部件，排除外圍軟體部件集成中出現的問題，形成最終的用戶系統。
方案點評: 該集成測試方法對於快速軟體開發很有效果，適合較複雜系統的集成測試，能保證一些重要的功能和服務的實現。缺點是採用此法的系統一般應能明確區分核心軟體部件和外圍軟體部件，核心軟體部件應具有較高的耦合度，外圍軟體部件內部也應具有較高的耦合度，但各外圍軟體部件之間應具有較低的耦合度。
·高頻集成測試
高頻集成測試是指同步於軟體開發過程，每隔一段時間對開發團隊的現有代碼進行一次集成測試。如某些自動化集成測試工具能實現每日深夜對開發團隊的現有代碼進行一次集成測試，然後將測試結果發到各開發人員的電子信箱中。該集成測試方法頻繁地將新代碼加入到一個已經穩定的基線中，以免集成故障難以發現，同時控制可能出現的基線偏差。使用高頻集成測試需要具備一定的條件: 可以持續獲得一個穩定的增量，並且該增量內部已被驗證沒有問題; 大部分有意義的功能增加可以在一個相對穩定的時間間隔（如每個工作日）內獲得; 測試包和代碼的開發工作必須是並行進行的，並且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本; 必須藉助於使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數頻繁，顯然，人工的方法是不勝任的。
高頻集成測試一般採用如下步驟來完成:
步驟一: 選擇集成測試自動化工具。如很多Java項目採用Junit+Ant方案來實現集成測試的自動化，也有一些商業集成測試工具可供選擇。
步驟二: 設定版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。
步驟三: 測試人員和開發人員負責編寫對應程式代碼的測試腳本。
步驟四: 設定自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，並將測試報告匯報給開發人員和測試人員。
步驟五: 測試人員監督代碼開發人員及時關閉不合格項。
按照步驟三至步驟五不斷循環，直至形成最終軟體產品。
方案點評: 該測試方案能在開發過程中及時發現代碼錯誤，能直觀地看到開發團隊的有效工程進度。在此方案中，開發維護原始碼與開發維護軟體測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在於測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。
以上我們介紹了幾種常見的集成測試方案，一般來講，在現代複雜軟體項目集成測試過程中，通常採用核心繫統先行集成測試和高頻集成測試相結合的方式進行，自底向上的集成測試方案在採用傳統瀑布式開發模式的軟體項目集成過程中較為常見。讀者應該結合項目的實際工程環境及各測試方案適用的範圍進行合理的選型。
附：集成測試計畫書 模版
原創作者：jerry
轉載請註明：來自Sawin系統分析之窗
最後修改時間：2005-4-27
1引言
1.1編寫目的
本文是描述****集成測試的大綱文章，主要描述如何進行集成測試活動？如何控制集成測試活動？集成測試活動的流程以及集成測試活動的工作安排。本文主要的讀者對象是項目負責人，集成部門經理，集成測試設計師。
1.2背景
項目名稱：***集成測試
項目相關對象：******************
1.3定義
**********：********************
1.4參考資料
《*********》
2測試項目
本測試主要為***系統的集成測試，目前***的版本為2.0,測試是***的最終集成測試，是建立在開發組程式設計師開發完畢自己的測試以及開發組測試的基礎之上
3 被測特性
3.1操作性測試
主要測試操作是否正確，有無誤差？分為兩部分：
3.1.1返回測試
由主界面逐級進入最終界面，按EXIT鍵逐級返回，檢查返回時候螢幕聚焦是否正確
比如：
1. 進入“系統設定”
2. 進入“頻道搜尋”
3. 進入“自動頻道搜尋”
4. 按EXIT鍵返回，檢查當前聚焦是否為“頻道搜尋”
5. 按EXIT鍵返回，檢查當前聚焦是否為“系統設定”
3.1.2進入測試
由主界面逐級進入最終界面，按MENU鍵返回主界面，再次進入，檢查是否聚焦正確
比如：
1. 進入“系統設定”
2. 進入“頻道搜尋”
3. 進入“自動頻道搜尋”
4. 按MENU鍵返回主界面
5. 當前聚焦是否為“系統設定”
6. 進入“系統設定”，當前聚焦是否為“頻道搜尋”
3.2功能測試
測試機頂盒中每個套用的功能是否正確
3.3性能測試
3.3.1疲勞性測試
測試連續開機1個月不關機器，每3天去運行一次套用。看系統的穩定性
3.3.2大容量數據測試
前段***資料庫表中含有大量數據，測試***功能
4 不被測特性
5 測試方法
1. 書寫測試計畫
2. 審核測試計畫，未通過返回第一步
3. 書寫測試用例；
4. 審核測試用例，未通過返回第三步
5. 測試人員按照測試用例逐項進行測試活動,並且將測試結果填寫在測試報告上；（測試報告必須覆蓋所有測試用例）
6. 測試過程中發現bug，將bug填寫在bugzilla上發給集成部經理；（bug狀態NEW）
7. 集成部經理接到bugzilla發過來的bug
7.1 對於明顯的並且可以立刻解決的bug，將bug發給開發人員；（bug狀態ASSIGNED）;
7.2 對於不是bug的提交，集成部經理通知測試設計人員和測試人員，對相應文檔進行修改; （bug狀態RESOLVED，決定設定為INVALID）;
7.3 對於目前無法修改的,將這個bug放到下一輪次進行修改；（bug狀態RESOLVED，決定設定為REMIND）
8. 開發人員接到發過來的bug立刻修改;（bug狀態RESOLVED，決定設定為FIXED）
9. 測試人員接到bugzilla發過來的錯誤更改信息，應該逐項複測，填寫新的測試報告（測試報告必須覆蓋上一次中所有REOPENED的測試用例）；
10. 如果複測有問題返回第六步（bug狀態REOPENED）
11. 否則關閉這項BUG（bug狀態CLOSED）
12. 本輪測試中測試用例中有95%一次性通過測試,結束測試任務；
13. 本輪測試中發現的錯誤有98%經過修改並且通過再次測試（即bug狀態CLOSED），返回第五步進行新的一輪測試；
14. 測試任務結束後書寫測試總結報告；
15. 正規測試結束進入非正規測試，首先是ALPHA測試，請公司里其他非技術人員以用戶角色使用系統。發現bug通知測試人員，測試人員以正規流程處理bug事件；
16. 然後是BETA測試，請用戶代表進行測試。發現bug通知測試人員，測試人員以正規流程處理bug事件。
幾點說明：
O 測試回歸計畫為三次；
O 測試用例應該寫得比較詳盡，步驟一定要標明清楚（應該包括：編號，測試描述，前置條件，測試步驟以及測試希望結果）；
O 對於測試人員覺得應該進行的測試項目，測試人員應該報告測試設計人員，完善和健全測試用例；
O 測試報告與測試用例分開，測試報告標明測試用例序號以及是否通過Y/N；
O 對於集成部經理無法決定的上交項目負責人決定；
O 性能測試中的疲勞性測試可以結合在功能測試部分，即測試期間不關閉機器；
O 性能測試中的大容量數據測試放在測試後部分輪次（第二步，只需要進行一次）
6 測試通過標準
測試結果與測試用例中期望的結果一致，測試通過，否則標明測試未通過。
6.1測試結果審批過程
6.1.1測試回歸申請結束
測試人員提出申請這輪測試結束，提交集成部經理；
集成部經理召集本組人員開會討論；
討論通過，進行下一輪測試，並且部署下一輪測試的注意事項，流程等內容；
如果發現這輪測試目前還存在問題沒有解決，延期下一輪測試時間，討論下一步工作應該如何進行。
6.1.2測試結果申請結束
測試人員提出申請測試結束，提交集成部經理；
集成部經理召集本組人員開會討論；
1. 討論通過，結束測試任務；
2. 如果發現目前測試還存在問題沒有解決，延期測試結束時間，並且討論下一步工作應該如何進行。
7 測試掛起和恢復條件
7.1掛起條件
O 進入第一輪測試，測試人員大體了解一下產品情況，如果在一小時之內發現５個以上（含５個）操作性錯誤，或者３個以上（含３個）功能性錯誤，退回測試組測試；
O 遇到有項目優先權更高的集成測試任務；
O 遇到有項目優先權更高的集成任務；
O 在測試複測過程中發現產品無法運行下去；
O 人員，設備不足。
7.2恢復條件
O 符合進入集成測試條件（一小時之內發現５個以下（不含５個）操作性錯誤，或者３個以下（不含３個）功能性錯誤）；
O 項目優先權更高的集成測試任務暫告完成；
O 項目優先權更高的集成任務暫告完成；
O 複測過程中產品可以運行下去；
O 人員，設備到位。
8應提供的測試檔案
O 測試計畫書
O 測試用例
O 測試報告
O 測試總結
9測試任務
O 制定審核測試計畫
O 制定和審核測試用例
O 進行測試活動
O 書寫測試報告
10測試環境需求
10.1硬體需求
***********
10.2軟體需求
************
10.3測試工具
*************
10.4測試需要的條件
**************
10.4.1 需要的文檔
O 用戶手冊
O 套用手冊
O 安裝說明
10.4.2需要完成的任務
O 程式設計師本人測試
O 測試組完成測試
11角色和職責
O 集成（測試）經理：控制並完成測試任務和測試過程，決定測試人員提交上來的bug是否需要修改；
O 測試設計人員：書寫集成測試用例；
O 測試人員：按照測試用例進行測試活動；
O 開發人員：MHP程式bug修改；
O 用戶代表：進行BETA測試。
12 人員和培訓
O 集成測試經理有責任對測試相關人員進行測試流程，規章制度培訓；
O 測試設計人員有責任對測試人員進行測試操作培訓
13 測試進度
測試工作 進度(人＊工作日)
測試計畫 ８
測試設計 60
測試執行總共進度 30
每次回歸進度 10
測試報告 ２
14風險及應急計畫
設備不到位:加緊設備購買;
人員不到位
人員請假：請假人員回來加班或趕緊測試進度／申請調配新的人員；
人員離職：調配新的人員；
人員調配到其他部門或項目：調配新的人員；
開發人員開發頻頻出錯：通知開發部門，商量策略；
其他原因的測試工作頻頻被掛起或者掛起後遲遲恢復不了：加班或延期
15審批
集成部經理 技術部經理
姓名： 姓名：
日期： 日期：
【作者介紹】 jerry
97年畢業於北京某高校計算級專業，先後在軟體公司和網路公司從事軟體開發，系統分析和設計工作。2001年涉及軟體質量保證，先後擔任測試工程師，測試部經理，副經理。精通軟體工程和測試流程，精通RUP, CMM, ISO, 6SIGMA軟體質量保證工作。
作者Email地址：[email protected]
