接口自動化基本流程和測試思路

接口自動化大致步驟：

1、發送請求

2、解析結果

3、驗證結果

定義三個和業務相關的類

1、一個用來封裝HTTPclient，用來發送請求

2、解析結果xml的類

3、一個用於比較測試結果和期望值的類，用於驗證

4、自動生成報告的類：自動發送報告之類的

（locust的python工具）

服務級：Web server（服務） Database（持久化工具-數據庫）、Cache（短時間持久化工具-緩存）

接口測試：

1、構造數據

（1）通過接口構造

比如獲取一個blog的文章信息，怎么構造數據呢？（文章哪里來？？）—返回blog信息

通過添加文章的接口，臨時構造數據（blog文章），然后斷言的時候看看是不是自己造的數據——會造成接口耦合（兩個程序模塊有關聯就叫做耦合。）—和造文章的接口耦合（如果創建文章的接口掛了，那返回blog信息的接口也就掛了）

公交卡充值依賴支付寶的支付接口服務，調用支付接口會有代價，所以模擬一個支付接口，所有通過mockserver（測試樁）去模擬支付接口的服務----不管輸入是什么，返回一直成功或是固定的

如何進行mock？？
mockserver介紹：https://www.cnblogs.com/fnng/p/7511539.html
使用：https://blog.csdn.net/qq_35049819/article/details/77839495 （未驗證）

（2）通過持久化層構造（更好）

意思就是在數據庫直接插入數據

2、調用接口

postman/jmeter–win

CURL-linux

Paw–mac

3、對接口返回進行斷言

通過不同的輸入-判斷不同的預期----數據驅動（輸入數據）
斷言參考方法：對比數據庫值，code驗證

4、接口測試的用例設計

功能測試用例
業務邏輯設計
業務邏輯方面的測試用例主要是針對服務端接口的處理邏輯進行的用例設計，這種用例設計不是針對某個功能點是否實現，而是對接口的處理邏輯以及一些相互依賴的業務進行驗證，通常依照接口的邏輯流程圖來進行。舉一個例子，購物系統中的兩個動作：登錄和下單操作，這兩個業務是相互依賴的，下單操作必須在登錄完成后（登錄狀態下），否則無法完成下單，這個時候我們就可以設計這樣一條case：沒有登錄的狀態下進行下單操作，看服務端如何處理。

可以看到這一塊有兩個判斷，我們需要對不同的判斷分支都設計用例，以保證流程圖中涉及到的分支我們都有測試用例覆蓋。圖中涉及到的不同的分支有：
1.abdf；
2.acg;
3.abdeg;
相應的，我們的用例就應該是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
業務邏輯的用例設計主要是以服務端接口內部的邏輯流程圖為基礎，針對流程圖中的判斷和分支進行用例設計，保證服務端接口的每一種邏輯下都有測試用例覆蓋。

異常處理情況
服務端接口和客戶端之間通常是通過HTTP請求來傳遞數據，在發送請求的時候，客戶端會攜帶各種不同的參數，此時服務端會根據不同的參數進行不同的處理，所以異常處理主要是針對請求中的參數情況：比如參數增加和缺省、參數的數據類型錯誤，參數攜帶錯誤的值、參數為空等等，這需要我們根據接口文檔中各種不同的參數去構造不同的參數異常，檢查服務端的響應情況。

性能和安全性方面
服務器的性能往往是個非常重要的關注點，在實際的測試中我們主要關注的是接口的QPS數值，以及CPU和內存占用等性能指標，通常借助於其他工具比如LoadRunner進行性能測試。安全性方面，主要考慮一些常見的安全策略比如請求加密、sql注入等等。

二、接口測試實例

1、postman測試

2、python測試

1 # coding:utf-8 2 import requests,unittest 3 class V2ETestCase(unittest.TestCase): 4 def test_ger_node_api(self): 5 python_node_id = 90 6 url = "https://www.v2ex.com/api/nodes/show.json" 7 node_name = 'python' 8 querystring = {"name":node_name} 9 res = requests.request("GET", url, params=querystring).json() 10 print res 11 self.assertEqual(res['id'],python_node_id) 12 self.assertEqual(res['name'], node_name) 13 14 if __name__=='__main__': 15 unittest.main() 

在命令行運行（以后做自動化測試用）：

報告可以生成HTML形式的-加進去

python為例：

unittest庫

Requests庫

Json

Dict字典

assert斷言

用postman做接口測試，選擇get還是post，加入數據發送請求，查看返回的結果—然后給接口做斷言（點右上角的code，選擇js語言，寫斷言）

當接口返回的數據時動態的，比如一個網站文章的最新評論----還是測試環境問題，搭建一個專屬的測試環境，不產生新的數據，一樣的可以測試接口—相當於動態數據靜態化

“怎么做接口測試”這個問題可以分解為兩個問題：
怎么設計接口測試用例？
怎么執行接口測試？

怎么執行接口測試？
Fiddler、SOAPUI、PostMan等可以做半自動的接口自動化測試；
使用Robot Framework做全自動化的接口自動化測試；
自己用代碼做全自動的接口自動化測試，如Java+testNG；

自動化接口測試+生成報告思路：
在接口的開始測試階段，我用POSTMAN來手工測試接口，單一接口測試通過后，把測試用例Copy到Jmeter中，作為后續的定期執行的基礎，在接口手工全部測完后，用Jmeter+Ant+Jenkins來定期檢查每天的接口，並生成測試報告，再寫一個爬蟲每天監控測試報告，如果出現了異常，發郵件報警。

1、每天的歷史報告肯定也是需要留存的
2、有案例失敗時的郵件通知

Jenkins有郵件報警和report展示的插件~ 樓主不用自己寫。。。

最后應該就是測試報告了，集成於自動化的接口測試，每天的接口測試報告也是挺重要的，Jmeter的測試報告雖然也很清楚，但是並不是我想要的東西，我理想的測試報告應該有一下那么兩點

測試通過率
每條測試的過程展示
測試通過率是方便查看報告的人直觀的了解本次測試的結果。

測試過程的展示需要展示如下內容：測試結果、請求地址、輸入參數、輸出結果、斷言結果。並且成功和失敗的標識需要非常明顯。