測試自動化為企業節省了大量時間——除非您選擇了錯誤的測試用例。這篇文章指出了您應該注意的事項。

根據2021年測試自動化報告，超過40%的公司正在尋求擴展和投資于測試自動化的資源。雖然這并不意味著手動測試會消失，但從ROI的角度來看，人們對自動化的興趣越來越大——無論是在金錢還是時間方面。

畢竟，我們可以同意編寫和運行這些單元測試用例很無聊。一個好的自動化策略可以騰出測試人員的時間來解決一些更復雜的問題，并有助于及早發現錯誤。

然而，團隊經常在沒有適當測試策略的情況下急于自動化測試，這會導致在進行大修時出現問題。通過選擇正確的自動化測試，最大限度地提高您的精力和投資回報。

在自動化任何測試用例之前應該考慮什么?

1.測試頻率

為邊緣情況組件編寫一個手動測試通常更有效。事實上，測試新功能可以讓您快速了解有關應用程序的更多信息。但是，隨著功能數量的增加，這并不有效。

將您的測試場景分為兩部分：重復部分和一次性或非常復雜的部分。

自動化重復次數最多的那些。您甚至可以設置測試頻率的閾值，高于該閾值您將考慮自動化。

例如，應用程序登錄或警報系統測試是測試自動化的理想候選者，因為它們需要在每次應用程序構建后運行。

這個規則也有幾個例外——比如，單個測試需要執行的數據輸入量非常大。在這種情況下，自動化該特定測試是有意義的，因為它會節省大量時間。

這里唯一的警告是自動化一系列相互依賴的重復測試。如果出現故障，可能很難確定是主要罪魁禍首的確切測試。這就是日志派上用場的地方，它可以幫助您有效地檢測這些長期模式故障。

2.測試覆蓋率

測試覆蓋率對于軟件質量和確保軟件構建的穩定性至關重要。自動化正確類型的測試可以幫助您以幾乎相同的時間投入實現高測試覆蓋率的目標。

例如，如果您的應用程序有很多組件，那么運行自動化測試是個好主意。這繞過了錯過特定測試的手動錯誤的可能性，并確保應用程序中最關鍵的部分順利運行。您還可以在無人看管的情況下運行那些冗長的夜間測試，并在醒來時查看測試失敗(或成功!)原因的詳細日志。

3.結果

結果的可預測性如何?自動化需要預先定義的輸入和輸出來產生通過和失敗條件，否則它們可能會導致錯誤的結果。

如果您處于測試的探索階段，并且您的測試是臨時的或需要非常具體的領域知識，那么將它們自動化并不是最好的主意。

4.特征重要性

如果一個項目是一個重要的功能，如果失敗可能會導致用戶體驗中斷，你應該編寫一個自動化測試套件。這樣，您就可以防止任何人為錯誤擾亂您的發布。

理想情況下，測試應該連續運行，以便盡快通知相關團隊。

5.時間回報比

雖然自動化可以騰出測試人員的時間，但組織和個人經常忽略測試的一個關鍵方面——維護自動化測試所需的成本和時間。如果您的應用程序的后端發生重大變化，通常為自動化測試編寫和重寫代碼就像手動測試一樣麻煩。

解決這個問題的一種有趣方法是讓測試工程師自動化，以了解程序的哪一部分失敗。您可以通過自動化更廣泛的應用程序測試來做到這一點，這樣如果出現問題，您就可以確切地知道去哪里尋找。智能測試執行是測試自動化領域的主要趨勢之一，它通過識別需要執行的特定測試來做到這一點。

6.人的參與

您嘗試自動化的測試套件有多復雜?如果需要用人眼重新檢查測試結果或需要進行實際的用戶交互，那么自動化可能不會有太大幫助。

例如，用戶體驗測試最好不要自動化，因為測試軟件在使用產品時永遠無法模仿人類的情緒。但是，如果您需要對測試輸出進行視覺確認，則可以運行自動截屏測試，然后進行手動驗證。

7.優先權

