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