全網(wǎng)最詳細的接口測試實(shí)戰案例

一、接口測試的誤區

前段時(shí)間，有個(gè)朋友跳槽去了一家公司做服務(wù)端的測試開(kāi)發(fā)工程師，月薪漲了50%

我第一時(shí)間向他送去了誠摯的祝福，同時(shí)詢(xún)問(wèn)了他去到新公司的工作情況。

他和我說(shuō)，他目前主要負責一個(gè)電商平臺的接口測試工作以及開(kāi)始著(zhù)手去搭建一個(gè)接口自動(dòng)化測試平臺。

因為該同事以前是做移動(dòng)端的測試的，從來(lái)沒(méi)有聽(tīng)說(shuō)過(guò)，他有做接口測試的經(jīng)驗。于是我出于好奇，就問(wèn)了一下：他目前是如何去進(jìn)行接口測試的。

他對這個(gè)問(wèn)題可能沒(méi)有做出充足的準備，也有可能他因為之前沒(méi)有接口測試的相關(guān)經(jīng)驗，他給到我的回答，其實(shí)和網(wǎng)上隨便搜出來(lái)的答案差不多：

通過(guò) Postman / Jmeter / 代碼調用 等測試工具，來(lái)模擬網(wǎng)絡(luò )請求，

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

2. 測試響應結果是否會(huì )返回約定的數據格式，有沒(méi)有字段沒(méi)有下發(fā)或下發(fā)不正確。

3. 驗證接口是否有安全性問(wèn)題，是否鑒權。

利用 Postman 進(jìn)行接口測試

對于這個(gè)回答，我并不感到意外，網(wǎng)上大多數的回復也都是這么說(shuō)的。

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

NO，這只是接口測試的冰山一角，接口測試遠沒(méi)有你想象中的那么簡(jiǎn)單！

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

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

接下來(lái)，臻叔將用一次深度的接口測試實(shí)戰，來(lái)分享一下，臻叔是如何去做接口測試的。

二、接口測試的實(shí)戰步驟

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

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

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

目前互聯(lián)網(wǎng)產(chǎn)品的后端服務(wù)，基本上都是分布式部署的，一個(gè)接口可能會(huì )調用其他接口，也有可能被其他接口調用，接口與接口之間，具有千絲萬(wàn)縷的依賴(lài)關(guān)系。

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

如果我們只熟悉自己的接口，不清楚與其他接口的依賴(lài)關(guān)系，不可謂知彼；

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

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

我們在測試的時(shí)候，很可能只會(huì )片面的去關(guān)注搜索網(wǎng)關(guān)開(kāi)放給前端調用的接口，

但只要把整個(gè)調用鏈路和流程圖畫(huà)出來(lái)，我們會(huì )發(fā)現其實(shí)搜索網(wǎng)關(guān)依賴(lài)好多的服務(wù)。

比如：

搜索網(wǎng)關(guān)需要調用價(jià)簽系統，去獲取商品促銷(xiāo)價(jià)格；

搜索網(wǎng)關(guān)需要調用推薦系統，去獲取搜索場(chǎng)景下的推薦的商品；

搜索網(wǎng)關(guān)需要去調用商品系統，去獲取實(shí)時(shí)的商品信息；

搜索網(wǎng)關(guān)需要去調用搜索服務(wù)，去ES召回商品、獲取搜索排序信息等等。

前端在搜索框搜索一個(gè)關(guān)鍵詞，對搜索網(wǎng)關(guān)發(fā)起一個(gè)HTTP請求，背后其實(shí)經(jīng)過(guò)了很多道工序去處理這個(gè)請求。

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

接口背后的業(yè)務(wù)邏輯是否正確處理、后端依賴(lài)的服務(wù)是否健壯、接口性能是否達標。

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

1、看項目wiki、產(chǎn)品文檔和開(kāi)發(fā)文檔。

2、看開(kāi)發(fā)寫(xiě)的代碼，閱讀代碼，當然是首選：JetBrains全家桶啦（Java用IDEA；Python用Pycharm）

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

 

第二步：編寫(xiě)接口測試用例

接口測試用例和平常的測試用例差不多，沒(méi)有太多的要求限制。因為測試工作中很多時(shí)候不是專(zhuān)門(mén)測接口的，所以這個(gè)步驟不一定要做。

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

如果說(shuō)要做接口自動(dòng)化，接口測試用例也是很有幫助的。

這里給出一個(gè)接口測試用例的案例：

 

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

接口文檔在軟件項目開(kāi)發(fā)過(guò)程中非常重要，接口文檔是連接前端開(kāi)發(fā)和后端開(kāi)發(fā)的一座橋梁。

在項目開(kāi)發(fā)之初，前端開(kāi)發(fā)和后端開(kāi)發(fā)會(huì )共同去約定一套接口規范，然后由后端開(kāi)發(fā)去編寫(xiě)接口文檔，然后前后端就可以按照約定去進(jìn)行協(xié)同開(kāi)發(fā)。

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

有的團隊習慣用wiki或者在線(xiàn)文檔去編寫(xiě)接口文檔；

