真人踩過的坑，告訴你避免自動化測試常犯的10個錯誤

雖然從自己的錯誤中學習也不錯，但從別人的錯誤中學習總是更好的。

作為一個自動化測試人員，分享常見的容易犯的10個錯誤，可以從中吸取教訓，引以為鑒。

一、必要時才自動化

新人小王接到為Web應用程序自動化測試脚本的任務時，既高興又緊張，因為這是他進入團隊的第一個任務。第一印象至關重要，他也希望給團隊留下完美的第一印象。小王被要求自動化Web應用程序其中的一個模塊，但他想錶現得更好、做更多的自動化，於是選擇了另外的模塊。然而結果是他撞進了死胡同，沒有完成。其實小王想做些新嘗試並沒有錯，錯在沒有諮詢前輩就試圖自動化該模塊。事實證明，這個模塊用不著自動化，因為集成的系統可能會導致多重誤報。

我在新的自動化測試人員身上看到過很多次這種情况。畢竟，好奇心可以引領前進。當學習自動化測試時，會想嘗試在每個項目中引入自動化，但這是不必要的。可能有足够的能力自動化某件事，但這件事是否足够可行？雖然眾所周知自動化可以節省時間和精力，但回答以下問題非常重要：“為什麼要將此項目自動化？”得到了確切務實的答案後，再為自動化開綠燈。

二、定義範圍

定義將要執行的測試的範圍是非常必要的。作為新手自動化測試人員時，總是試圖測試所有的東西，並使每個測試都自動化。問題是盡管可以成功地自動化所有測試，但這既不實用也不可行。

首先，代碼中有很多部分並不需要頻繁的測試，但可能需要占用大量時間為其開發框架或脚本。比如當測試一個網站時，自動化網站的每個元素並在其上運行脚本是沒有用的，這不值得花時間和精力。

其次，自動化所有的東西會增加測試自動化百分比，這會提供書面上很好的數據，讓自己覺得完成了一項出色的工作，然而實際上並非如此。

定義測試的範圍，只考慮能够及時提供實際價值的自動化測試的可行代碼，做出明智選擇。

三、准確選擇自動化測試工具

自動化測試人員最常見的另一個錯誤是沒有選擇正確的自動化測試工具。一個項目包含許多專注於不同測試目標的組件。這些目標應分為不同的工具，以幫助更有效地實現這一目標。

例如，如果想測試一個網站的API，最好使用Postman；但如果你想確保Web應用程序在不同瀏覽器間的完美呈現，那麼在線Selenium Grid將是自動化跨瀏覽器測試的最佳選擇。

四、與其他測試人員良好協調

測試團隊中有很多人，大家具備不同的技能。例如，有人可能擅長業務測試，而其他人可能擅長功能測試。然而，這不是不與他們討論任務進展的理由。協調是加速產品交付的關鍵。了解誰在做什麼、使用什麼工具、對測試自動化的編程語言是否滿意。

這有助於幫助排除自動化測試脚本的故障，萬一事情不順利，就會知道該尋求誰的幫助，了解團隊也可以幫助自己在需要的時候進行協調。正如在最後一點中所討論的，一個項目可能需要不同的工具來實現組合的目標，可以讓擅長不同工具的測試人員發揮自己的作用。

五、檢查投資回報率

僅僅將測試人員的工資作為與整個測試過程相關的成本考慮進去是一個非常新手級的錯誤。顯然，情况並非如此。

例如希望對網站執行跨瀏覽器測試，測試人員的工資當然是成本的一部分。但如果團隊不知道這種類型的測試或與之相關的任何工具，那麼還需要通過培訓來提昇他們的技能，這會產生額外成本。此外，還需要有合適的自動化測試工具或者框架來執行自動化瀏覽器測試。當然，也可以考慮開源框架。

這只是一個例子。同樣，在對Web應用程序執行自動化測試的過程中，您還會遇到其他投資。但是，他們肯定會出現。因此，應仔細考慮測試成本，並牢記您將獲得的這些投資回報。如果回報率較低，則需要更改策略並再次計算。但最終，您需要在整個測試過程中獲得良好的投資回報率。

