接口自動化測試設計

1.接口測試基礎

1.1.什麼是接口測試？

•     接口測試是測試系統組件間接口的一種測試。
•     接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。
•     接口測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
•    從接口形式來看各類應用程序的API(最著名的Windows系統API)，硬件的驅動程序，數據庫DAO層接口，及WebService 接口和Http Rest接口。
•    接口測試一般包括兩類，底層模塊之間的接口測試和上層服務接口測試。前者一般由開發工程師作單測覆蓋，後者則一般由測試工程師測試保證。

1.2.接口測試原理？

    經過測試程序或工具模擬客戶端向服務器發送請求報文，服務器接收請求報文後作出處理，而後將應答報文返回給客戶端，即客戶端發送應答報文的過程（Request -> Response）

 

1.3.接口測試分類？

•     系統與系統之間的調用：銀行會提供接口供電子商務網站調用，或者說支付寶會提供接口給百度外賣調用。
•     上層對下層服務的調用：如Service層會調用DAO層的接口，而應用層又會調用服務層提供的接口。
•     系統內的服務之間的調用：如註冊用戶時，先調用用戶查詢的服務，查看該用戶是否已經註冊

1.4.爲何接口測試？

    測試金字塔概念由Mike Cohn提出，在《Succeeding with Agile》中作詳細論述。核心觀點：底層的單元測試應多於UI層的端到端測試。

    1).UI：一般指 Web、App的測試；2).Service：通常針對接口、服務，如 HTTP、WebService 接口測試；3).Unit：包含比較多，如：Web應用的dao、service、model，controller的junit單元測 試，javascript、css的前端單元測試，大部分應由開發作測試保證。

    參考金字塔層次劃分，不能層次的測試投入量是不一樣的，越上層比重應越小，以儘可能低的測試成本防護不一樣類型的風險。金字塔分層測試的ROI則是倒金字塔，即 Unit > Service > UI。Service測試層於QA而言是重要一環，也是性價比相對較高的。總之，分層自動化測試是追求覆蓋的傳統自動化測試的一種修正，充分利用自動化測 試的優勢，規避自動化測試的缺點。

 

1.4.接口測試範圍？

    新增及改動接口的測試（接口的改動點，可經過代碼及配置 diff 測試，圈定最小測試範圍。服務端接口迭代過程，需測試接口依次增多。測試時間足夠條件下，固然須要進行全迴歸測試。但時間較短，應考慮接口的重要性與優先級，優先對核心且調用頻繁的接口測試。）新增及改動業務功能測試。接口的性能與安全測試（是否須要對接口實施性能和安全測試，取決於接口特色。一個對第三方電商平臺提供支付功能的接口，如：支付寶接口，性能和安全測試是 必需要例行化測試的。一個系統內部調用的獲取列表頁接口，性能和安全性考慮優先級相對不那麼高。總體而言，從接口的業務特色，即流量大小、調用方式、服務 架構、業務閉環的重要性等角度考慮。）

 

2.接口測試策略

    檢查： 接口設計檢查，經過接口文檔定義對接口交互數據作有效性檢查，整數型數據位數、浮點型數據精度、字符串數據範圍值等，要求客戶端傳入的整數型、浮點型、字 符串型數據及最大值和最小值都能做爲服務端接口有效輸入，確保服務端不會自動進行截斷或四捨五入操做。(接口設計評審階段便可進行)

               接口依賴關係檢查，一般用戶的一個操做可能對應服務端調用多個接口完成，從業務操做角度來看，各類業務操做所涉及的多個接口之間調用進行測試。依賴關係檢 查，主要經過接口的輸出值爲另外一接口的輸入值來實現的，所以在進行接口測試以前，須要分析所測試接口的輸入值是經過客戶端仍是其餘接口輸出來獲取的，在設 計測試用例時，加入接口的依賴關係說明以便於測試。

    驗證：接口輸入/輸出驗證，服務端接口功能測試相似於單元測試，在設計測試用例時，側重點在於接口模塊輸入/輸出項的正確性驗證，根據接服務端接口處理方式分類有多種：條件判斷接口、數據查詢接口、邏輯運算接口。

    構造：接口測試過程，經常須要構造測試數據。一般是數據庫插入，mock 接口，調用依賴接口，開發腳本工具批量等。

    自動化：相對於UI層自動化測試，服務端接口的自動化測試更容易實施，較穩定且維護成本低。參考接口case的優先級作自動化覆蓋，迴歸測試、線上監控等收益均較大。

2.1.接口測試關注點？

•     入參數據：每一個接口入參的默認值、異常類型、非空交易。 參數是否有默認值，若沒有，接口邏輯是如何處理的；參數必須輸入值，若不輸入或輸入錯誤，接口如何返回；接口報錯，服務端和客戶端是否都作了容錯處理。
•     出參返回：接口返回數據是否正確。
•     頁碼頁數的異常值：接口有翻頁時，如：第一頁有數據，翻到第二頁。第二頁的數據是否與第一頁重複，第二頁接口是否報錯，頁碼、頁數，傳很大的值，接口是否報錯。
•     數據庫增刪改查，如對某接口post請求後，對列表頁接口刷新請求，新數據是否與post數據一致。典型case，發佈評論，post請求後是否返回評論數據，若無則檢查是否緩存未寫入數據庫致使。
•     參數個數：入參支持多個值時，考慮傳值個數多的狀況，接口是否報錯，接口應返回友好提示。
•     參數類型：輸入參數類型必須校驗，輸出參數必須正確。便是int類型的，不能返回string類型。
•     排序：列表頁接口應考慮排序值，升降序、時間排序等是否正確。
•     版本兼容：接口的改動（增長、減小字段）須要兼容老版本。
•     參數聯動性：校驗返回的多個參數的實際結果是否符合需求，如：返回一個商戶的列表，總數字段和列表數據是否一致。
•     業務：從業務中來，到業務中去。接口測試是對業務邏輯的測試覆蓋，對業務架構的理解。

