Web應用自動化失敗緣由彙總

時間 2019-11-06

標籤 web 應用自動化失敗緣由彙總欄目 HTML 简体版

原文原文鏈接

多位從業多年的測試工程師經驗彙總，提及來都是一部血淚史。前端

不切實際的指望– 100％自動化

最初的測試自動化失敗是從不切實際的指望中得到的。在個人職業生涯中，我已經屢次觀察到它，一旦您得到了自動化的質量保證或工做人員，管理層就指望他們對全部內容進行自動化測試。儘管聽起來很使人愉悅，但這是不可能的。您不能進行100％的自動化測試，由於在少數幾個領域必須進行人工檢查。這些領域之一可能與您的Web應用程序的可訪問性有關。面試

例如，若是您正在執行自動跨瀏覽器測試，則用於Selenium測試的自動化腳本將在不一樣的瀏覽器或操做系統上呈現網頁的顯示。可是，要肯定網站是否按照設計進行渲染，版式是否合適，文字是否合適，最好手動評估數據庫

自動化什麼以及自動化多少？

許多組織確實意識到指望進行100％自動化測試的問題陳述，但一般會遇到如下問題。咱們能夠實現什麼自動化，若是不是100％，那麼咱們能夠爲Web產品實際實現多少自動化？編程

沒有適用於每一個企業的自動化測試覆蓋率的完美百分比或近似值。這徹底取決於您所提供的Web應用程序，而且因爲不一樣的企業正在知足不一樣的需求。天然而然地，人們會對圍繞自動化測試實際能實現的自動化測試百分比抱有獨特的指望？自動化測試的範圍將從電子商務Web應用程序到靜態，動態或動畫Web應用程序有所不一樣。所以，若是您想知道爲何自動化測試對您的組織失敗？而後，我建議您根據所提供的Web應用程序的類型來評估所需的自動化測試量。後端

管理不當致使測試自動化缺少可見性

在我做爲自動化測試員開始IT生涯時，我就一直是管理不當的受害者。我當時在一家基於Service的公司工做，他們爲我分配了個人第一個項目。這個項目已經運行了兩年，當我加入後，我被交給了一系列測試自動化腳本。項目的高層將要離開組織，管理層對即將到來的衝刺太忙了，沒法考慮將要離開的高級自動化測試人員進行的全面知識轉移課程。他們離開後發生的景象不佳？個人經理在聽證會的結尾說，咱們因停電而大吃一驚，而我剛起步，對各類出站和入站流程如何受到衆多自動化腳本的影響的瞭解最少。然而，我見過一些由少數成員負責實現自動化的團隊，而其餘成員則對正在發生的事情一無所知。瀏覽器

您是否定爲當一半的團隊缺少可見性時，從自動化測試中得到魔術效果是不現實的嗎？因爲自動化必須是一個協做的工做，所以對每一個團隊成員進行相關工具和流程的教育很是重要，尤爲是對新手而言。您能夠經過舉行團隊會議和會議來討論與自動化有關的工具，趨勢和實踐，從而實現這一目標。緩存

對手動測試或探索性測試不瞭解

這可能會讓您有些驚訝，測試自動化失敗的另外一個緣由多是缺乏手動測試技能或探索性測試技能。自動化測試腳本並不意味着團隊成員能夠減小一些懈怠。到目前爲止，咱們已經知道，自動化方法不能涵蓋全部內容，而這正是挑戰所在。由於如今您必須更深刻地研究Web應用程序，並找到隊友還沒有發現的關鍵測試方案。網絡

自動化是節省測試工做的一種方式。軟件公司應該使用它來最大程度地減小重複，並僅使那些不易更改的元素自動化。一旦完成，公司應該分配他們的資源來執行普遍的手動測試或探索性測試，以找到獨特的測試用例。併發

不仔細考慮並編寫腳本

自動化彷佛是減小工做量的一站式目標。可是在開發測試自動化腳本以前，必須考慮周全。此外，這可能會花費大量的自動化測試執行時間。框架和測試自動化工具的靈活性在開發腳本場景所需的時間中起着相當重要的做用。框架

