軟件測試之-集成測試


1、集成測試概念

	1.集成測試也叫組裝測試、聯合測試、子系統測試或部件測試。

	2.集成測試是在單元測試的基礎上,將所有模塊按照概要設計要求(如根據結構圖)組裝成為子系統或系統,進行集成測試。

2、集成測試的目的

	1.找出模塊接口以及整體體系結構上的問題;
	
	2.確保各組件組合在一起后能夠按照既定意圖協作運行,並確保增量的行為正確;
	
	3.集成測試屬於灰盒測試;
	
			1)驗證接口是否與設計相符合;
			
			2)發現設計和需求中存在的錯誤。

3、集成測試關注的重點

一些模塊雖可以單獨正常工作,但不能保證連接起來也能正常工作,程序在某些局部反映不出來的問題,在全局上就很有可能暴露出來,影響功能的實現。

因此,集成測試應當考慮一下兩個問題:

1.模塊間的接口(需要考慮的有兩點)

		1)在把各個模塊連接起來的時候,穿越模塊接口的數據是否會丟失;
			
		2)全局數據結構是否有問題,會不會被異常修改。

2.集成后的功能(需要考慮三點)

		1)各個子功能組合起來,能否達到預期要求的父功能;
			
		2)一個模塊的功能是否會對另一個模塊的功能產生不利的影響;
			
		3)單個模塊的誤差積累起來,是否會放大,從而達到不可接受的程度。

4、集成測試的層次

一個產品的開發過程包括了一個分層的設計和逐步細化的過程,從最初的產品到最小的單元可以划分為:產品——>子系統——>硬件子系統、軟件子系統——>軟件模塊——軟件程序——>單元。

一般單元測試針對最小的單元結構,系統測試對應於產品級,而當中的所有各層測試都需要通過集成測試來完成,由於集成的力度不同,因此將集成測試划分為3個級別:

	1.模塊內集成測試(單元測試完成后)
		
	2.子系統內集成測試,即模塊間集成測試
	
	3.子系統間集成測試

5、集成測試策略

集成測試策略是在測試對象分析的基礎上,描述軟件模塊集成(組裝)的方式、方法,分類如下:

1.大爆炸集成(Big Bang Integration)

是屬於非增值式集成(Non-Incremental Integration)的一種方法,也叫一次性組裝或整體拼裝。該集成把所有系統組件一次性集合到被測系統中,不考慮組件之間的相互依賴性或者可能存在的風險。應用一個系統范圍內的測試包來證明系統最低限度的可操作性。

	1)方法(策略)
		a.在這種集成方式中,首先對每個模塊分別進行單元測試
		b.然后再把所有單元組裝在一起進行測試		
		c.最后得到要求的軟件系統
			
	2)目的
		在最短時間內把系統組裝出來,並且通過最少的測試來驗證整個系統
			
	3)優點
		a.在有利的情況下,大爆炸集成可以迅速完成集成測試,並且只要極少數的驅動和樁模塊設計(如果需要的話);
		b.它需要的測試用例也是很少的;
		c.該方法比較簡單;
		d.多個測試人員可以並行工作,對人力,物力資源利用率較高。

	4)缺點
		a.這種一次性組裝方式試圖在輔助模塊的協助下,在模塊單元測試的基礎上,將所測模塊連接起來進行測試,但是由於程序中不可避免地存在模塊間接口、全局數據結構等方面的問題,所以一次試運行成功的可能性並不很大;
		b.在發現錯誤的時候,其問題定位和修改都比較困難;
		c.即使被測系統能夠被一次性集成,但還是會有很多接口錯誤很容易的躲過測試而進入到系統范圍測試內。

	5)適用范圍
		a.維護型項目(或功能增強型項目),其以前的產品已經很穩定,並且新增的項目只有少數幾個組件被增加和修改;
		b.被測系統比較小,並且它的每個組件都經過了充分的單元測試;
		c.產品使用了嚴格的凈室軟件工程過程,並且每個開發階段的質量和單元測試質量都非常高。

2.自頂向下的集成策略(Top-Down Integration)

