說說我在自動化測試中遇到的坑

這篇關于自動化測試的文章，可能和你看到的大多數自動化的文章有所不同。我不是一位專職的自動化測試工程師，沒有開發過自動化的工具或者架構，用的自動化的工具也不多，也沒有做過開發，是以我講不出那些現在很多人很看重的“很深”的東西。我也不想去講某個流行的自動化的工具要怎麼使用什麼的，我覺得這些東西并不是我的，而且也是可以很容易擷取的。

那麼在自動化這個很大的領域來說，我是什麼呢？ 我是自動化技術的使用者，要在團隊中做自動化，還是腳本的編寫者、管理者和運作者。 我想大多數測試朋友和我做的事情是一樣的把。我想在這篇文章中，給大家分享一下我這些年實踐自動化的經曆，特别是那些不是那麼成功的經曆，希望能夠給你帶來一些思考和共鳴。

我的自動化曆程

初次接觸自動化測試

初次接觸自動化測試：我發現光靠工具和熱情是做不好自動化測試的。

我是自動化測試的簇擁者。記得剛做測試那會，一聽到“自動化測試”這個概念，就覺得好神奇，當時就把“手頭的工作都自動化了”。我能把這些内容都自動化，不是我厲害，而是新員工手裡的工作不多，又很簡單，而且當時公司已經研發了一些自動化平台，我的這些自動化測試的原理就是捕捉到一個windows的視窗然後往裡面發送字元串，連測試結果都還不能做到自動檢查，還要自己去看日志或者截屏。盡管做得非常粗糙，這也極大的鼓勵了我，我每天跑着這樣的腳本樂此不疲，想象着下一步這些腳本會變得很智能。

接下來我就開始向公司的自動化測試前輩（本部門、外部門）學習，自己開始搞自動化。這時我又換了個産品，新的leader當時并不贊同做自動化（現在非常能夠了解他當時為什麼不贊成做自動化），我很沮喪，但我想公司已經有了現成的自動化測試的平台和工具了，我隻要學會了用這個工具，自己就可以寫腳本了，自動化測試不就做起來了嘛，不就是個工具嗎，能有多難呢。于是我決定加班來學習腳本語言和學習使用工具。我的進展不錯，但很快我就開始感到，自動化測試并不像我想象的那麼美：

• 一個非常簡單的功能，寫好再調通，花費的時間并不少。别人5分鐘就能做好的事情，我要花1個小時。

• 腳本執行時一旦發現問題，排查起來花費的時間也不少。一般來說跑出問題了，我會再反複跑幾次，先确認是不是真的有問題，再加各種列印或者等待來運作腳本定位問題（别笑，當時真的是這樣的）。

  我還記得當時我對這個問題，是這樣安慰自己的，沒事，自動化的優勢是展現在反複執行上的。但是很快我就發現：

• 界面、環境稍微有點變化，腳本就不能用了。這點讓我感到反複執行好像也不是那麼好使，有點崩潰。
• 由于我們的産品經常會定制，版本的分支也很多，我發現如何把這些腳本管理起來，便于在不同的測試場景下測試也是個問題。

這兩個問題讓我有些崩潰，大家都說的自動化測試反複執行是強項，為什麼到我這裡就不靈了呢。

我開始意識到， 自動化測試不是靠一個工具，然後靠一腔熱情加個班就可以完成的事情。 除了工具，如何設計函數，如何檢查腳本的運作結果，如何做版本管理等等每一件事情的工作量都不小，需要有政策有規劃，一步步的來完成。當然，如果你隻是想寫幾個腳本玩玩除外。

第二次進行自動化測試

第二次進行自動化測試：沒有做好自動化的準備，盲目追求自動化率。

第一次的自動化測試就這樣以失敗告終了。但我也成長為了一名測試基層小leader，有了些可以“做主”的小權利。我認真總結了上次的經驗，顯然問題主要出在沒有規劃和設計自動化上，我想隻要我做好了規劃，加強設計，再做一次自動化一定行，于是我決定和我的小夥伴一起，再來做一次自動化。

當時我所在的公司的做事方式是做事情必須要有個目标，要寫個承諾，年底還會拿這個承諾來考核你。是以我開始思考自動化測試的目标。我發現無論是公司内部還是公司外部，隻要說到自動化，都是說定位于回歸測試，好吧，既然大家都這樣說，那一定有大家的道理，那我的自動化目标也是定位在回歸測試自動化好了。另外既然是一個團隊都來做自動化，肯定要從簡單的地方開始入手，這樣我們的自動化的目标就變成了從簡單的回歸測試開始自動化，完成100%的回歸測試。

這個目标看起來似乎沒有任何毛病，但具體執行起來的時候，在“簡單的内容先自動化”的思想的指導下，我們做了很多測試邊界的腳本。（什麼叫測試邊界值的腳本呢。比如一個接口的配置是允許輸入（1，5），邊界值就是0，1，5，6，邊界值的腳本就是測試資料為0、1、5、6的腳本）。

