文/張魯珊

科技發(fā)展迅速，互聯(lián)網(wǎng)行業(yè)不斷壯大，隨之軟件產(chǎn)品層出不窮，如何保證產(chǎn)品質(zhì)量，成為非常重要的事情，以O(shè)TA 升級云平臺為例，軟件功能很復雜，測試工作量龐大，除了使用手工測試來驗證功能以外，需要通過對大量的接口模擬數(shù)據(jù)驗證，覆蓋需求涵蓋的所有可能的結(jié)果，保證其穩(wěn)定性。開源測試工具在一定層面上不足以滿足我們的測試需求，為方便管理測試用例及數(shù)據(jù)，我們定義了一套接口自動化測試框架。在人力不足及接口工作量較大的情況下，引入此框架，實現(xiàn)對接口測試用例及數(shù)據(jù)以及腳本的管理，更好的完成接口測試工作。

1 接口自動化測試框架設(shè)計

1.1 環(huán)境說明

環(huán)境搭建采用如表1所示工具。

1.2 框架說明

根據(jù)框架示意圖，按照框架層級，逐一做如下闡述：

1.2.1 配置層

配置層主要包括對配置文件信息的初始化設(shè)定，包括如下3 方面的配置：

（1）pom.xml 的配置，用于管理maven依賴包，以及同步代碼至git 上時的maven 打包配置等。

（2）testng 對應xml 的配置，用于定義需要執(zhí)行的項目對應的測試類及測試方法。

（3）config 配置，包括對于一些環(huán)境信息、接口初始默認參數(shù)、數(shù)據(jù) 庫配置信息的維護。

1.2.2 接口層

主要實現(xiàn)對底層代碼的封裝，包括驅(qū)動讀取數(shù)據(jù)方法的實現(xiàn)，基于http 協(xié)議接口請求方法的實現(xiàn)，配置文件的讀取，結(jié)果斷言處理，對數(shù)據(jù)庫的讀寫操作，測試報告的生成，以及接口測試腳本的維護。

1.2.3 測試用例層

測試用例及數(shù)據(jù)維護在Data ProvidersExcel 中，啟動執(zhí)行代碼后，會通過testng 的數(shù)據(jù)驅(qū)動類，逐條讀取Excel 中每條用例對應的測試數(shù)據(jù)，通過調(diào)用http 接口發(fā)送數(shù)據(jù)并獲取返回結(jié)果。

表1

1.2.4 持久層

主要包括3 個方面的數(shù)據(jù)存儲：

（1）DBUtil 管理數(shù)據(jù)庫的連接和操作，保持數(shù)據(jù)與數(shù)據(jù)庫內(nèi)容同步。

（2）Redis 作為數(shù)據(jù)庫，在使用過程中，實現(xiàn)數(shù)據(jù)快速存儲且持久化。

（3）每次執(zhí)行完測試任務后，會生成測試報告存儲在target 目錄下記錄接口測試的執(zhí)行情況，分為2 個報告形式，1 個為自定義的用例報告為Excel 的形式，1 個為reportNG 框架定義的html 格式報告。

2 接口自動化測試實現(xiàn)

2.1 測試準備

按照接口文檔定義的每個接口上送的測試數(shù)據(jù)，json 格式或xml 格式配置在excel 文檔中，并編寫對應的接口測試腳本，為測試執(zhí)行做準備。

2.2 配置管理

實現(xiàn)過程中，為了讓一份配置可以在不同代碼中被使用，故進行配置數(shù)據(jù)與代碼分離，被測接口在初始化時，通過讀取配置文件中配置的請求url，相關(guān)的既定參數(shù)，載入各項配置信息。

2.3 測試腳本編寫

按照實際項目的接口文檔，建立與之對應的類與方法，并對每個接口進行拼接上送字段的特殊邏輯處理，以及獲取接口返回，對返回數(shù)據(jù)處理，并調(diào)試通過。

2.4 測試執(zhí)行

通過在testng 對應可執(zhí)行的xml 中配置需要執(zhí)行的測試類和方法，運行xml 文件，驅(qū)動讀取測試方法對應的測試用例數(shù)據(jù)，拼接成request 請求，模擬客戶端發(fā)送請求，服務器接收到客戶端的請求后，將結(jié)果按照一定格式返回，并對比返回結(jié)果與用例預期結(jié)果，一致則為執(zhí)行成功，否則為失敗，最終將所有用例的測試結(jié)果記錄在Excel 表格中，結(jié)合reportNG生成html 測試報告，顯示統(tǒng)計結(jié)果：總用例數(shù)，通過數(shù)，失敗數(shù)，測試通過率和失敗率等。

2.5 jenkins集成

通過jenkins 集成項目，配置好定時任務和郵件，就會在指定時間調(diào)用接口自動化測試任務并執(zhí)行測試用例，最終將測試報告發(fā)給特定的收件人。

3 接口自動化測試框架應用

鑒于前期對接口測試的考量，根據(jù)項目需要，來搭建的接口自動化測試框架，那值得思考的是，到底在一個項目中，什么時候引入接口測試？前提條件是什么？如何設(shè)定接口測試范圍？

根據(jù)實際項目經(jīng)驗得出，引入接口測試的前提是：接口規(guī)范文檔的落實，引入接口測試的時機：即文檔確立后。測試范圍：從功能測試用例中剝離涉及接口部分的用例，結(jié)合接口文檔，進行分析并設(shè)計測試用例。在完成用例中，篩選部分用例，作為后續(xù)開發(fā)每次發(fā)版或改動后的執(zhí)行用例。

用例完成之后，可以導入測試框架，并配置測試數(shù)據(jù)，在測試腳本文件中建立項目對應的接口測試類和方法，完成腳本的編寫，配置相關(guān)請求url 及初始數(shù)據(jù)，一切準備工作就緒后，通過對特定啟動文件的執(zhí)行，即可完成所有設(shè)定接口的執(zhí)行工作，最終輸出測試報告。

4 結(jié)論

在實際項目中，軟件迭代頻繁，回歸測試周期短，測試人員精力有限，很難做到在每個迭代周期，對所有功能進行回歸驗證。接口自動化因其實現(xiàn)簡單，成本低，測試點覆蓋率高，很受重視。

開源測試工具存在局限性，并不能很好的應對每個項目的測試工作，因此我們基于TESTNG 框架，編寫了一套接口自動化測試框架，框架功能比較完善，結(jié)構(gòu)簡單清晰，并且將測試數(shù)據(jù)與代碼分離，配置文件數(shù)據(jù)單獨管理，足以應對各種情況的接口自動化測試，只要前期維護好代碼和數(shù)據(jù)，后續(xù)會很簡單，代碼變動量小，只需要對每次的測試數(shù)據(jù)進行變更。未來還會更深入的研究將測試框架變?yōu)榭梢暬臏y試工具，達到讓不懂代碼的測試人員，也能很好的利用工具實現(xiàn)接口自動化測試。