簡單的舉下例子，我們的增删改查對象基本上是每個系統都會有的。那麼我們如何去測試這個接口？其實我們在寫自動化腳本的時候需要考慮的東西很多，不過核心的隻有那麼幾點，一是要穩定，二是要可重用。我們的腳本和代碼一樣，我們在寫增加對象的時候需要編寫一個邏輯，邏輯中調用開發提供的接口，參數值在我們寫具體用例時給予傳入，例如邊界值等等。整個增加功能我們隻需要一個邏輯就可以搞定，節省了時間，腳本還不容易出錯，後期即使接口變了，我們隻需要改一下邏輯，所有的腳本還是可以正常運作了。這個和編碼規範一樣，通用的東西寫在一個方法裡，友善擴充和修改。可以想象一下把restclient做成可以連跑的工具。
話又說回來這種工具也是有局限性的，它不關注頁面，目前我們市面上能夠隻提供接口或者api來賺錢的公司畢竟少數，大家還都是做産品的出身，畢竟東西是要拿出去賣錢的，沒有頁面你讓客戶看什麼？而且這種工具引進項目之後，測試人員沒有端到端的打通過産品，還是需要手工在頁面上操作，這個工具也不能發現ui和接口未對齊的地方的缺陷。
下面我們來談談時下應用最多的自動化類型工具--gui類型的自動化工具。
圖形使用者接口類型的工具，顧名思義，是從頁面直接觸發指令，完成測試人員手動執行的步驟。相當與一個不需要休息不需要拿薪水的測試人員，每天孜孜不倦的幹着重複的事情，卻沒有任何抱怨一樣。不管是我們的qtp還是公司内部自己開發的自動化工具，無非就是先尋找頁面上的id資訊或者腳本定位資訊或者xpath資訊，定位到某一個按鈕或者輸入框，點選或者輸入測試内容，送出後校驗頁面能夠給予的傳回資訊，不同的腳本傳遞不同的參數或者點選不同的按鈕，校驗最後的輸出也好，校驗頁面的錯誤提示資訊也罷，都是以工具替代人工來執行，例如我們可以編寫某個系統的門檻用例、冒煙用例的自動化腳本，在開發人員使用自動編譯工具生成最新版本的時候，我們自動擷取最新版本執行安裝，之後執行自動化腳本，在夜裡、第一時間掌握版本的實際資訊，是否能夠轉測試成功，是否存在主幹流程上不通的情況，如果附帶錄像回放工具，那這個工具還能幫助開發人員還原當時錯誤的情況讓開發人員“穿越”到之前的情況檢視頁面出現的bug，一舉多得。
既然這種工具這麼好，那我們趕緊開展哦~~~
再者這個工具有一個弱點，分析不了邏輯，如果一個頁面需要邏輯展示或者時下最流行的圖形操作，這個自動化真是鞭長莫及，這個分析能夠根本不能勝任的，測試人員你還是老老實實的自己構造條件手工測試吧！
看到了吧，過分依賴頁面的自動化工具的下場了吧。
測試，你做好設計準備了嗎？
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/
![Winrunner的一些技巧[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)