組裝測試

組裝測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。

組裝測試是在單元測試的基礎上，測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在組裝測試之前，單元測試應該已經完成，組裝測試中所使用的對象應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那麼組裝測試的效果將會受到很大影響，並且會大幅增加軟體單元代碼糾錯的代價。

組裝測試是單元測試的邏輯擴展。在現實方案中，組裝是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。組裝測試採用的方法是測試軟體單元的組合能否正常工作，以及與其他組的模塊能否組裝起來工作。最後，還要測試構成系統的所有模塊組合能否正常工作。組裝測試所持的主要標準是《軟體概要設計規格說明》，任何不符合該說明的程序模塊行為都應該加以記載並上報。

所有的軟體項目都不能擺脫系統組裝這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟體單元做起，軟體單元只有經過組裝才能形成一個有機的整體。具體的組裝過程可能是顯性的也可能是隱性的。只要有組裝，總是會出現一些常見問題，工程實踐中，幾乎不存在軟體單元組裝過程中不出任何問題的情況。從圖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進入第一輪測試，測試人員大體了解一下產品情況，如果在一小時之內發現5個以上（含5個）操作性錯誤，或者3個以上（含3個）功能性錯誤，退回測試組測試；

O遇到有項目優先順序更高的組裝測試任務；

O遇到有項目優先順序更高的組裝任務；

O在測試複測過程中發現產品無法運行下去；

O人員，設備不足。

7.2恢復條件

O符合進入組裝測試條件（一小時之內發現5個以下（不含5個）操作性錯誤，或者3個以下（不含3個）功能性錯誤）；

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測試進度

測試工作進度(人*工作日)

測試計劃8

測試設計60

測試執行總共進度30

每次回歸進度10

測試報告2

14風險及應急計劃

設備不到位：加緊設備購買；

人員不到位

人員請假：請假人員回來加班或趕緊測試進度/申請調配新的人員；

人員離職：調配新的人員；

人員調配到其他部門或項目：調配新的人員；

開發人員開發頻頻出錯：通知開發部門，商量策略；

其他原因的測試工作頻頻被掛起或者掛起后遲遲恢復不了：加班或延期

15審批

組裝部經理技術部經理

姓名：

日期：