談產(chǎn)品集成

　　對于大型產(chǎn)品開(kāi)發(fā)，一次可能開(kāi)發(fā)多個(gè)新的業(yè)務(wù)系統，同時(shí)一個(gè)業(yè)務(wù)系統本身又包含多個(gè)業(yè)務(wù)模塊和組件。只要我們在前期產(chǎn)品規劃中存在子系統和模塊的分解，那么后續就一定存在產(chǎn)品集成的動(dòng)作。在架構設計中我們通過(guò)進(jìn)行組件分解，識別和定義組件間接口，一方面是通過(guò)分而治之降低大系統復雜度，另外一方面則是通過(guò)分解和接口定義后各模塊可以并行開(kāi)發(fā)。只要架構階段存在分解動(dòng)作，那么最終在各模塊開(kāi)發(fā)完成后一定存在集成動(dòng)作。架構做出一個(gè)假設，只要在分解的時(shí)候各組件模塊按預定的接口契約進(jìn)行實(shí)現，那么后續各個(gè)組件一定可以進(jìn)行集成和組裝形成一個(gè)完整的產(chǎn)品。所以架構不能僅僅只關(guān)心解耦，還必須關(guān)心集成和裝配，解耦后的東西無(wú)法集成，那么分解過(guò)程仍然是失敗的。

　　產(chǎn)品集成和持續集成的關(guān)系

　　產(chǎn)品集成強調是的是把左右的組件最終能夠組裝和集成起來(lái)，形成一個(gè)完整的系統。而大師Martin Fowler對持續集成是這樣定義的:持續集成是一種軟件開(kāi)發(fā)實(shí)踐，即團隊開(kāi)發(fā)成員經(jīng)常集成它們的工作，通常每個(gè)成員每天至少集成一次，也就意味著(zhù)每天可能會(huì )發(fā)生多次集成。每次集成都通過(guò)自動(dòng)化的構建(包括編譯，發(fā)布，自動(dòng)化測試)來(lái)驗證，從而盡快地發(fā)現集成錯誤。許多團隊發(fā)現這個(gè)過(guò)程可以大大減少集成的問(wèn)題，讓團隊能夠更快的開(kāi)發(fā)內聚的軟件?？梢?jiàn)持續集成只能算做產(chǎn)品集成的一個(gè)子實(shí)踐。

　　要明白持續集成只是產(chǎn)品集成的一種方式，不論是開(kāi)發(fā)過(guò)程是瀑布模式，增量模式還是迭代模式，都可以采用持續集成的思路。要明白持續集成的一個(gè)核心是將整個(gè)開(kāi)發(fā)過(guò)程透明化，同時(shí)將集成工作提前化。盡可能早的暴露問(wèn)題和風(fēng)險，同時(shí)糾正在前期系統分析和架構設計中的不足。

　　對于持續集成我們往往會(huì )強調每日構建，冒煙測試，自動(dòng)化測試等內容。強調開(kāi)發(fā)，測試和生產(chǎn)環(huán)境的部署流水線(xiàn)作業(yè)。但是要明白對于大型產(chǎn)品集成仍然回包括模塊內測試和集成，模塊間測試和集成，跨系統間的測試和集成工作。對于單個(gè)模塊內可以采用每日構建和持續集成策略，但是對于模塊間和跨系統我們可以采取分迭代式的集成方式進(jìn)行集成。

　　關(guān)于持續集成的核心邏輯

　　在這里要分兩個(gè)層面來(lái)談，首先是單環(huán)境，涉及到自動(dòng)化構建，部署，測試一系列動(dòng)作。具體過(guò)程可以簡(jiǎn)化描述如下。首先是編寫(xiě)好自動(dòng)化編譯腳本代碼，如使用ant工具完成;然后設置定時(shí)作業(yè)和任務(wù)，開(kāi)發(fā)人員按時(shí)check in相關(guān)代碼。使用CI持續集成工具根據定時(shí)任務(wù)點(diǎn)在構建環(huán)境自動(dòng)獲取最新代碼，自動(dòng)運行ant自動(dòng)化編譯腳本對代碼進(jìn)行編譯，編譯完成后自動(dòng)化部署到某個(gè)環(huán)境。部署完成后運行單元測試自動(dòng)化腳本對代碼進(jìn)行自動(dòng)化測試，輸出自動(dòng)化測試結果和報告;如果通過(guò)的話(huà)測試人員通過(guò)QTP進(jìn)行進(jìn)一步自動(dòng)化測試或手工執行一遍冒煙測試腳本，完成本次持續集成。在持續集成模式下，一方面是可以盡可能早的發(fā)現問(wèn)題，一方面對測試人員隨時(shí)都可以有一個(gè)可進(jìn)行詳細功能性測試的可用環(huán)境。

