全網最詳細的接口測試實戰案例

一、接口測試的誤區

前段時間，有個朋友跳槽去了一家公司做服務端的測試開發工程師，月薪漲了50%

我第一時間向他送去了誠摯的祝福，同時詢問了他去到新公司的工作情況。

他和我說，他目前主要負責一個電商平臺的接口測試工作以及開始著手去搭建一個接口自動化測試平臺。

因為該同事以前是做移動端的測試的，從來沒有聽說過，他有做接口測試的經驗。于是我出于好奇，就問了一下：他目前是如何去進行接口測試的。

他對這個問題可能沒有做出充足的準備，也有可能他因為之前沒有接口測試的相關經驗，他給到我的回答，其實和網上隨便搜出來的答案差不多：

通過 Postman / Jmeter / 代碼調用 等測試工具，來模擬網絡請求，

1. 校驗接口傳參是否合理（少傳 / 漏傳 / 多傳 / 邊界值 / 參數類型校驗等等）。

2. 測試響應結果是否會返回約定的數據格式，有沒有字段沒有下發或下發不正確。

3. 驗證接口是否有安全性問題，是否鑒權。

利用 Postman 進行接口測試

對于這個回答，我并不感到意外，網上大多數的回復也都是這么說的。

但是對于一個純服務端的測試而言，僅僅是調調參數，真的就能完成接口測試了么？

NO，這只是接口測試的冰山一角，接口測試遠沒有你想象中的那么簡單！

那么，接口測試主要需要測試哪些方面呢？

按照慣例，先上老（nao）圖：

接下來，臻叔將用一次深度的接口測試實戰，來分享一下，臻叔是如何去做接口測試的。

二、接口測試的實戰步驟

接下來我們以電商平臺的搜索接口來做案例，一步步給大家講解接口測試的步驟。

第一步：梳理上下游調用鏈

1）為什么要梳理上下游調用鏈？

目前互聯網產品的后端服務，基本上都是分布式部署的，一個接口可能會調用其他接口，也有可能被其他接口調用，接口與接口之間，具有千絲萬縷的依賴關系。

如果我們的把自己負責的接口純粹地當成黑盒去測試，不可謂知己；

如果我們只熟悉自己的接口，不清楚與其他接口的依賴關系，不可謂知彼；

所謂知己知彼，方能百戰不殆。

所以，梳理上下游調用鏈是首先要做的工作。

我們在測試的時候，很可能只會片面的去關注搜索網關開放給前端調用的接口，

但只要把整個調用鏈路和流程圖畫出來，我們會發現其實搜索網關依賴好多的服務。

比如：

搜索網關需要調用價簽系統，去獲取商品促銷價格；

搜索網關需要調用推薦系統，去獲取搜索場景下的推薦的商品；

搜索網關需要去調用商品系統，去獲取實時的商品信息；

搜索網關需要去調用搜索服務，去ES召回商品、獲取搜索排序信息等等。

前端在搜索框搜索一個關鍵詞，對搜索網關發起一個HTTP請求，背后其實經過了很多道工序去處理這個請求。

如果只是單獨的調調參數，就希望把接口測試做好，顯然是不可能的。（開發自己都能調（tiao）接口參數，還要測試做什么？）

接口背后的業務邏輯是否正確處理、后端依賴的服務是否健壯、接口性能是否達標。

2）怎么梳理上下游調用鏈？

1、看項目wiki、產品文檔和開發文檔。

2、看開發寫的代碼，閱讀代碼，當然是首選：JetBrains全家桶啦（Java用IDEA；Python用Pycharm）

3、梳理出上下游調用關系后，手繪一份系統流程圖，如果還有不明確的地方，可以找PM、開發溝通確認。

 

第二步：編寫接口測試用例

接口測試用例和平常的測試用例差不多，沒有太多的要求限制。因為測試工作中很多時候不是專門測接口的，所以這個步驟不一定要做。

但是你心里要清楚你要測的點，如果你是第一次做接口測試，臻叔還是建議自己去寫一份接口測試用例，并且好好歸檔。

如果說要做接口自動化，接口測試用例也是很有幫助的。

這里給出一個接口測試用例的案例：

 

第三步：測試接口文檔&調試接口

接口文檔在軟件項目開發過程中非常重要，接口文檔是連接前端開發和后端開發的一座橋梁。

在項目開發之初，前端開發和后端開發會共同去約定一套接口規范，然后由后端開發去編寫接口文檔，然后前后端就可以按照約定去進行協同開發。

接口文檔的管理和編輯有多種方式：

有的團隊習慣用wiki或者在線文檔去編寫接口文檔；

有的團隊喜歡用專業的接口文檔工具，比如：Swagger、Yapi等去生成接口文檔。

我們公司習慣于用絲襪哥（swagger）去維護接口文檔。

swagger 對多種編程語言/框架 都提供了良好的接入方案。就拿Java來說，只需要引入相應的jar包，在接口上添加相應的api文檔注解，就可以自動生成網頁版的接口文檔。

并且還可以通過接口文檔去對接口進行調試，大大提高了開發效率。

但不管是以何種方式去管理和維護接口文檔，接口文檔都是必須要有的。

測試接口文檔可以參考以下測試點：

確保開發必須提供接口文檔。如果開發沒有寫接口文檔的習慣，應push開發去寫接口文檔。

檢查接口文檔的格式內容等是否完備，包括：URL、請求方法、Header、入參、返回值、示例Demo等。

檢查接口設計是否符合公司規范。包括接口命名、接口格式、字段命名、字段類型、響應狀態碼、接口容錯、字段是否冗余、接口是否鑒權、是否做版本區分等等。

