不是所有的項目都需要作為自動化測試項目，有時候手工測試可能比自動化測試反而簡單，有些時候因為技術或者環境等因素，某些功能也無法實現自動化。

通常適合于軟件測試自動化的場合：

與手工測試相比，測試自動化的優勢是明顯的。首先自動化測試可以提高測試效率，使測試人員更加專注于新的測試模塊的建立和開發，從而提高測試覆蓋率;其次，自動化測試更便于測試資產的數字化管理，使得測試資產在整個測試生命周期內可以得到復用，這個特點在功能測試和回歸測試中尤其具有意義。

通過流程圖可以看到，自動化測試流程圖和手工測試流程在測試用例編寫前基本一致，不同之處是，測試用例輸出完成后是腳本開發者開始編寫腳本，腳本編寫完成后執行自動化測試。

在對一個項目開展自動化測試以前，需要對軟件需求進行分析，以觀察其是否適合使用自動化測試。對于適合自動化測試的項目或者模塊開展自動化測試，對于不適合的應該及時提出。

可以開展自動化測試，通常需要同時滿足以下條件：

1、需求的穩定性決定了自動化腳本的維護成本。

如果軟件需求變動過于頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試框架，如果所花費的成本不低于利用其節省的測試成本，那么使用自動化測試將沒有任何意義。

項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。

自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么將沒有必要引入自動化測試，手工測試完全可以勝任。

2、根據項目時間安排，制定自動化腳本的交付時間和交付范圍。

在展開自動化測試之前，最好做個測試計劃，明確測試對象、測試目的、測試的項目內容、測試的方法、測試的進度要求，并確保測試所需的人力、硬件等資源都準備充分。制定好測試計劃后，下發給測試組內人員，測試組內人員根據計劃完成各自分配的任務。

自動化用例的設計和手工用例的設計一致，絕大多數情況并沒有單獨區分，而是統一由用例設計者設計出來，手工測試執行用例的過程中，自動化人員編寫測試腳本。自動化用例的設計在實際項目中，一般分為兩種情況：

1）通常情況下這類的企業已經有成熟的用例，需要招聘自動化編碼人員將已有的用例，實現自動化。這類的公司的自動化人員只需要根據已有的用例實現自動化即可。

2）有些公司對于測試的質量尤其看重，這個時候往往需要一個經驗豐富且對需求非常熟悉的測試人員來專門負責測試用例的編寫，以防止設計漏測的發生。這種情況大多是對于已有的用例進行修改和補充，方便自動化腳本適配。

這種情況一般是由于公司里面的測試不多。每個人都分配任務，這個時候需要自動化測試人員根據所分配的任務設計用例，同時還可能負擔起手工測試，以及用例編寫者和用例執行者的身份。

腳本的編寫和命名要符合管理規范，以便統一管理和維護。腳本編寫好了之后，需要反復執行，不斷調試，直到運行正常為止。調試的期間也有可能發現產品質量問題，這個時候需要提單跟蹤。

腳本的質量會影響到整個自動化執行的效率以及質量，更是影響到后期的維護成本，每一個自動化腳本在誕生后，都會在后續的版本上持續運行，如果某個腳本存在質量問題，那么就意味著這個腳本所檢測的測試點，會被一直漏測。

在后續通過腳本的備注，就可以方便的知道腳本里面的寫的是那條用例，和用例的詳細信息。

第一個好處是：一眼就可以看出腳本的創建人創建時間，修改人修改時間，方便找人定位問題。

第二個好處是：后續腳本出現問題，責任劃分明確。

腳本的檢測點太多，會導致兩個問題。其一，腳本篇幅太長，不利于后期維護。其二，檢測點過多，不利于問題定位。

如果在編寫腳本的時候沒有對腳本修改或者創建的內容進行復原，很可能會對之后運行的腳本產生影響。

在腳本開發人員編寫好腳本后，不應在直接交付腳本參與測試，而是應該組織組內專家，對腳本進行檢視。確認腳本無問題后，才可參與測試。

