我是如何一步一步作接口測試的一些感悟

不知不覺在公司作接口測試已經接近一個月了。因爲以前沒作過接口測試，因此上手時走了很多彎路，並且老實說如今還在走彎路中，因此只能說是感悟吧。

接口測試的目的

這個算是老生常談了，但我以爲只要聊到接口這個仍是繞不過的，沒有目標就沒有評判標準，因此測試的目的仍是很重要的。

先搬運一下維基百科上的英文解釋（中文沒找到，百度的就算了。。。）：

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality， reliability， performance， and security.[1] Since APIs lack a GUI， API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).[3][4]

翻譯過來就是：

API 測試是一種做爲集成測試的一部分，經過直接控制被測應用的接口（API）來肯定是否在功能、可靠性、性能和安全方面達到預期的軟件測試活動。[1]因爲 API 都沒有 GUI 界面，API 測試都是在通信層進行的。[2]如今 API 測試在自動化測試中有着很重要的地位，由於 API 通常是應用邏輯的主要接口，同時 GUI 測試在敏捷開發和 DevOps 的快速迭代和頻繁變動中很難維護。[3][4]

[1]:Testing APIs protects applications and reputations， by Amy Reichert， SearchSoftwareQuality March 2015

[2]:All About API Testing: An Interview with Jonathan Cooper， by Cameron Philipp-Edmonds， Stickyminds August 19， 2014

[3]:The Forrester Wave? Evaluation Of Functional Test Automation (FTA) Is Out And It's All About Going Beyond GUI Testing， by Diego Lo Giudice， Forrester April 23， 2015

[4]:Produce Better Software by Using a Layered Testing Strategy， by Sean Kenefick， Gartner January 7， 2014

而後我目前在工做中 Leader 對個人預期：

發現儘量多的問題。先說下背景，他是 app 端的主程，他對我作接口測試的期待是儘早發現接口的問題，減小他們 app 和服務端聯調是發現的問題。他舉了個例子，例如服務器返回一個 {"width":30， "url":"http://xxx/a.jpg"} ，那麼有可能存在這個圖片的實際寬度和 width 字段不一致。

和大東等曾經作過 API 測試的人的交流：

覆蓋業務，包括業務正常/異常的狀況

我一開始的理解：

發現問題，恩。那就是把文檔裏說的必須字段缺了試試，只有必須字段試試，必須字段用非法值試試。可選字段缺了試試，可選字段非法值試試。

結果就是：一個接口至少6個用例，甚至更多。並且不少時候不必定測獲得業務（如接口只返回成功失敗，但有可能實際上失敗了但返回的是成功，須要調用其餘接口驗證）

目前的理解（估計仍是有點走偏）：

結合業務設計用例。若有翻頁參數，那就試試默認值、有效值、最後一頁、最後一頁+一、無效值。針對各個參數和業務場景去設計用例。

接口測試的實現

在這一點上我走了兩條路：Jmeter 和純 Java 代碼。如今看來，兩條都不是好路，因此就不分享了。這裏主要說下 Testerhome 上最近出現的一些接口測試工具方面的帖子，簡單彙總一下他們的實現方式：

到目前爲止的作過的接口測試的總結

怎麼說呢，我以爲我如今作的雖然也是接口測試，但我設計的用例更多的是具體功能。例如發表朋友圈，我會調用上傳接口（順帶檢查上傳的文件 md5 對不對，順序對不對，相關屬性字段對不對），髮圈子接口（基本就檢查返回值就夠了，但要有不一樣類型的文字，包括特殊符號、長度等），查看圈子接口（圖片 md五、順序、相關屬性對不對、發佈人對不對、回覆和點贊方面的數據對不對）。由於是三個獨立的接口，因此每一個接口都須要有必定的封裝方法（發信息的、獲取返回值裏指定字段的，等）。每一個封裝方法平均10行代碼左右，一個用例用3個接口基本就須要 3x10+10（一些說明和很差封裝的部分）行代碼。一個功能大概要覆蓋10個用例，因此就須要10x40行代碼，就是400行代碼。除去一些能夠共用的代碼，基本須要300行代碼左右（某些複雜功能會更多）。

PS：經過 git 統計了一下我天天的代碼量，大概在1000左右，但用例數仍是天天15個左右。

