軟件集成測試培訓(xùn)教材

1、軟件集成測試培訓(xùn)1課程目標(biāo)了解集成測試的概念掌握集成測試的基本思路和方法2課程內(nèi)容集成測試介紹集成測試分析集成測試策略集成測試過程集成測試環(huán)境3什么是集成測試集成測試（Integration Testing），也叫組裝測試、聯(lián)合測試、子系統(tǒng)測試或部件測試。集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計(jì)要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。也就是說，在集成測試之前，單元測試已經(jīng)完成，并且集成測試所使用的對象應(yīng)當(dāng)是已經(jīng)經(jīng)過單元測試保證了的單元，如果不經(jīng)過單元測試，那么集成測試的效果將受到影響，并且會付出更大的代價(jià)，單元測試和集成測試所關(guān)注的范圍是不同的，因此，它們在發(fā)現(xiàn)問題

2、的集合上包含有不相交的區(qū)域，你不能使用單元測試來替代集成測試，反之也是一樣。4集成測試和系統(tǒng)測試的區(qū)別系統(tǒng)測試所測試的對象是整個(gè)系統(tǒng)以及與系統(tǒng)交互的硬件和軟件平臺。系統(tǒng)測試更多程度上是站在用戶的角度上對系統(tǒng)做功能性的驗(yàn)證，同時(shí)還對系統(tǒng)進(jìn)行一些非功能性的驗(yàn)證，包括性能測試、壓力測試、容量測試、安全性測試、恢復(fù)性測試等等。系統(tǒng)測試的依據(jù)來自于用戶的需求規(guī)格說明書和行業(yè)的已成文的或事實(shí)上的標(biāo)準(zhǔn)。集成測試所測試的對象是模塊間的接口，其目的是要找出在模塊接口上面，包括整體體系結(jié)構(gòu)上的問題。其測試的依據(jù)來自于系統(tǒng)的高層設(shè)計(jì)（構(gòu)架設(shè)計(jì)）。5集成測試關(guān)注的重點(diǎn)實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證

3、連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。因此集成測試應(yīng)當(dāng)考慮以下問題：在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會丟失。各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能。一個(gè)模塊的功能是否會對另一個(gè)模塊的功能產(chǎn)生不利的影響。全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改。單個(gè)模塊的誤差積累起來，是否會放大，從而達(dá)到不可接受的程度。因此，單元測試后，有必要進(jìn)行集成測試，發(fā)現(xiàn)并排除在模塊連接中可能發(fā)生的上述問題，最終構(gòu)成要求的軟件子系統(tǒng)或系統(tǒng)。6集成測試和開發(fā)的關(guān)系集成測試是與軟件開發(fā)的概要設(shè)計(jì)階段相對應(yīng)的，軟件概要設(shè)計(jì)中關(guān)于整個(gè)系統(tǒng)的體系結(jié)構(gòu)

4、是集成測試的輸入基礎(chǔ)。體系結(jié)構(gòu)是把一個(gè)大的系統(tǒng)組織成為可以管理的和可實(shí)現(xiàn)的組件或子系統(tǒng)的結(jié)構(gòu)。它服務(wù)于很多目標(biāo)，包括風(fēng)險(xiǎn)管理，進(jìn)度和驗(yàn)證。Booch認(rèn)為集成是面向?qū)ο箝_發(fā)中最關(guān)鍵的活動。其實(shí)即使在結(jié)構(gòu)化設(shè)計(jì)中，集成也是同樣重要的。集成測試與構(gòu)架設(shè)計(jì)之間具有相互的依賴性。如果構(gòu)架設(shè)計(jì)不明確，集成測試設(shè)計(jì)將無法很好的完成。同樣集成測試可以用來發(fā)現(xiàn)構(gòu)架設(shè)計(jì)中的錯(cuò)誤、遺漏和二義性問題，包括前期的驗(yàn)證活動和后期的確認(rèn)測試。7集成測試的層次一個(gè)產(chǎn)品的開發(fā)過程包括了一個(gè)分層的設(shè)計(jì)和逐步細(xì)化的過程，從最初的產(chǎn)品到最小的單元。該層次大致可以通過下圖表示出來。系統(tǒng)結(jié)構(gòu)圖8軟件結(jié)構(gòu)圖9課程內(nèi)容集成測試介紹集成測試分

5、析集成測試策略集成測試過程集成測試環(huán)境10集成測試分析要做好集成測試，必須加強(qiáng)集成測試的分析工作。類似于概要設(shè)計(jì)對詳細(xì)設(shè)計(jì)的作用，集成測試分析直接指導(dǎo)了集成測試用例的設(shè)計(jì)，并且在整個(gè)集成測試過程中占據(jù)了最關(guān)鍵的地位。11體系結(jié)構(gòu)分析體系結(jié)構(gòu)的分析需要從兩個(gè)角度出發(fā)，首先從需求的跟蹤實(shí)現(xiàn)出發(fā)，劃分出系統(tǒng)實(shí)現(xiàn)上的結(jié)構(gòu)層次圖形。結(jié)構(gòu)圖對集成的層次考慮是由幫助的。其次需要?jiǎng)澐窒到y(tǒng)組件之間的依賴關(guān)系圖，如下圖所示。通過該圖的分析，需要?jiǎng)澐殖黾蓽y試的粒度，即基礎(chǔ)模塊的大小。集成測試模塊的劃分是一件頭疼的事，模塊劃分到底要多大？需不需要設(shè)計(jì)驅(qū)動和樁？該模塊的劃分是不是可以有效降低消息接口的復(fù)雜性？接口是否

6、充分等？模塊劃分的好，可以極大提高集成測試的效率，反之則會降低集成測試的質(zhì)量。關(guān)于模塊的劃分請參考下一節(jié)。體系結(jié)構(gòu)的分析還為集成測試策略的選擇提供了思路。12系統(tǒng)依賴關(guān)系示意圖系統(tǒng)依賴關(guān)系示意圖13模塊分析模塊分析是集成測試分析最重要的工作之一。模塊劃分的好壞直接影響了集成測試的工作量、進(jìn)度以及質(zhì)量。因此需要慎重對待模塊的分析。一般模塊劃分可以從下面幾個(gè)角度出發(fā)進(jìn)行考慮：本次測試主要是希望測試哪個(gè)模塊；這個(gè)模塊與哪幾個(gè)模塊有最密切關(guān)系，可以一、二、三、四按照密切程度排隊(duì)；把該模塊與關(guān)系最密切的模塊首先集成在一起；這時(shí)再考慮這樣劃分后的外圍模塊，這些模塊與被集成模塊之間的消息流是否容易模擬，是否