因爲每種狀況都不一樣，所以必須編寫腳本。即便您仔細考慮，若是不編寫腳本腳本，這都是浪費。確保測試工程師的編碼技能與測試的複雜性保持一致。複雜的測試須要大量時間才能實現自動化。所以，隨着全新功能的發展，他們一般沒有機會發現迴歸錯誤。在寫下測試方案以前，請確保牢記這些注意事項。

對什麼時候使用自動化以及什麼時候不使用自動化缺少理解！

「爲何測試自動化對您的公司失敗？」背後的最多見緣由？」是人們不知道何時應該自動化，何時不知道。例如，能夠自動化不一樣的網頁功能。可是經過測試自動化評估填充，圖像等渲染問題不是一個好主意。若是使用座標來肯定元素位置，則在以不一樣的屏幕分辨率和大小運行時，可能會致使差別。

在測試易於進行大量更改的項目時，使用自動化是不可行的。若是您要測試穩定的實體，那麼自動化是必經之路。基本上，須要重複執行某些操做的普通任務最適合自動化測試。所以，測試自動化能夠簡化您的迴歸測試過程。

人員和資源計劃選擇不當

我看到IT行業廣泛存在錯誤觀念。人們認爲任何開發人員或測試人員均可以執行測試自動化。測試自動化的設計，配置和實施須要特定的技能。執行自動化的測試人員應該知道如何在經理，開發人員和客戶之間闡明想法。他/她還應該對開發趨勢有清晰的瞭解，而且應該知道開發團隊要去的方向。

自動化測試工程師是最困難但重要的一些人。爲了啓動各類自動化項目，聘請具備普遍技術知識的測試人員相當重要。整個團隊應該知道發生了什麼，而不是由一個或幾我的進行自動化測試。即便在僱用技術精湛的員工方面投入很高，但回報仍是值得的。

沒有足夠注意測試報告

因爲自動化測試是一個相對較新的現象，所以失敗的可能性很高。測試團隊進行的新實驗太多，所以準確分析結果變得很重要。進行測試後，測試人員必須作出詳盡的測試報告。可是，這就是測試自動化對您而言失敗的緣由！您的團隊沒有對測試報告分析給予足夠的重視。若是執行不當，分析可能會致使無人看管的故障，並浪費時間，資源和精力。

在自動測試中，有些測試成功，有些失敗。所以，必須檢查測試報告是否有故障並分析某些測試失敗的緣由。最好手動進行分析，以發現真正的故障。揭露隱藏的問題並確保它們不會被其餘問題掩蓋而被忽略是相當重要的。

自下而上的方法來定義您的自動化目標

設置過高而不能成爲自動化的真正目標，在紙面上彷佛很完美。可是，在執行步驟時，團隊成員之間嚴重缺少清晰度。最大的問題是目標不明確。他們缺少從自動化中得到真正價值的準確性和準確性。大多數公司所作的是，他們開始將很是複雜的事情自動化，並最終重構整個框架。結果，團隊最終會浪費大量時間，金錢和精力。

您能夠經過從小處着手並逐步提升複雜性來消除不肯定性。選擇穩定的功能，並從其自動化開始。以後，收集反饋以肯定出了什麼問題。一旦您的測試達到一致性，就能夠繼續使用其餘功能。對於不一樣的項目環境，需求可能會有所不一樣，所以請使用自定義方法進行測試自動化。

選擇合適的工具進行高效有效的測試

在擁有大量自動化工具的狀況下，有時候選擇最佳工具變得充滿挑戰。最終目標是改善總體測試程序並知足實際要求。可是大多數團隊都沒法從頭再來，也沒有挑選出最適合其測試需求的工具。毫無疑問，自動化測試高度依賴於您決定繼續使用的工具。每一個工具都有特定的功能。可是，團隊缺少充分利用這些功能所需的專業知識水平。