　　其次如果對于多環(huán)境，涉及到開(kāi)發(fā)環(huán)境測試通過(guò)后自動(dòng)部署集成測試環(huán)境，集成測試環(huán)境測試通過(guò)后自動(dòng)部署到驗收環(huán)境等一系列動(dòng)作。對此我們叫部署流水線(xiàn)模式，實(shí)現跨環(huán)境的持續集成管理。

　　對于持續集成，由于組件間可能存在編譯依賴(lài)，我們需要分析組件間的依賴(lài)關(guān)系，以順利的完成整改編譯過(guò)程。而在產(chǎn)品集成過(guò)程中我們考慮的不是編譯依賴(lài)而是本身組件間的功能依賴(lài)，因此我們需要進(jìn)一步詳細的考慮組件間的集成順序和集成策略問(wèn)題。

　　產(chǎn)品集成順序的分析

　　產(chǎn)品集成順序分為兩種模式，一種是自頂向下的模式進(jìn)行集成，一種是自底向上的方式進(jìn)行集成。對于自頂向下方式的集成，首先集成最外層或流程最末端的業(yè)務(wù)模塊，業(yè)務(wù)模塊前置依賴(lài)用模擬器(樁)實(shí)現。然后繼續在每一層按寬度或深度優(yōu)先，用完全實(shí)現模塊代替模擬器，并建立下層。以這種方式繼續直到所有被測系統中的樁已經(jīng)實(shí)現和測試。在這種模式下可以看到整個(gè)集成過(guò)程完全是頂層需求驅動(dòng)進(jìn)行，集成工作可以較早的開(kāi)始進(jìn)行，如果產(chǎn)品集成圖是正金字塔結構較容易，模擬器開(kāi)發(fā)較少;反之同理。

　　對于自底向上集成，首先集成最底層的業(yè)務(wù)模塊，只在底層模塊未實(shí)現前使用模擬器(樁)。然后繼續在實(shí)現并測試對上一級模塊，這些構件使用已經(jīng)測試的下級模塊。整個(gè)系統使用根一級模塊測試。對于這種模式模擬器開(kāi)發(fā)較少，同時(shí)上次各模塊基本可以開(kāi)始并行測試。這種集成方式最大的風(fēng)險是如果上次需求變化可能直接影響到最底層。

　　產(chǎn)品集成的集成場(chǎng)景分析

　　集成場(chǎng)景分析目的是為后續的集成測試用例設計提供依據，集成測試用例要覆蓋所有場(chǎng)景。對于場(chǎng)景分析輸入主要包括跨模塊協(xié)同業(yè)務(wù)流程圖，系統需求規格說(shuō)明書(shū)，概要設計說(shuō)明書(shū)等。對于集成場(chǎng)景分析可以從靜態(tài)和動(dòng)態(tài)兩個(gè)層面進(jìn)行分析，對于靜態(tài)分析主要分析模塊依賴(lài)關(guān)系，分析某一個(gè)服務(wù)接口影響到的業(yè)務(wù)模塊具體功能點(diǎn)，可以模塊-》模塊的矩陣分析方法進(jìn)行。對于動(dòng)態(tài)分析主要是根據跨系統或模塊流程入手，分析跨模塊的流程協(xié)同，流程協(xié)同中所涉及到的所有接口服務(wù)。

　　集成場(chǎng)景的分析將為集成測試用例的設計提供核心輸入，要明白，集成測試不是簡(jiǎn)單的接口測試，接口反映的是跨系統或模塊的交互流程，需要通過(guò)交互流程的貫通來(lái)檢驗接口本身的正確性。

原文轉自：http://kjueaiud.com