做死的自動化測試

儘管如今已經再也不作自動化測試了，可是對自動化測試仍是保持一直保持關注的。就像是儘管跟女神相隔兩地，無緣一睹真容，但仍是悄悄關注她的微博，默默的在朋友圈中刷出關於她的點點滴滴。

從業不少年了，作過不少項目，有成功有失敗，可是自動化測試項目的失敗率無疑是最高的。長此以往，便漸漸可以總結出一種自動化測試做死的節奏。

節奏一：大神，幫幫忙啊，救命啊，總是搞不定啊

這句話我常常看到，通常來講有時間的話，我會教你怎麼去解決這個問題。不過幾天后，相似的問題出現了，你仍是解決不了。

首先，大神很忙。有些大神願意分享，他們貢獻的資料不少，可是，你不查，你不看，你老是認爲"不恥上問"最直接，但大神幫你解決問題的同時又增長了你的惰性和依賴性，結果你進步的很慢，一直沒有自信，後來問題太多，直接放棄。

遇到問題不要懼怕，去網上搜一下，不少人會遇到一樣的問題，大概看一下別人怎麼解決的，而後本身觸類旁通，不只解決了問題，並且還能有所進步，這纔是正道。

後來有人問我問題，我通常的回答是"去網上搜一下XXXX"，不是我不肯意幫你，我是在教你，不管作什麼事，最後你只能靠本身。

通常遇到這種節奏的人學習能力恐怕是不強的，若是自動化測試交給這些人來作，那麼做死是能夠預期的到的。

提升本身的學習能力與糾錯能力，遇事不慌，有一套比較好的解決問題的方法，堅持下去，慢慢的改進，慢慢的提高本身，這樣就能夠了。

節奏二：我看了，這些代碼我都看過了，可是這個項目到底怎麼作啊

這是典型的光說不練。我有一本書叫作webdriver實用指南,裏面有不少代碼，涵蓋了ruby/python/java/watir-webdriver等。有人一再問我書裏面提到的問題，個人回答老是："這些代碼你敲過了嗎?"，答曰:"沒，可是我有看過了"。對此我只能啼笑皆非，看過不等於作過，自動化測試項目說白了就是代碼實踐，光看不寫是學不會堆代碼的。所以，在作項目的時候，必定要多作，別隻是在收集別人的意見，好比"你以爲我這個項目適合作自動化嗎？", "我應該用什麼工具作自動化啊？"，別人老是旁觀者，只有你親自實驗得出的結果纔是準確的，不要把別人的意見看成聖旨箴言，本身實踐纔是第一要務。

對於自動化測試，個人理解是先把代碼敲熟練了。若是一個工具或者代碼不能掌握到駕輕就熟的程度，那麼作起項目來應該是困難重重的。還有，本身多寫代碼，多去理解錯誤提示，不少問題你本身就能頓悟了，不要遇到一點點小問題就去問別人，別人不但不會幫你，也許內心還會鄙視你，真的，我之前就被鄙視過。

看過不等於作過，這點很重要。就算你看過島國全部一線女優的片子，但若是沒作過的話，你仍然只是個可憐的處男，連逆襲的機會都沒有。

節奏三：大神，爲何出錯了啊

這是太言簡意賅了。我很想幫你，可是在幫你以前我會先問一串:"你用的是什麼工具，什麼操做系統，什麼編程語言之類"，固然了，這是在我心情好的時候，有時候心情不爽，直接拉黑，整個世界就清靜了。提問是有藝術的，把問題描述清楚，別人纔好去幫你，否則沒人會理你。而後你感到本身被忽略了，而後你傷心了，而後你吐槽了，而後你無力吐槽了，最後你放棄了。同樣的做死的節奏。其實，只要你把問題描述清楚，而後去網上搜索一下，基本就能獲得答案。記住，google是你最好的朋友，大神不是。

節奏四：我只要會xxx語言就能夠了，其餘的語言不須要

理論上這是正確的，可是語言說白了仍是工具，在作一件很復瑣事情的時候，單一的工具每每是難以很好的完成任務的。任何語言都有其擅長的部分，不擅長的地方，取長補短纔是王道。我用過不少的語言，可是在作前端UI自動化的時候，我發現ruby+watir webdriver很方便，因而一直用，項目一直在作，幾年了都沒失敗。但若是當年用的是java的話，我估計咱們的產品在改版幾回之後，這個自動化項目就要壽終正寢了。多學一點語言其實沒壞處，不過若是你選擇專一，那麼你有你的道理，你能夠堅持，沒人會責怪你。