此外，公司陷入了對特定工具的炒做。可是在選擇它以後，他們意識到它並無提供他們但願得到的一切。另外，每一個團隊都有預算，有時該工具的成本超出了預算。在繼續選擇炒做工具以前，請仔細列出要求。以後，肯定您對該工具的指望。在設定目標時要很是具體，並檢查與產品用戶接受標準的對應關係。您也能夠諮詢有使用這些工具經驗的專家。

忽略假陰性和假陽性

幾乎每一個組織都常常觀察到這一點。一旦自動化測試套件準備就緒而且工做正常，管理就開始放鬆。他們開始放寬對測試執行的深刻分析，由於他們認爲只有經過/失敗檢查才足夠。可是，這就是測試自動化對他們失敗的緣由！

有時，系統從根本上能夠正常運行。可是，自動化腳本不能反映出相同的狀況。他們以其餘方式陳述並致使假陽性方案。所以，這形成了混亂的局面，浪費了時間，精力和資源。我已經看到測試團隊試圖找到不存在的東西是多麼使人沮喪！

另外一種狀況是，自動化腳本發出綠色信號時，出現了問題。系統沒法正常運行，但腳本另有聲明。網絡問題可能會致使測試環境設置出現差別。這是因爲數據庫開始階段缺少準確性而致使的。從長遠來看，讓系統處於受損狀態可能會致使災難性後果。

具備未定義ID的Web元素

每一個Web元素都必須有一個ID才能執行有效的測試。可是有時，開發人員沒法將ID分配給全部Web元素，這就是測試自動化失敗的緣由。在這種狀況下，自動腳本必須查找這些Web元素，這會花費大量時間。此外，若是腳本沒法在規定的時間內找到這些元素，則測試將失敗。所以，爲了確保腳本的正確同步，團隊必須爲全部Web元素分配惟一的ID。

不利用並行執行

所以，您最終使全部想要自動化的東西都自動化了。您最終得到了龐大的測試套件，直到如今，您纔開始碰壁。這些複雜的測試套件執行時間比您預期的要長。這開始與您各自的IDE測試自動化框架中的測試隊列質量相抵觸。結果，因爲隊列超時問題，測試用例忽然中止，這都是由於您要按順序執行它們。測試用例的順序執行是Web應用程序測試自動化失敗的另外一個緣由。

與順序運行測試不一樣，並行執行使您能夠在不一樣的環境中同時執行多個測試。可是自動化測試可能會致使意外的代碼交互。調試失敗緣由很是困難，所以您須要透徹的報告機制，提供有關測試執行的詳細看法。

經過測試自動化對ROI的錯誤估計

不管您在線經營什麼業務，ROI都將成爲每次董事會會議的議程。股東要求更高的回報。並且，不管您準備測試自動化套件花費了多少時間和精力，若是它們產生的ROI均達不到預期，那麼它們的重要性將比您預期的要輕得多。

在計算測試自動化的投資回報率時，可能須要考慮許多指標，例如測試維護，購買必要的測試自動化工具所涉及的成本，板載資源等等。計劃不切實際的ROI對於許多組織而言多是成問題的，而且多是測試自動化失敗的緣由。

沒法評估漣漪效應

許多組織給人以自動化測試容易的印象。您所須要作的只是編寫幾行代碼以自動化您的Web應用程序的測試工做流程。就是這樣！您徹底沒必要擔憂測試自動化腳本的計劃和輸入。但這不是！

您須要評估波紋效應。您的Web應用程序將包含許多旨在測試不一樣模塊和流程的測試自動化腳本。若是一個測試腳本沒法正確執行，則其餘腳本也可能觸發測試自動化失敗。不只如此，在計劃資源時還應該計算出連鎖反應。

假設您有一個高級資源，他曾經寫過腳本，如今已經離開了公司。您可能沒有想到辭職可能會在自動化項目的將來時間表中產生連鎖反應。這就是爲何須要記錄有關係統中每一個自動化測試腳本的每一個細節的緣由。該文檔應做爲萌芽的自動化測試人員以及經驗豐富的自動化測試人員的標準。

