領導叫我做介面測試，我好慌！
- 2019 年 10 月 6 日
- 筆記
不要慌，問題不大! 此文主要獻給在工作中接觸介面測試，在群里諮詢，公司叫我測試介面我該怎麼去進行？測試用例怎麼設計呢？還有我都不知道該怎麼下手。我們來從做介面測試的前提以及介面測試必要的基礎去分析分析。
這裡個人作為介面小兵，簡單整理幾點，如果要進行系統的介面測試以下幾點個人覺得是很有必要的：
1.被測對象業務充分熟悉
2.完備的介面文檔/對象模型
3.自己至少有基礎的介面測試功底(至少要會使用工具進行單/多介面)
個人使用postman：
4.熟悉HTTP/HTTPS請求；會使用抓包工具
個人使用Fiddler：
5.後期介面框架的搭建
基於程式碼層去實現介面自動化最好，也是最體現價值的，現熱python語言去做介面自動化，簡易Python介面測試之Requests
下面是無涯大佬寫的一本python自動化實戰數據，裡面包含基於python語言的介面自動化如何進行，寫的很不錯，大家可選擇性購買，在《Python自動化測試實戰》的書籍裡面系統的介紹了基於Python語言的介面自動化測試實戰和基於Python語言的UI自動化測試實戰，特別是介面測試部分，詳細的介紹了HTTP的協議原理，序列化與反序列化，主流測試工具(Postman和JMeter)在介面測試實戰中的應用，
以及Requests的介面測試實戰，和介面測試框架的設計，但是總覺得缺少一些維度沒說明白，到書校驗的後期一直想加，但是由於時間的緊張，就沒繼續添加新的內容。雖然我們很清晰的測試「測試金字塔」的模型，也系統完善的介紹了API的知識體系。但是介面測試的維度到底是什麼，在UI和API的測試之間選擇什麼，如何選擇？
我建議盡量做API的自動化測試，一方面做API的測試比較簡單，第二是執行效率高，在維護成本上需要看具體設計的框架，但是比起UI的框架維護成本還是比較低的。介面測試從大的維度來說，
分為兩類，一個是單介面的測試，另外一個是多介面的測試（基於業務場景的測試），單介面的在微服務和開放平台測試中比較常見，比如提供了一個介面給合作夥伴，但是需要測試來測試下這個介面的功能和它的穩定性，那麼只需要在如下幾個維度來具體測試：
1、介面的請求參數它的數據類型後台是否做了校驗
2、介面的請求參數必填的參數後台是否做了處理
3、介面的請求參數長度是否做了處理 4、提供的介面是否實現了對應的業務場景和業務功能
5、這裡個人補充一點介面的健壯性
在這裡還是重點來看前面幾點，關於後面的在多介面的測試來逐步的總結。
先簡單的寫一個介面，實現的源碼如下：
#!/usr/bin/env python# -*-coding:utf-8 -*-from flask import *from flask_restful import Api,Resource,reqparse app=Flask(__name__)api=Api(app=app) class WuYaView(Resource): def get(self): return jsonify({'index':'無涯課堂'}) def post(self): parser=reqparse.RequestParser() parser.add_argument('author',type=str,help='作者名稱不能為空',required=True) parser.add_argument('count',type=int,help='書的印刷數量為正整數') parser.add_argument('sex',choices=['1','0']) return jsonify({'status':0,'msg':'ok','data':parser.parse_args()}) api.add_resource(WuYaView,'/api/v1/book') if __name__ == '__main__': app.run(debug=True)
上面的一個簡單的API，這個介面它有GET請求和POST請求的方法，在POST請求的方法中，auhtor欄位是必須填寫的,count欄位類型是int,sex的參數只能只能填寫'1'和'0'，如果請求參數不符合規範，後台都會返回錯誤的提示資訊，先看author為空，錯誤資訊如下圖所示：
當請求參數count為字元串的時候，見返回的錯誤資訊，如下圖所示：
請求參數sex不是指定的特定參數，見返回的錯誤資訊，如下圖所示：
最後來看一完整的請求，也就是說介面的請求參數是正確的，如下圖所示：
從如上的角度來看，做單個介面測試是很有必要的，而且是必須的，但是我一般建議做單個介面測試的維度，只需要校驗下介面是否可以正常的請求，以及請求後響應數據是否正確，至於請求參數這一層，依據情況來做，怎麼說了，很多公司給測試介面的API文檔都不提供，更別說去修改這些本應該判斷的問題了，也從某些維度說，不是所有的事都是必須做的，依據情況進取捨。
多介面的測試，也就是基於業務場景的測試，這部分測試起來難度還是大的，但是這也是介面測試必須要做的部分，如果單純的驗證一個介面是否請求OK是沒有多大意義的，更多的應該站在業務場景來設計介面測試用例，那麼也就意味著中間需要處理很多的業務場景，動態參數的處理和業務邏輯的處理，關於這些在《Python自動化測試實戰》的書裡面都有對應的案例實戰。
比如一個XX管理模組，使用介面自動化測試實現它的添加，查詢，修改，刪除，中間第一個需要處理的是添加成功後用戶的ID需要獲取到，並傳給下一個介面，這中間就會使用到函數的返回值的知識體系，以及動態參數的處理思路，
另外一個業務邏輯是當添加用戶的時候，實際XX用戶已經存在（不能重複添加），那麼也就需要在對象層對添加用戶的介面進行判斷，當添加用戶存在的時候，怎麼處理，不存在當然是繼續添加和走業務場景，這中間也許有人反駁說我執行添加前看一下，如果存在手動刪除，這樣不智慧，
另外一個觀點是每次執行後都會刪除，這是必須的，但是我們無法保證每次測試用例執行創建的用戶就刪除，比如某次執行的時候，刪除的介面出了問題，導致沒刪除，在這中間，程式不能有太多的假設，用例必須考慮到各個業務場景和邏輯，然後在對象層進行處理。
這個案例的程式碼我就不寫了，感興趣的同學可以購買我的書籍看看，裡面有案例程式碼。我不喜歡講里理論，成年人的學習方式更加看重解決問題的思路和對問題的認知維度，理論是需要的，但是理論更多應該是我們經過實踐總結起來，這樣更加有意思。
《Python自動化測試實戰》它不是一本講理論的是，它更加看重問題的解決思路，和案例的實戰。在實踐中學習，在學習中實踐的思考模式，把理論知識與實際應用相結合，舉出真實的案例，讓讀者學會舉一反三。也歡迎需要的同學購買。
腳本：無涯
圖片：無涯
來源：無涯
/ END.
