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