測試套件不是一成不變的東西–它應該隨着平臺的發展而發展/變化/不適應的測試套件

測試自動化對您的組織失敗的另外一個緣由多是不合適的測試套件。許多自動化測試人員會建立靜態測試套件，這些套件在您擴展業務時並不那麼靈活。每當平臺發展時，它們最終都會從新編寫整個自動化測試腳本。這是一個壞習慣，由於您在浪費時間，資源帶寬和金錢。另外，這是一個錯誤的過程。確保您編寫隨平臺擴展而發展和適應的測試套件。

自動化一個過程並跳到另外一個過程而無需回頭

避免測試自動化失敗的另外一種方法是即興測試套件。如今，這聽起來彷佛很明顯，可是在許多組織中卻沒有實踐。緣由是，一旦他們設計了測試套件，並發現它能夠正常工做，便開始着手自動化新領域。我沒有批評沉迷或探索新領域以實現自動化的努力。可是，管理一個時間窗口並讓您和您的團隊回顧現有的代碼段，以找出進一步優化它的方法並無什麼壞處。始終嘗試使用您的測試套件，以使事情變得更好。

沒法合做

隨着敏捷軟件，看板軟件等現代SDLC（軟件開發生命週期）方法在全球範圍內的採用，協做已成爲將Web應用程序更快部署到市場中的關鍵組成部分。

這是一個多維軟件開發過程，全部團隊都在同時開發Web應用程序。您有一組開發人員設計前端，另外一個負責後端，還有一個負責中間件活動的團隊。做爲測試人員，您須要瞭解哪一個團隊負責哪一個模塊。您必須及時瞭解不一樣團隊所作的產品加強功能，並對自動化腳本進行相關更改，以確保測試自動化不會失敗。

執行每一個測試自動化套件以前，手動設置測試環境

自動化測試的主要目的是最大程度地減小重複手動測試所涉及的壓力，以節省時間。從抽象的角度看，這聽起來不錯，但對於那些執行測試自動化的人來講，要意識到爲執行內部測試自動化而配置正確的基礎結構的艱辛。我常常觀察到測試人員在執行新腳本以前會刷新整個測試自動化套件，以免與腳本產生任何歧義。但這不能使自動化測試的整個過程都失敗，不是嗎？

例如，若是您正在使用內部Selenium Grid執行自動跨瀏覽器測試，以測試適用於Google Chrome和Safari瀏覽器的macOS和Windows操做系統的網站。如今，您可能每次都要運行Selenium腳本以前就不得不面對設置新操做系統的麻煩。

在靜態測試環境中重複運行多個測試套件，而無需進行清理

這是組織自動化測試失敗的很是廣泛的緣由。特別是在臨近最後期限時。您的測試部門將繼續在同一測試環境上運行大量測試套件，而不會清除先前執行的測試自動化腳本的緩存。這可能會致使錯誤的測試評估，當您遇到更多的假陰性和假陽性時，您的測試報告可能會受到影響。

例如，假設您須要針對不一樣的地理位置測試您的Web應用程序。在靜態測試環境中執行地理位置定位時。您的腳本可能會遭到Google的測試，要求您證實本身不是機器人。這將致使測試自動化腳本失敗。

這就是須要使用清除的緩存的新虛擬機的緣由，所以您能夠得到自動化跨瀏覽器測試腳本的準確結果。

測試環境自己很麻煩

爲了使自動化可以在不一樣的測試環境中工做，須要進行大量的計劃。您須要在暫存環境上進行測試，以確保將代碼移入生產管道時，它們能夠完美地工做。可是，常常會發生這樣的狀況：在舞臺環境中進行測試時，用於代碼更改的測試自動化腳本能夠無縫運行，可是當移至生產環境時，它就會崩潰。此類問題背後可能有許多緣由，例如缺少持續的監控，登臺環境沒法使生產環境成對增加，缺乏實時流量等等。