7、方便控制。14模塊分析一個(gè)合理的集成模塊劃分應(yīng)該滿足以下幾點(diǎn)：被集成的幾個(gè)子模塊關(guān)系緊密；外圍模塊便于屏蔽，外圍模塊與集成模塊之間沒有太多、太頻繁的調(diào)用關(guān)系，被集成模塊沒有采用類似POST_MESSAGE等調(diào)用函數(shù)的方式調(diào)用外圍模塊的情況。如果實(shí)在無法避免，你不得不考慮編寫樁函數(shù)或樁模塊，以代替被屏蔽部分的功能。模擬外圍模塊發(fā)往被集成模塊的消息便于構(gòu)造、修改；外圍模塊發(fā)往被測試模塊的消息能夠模擬大部分實(shí)際環(huán)境的情況；15模塊分析的2/8原則在軟件工程中有一條事實(shí)上的原則，即2/8原則，該原則對測試同樣起作用。從測試的實(shí)踐發(fā)現(xiàn)，測試中發(fā)現(xiàn)的錯(cuò)誤中的80%很可能起源于程序模塊中的20%【6】。并且

8、經(jīng)驗(yàn)也告訴我們，很多錯(cuò)誤報(bào)告常常可以在同一個(gè)模塊中被追蹤到，并且統(tǒng)計(jì)數(shù)據(jù)表明一段程序中已經(jīng)發(fā)現(xiàn)的錯(cuò)誤數(shù)目往往和尚未發(fā)現(xiàn)的錯(cuò)誤數(shù)成正比。例如，在IBM OS/370操作系統(tǒng)中，用戶發(fā)現(xiàn)的全部錯(cuò)誤的47%只與該系統(tǒng)中4%的模塊有關(guān)。對這樣的一些模塊，我們稱之為易錯(cuò)模塊或高危模塊。一般我們可以把系統(tǒng)中的模塊劃分成三個(gè)等級：高危模塊（這是集成測試需要關(guān)注的關(guān)鍵模塊），一般模塊低危模塊（如果時(shí)間不允許的話，往往會減少或忽略這部分模塊的集成，同時(shí)可能會對這類模塊直接采用大爆炸式集成策略）。所以，劃分集成測試對象模塊時(shí)，首先應(yīng)該判斷系統(tǒng)中哪些是關(guān)鍵的模塊。16關(guān)鍵模塊的特性和多個(gè)軟件需求有關(guān)，或與關(guān)鍵功能相

9、關(guān)；處于程序控制結(jié)構(gòu)的頂層；本身是復(fù)雜的或者是容易出錯(cuò)的；含有確定性的性能需求；被頻繁使用的模塊（這部分模塊不一定會出錯(cuò)，但可能會是性能的瓶頸，并且這類模塊一旦出錯(cuò)，影響會比較大）；17分析關(guān)鍵模塊的思路盡可能和開發(fā)人員多討論討論，聽聽他們的意見，一般開發(fā)人員對哪些模塊是關(guān)鍵模塊，心理比較清楚；通過使用靜態(tài)分析工具來分析系統(tǒng)各模塊，尋找高內(nèi)聚的模塊、被頻繁調(diào)用的模塊或處于控制頂層的模塊；根據(jù)需求跟蹤表來分析關(guān)鍵模塊，一般與關(guān)鍵功能或關(guān)鍵接口相關(guān)的模塊都是比較關(guān)鍵的。同時(shí)與一些特殊需求相關(guān)的模塊也需要特別關(guān)注；對于一個(gè)維護(hù)型的項(xiàng)目，可以根據(jù)以往的歷史經(jīng)驗(yàn)來判定，這包括產(chǎn)品歷史缺陷的分析；對于一個(gè)

10、新的產(chǎn)品，可以根據(jù)開發(fā)過程前期包括文檔的檢視、代碼的走讀、單元測試發(fā)現(xiàn)的問題進(jìn)行分析，并因此確定可能風(fēng)險(xiǎn)最大的模塊。18函數(shù)質(zhì)量度量分析19函數(shù)調(diào)用關(guān)系分析20系統(tǒng)質(zhì)量度量分析21接口分析集成測試的重點(diǎn)就是要測試接口的功能性、接口的可靠性、接口的安全性、接口的完整性、接口的穩(wěn)定性等多個(gè)方面。因此我們必須對被測對象的接口進(jìn)行詳細(xì)的分析。這些分析包括接口的劃分，接口的分類和穿越接口的數(shù)據(jù)分析。22接口的劃分接口的劃分是以概要設(shè)計(jì)為基礎(chǔ)的，其方法與相關(guān)的結(jié)構(gòu)設(shè)計(jì)技術(shù)類似。一般可以通過下面幾個(gè)步驟來完成：確定系統(tǒng)的邊界、子系統(tǒng)的邊界和模塊的邊界。確定模塊內(nèi)部的接口；確定子系統(tǒng)內(nèi)模塊間接口；確定子系統(tǒng)間

11、接口；確定系統(tǒng)與操作系統(tǒng)的接口；確定系統(tǒng)與硬件的接口；確定系統(tǒng)與第三方軟件的接口；23接口的分類系統(tǒng)內(nèi)接口：系統(tǒng)內(nèi)部各模塊交互的接口，這是集成測試的重點(diǎn)；系統(tǒng)外接口：外部系統(tǒng)（包括人、硬件和軟件）對系統(tǒng)交互的接口，這類測試一般會延續(xù)到系統(tǒng)測試階段來完成。24系統(tǒng)內(nèi)接口函數(shù)接口：通過函數(shù)的調(diào)用和被調(diào)用關(guān)系來確定。關(guān)于函數(shù)接口的集成測試比較成熟，提到的大部分集成策略都可以應(yīng)用到這類接口上。消息接口：消息接口在面向?qū)ο笙到y(tǒng)和嵌入式系統(tǒng)中是很普遍的。在這種接口下，軟件模塊間并不直接發(fā)生聯(lián)系，而是通過消息包（遵循接口協(xié)議）發(fā)生關(guān)系，常見的例子是整個(gè)系統(tǒng)共用一個(gè)或多個(gè)消息包隊(duì)列，由操作系統(tǒng)進(jìn)行消息包調(diào)度，

12、取出位于消息隊(duì)列頭的消息并調(diào)用該消息的處理模塊的處理函數(shù)。該處理模塊，其核心通常是一個(gè)被動的有限狀態(tài)機(jī)模型，根據(jù)消息內(nèi)容和自身狀態(tài)做出反應(yīng)，通常是完成狀態(tài)遷移并將發(fā)往另一個(gè)模塊的消息放到消息隊(duì)列中去。對于這種接口的測試我們往往采用工具來模擬，在集成策略上可以使用7.2中支持有限狀態(tài)機(jī)模型的集成策略。其它接口：其它類型接口包括全局變量、配置表、注冊信息、中斷等。這類接口具有一定的隱蔽性，往往測試人員會忽略這部分接口。這類接口經(jīng)常是測試不充分的。這類接口的測試需要借助一定的自動化工具。25接口數(shù)據(jù)分析對于函數(shù)接口，我們需要關(guān)注穿越函數(shù)接口的參數(shù)個(gè)數(shù)、參數(shù)屬性（參數(shù)類型，輸入輸出屬性）、參數(shù)的順序、

