所以有必要詳細和認真了解下怎麼開展對介面的功能測試。
所以梳理了以下介面功能測試：知識點參考來自於
1、json格式測試：
通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試
如果傳遞非json的情況，這時候程式會不會正確的處理，返回相應的 error code
2、預設值測試：
很多情況一些非必填的引數會有預設值，比如說乙個查詢的介面，引數count為返回查詢的結果數量，
預設為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的資料超過10條。
3、異常型別測試：
比如上面的count引數，這個引數的型別一定是可以轉換為int型別的，這時候我們需要測試如果傳的一些不可以
轉換為int型別值來測試**是否加入判斷。
4. 必傳項測試：
如果介面的引數有必傳項，那麼需要測試在不傳這個引數的時候介面返回情況，測試是否會提示
相應的error code
5. 非必傳項測試：
如果介面有非必填項，當我不傳遞這些引數的時候會不會正常的返回相應的結果
6.非空測試：
無論是必傳的和非必傳的引數，傳遞的key是正確的，但是value=null，這時候返回結果是否正確
7.業務邏輯測試：
傳遞正確的引數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行
增刪改的操作，也需要看資料庫是否同步進行了這些操作
8.相容性測試：
比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的呼叫方式
9.錯誤碼測試：
通用的錯誤碼與業務錯誤碼是否能夠清晰的說明呼叫問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
10.資料異常測試：
假如資料庫設計為32位varchar型別，那麼如果傳33位會是什麼情況，會不會丟擲相應的錯誤碼，而不會丟擲資料庫異常
11.返回值測試：
返回值除了內容需要是正確的，還需要型別也是正確的，保證呼叫方拿到這些引數能夠正確的解析
12.加密測試：
單個的介面測試通過後，需要將單個的介面組成連續的場景，比如說投資介面需要用到乙個類似token的
引數，而這個引數是登陸介面獲取到的，所以就需要先呼叫登陸介面，然後再去呼叫投資介面。
還有就是
像資料許可權與操作許可權這些，都會依賴一些其他的介面，那麼把這些依賴的介面組成乙個場景來測試資料的 正確性。
還有一部分介面是內部呼叫的，比如說註冊介面，在註冊的時候通常需要獲取乙個驗證碼，然後輸入 驗證碼再進行提交註冊的操作，
在這過程中，驗證驗證碼的操作是在註冊的內部完成的，那麼其實在組合場景 的時候就不需要再去中間加入驗證驗證碼的介面。
1. 介面測試簡述：
1、檢查介面返回的資料是否與預期結果一致。
2、檢查介面的容錯性，假如傳遞資料的型別錯誤時是否可以處理。例如上面的例子是支援整數，傳遞的是小數或字串呢？
3、介面引數的邊界值。例如，傳遞的引數足夠大或為負數時，介面是否可以正常處理。
4、介面的效能，介面處理資料的時間也是測試的乙個方法。牽扯到內部就是演算法與**的優化。
5、介面的安全性，如果是外部介面的話，這點尤為重要。
2、單介面與組合介面
（1）單介面
單介面入參，出參
入參：引數邊界值、型別、非必傳、必傳
出參：資料型別、結果與mysql表資料比較、響應碼(正確碼、錯誤碼)、資料的準確性(比如四捨五入的情況、浮點被強製成整型等)
許可權（重要）：token失效（有效）
（2）組合介面
結合測試場景(要結合業務)，編寫相應的測試用例；
場景：比如新建乙個客群，驗證將其轉化為系統客群 是否成功；
介面間的引數傳遞；
介面測試和功能測試
單元測試 單元測試是測試中的最基本的測試，也是測試中的最小單元，它的物件是函式物件，也可以包含輸入輸出，針對的是函式功能或者函式的內部邏輯方面。並不包含業務邏輯 介面測試 介面是拋開介面而說，介面封裝了介面對使用者提供功能，而介面測試則是拋開了介面對介面的封裝和整合 介面提供的乙個功能中可能包含了多...
Fidder功能介紹 介面測試
一 fiddler工具介紹 fiddler 是乙個http協議除錯 工具 1 是位於客戶端和伺服器的http 它能記錄所有客戶端和伺服器的http和https請求響應，進行截獲 重發 編輯 轉存等操作。2 允許監視 設定斷點，甚至修改輸入輸出資料，fiddler包含了乙個強大的基於事件指令碼的子系統...
介面功能測試，python3 5
閒來無事，把以前的 貼出來 return 請求成功，開始判斷響應狀態 requests statuscode.text else return requests statuscode print 請求失敗if內 except exception as e print 請求失敗try內 3try a ...