說了這麼多做死的節奏，如今就稍微總結一下自動化應該怎麼作。

原則一：能力使然

這個能力是指的綜合能力。首先你要會測試，自動化測試畢竟是在用代碼寫用例。其次你要會寫代碼，你要把用例翻譯成代碼。不要迷信於錄製回放工具，光用這個基本上作不成項目。並且會錄製回放對你來講也沒什麼意義，任何一我的學習個一天必定能學會錄製回放。作自動化測試其實是對自身能力一個很好的提高，必定要抓住這個機會，不要去弄沒啥技術含量的錄製回放，學會了有什麼用，你們都會錄，憑什麼讓你錄。

作自動化測試其實挺難的，會有不少困難，畢竟前端UI的東西是最容易變化的，可是若是你能力足夠強大的話，這些變量對你來講總會有辦法去克服。好比UI總是變，就能夠封裝一些page object的思想，讓UI修改變得容易一些。還有用例總是跑出錯，不如在代碼里加入自動截圖，一眼就能定位問題，代碼維護起來天然就容易很多。

沒有一個成功的自動化項目是菜鳥作成功的，當你作成功了一個項目之後，你天然就從菜鳥變成了高手。

原則二：不變應萬變

UI老是在變，比孫悟空還會變。可是在變的過程當中必定有一些東西是不變的，咱們作自動化測試的時候要儘可能用這些不變的東西。好比表單元素的name，通常不會頻繁變更，相對穩定。另外數據是會變的，好比你進入一個工單的列表頁面，有時候會有10條數據，有時候會有20條。有時候第一條數據的內容是A，有時候是B，這是由於數據在變化，這時候你只要讓數據能固定住，這樣進入工單列表後必定只有10條數據，第一條數據永遠是A，那麼你的用例寫起來天然是神清氣爽，難度不高，也容易維護。

原則三：團結一切可團結的力量

對我來講，不少時候我老是一我的在戰鬥。開發努力改一個迭代，改出若干新功能和若干bug，而後我更新對應的自動化用例。由於個人框架擴展性還不錯，因此開發改兩週的UI，我兩天就能改完，不過若是總是我一我的在改，那麼我必定會很是孤獨吧。這時候不如讓手工測試人員幫我一塊兒改，對他們來講自動化是福音，能節約其迴歸的時間，因此改用例對他們來講是頗有必要的一件事情，而後我教他們怎麼改，他們學會了之後我就能夠放手去作其餘事情。如今我已經基本不作自動化了，緣由就在這裏，有人幫我作，並且比我更有動力去作。

原則四：把成果展現出來

我專門寫了個報告平臺來展現自動化的測試報告。必定要讓團隊成員知道你在幹什麼，報告是最簡單的途徑。成功的項目必定有很不錯的報告，這點無可置疑。

原則五：可維護的代碼

代碼要容易讀，容易改。看看我寫的lazyman框架裏的示例代碼吧，再看看原生的webdriver代碼，你應該會有所感觸。記住，原生的webdriver代碼必定是不太好維護的，沒有框架支持和封裝，原生的webdriver代碼通常很難規模化，很難達到成百上千個用例的規模。好的框架可使你事半功倍，不要迷戀原生代碼，能夠用，但不夠用。

最後再來點Q&A

自動化用例從哪裏來？

從手工用例中來，擇其善者而從之，不善者而改之，僅此而已。

自動化用例要測到多細？

這要看你有多少時間和人力。時間多人手夠就細一點，否則就粗放一點，保證能節約迴歸成本就好。

個人項目總是在改UI，是否是不適合自動化？

這要看你有多少時間和人力。時間多人手夠的話開發改，你也改，反正改用例的工做量必定小於開發的工做量，只要你能改的過來，自動化就能夠作。

個人項目裏面那些元素沒有id和name，怎麼去定位啊？

本身加id和name，若是你連修改html的代碼權限都沒有，那麼恭喜你，你的自動化項目作起來很難很難。

我是初學者，用什麼語言和工具啊？

watir-webdriver