13、參數(shù)的等價(jià)類情況、參數(shù)的邊界值情況等。如果需要的話還要考慮他們的組合情況。關(guān)于消息接口，我們需要分析消息的類型、消息的域、域的順序、域的屬性、域的取值范圍、可能的異常值等。如果需要的話，也要考慮它們的組合情況。關(guān)于類接口，我們需要對類的屬性進(jìn)行分析，一般重點(diǎn)在于對公共屬性和保護(hù)屬性進(jìn)行分析。必要的時(shí)候會對部分私有屬性進(jìn)行分析。分析的方法包括等價(jià)類劃分和邊界值分析。對于其它類接口的分析，我們需要分析其讀寫屬性、并發(fā)性、等價(jià)類和邊界值。特別對于配置文件這類接口，其涉及到的數(shù)據(jù)變化量是及其龐大的，在分析這類數(shù)據(jù)的時(shí)候，可能需要結(jié)合一定的約束條件，盡可能減少用例的數(shù)量。26集成測試的風(fēng)險(xiǎn)技術(shù)風(fēng)險(xiǎn)如測試

14、人員對集成測試技術(shù)掌握比較薄弱或沒有類似產(chǎn)品的集成測試經(jīng)驗(yàn)；產(chǎn)品缺乏相關(guān)技術(shù)文檔尤其是對接口描述穩(wěn)定的缺乏；測試人員缺乏產(chǎn)品背景知識；測試人員對相關(guān)集成測試工具使用不了解等等；人員風(fēng)險(xiǎn)如人員變動頻繁，人員到位不及時(shí)，缺乏有經(jīng)驗(yàn)的老員工等；物料儀器測試環(huán)境如電腦、單板或其他硬件風(fēng)險(xiǎn)；物料儀器申購風(fēng)險(xiǎn)；測試工具無法及時(shí)到位風(fēng)險(xiǎn)等；管理風(fēng)險(xiǎn)版本計(jì)劃更改風(fēng)險(xiǎn)；人員、時(shí)間計(jì)劃變更風(fēng)險(xiǎn)；缺乏有效配置管理；過程失控；開發(fā)進(jìn)度延遲等；市場風(fēng)險(xiǎn)市場需求更改；市場供貨時(shí)間更改等；27可測試性分析系統(tǒng)的可測試性分析應(yīng)當(dāng)在項(xiàng)目開始的時(shí)候作為一項(xiàng)需求提出來，并設(shè)計(jì)到系統(tǒng)中去。在集成測試階段，我們分析可測試性主要是為了平

15、衡隨著集成范圍的增加而導(dǎo)致的可測試性下降。對于一個(gè)接口不可測的系統(tǒng)，集成測試的實(shí)現(xiàn)是相當(dāng)困難的，這會導(dǎo)致大量測試代碼的添加或接口測試工具的開發(fā)。盡可能早的分析接口的可測試性，提前為測試的實(shí)現(xiàn)做好準(zhǔn)28常見的集成測試故障配置/版本控制錯(cuò)誤；遺漏、重疊或沖突的函數(shù)；文件或數(shù)據(jù)庫使用不正確的或不一致的數(shù)據(jù)結(jié)構(gòu)；文件或數(shù)據(jù)庫使用沖突的數(shù)據(jù)視圖/用法；破壞全局存儲或數(shù)據(jù)庫數(shù)據(jù)的完整性；由于編碼錯(cuò)誤或未預(yù)料到的運(yùn)行時(shí)綁定導(dǎo)致的錯(cuò)誤方法調(diào)用；客戶發(fā)送違反服務(wù)器前提條件的消息；客戶發(fā)送違反服務(wù)器順序約束的消息；錯(cuò)誤的對象和消息的綁定（多態(tài)中經(jīng)常發(fā)生）；錯(cuò)誤參數(shù)或不正確的參數(shù)值；由不正確的內(nèi)存管理分配/收回引起

16、的失?。徊徽_的使用虛擬機(jī)、ORB或OS服務(wù)；IUT試圖使用目標(biāo)環(huán)境的服務(wù)，而該服務(wù)對目標(biāo)環(huán)境的指定版本是已經(jīng)過時(shí)或不向上兼容的；IUT試圖使用目標(biāo)環(huán)境的新服務(wù)，而該目標(biāo)環(huán)境當(dāng)前的版本不支持該服務(wù)；組件之間的沖突，例如當(dāng)進(jìn)程Y運(yùn)行時(shí)，線程X就會崩潰；資源競爭：目標(biāo)環(huán)境不能分配象征性裝載所需要的資源29集成測試用例設(shè)計(jì)思路集成測試是界于白盒測試和黑盒測試之間的灰盒測試，因此在該測試的用例設(shè)計(jì)方法中會綜合使用兩類測試中的測試分析方法。一般經(jīng)過集成測試分析之后，測試用例的大致輪廓已經(jīng)確定，集成測試用例設(shè)計(jì)的基本要求就是要充分保證其正確性，保證其能無誤的完成測試項(xiàng)既定的測試目標(biāo)。在這里我們根據(jù)單元測試

17、用例設(shè)計(jì)的思路，來分析集成測試的用例設(shè)計(jì)（其實(shí)不管做哪個(gè)級別的測試，一般都脫離不了這些思路，不同的是思維的重點(diǎn)和覆蓋的范圍）。在實(shí)際操作的時(shí)候，你可能需要綜合這些方法。30為系統(tǒng)運(yùn)行起來而設(shè)計(jì)用例集成測試的第一個(gè)需要關(guān)注問題是接口能用，并且不會阻塞后續(xù)的集成測試執(zhí)行。因此可以根據(jù)這個(gè)原則設(shè)計(jì)一些基本功能的測試用例來進(jìn)行最低限度的驗(yàn)證。可使用的測試分析技術(shù)：規(guī)范導(dǎo)出法等價(jià)類劃分31為正向測試而設(shè)計(jì)用例假設(shè)我們的過程是良好的，那么我們的接口設(shè)計(jì)及模塊功能設(shè)計(jì)需求是明確和無誤的。那么作為集成測試的一個(gè)重點(diǎn)就是需要驗(yàn)證這些接口需求和集成后的模塊功能需求被正確無誤的滿足了。基于這個(gè)原則，我們直接可以根據(jù)

18、概要設(shè)計(jì)文檔導(dǎo)出相關(guān)的用例。可使用的測試分析技術(shù)：規(guī)范導(dǎo)出法輸入域測試輸出域覆蓋等價(jià)類劃分狀態(tài)轉(zhuǎn)換測試32為逆向測試而設(shè)計(jì)用例在集成測試中的逆向測試包括分析被測接口有沒有實(shí)現(xiàn)規(guī)格沒有要它實(shí)現(xiàn)的功能，規(guī)格中可能出現(xiàn)的接口遺漏或接口定義錯(cuò)誤，分析可能出現(xiàn)的接口異常情況，包括接口數(shù)據(jù)本身的錯(cuò)誤，接口數(shù)據(jù)順序錯(cuò)誤等。有時(shí)，在經(jīng)過接口的數(shù)據(jù)量是相當(dāng)龐大的，例如在電信軟件中，一些協(xié)議消息，動輒就包括了幾十、上百個(gè)IE （Information Element）。考慮所有IE的異常情況，甚至異常組合幾乎是不可能的。因此在這一點(diǎn)上還需要基于一定的條件約束，包括分析一些關(guān)鍵的IE，不可能的組合情況，需要考慮的組

