隨著網際網路技術的發展，無論哪個公司，哪個團隊都在談論自動化測試、動手實現自動化測試，從而讓測試顯得更加“高大上”。

  那麼是不是所有的業務都適合自動化？是不是自動化做的越多，效果越好呢？下面就自己一些經驗和感悟，聊聊自己的一些體會。

二、為什麼自動化測試?

1. 在測試時，你進行了新的部署、bug修復，這是你如何保證新bug沒有被引入老功能？你需要測試之前的功能。

  因而，每當有bug修復，或新功能新增時，你都要手工測試所有功能？考慮到花費、資源、時間等等因素，你這麼測試不是高效的。

因而自動化有了需求：

當你有太多回歸測試工作要做時，請自動化你的測試工作

2. 當你正在測試一款web應用時，與此同時，這個應用可能有數千使用者正在使用。

  你將如何測試這樣的web應用？你將如何使用手工方式，同時模擬這些多的使用者呢？這是一件十分困難的手工操作。

模擬眾多虛擬使用者，來測試應用的負載容量時，請將你的負載測試自動化

3. 你正在測試一款程式碼被頻繁修改的應用，雖然GUI幾乎一樣，但功能變動越多，需要的測試“維修”就越多。

當你的GUI幾乎不變，功能頻繁發生變化時，請將你的測試工作自動化。

三、關於自動化測試，有哪些風險?

  在一些不同的情況下，你可以考慮自動化測試工作。這裡我介紹自動化測試的一些風險。如果你已經下定決心要做自動化或者想要更早地採取措施，那麼請先考慮以下問題。

1. 你能找到有經驗的人力嗎?

想要自動化，你需要有一些程式設計經驗的人員。

考慮一下你的人力資源。他們有足夠的自動化測試經驗嗎？如果沒有，他們有 技術

  能力或程式設計背景來輕鬆應對新技術嗎？你打算投資建立一個好的自動化團隊嗎？如果你的答案是肯定的，那麼考慮自動化你的工作吧。

2. 自動化的初始成本非常高

  我贊同這個觀點：由於要僱用熟練的手動測試人員，因而手動測試的相關成本很高。但如果你正在考慮將自動化作為方案，請三思而後行。

自動化的初始新建成本太高，例如：自動化工具的購買，測試指令碼的培訓和維護。

  很多自動化工具使用者都會後悔做自動化。如果你花費了很高的成本，卻只得到了一些好看的測試工具和一些基本的自動化指令碼，那麼自動化的用途是什麼？

3. 如果UI不是一成不變的，不要試圖自動化

  自動化測試使用者介面前務，請必要小心。如果使用者介面正在大範圍傳送變化，那麼自動化指令碼的維護成本將會非常高。在這種情況下，基本的UI自動化就足夠了。

4. 你的應用是否足夠穩定，可以支援你的自動化測試工作?

  在早期的開發週期中自動化測試工作將是一個壞主意（除非它處在一個敏捷的環境）。 在這種情況下，指令碼的維護成本將非常高。

5. 你正在考慮100%自動化?

  別異想天開了，你不可能100%將測試工作自動化。當然，有一些領域，如效能測試，迴歸測試，負載/壓力測試，你可以有機會達到接近100％的自動化。但使用者介面，文件，安裝，相容性和恢復等領域，必須手動完成測試。

6. 不要自動化只執行一次的測試任務

  某些識別應用領域和測試用例，可能只需要執行一次，並且不需要包含在迴歸測試中。避免自動化此類模組或測試用例。

7. 你的自動化套件會長期使用嗎?

  每個自動化指令碼套件都應該有足夠長的使用壽命，其新建成本應該絕對低於手動執行成本。然而分析每個自動化指令碼套件的有效成本有點困難。

  對於單獨的構建（一般假設，取決於具體的應用程式的複雜性），大約應該使用或執行至少15到20次自動化套件，才能獲得良好的ROI。

四、總結

  自動化測試是實現大多數測試目標和有效利用資源和時間的最佳方式。但在選擇自動化工具之前，你應該謹慎。在決定自動化測試工作之前，請確保有熟練的人力。否則，您的工具只是一個空架子，無法獲得ROI。

  將昂貴的自動化工具交給非技術人員會帶來失望。在購買自動化工具之前，請確保該工具最適合你的要求。你不太可能擁有與你的要求100％匹配的工具。

  你需要找出最符合你要求的工具的侷限性，然後使用手動測試來克服這些測試工具的限制性。開源工具也是開始自動化的好選擇。

  不是100％依賴於手動或自動化，而是要使用手動測試和自動化測試的最佳組合。這是每個專案的最佳解決方案（我認為）。自動化套件不會找到所有的錯誤，也不能替代真正的測試人員。在許多情況下，隨機測試也是必要的。

如果想學習交流，就快加入：893694563，群內學軟體測試，分享技術和學習資料，陪你一起成長和學習。那就：碼上開始