介面測試實戰專案02：根據介面文件測試
大家好，我是測試奇譚的作者風風。
上兩次，我們已經瞭解：
這次，我們正式進入測試階段。
為什麼要做介面測試
這個問題的答案很多，我這裡只給大家做個引子。
01 可以精確定位bug
比如：當你在測試某網頁時，發現網頁顯示的資料不正確，你該怎麼辦？
初級測試，直接提bug給開發；高階測試，會定位bug，而要定位bug，就要熟悉介面。
02 提高測試效率
有了01，自然會有提效方面的考慮，這是其一。
其二，如果你測的專案是前後端分離的，後端的提測時間往往早於前端提測時間。如果你是後端測試，你要等著前端提測之後，才開始測試嗎？
此時，你需要介面測試，先把後端的介面過一遍，有問題儘早解決。
03 從技術角度去熟悉業務，發現程式的隱患
現在很多中大型公司都在倡導：測試要會走查開發的程式碼，通過程式碼更深入地理解業務。
業務程式碼走查的第一步，往往是從介面開始——看呼叫，看後端邏輯處理，再看後端返回資料，這些和介面的知識息息相關。
……
介面文件
在進行介面測試之前，我們需要了解介面文件這個概念。
介面文件，說白了，就是供人檢視的文件（一般採用Restful風格編寫），通過規範介面文件編寫標準，保證不同的人寫出來的文件可讀性和可維護性俱佳。
不然A是一個書寫風格，B是一個書寫風格……N是一個書寫風格。作為測試的你，拿到一份AB……N類風格介面文件，你崩潰不？
開啟測試奇譚之前提供的介面測試專案，裡面有一份介面文件。
閱讀介面文件，除了必要的描述外，關鍵資訊在於介面資源：
01 熟悉介面資源（藍色部分）
URL定位資源：一個URL（介面）定位一個資源（你想拿到的東西）
methond操作資源：即你想要對這個東西做什麼操作（初學瞭解GET-查、POST-增、PUT-改、DELETE-刪，即可）
02 請求資源（黃色部分）
如圖所示，傳入資料（一般是json資料格式），發起請求
03 響應：請求的結果（紅色部分）
請求的響應碼 + 響應的結果（一般是json資料格式）
而關於json格式的講解，看這個圖就夠了（值得收藏喲~）
介面請求上手操練
瞭解介面文件後，我們上手來操練一波。
01 啟動專案，開啟postman02 閱讀介面文件中，關於新增學院資訊的部分
03 發起請求（和上文的紅黃藍部分一一對應理解哦~）
http://127.0.0.1:8099/api/departments/
{"data":[ {"dep_id":"T01","dep_name":"Test學院","master_name":"Test-Master","slogan":"Here is Slogan" } ]以上，成功！
一如既往，做個總結
01 介面測試其實沒那麼複雜，只是你沒有接觸它而已；
02 建議上手操作。