新手測試周報范文

當您開始作為自動化測試員的旅程時，錯誤肯定會發生。 如果您不參加Selenium自動化測試腳本的深入研究而參加自動化網站測試，也可能會發生這種情況。 雖然可以從錯誤中學習，但最好還是從別人那里學習，以防患于未然。

在處理自動化測試項目時，您承擔著巨大的責任。 您不正確的簽收可能導致生產中斷，最終可能導致客戶和聲譽損失。 我已經去過接收端幾次了，這不是一個愉快的經歷。 因此，作為一個自動化測試人員，我現在要確保避免這14個錯誤，我將與您分享這些錯誤。 請確保對它們進行記錄，以免出現紅臉。

必要時自動化

當我承擔了為我的Web應用程序自動化Selenium測試腳本的責任時，我感到非常高興，因為這是我對團隊的第一份工作。 第一印象總是至關重要的，我希望我的完美。 我被要求自動化Web應用程序的一個模塊，我對此感到很自在。 但是，我想做更多的自動化工作，所以我從自己的理解中選出了另一個模塊。 我碰到了死胡同，卻未能自動化。 現在，嘗試自動化新模塊沒有錯。 我在沒有咨詢我的前輩的情況下試圖自動執行該模塊是錯誤的。 原來，該模塊并不是要自動化的，因為集成系統可能會導致多個誤報和誤報。 我花了我的時間在那個永遠不會自動化的模塊上。 我什至最終忽略了我的其余職責。 這么多給一個好印象吧？

我已經看到許多新的自動化測試儀會發生這種情況。 畢竟，好奇心可以帶您到位。 當您學習自動化測試時，您可以嘗試在每個項目中引入自動化。 這不是必需的。 您也許可以自動化某件事，但這是否可行？ 眾所周知，自動化可以節省時間和精力，但回答以下問題絕對重要：為什么需要使該項目自動化？ 如果您得到務實的答案，則只有向自動化顯示綠燈。 避免將此錯誤作為自動化測試人員至關重要。

定義范圍

定義要執行的測試范圍是非常必要的。 當我是一名新的自動化測試人員時，我嘗試測試所有內容并使每項測試自動化。 問題是，盡管您可以成功地自動化所有測試，但是它既不可行也不可行。 首先，代碼的許多部分不需要經常測試，我們可能需要花費大量時間來開發僅用于這些代碼的框架或腳本。

例如，在使用Selenium測試網站時，自動化網站的每個元素并在其上運行腳本是沒有用的。 這不值得花費時間和金錢。 其次，使一切自動化將增加測試自動化百分比，這會讓您感到自己做得非常出色，這是不對的。 在紙上看起來可能不錯，但這不是必需的。 定義測試范圍，并僅考慮可行的代碼以提供實時價值的自動化測試。

明智地選擇自動化測試工具

作為自動化測試人員，另一個最常見的錯誤是沒有選擇正確的自動化測試工具。 一個項目包含著重于不同測試目標的許多組件。 這些目標應分為不同的工具，可以幫助更有效地實現該目標。 例如，如果要測試網站的API，則最好選擇Postman，但如果要確保在不同瀏覽器中完美呈現Web應用程序，則在線Selenium Grid是進行自動跨瀏覽器測試的最佳選擇。

這種情況的直接方法是不要跳到軟件上，然后嘗試通過該軟件解決問題。 首先，找到問題，然后找到合適的工具。

與研究員測試人員協調良好

測試團隊中有很多人。 所有這些人都具備不同的技能。 例如，某人擅長業務測試，而某人擅長功能測試。 但是，這沒有理由讓您不與他們討論任務的進度。 協調是加快產品交付的關鍵。 確認誰在研究什么，他們在使用什么工具，他們對哪種用于自動化測試的編程語言感到滿意。 為什么？

這肯定會幫助您對Selenium自動化測試腳本進行故障排除。 因此，萬一事情往南走，您將知道在哪里敲門，或者更確切地說是誰在敲門！

了解您的團隊還可以幫助您在需要時進行管理。 正如最后一點所討論的，一個項目可能需要使用不同的工具來實現合并的目標，最好讓測試人員使用他喜歡的工具。

重要的是不要強迫任何人隨意使用任何任務和工具。 為此，您始終可以在開始測試過程之前進行空運行。 如果沒有適合的西裝，則需要進行相應的培訓。