自動化測試的執行并不依賴人員，任何時候都可以執行自動化測試。但不是任何時候都適合執行自動化腳本。

一般情況下都是在設備空閑的時候運行自動化測腳本，因為不同的腳本之間會產生影響，如果同時運行多個腳本，或者在運行腳本的同時有其余人員在使用設備，那么會引發難以定位的問題。例如：運行腳本在運行過程中需要刪除某一個數據，但是恰好在腳本運行前有人使用環境人為的刪除了腳本要刪除的數據，那么腳本就會出錯，如果不看產品的運行日志，或者說日志記錄不清楚，那么很可能被當成一個“bug”來處理。但是這個“bug”并非一個真正的bug，沒有辦法定位和修改，最后會被當成一個無法復現的問題。這期間既浪費了開發的人力也浪費了測試的人力。

自動化執行人員和腳本編寫人員可以不是同一個人，在實際項目中，很可能是某一個人運行產品的所有自動化腳本。如果腳本運行失敗，運行人員需要大致對腳本失敗原因進行分析：如果是產品問題，需要提單跟蹤；如果是腳本問題，那么可以找對應的腳本開發人員進行修改；如果是環境問題，那么就修復環境。

應該及時分析自動化測試結果，如果沒有專人執行自動化測試，建議測試人員每天抽出一定時間，對自動化測試結果進行分析，以便盡早地發現缺陷。如果有專人負責自動化測試，可以交給專人完成。

理想情況下，自動化測試案例運行失敗后，自動化測試平臺會自動大致判斷一下是什么缺陷，然后對于缺陷進行一個初步的分類（腳本問題？環境問題？產品問題？）。如果是產品問題，就會自動上報一個缺陷。測試人員任然需要，確認這些自動上報的缺陷，是否是真實的系統缺陷。如果是產品缺陷就提交開發人員修復，如果不是系統缺陷，就檢查自動化測試腳本或者測試環境；如果是環境問題，需要去環境上面確認；如果是腳本問題，腳本開發人員修改腳本。

測試記錄的BUG要記錄到缺陷管理工具中去，以便定期跟蹤處理。開發人員修復后，需要對此問題執行回歸測試，就是重復執行一次該問題對應的較薄的地方，執行通過則關閉，否則繼續修改。自動化測試回歸相對于手工測試回歸方便很多，只需要將失敗的用例和開發修改點相關的用例運行一遍即可。

如果問題的修改方案與客戶達成一致，但與原來的需求有所偏離，那么在回歸測試前，還需要對腳本進行必要的修改和調試。

在自動化腳本運行完成后，測試組長需要對測試的所有結果進行分析，分析結果一般以數據為主。例如：一共執行了多少條自動化用例，覆蓋了哪些功能模塊，用例通過百分比，沒有通過的腳本有多少是產品問題，是否所有的產品問題都已經提單跟蹤。

通過對于腳本的分析，大概了解項目的運行情況，可以及時調整人員安排和計劃的制定。

很多自動化腳本不可能寫了之后一運行就是好幾年，永遠不會變化。

一般情況產品的需求都可能發生變化，需求發生變化用例和腳本也會隨之發生變化。這樣就需要自動化腳本編寫者新增腳本，或者對于不適用的腳本及時的進行剔除或者修改。

不只是需求會發生變化腳本才會變化，可能在運行腳本的時候發現腳本穩定性、可靠性不好等因素，導致某些腳本有時候運行成功，有時候運行不成功。這樣也需要腳本開發者對腳本進行加固處理。

推薦閱讀：

如何設計自動化測試方案？自動化測試主要適用于哪些測試階段或過程？

自動化測試用例如何編寫?自動化測試用例選型原則

自動化測試工具的基本要求 軟件自動化測試工具分類有哪些？

自動化測試生命周期的6個階段

自動化測試工具有哪些？好用的自動化測試工具推薦