由于我們的目标是要100%的回歸測試，但我們當時并沒有一個标準的回歸測試用例集。那些簡單的邊界值腳本就自然而然的都成為了回歸測試用例集。後來項目壓力壓下來，做自動化的時間變少了，為了達到自動化率的目标，我們甚至發展到把一個測試邊界的腳本，拆成多個腳本（比如上面那個例子，測試資料為0、1、5、6，本來一個腳本就可以測試完，我們卻偏要寫4個腳本），這樣，我們“很聰明”的達到了自動化測試的目标。

但這樣的自動化，我們自己都不不太想去運作，因為我們自己心裡清楚，這樣的腳本，運作不運作又有多大的意義呢。

這次經曆讓我對自動化測試有了新的思考：

• 自動化的腳本要開發哪些内容，不應該在自動化開發的時候才來決定，而應該是事先就确定好了的。換句話說，測試用例是自動化的基礎，

  有明确的測試用例才能保證自動化測試的内容符合預期目标。

• 沒有考慮項目進度會影響到自動化測試這個風險，也沒有考慮自動化實作時會不會有什麼問題或困難，就輕易承諾100%的自動化率，

  盲目追求自動化率，使得最後大家花精力開發出來的自動化腳本沒有太大的作用。

歸根到底，還是沒有做好自動化的準備。

我們在做自動化測試的時候，很容易隻是盯着自動化，僅從自動化這個方面去思考，把自動化當成了一種很進階的測試，去設計自動化的架構，組織等，卻忽 視了自動化測試的本質——自動化測試就是一種測試執行的方式。我們在手工測試時要如何準備測試執行，自動化測試的時候也需要考慮 。

第三次自動化測試

第三次自動化測試：自動化腳本的誤判。

第二次測試就這樣也算是失敗了（反正腳本幾乎是都廢了）。有了這兩次的失敗經驗，俗話說事不過三，是以我準備再來一場。

這時團隊的測試能力已經有了長足的提升，我們已經有了一些測試用例，為了做好自動化測試，我專門組織大家把需要自動化測試的用例篩選出來了。既然目标是回歸測試，用例的篩選标準也很明确，就是那些基礎的，需要手工反複執行的用例。

然後我又對這些用例逐個進行了分析，把目前的自動化測試技術暫時不能支援的用例也标記出來了，告訴大家不用擔心，這些用例可以下一次再執行，我們就算是要追求100%的回歸測試率，也是我們真正應該執行的，并且現在可以自動化測試的那些用例。

我還記得當時我們的自動化測試平台也升了次級了，平台也更穩定了，提供的功能也更多了，大家的幹勁也很足，所謂天時地利人和，我對這次的自動化測試實踐充滿信心。

很快，腳本被一批批的開發出來了，之前不能自動化的測試的用例也随着自動化測試技術的突破而變得可以自動化了，一切都在向着好的方向發展。但很快我們就發現新的問題出現了，自動化腳本結果出現了誤判！

什麼叫自動化腳本的誤判呢，就是自動化腳本在自動化平台上顯示的結果和真實的結果不一緻。比如腳本A在自動測試報告中顯示的結果為PASS，但實際的功能卻有可能有問題。在自動化測試報告中顯示的結果為失敗，但實際可能卻是受到環境的影響造成的，功能卻沒有問題。

換句話說，我們無法相信自動化測試的結果。

這真是要把人折磨死的節奏啊。

我們想了很多辦法，比如每一輪自動化測試，同一個腳本都反複執行幾次（如執行5次），然後設定一個腳本執行失敗的“容錯值”（比如設定容錯值為2，即執行5次這個腳本，腳本失敗隻要不超過2次就都算通過，OMG這個想法也真是見招拆招，見洞補洞，喪心病狂啊）。想辦法儲存所有的測試執行記錄，然後再手工再從測試記錄裡面去抽檢一定比例的測試腳本的執行結果，看抽檢的結果和腳本運作結果的差異，再以此來決定腳本出現誤判的機率（OMG，我都服了我們小組的驚人的數學功底，但這真的是完全跑偏了好嗎）…….

其實這些問題，歸根到底就是腳本的check部分寫得有問題 。

如果我們把自動化測試比作一個機器人。讓自動化測試來模拟執行某個功能并不難，這就像是機器人的手一樣。 難的是機器人的“腦子”，如何讓自動化腳本來聰明的确認腳本的執行結果就變得非常重要，這才是自動化測試真正的難點 。

希望以上内容對你有所幫助！軟體測試是IT相關行業中最容易入門的學科~不需要開發人員燒腦的邏輯思維、不需要運維人員24小時的随時待命，需要的是細心認真的态度和IT相關知識點廣度的了解，每個測試人員從入行到成為專業大牛的成長路線可劃分為：軟體測試、自動化測試、測試開發工程師 3個階段。

如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以加我們的軟體測試交流：313782132，裡面有各種軟體測試資料和技術交流。