簡介
上篇我們已經介紹了什么是接口測試和接口測試的意義。在開始接口測試之前，我們來想一下，如何進行接口測試的准備工作。或者說，接口測試的流程是什么？有些人就很好奇，接口測試要流程干嘛？不就是拿着接口文檔直接利用接口測試工具測試嘛。其實，如果只是三五個接口，你可以這么做一個臨時的接口測試。但是，如果是上百個接口，或者，你們公司的這個項目，第一次做接口測試，那么，我們還是很有必要嚴格遵守接口測試的流程。
接口測試的流程
接口測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：1.測試接口文檔（需求文檔） 2.根據接口文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類划分，邊界值等設計方法） 3. 執行測試，查看不同的參數請求，接口的返回的數據是否達到預期。
接口測試和功能測試一樣，流程也大致遵守V模型，請看下圖
一般來說，接口測試左邊的每個階段，每個公司可能都側重點不同，例如有些公司就沒有需求討論和需求評審這個階段。不管如何，用例設計，這個是少不了，而且是重點，要花時間的階段。只有覆蓋全面的接口測試用例，才能有比較好的測試接口覆蓋率，才會找出更多的接口的Bug，后期接口才能越穩定。
為什么要寫用例
功能測試用例，大家都寫過。接口測試用例，很多人沒有寫過。在后邊后又專門一章關於接口用例和接口報告的模板。在寫之前，我們來討論下，為什么要寫接口用例。
- 理清思路，避免漏測和重復測
- 提高測試效率
- 跟進測試進度
- 告訴領導做過
- 跟進重復性工作
- 更好的記錄問題，發現問題，復現問題
- 同時這也是是接口測試流程中的一個產物（測試用例）
上面七點，結合自己測試實際經驗，應該來說是很好理解和認同的。有用例，自己做到心中有數，不要一個測試點重復測好多次，就有思路，避免漏掉測試點。跟着用例測試，避免隨機測試那種沒有目的性的測試，提高測試效率。有用
例，上級問你完成的進度，你好用數據回答。有用例，用來標記你執行的結果，證明你做過測試。避免將來發生問題，人家說你沒有測試，有數據和證據說話。有用例，測出問題你可以根據用例將問題輕而易舉的浮現出來，不至於等你反饋或
者復現的問題時，你忘記是如何操作才回出現問題。接口測試也需要重復跑，跑幾輪，或者用自動化天天跑。這樣的重復性工作，用例可以保證每次重復做的是一樣的情況。
接口主要設計用例點
主要從四個方面來設計接口用例：功能，邏輯業務，異常，安全
功能：
1）功能是否正常；
2）功能是否按照接口文檔實現
舉例：比如博客園添加隨筆，需要登錄才能添加。也就是業務要求不支持游客添加隨筆功能，如果設計一個沒有登錄的用戶，然后去測試添加隨筆接口，結果接口能添加到隨筆，說明功能不正常，不符合需求和接口文檔描述。
邏輯業務：是否依賴業務；
舉例：該接口調用之前，需要調用登錄接口，如果不登錄也能請求數據，不符合業務規則。
異常：參數異常和數據異常
參數異常：關鍵字參數，參數為空，多，少參數，錯誤參數
數據異常：關鍵字數據，數據為空，長度不一致，錯誤數據
舉例：不管數據異常還是參數異常，測試點差不多，一個參數有key和value，key表示參數，value表示數據。第一，看看參數和數據能不能支持關鍵字，例如Java中的保留關鍵字等等。第二個就是參數和數據都為空，看看是否做了判斷。第三個，參數多和少，例如有兩個參數的接口，你需要設計一個三個參數的用例，一個只有一個參數的用例。數據那邊長度不一致，例如設計很長的字符串是否支持，因為數據庫創建表過程都設置好了每個字段的長度。輸入錯誤的參數和數據，例如故意輸出單詞等等。
安全測試用例設計：
1)cookie：有cookie才能獲取數據，如果不帶cookie還有信息返回，說明有問題
2)header：正常接口帶header信息，刪除header看是否能夠返回數據。
3)唯一識別碼：app手機識別碼，一般是唯一的。
安全測試主要從上面三點檢查。第三個是唯一識別碼，主要是指app上手機的識別碼，一般很少用到，除非很嚴格的接口測試，例如銀行app登錄，需要指紋，而指紋來源手機，一般有一個手機識別碼判斷過程。