接口測試自動化生成框架
接口測試這個詞語，相信大家都不陌生了吧。目前我個人的理解，接口測試應該屬于白盒測試的范疇，也是很多測試工程師很想從事和向往的一個測試手段。大家都覺得白盒測試深不可測，但實際上是怎么樣的呢。
接口測試的實施優先級
對于 Web 應用來說，接口測試就是對某一個接口進行測試代碼的編寫和執行。一般情況下，實施接口測試的優先級是：對暴露在外面的接口（該接口會給第三方調用）進行接 口測試；內部的核心功能接口也會做接口測試；內部非核心功能接口的接口測試（很多時候就是單元測試）。當然這個實施的具體細節，還需要根據項目的情景和人 員的能力來確定如何實施接口測試、在哪里做接口測試、為什么要做接口測試、做到什么程度等。
接口測試的實施條件
接下來說下，接口測試實施需要的一些條件。第一個就是測試人員的能力，代碼的熟悉能力、接口測試框架的使用能力、接口測試環境的搭建能力、接口 測試設計的能力、基礎代碼的編寫能力、基礎 Debug 能力等。第二個就是接口測試框架，框架是否定制化一些功能（比如自動加載 java bean、方便初始化數據、方便校驗數據庫數據等）。第三個就是測試團隊和測試流程的支持，測試團隊需要支持測試人員對核心接口進行接口測試（包括時間 上、精力上、技術上等支持）；測試流程上需要保證接口測試的效率和項目接入性（在項目當中實施接口測試，充分考慮開發團隊和功能測試團隊合作等）。
接口測試的實例
接下來會通過一個案例來說明接口測試的一些基本考慮點，這里不涉及到詳細的接口測試流程和注意點，只會把接口測試的一些想象展示給大家。
public interface IdleItemService { Resultpublish (ExtraItem extraItem); /* * * taobao.idlesell.item.update * 編輯閑置寶貝 */ Result update (ExtraItem extraItem); /* * * taobao.idlesell.item.get * 查詢閑置寶貝 */ Result query (Long itemId,Boolean hasDesc,Boolean hasPic,String appKey); }
上面的代碼是淘寶的提供出去的某個 Top 接口代碼，測試人員需要針對這個 Top 接口做最嚴格的接口測試，那他該怎么做呢，需要持續關注什么呢。
接口測試之前，需要充分的了解接口的實現功能的業務邏輯、接口參數、接口返回值。功能業務邏輯：外部可以通過該接口發布一個閑置二手的寶貝，具體細節不做說明。
接口參數: 一個寶貝的所有信息參數。見圖：
接口返回值：Result
接口的測試設計主要關注點
- 接口中所有的入參都要寫測試用例。
- 每個入參的每個錯誤類型都要準備一個異常用例。如必須參數缺省、參數類型錯誤、參數范圍錯誤、參數超過最大位數、參數沒有達到最小指定位數、參數 的無效值（有效狀態外）、參數的小數點超過規定長度、參數含有非法字、參數含有違禁字、參數的關聯性檢查（如所在省、市，所在地不匹配）等等。
- 對于正常系的用例，要把所有入參的各種合法的有效值都執行到。所有入參的最大位可以用一個測試用例執行掉。所有可缺省的參數不要（只輸入必須參數）的測試用例也要做一個。
- 對于搜索接口，應該把每個參數單獨作為搜索條件來確認搜索結果是否正確，然后再確認多條件輸入后的結果。
如下是部分參數的接口測試設計的截圖：
接口的測試代碼的編寫
大家應該發現了對于所有的參數，我們都需要校驗一下參數的基本特征，如前面講到的異常用例一樣。那么接口測試代碼又是什么樣的呢。
- step1: 編寫測試基類（加載資源、初始化環境）（可選）。
- step2: 編寫測試類。
- step3: 在該測試類中編寫測試方法。
- step4: 在測試方法中調用被測方法。
- step5: 驗證預期結果與返回的結果是否一致。
- step6: 執行測試查看測試結果。
那么針對所有的接口測試用例寫接口測試代碼，可以看到的是，我們的接口測試代碼主要是入參的不同，校驗結果的不同，其他區域的測試代碼都是一樣的。我們要做的是不斷的 copy 前一個測試用例代碼，然后修改某個參數、修改某個驗證點就搞定了。
接口測試自動化生成框架
對于這些比較重復的測試代碼編寫工作，大家肯定想到是否可以自動生成這些腳本，還會想到自動生成的腳本是否可以和測試數據一起自動運行測試代碼呢。這里可沒想象那么簡單，需要考慮業務邏輯、接口環境、測試數據、接口測試框架等一系列的組合。
我們來簡單點吧，我們的目的，在一定的測試范圍內，充分利用工具來自動化生成測試用例，保證測試用例的覆蓋率。 兩種程度的復用該測試套件，一種是測試用例的生成和復用，一種是測試代碼的生成和復用。 請看下面的自動化生成框架的架構圖：
模板引擎架構圖如下：
相關術語解釋：
- All Pairs：利用參數來定制化生成測試用例的攻擊，入口是 Excel 準備的參數文件；出口是 txt 文件的測試用例。這個工具是開源的，可以自己定制化開發，具體請見：http://www.infoq.com/cn/news/2011/08/combination-test
- 業務 API 庫：由于需要生成測試代碼，需要知道業務邏輯所涉及到的接口和類，比如 IC 中的發布寶貝的發布接口。
- 模板：根據業務邏輯規則制定的邏輯描述，可以利用因果圖分析法中的“或與非”來描述接口業務功能邏輯（需要抽象出相應的關鍵因子，也就是部分的接口入參）
- 測試用例分析器：將 txt 文件格式的測試用例進行分析，分析每個用例的參數和參數值和業務邏輯。
- 測試數據分析器：將 xml 文件格式的測試數據進行分析，與生成的每個測試用例代碼進行組合和處理，生成帶數據的測試代碼。
那么接下來我們需要做什么呢。迭代去開發我們需要的組件就行，第一步考慮自動生成接口測試框架代碼，定制化的選擇接口來自動生成框架代碼（包括 集成了現成的接口測試框架）；接下來考慮如何讓我們的用戶（測試人員）來輸入我們的測試數據，并考慮與框架代碼生成進行集成融合；另外一塊就是測試環境的 API 的調用了，如何能自動運行自動生成的測試代碼并反饋結果給測試人員等一系列的問題需要進一步深入挖掘。
這里還需要說明的是，我們不期望這個框架能解決所有接口功能接口測試代碼的自動生成（有些接口實現業務邏輯較復雜），我們能解決掉一部分重復工作（某個接口的 60% 的測試代碼），且能告訴大家我們可以做一些事情更智能化和簡單化。
關于作者
高翔(花名季哥) 淘寶軟件有限公司資深測試工程師，曾任職于華為南京研究所和群碩軟件有限公司。有著通訊、ERP、互聯網等多種行業的測試經驗，對需求分析、測試流程、測 試設計方法、風險分析有較深的理解，擅長于測試模型的建立、用例架構的設計、公共組件功能的抽象和應用、探索式測試流程和方法實踐。
來自: InfoQ