首先感謝公司，只來了一年，我接觸了兩種自動化工具，一種是測試接口的，一種是直接從GUI下發的。翻開目前存在的測試資料，能夠被企業級應用的自動化工具類型也無非就這兩種方式，深入接觸了之后，覺得兩種方式各有千秋，也各自能夠完成自己的使命。當然了，這兩種工具公司內部開發，也只能在內部平臺上使用。不過沒什么，學習了方法和過程，就向看慣了五岳、黃山一樣。
接口測試工具：首先這種方式測試人員自己就可以編寫工具，開發人員有一套編碼規范，在設計階段就會提供北向或者南向接口，每個迭代會發布接口屬性列表，告訴前端頁面開發，我們的這個怎么調用。一般項目比較大一點時，前期都是需要先將后臺穩定，過兩個迭代才將頁面集成進來。可是在沒有頁面的情況下，測試人員不能根據手工測試，需要自己給接口傳參數來測試結果。測試人員在用例撰寫完成后，就需要編寫腳本了，因為在沒有頁面的情況下，我們的測試執行就全靠它了。
簡單的舉下例子，我們的增刪改查對象基本上是每個系統都會有的。那么我們如何去測試這個接口？其實我們在寫自動化腳本的時候需要考慮的東西很多，不過核心的只有那么幾點，一是要穩定，二是要可重用。我們的腳本和代碼一樣，我們在寫增加對象的時候需要編寫一個邏輯，邏輯中調用開發提供的接口，參數值在我們寫具體用例時給予傳入，例如邊界值等等。整個增加功能我們只需要一個邏輯就可以搞定，節省了時間，腳本還不容易出錯，后期即使接口變了，我們只需要改一下邏輯，所有的腳本還是可以正常運行了。這個和編碼規范一樣，通用的東西寫在一個方法里，方便擴展和修改。可以想象一下把restclient做成可以連跑的工具。
下面簡單談談這種接口測試的適用范圍和優勢，接口測試更好的適應在中間件開發團隊以及更頁面弱相關的項目中，首先我們不需要關心頁面實現是個什么樣子，我們只提供接口，我們關心的接口能否正確的接納信息并給予正確的返回，其實我們現在還沒有頁面來調用我們，連我們自己都不知道頁面長什么樣子，但是我們要保證頁面集成之后我們的接口是沒有問題的。對于測試人員的角度來看，這種工具有很多好處，一是邏輯抽象化容易，其基本上和寫單元測試用例類型，只不過測試對象不是一個函數或者類，是一個功能點罷了，二是這種工具寫好的腳本穩定性很高，不受頁面變化的影響，后臺接口的變更頻率比前端頁面小的多。
話又說回來這種工具也是有局限性的，它不關注頁面，目前我們市面上能夠只提供接口或者API來賺錢的公司畢竟少數，大家還都是做產品的出身，畢竟東西是要拿出去賣錢的，沒有頁面你讓客戶看什么？而且這種工具引進項目之后，測試人員沒有端到端的打通過產品，還是需要手工在頁面上操作，這個工具也不能發現UI和接口未對齊的地方的缺陷。
那么下面的一種工具就能夠滿足要求了，那就是GUI的自動化工具，它能直接模擬測試人員觸發功能按鈕，端到端的測試交付的功能，我們常見的QTP也是屬于這一類的。不過這種自動化工具也是有其長處和短處的，具體如何取舍呢？
下面我們來談談時下應用最多的自動化類型工具--GUI類型的自動化工具。
圖形用戶接口類型的工具，顧名思義，是從頁面直接觸發命令，完成測試人員手動執行的步驟。相當與一個不需要休息不需要拿薪水的測試人員，每天孜孜不倦的干著重復的事情，卻沒有任何抱怨一樣。不管是我們的QTP還是公司內部自己開發的自動化工具，無非就是先尋找頁面上的ID信息或者腳本定位信息或者XPath信息，定位到某一個按鈕或者輸入框，點擊或者輸入測試內容，提交后校驗頁面能夠給予的返回信息，不同的腳本傳遞不同的參數或者點擊不同的按鈕，校驗最后的輸出也好，校驗頁面的錯誤提示信息也罷，都是以工具替代人工來執行，例如我們可以編寫某個系統的門檻用例、冒煙用例的自動化腳本，在開發人員使用自動編譯工具生成最新版本的時候，我們自動獲取最新版本執行安裝，之后執行自動化腳本，在夜里、第一時間掌握版本的實際信息，是否能夠轉測試成功，是否存在主干流程上不通的情況，如果附帶錄像回放工具，那這個工具還能幫助開發人員還原當時錯誤的情況讓開發人員“穿越”到之前的情況查看頁面出現的BUG，一舉多得。
既然這種工具這么好，那我們趕緊開展哦~~~
熟練的測試人員都知道這種工具有個很不好的弱點。這種工具過分依賴頁面，可以說頁面一旦有個風吹草動這個工具生成的腳本就需要更改；一般情況下展開測試自動化都是在項目的后期，基本功能已經無大礙，連續測試過幾輪都沒有問題，頁面也漸漸趨于穩定。所以，采用這種形式的自動化時，測試人員需要做的首件事情就是和開發的SE確定頁面和頁面控件的ID。其實這些東西我就在這里說說，這個東西實現起來，推動起來是多么難最后還是要修改，被這個腳本折騰吃過苦頭的事還歷歷在目。其實項目開始的時候，領導一聲令下要使用GUI工具自動化時就想到這一點，結果就是迭代一推動到迭代二，在推到迭代四，一直到最后要自動化了，下了最后通牒時才給出一個結果。不是開發的SE故意敷衍你，就算迭代一他費好大的勁搞好了又能怎么樣呢？眾所周知頁面這個東西，都是仁者見仁智者見智，更不用資料和UCD的那一幫子整天覺得這個不爽那個不順眼的，我不是詆毀他們哈，只是覺得頁面這個東西，定的太死后面吃虧的是我們自己，包括測試和開發。即便如此，我們實現了自動化，還是給修改帶來了很大的工作量。很難保證開發在某一個迭代頁面沒有動一點東西，只能祈求不要動主干或者不要添加什么ID或者打亂原來的XPath（有些東西開發是沒辦法給出ID的）。
再者這個工具有一個弱點，分析不了邏輯，如果一個頁面需要邏輯展示或者時下最流行的圖形操作，這個自動化真是鞭長莫及，這個分析能夠根本不能勝任的，測試人員你還是老老實實的自己構造條件手工測試吧！
看到了吧，過分依賴頁面的自動化工具的下場了吧。
但是我們不能因噎廢食，自動化工具如果不能提高我們的測試效率，那我們憑什么花那么大力氣去定規范和寫腳本？自動化工具，不管是接口的還是GUI的，其能夠存在都是有其道理的。一般情況下接口是不會隨便動的開發人員也害怕領導找他的麻煩，改動接口還得聯調，又是一個大工作量，所有接口自動化工具生成的腳本穩定，可執行程度高，基本不會出錯，如果里面存在缺陷可以很大程度上能夠校驗出來，缺點是不能結合頁面不知道最后集成后會有什么問題；GUI類型的工具強大的地方在端到端的驗證，能夠像人一樣操作被測系統，給測試人員最好的結論，缺點就是維護成本高，易變更（這一點高手測試人員可以盡量減少）。此處比較羅列，想讓使用自動化的項目組有個參考，看哪一點舍棄損失最少或者采用哪種收益和成本最大。其實說了這么多，其實自動化工具再好也替代不了人，自動化腳本跑動的腳本依賴用例，用例設計依賴測試人員，用例才是測試根本！
測試，你做好設計準備了嗎？