19、合等。對于面向?qū)ο笙到y(tǒng)和基于有限狀態(tài)機(jī)的系統(tǒng)還需要考慮可能出現(xiàn)的狀態(tài)異常，包括：丟失的或不正確的狀態(tài)轉(zhuǎn)換；一個(gè)有效的消息被忽略；不可預(yù)測的行為；一個(gè)可能的潛行路徑；一個(gè)不期望的消息引起的失?。唤邮軟]有定義的消息等。可使用的測試分析技術(shù)：錯(cuò)誤猜測法基于風(fēng)險(xiǎn)的測試基于故障的測試邊界值分析特殊值測試狀態(tài)轉(zhuǎn)換測試33為滿足特殊需求而設(shè)計(jì)用例以前的觀點(diǎn)中，類似安全性測試，性能測試，可靠性測試等主要在系統(tǒng)測試階段進(jìn)行，但是目前通過在軟件設(shè)計(jì)過程中細(xì)化了這些特殊的需求，一些產(chǎn)品開始在模塊設(shè)計(jì)文檔中就明確了接口的安全性指標(biāo)、性能指標(biāo)等，這種情況下應(yīng)盡早開展接口相對于這些特殊需求的測試，以便最終保證系統(tǒng)整體特殊

20、需求的滿足。可使用的測試分析技術(shù)：規(guī)范導(dǎo)出法34為高覆蓋設(shè)計(jì)用例不同于單元測試，在集成測試中最關(guān)注的覆蓋是功能覆蓋和接口覆蓋。通過分析集成后模塊的哪些功能沒有被測試到，哪些接口沒有被覆蓋（尤其對于消息接口，所有可能的正常消息，異常消息都應(yīng)當(dāng)被驗(yàn)證）到來設(shè)計(jì)測試用例?？墒褂玫臏y試分析技術(shù)：功能覆蓋分析接口覆蓋分析35測試用例設(shè)計(jì)注意事項(xiàng)成本，進(jìn)度，質(zhì)量是我們開發(fā)過程中需要均衡的三個(gè)點(diǎn)，同樣在集成測試過程中，我們也需要考慮這三者之間的平衡。測試重點(diǎn)要突出，關(guān)鍵的接口必須被覆蓋到，同時(shí)用例設(shè)計(jì)要考慮充分的可回歸性和執(zhí)行的自動化。36集成測試分析案例舉例教師提供案例，分析集成測試方案根據(jù)貴公司文檔，討

21、論集成測試方案.37課程內(nèi)容集成測試介紹集成測試分析集成測試策略集成測試過程集成測試環(huán)境38一般單元級測試針對該體系結(jié)構(gòu)圖最底層的葉子節(jié)點(diǎn)，而系統(tǒng)測試對應(yīng)的是產(chǎn)品級的。而當(dāng)中所有各層測試都需要通過集成測試來完成，由于集成的力度不同，一般可以把集成測試劃分成三個(gè)級別：模塊內(nèi)集成測試；子系統(tǒng)內(nèi)集成測試；子系統(tǒng)間集成測試；軟件模塊結(jié)構(gòu)圖39集成測試策略集成測試策略就是在測試對象分析的基礎(chǔ)上，描述軟件模塊集成（組裝）的方式、方法。 集成測試的基本策略比較多，分類比較雜，Mayer分析比較了自底向上集成（Bottom-Up Integration），自頂向下集成（Top-Down Integration

22、），大爆炸集成（Big Bang Integration）和三明治集成（Sandwich Itegration）。Beizer 提出了基干集成（Backbone Integration）方法。Jacoboson提出了關(guān)于面向?qū)ο笙到y(tǒng)中集成的策略。Robrt V. Binder對這些方法進(jìn)行了綜合性的介紹，并總結(jié)成了相應(yīng)的模式。40大爆炸集成目的在最短的時(shí)間內(nèi)把系統(tǒng)組裝出來，并且通過最少的測試來驗(yàn)證整個(gè)系統(tǒng)。介紹大爆炸集成（Big Bang Integration）是屬于非增值式集成（Non-Incremental Integration）的一種方法，也叫一次性組裝或整體拼裝。該集成把所有系統(tǒng)組

23、件一次性集合到被測系統(tǒng)中，不考慮組件之間的相互依賴性或者可能存在的風(fēng)險(xiǎn)。應(yīng)用一個(gè)系統(tǒng)范圍內(nèi)的測試包來證明系統(tǒng)最低限度的可操作性。策略在這種集成方式中，首先對每個(gè)模塊分別進(jìn)行單元測試，然后再把所有單元組裝在一起進(jìn)行測試，最終得到要求的軟件系統(tǒng)。如圖(a)有一系統(tǒng)結(jié)構(gòu)，其單元測試和組裝順序如圖(b)所示。在圖中，模塊d1、d2、d3、d4、d5是對各個(gè)模塊做單元測試時(shí)建立的驅(qū)動模塊，s1、s2、s3、s4、s5是為單元測試而建立的樁模塊。41大爆炸集成優(yōu)點(diǎn)在有利的情況下，大爆炸集成可以迅速完成集成測試，并且只要極少數(shù)的驅(qū)動和樁模塊設(shè)計(jì)（如果需要的話）；它需要的測試用例也是最少的；該方法比較簡單；多

24、個(gè)測試人員可以并行工作，對人力，物力資源利用率較高。缺點(diǎn)這種一次性組裝方式試圖在輔助模塊的協(xié)助下，在模塊單元測試的基礎(chǔ)上，將所測模塊連接起來進(jìn)行測試。但是由于程序中不可避免地存在模塊間接口、全局?jǐn)?shù)據(jù)結(jié)構(gòu)等方面的問題，所以一次試運(yùn)行成功的可能性并不很大；在發(fā)現(xiàn)錯(cuò)誤的時(shí)候，其問題定位和修改都比較困難；即使被測系統(tǒng)能夠被一次性集成，但還是會有許多接口錯(cuò)誤很容易的躲過測試而進(jìn)入到系統(tǒng)范圍測試內(nèi)。我們一般不推薦單獨(dú)使用這種集成方法。42大爆炸集成適用范圍一個(gè)維護(hù)型項(xiàng)目（或功能增強(qiáng)型項(xiàng)目），其以前的產(chǎn)品已經(jīng)很穩(wěn)定，并且新增的項(xiàng)目只有少數(shù)幾個(gè)組件被增加或修改；被測系統(tǒng)比較小，并且它的每個(gè)組件都經(jīng)過了充分的單

25、元測試；產(chǎn)品使用了嚴(yán)格的凈室軟件工程過程，并且每個(gè)開發(fā)階段的質(zhì)量和單元測試質(zhì)量都相當(dāng)高。43自頂向下的集成目的從頂層控制開始，采用同設(shè)計(jì)順序一樣的思路對被測系統(tǒng)進(jìn)行測試，以驗(yàn)證系統(tǒng)的接口穩(wěn)定性。介紹自頂向下的集成（Top-Down Integration）采用了和設(shè)計(jì)一樣的順序?qū)ο到y(tǒng)進(jìn)行測試，它在第一時(shí)間內(nèi)對系統(tǒng)的控制接口進(jìn)行了驗(yàn)證。假定你正遵循一個(gè)迭代式或增量式的方法在開發(fā)一個(gè)系統(tǒng)，該系統(tǒng)控制結(jié)構(gòu)模型與樹一樣，其中頂層的組件具有控制的責(zé)任，采用自頂向下的集成測試首先集中于頂層的組件，然后逐步測試處于底層的組件。自頂向下的集成方式可采用深度優(yōu)先策略和廣度優(yōu)先策略。策略在這里我們使用74（a）這