六、過度依賴無代碼測試

雖然無代碼自動化測試工具的學習曲線很短，很容易入門，但它們不會幫助構建自動化測試人員配置文件所需的相關技能集。作為初學者，它們很好地幫助新手起步，但隨著自身技能的發展，就會意識到它們並不像期望的那樣有用。如果决定用無代碼自動化工具的智慧參加自動化測試人員的面試，或者一直單獨用無代碼自動化來自動化複雜的web應用程序，那麼將經曆一段艱難的時光。

可靠性是這類工具的另一個大問題。在一天結束的時候，需要了解代碼，以便調試自己的自動化測試套件執行出錯的地方。此外，如果面對一個複雜的網站，那麼就不會發現無代碼自動化測試工具可以像你想的那樣靈活。建議不要逃避代碼，而是要熟練地學習它。最重要的是，這將是個人簡曆上的一大魅力。因此，作為自動化測試人員，請確保避免這種常見的錯誤。

七、維護測試設計

測試設計是將一般測試目標轉換為有形測試用例和條件的過程。作為開發人員，我們傾向於認為既然測試需要編碼，為什麼開發人員不能完成這項工作？如果是這樣的話，那麼測試這個崗比特也就不存在了。

作為初學者，不理解測試設計的重要性可能是作為自動化測試人員最大的錯誤。任何時候測試任何東西都是荒謬的想法。為了有效地進行測試，測試人員需要設計測試，然後對其進行編碼。設計測試有助於創建有意義的測試，並使整個測試過程非常高效。

八、關注代碼重用性

測試用例對它所應用的代碼並不是唯一的。在一個項目中，會出現許多類似的組件，它們需要類似的測試設計和測試套件。比如，在使用Selenium進行跨瀏覽器測試時，我們發現Web頁面的四個元素都是輸入字段，並且需要類似的測試用例。在這裏，可以通過僅為第一個元素編寫測試來複制粘貼代碼。雖然這將給出預期的結果，但問題是將來開發人員可能會以某種方式更改元素。現在，要更改測試用例，就需要更改所編寫的每個測試套件中的代碼。所有的時間都將浪費在尋找和修改這些測試代碼上。

為了避免這種情况，應該始終關注代碼的可重用性。與其一次又一次地粘貼代碼，不如用適當的參數構造一個函數，並在每個元素上調用該函數。這樣，如果將來有任何更改，只需要修改函數，就可以開始了。

九、100%自動化是一個神話

跟計算機領域經典的“人月神話”一樣，這裏的“神話”同樣指不可能達到的天方夜譚。

不要相信這種神話，因為作為一個自動化測試人員，這將是一個嚴重的錯誤。作為自動化測試領域的新手，對於將自動化引入到項目中都會很興奮。但這會讓人犯錯誤，認為自動化測試可以完全取代手動測試過程。隨著時間的推移，我們將知道這是不可能的。百分之百用自動化測試取代手動測試是一個神話，它永遠不可能實現。

作為這方面的初學者，不要試圖實現這樣的目標。又回到第一條，只有在必要時才進行自動化，並且只對那些需要自動化的項目進行自動化。

十、遵循從頭開始

在測試時，會遇到不同類型的問題。需要設定目標並對這些問題進行分類。一種基礎方法是用較小的模塊而不是大模塊開始自動化測試。

作為自動化測試人員，最大的錯誤之一是開始自動化時使用更大、更複雜的模塊。可能缺乏對每個用戶交互中涉及的入站和出站流程的認識；甚至可能缺乏處理棘手的測試用例的熟練程度；可能最終會浪費大量的時間，但卻一無所獲。所以從小處開始，從基礎的方法中增加自動化測試的覆蓋率。

第一次踏入自動化測試領域，難免犯一些錯誤，這些錯誤會造成時間、金錢、精力的浪費。希望這篇文章能對自動化測試新人有所幫助，幫大家避免踩這些不必要的坑。