有的團隊喜歡用專(zhuān)業(yè)的接口文檔工具，比如：Swagger、Yapi等去生成接口文檔。

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

swagger 對多種編程語(yǔ)言/框架 都提供了良好的接入方案。就拿Java來(lái)說(shuō)，只需要引入相應的jar包，在接口上添加相應的api文檔注解，就可以自動(dòng)生成網(wǎng)頁(yè)版的接口文檔。

并且還可以通過(guò)接口文檔去對接口進(jìn)行調試，大大提高了開(kāi)發(fā)效率。

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

測試接口文檔可以參考以下測試點(diǎn)：

確保開(kāi)發(fā)必須提供接口文檔。如果開(kāi)發(fā)沒(méi)有寫(xiě)接口文檔的習慣，應push開(kāi)發(fā)去寫(xiě)接口文檔。

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

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

當后端開(kāi)發(fā)完成接口的開(kāi)發(fā)工作時(shí)，我們就可以提前開(kāi)始對接口進(jìn)行初步測試了。

步驟如下：

把后端代碼部署到測試環(huán)境上。

通過(guò)postman或swagger去對接口文檔提到的接口進(jìn)行測試。

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

前面的步驟只是利用測試工具去發(fā)起網(wǎng)絡(luò )請求，來(lái)模擬接口調用。

但在真實(shí)的場(chǎng)景下，搜索網(wǎng)關(guān)的接口實(shí)際上是提供給 APP/WEB/小程序 進(jìn)行調用的。

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

可以利用Charles來(lái)對前端發(fā)送的請求進(jìn)行抓包，

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

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

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

當有些數據有多種狀態(tài)，并且數據比較難以構造時(shí)，我們可以通過(guò)Mock數據去進(jìn)行測試。

常見(jiàn)的Mock數據的方式有：

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

如果是PHP或者Python等動(dòng)態(tài)語(yǔ)言，可以直接在后端代碼里面去更改條件。

數據庫中去修改數據。

用專(zhuān)業(yè)的Mock工具去構造數據，如：EasyMock、TestableMock、Mockjs等。

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

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

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

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

看日志

業(yè)務(wù)測試過(guò)程中，我們需要時(shí)刻關(guān)注后端日志狀態(tài)。

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

比如：

搜索結果頁(yè)返回空數組是常見(jiàn)現象，一般代表搜索關(guān)鍵詞沒(méi)有召回任何商品。

但是臻叔有一次測試過(guò)程中，發(fā)現同一個(gè)關(guān)鍵詞，在同樣的條件下，有時(shí)召回0個(gè)商品，有時(shí)召回多個(gè)商品。

一開(kāi)始覺(jué)得很蹊蹺，后來(lái)一查看后端日志，才發(fā)現召回商品的時(shí)候超時(shí)了。

看代碼

推薦大家在做接口測試的時(shí)候，一定要去閱讀開(kāi)發(fā)的源碼。

閱讀源碼可以對業(yè)務(wù)邏輯實(shí)現了解更加深入。

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

閱讀源碼還有個(gè)好處就是，對開(kāi)發(fā)起到一個(gè)約束作用，因為代碼是公開(kāi)的，如果從代碼層面發(fā)現很多Bug的話(huà)，開(kāi)發(fā)的面子也過(guò)不去。

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

如果代碼量很大怎么辦？

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

此外，還有2個(gè)工具推薦：

java覆蓋率工具 jacoco，這里可以用來(lái)統計代碼覆蓋率。

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

代碼靜態(tài)掃描 sonar，主要是用來(lái)檢測代碼編寫(xiě)是否規范。

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

 

第六步：接口性能調優(yōu)（Arthas）

這里再給大家看一個(gè)真實(shí)工作中的案例：

排查過(guò)程：

（1）先在A(yíng)PP上嘗試復現

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

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

進(jìn)入Arthas命令行

java -jar arthas-boot.jar

 

trace 接口調用的方法

trace 類(lèi)名 方法名

 

最后發(fā)現可能是調用價(jià)格標簽的時(shí)候很慢。

后來(lái)終于找到了原因：

調用依賴(lài)的服務(wù)的某個(gè)方法在測試環(huán)境中已經(jīng)不維護了，但是代碼存在bug，還會(huì )繼續調用，導致調用超時(shí)。

經(jīng)過(guò)優(yōu)化后，搜索網(wǎng)關(guān)響應速度從 3s 縮短到 300ms 左右。

 

 

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

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

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

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

 

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

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

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

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

 

第九步：開(kāi)始做接口自動(dòng)化

接口自動(dòng)化一般常用于進(jìn)行線(xiàn)上巡檢回歸、提測冒煙測試等場(chǎng)景。

實(shí)現接口自動(dòng)化，常見(jiàn)有幾種方式：

（1）coding：

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

（小而美，方便定制化）

pytest生成的測試報告

（2）postman+newman

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

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

（3）流量錄制與回放

（低代碼實(shí)現，但是實(shí)現成本頗高）

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

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