一、自動化測試的好處
1.回歸測試，降低測試成本
對於產品型的軟件或生命周期長的項目，經常會有新功能的開發或需求的變動，對於新發布的軟件功能，大部分都和上一個版本相近或相同，這些功能如果在上一個版本之前已經實現了自動化測試，那么新發布的版本中，這部分功能就可以自動化測試實現，避免了重復測試的成本，也確保了軟件的質量。
2.提高測試效率
一些測試用例手工測試是比較繁瑣的，比如話單或協議字段的檢查，如果是人工檢查將是一件既繁瑣又耗時還容易出錯的工作，如果是自動化測試，測試就會變得輕松和容易很多。
對於檢查點很多的測試用例，如果手工執行一步都需要停下來檢查好幾個復雜的檢查點，測試的效率自然是非常低，使用自動化測試，設置好了輸入條件和預期結果，只要點擊按鈕運行一下腳本就知道了復雜的測試結果。
3．易於發現軟件的改動
自動化測試腳本可以重復執行，容易發現軟件的任何變動。比如修復了一個TR后，引起原功能的改動，執行相同的腳本，可以通過測試輕易發現問題。
4.充分利用資源
自動化測試可以不需要人在現場的情況下自動執行，發布了一個新版本的軟件后，可以在白天的上班時間進行新功能的手工測試，原有功能的自動化測試可以在晚上或周末執行，第二天上班就可以看到執行的結果。這樣充分利用時間資源，提高測試的效率，也避免了開發和測試之間的等待。
5．性能測試
在一些壓力大的性能測試中，人工是很難模擬的。在沒有引入自動化測試工具之前，為了測試並發，研發中心再加上公司的其它部門上千號人在研發經理的口令“1－、2－、3！”的號召下，大家同時按下同一個按鈕。這樣的測試，雖然是模擬了並發，但需要消耗相當大的成本，想要測試一次也不容易。
在性能測試中使用自動化測試，可以輕易模擬並發，為性能壓力測試提供了更好的方法。
6．將精力投入更有意義的測試
自動化測試減輕了很多重復的工作，我們有更多的時間去思考如何提高軟件的質量，制定詳細的測試計划，精心設計測試用例，構建更復雜的測試。對於我來說，這是自動化測試給我帶來的最大的好處。
二、自動化測試的基本原則
2.1 判斷是否適合做自動化
1、不適合做自動化測試的系統
1）系統業務邏輯和交互過於復雜
如果系統業務邏輯和交互過於復雜，要實現自動化測試的成本非常高，工具開發和腳本編寫的時間可能遠遠大於手工測試，這個系統就沒有自動化測試的必要。
2）項目周期過短
如果系統的生命周期很短（半年內），即使很容易實現自動化測試，但自動化測試的使用率只有很短的時間或很有限的次數，這樣的自動化測試也沒有必要。因為前期腳本的編寫和后期的維護都需要很多的時間，雖然自動化測試在功能測試的過程或回歸測試的過程會節省一些時間，但如果自動化測試的腳本只是很短的生命周期，自動化測試的成本就非常的高了。
3）系統需求頻繁變動
對於功能不穩定的系統，會由於這些不穩定因素導致自動化測試失敗，自動化的測試結果也就變得不可信，這類型的系統也不適合使用自動化測試。
2、適合做測試化測試的系統
適合做自動化測試的系統，通常是一些生命周期比較長的項目或產品，且系統功能實現自動化測試也較為容易，這樣的項目使用自動化測試必然可以節省很多的資源和成本。特別是一些在今后的幾年間需要不斷開發和維護的項目，需要重復的進行大量的回歸測試，如果有完善的自動化測試腳本，回歸測試就可以節省大量的時間和精力了。對於一些增量式的產品，白天手工測試新功能，晚上或周末利用自動化測試腳本回歸測試，可以達到資源使用的最優化，用很少的時間和很少的資源做很多的事情。
簡而言之，是否值得使用自動化測試，就要看它是否具有自動化測試的特點和高的投資回報率。
2.2 開始自動化測試的時機
如果是新的自動化測試工具的開發或研究，最好預留一個比較充裕的時間，時間太趕很難設計出精品。如果想在功能測試階段使用自動化測試，那么自動化測試架構的設計最好能夠與代碼實現同步，否則如果等代碼實現提交測試之后再做自動化測試工具的開發或研究，在功能測試或回歸測試的過程中就被動了很多。
關於在項目的什么階段開始自動化測試，由項目決定，對於需求相對穩定並且是基於成熟的架構上開發的系統，自動化測試腳本最好在功能測試開始之前編寫，在功能測試階段就可以使用已經編寫好的腳本做功能測試了。
但我們平時遇到的項目，有很多是需求變化比較大的，或者是一些不夠成熟的系統，這樣的系統如果在功能測試之前編寫好的腳本，很有可能不能在系統上正確運行，大多還是需要手工執行才可以測試，甚至會在功能測試完后系統跟功能測試之前的系統會有非常大的區別。對於這樣的項目，自動化測試開始得越早項目的成本就越大，最好在系統的架構或需求相對穩定后再做自動化測試。
對於一些需要錄制GUI界面的功能的自動化測試，在頁面的功能相對穩定之后再做自動化測試性價比會比較高，因為頁面是最容易變動的部分，而且任何一個控件的修改都會導致自動化工具不能識別控件，導致很多自動化測試腳本會跟着做大量的修改，增加了維護的成本。當然，因為頁面變化而引起的腳本的改動的大小，也跟自動化測試的架構和寫腳本的功力有密切的關系。
對於一些協議或接口相關的功能測試（比如：XML或socket接口等），是較為容易實現自動化測試的，封裝好底層的協議提供給自動化測試腳本調用，即使是協議會有變化，改動起來還是很簡單的，維護的成本相對較低。
總的來說，在軟件功能達到相對的穩定，沒有嚴重錯誤和邏輯錯誤后開始自動化測試，性價比是比較高的。
2.3 自動化測試的覆蓋率
自動化測試的覆蓋率是很多管理層所關心的，很多項目或產品的自動化測試目標之一就是自動化測試的覆蓋率。從管理的角度來說，100%的自動化目標只是一個從理論上可能達到的，但是實際上達到 100% 的自動化的代價是十分昂貴的。自動化測試覆蓋率越高，測試腳本的維護成本也就越大。由於對每一個構建版本的需求變化的復雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。
自動化測試的覆蓋率的大小與自動化測試的成本有着很大的聯系。自動化測試的覆蓋率為多少比較恰當，也要看被測試系統的性質和測試的階段。
在自動化測試設計的階段，可以考慮先實現冒煙測試的測試用例自動化，冒煙測試的功能一般是系統的主要功能，是自動化測試設計必須首先實現的，而且通過實現這些功能，也可以檢驗自動化測試的架構是否合理。
在功能測試的前期，自動化測試腳本的覆蓋率最好只是一些關鍵的並且是相對穩定的功能的測試自動化，用於冒煙測試或關鍵功能測試。
系統穩定后，如果系統是一個生命周期很長的系統，且測試的功能很容易實現自動化測試，這樣的系統的自動化測試覆蓋率可以考慮在80％以上。
但如果是一些時間很趕的項目，或者是一些比較難實現自動化測試的功能，也就沒有追求高的自動化測試的覆蓋率的必要。隨着測試案例的增加，維護的成本也會相應增加，特別是一些GUI的測試，自動化比率越高，維護腳本的成本也就越高。
不要追求在很短的時間實現自動化測試，也不要追求100％的自動化測試覆蓋率，積累經驗循序漸進的自動化測試，效果會更好。
三、自動化測試實現基本策略
自動化測試與軟件開發本質上是一樣的，利用自動化測試工具，經過測試需求分析，設計出自動化測試用例，從而搭建自動化測試的框架，設計與編寫自動化腳本，驗證測試腳本的正確性，最終完成自動化測試測試腳本（即主要功能為測試的應用軟件）。
3.1 測試系統需求分析
任何測試的基礎都是被測系統的功能，不管是手工的功能測試還是自動化測試或者是性能測試，都是基於系統的功能展開的。當測試項目滿足了自動化的前提條件，並確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應的測試用例、測試數據，並形成詳細的文檔，以便於自動化測試框架的建立。
很多公司都是將自動化測試和功能測試划分成兩個不同的team，自動化測試team的同事實現自動化測試工具的開發，功能測試team的同事向自動化測試team的同事提需求，自動化測試team的同事編寫代碼實現自動化測試工具的功能后提交給功能測試team的同事使用，這是當前非常常見的自動化測試的模式，畢竟每個人都有自己擅長的技能，某個人也不可能面面俱到，通過這樣的一種方式可能使自動化測試的門檻變得更低一些。自動化測試工具的開發和自動化測試的使用的確是可以由不同的角色去承擔，不過作為自動化架構設計的人員，應該是對系統的功能或需求非常熟悉，同時具有良好的設計和開發能力，才可以設計出適合測試系統的自動化測試架構，否則開發出來的自動化測試工具就只是簡單的一個工具，某種程度上會增加維護的成本。
漂亮的自動化測試架構的設計是一個漸進的過程，但這個漸進是基於對功能熟悉的基礎上，全盤考慮之后一點一點的搭建起來的。
3.2 自動化測試工具的選擇
很多測試的同行或以前的老同事都會問，你們用什么自動化測試工具？幾年前入門測試時跟着老前輩寫自動化測試工具，后來因為興趣偶爾玩一下當時流行的自動化測試工具，再到現在毫無選擇工具的余地設計自動化測試架構，越來越發覺自動化測試工具真的沒有那么的重要。工具始終是工具，思想和架構才是自動化測試的核心，同樣的工具不同的人使用會出現完全不一樣的結果，而且，不管是什么樣的自動化測試工具，原理都有異曲同工之處。所以，不需要把工具看得那么重要，而是把怎樣使用工具，怎樣利用工具為你服務放在首位。也就是你的思想位於工具之上。
但是，是不是這就意味着測試工具一點也不重要呢？當然不是，遇上不穩定或不友好的測試工具，可能會浪費大量的時間在調試工具上，也可能會出現因為工具不穩定導致測試結果的不可信任，那么自動化測試不是提高測試效率反而是阻礙了測試的進度了。
關於工具的選擇或開發，基本的原則為：1)首先，能夠滿足項目的需求，容易擴展，可以滿足系統任何重要功能的自動化測試；2)其次，友好易用，容易上手，為測試人員提供較為低的門檻；3)當然最重要的是它的穩定性，是否不需要人工干預就能穩定地批量運行所有的自動化測試腳本，並且能夠產出准確的測試報告；4)最后，還有一點就是它的性價比是否值得，免費的軟件對公司來說當然是最好：）
市場上有很多測試工具，在這些測試工具中，puretest是一個性價比很高的自動化測試工具。它容易入門，易於擴展，使用簡單，運行穩定，基本上可以滿足任何包括GUI、協議和業務邏輯的測試。
3.3 自動化測試架構設計
自動化測試架構的設計是整個自動化測試的靈魂核心，它的好壞關系到自動化測試的成敗。從系統的基本功能入手，設計自動測試架構，這是軟件測試的關鍵一步。架構的好與壞很重要，它影響到系統的擴展、維護和使用，如果想要系統容易擴展和維護，一定要多花心思在設計上。很多同行問我使用什么測試工具，我會告訴他們，用什么測試工具其實並不那么重要，不同的人使用同樣的測試工具，會做出效果完全不一樣的自動化測試，那是因為他們的架構不同，設計比工具重要得多。
怎樣的自動化測試架構才算是一個好的架構？首先是容易擴展，能夠滿足現在的功能需求，也能滿足以后需要測試的功能的需求。第二，容易維護，當業務流程、接口或頁面變動的時候，只需要做一些簡單的修改就可以實現。第三，可讀性強，別人能夠容易讀懂和接手維護。第四，容易使用，項目組的其他人想要使用的時候能夠簡單地搭建和運行。第五，有統一的編碼規范、存儲規范和編寫風格。第六，方便調試，當腳本運行出現問題的時候，可以方便跟蹤問題產生的根源。第七，結構清晰，測試用例與測試工具和代碼分離。最后，是最重要的一點，是腳本具有很高的可信性以及自動運行的穩定性。
在設計架構之前，首先要熟悉測試系統以及這個測試系統需要測試的功能有哪些類型，每種測試類型在測試架構中是否都可以滿足。在設計架構時，可以選擇覆蓋系統基本功能的smoke test測試用例來做基本的測試用例，在實現這些基本的測試用例的自動化測試過程中，對架構進行完善。基本的自動化測試框架實現之后，再回顧一下是否測試系統中需要實現自動化的測試用例，測試架構都可以滿足需求，如果不可以滿足則需要繼續做進一步的開發，如果測試架構可以滿足需求，接下來可以讓其他的同事使用，收集改進的建議對測試架構進行完善和改進。好的測試架構，是要使用的人覺得舒服。
自動化測試架構設計的時候的一些基本的策略：
1、 自動化測試腳本與自動化測試架構的代碼分離，自動化測試架構的代碼實現自動化測試的基本功能，自動化測試腳本包含業務邏輯。
2、設計清晰的腳本和配置文件的存放目錄。
3、 數據驅動
1）測試系統相關的配置、模擬器的配置等系統級的配置用系統級配置文件存放，不要把這些值寫死在腳本或代碼中，否則當測試系統的環境變化的時候相應的維護成本也會很高。
2）測試系統所使用到的一些規范定義取值，定義在配置文件中，在腳本中需要使用的時候引用變量定義，這樣即使規范定義改變了也不需要修改腳本，只要簡單的修改配置文件即可；如果外部規范定義和內部的定義取值不一樣，最好有對應的mapping定義表。
3）測試數據的數據模型如果比較復雜，最好也在配置文件中對數據模型以及字段的取值進行定義，方便在腳本中創建數據時使用。
4） 協議或Schema或話單的格式，在配置文件中定義，當協議的格式改動的時候，只需要修改配置文件即可。
5）腳本中盡量少用常量，輸入參數、腳本運行時提取的值、測試結果的對比等，都可以使用變量，避免腳本的常量寫死后引起的維護工作。
4、測試數據准備
1） 測試數據准備，有兩種類型，一類是腳本運行前事先可以准備好的數據，這種類型的數據，可以在自動化測試前自動創建好並保存到文件中提供給測試腳本使用；另一類是腳本運行時要創建的特殊數據，這些數據可以在腳本運行的過程中調用基礎腳本進行創建。
2） 公用的數據，如果在腳本運行的過程中被修改，在該腳本運行結束后需要恢復到原樣，避免因為公用數據的修改引起其它腳本運行失敗。
5、模塊化：對基礎腳本進行封裝，一些可以公用的腳本單獨封裝給其余的測試腳本調用，當公用的業務邏輯改變的時候，只需要修改基礎腳本，而不需要對所有的測試腳本進行改動。
6、 提供自動化腳本編寫模版，新寫的腳本只需要在模版的基礎上做很小的改動就可以實現功能，可以節省腳本編寫的時間和降低腳本編寫的門檻。
3.4 自動化測試腳本編寫
自動化測試腳本的編寫功力很重要，寫得好的腳本，可以減少維護的工作量。自動化測試腳本一般由測試的輸入、業務邏輯、測試輸出和測試結果驗證幾部分組成。自動化腳本的編寫，要注意全局的把握和review，不同的人會有不同的風格，稍不注意就會問題多多。在自動化腳本編寫前，給相關同事提供技術和架構的培訓，培訓的內容包括被測試系統的基本功能介紹、自動化測試工具的架構、自動化測試的配置說明、自動化測試的編寫原則、自動化腳本編寫示例等。自動化測試腳本的例子也很重要，建議在腳本編寫前對系統准備實現自動化測試的功能進行分類，由資深的自動化測試工程師根據每個分類都先寫一個例子並且review通過后作為這些功能的自動化測試腳本的編寫模板，其余的同事可以參照例子按照自動測試架構編寫規范寫腳本。
編寫腳本時應該注意腳本的可重用性和可維護性，如果腳本中充滿了硬編碼的值，這些值應該被參數化，否則腳本僅僅適用於一個測試情況，腳本還應該加入條件判斷、循環等結構，以便增強測試腳本的靈活性。
在編寫腳本的時候必然會遇到技術問題或業務問題，需要有資深的工程師或TL協助解決，並且在整體的架構上全局把握。腳本編寫完成后，需要有一個抽查Review的過程，挑幾個典型的腳本review一下，看看是否存在不足的地方，然后改進。
3.5 自動化測試腳本測試
當每一個測試用例所形成的腳本通過測試后，並不意味着執行多個甚至所有的測試用例就不會出錯。輸入數據以及測試環境的改變，都會導致測試結果受到影響甚至失敗。而如果只是一個個執行測試用例，也僅能被稱作是半自動化測試，這會極大的影響自動化測試的效率，甚至不能滿足夜間自動執行的特殊要求。
自動化測試腳本最基本的原則是測試結果可信，也就是在批處理運行這些腳本的時候，該測試通過的就測試通過，該測試失敗的就測試失敗，如果出現本應該失敗的腳本在運行的時候通過了或本應該通過的腳本在運行時失敗了，測試結果就變得不可信了，自動化測試也就失去它本應該有的意義。
因此，腳本的測試與試運行極為重要，它需要檢查多個腳本不能依計划執行的原因，並保證其得到修復。同時他也需要經過多輪的腳本試運行，以保證測試結果得一致性與精確性。
3.6 自動化測試腳本執行
自動化腳本主要有三個用途：功能測試、為手工測試做數據准備和回歸測試。在功能測試的階段，可以利用自動化測試腳本進行數據的准備，也可以利用自動化腳本進行功能測試。在項目穩定之后自動化測試的最大價值就是回歸測試。
腳本可以分為三個級別：基本流程測試腳本，用於每次出新build安裝后做smoke test；關鍵功能測試腳本，每次出新build后對所有重要功能進行回歸測試，確保改動不會對原有功能的造成影響；全面回歸測試腳本，系統經過比較大的修改或系統上線前作回歸測試。自動測試腳本在回歸測試中發揮了出色的作用，特別是系統在上線前夕，為了適應客戶的需求，功能不斷修改，對於原有的功能，自然不可能都手工測試，腳本在這個時候的意義特別大。
3.7 自動化測試持續集成
自動化測試可以做到持續集成，從編譯到測試，任何一步都可以自動化：
1、將所有的源代碼存放在服務器，持續集成任務起來后到源代碼管理服務器上進行自動編譯，對編譯的結果進行分析，並將編譯成功的軟件版本放到發布服務器；
2、將新版本的軟件下載到測試環境，並且自動安裝；
3、自動安裝成功后進行冒煙測試，如果冒煙測試成功則證明軟件的版本是可用的；
4、自動執行自動化測試腳本進行功能測試或回歸測試；
5、自動化測試結束后生成測試報告，將測試結果發送郵件給相關的人員。
在持續集成中任何一步失敗都會導致整個測試失敗，自動化測試生成失敗的測試報告，並將測試結果發送給相關的人員。