26、個(gè)模型來描述該方法的具體策略：以主模塊為所測模塊兼驅(qū)動模塊，所有直屬于主模塊的下屬模塊全部用樁模塊替換，對主模塊進(jìn)行測試；采用深度優(yōu)先（Depth-First）（如圖75所示）或?qū)挾葍?yōu)先（Breadth-First）（如圖76所示）的策略，用實(shí)際模塊替換相應(yīng)樁模塊，再用樁代替它們的直接下屬模塊，與已測試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)；進(jìn)行回歸測試（即重新執(zhí)行以前做過的全部測試或部分測試），排除組裝過程中引起的錯(cuò)誤的可能；判斷是否所有的模塊都已組裝到系統(tǒng)中？如果是，則結(jié)束測試，否則轉(zhuǎn)到步驟2去執(zhí)行。44自頂向下的集成深度優(yōu)先組裝方式45自頂向下的集成廣度優(yōu)先組裝方式46自頂向下的集成優(yōu)點(diǎn)自頂向下

27、的增殖方式在測試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。在一個(gè)功能劃分合理的程序模塊結(jié)構(gòu)中，判斷常常出現(xiàn)在較高的層次里，因而較早就能遇到。如果主要控制有問題，盡早發(fā)現(xiàn)它能夠減少以后的返工，所以這是十分必要的；如果選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能，可先對邏輯輸入的分支進(jìn)行組裝和測試，檢查和克服潛藏的錯(cuò)誤和缺陷，驗(yàn)證其功能的正確性，就為其后對主要加工分支的組裝和測試提供了保證；功能可行性較早得到證實(shí)，還能夠給開發(fā)者和用戶帶來成功的信心；最多只需要一個(gè)驅(qū)動模塊（頂層組件的驅(qū)動器）。減少了驅(qū)動器開發(fā)的費(fèi)用。特定組件的驅(qū)動器一般使用難以編碼的測試用例并且與組件的接口耦合性很大

28、，這種設(shè)置限制了驅(qū)動器和測試包的復(fù)用。而采用自頂向下的策略，最多只需要維護(hù)一個(gè)頂層模塊的驅(qū)動器，盡管也會遇到不可復(fù)用的問題，但維護(hù)工作量將小很多；由于和設(shè)計(jì)順序的一致性，因此可以和設(shè)計(jì)并行進(jìn)行，如果目標(biāo)環(huán)境可能存在改變，該方法可以比較靈活的適應(yīng)；支持故障隔離，例如，假設(shè)A模塊執(zhí)行正確，但是加入B模塊后，測試執(zhí)行失敗，那么可以確定，要么B模塊有問題，要么A和B的接口有錯(cuò)誤。47自頂向下的集成缺點(diǎn)樁的開發(fā)和維護(hù)是本策略的最大成本。因?yàn)闃对诿總€(gè)測試中都必須被提供，并且隨著測試配置使用的樁的數(shù)目增加，維護(hù)樁的成本將急劇上升；底層組件中的一個(gè)無法預(yù)計(jì)的需求可能會導(dǎo)致許多頂層組件的修改，這破壞了部分先前構(gòu)

29、造的測試包；底層組件行為的驗(yàn)證被推遲了。同時(shí)為了能夠有效的進(jìn)行測試，需要控制模塊具有比較高的可測試性；隨著底層模塊的不斷增加，整個(gè)系統(tǒng)越來越復(fù)雜，導(dǎo)致底層模塊的測試不充分，尤其是那些被重用的模塊。48自頂向下的集成適用范圍該方法適合于大部分采用結(jié)構(gòu)化編程方法的軟件產(chǎn)品，且產(chǎn)品的結(jié)構(gòu)相對比較簡單，一般對于大型復(fù)雜的項(xiàng)目往往會采用多種集成測試方法的綜合使用策略。對于具有如下屬性的產(chǎn)品，可以優(yōu)先考慮本集成測試策略。產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；產(chǎn)品的高層接口變化比較小；產(chǎn)品的底層接口未定義或經(jīng)常可能被修改；產(chǎn)品的控制模塊具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；希望盡早能夠看到產(chǎn)品的系統(tǒng)功能行為；在極限編程

30、（Extreme Programming）中使用探索式開發(fā)風(fēng)格時(shí)，其集成策略可以采用自頂向下策略。49自底向上的集成目的從具有最小依賴性的底層組件開始，按照依賴關(guān)系樹的結(jié)構(gòu)，逐層向上集成，以檢測整個(gè)系統(tǒng)的穩(wěn)定性。介紹自底向上的集成（BottomUp Integration）方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測試。因?yàn)槟K是自底向上進(jìn)行組裝，對于一個(gè)給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以通過直接運(yùn)行子模塊得到。策略自底向上集成的步驟如下：起始于模塊依賴關(guān)系樹的底層葉子模塊，也可以把兩個(gè)或

31、多個(gè)葉子模塊合并到一起進(jìn)行測試，或者把只有一個(gè)子節(jié)點(diǎn)的父模塊與其子模塊結(jié)合在一起進(jìn)行測試；使用驅(qū)動模塊對步驟1選定的模塊（或模塊組）進(jìn)行測試；用實(shí)際模塊代替驅(qū)動模塊，與它已測試的直屬子模塊組裝成為一個(gè)更大的模塊組進(jìn)行測試；重復(fù)上面的行為直到系統(tǒng)的最頂層模塊被加入到已測系統(tǒng)中。以圖74（a）這個(gè)模型為例，該集成策略可以使用圖77表示。50自底向上的集成其中，d1，d2，d3，d4，d5代表驅(qū)動模塊，圖形中的集成順序?yàn)橛勺蟮接摇Ｗ缘紫蛏霞墒疽?51自底向上的集成優(yōu)點(diǎn)允許對底層模塊行為的早期驗(yàn)證。可以在任何一個(gè)葉子節(jié)點(diǎn)已經(jīng)就緒的情況下進(jìn)行集成測試；在工作的最初可能會并行進(jìn)行集成，在這一點(diǎn)上比使用自

32、頂向下的策略效率高；由于驅(qū)動模塊是額外編寫的，而不是實(shí)際模塊，因此對實(shí)際被測模塊的可測試性要求比自頂向下的集成策略要小得多；減少了樁模塊的工作量，畢竟在集成測試中，樁模塊的工作量遠(yuǎn)比驅(qū)動模塊的工作量要大得多。但是為了模擬一些中斷或異常，可能還是需要設(shè)計(jì)一定的樁模塊；該方法也支持故障隔離。52自底向上的集成缺點(diǎn)驅(qū)動模塊的開發(fā)工作量也是很龐大的（可以通過提供對已測試組件的復(fù)用技術(shù)來降低這個(gè)成本）；對高層的驗(yàn)證被推遲到了最后，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)，尤其對于那些控制結(jié)構(gòu)在整個(gè)體系中非常關(guān)鍵的產(chǎn)品；隨著集成到了頂層，整個(gè)系統(tǒng)將變得越來越復(fù)雜，并且對于底層的一些異常將很難覆蓋，而使用樁將簡單得多。5