能夠看出，個人速度主要是慢在了代碼量太大，時間都用在打代碼上了，並且代碼調試起來又會花必定的時間，因此效率天然低。因此若是優化寫用例的方式，就算吐血也寫不快了。接下來得總結一下那些地方能夠抽取出來，用錄製或者自動生成的方法來完成，把寫用例精簡成填表格或者純填數據。

Updated 2015.11.30

今天和 Monkey 以及公司另外一位有作過 api 測試的同事交流了一下，發現了一個最根本的問題： 個人用例設計有問題

這個講概念比較難說清楚，仍是以上面提到的發表朋友圈做爲例子。

假設我要驗證發表朋友圈的 接口，它的工做流程以下：

上傳圖片，服務器返回這些圖片的 url

發表朋友圈，包含朋友圈文字內容和各個圖片 url 兩個主要字段。服務器只會返回是否成功以及這條朋友圈的 id

我設計的正常發朋友圈的用例以下：

用上傳圖片接口上傳圖片，驗證圖片是否上傳成功，各 url 對應文件的 md5 是否和我本地上傳的圖片的 md5 吻合。

用發本地圈接口發本地圈，其中圖片 url 來自第一步的返回值

用查看本地圈接口查看發出的本地圈，檢查它的內容、圖片是否正確。

咋看之下好像沒啥問題（相信作過 api 測試的童鞋已經看出問題了），但其實這個用例自己存在一個嚴重的問題： 接口成爲了手段，驗證點實際上是功能。

我交流後獲得的 api 測試用例主要應該有兩類：

單一接口測試。調用一個接口就是一個用例

多接口的業務測試。會調用多個接口，且接口之間可能存在數據傳遞。

api 測試最簡單，而且每一個接口都應該至少有一個的用例應該就是使用 默認參數調用 單個接口。重點在這裏：單個。像我上面這樣的用例已經不是驗證發朋友圈的接口了，而是驗證 發朋友圈的功能。

那麼發朋友圈的接口應該有什麼用例呢？我按照如今的測試接口的思路從新想了一下，主要有這幾個：

有圖片、有文字，預期返回發佈成功

無圖片，有文字，預期返回發佈成功

有圖片，無文字，預期返回發佈成功

無圖片，無文字，預期返回發佈失敗

有圖片、有文子，預期返回發佈成功，同時數據庫中的記錄符合預期

每個用例測試一個點，發佈成功這個返回值是否正確由一個單獨的用例來覆蓋就足夠了。

用例肯定了，那麼能夠看出接口測試其實有不少能夠重用的點。接口測試的本質是經過測試參數的排列組合驗證返回值/數據庫變動是否符合預期，從而肯定接口相關代碼是否正確。從業務角度考慮的意思是這些排列組合不是隨便想出來，而是業務中有可能出現的排列組合。

這也是爲何很多接口測試用例採用 excel 表格來編寫，由於參數的排列組合用表格呈現是最簡單快捷的。

還有一個例子說明用例越簡練越好。

例如列表接口有個翻頁的功能。它有一個入參：lastTopicId ，返回值裏有一個 isMore 的字段。lastTopicId 表示從哪一個 topic 開始顯示， isMore 表示是否存在下一頁（1爲有，0爲無）。

針對這個接口的其中一個用例，須要驗證 isMore 字段在最後一頁時是否爲0。我一開始的思路是像功能那樣，不斷翻頁，直到達到一個很大的頁數或者到達 isMore 爲 0 的狀況。因爲頁數不肯定，所以就算這個很大的頁數設得很是大也沒有十足的把握絕對不會超出這個頁數。因此思路自己有問題。

和 Monkey 和個人同事交流後，他指出正確的思路應該是：

經過一個可信的途徑（從服務器數據庫直接計算，或者有一個端口告訴你最有一頁的 lastTopicId 是什麼），用一個步驟知道怎麼一次性去到最後一頁。

直接去到最後一頁

驗證 isMore 參數值

有些東西開發能夠很方便地給到咱們，那麼咱們沒有必要那麼艱難地本身去計算出來，而是直接讓開發增長一個接口讓咱們能直接獲取到數據就好。讓接口測試作得更好，開發的協助是分不開的。

作好接口測試並不像以前想象得那麼簡單，但也沒有剛開始的時候作得那麼艱難。無論怎樣，既然開始了，那就要想辦法把它作好。接下來我會使用新的設計用例思路作剩下的接口測試用例，並修改 Java 代碼讓其支持使用 excel 做爲用例。感悟中若是有不對的地方，歡迎你們及時提出。

更多關於接口測試方面的能夠加QQ羣：747981058