檢查投資回報率

僅將測試人員的薪水視為與整個測試過程相關的成本，這是一個非常菜鳥的錯誤。 在最初的日子里，我做過同樣的事情。 顯然，事實并非如此。 例如，假設您要對網站執行跨瀏覽器測試 。 測試人員的薪水顯然是成本的一??部分。 如果您的團隊不知道這種類型的測試或與之相關的任何工具，那么您需要通過培訓他們來提高他們的技能。 這產生了額外的費用。 此外，您需要具有正確的自動化工具或框架來執行自動化瀏覽器測試 。

現在，您可能正在考慮選擇像Selenium這樣的開源框架。 這樣，您可能不必支付更多，對嗎？ 嗯，就像其他所有東西一樣，Selenium不是完美的。 Selenium自動化測試面臨一些挑戰。 主要問題在于可伸縮性。 如您所知，Selenium Grid將幫助您執行并行測試，這很棒。 但是，您只能通過提供Selenium Grid的計算機中安裝的瀏覽器來測試您的網站。 現在，您可能必須測試數百種瀏覽器，以及針對移動和臺式設備的不同操作系統上的瀏覽器版本。 自行執行此操作將非常耗時且昂貴。 選擇設備實驗室將傷您的口袋。 所以，你可以做什么？

您可以尋找在線Selenium Grid，例如LambdaTest。 我們的Selenium Grid可幫助您跨2000多種真實的瀏覽器和真實的操作系統測試您的網站。 最好的部分？ 一切都在云上，這意味著您可以擺脫維護內部基礎結構的麻煩，而選擇使用托管在云上的分布式計算機。 您不僅會節省時間，而且會節省金錢。

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

并非每個開源都將成為黃金

開源工具每天都在流行。 他們在用戶，支持和社區方面確實很棒。 開源軟件的最好之處在于，全球有大量的開發人員參與其中，從而可以更快地進行改進。 但是，這并不意味著您僅選擇或搜索開源工具。 開源工具的開發者也需要像其他人一樣的錢。 因此，更多時候您可能找不到帶有功能的開源軟件，即使很少有開源提供大量功能，也無法告知需要多長時間！ 軟件錯誤可能會彈出，而社區支持程度較低的開源工具將很難找到這些錯誤的修復程序。 您可能最終意識到，這是您作為自動化測試員的大錯誤。

因此，始終建議使用具有大型社區支持的開源框架（例如Selenium）進行Web應用程序自動化測試。 因此，在開始之前，不要只將目光投向開源類別。 如果開源可以滿足您的要求，那很好，但如果不滿足，那么您就需要擁有合適的軟件。

將無代碼自動化視為墊腳石

盡管無代碼自動化測試工具的學習范圍狹窄且易于上手，但它們無法幫助您建立自動化測試人員檔案所需的相關技能。 作為一個初學者，他們很好地幫助您入門，但是隨著您在測試自動化事業中的發展，您會意識到他們并沒有您期望的那樣有幫助。 而且，如果您決定以無代碼自動化工具的智慧參加一次自動化測試人員資料的采訪，或者如果您認為僅憑無代碼自動化就可以使復雜的Web應用程序自動化，那么您將需要花費大量的時間來破解它。

在這些類型的工具中，可靠性是另一個大問題。 最終，您需要學習代碼以調試自動化測試套件執行出錯的地方。 同樣，如果您要處理一個復雜的網站，那么您將找不到無代碼的自動化測試工具，它沒有您想要的那么靈活。 建議不要逃避代碼，而是要熟練地學習它。 最重要的是，這將是您簡歷的魅力。 因此，請確保避免作為自動化測試人員的常見錯誤。

維護測試設計

測試設計是將一般測試目標轉換為有形測試用例和條件的過程。 作為開發人員，我們傾向于認為既然測試需要編碼，為什么開發人員無法完成這項工作？ 好吧，如果真是那樣，那么測試人員將不存在。

作為一個初學者，我不了解測試設計的重要性，這可能是我作為自動化測試員的最大錯誤。 隨時進行任何測試都是荒謬的想法。 為了有效地進行測試，測試人員需要設計測試，然后對它們進行編碼。 設計測試有助于創建有意義的測試，并使整個測試過程非常有效。

避免出現假陽性和假陰性結果