采用了和設計一樣的順序對系統進行測試,在第一時間內對系統的控制接口進行了驗證。

	1)方法(策略)
		 a. 以主模塊為所測模塊兼驅動模塊,所有直屬於主模塊的下屬模塊全部用樁模塊替換,對主模塊進行測試;
		 b.采用深度優先(Depth-First)或者寬度優先(Breath-First)的策略,用實際模塊替換相應樁模塊,再用樁替代它們的直接下屬模塊,與已測試的模塊或子系統組裝成新的子系統;
   	     c.進行回歸測試,排除組裝過程中引起的錯誤的可能;
		 d.判斷所有的模塊是否都已組裝到系統中?如果是,則結束測試,否則轉到b步驟去執行。
			
	2)目的
		從頂層控制開始,采用同設計順序一樣的思路對被測系統進行測試,以驗證系統的接口穩定性。
			
	3)優點
		a.自頂向下的增殖方式在測試過程中較早的驗證了主要的控制和判斷點;
	    b.功能可行性較早得到證實,還能夠給開發者和用戶帶來成功的信心;
		c.最多只需要一個驅動模塊,減少了驅動器開發的費用;
		d.由於和設計順序的一致性,可以和設計並行進行,如果目標環境可能存在改變,該方法可以靈活的適應;
		e.支持故障隔離。

	4)缺點
		a.樁的開發和維護是本策略的最大成本,隨着樁數目增加,成本急劇上升;
		b.底層組件中一個無法預計的需求可能會導致許多頂層組件的修改,這破壞了部分先前構造的測試包;
		c.底層組件行為的驗證被推遲;
		d.隨着底層模塊的不斷增加,整個系統越來越復雜。

	5)適用范圍
		適用於大部分采用結構化編程方法的軟件產品,且產品的結構相對比較簡單,對於具有以下屬性的產品,可以優先考慮該策略:
		a.產品控制結構比較清晰和穩定;
		b.產品的高層接口變化比較小;
		c.產品底層接口未定義或經常可能被修改;
		d.產品控制模塊具有較大的技術風險,需要盡早被驗證;
		e.希望盡早可以看到產品的系統功能行為;
		f.在極端編程(Extreme Program)中使用探索式開發風格時,其集成策略可以采用自頂向下。

3.自底向上的集成策略(Bottom-Up Integration)

是從程序模塊結構的最底層的模塊開始組裝和測試,因為模塊是自底向上進行組裝,對於一個給定層次的模塊,它的子模塊(包括子模塊下屬所有模塊)已經組裝並測試完成,所有不在需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以通過直接運行子模塊得到。

4.三明治集成(Sandwich Integration)

也稱為混合式集成,集合了自頂向下和自底向上兩種策略的優點,它將系統划分為3層,中間一層為目標層,測試的時候,對目標層上面的一層使用自頂向下的集成策略,對目標層下面的一層使用自底向上的集成策略,最后測試在目標層會合。

5.基干集成(Backbone Integration)

在很多系統中,尤其是嵌入式系統,一般划分為兩個部分:內和部分(基干部分)和外圍應用部分,這兩部分經常被不同的項目組並行開發,該策略首先要識別應用的控制組件部分,基干部分和應用子系統部分,然后進行測試。
結合自頂向下,自底向上和大爆炸集成的元素,驗證緊密耦合的子系統之間的互操作性。

6.分層集成(Layers Integration)

分層集成是針對分層模型使用的一種策略。
通過增量式集成的方法驗證一個具有層次體系結構的應用系統的穩定性和可互操作性。

7.基於功能的集成(Function-Based Integration)

是從功能角度出發,按照功能的關鍵程度對模塊的集成順序進行組織。
采用增值的方法,盡早的驗證系統關鍵功能。

8.基於進度的集成(Schedule-Based Integration)

考慮了項目的進度壓力,兼顧進度和質量,在兩者之間尋找均衡點進行測試,該集成的最基本策略是把最早可獲得的代碼拿來立即進行集成,必要的時候開發樁模塊和驅動模塊,在最大程度上保持與開發的並行性,從而縮短了項目集成的時間。

9.基於風險的集成(Risk-Based Integration)

是基於假設:系統風險最高的模塊間的集成往往是錯誤集中的地方,因此盡早的驗證這些接口有助於加速系統的穩定。所以該集成需在第一時間內驗證高危模塊間的接口,保證系統的穩定性。

10.基於事件(消息)的集成(Event/Message-Based Integration)

針對基於狀態機的系統(工作原理是基於狀態變遷,內部模塊間的接口主要通過消息來完成),因此該集成是從驗證消息路徑的正確性角度出發,漸增式的把系統集成到一起,從而驗證系統的穩定性。

11.基於使用的集成(Use-Based Integration)

針對面向對象的系統,從分析類之間的依賴關系出發,通過從最小依賴關系的類開始集成,逐步擴大,最后集成到整個系統,通過該集成方法,可以驗證類之間接口的正確性。

12.分布式集成(Distributed Services Integration)

針對可以有許多並發運行、沒有專門控制軌跡的組件、以及沒有專門服務器層的分布式系統。
驗證松散耦合的同級組件之間交互的穩定性。

13.客戶/服務器的集成(Client/Server Integration)

對於和單獨的服務器組件進行松散耦合的客戶端組件,可以使用客戶/服務器集成來完成。
驗證客戶和服務器之間交互的穩定性。

14.高頻集成(High-frequency Integration)

快速迭代式開發和增量式開發可能會導致系統功能的遺漏和沖突,該集成主要是為了避免以上問題,同時控制可能出現的基線偏差。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM