一、自動化測試的好處

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、自動化測試結束後生成測試報告，將測試結果傳送郵件給相關的人員。

在持續整合中任何一步失敗都會導致整個測試失敗，自動化測試生成失敗的測試報告，並將測試結果傳送給相關的人員。