集成測試實踐之淺談api的分類

　　接觸api測試已經有半年了，也算是小有心得。所以談談我眼中的api。

　　想從理論的角度了解，請訪問http://qa.corp.anjuke.com/?p=59。我師父寫的掃盲貼，適合不知道神馬是api，也不知道怎么測試api的入門階段的童鞋。

　　按照我個人的理解，我接觸到的api大概可以分成那么幾類：

　　1.純讀取數據接口，返回的數據基本是固定的，很少改變。這類api通常比較好測。

　　比如：獲取城市信息。

　　2.通過篩選條件得到結果。這類api是基于第一種分類的api的，因為篩選條件都在第一個分類的api里面，有一定的邏輯，多樣的篩選條件測起來會有點頭暈。所以要事先規劃測試用例。

　　比如：房源列表。

　　3.有復雜邏輯的接口。需要分析用戶的行為，然后根據行為獲得相應內容。這樣的接口特別頭疼，因為它的邏輯最復雜，在測試之前一定要和產品確認好邏輯，任何小問題都要確認，最好是能和開發也確認一遍邏輯，因為在邏輯很復雜的情況下，開發和產品理解的可能不是同一個意思，這種情況我已經遇到過多次。在確定邏輯后，一定準備好測試用例測試數據。

　　比如：推薦。

　　4.寫數據接口。這類接口就是你發一個請求，服務器相應會寫入你傳的數據。由于基本沒什么邏輯，也比較好測試，只需要上服務器查看就可以了。

　　比如：發送日志信息。

　　5.操作類接口。這類接口往往是幾個小接口互相關聯的。這類接口的復雜程度不是絕對的，要根據是否有業務邏輯劃分。

　　比如：收藏和取消收藏，這類接口測試就比較簡單，你可以用收藏接口收藏一套房子，然后去收藏列表查看，然后再取消收藏，再去查看取消收藏列表。需要注意的地方就是收藏數量上限，以及收藏或者取消收藏不存在房源或者過期房源時，返回不會出錯。

　　但例如一些涉及復雜業務邏輯的接口，就往往沒那么簡單了。我就不一一舉例了。

　　最后，我給api測試的八字真言：多測，多想，熟悉業務。

　　光說那么一大堆其實很枯燥，如果真的想了解api，那就動手實踐吧!

　　為找到每一個api bug 而驚喜!

原文轉自：http://www.kjueaiud.com