什么時候需要測試結果?如果自動化測試有助于您更快地將產品推向市場，那么您應該繼續使用它。但是，當您需要立即獲得結果時，不要讓編寫和運行自動化測試成為瓶頸。

此外，您應該記住，“測試”并不是唯一可以自動化以提高應用程序效率的東西。手動數據收集或設置數據輸入等任務也非常適合自動化。因此，如果有一個大型數據集但您的時間不夠用，那么自動化它可能是您的救星!

經常自動化的測試用例

1.性能測試(負載、壓力測試)

負載測試幾乎因“隔夜”測試而臭名昭著。根據定義，負載測試需要大量資源，因為它們可以識別公司擴展時出現的系統滯后和性能問題。

這就是為什么進行自動化測試的工具很有意義的原因——因為它們可以以很少的成本有效地模擬用戶和資源。我的意思是，嘗試找1000名用戶對尚未發布的產品進行錯誤測試-哎呀!

雖然您絕對不能聘請1000名QA專家來進行自動化測試，但測試自動化框架可以設置虛擬用戶并讓他們像真實用戶一樣與您的產品進行交互。這將使您能夠通過在流程早期識別它們來擴展和避免中斷。然后，您的團隊可以查看性能指標并確定速度下降或中斷的確切原因。

同樣，如果您需要進行跨瀏覽器測試，自動化測試可以幫助您通過幾個步驟收集應用程序跨多個配置的性能。

自動化您的性能測試以查看哪里出現問題，以及您的應用程序是否可以處理這些問題。

2.單元測試

如果您正在開發大型應用程序的代碼庫，自動化單元測試將節省您的時間。單元測試的自動化測試將幫助您實時發現錯誤，讓您持續了解各個組件是否正常工作。

自動化在重構代碼時特別有用，因為只要單元測試是綠色的，您就可以放心地假設單個代碼單元的行為沒有改變。此外，這些測試的報告可以立即提供給整個團隊。

3.回歸測試(煙霧、健全性測試)

回歸測試可確保即使進行了大量更改，應用程序也能順利運行。這意味著需要反復重新測試多個應用程序組件。由于這種重復，回歸測試是測試自動化的理想候選者。

自動化回歸測試將幫助您節省手動資源和時間，并更快地擴展。雖然回歸測試通常在軟件發布結束時執行，但自動化它們也為您提供了一個迭代和連續運行它們的選項。這有助于更快地識別程序中的錯誤并創建快速反饋循環，從而更快地解決問題。

4.功能測試

功能測試本質上是驗證應用程序是否在前端以應有的方式運行。雖然功能測試的某些方面是手動的，但很多方面應該是自動化的，以確保無錯誤的產品交付。

例如，端到端測試自動化可確保關鍵的預定義用戶體驗流程對于每日發布的產品順利運行。

使用selenium自動化功能測試是一種流行的選擇。您甚至可以使用稍微不同的數據集或用戶行為來調整測試，以涵蓋多個用例。

哪些測試絕對不應該自動化?

1.探索性測試

探索性測試包括更廣泛的非腳本測試，這些測試必不可少，但都是即時完成的。通常，這些測試需要一些領域知識和對應用程序的熟悉才能找出意外行為。由于它們沒有很好地定義，它們不能被自動化。

但是，一旦測試人員通過探索性測試發現缺陷，這些測試操作就可以記錄下來并自動化以供將來構建。

2.可用性測試

如前所述，可用性測試不應該自動化，因為很難預測人類行為。這可能包括錯誤的字體、顏色或使人們感到困惑的UI。只有在執行Beta或QA測試時，您才會知道這些。盡管有一些工具可以嘗試自動執行此操作，但讓人工查看它更有效(且成本更低)。

自動化還是不自動化?

測試自動化對于高效的CI/CD管道至關重要。測試自動化領域正在進行許多創新，例如并行測試執行、DevTestOps、物聯網測試自動化等。這些自動化框架幫助大大縮短了產品的上市時間并提高了構建質量。

選擇正確的自動化測試只是為您的組織實現這一目標的第一步，因此更快地測試、更快地失敗和更快地修復!