當后端開發完成接口的開發工作時，我們就可以提前開始對接口進行初步測試了。

步驟如下：

把后端代碼部署到測試環境上。

通過postman或swagger去對接口文檔提到的接口進行測試。

第四步：前端接口測試&Mock數據（接口層面的測試）

前面的步驟只是利用測試工具去發起網絡請求，來模擬接口調用。

但在真實的場景下，搜索網關的接口實際上是提供給 APP/WEB/小程序 進行調用的。

我們同樣也需要關注前端調用過程是否是正常的。（需要等待前端開發完畢，才能介入測試）

可以利用Charles來對前端發送的請求進行抓包，

驗證前端調用接口的傳參是否正確；

驗證后端的接口響應是否符合預期；

前端拿到數據之后，交互和UI展示是否正確。

當有些數據有多種狀態，并且數據比較難以構造時，我們可以通過Mock數據去進行測試。

常見的Mock數據的方式有：

用 Fiddler 或者 Charles 去篡改請求和響應。

如果是PHP或者Python等動態語言，可以直接在后端代碼里面去更改條件。

數據庫中去修改數據。

用專業的Mock工具去構造數據，如：EasyMock、TestableMock、Mockjs等。

比較快速的方式，當然是直接用Charles去模擬。

如果說只是改少量的響應數據，比如說：改變一個標簽下發的文案，看看前端的展示。這種情形就非常適合用 Charles 去模擬數據。

但是 Charles 模擬也有一個弊病，那就是假如遇到接口下發的數據結構比較復雜，涉及到多個字段的變更，用 Charles 去 Mock 數據就比較麻煩。

第五步：后端接口測試&業務邏輯覆蓋（看日志、看代碼）

看日志

業務測試過程中，我們需要時刻關注后端日志狀態。

有時候接口響應數據是正常的，但是后端日志可能正在報錯，

比如：

搜索結果頁返回空數組是常見現象，一般代表搜索關鍵詞沒有召回任何商品。

但是臻叔有一次測試過程中，發現同一個關鍵詞，在同樣的條件下，有時召回0個商品，有時召回多個商品。

一開始覺得很蹊蹺，后來一查看后端日志，才發現召回商品的時候超時了。

看代碼

推薦大家在做接口測試的時候，一定要去閱讀開發的源碼。

閱讀源碼可以對業務邏輯實現了解更加深入。

另外，有些條件，在手工測試中很難模擬出來，但是通過閱讀源碼，甚至單元測試，就能夠輕松的模擬出來。

閱讀源碼還有個好處就是，對開發起到一個約束作用，因為代碼是公開的，如果從代碼層面發現很多Bug的話，開發的面子也過不去。

關于閱讀源碼，我們可以把代碼拉到本地，用IDEA等工具去查看源碼。

如果代碼量很大怎么辦？

告訴大家一個小訣竅：當開發提交代碼之后，我們可以在Gitlab上看他的Commit記錄，或者將他的開發分支和生產環境的分支做個diff，這樣就能知道他改了哪些地方。

此外，還有2個工具推薦：

java覆蓋率工具 jacoco，這里可以用來統計代碼覆蓋率。

感興趣可以參考：https://github.com/jacoco/jacoco

代碼靜態掃描 sonar，主要是用來檢測代碼編寫是否規范。

感興趣可以參考：http://www.sonar.org.cn/

 

第六步：接口性能調優（Arthas）

這里再給大家看一個真實工作中的案例：

排查過程：

（1）先在APP上嘗試復現

（2）抓包看接口返回響應時間，一次請求居然花費了3.69s

（3）通過Arthas的trace逐步去排查接口響應慢的原因：

進入Arthas命令行

java -jar arthas-boot.jar

 

trace 接口調用的方法

trace 類名 方法名

 

最后發現可能是調用價格標簽的時候很慢。

后來終于找到了原因：

調用依賴的服務的某個方法在測試環境中已經不維護了，但是代碼存在bug，還會繼續調用，導致調用超時。

經過優化后，搜索網關響應速度從 3s 縮短到 300ms 左右。

 

 

第七步：接口異常機制（Chaosblade）

因為接口依賴的服務很多，經常需要調用其他接口。假如依賴的服務出現了異常，我們就需要考慮我們的接口是不是做了容錯處理，或者是降級處理。

可以用Chaosblade去注入異常。（非必須，但有更好）

Chaosblade是阿里開源的混沌工程工具，感興趣的可以去了解下：https://chaosblade.io/docs/

 

第八步：接口版本控制&diffy

一般接口都會區分版本，如果接口不是很規范，或者改了一些通用的邏輯，這個時候就需要對老版本進行一次回歸測試。

最笨的方法就是拿新老版本的兩個app對比測試。我們也可以用diffy這個工具來做回歸測試。

diffy是推特開源的一款接口數據對比工具，這里是Github地址 ：twitter-archive/diffy

 

第九步：開始做接口自動化

接口自動化一般常用于進行線上巡檢回歸、提測冒煙測試等場景。

實現接口自動化，常見有幾種方式：

（1）coding：

python+pytest+requests，臻叔公司目前采用這種方式去做。

（小而美，方便定制化）

pytest生成的測試報告

（2）postman+newman

（利用工具，效率最高，但是不太方便定制化）

感興趣可以參考：https://www.npmjs.com/package/newman#newmanrunoptions-object--callback-function--run-eventemitter

（3）流量錄制與回放

（低代碼實現，但是實現成本頗高）

常用的流量錄制與回放工具：gor

原文轉自：https://zhuanlan.zhihu.com/p/369650421