自動化測試框架思路

Just4life發表於2013-07-30
框架

       1.1          自動化測試的優點

　　 提高測試效率和降低測試成本

        實現快速的迴歸測試，加快測試進度從而加快產品釋出進度

　　 更多的測試，提高測試覆蓋率

       保證一致性

　　 提高測試的可靠性，避免人為因素

 

　　1.2.        為什麼要做自動化測試框架

　　通過以往的嘗試，發現真正實現自動化測試，並不是掌握了某個自動化測試工具，掌握了指令碼的編寫技術就能夠達成，面對複雜的ERP系統，簡單的錄製/回放並不能達到自動化測試的要求，完全通過編寫指令碼的方式，工作量巨大且可維護性極差、不能複用。實現自動化就是為了能夠提升測試效率，不具備可維護性、複用性差將成為導致自動化測試失敗的最致命因素，付出巨大代價但起到的效果甚微。

　　基於以上因素並結合行業發展思路，在正式實施自動化之前，必須搭建一套適合的自動化測試框架，將指令碼能夠有效的組織、連貫應用起來，提高測試指令碼的可維護性和可讀性。

 

　　1.3.        希望達成的目標

　　搭建符合以下要求的自動化測試框架，使得未來自動化測試正式實施時能夠有序、高效的開展：

　　 高複用性

　　 高可維護性

　　 穩定性

　　 快速編寫指令碼

　　 自動執行

　　 正確輸出結果

　　 能夠不斷提升自動化測試比例

 

　　1.4.        實現思路

　　 分層設計：業務流程、功能點、操作元件

　　我們在進行測試時，首先會驗證各個頁面、各個欄位的正確性，到驗證功能點的正確性，再組合各個功能點進行業務邏輯、業務流程的驗證，最終確保系統滿足業務需求。　 　        對於自動化指令碼，採用分層的思想，先實現最底層的操作元件，通過呼叫操作元件、及業務邏輯實現對功能點的驗證，再通過呼叫業務邏輯組合功能點實現對業務流 程的驗證。不同的業務流程，對於底層的操作元件、中間層的功能點函式是完全可以複用的，只是呼叫的業務邏輯的差異，或者是測試資料的差異性。

　　 儘可能做到各指令碼之間具備獨立性，不相互依賴，便於進行各種基本場景的組合執行。

　 　如銷售系統中的選擇房間操作，在做預約、小訂、認購等操作時，都需要用到選擇房產，因此可以將選擇房產做為一個公共的操作元件，詳細描述選擇房產的操作 步驟，在測試新增預約、新增小訂、新增認購等功能點時都需要呼叫到選擇房產的操作元件，只是業務的校驗邏輯與所選擇的資料不一致。

　　再看業務流程，新增一個小訂單後可以作廢，也可以由小訂轉認購，業務流程就有兩個：新增小訂單—作廢訂單，新增小訂單—轉認購，這兩個業務流程中“新增小訂單”這個功能點是一致的，可以通過呼叫不同的用例資料組合成不同的業務流程。

  ● 指令碼分離設計：物件、操作、測試資料、業務邏輯相互剝離、靈活呼叫

　 　對某個功能進行自動化測試，實際上就是對這個功能涉及的物件進行操作，輸入測試資料來驗證其結果的正確性，複雜的驗證點需要編寫業務邏輯。如果全部用腳 本的方式編寫，針對每一條測試資料就需要編寫一份指令碼，指令碼量相當巨大，同時任何改動（程式、測試用例、GUI物件）都需要調整大量的指令碼。

　　為了達到可維護性、可複用性，將物件、操作、測試資料、業務邏輯剝離、分開管理，通過呼叫關係去組合實現不同的測試用例。

　　 物件資源庫

   　 測試資料資源庫

　　 操作元件（描述操作步驟）

　　分離後，如果要增加測試用例，只需要維護測試資料，如果程式修改，增加了物件，那麼只需要維護物件庫、操作元件，增加對這個物件的操作。

　　 封裝基礎函式、基本的業務邏輯、驗證點

　　 通過對基本業務邏輯、驗證點的封裝、呼叫，實現快速的指令碼開發

　　如一個資料儲存的功能，每一條資料在做了增、刪、改的操作後，都需要驗證儲存至後臺資料庫的資料正確性，通過預期結果與資料庫實際產生的資料集進行比較驗證，在獲取資料庫實際產生的資料集的方式是通用的，只是不同的功能所要驗證的資料表、欄位及Where條件不一致，獲取資料集的方式就可以封裝成一個基礎函式，傳入不同的SQL語句做為引數即可。同時預期結果與實際結果集的比較也可以封裝為基礎函式。

　 　再如，系統頁面中在某些操作或條件下，部分欄位是隻讀不允許編輯的，或者是隱藏不顯示的，編寫指令碼時需要對每一個物件寫一條語句驗證其只讀和隱藏屬性的 正確性，如果將只讀和隱藏屬性的驗證進行封裝，針對每一個頁面進行驗證，那麼只需要傳入這個頁面只讀或隱藏的物件名稱，呼叫封裝的函式執行驗證。可以大大 減少指令碼量，也更易於維護。

        有效的執行體系

　　 批量、定製執行、自動執行

　　 自動化測試真正達到提升測試效率，需要實現無人值守情況下的批量自動執行，並且可以定製執行。

　　 異常處理機制

　 　指令碼執行過程中，因程式錯誤或環境問題、指令碼自身問題經常會出現非預期的錯誤：如意料外的彈出視窗、發現錯誤的資料、未找到物件、輸入檔案打不開或不能 讀等，有些情況下當前用例出錯，並不影響後續用例的執行，需要支援異常處理機制，終止執行或者終止當前用例，繼續後續用例的執行，亦或者跳過當前步驟，繼 續執行後續操作，並輸出當前的錯誤報告。

 

      業務資料還原初始狀態

 　　自動化測試需要迴圈執行，執行完成後，需要恢復初始狀態（主要是業務資料），以使得程式重新提交版本後能夠迴圈執行，不斷的對新版本進行迴歸驗證。

　　 版本管理

　　隨著待驗證版本的不一致，自動化測試指令碼也會不斷的更新、維護，同樣需要進行版本管理。

　 結果體系

　   針以每條用例，輸出用例執行結果

   　針對每個檢查點，輸出詳細的檢查點執行結果

　　輸出執行日誌

　　結構化管理

　　物件、操作元件、基礎函式、測試資料、功能點指令碼、業務流程組合，如此多的層級、呼叫關係，必須進行結構化管理，採用高度組織化的目錄結構、分級管理，方便進行正確及快速的呼叫，方便能夠快速定位、查詢問題。

相關文章