基于數據驅動的酒店對賬自動化測試系統
隨著馬蜂窩酒店業務規模的不斷擴大，酒店平臺與各 OTA 的業務往來越來越頻繁。實際業務中，在向各 OTA 平臺結算金額前，我們需要通過對賬環節與自身系統訂單進行比對，確認雙方訂單金額、狀態等是否存在異常，并以此作為結算金額的計算依據。
為什么需要自動化測試?
大家都知道，賬務數據對精確性的要求非常高。之前酒店賬務數據一致性的測試，基本是依靠財務人員手工處理。
圖1：過去我們是這樣的
業務的增長使對賬系統的測試任務越來越多，傳統的測試方法導致的問題愈加明顯：
1)多源數據。賬務數據來自不同的 OTA 平臺，數據格式沒有統一標準和規范，影響數據處理效率。
2)大量數據的處理效率以及準確性。數據的測試結果由賬務人員手動對比 Excel 文件獲得，每月都需要處理海量的流水數據，處理慢、精度低，并且不可避免的有錯誤出現。
3)多輪回歸測試。測試時任務流程長且重復單調，人工在多輪測試后，非常容易疲憊厭倦，導致錯誤率上升，影響接下來的測試結果。
4)問題定位。使用手工測試，很難完整地記錄測試結果和測試報告，在測試過程中遇到的異常情況，很多情況下無法進行實時記錄，使得問題定位時花費較長時間。
基于酒店對賬任務的現狀和問題，我們決定決定采用以 Excel 表格作為數據源，使用 Java 語言來整合、篩選以及數據對比的方式，搭建一套酒店對賬自動化測試平臺，一方面可以有效地在短時間內處理大量數據;另一方面可以將財務人員從龐雜的手工對賬測試中解放出來，提高工作效率。
圖2：現在我們是這樣的
通過本文，希望和大家分享過去幾個月馬蜂窩酒店財務對賬項目的探索和實踐，并對對賬自動化測試平臺進行一個總結。
基于數據驅動的自動化測試系統
上文提到過，酒店的對賬數據來自于不同的 OTA，數據格式存在一定的差異。如何使用同一套代碼，來處理這些數據方面的差異，提高腳本的復用性呢?我們采用了基于數據驅動的測試方式。
1.如何理解數據驅動
如果測試數據和代碼結合在一起，每一次修改數據，兩者都要同時變化，這種測試的方式不適合酒店業務數據的處理。數據驅動的方式將測式數據參數化，通過給測試腳本類的構造函數傳遞參數，從而達到數據的改變驅動自動化測試的執行，最終使得測試結果的改變。
通過這種方式，可以使測試數據和測試代碼相分離，各自維護，只需要較少的代碼產生的大量測試用例，提高腳本的復用率和可維護性。
2.技術實現
結合上文我們可以明確，在數據驅動的自動化測試框架中，一是必須要有與電子表格、文本文件、數據庫等集成的能力;二是必須有數據來控制測試的業務流。整套框架我們采用的是 Maven + TestNG + Java +POI 來實現。
-- Maven 是一個通過配置文件來管理項目的構建工具，應用在自動化測試中時，無論是對 Jar 包的管理還是執行測試案例，表現都很出色。
-- TestNG 是一套可以利用注釋來控制測試流程，從而達到強化測試功能的測試框架。它加入了單元測試、注解、組概念、套件、異常、參數化、依賴等測試思想，使其可以很好地支持和管理自動化測試任務。
-- Apache POI 是一種流行的 API , 它允許程序員創建、修改和顯示 MS Office 文件。它是由 Apache 軟件基金會開發和發布的一個開源庫，用于使用 Java 程序設計或修改 MS-Office 文件。 它包含將用戶輸入數據或文件到 MS Office 文檔進行解碼的類和方法(詳見官網：http://poi.apache.org/)。
通過使用 Apache POI 來解析 Excel 文檔，結合 Java 語言對文檔內容進一步處理，可以達到自動化的測試效果。
具體到一個測試用例的執行過程為：
圖3：測試用例執行過程
自動化測試框架大致結構圖：
圖4：自動化測試框架結構圖
各模塊功能：
- DataProvider：通過構造函數向測試腳本傳遞測試數據，從而達到數據驅動的目的;
- TestScript：封裝測試腳本;
- commonFunction 將一些常用的方法抽離出來放到該模塊中;
- Data：將一些共享的常用的數據抽離出來放到該模塊;
- Report：測試結果模塊;
- 執行入口： xml 文件，可以用來配置測試的范圍。
整個框架的工作流程大致可以描述為：
- Testng.xml 作為測試入口;
- DataProvider 通過測試數據驅動測試腳本的執行;
- 測試腳本中通過 POI 讀取測試數據，Java 分析測試數據，然后輸出Report(在 Testscipt 中需要用到 Data 模塊和 CommonFunc 模塊。)
3.框架優化
一個好的測試框架的目標是能夠減少代碼量，大大提高測試腳本開發的效率。但它不是一蹴而就的，而是隨著項目的不斷的深入進行持續地改進。從上線投入使用開始，我們的框架也在不斷優化，主要和大家分享以下幾點經驗：
1)Data 模塊。在測試過程中發現一些測試數據會經常被使用到，而且經常需要改變，每次改動需要改動好多文件。我們對就對這部分數據進行了收取，放到 Data 模塊中。
2)commonFunction 模塊。在對 Excel 讀寫時，通過對不同的單元格數據類型的判斷，進行不同的處理，來使單元格操作的健壯性增強。
3)對于 Excel 文件的讀寫需要多個循環，為了提高性能，應該事先對數據進行預處理，避免多個循環的嵌套。
近期規劃及演進方向
現在測試數據的數據源是通過 Excel 文件來獲取的，需要人為手工的進行數據的整合，對于持續化集成是一個阻礙。通過給接口傳參來獲取數據的方式，是一個比較理想的構想。通過接口獲取數據的方式，可以通過 Jenkins 實現持續集成，測試人員可以給財務人員提供可視化的參數輸入入口，實現財務人員觸發測試腳本進行測試。這樣做可以釋放測試資源，提高回歸頻率，減少財務風險。
本文作者：高攀，馬蜂窩酒店研發團隊高級測試工程師。主要負責酒店自動化體系的搭建和優化，以及財務訂單業務線整體測試工作。
【本文是51CTO專欄作者馬蜂窩技術的原創文章，作者微信公眾號馬蜂窩技術(ID：mfwtech)】