33、3自底向上的集成適用范圍該方法適合于大部分采用結(jié)構(gòu)化編程方法的軟件產(chǎn)品，且產(chǎn)品的結(jié)構(gòu)相對比較簡單，一般對于大型復(fù)雜的項(xiàng)目往往會采用多種集成測試方法的綜合使用策略。對于具有如下屬性的產(chǎn)品，可以優(yōu)先考慮本集成測試策略。采用契約式開發(fā)（Design by Contract）的產(chǎn)品；底層接口比較穩(wěn)定的產(chǎn)品；高層接口變化比較頻繁的產(chǎn)品；底層模塊較早被完成的產(chǎn)品。54三明治集成目的綜合自頂向下的集成測試策略和自底向上底集成測試策略優(yōu)點(diǎn)。介紹三明治集成（Sandwich Integration）有時(shí)也被稱為混合式集成。由于自頂向下集成策略和自底向上底集成策略都有各自的缺點(diǎn)，因此自然而然的想到集中這兩者優(yōu)點(diǎn)的

34、混合測試策略。三明治集成就是這樣一種方法，它把系統(tǒng)劃分成三層，中間一層為目標(biāo)層。測試的時(shí)候，對目標(biāo)層上面的一層使用由頂向下的集成策略，對目標(biāo)層下面的一層使用自底向上的集成策略，最后測試在目標(biāo)層會合。策略使用這個(gè)模型，其中目標(biāo)層為B，C，D。目標(biāo)層上面一層是A，目標(biāo)層下面一層是E，F(xiàn)。使用三明治集成的具體步驟如下：首先對目標(biāo)層上面的一層使用由頂向下的集成策略，因此測試A，使用樁代替B，C，D；其次對目標(biāo)層下面的一層使用自底向上底集成策略，因此測試E，F(xiàn)，使用驅(qū)動代替B，D；其三，把目標(biāo)層下面的一層與目標(biāo)層集成，因此測試（B，E），（D，F(xiàn)），使用驅(qū)動代替A；最后，把三層集成到一起，因此測試（A，

35、B，C，D，E，F(xiàn)）55三明治集成我們在進(jìn)行三明治集成的時(shí)候，需要記住盡可能減少驅(qū)動和樁模塊的數(shù)量，例如在上面例子中，我們選取使用由目標(biāo)層下面一層與目標(biāo)層先集成，而不是使用目標(biāo)層上面一層與目標(biāo)層先集成，這是因?yàn)檫@樣可以減少樁模塊的設(shè)計(jì)。三明治測試策略56三明治集成優(yōu)點(diǎn)集合了由頂向下和自底向上的兩種集成策略的優(yōu)點(diǎn)；缺點(diǎn)中間層在被集成前測試不充分。適用范圍大部分軟件開發(fā)項(xiàng)目都可以使用這種集成策略。57修改過的三明治集成目的彌補(bǔ)三明治集成不能充分測試中間層的缺點(diǎn)，盡可能提高測試的并行性。介紹略。策略該方法的具體步驟如下：并行測試目標(biāo)層，目標(biāo)層上面一層，目標(biāo)層下面一層。其中對目標(biāo)層上面一層使用自頂向下

36、集成策略，目標(biāo)層下面一層使用自底向上集成策略，對目標(biāo)層使用獨(dú)立測試策略（需要驅(qū)動和樁）；并行測試目標(biāo)層與目標(biāo)層上面一層的集成和目標(biāo)層與目標(biāo)層下面一層的集成；58修改過的三明治集成修改后的三明治集成59修改過的三明治集成優(yōu)點(diǎn)具有三明治集成的所有優(yōu)點(diǎn)，且能對中間層能夠盡早進(jìn)行比較充分的測試。該策略的并行度比較高。缺點(diǎn)中間層如果選取不恰當(dāng)，可能會有比較大的驅(qū)動模塊和樁模塊的工作量；適用范圍大多數(shù)軟件開發(fā)項(xiàng)目。60基干集成目的結(jié)合自頂向下，自底向上和大爆炸集成的元素，以驗(yàn)證緊密耦合的子系統(tǒng)間的互操作性。介紹基干集成（Backbone Integration）是由Beizer提出來的。在很多系統(tǒng)中，尤其

37、在嵌入式系統(tǒng)中，一般可以劃分成兩個(gè)部分：內(nèi)核部分（基干部分）和外圍應(yīng)用部分，這兩部分經(jīng)常會被不同的項(xiàng)目組并行開發(fā)。它具有如下特點(diǎn)：內(nèi)核部分提供了系統(tǒng)最基本的功能和服務(wù)；外圍應(yīng)用以內(nèi)核為基礎(chǔ)，不能脫離內(nèi)核而獨(dú)自使用；內(nèi)核具有很高的耦合性，并且相當(dāng)復(fù)雜，試圖設(shè)置其樁模塊會是相當(dāng)困難且成本很高的事情；高層控制層可以使用較高層或中間層做樁來進(jìn)行測試；中間層是有一些模塊組構(gòu)成，這些模塊組內(nèi)具有較高的耦合性，而模塊組之間耦合較松散。61基干集成策略基干集成策略首先應(yīng)識別應(yīng)用的控制組件部分，基干部分和應(yīng)用子系統(tǒng)部分。測試的順序是基于這個(gè)分析結(jié)果的。其具體的測試步驟大致可以表述如下：對基干中的每個(gè)模塊進(jìn)行單獨(dú)

38、的，充分的測試，必要時(shí)使用驅(qū)動器和樁模塊；對基干中所有的模塊進(jìn)行大爆炸集成，形成基干子系統(tǒng)，并使用一個(gè)驅(qū)動模塊檢查經(jīng)過大爆炸的基干；對應(yīng)用的控制子系統(tǒng)進(jìn)行自頂向下的集成；把基干和控制子系統(tǒng)進(jìn)行集成，重新構(gòu)造控制子系統(tǒng)；對各應(yīng)用子系統(tǒng)采用自底向上底集成策略；集成基干子系統(tǒng)，控制子系統(tǒng)和各應(yīng)用子系統(tǒng)形成整個(gè)系統(tǒng)；62基干集成優(yōu)點(diǎn)具有三明治集成的優(yōu)點(diǎn)，更適合于大型復(fù)雜項(xiàng)目的集成；缺點(diǎn)必須對系統(tǒng)的結(jié)構(gòu)和相互依存性進(jìn)行仔細(xì)的分析；必須開發(fā)樁模塊和驅(qū)動模塊，并且由于被測系統(tǒng)的復(fù)雜性導(dǎo)致這些模塊開發(fā)工作量的加大，可以通過復(fù)用技術(shù)在一定程度上降低成本；由于局部采用了大爆炸的策略，因此有些接口可能測試不完整。使

