其實自動化測試很好理解，由兩部分組成，“自動化”和“測試”，所以我們要理解自動化測試，就必須理解“自動化”和“測試”，只有理解了這些概念，才能更輕松的做好的自動化測試。其中“自動化”可以想象成通過各種編程技術實現程序對被測系統可操控的行為，重點在於對“測試”的理解。
1.1 關於測試的理解
所以首先作為一個測試人員，先應該思考測試的本質是什么？
大多數從事自動化測試的人都是從手工測試轉型過來的，所以對於測試都不會太陌生，那么對於測試工作我們可以簡單的認為兩種情況：
1,驗證被測系統是正確的（即程序按照預期運行，認為做了正確的事情）
2,尋找錯誤（即程序沒有做錯誤的事情）
我們知道大概所有的測試用例都是按照情況1在編寫測試用例，執行，而同樣在做着情況2的事情，其中驗證正確比較簡單，只需要將實際結果和預期結果做比較，
一般只有一件正確的事會發生就只需要驗證這件事發生了即可,而尋找錯誤就比較困難,因為太多不可預知或者偶然性的錯誤會發生。
所以測試最終的結果就是期望結果，我們可以嘗試回顧一下我們平時的日常工作流程
1．分到任務拿到需求,開始理解需求,那么分析需求的目的是什么？
2．學習並了解相關業務知識與工作流程，那么搞清業務流程的目的是什么？
3．當上面的工作完成后，開始設計並編寫測試用例，那么設計測試用例的目的是什么？
4．開發完成后開始執行測試用例，那么判斷測試用例fail/pass的標准是什么？
所以最后的我們測試目的就是：找出期望結果與實際結果不符的場景
如果理解了這個概念，那么單純從技術角度上來說，我們的測試要做的最重要的工作就是搞清楚一個軟件的功能塊的期望結果是什么，
不管用什么方法(UI/API/UT自動化 等等)，只要能把期望結果理解清楚，我們的測試便成功了一大半。
1.2 關於自動化測試的理解
我對於自動化測試理解就是測試方法+測試目的(驗證結果)，並不局限你使用了什么技術或者框架，但是自動化測試要做的事情與功能測試是一致。
先來看看功能測試如何進行的：
編寫測試用例，測試用例當中最主要的是測試步驟和預期結果；測試人員根據測試用例執行操作步驟，然后通過眼睛和思考判斷實際結果與預期結果是否相等。如果相等，測試通過；如果不相等，測試失敗。
自動化測試本質就是基於功能測試的實現，自動化測試常見主要包含三個層面的自動化，單元測試自動化，接口測試自動化和UI測試自動化。當然，不同層面的自動化關注點是不一樣的。
單元測試自動化，調用被測試的類或方法，根據類或方法的參數，傳入相應的數據。然后，得到一個返回結果。最終斷言返回的結果是否等於預期結果。如果相等，測試通過；如果不相等，測試失敗。所以，這里單元測試關注的是代碼的實現與邏輯。當然根據不同的測試系統或者軟件架構單元測試方法以及技術都不一樣，比如我曾經經歷過前端js/后台springmvc/oracle數據庫層不同層面的單元測試工作
接口測試自動化，根據接口文檔，到底是傳get請求呢？還是post請呢？調用被測試的接口，構造相應的數據（id=1,name=zhangsan），得到返回值，是200成功，並返回查詢結果。還是500，用戶名不能為空。不管輸入的參數是怎樣的，我們都將得到一個結果。最終斷言返回的結果是否等於預期結果。如果相等，測試通過；如果不相等，測試失敗。所以，接口測試關注的是數據。只要數據正確了，功能就做成大半，剩下的無非是如何把這些數據展示在頁面上。
UI測試的自動化，這種測試更貼近用戶的行為，模擬用戶點擊了某個按鈕，向個輸入框里輸入了什么。但是用戶可以看到登錄成功了，但UI自動化並不知道它剛才的點擊有沒有生效。所以，要找“證據”，比如，登錄成功后頁面右上角會顯示“歡迎，xxx”。這就是登錄成功的有力“證據”。於是，當web自動化登錄成功后，就去獲取這個數據進行斷言。斷言如果相等，測試通過；如果不相等，測試失敗。所以，web自動化的關注點用戶操作形為，頁面上真正的按鈕和輸入框是否可用。
1.3 如何實現自動化測試
剛才提到自動化測試本質就是基於功能測試的實現，都是比較實際結果和預期結果是否相符。
其實大概可以分為三個部分：
實際結果：就是我們通過操作獲取的實際執行結果，通常所講的自動化測試的難度，大部分指就是指通過自動化獲取實際結果的難度。因為UI層更貼近用戶層，所以不管是視覺還是業務處理都相對於其他層更負責，所以往往實施起來難度驗證結果很負責，成本更高
預期結果：是我們在需求上人為定義的，很多測試員在測試時遇到需求不明確，沒有標准，其實就是不知道預期結果是什么。將預期結果轉化為機器可識別的數據也是一個難點。
結果比較：驗證測試結果是正確還是錯誤，良好的自動化測試除了需要自動化的執行，還需要包括自動化的驗證，有時候自動化的驗證比自動化操作更困難。
要實現自動化測試，就要將這三樣東西通過程序來實現，並且高效地結合起來。何謂高效地結合起來？就是預期結果和實際結果可以大量快速獲取進行比較，並且盡量少地出現人為干涉。比如我們控制一個程序能夠讀取到全部預期結果，並且執行操作獲取全部實際結果，然后可以自動比較兩者生成報告，這樣就比我們人手控制一個程序單個多次地讀取預期結果，再人手控制另一個程序單個多次地獲取實際結果，再人手控制第三個程序去單個多次地比較前兩者的結果要高效。當然，如果這些程序是統一控制，相互自動觸發的話，那效果也等同於一個程序，在實際中這種情況是很常見的。
實際過程中又可以分為UI界面交互和非UI界面交互的情況。
非UI界面交互，以接口測試為例：
1.批量的發送請求並獲取返回值，
2.批量得到預期結果並轉為機器可識別的數據，可以用xml或者excel一類的文檔來准備數據，使用工具的話可以將多個case保存為一個集合。
3.批量比較返回值和預期結果數據，將前兩步的數據都獲取到之后再用字符或者正則表達式來比較兩者，用工具的話需要選擇那些可以斷言返回值的。
4.將比較結果生成測試報告。
UI界面交互，以Web UI測試為例：
1.需要實現web操作，無論你是自己寫程序實現，還是用現有的工具，都是將動作、對象、數值組織起來完成一個web操作。比如登入網站，分3個步驟，（1）輸入用戶名，（2）輸入密碼，（3）點擊登入按鈕，
2. web操作之后，我們就可以獲取到相關的實際結果，例如登入成功的提示，或者登入后的網頁內容，我們就需要通過程序去獲取回來，准備之后的比較。
3.通過實際結果與預期結果判斷，使用斷言來判別執行失敗或者通過。
總結, 如果想用自動化測試去發現錯誤，首先就必須由人去預想可能出現錯誤的各種情況，然后用自動化去檢查。這樣其實就不是用自動化去發現錯誤了，而是由人去尋找錯誤（或者錯誤的可能性），然后用自動化去驗證。偏偏試圖通過自動化去發現錯誤是很多人開展自動化的最初目的，於是就導致了自動化的高代價，投入了人工（預測錯誤，設計用例，編寫腳本），但自動化的成果只能局限在人工能夠預測到的范圍之內。所以我們可以看到很多案例，在使用了自動化測試之后，用手工測試依然可以發現大量的bug。所以，能否發現bug，最核心的東西是用例，而不是工具或方法，只有用例能夠發現bug，工具只是實現的手段而已。因此，想要測試得更好，應該加強的是設計用例的能力。