關于接口測試的一點想法

        接口測試在大多數公司都沒有定做必要環節，如果時間充足并且測試人員有這個想法就做下接口測試，或者後端開發完成前端遲遲不能提測，測試可以在間歇時間進行下接口測試，以期提前發現接口的問題。當然了，我以前也是在這兩種情況中進行的接口測試。

        最近，由于測試leader有意培養所有測試人員的接口測試能力，也是工作沒那麼緊張，是以要求我們将正在運作的系統已上線的功能寫成接口測試，以後優化上線前先進行已上線接口的測試，無影響才可以。而且團隊中一直有一個被“大才小用”的測試開發，來帶領大家一起做這項工作。

        一步一步，一個一個接口寫下來，發現接口測試真的很有必要。不做接口測試，雖然能滿足功能，但是潛在的危害很大。對于使用者規模大，業務量大，對自己有要求的産品，接口測試不僅必要，甚至應該專門預留接口測試的時間。不然如果有使用者想鑽漏洞，有競争對手想黑你，有黑客想攻擊你，真的太簡單了。

我想舉幾個實際的栗子：

1. 兩個角色的使用者分别可以對産品進行定價和接單，為友善描述，定義角色A可以定價，角色B可以接單。用A角色的使用者登入後，能夠看到定價的菜單，就能定價操作，用B角色的使用者登入沒有定價菜單，自然也就不能進行定價操作，隻有接單菜單。這樣在前端正常操作是沒有問題的。但是如果用接口去測試，B角色的使用者也可以直接通過定價的URL去定價，後端沒有校驗使用者的角色權限。

2. 前端進行輸入長度的校驗，資料庫存儲的長度是100個字元，前端也限制100字元，但是背景沒有處理，也就是通過接口發送超過100，背景沒有限制，直接交給資料庫，資料庫就會報錯。

3. 某個功能通過兩個接口來實作，比如确認付款功能。先調用上傳圖檔接口，上傳圖檔成功後再調用付款接口。頁面測試時，如果上傳圖檔接口沒有傳回成功，不會繼續調用付款接口。但是如果通過接口來調用，直接調用付款接口也是可以成功的，因為在付款接口裡面沒有對圖檔上傳的結果進行校驗。

4. 與1類似，也是在操作的時候沒有驗證使用者是否有權限。比如說A沒有稽核權限，A登入系統看不到可以以稽核的記錄，但是直接用接口調用稽核的話A是可以稽核成功的。