基本介紹
- 中文名：組裝測試
- 外文名：Assemble testing
- 別名：集成測試、聯合測試
- 屬性：單元測試的邏輯擴展
- 標準：《軟體概要設計規格說明》
- 方法：黑盒測試方法
- 來源：設計模型、組裝構件計畫
簡介,組裝過程,簡介,組裝測試工作機制,工件清單,組裝測試常用方案選型,簡介,自底向上組裝測試,核心繫統先行組裝測試,高頻組裝測試,組裝測試計畫書 模版,
簡介
組裝測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計畫，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。
組裝測試是在單元測試的基礎上，測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模組、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在組裝測試之前，單元測試應該已經完成，組裝測試中所使用的對象應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那么組裝測試的效果將會受到很大影響，並且會大幅增加軟體單元代碼糾錯的代價。
組裝測試是單元測試的邏輯擴展。在現實方案中，組裝是指多個單元的聚合，許多單元組合成模組，而這些模組又聚合成程式的更大部分，如分系統或系統。組裝測試採用的方法是測試軟體單元的組合能否正常工作，以及與其他組的模組能否組裝起來工作。最後，還要測試構成系統的所有模組組合能否正常工作。組裝測試所持的主要標準是《軟體概要設計規格說明》，任何不符合該說明的程式模組行為都應該加以記載並上報。
所有的軟體項目都不能擺脫系統組裝這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟體單元做起，軟體單元只有經過組裝才能形成一個有機的整體。具體的組裝過程可能是顯性的也可能是隱性的。只要有組裝，總是會出現一些常見問題，工程實踐中，幾乎不存在軟體單元組裝過程中不出任何問題的情況。從圖1可以看出，組裝測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。
組裝測試的必要性還在於一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常工作。程式在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如疊代式開發，設計和實現是疊代進行的。在這種情況下，組裝測試的意義還在於它能間接地驗證概要設計是否具有可行性。
組裝過程
簡介
一、組裝測試過程
二、單元測試工作內容及其流程
三、組裝測試需求獲取
2． 由組裝工作版本的外部接口確定組裝測試用例。
組裝測試工作機制
軟體組裝測試工作由產品評測部擔任。需要項目組相關角色配合完成。如圖示：
軟體評測部：
軟體項目組：
組裝測試工作內容及其流程：
工件清單
2、 組裝測試用例
3、 測試過程
4、 測試腳本
5、 測試日誌
6、 測試評估摘要
組裝測試常用方案選型
簡介
組裝測試的實施方案有很多種，如自底向上組裝測試、自頂向下組裝測試、Big-Bang組裝測試、三明治組裝測試、核心組裝測試、分層組裝測試、基於使用的組裝測試等。在此，筆者將重點討論其中一些經實踐檢驗和一些證實有效的組裝測試方案。
自底向上組裝測試
自底向上的組裝（Bottom-Up Integration）方式是最常使用的方法。其他組裝方法都或多或少地繼承、吸收了這種組裝方式的思想。自底向上組裝方式從程式模組結構中最底層的模組開始組裝和測試。因為模組是自底向上進行組裝的，對於一個給定層次的模組，它的子模組（包括子模組的所有下屬模組）事前已經完成組裝並經過測試，所以不再需要編制樁模組（一種能模擬真實模組，給待測模組提供調用接口或數據的測試用軟體模組）。自底向上組裝測試的步驟大致如下:
步驟一: 按照概要設計規格說明，明確有哪些被測模組。在熟悉被測模組性質的基礎上對被測模組進行分層，在同一層次上的測試可以並行進行，然後排出測試活動的先後關係，制定測試進度計畫。圖2給出了自底向上的組裝測試過程中各測試活動的拓撲關係。利用圖論的相關知識，可以排出各活動之間的時間序列關係，處於同一層次的測試活動可以同時進行，而不會相互影響。
步驟二: 在步驟一的基礎上，按時間線序關係，將軟體單元組裝為模組，並測試在組裝過程中出現的問題。這裡，可能需要測試人員開發一些驅動模組來驅動組裝活動中形成的被測模組。對於比較大的模組，可以先將其中的某幾個軟體單元組裝為子模組，然後再組裝為一個較大的模組。
步驟四: 將各子系統組裝為最終用戶系統，測試是否存在各分系統能否在最終用戶系統中正常工作。
核心繫統先行組裝測試
核心繫統先行組裝測試法的思想是先對核心軟體部件進行組裝測試，在測試通過的基礎上再按各外圍軟體部件的重要程度逐個組裝到核心繫統中。每次加入一個外圍軟體部件都產生一個產品基線，直至最後形成穩定的軟體產品。核心繫統先行組裝測試法對應的組裝過程是一個逐漸趨於閉合的螺旋形曲線，代表產品逐步定型的過程。其步驟如下:
步驟二: 對於核心繫統中的所有模組一次性集合到被測系統中，解決組裝中出現的各類問題。在核心繫統規模相對較大的情況下，也可以按照自底向上的步驟，組裝核心繫統的各組成模組。
步驟四: 在外圍軟體部件添加到核心繫統以前，外圍軟體部件應先完成內部的模組級組裝測試。
步驟五: 按順序不斷加入外圍軟體部件，排除外圍軟體部件組裝中出現的問題，形成最終的用戶系統。
方案點評: 該組裝測試方法對於快速軟體開發很有效果，適合較複雜系統的組裝測試，能保證一些重要的功能和服務的實現。缺點是採用此法的系統一般應能明確區分核心軟體部件和外圍軟體部件，核心軟體部件應具有較高的耦合度，外圍軟體部件內部也應具有較高的耦合度，但各外圍軟體部件之間應具有較低的耦合度。
高頻組裝測試
高頻組裝測試是指同步於軟體開發過程，每隔一段時間對開發團隊的現有代碼進行一次組裝測試。如某些自動化組裝測試工具能實現每日深夜對開發團隊的現有代碼進行一次組裝測試，然後將測試結果發到各開發人員的電子信箱中。該組裝測試方法頻繁地將新代碼加入到一個已經穩定的基線中，以免組裝故障難以發現，同時控制可能出現的基線偏差。使用高頻組裝測試需要具備一定的條件: 可以持續獲得一個穩定的增量，並且該增量內部已被驗證沒有問題; 大部分有意義的功能增加可以在一個相對穩定的時間間隔（如每個工作日）內獲得; 測試包和代碼的開發工作必須是並行進行的，並且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本; 必須藉助於使用自動化工具來完成。高頻組裝一個顯著的特點就是組裝次數頻繁，顯然，人工的方法是不勝任的。
高頻組裝測試一般採用如下步驟來完成:
步驟一: 選擇組裝測試自動化工具。如很多Java項目採用Junit+Ant方案來實現組裝測試的自動化，也有一些商業組裝測試工具可供選擇。
步驟三: 測試人員和開發人員負責編寫對應程式代碼的測試腳本。
步驟五: 測試人員監督代碼開發人員及時關閉不合格項。
按照步驟三至步驟五不斷循環，直至形成最終軟體產品。
以上我們介紹了幾種常見的組裝測試方案，一般來講，在現代複雜軟體項目組裝測試過程中，通常採用核心繫統先行組裝測試和高頻組裝測試相結合的方式進行，自底向上的組裝測試方案在採用傳統瀑布式開發模式的軟體項目組裝過程中較為常見。讀者應該結合項目的實際工程環境及各測試方案適用的範圍進行合理的選型。
組裝測試計畫書 模版
原創作者：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. 審核測試用例，未通過返回第三步
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）
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 對於組裝部經理無法決定的上交項目負責人決定；
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.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審批
組裝部經理 技術部經理
姓名： 姓名：
日期： 日期：
