引言：
不知不覺中成為一名測試攻城獅已將近7年之久，在這期間做過不少API接口測試。 最早接觸的API接口在項目中稱之為（webservice)，期間走了不少彎路。也收獲了不少的經驗，現分享下在測試的路上走過的坑。
第一階段小白初體驗:
初始接觸API是在11年，第一次接觸API接口一臉的懵逼，很茫然不知如何下手測試，對http網絡協議也不了解。后來 由研發同學提供對應接口 web界面，測試時進入對應接口界面，在textbox輸入對應參數值 提交后查看返回值。但剛幵始一臉懵逼，返回值也不清楚是否正確，每次都是把研發同學叫 過來直接看結果。嚴重耽誤了效率,后來不斷的自我反思，在研發同學的不斷講解API知識。 不斷前行最終自己可以獨立測試，雖然中間過程也比較坑。比較囧(在這里特別感謝研發 的同學非常耐心的講解API知識，也非常感謝大芽同學的幫助 ）
第二階段菜鳥階段
經過不斷的摸索和不斷學習API知識，提高自己。從http網絡協議入手，到一次網絡請求的工作過程。如下圖
HTTP網絡協議，目前常用的請求類型：POST；GET；PUT等。目前用的比較多的是POST,GET這2種。一般涉及到寫操作使用POST請求，只是讀操作使用GET請求。
通過不斷測試API接口和閱讀API接口開發文檔，總結經驗設計API功能測試用例。例如初始時設計發表評論接口： 設計Case如下 1.有Userid，有評論內容 2.無Userid，有評論內容 3.有Userid，無評論內容 4.無Userid，無評論內容 5.有Userid,有評論內容（查詢數據庫，是否存儲一致）6.有Userid,評論內容等於限制數 7.有Userid,評論數大於限制數。
用例設計完成，剩下的就是執行用例。不斷的總結經驗，根據發現的Bug，補充自己的測試用例。在測試過程中發現了Bug,盡量描述全。把請求的參數，以及返回的參數全貼到Bug描述里面，這樣研發在復現Bug，也很節省時間。這樣也是提高了大家的工作效率。使用Excel比較不錯，設計用例時候排列組合就好。
第三階段工具運用：
在繁重的測試過程中發現這種由研發提供的web界面方式效率比較低下，回歸測試時 非常不便捷。測試數據每次都要重新輸入，增加了大量的重復工作。每次回歸測試都需要消耗大量的時間，主要是測試數據的管理在WEB頁面沒辦法保存。通過網上查找和同事咨詢，引入了接口測試工具 SoapUI。在SoapUI中創建API的項目，添加對應API接口。創建API接口測試用例，把測試數據配置好就可以了。在執行測試任務時，執行對應的API接口測試用就可以了。使用SoapUI后重復輸入的工作解放了出來。提高了非常不錯的工作效率，節省了不 少工期.
第四階段菜鳥業務提升
在測試過程發現自己設計的用例，數量上太過於龐大。而且大多數用例都是用來測試接口本身，反而忽略了接口本身的業務。
例如login接口，設計功能用例： 1.有帳號，有密碼 2.有帳號，無密碼 3.無帳號，無密碼 4.無帳號，無密碼 5.有帳號，有密碼 （登錄用戶，與數數據庫校驗一致）
但實際的用戶可不單單一類用戶，按照注冊來分可以分為新注冊用戶，老用戶。按照權限來分比如京東，分為普通會員，銅牌會員、銀牌會員、金牌會員、鑽石會員。所以實際測試需要測試 這2大類用戶登錄。這個時候需要提煉出實際業務測試用例，實際的業務有的是不單調一個接口，是多個接口組成。中間還涉及到B接口需要從A接口獲取參數。
設計業務用例：1.新注冊會員登錄 2.普通會員（老用戶）登錄 3.銅牌會員登錄 4.銀牌會員登錄 5.金牌會員登錄 6鑽石會員登錄 7.非注冊用戶登錄。
確定了測試用例，剩下的就按照測試用例執行就可以了。