軟件開發的過程是一個持續集成和改進的過程，而每一次的改進都可能引進新bug,因此當軟件的一部，或者全部修改時，都需要對軟件產品重新進行測試。
其目的是要驗證修改后的產品是符合需求的，而當沒有自動化測試代碼時，往往會由於各種各樣的原因，回歸不充分，導致bug遺漏。
自動化測試模型
一個自動化測試框架就是一個集成體系，在這一體系中包含測試功能的函數庫、測試數據源、測試對象識別標准，以及種可重用的模塊。
自動化測試框架在發展的過程中，不斷有新的模型（概念）被提出，目前經歷了幾個階段:模塊驅動測試、數據驅動測試、對象驅動測試。
自動化測試模型是自動化測試架構的基礎。
線性測試
通過錄制或編寫腳本，一個腳本完成一個場景（一組完整功能操作） ，通過對腳本的回放來進行自動化測試；
優勢就是每一個腳本都是獨立的，任何一個腳本文件拿出來就能單獨運行；
缺點也很明顯，用例的開發與維護成本很高；
這種模式下數據和腳本是混在一起的，如果數據發生變也需要對腳本進行修改。這種模式下的腳本沒有可重復使用的概念；
模塊化與類庫
把腳本中重復使用的部分代碼獨立出來，形成公共的模塊或庫，需要的時候進行調用；
優點：提高了開發效率，不用重復的編寫相同的腳本；方便了代碼的維護，代碼的更改限制在模塊之內；
數據驅動
數據的改變（更新）驅動測試自動化的執行，從而引起測試結果的改變；
可以直白地理解成“輸入數據的不同從而引起輸出結果的變化”；
優點是實現了數據與腳本的分離（參數化），增強的腳本的復用性；
在開發層面，易於實現；
關鍵字驅動
理解了數據驅動，無非是把“數據”換成“關鍵字”，通過關鍵字的改變引起測試結果的改變；
獨立以編程方式實現關鍵字驅動似乎不太容易，一般是利用現有工具和框架；
在QTP、robot framework 等此類型的測試工具中， “填表格”式的關鍵字驅動封裝了很多底層的東西，易用性強；
測試人員只要考慮三個問題：要做什么？ 對誰做？怎么做？
自動化測試用例
| 自動化測試用例 | 手工測試用例 |
|---|---|
| 執行對象是腳本，任何一個判斷都需要編碼定義。 | 較好的異常處理能力，能通過人為的邏輯判斷校驗當前步驟的功能實現正確與否 |
| 用例步驟之間關聯性強。 | 人工執行用例具有一定的步驟跳躍性。 |
| 主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重復的工作中解脫出來。 | 人工測試步步跟蹤，能夠細致的定位問題。 |
| 主要定位在冒煙測試和回歸測試 | 主要用來發現功能缺陷 |
自動化測試替代不了手工測試，目的僅僅在於讓測試人員從繁瑣重復的機械式測試過程解脫出來，把時間和精力突入到更有價值的地方，從而挖掘更多的產品缺陷。
- 冒煙測試執行的是主體功能點的用例。
- 回歸測試執行全部或部分的測試用例。
自動化測試用例設計
一些注意事項：
- 不是所有的手工用例都要轉為自動化測試用例。
- 考慮到腳本開發的成本，不要選擇流程太復雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現腳本。
- 選擇的用例最好可以構建成場景。例如一個功能模塊，分 n 個用例，這 n 個用例使用同一個場景。這樣的好處在於方便構建關鍵字測試模型。
- 選擇的用例可以帶有目的性，例如這部分用例是用例做冒煙測試，那部分是回歸測試等，當然會存在重疊的關系。如果當前用例不能滿足需求，那么唯有修改用例來適應腳本和需求。
- 選取的用例可以是你認為是重復執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用回歸測試。
- 選取的用例可以是主體流程，這部分適用冒煙測試。
- 自動化測試也可以用來做配置檢查，數據庫檢查。這些可能超越了手工用例，但是也算用例拓展的一部分。項目負責人可以有選擇地增加。
- 如果平時在手工測試時，需要構造一些復雜數據，或重復一些簡單機械式動作，告訴自動化腳本，讓他來幫你。或許你的效率因此又提高了
一些原則：
- 一個腳本是一個完整的場景
- 一個腳本只驗證一個功能點
- 遵循用戶正常使用原則編寫腳本，盡量只做功能中正向邏輯的驗證。不要考慮太多逆向邏輯的驗證（逆向邏輯的情況會很多，需要編寫大量的腳本，而且非正常的邏輯難以被自動化腳本所驗證）
- 在整個腳本中只對驗證點進行驗證，不要對整個腳本每一步都做驗證。
- 如果對數據進行了修改，需要對數據進行還原。
- 腳本之間不產生關聯性，也就是說編寫的每一個腳本都是獨立的，不能依賴或影響其他腳本。
軟件過程自動化
- 構建自動化：自動化從各個模塊的源碼構建組裝成一個完整的產品
- 測試自動化：構建前自動完成相應的測試工作
- 部署自動化：對於通過測試的構建好的產品，做好成品測試后，自動化部署到生產服務器
- 自動化場合選取：盡量對穩定的對象做自動化，如API接口；GUI不建議使用自動化，投資回報比太低，變更大
- 自動化比例：基於穩定的測試環境和測試計划；在效率和質量上尋求平衡點
自動化測試的實施
適合做自動化測試的項目
-
軟件需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。
如果軟件需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本。
而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那么自動化測試便是失敗的。
項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。 -
項目周期較長
自動化測試需求的確定、框架的設計、腳本的編寫與調試，這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。
如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么自動化測試便成為笑談。 -
自動化測試腳本可重復使用
所測試的項目之間是否很大的差異性（如C/S系統和B/S系統的差異）；
所選擇的測試工具是否適應這種差異；
測試人員是否有能力開發出適應這種差異的自動化測試框架。
不同階段對應的自動化測試
-
單元測試
關注代碼的實現邏輯，例如一個if 分支或一個for循環的實現；
利用相應的單元測試框架，幾乎所有的主流語言，都會有其對應的單元測試框架。 -
集成、接口測試
關注函數、類（方法）所提供的接口是否可靠。 -
UI層的功能測試
通過相應的自動化測試工具來模擬UI層的功能測試，從而解放重復的勞動。
自動化測試應該側重於單元測試與接口測試。然后有選擇有必要地通過自動化方式“部分解放”UI層的重復勞動。
三種測試的比例要根據實際的項目需求來划分。
以google為例，70%的投入為單元測試，20%為集成、接口測試，10% 為UI層的自動化測試（《google 測試之道》）。