當測試結果錯誤地表明測試通過但實際上沒有通過時，就會出現假陽性。 反之亦然。 在測試人員中盲目相信測試報告是一個非常普遍的錯誤。 這也可以稱為您正在測試的元素的非驗證。 例如，假設您正在使用使用不同測試用例編寫的測試腳本來測試登錄頁面。 測試報告表明登錄已通過。 在這種情況下，您需要驗證登錄是否成功。 作為自動化測試人員，請不要因總是誤報和誤報而陷入錯誤。

專注于代碼可重用性

一個測試用例并不是它所應用的代碼所獨有的。 在一個項目中，會出現許多相似的組件，它們需要相似的測試設計和測試套件。 例如，在使用Selenium進行跨瀏覽器測試時，我們發現網頁的四個元素都是輸入字段，并且需要類似的測試用例。 在這里，您可以通過僅針對第一個元素編寫測試來復制粘貼代碼。 盡管這將提供預期的結果，但問題在于，將來開發人員可能會以某種方式更改元素。 現在，要更改測試用例，您需要更改您編寫的每個測試套件中的代碼。 整個時間都浪費在查找和修改這些測試代碼上。 我犯了這個錯誤，我可以看出，測試時這變得非常難看。
為避免這種情況，您應始終專注于代碼的可重用性。 而不是一遍又一遍地粘貼代碼，您應該構造一個帶有適當參數的函數，并在每個元素上調用此函數。 這樣，如果將來有任何更改，您只需要修改功能就可以了。

100％自動化是神話

不要迷戀這個神話，因為這將是一個自動化測試員的嚴重錯誤。 作為測試自動化領域的新手，我很高興為項目帶來自動化。 這導致我犯了一個錯誤，認為自動化測試可以完全替代手動測試過程。 隨著時間的推移，我知道這是不可能的。 用自動化測試完全替代手動測試（100％）是一個神話。 它永遠不可能實現。 作為該領域的初學者，請勿嘗試實現此目標。 僅在必要時自動化，并且僅在那些需要自動化的事物上自動化。

遵循地面向上的方法

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

作為自動化測試儀，最大的錯誤之一就是要使用更大，更復雜的模塊開始自動化。 不要那樣做！ 您缺乏對每個用戶交互中涉及的入站和出站流程的了解。 您甚至可能缺乏處理棘手的測試用例的能力，并且最終可能會浪費大量時間而無所適從。 因此，從小處著手，并從根本上增加自動化測試的覆蓋范圍。

參與探索性測試

作為自動化測試人員，常見的錯誤之一就是不將探索性測試納入您的每周例行程序。 探索性測試是一次偉大的冒險，它有助于尋找新的測試用例。 當我們進入自動化階段時，探索性測試至關重要。 僅使用測試腳本可能會忽略自動化測試中一些意外的重要測試用例。 作為一個初學者，我們只想依靠腳本和預先編寫的測試，應該避免這種情況。

花一些時間進行探索性測試。 您可能永遠都不知道在野外測試時可能會捕獲哪些錯誤。

UI不滲透的設計測試

在較早的版本中，軟件的用戶界面發生了很大變化。 自動化測試可以幫助我們重復執行測試，如果沒有實現，那就沒有意義了。 在早期階段，測試人員會像自動化測試人員一樣忽略這些類型的錯誤，我也這樣做。 現在，我知道我不應該擁有！！

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

結語

自動化是一個蓬勃發展的行業。 從小型JUnit測試到大型Selenium腳本，每個人都在朝著自動化邁進。 您可能會在添加了小的補丁的情況下遇到相同的代碼，并且不得不再次運行相同的測試。 借助自動化，重復性任務中的錯誤容限已減少至零。 但是，只有在一些自動化方面的實踐和經驗之后，才能達到此階段。 當人們第一次進入自動化領域時，他們注定會犯一些錯誤。 盡管犯錯不是犯罪，但是如果您在公司或團隊中工作，這些錯誤會浪費您的金錢，時間和其他關鍵資源。 這就是為什么事前安全要好一些的原因。 我希望您不會因為自動化測試員而屈服于這14個錯誤。 測試愉快！

翻譯自: https://www.javacodegeeks.com/2020/02/14-mistakes-i-did-that-you-should-avoid-as-a-newbie-automation-tester.html

新手測試周報范文

總結

以上是生活随笔為你收集整理的新手测试周报范文_作为新手自动化测试人员，我应该避免的14个错误的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。