不知不覺在公司做介面測試已經接近一個月了。由於之前沒做過介面測試，所以上手時走了不少彎路，而且老實說現在還在走彎路中，所以只能說是感悟吧。
介面測試的目的
這個算是老生常談了，但我覺得只要聊到介面這個還是繞不過的，沒有目標就沒有評判標準，所以測試的目的還是很重要的。
先搬運一下維基百科上的英文解釋（中文沒找到，百度的就算了。。。）：
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個用例，甚至更多。而且很多時候不一定測得到業務（如介面只返回成功失敗，但有可能實際上失敗了但返回的是成功，需要呼叫其他介面驗證）
目前的理解（估計還是有點走偏）：
結合業務設計用例。如有翻頁引數，那就試試預設值、有效值、最後一頁、最後一頁+1、無效值。針對各個引數和業務場景去設計用例。
介面測試的實現
在這一點上我走了兩條路：Jmeter 和純 Java 程式碼。現在看來，兩條都不是好路，所以就不分享了。這裡主要說下 Testerhome 上最近出現的一些介面測試工具方面的帖子，簡單彙總一下他們的實現方式：
到目前為止的做過的介面測試的總結
怎麼說呢，我覺得我現在做的雖然也是介面測試，但我設計的用例更多的是具體功能。例如發表朋友圈，我會呼叫上傳介面（順帶檢查上傳的檔案 md5 對不對，順序對不對，相關屬性欄位對不對），髮圈子介面（基本就檢查返回值就夠了，但要有不同型別的文字，包括特殊符號、長度等），檢視圈子介面（圖片 md5、順序、相關屬性對不對、釋出人對不對、回覆和點贊方面的資料對不對）。因為是三個獨立的介面，所以每個介面都需要有一定的封裝方法（發資訊的、獲取返回值裡指定欄位的，等）。每個封裝方法平均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