摘自http://www.51testing.com/html/32/n-4422132.html

接口測試作為測試金字塔的第二層，有著低成本、高回報的優勢。越來越多的人開始做接口測試，同時可以選擇的工具、框架也越來越多。測試人員甚至不用操作app或平臺，通過接口就可以測試不同場景，并測試完全流程，同時接口測試也給造數據也帶來了方便。

　　但是，這就是接口測試了嗎？當然不是。完整的接口測試不僅要校驗接口能否調通，還要校驗各種組合場景、異常場景、輸入參數合法性有效性和邊界值、接口安全、接口性能等。大部分同學的接口測試普遍存在兩個問題，一是場景太淺，另一個是斷言不足。前者造成測試范圍有局限，后者是對測試結果校驗不足。只校驗了響應碼的接口測試是無意義的，也不利于持續集成和持續部署。

那么接口測試用例如何設計呢？從輸入、處理邏輯、輸出三部分入手。輸入就是各種參數類型及組合的校驗，如對數值類型，通過負數、0、小數、99999999999999999等，前端可能過濾掉了這些輸入，但是在接口層還是要做校驗，特別是對金額來說。對輸入的測試可以用等價類、邊界值、判定表、因果圖等方法來分析。對于輸出，則是要覆蓋各種響應嗎和返回結果，正常的、異常的、特殊的、失敗的情況等等。

我想討論的，是第二部分，業務邏輯。大家都會對接口做正常場景的測試，也會做參數校驗的測試，但是不知道如何結合業務做接口測試。我們知道在業務流程中，是用戶/后臺的一些操作，引起數據或者狀態的改變，然后引申出各個檢查點。比如用戶還款，還清了最后一期，那么這個操作的結果需要列出來：比如更新應收臺賬、更新回款記錄、更新還款狀態、恢復額度；我們的檢查點也要列出來：在客戶端檢查待還列表、檢查提現記錄、檢查卡片狀態，以及在后臺檢查各個表的數據。這些就是可以提供給接口測試的。因為業務流程有很多條線，場景不僅只有一個主流程，這個還清最后一筆就是一個場景，除了要校驗接口響應中的結果，還要到數據庫校驗各個值，同時可以通過其它接口，如再次調用還款接口會還款失敗，調用額度查看接口額度已回恢復，查看待還列表接口狀態為已還清。要在接口測試中實現比較全的場景和校驗點，需要提前把checklist列出來，詳細的測試用例可以不需要，但是checklist一定要有。總結起來就是通過響應結果進行校驗、到數據庫進行校驗、通過其它接口校驗。

接口測試的業務場景如何梳理呢？在app或者平臺上可能限制了我們的操作，但是接口不同，只要我們愿意，我們可以設計各種順序、各種次數的場景，當然都是要和業務邏輯有關系的。根據狀態不同，我們可以測試當用戶處于未登錄、未綁卡、未借款狀態的時候的一些操作；根據操作路徑不同，我們可以讓用戶通過微信、支付寶、銀行卡支付；根據業務規則不同，可以測試不可部分還款/提前還款的產品可否進行部分還款/提前還款、無該優惠的用戶群可否使用該優惠券；根據操作次數不同，我們可以測試用戶重復綁卡、重復提現、重復還款；根據操作順序不同，我們可以測試先收到優惠券再還款、還款中收到優惠券；根據數據不同，可以設計不同期數、不同金額的提現方式。同時在接口中一樣也可以用場景插入、場景替換、場景刪除、場景重復、數據替換的方式設計用例。而針對異常場景，用戶權限不允許的操作、狀態不允許的操作、數據不允許的操作、極限條件下的操作，都可以用上面的方式通過接口進行測試。

　　把重要的接口測試用例通過腳本實現，不僅可以提高回歸效率，減少版本優化所需要的測試時間；接入持續集成持續部署，還可以起到監控的作用，同時可以讓優質的代碼更快上線。把重復性的工作通過自動化的方式實現，我們才能有更多的時間去做探索性的測試和其它專項測試。當然接口測試維護成本還是需要的，但和UI自動化相比已經是非常低了。