39、用范圍基干集成策略比較適合于大型復(fù)雜項(xiàng)目，一般來說，對于具有如下特定的項(xiàng)目可以優(yōu)先考慮：具有多層協(xié)議的嵌入式系統(tǒng)開發(fā)；操作系統(tǒng)產(chǎn)品。63分層集成目的通過增量式集成的方法驗(yàn)證一個(gè)具有層次體系結(jié)構(gòu)的應(yīng)用系統(tǒng)的穩(wěn)定性和可互操作性。介紹分層模型在通訊系統(tǒng)中是很常見的。分層集成（Layers Integration）就是針對這個(gè)特點(diǎn)使用的一種集成策略。系統(tǒng)的層次劃分可以通過邏輯的或物理的手段進(jìn)行。在邏輯上，一般通過功能把系統(tǒng)劃分成不同功能層次的子系統(tǒng)，子系統(tǒng)內(nèi)部具有較高的耦合性，子系統(tǒng)間的關(guān)系具有線性層次關(guān)系；在物理上，可以根據(jù)不同單板內(nèi)的系統(tǒng)劃分為不同的硬件子系統(tǒng)，各硬件子系統(tǒng)之間根據(jù)連接具有線性層次

40、關(guān)系。如果各層之間有拓樸網(wǎng)絡(luò)關(guān)系，則不適合使用該集成方法。64分層集成策略分層集成的具體步驟大致如下：劃分系統(tǒng)的層次確定每個(gè)層次內(nèi)部的集成策略，該策略可以使用大爆炸集成，自頂向下集成，自底向上集成和三明治集成中的任何一種策略。一般對于頂層可能還有第二層的內(nèi)部采用自頂向下的集成策略；對于中間層采用自底向上的集成策略；對于底層主要進(jìn)行單獨(dú)測試；確定層次間的集成策略，該策略可以使用大爆炸集成，自頂向下集成，自底向上集成和三明治集成中的任何一種策略。65層次內(nèi)集成下圖給出了一個(gè)分層集成的示意圖，層之間采用了由頂向下的集成策略。66層間集成67分層集成優(yōu)點(diǎn)其優(yōu)缺點(diǎn)與其使用的層間集成測試策略類似。缺點(diǎn)同上

41、。使用范圍有明顯線性層次關(guān)系的產(chǎn)品系統(tǒng)。68基于功能的集成目的采用增值的方法，盡早的驗(yàn)證系統(tǒng)關(guān)鍵功能。介紹在開發(fā)過程中，如果能盡早看到系統(tǒng)的主要功能被實(shí)現(xiàn)，這對整個(gè)團(tuán)隊(duì)的士氣是一個(gè)極大的鼓舞?；诠δ艿募桑‵unctionBased Integration）是從功能角度出發(fā)，按照功能的關(guān)鍵程度對模塊的集成順序進(jìn)行組織。69基于功能的集成策略基于功能的集成策略大致步驟如下：確定功能的優(yōu)先級別；分析優(yōu)先級最高的功能路徑，把該路徑上的所有模塊集成到一起，必要是使用驅(qū)動模塊和樁模塊；增加一個(gè)關(guān)鍵功能，繼續(xù)步驟2，直到所有模塊都被集成到被測系統(tǒng)中；注：為了提高集成的有效性，在步驟2的時(shí)候，會優(yōu)先考慮關(guān)

42、鍵功能的正常路徑（盡可能覆蓋最少模塊集），然后逐步考慮該功能的異常路徑，并增加相應(yīng)的異常處理模塊。對于步驟3，一般在選擇下一個(gè)關(guān)鍵功能的時(shí)候，需要看該功能的增加會不會引起新模塊的加入，如果不會引起新模塊的加入，那么可以考慮選擇再下一個(gè)關(guān)鍵功能，因?yàn)檫@里的測試是要做到所有模塊的覆蓋，而不是功能的覆蓋或路徑的覆蓋。70基于功能的集成優(yōu)點(diǎn)采用該方法，可以盡快的看到關(guān)鍵功能的實(shí)現(xiàn)，并驗(yàn)證關(guān)鍵功能的正確性；由于該方法在驗(yàn)證某個(gè)功能的時(shí)候，可能會同時(shí)加入多個(gè)模塊，因此在進(jìn)度上比自底向上，自頂向下或三明治集成要短；接口的覆蓋使用的測試用例比較少；可以減少驅(qū)動模塊的開發(fā)，原因與自頂向下的集成策略類似。缺點(diǎn)對于

43、復(fù)雜系統(tǒng)，功能之間的相互關(guān)聯(lián)性可能是錯(cuò)綜復(fù)雜并難以分析的；對有些接口的測試不充分，會丟失許多接口錯(cuò)誤；一些初始的集成需要使用樁模塊；可能會有比較大的冗余測試；使用范圍關(guān)鍵功能具有較大風(fēng)險(xiǎn)的產(chǎn)品；技術(shù)探索型的項(xiàng)目，其功能的實(shí)現(xiàn)遠(yuǎn)比質(zhì)量更關(guān)鍵；對于功能實(shí)現(xiàn)沒有把握的產(chǎn)品；71高頻集成目的頻繁的將新代碼加入到一個(gè)已經(jīng)穩(wěn)定的基線（Baseline）中，以免集成故障難以發(fā)現(xiàn)，同時(shí)控制可能出現(xiàn)的基線偏差。介紹快速迭代式開發(fā)或增量式開發(fā)可能會導(dǎo)致功能的遺漏或沖突。其最初的起始可能是一個(gè)最低功能限度的集成包，隨著新代碼的迅速開發(fā)并加入到系統(tǒng)中，需要驗(yàn)證擴(kuò)大后的系統(tǒng)是否是穩(wěn)定的，并且功能是正確的，如果這些問題遺

44、留到最后再檢查，其成本可能是巨大的。高頻集成（High-frequency Integration）就是采用的這個(gè)策略。使用高頻集成需要具備以下條件：可以獲得一個(gè)穩(wěn)定的增量，并且已完成的某子系統(tǒng)已被驗(yàn)證沒有問題；大部分有意義的功能增加可以在一個(gè)固定的頻率間隔內(nèi)獲得，比如通過每日創(chuàng)建來獲得；測試包和代碼并行開發(fā)，并且始終維護(hù)的是最新的版本；必須使用自動化，例如采用GUI的捕獲/回放工具；必須使用配置管理工具，否則版本的增量將無法控制；72高頻集成策略高頻集成有三個(gè)主要的步驟，具體如下：1、開發(fā)人員完成要提供的代碼的增量部分，同時(shí)測試人員完成相關(guān)的測試包，具體包括：編寫或修改代碼；編寫或修改對相應(yīng)

