安裝 Build
Build 本身必須提供命令行安裝模式，具體過程如下。
- 解壓剛下載的最新 Build
- 啟動 silent install （安裝所需的配置文件必須預先定義好）
- 檢查安裝日志，確認沒有錯誤發生
- 初步驗證安裝結果，例如文件系統，數據庫，以及創建在 Websphere 應用服務器中的各種配置對象等。
Build 成功安裝是執行功能測試用例的前提。如果驗證程序無法檢測出 Build 安裝失敗，則其在繼續執行功能測試用例時，測試用例必然失敗，驗證程序雖然仍能判斷 Build 是壞的，但問題定位卻是錯誤的：某功能測試用例失敗，實際則是安裝失敗。
為避免這種情況的發生，就要求對實際安裝結果進行適當驗證。通常來說，簡單的日志檢查并不充分，我們還要預先搞清正確的安裝結果，并以此為標準對實際安裝結果進行驗證，如文件系統和數據庫等。
執行主干功能測試用例
Build 驗證只對軟件的主干功能進行初步測試，不同軟件的測試用例各不相同。在測試用例的自動化開發中，需要注意以下幾點：
- 盡量選擇相對穩定的系統級接口，如各模塊的命令行腳本，J2EE 應用服務器的 mbean 等。這樣可以使 Build 自動驗證程序長時間穩定運行，而無需頻繁修改。
- 對測試用例執行結果進行嚴格驗證，如檢查返回代碼，日志文件，以及用例生成的各種對象（如數據庫記錄等），以此提高對壞 Build 的問題自動定位的準確度。
- 避免圖形用戶界面（GUI）的細節測試。因為在一個完整的軟件開發周期中，GUI 的實現是一個漸進的過程，因此它們的自動化測試腳本也需要經常更新。這與 Build 自動驗證程序的穩定性要求相背。
- 避免陷入底層的 API 測試，一方面底層 API 本身并不穩定，另一方面單元測試已經覆蓋底層 API 的測試。
發布 Build 驗證結果
構建（Build）驗證服務器需要把 Build 驗證結果存儲到驗證結果發布服務器，兩者通過數據庫交互，數據庫結構可參考 BVT（Build Verification Test）DDL 。
清單 2. BVT DDL
create table BVT.RESULTS ( ---- build id ---- BUILD_ID VARCHAR(256) NOT NULL, ---- start time of BVT ---- START_TIME TIMESTAMP, ---- end time of BVT ---- END_TIME TIMESTAMP, ---- whether the build passed BVT ---- BVT_STATE SMALLINT, ---- result of the download build step ---- DOWNLOAD_BUILD SMALLINT, ---- result of the silent install step ---- SILENT_INSTALL SMALLINT, ---- result of the install verification step ---- VERIFY_INSTALL SMALLINT, ---- result of each test case ---- CASE1 SMALLINT, CASE2 SMALLINT, … … ---- defect number for the bad build ---- DEFECT_NO VARCHAR(20), ---- log.zip ---- BVT_LOG BLOB(1000M), ---- specific description for the build ---- NOTES VARCHAR(2048), primary key (BUILD_ID) ); |
驗證結果發布通常包含以下步驟：
- 將測試用例的執行結果存儲到驗證結果發布服務器。
- 將 Build 驗證過程的相關日志存儲到驗證結果發布服務器。
- 將 Build 驗證結果通過 email 發送給相關的測試開發人員。
- 如果被驗證 Build 是壞的，則自動在 Bug 追蹤系統（如 CMVC）中生成 Defect 。
清理測試環境
Build 驗證結果發布以后，必須清理測試環境，為下一個 Build 做好準備。這個步驟非常重要，由于構建（Build）驗證服務器需要在無人干預的情況下 7 × 24 小時連續運行，如果環境清理不成功，則可能引起下一次 Build 自動驗證的失敗，甚至導致構建（Build）驗證服務器發送錯誤的 Build 驗證報告。一般來說，有以下幾種清理測試環境的方法：
- 調用軟件本身的卸載命令。由于軟件開發過程中，卸載命令本身可能并不完善，出錯的可能性很大，所以該方法使用較少。
- 直接編程刪除文件系統的相關文件，數據庫中的相關對象，甚至操作系統中的相關配置。該方法可靠性較好，但需要較大的開發工作量，而且在整個軟件開發周期中，可能需要經常修改環境清理程序。尤其當被驗證的軟件需要安裝在其他軟件之上的時候，環境清理問題會變得更加復雜。
- 準備一個干凈的測試環境（如果被驗證軟件需要安裝在其他軟件之上，則可事先安裝好相關的軟件），然后用 Ghost（或其他備份軟件）做硬盤備份，清理測試環境時只要簡單的從備份映像恢復即可。
方案 3 簡單可靠，而且適用于復雜軟件（即被驗證軟件需要安裝在其他軟件之上）。在 Windows 上，我們可以配置一個任務計劃（Scheduled Task）使得自動驗證程序在備份映像恢復時能夠自啟動。
結束語
構建（Build）自動驗證可以作為自動化開發環境的一個增強環節，通過對軟件主干功能的初步測試，盡快將嚴重錯誤報給開發人員，并為測試人員過濾掉不符合要求的壞構建（Build）。本文給出的 Build 自動驗證解決方案具有較強的通用性，但應用到具體軟件的構建（Build）自動驗證時，仍需選擇適當的功能測試用例，尤其要注意對測試用例執行結果的嚴格驗證，以提高對壞構建（Build）中的問題的自動定位的準確度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
