上三次，我們已經了解：
測試奇譚：什麼是介面測試？這篇文章讓你明白
測試奇譚：介面測試實戰專案01：介面測試環境搭建
測試奇譚：介面測試實戰專案02：根據介面文件測試
這次，我們開始按照測試用例進行介面測試。
在測試之前，我先說一點：
此套專案提供了乙份完整的測試用例，但如果你想掌握介面測試技能，建議你先閱讀介面文件，然後自己寫乙份測試用例，再對照標準用例，查漏補缺，100%對你有益
開啟測試用例。該用例有四個大場景（查詢、新增、更新、刪除），共57條用例（查詢學院資訊28個，新增學院資訊15個，更新學院資訊11個，刪除學院資訊3個）。
在實際的介面測試中，當你寫完測試用例後需要挨個執行用例，確保每一條用例通過，如果不通過，那你便發現了乙個bug。
風風這裡不會跟大家過每個用例，因為簡單的介面測試真沒多少難度，但凡你會用電腦，都可以依葫蘆畫瓢操作上手。
但如果你真遇到什麼問題，也別怕，找風風，風風樂意為你解答。
具體的測試方法見postman截圖（一般我們都使用postman做介面測試）：
get請求（查詢學院資訊）
post請求（新增學院資訊）
put請求（更新學院資訊）
delete請求（刪除學院資訊）
在上手操練中，你是否有這樣的煩惱：
01 有些用例，操作得很煩
比如這三個，
在第一條用例中，你需要新建t01、t02學院；
在第二條用例中，你又需要刪除其中乙個學院才可以請求；
在很下面的第三條用例中，你又需要刪除兩個學院才可以請求。
想想如何解決？
當你熟悉業務後，你的用例其實可以改為：
第一步，驗證t01，t02兩個為空的場景；
第二步，新增t01，驗證t01存在，t02不存在的場景；
第三步，新增t02，驗證兩個都存在的場景。
到最後，你的資料，是t01和t02都在，可以拿存在的資料去驗證其他場景，比如更新和刪除等，而不是像之前被動地跟著用例走，做了很多重複性工作。
02 重複測試
當你辛苦測試一次之後，開發突然告訴你：我改了一點**，需要你重新測試一次。
第一次你可能會接受，但次數多了之後，你100%會煩躁，覺得測試工作十分枯燥，毫無意義。
想想如何解決？
自動化測試。
這就是自動化測試的初衷——減少重複性工作（值得減少的），提高工作效率（減少精力投入）。
所以：邊工作邊思考，才能讓你持續進步。
01 不要嫌麻煩，一定要上手操練！
03 真實的工作萬般複雜，高難度介面測試也有，因此得保持一顆敬畏之心。
實戰演練基於加密介面測試測試用例設計
如果介面測試僅僅只是掌握一些requests或者其他一些功能強大的庫的用法，是遠遠不夠的，還需要具有根據公司的業務以及需求去定製化乙個介面自動化測試框架能力。所以在這個部分，會主要介紹介面測試用例分析以及通用的流程封裝是如何完成的。介面測試用例分析 首先在做用例分析之前，可以通過追查公司一年來所有的...
針對介面測試用例設計，我在專案中（搜狗測試）總結
1 介面測試基本工作 1 介面協議型別 如http tcp 2 介面的請求型別 get post等 3 介面引數命名準確 例如，http x uds search userdatasearch 4 介面請求引數，引數型別，是否必選 5 介面返回結果，資料格式正確 例如json pb檔案 6 介面所涉...
頭條專案介面自動化測試 二 之測試用例設計
1 用例設計 模版 id 模組 介面名稱 請求url 用例名稱 請求方法 請求引數型別 請求引數 預期結果 實際結果 備註。注意 單介面顆粒度放的比較小 以測試資料為顆粒度 2 實踐 請求登陸介面 響應 設計用例 1 用例設計 模版 id 模組 介面名稱 請求url 用例名稱 請求方法 請求引數型別...