45、代碼的測試包；對新增或修改過的代碼進(jìn)行代碼走讀，檢視和評審；對測試包進(jìn)行代碼走讀，檢視和評審對修改或新增的組件進(jìn)行靜態(tài)分析（如：PCLINT檢查等，一般是通過工具來完成）；對代碼進(jìn)行創(chuàng)建工作（Build）；在新的創(chuàng)建上運(yùn)行測試包，包括使用類似內(nèi)存檢測工具，性能檢測工具進(jìn)行跟蹤檢查；當(dāng)組件通過所有測試時(shí)，將已修改過的測試包提交到集成測試部門；73高頻集成策略2、集成測試人員將開發(fā)人員修改或增加的組件集中起來形成一個(gè)新的集成體，并且在上面運(yùn)行集成后的測試包。具體工作包括：在一個(gè)既定的規(guī)定期限內(nèi)，負(fù)責(zé)集成的人員終止接受任何增量，并形成一個(gè)新系統(tǒng)的基線；進(jìn)行創(chuàng)建工作，并在上面運(yùn)行測試包。這個(gè)測試將包括

46、冒煙測試，新開發(fā)的測試。如果時(shí)間允許應(yīng)盡可能多的運(yùn)行測試；3、評價(jià)結(jié)果?！霸诮ㄔ爝^程中，糾正錯(cuò)誤是項(xiàng)目中優(yōu)先級最高的”。74高頻測試需要解決的問題在高頻集成中，必須切實(shí)有效的解決下列問題：誰維護(hù)現(xiàn)有的集成測試包？創(chuàng)建的周期是多長？誰來進(jìn)行創(chuàng)建工作？誰來做集成測試？在什么情況下進(jìn)行？當(dāng)創(chuàng)建失敗或測試沒有通過時(shí)，采取什么后續(xù)的動作？系統(tǒng)將退回到哪個(gè)版本？問題定位和糾正的任務(wù)分配給哪個(gè)人或哪個(gè)組織？如何進(jìn)行自動化？75高頻集成優(yōu)點(diǎn)由于在該策略中，開發(fā)維護(hù)源代碼和測試包具有同等的重要性，這對有效防止錯(cuò)誤非常有幫助；嚴(yán)重錯(cuò)誤，遺漏和不正確的假設(shè)經(jīng)常能被較早的揭示；當(dāng)錯(cuò)誤產(chǎn)生時(shí)，其最可能存在于新增加或修改

47、的代碼中，這對調(diào)試非常有利；整個(gè)開發(fā)組集中于生產(chǎn)一個(gè)運(yùn)轉(zhuǎn)的系統(tǒng)，而不是用于實(shí)際工作的一個(gè)系統(tǒng)。這有助于開發(fā)人員盡早能夠看到一個(gè)可運(yùn)行的系統(tǒng)，并提高士氣；對樁代碼的需要不是必須的，這可以避免編寫和維護(hù)容易損壞的測試代碼；開發(fā)和集成可以并行進(jìn)行；缺點(diǎn)測試包可能會過于簡單，并因此難以發(fā)現(xiàn)有價(jià)值的問題；在剛開始的幾個(gè)周期可能不易于平穩(wěn)的進(jìn)行集成；如果沒有對高頻集成建立適當(dāng)?shù)臉?biāo)準(zhǔn)，一長串成功的集成可能導(dǎo)致不應(yīng)有的可信度，這往往會使風(fēng)險(xiǎn)增加；使用范圍采用迭代（或增量）過程模型開發(fā)的產(chǎn)品76基于進(jìn)度的集成目的盡可能早的進(jìn)行集成測試，提高開發(fā)與集成的并行性，有效的縮短進(jìn)度。介紹進(jìn)度壓力是每個(gè)軟件開發(fā)項(xiàng)目都會遇

48、到的問題。為了完成進(jìn)度，很多項(xiàng)目往往犧牲了部分的質(zhì)量，并且加班加點(diǎn)的疲勞工作。基于進(jìn)度的集成（ScheduleBased Integration）就是在兼顧進(jìn)度和質(zhì)量兩者之間尋找了一個(gè)均衡點(diǎn)。該集成的一個(gè)最基本的策略就是把最早可獲得的代碼拿來立即進(jìn)行集成，必要的時(shí)候開發(fā)樁模塊和驅(qū)動模塊，在最大程度上保持與開發(fā)的并行性，從而縮短了項(xiàng)目集成的時(shí)間。優(yōu)點(diǎn)具有比較高的并行度；能夠有效縮短項(xiàng)目開發(fā)的進(jìn)度；缺點(diǎn)可能最早拿到的模塊之間缺乏整體性，只能進(jìn)行獨(dú)立的集成，導(dǎo)致許多接口必須等到后期才能驗(yàn)證，但此時(shí)系統(tǒng)可能已經(jīng)很復(fù)雜，往往無法發(fā)現(xiàn)有效的接口問題；樁模塊和驅(qū)動模塊的工作量可能會變得很龐大；由于進(jìn)度的原因

49、，模塊可能很不穩(wěn)定且會不斷變動，導(dǎo)致測試的重復(fù)和浪費(fèi)；使用范圍進(jìn)度優(yōu)先級高于質(zhì)量的項(xiàng)目77基于風(fēng)險(xiǎn)的集成目的在第一時(shí)間內(nèi)驗(yàn)證高危模塊間的接口，從而保證系統(tǒng)的穩(wěn)定性。介紹基于風(fēng)險(xiǎn)的集成（RiskBased Integration）是基于這樣一個(gè)假設(shè)，既系統(tǒng)風(fēng)險(xiǎn)最高的模塊間的集成往往是錯(cuò)誤集中的地方，因此盡早的驗(yàn)證這些接口有助于加速系統(tǒng)的穩(wěn)定，從而增加對系統(tǒng)的信心。該方法與基于功能的集成有一定的相通之處，可以結(jié)合使用。優(yōu)點(diǎn)最具有風(fēng)險(xiǎn)的模塊最早進(jìn)行驗(yàn)證，有助于系統(tǒng)的快速穩(wěn)定；缺點(diǎn)需要對各組件的風(fēng)險(xiǎn)有一個(gè)清晰的分析使用范圍項(xiàng)目有些模塊具有較大的風(fēng)險(xiǎn)，且沒有信心78基于事件（消息）的集成目的從驗(yàn)證消息路

50、徑的正確性出發(fā)，漸增式的把系統(tǒng)集成到一起，從而驗(yàn)證系統(tǒng)的穩(wěn)定性。介紹對于許多基于狀態(tài)機(jī)的系統(tǒng)來說（例如，嵌入式系統(tǒng)，面向?qū)ο笙到y(tǒng)），其工作原理是基于狀態(tài)變遷，內(nèi)部模塊間的接口主要是通過消息來完成的。因此驗(yàn)證消息路徑的正確性對于這類系統(tǒng)具有比較重要的位置，基于消息/事件/線程的集成（MessageBased/EventBased/ThreadBased Integration）就是針對這一特點(diǎn)而設(shè)計(jì)的一種策略。79基于事件（消息）的集成策略從系統(tǒng)的外部看，分析系統(tǒng)可能輸入的消息集；選取一條消息，分析其穿越的模塊；集成這些模塊進(jìn)行消息接口測試；選取下一條消息，重復(fù)步驟2和3，直到所有模塊都被集成到系統(tǒng)中；注：消息的選取可以從三個(gè)角度考慮，消息的重要性；盡早驗(yàn)證重要的消息路徑；消息路徑的長度；為了能有效驗(yàn)證接口的完整性和正確性，盡可能選取路徑較短的消息；新的消息的選擇是否能夠使得