這是兩個很繞口的詞。而且乍一看起來好像就是同一份
工作。今兒聊聊我個人對于這兩者的認識。
舉例：
有一天，一家
手機公司要做一個UI自動化
測試，于是他們聘請了一名工程師。
這個工程師需要做的事情，首先就是setup一個
自動化測試環境。單單從這方面來說，測試工程師和自動化工程師需要做的是完全一樣的。比如搭建起來一套完整的UiAutomator環境。
之后就會有區別了。當環境搭建好以后，測試工程師的主要精力就會鋪到編寫腳本，執行測試上。而自動化工程師則會把精力放在如何優化UiAutomator環境上
比如，大家都知道UiAutomator的case編寫完成后，首先需要通過ant編譯，然后再通過adb命令進行push，最后才能執行。這一點上，一般來說測試工程師就不會做什么改變了，但是自動化工程師一定會做一個程序或者批處理或者其他的什么，讓這幾個步驟變成點一下就全干完的事情。
什么是測試自動化：
這是一種讓測試過程脫離人工的一次變革。對于控制成本，控制質量，回溯質量和減少測試周期都有積極影響的一種研發過程。
什么是自動化測試：
通過將測試執行部分部分或者全部交由機器執行的一種測試，叫做自動化測試。這種測試不需要人的實時參與。同時這種測試在小規模應用時會比手動測試昂貴許多。
自動化測試可以看作測試自動化的一部分。
不同的工程師，工作不同：
一個自動化工程師，會比較專注于測試工具的研發。最主要的是這個工程師會從成本的角度去考慮問題。這一點比較像PM。他所做的一切是為了減少自己或者團隊的工作量，盡可能的將重復的，有規律可循的工作代碼化，自動化。
一個自動化測試工程師，會比較專注于測試代碼的開發，以及測試結果的分析。對于被測設備本身非常感興趣。他們比較傾向于一種完美主義者，追求的是高質量而經常忽略成本。這一點更像開發人員。
現在絕大多數公司都會執著于自動化測試，而忽略測試自動化。這一點會讓整個AT（automation
test，下同）成本變得非常高。
我曾經
面試過一家公司的AT工程師，對方對于AT的做法就是每天都在release新的測試代碼，每天都在run不同的測試。每天都在修改之前的case。我說你這個并不是自動化測試，而是一種用代碼測試產品的手動測試。這樣的測試，經常被冠以自動化測試之名混水摸魚。
這家公司很明顯的只是將代碼
單元測試貼上了自動化的幌子。
自動化測試的幾個準則：
并不是將測試用例代碼化了，就可以稱之為自動化測試了。這是現在很多公司宣稱自己做AT的一個噱頭。
AT的代碼有很多的要求。
首先就是你的覆蓋面要夠廣。個位數case的自動化完全沒有意義。
第二就是你的case必須要能夠復用：軟件每天都在變，如果你的case要天天跟著軟件變，那你的case是完全不合格的。
第三就是測試的規模要夠大：要么時間長（case多或者是壓力測試），要么測試產品多。這樣才能體現出來自動化測試的優勢。、
測試自動化的幾個準則：
第一個就是要減少除工具研發部門外，其他所有測試部門的人力成本。這個是測試自動化追求的終極目標之一。、
第二個就是提高測試質量，不僅僅包括測試執行的質量，還包括測試的統計質量，數據回溯質量，等等等等。這些質量的提高可以幫助測試團隊修正他們的測試方法，而不是每天將精力鋪在無止境的數據收集和分析中。
第三個就是要搶出時間。某一項工作自動化后的時間，要么比人手做時間短，要么可以在非工作的16個小時中進行。通過讓電腦OT的方法來解放工程師或者項目經理。
自動化的三大入手點：
自動化的三大入手點其實和三大準則是一樣的。看哪個需求更加迫切：
1. 成本：自動化并不一定圍繞測試執行，還可以包括測試的準備，log的提取，數據分析等等。將所有的與測試有關的工作逐一列出，然后找到重復的，可以被代碼化的部分，評估現有工作成本和自動化成本，尋找到收益最大的工作塊并順序將之代碼化。
2. 質量：和成本差不多，只是在評估的時候需要評估的是該工作塊現有的質量狀況和需求質量間的差異，尋找到差異最多的那個模塊，并將所有質量差的模塊逐一進行自動化。
3. 時間：和以上兩點一樣，都需要尋找到與測試有關的所有步驟和工作塊，將其中關鍵路徑上，動作最慢，耗時最大的部分進行自動化。
版權聲明：本文出自 zeustest 的51Testing軟件測試博客：http://www.51testing.com/?15030005
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。