2.2.接口測試Case設計？

Case參考點：輸入參數測試，功能測試，邏輯測試，異常狀況。

設計思路：a)優先級-針對全部接口，外部接口 > 系統內部核心接口 > 系統內部非核心接口。

                 b)優先級-針對單接口， 正向用例 > 逆向用例（一般狀況，非絕對)；前置條件 > 默認參數 > 參數必填 > 參數關聯 > 參數類型限制 > 參數數據範圍限制。

Case覆蓋：主流程 -> 分支流程 -> 異常流程。

 

3.接口自動化演進

    接口自動化演進，一般是從手動測試 -> 工具測試 -> 代碼測試 -> 平臺服務化演進。

    手動：從客戶端的業務場景測試去覆蓋服務層接口，藉助Fillder、Charles、FireBug等工具抓包分析。優勢：簡單，模擬真實業務場景；缺點：接口邏輯覆蓋不夠，異常和輸入校驗不足，重複繁瑣，迴歸成本高。

    工具：使用PostMan，HttpRequest，Jmeter, SoapUI 等工具作接口測試。優勢：容易保證接口邏輯覆蓋，便於異常和輸入校驗，提升迴歸效率；缺點：缺少自定義靈活性，接口依賴處理繁瑣，不便自動化工程化。

    代碼： 選擇如，Java + Httpclient，Python + Requests, PHP + Requests/cURL/HTTPFul，搭建接口自動化框架，開發接口自動化case。優勢：靈活性好，擴展性強，邏輯覆蓋容易，異常和輸入校驗充 分，迴歸效率高；缺點：存在必定學習成本，框架及case腳本需持續維護。

    平臺：通用的接口自動化測試平臺，簡而言之知足接口自動化測試的Web平臺，如：Numen。優勢：通用性強，上手快，一鍵式，配套服務全等；缺點：業務契合度，靈活性，維護成本，API擴展等。

3.1.接口測試工具？

    代理抓包工具
        Fillder, http://www.telerik.com/fiddler
        Charles, https://www.charlesproxy.com/
        Wireshark, https://www.wireshark.org/
    
    調試工具
        Firebug(Firefox), https://addons.mozilla.org/en-US/firefox/addon/firebug/
        DevTools(Chrome), https://github.com/CN-Chrome-DevTools/CN-Chrome-DevTools
    
    Json&Url encode工具
        json在線解析,格式驗證, http://json.cn/
        json壓縮轉義, http://www.sojson.com/yasuo.html
        jsonview插件(Chrome), https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=zh-cn
       url encode工具, http://tool.chinaz.com/Tools/URLEncode.aspx

    測試工具
        PostMan, https://chrome.google.com/webstore/detail/postman/
        SoapUI, https://www.soapui.org/
        Jmeter, http://jmeter.apache.org/

3.2.接口自動化框架設計？

接口自動化測試框架設計關鍵點，其實能夠用Driven、Organize、Support、CI歸納。

Driven：Data Driven(數據驅動)，接口測試關注輸入、輸出及各類異常數據，歸根結底其實就是作數據測試。如何設計合理的參數化實現，下降測試數據維護成本，是自 動化框架設計的重要內容。KeyWord Driven(關鍵字驅動，即封裝)，將測試過程當中公共過程、通用步驟儘可能封裝爲通用函數，其中分別爲業務、過程common 函數。合理的封裝函數設計，將使得自動化腳本簡潔化、一致性，可維護性高。

Organize：組織。考慮兩個維度，如何管理組織自動化工程？如何組織自動化case？以Java語言舉例，接口自動化case較少只有幾個，建立一個普通java工程項目，在 main方法中，羅列寫出case實現便可。無可厚非，這是一種簡單實現。但隨着接口數量增長，接口case愈來愈多，這種方式的維護成本愈來愈高，冗餘愈來愈重。咱們須要考慮將自動化工程化而不是腳本化，即作工程管理，如使用maven管理工程，配置各種jar包依賴，定義測試等。測試case使用單測 工具管理組織，如：junit/TestNG，有什麼好處？定義了case的執行順序，通用豐富的assert驗證，結果統計收集等。

Support：接口自動化測試不僅是模擬一個請求發送及響應解析的過程，作爲框架需考慮的遠不僅這些。如：json數據的比對，數據庫增刪改查操做，接口的數據mock構造，md5值校驗，url的unicode/encode，report，email等等。

CI：自動化框架搭建了，自動化case工程化了。選擇什麼方式調度，何時執行。IDE 手動調度執行，bat/sh？CI 是一種高效的機制，每次代碼編譯打包部署，都應該觸發CI的自動化執行，自動化框架須要考慮CI的集成。

 

4.外面團隊，如何作接口自動化？

測試工具：PostMan, SoapUI，Jmeter……

自動化框架

    Java：java + httpclient + junit/testng + ant/maven + Jenkins

               java + jmeter.jar + + junit/testng + ant/maven + Jenkins

    Python：python + (robotFrameWork) + (requests) + (xlrd) + pyUnit + Jenkins

    Ruby：ruby + (cucumber/rspec) + (http/net) + TestUnit + Jenkins

    PHP：php + requests + phpUnit + Jenkins

    NodeJS：node.js + mocha +supertest + Jenkins