其實自動化測試很好理解，由兩部分組成，“自動化”和“測試”，所以我們要理解自動化測試，就必須理解“自動化”和“測試”，只有理解了這些概念，才能更輕鬆的做好的自動化測試。其中“自動化”可以想象成通過各種程式設計技術實現程式對被測系統可操控的行為，重點在於對“測試”的理解。
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，工具只是實現的手段而已。因此，想要測試得更好，應該加強的是設計用例的能力。