自動化新手要避免的坑（下）

時間 2021-03-15

原文原文鏈接

H：維護測試設計

測試設計是將測試目標轉換爲實際測試用例和條件的過程。瀏覽器

做爲一個初學者，我不瞭解測試設計的重要性，這多是我做爲自動化測試員的最大錯誤。隨時進行任何測試都是荒謬的想法。爲了有效地進行測試，測試人員須要設計測試，而後對它們進行編碼。設計測試有助於建立有意義的測試，並使整個測試過程很是有效。框架

I：避免誤報

當測試結果錯誤地代表測試經過但實際上沒有經過時，就會出現誤報。反之亦然。在測試人員中盲目相信測試報告是一個很是廣泛的錯誤。例如，假設您正在使用使用不一樣測試用例編寫的測試腳原本測試登陸頁面。測試報告代表登陸已經過。在這種狀況下，您須要驗證登陸是否成功。做爲自動化測試人員，請不要因老是誤報和誤報而陷入錯誤。能夠經過增長驗證方法和重複測試來找出那些測試用例容易誤報，創建誤報後的確認機制。還有在編寫測出用例的時候也要把測試用例的穩定性考慮進去。函數

J：專一於代碼可重用性

一個測試用例不是它所應用的代碼所獨有的。在一個項目中，會出現許多類似的組件，它們須要類似的測試設計和測試套件。例如，在使用Selenium進行跨瀏覽器測試，咱們發現網頁的四個元素都是輸入字段，而且須要相似的測試用例。在這裏，您能夠經過僅針對第一個元素編寫測試來複制粘貼代碼。儘管這將提供預期的結果，但問題在於，未來開發人員可能會以某種方式更改元素。如今，要更改測試用例，您須要更改您編寫的每一個測試套件中的代碼。所有時間都浪費在查找和修改這些測試代碼上。我犯了這個錯誤，我能夠看出，測試時這變得很是難看。性能

爲避免這種狀況，您應始終專一於代碼的可重用性。而不是一遍又一遍地粘貼代碼，您應該構造一個帶有適當參數的函數，並在每一個元素上調用此函數。這樣，若是未來有任何更改，您只須要修改功能就能夠了。測試

測試之《代碼不朽》腦圖

K：不要相信100％自動化

不要迷戀這個理想的指標，由於這將是一個自動化測試員的嚴重錯誤。做爲測試自動化領域的新手，我很高興爲項目帶來自動化。這致使我犯了一個錯誤，認爲自動化測試能夠徹底替代手動測試過程。隨着時間的推移，我知道這是不可能的。用自動化測試徹底替代手動測試（100％）是一個神話。它永遠不可能實現。做爲該領域的初學者，請勿嘗試實現此目標。僅在必要時自動化，而且僅在那些須要自動化的事物上自動化。編碼

L：大局觀

在測試時，您會遇到不一樣類型的問題。您將須要設定目標並對這些問題進行分類。全面的方法意味着使用較小的模塊而不是較大的模塊開始自動化測試。命令行

做爲自動化測試工程師，最大的錯誤之一就是要使用更大，更復雜的模塊開始自動化。不要那樣作！您缺少對每一個用戶交互中涉及的入站和出站流程的瞭解。您甚至可能不具有處理棘手的測試用例的能力，而且最終可能會浪費大量時間而無所適從。所以，從小處着手，並從根本上增長自動化測試的覆蓋範圍。設計

M：參與探索性測試

探索性測試爲什麼如此重要？

做爲自動化測試人員，常見的錯誤之一就是不將探索性測試歸入您的每週例行程序。探索性測試是一次必要的冒險，它有助於尋找新的測試用例。當咱們進入自動化階段時，探索性測試相當重要。僅使用測試腳本可能會忽略自動化測試中一些意外的重要測試用例。做爲一個初學者，咱們只想依靠腳本和預先編寫的測試，應該避免這種狀況。花一些時間進行探索性測試。您可能永遠都不知道在野外測試時可能會捕獲哪些錯誤。3d

N：UI測試考慮變化

在較早的版本中，軟件的用戶界面發生了很大變化。自動化測試能夠幫助咱們重複執行測試，若是沒有實現，那就沒有意義了。在早期階段，測試人員會像自動化測試人員同樣忽略這些類型的錯誤，我也這樣作。

用戶界面的更改迫使咱們更改測試腳本。有時，某個元素在未來的版本中會更改其位置，而腳本會利用該位置進行進一步測試。因爲位置更改是測試所依賴的，所以完整的測試執行失敗。例如，在自動瀏覽器測試中，若是某個圖像的位置發生更改，則Selenium自動化測試腳本將沒法找到該位置。這將使整個測試失敗。這些依賴於用戶界面的測試應儘量少地編寫。