安裝 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/