API測試 自動化測試

background：最近兩個月被分配做UI automation，原因是換了一套平臺，需要重新部署，有些業務需求改了case都跑不過了，我的任務是debug case，把case都跑通。工具是Robot Framework。
當時感覺task相對輕松，因為業務相對簡單，只是Case多些，但debug case，應該是我強項（這些年的工作經驗裏debug 代碼了解業務是我的強項，雖然不是什麽好的學習代碼的習慣吧），不過越debug越傻眼，因為核心邏輯就那幾個keywords，有時可能牽一發動全身，而且最最郁悶的是，公司用的是AWS，采用的是Lambda+API Gateway的request方式，而lambda每天有訪問次數限制，超過峰值速度就會特別慢，每天下午基本debug不了case，所以要早上早早的到，爭分奪秒改case跑case，效率真的很低，每天改四五個case很不錯了；而且坑很多，明明看著沒問題，debug也發現不了哪兒錯，case就是不過，後來發現如果sleep幾秒（爭分奪秒的秒是這麽滴重要，哈哈），case就pass了，可不知道的時候，就會花幾個小時。
後來領導說效率太低，要改進測試方法，這可樂壞本寶寶了，因為之前研究過自動化測試，雖然沒怎麽做過，但我知道我們的automation測試癥結在哪兒。

從自動化測試金字塔的角度出發，UI的投入產出比是最低的，我們UI的case很多，但是沒有API測試，而且最怕的就是把automation 做成了倒金字塔。於是征得領導同意後我開始研究怎麽做UI 的API測試，我是從以下幾個方面調研的：學習工具的成本、是否開源、開發的成本、與jenkins的集成、case是否容易管理，自動生成report。後來發現TestNG是最佳選擇，但是由於某些原因，TestNG被否了，最終的決定是用HTTPClient jar包自己寫Keyword，然後用Robot調用這些keyword。

當時為了驗證TestNG的可行性，自己寫了個Demo，感覺用TestNG寫case很省時間。後來自己寫keyword在eclipse下debug的時候發現也還算好，雖然沒有TestNG那麽高效，但比Robot cost小很多。
可當用Robot調用這些keyword的時候問題來了，而且讓我再次感慨Robot還是不方便，原因有以下幾點吧

1. Eclispe debug方便直觀，而Robot只能加log，不容易定位問題。
2. 如果是keywod的問題，Eclipse可以直接debug定位，而Robot是對keyword進行了調用，還需要回到eclipse再次debug，debug需要更長的時間
3. 最後核心還是Robot寫的keyword，而不是java的keyword，這樣其實和UI automation沒什麽太大區別，我感覺cost還是很高。

不過API測試也不是萬能的，比如最近新加的一個功能，本來我全用API寫的，沒有UI Automation，但後來因為一個手工測試，API case跑過了，但UI測試是能catch住的一個bug，所以讓我更堅信一句話：無論手工測試還是自動化測試，最核心的還是case的design。怎樣用測試理論中的最少的case cover更多的功能，怎樣設計case使得UI Automation、API測試更合理化，都是一個功底活兒

淺談API測試與UI Auomation一點心得