如何使用Selenium來計算自動化測試的投資回報率？
跨瀏覽器測試是一種測試，需要大量的精力和時間。通過不同的瀏覽器，作業系統，裝置，螢幕解析度測試Web應用程式，以評估針對各種受眾的Web內容呈現的過程是一項活動。特別是如果手動處理。使用Selenium進行的自動跨瀏覽器測試可以幫助您節省例行測試活動的時間，並幫助您縮短迴歸測試的時間。但是，人們很少喜歡變化。如果手動測試在您的組織中很流行，那麼當您要求他們實施測試自動化時，管理層顯然會提出問題。
測試自動化雖然非常有益，但通常可能會證明是昂貴的，但值得嗎？在說服高層管理人員的同時，您可能會發現這是一個難題。在開發Web應用程式時，將需要您提供使用Selenium進行測試自動化的有效ROI，並通過使用Selenium進行自動化跨瀏覽器測試來簡化Web應用程式的自動化，從而突出顯示自動化測試的好處，因為它可以更快地完成工作，而無需人工。
在本文中，我們將討論使用Selenium評估測試自動化的ROI的不同指標，以及涵蓋基礎知識和高階技術的ROI計算技術。
使用Selenium評估測試自動化的ROI的指標
您和您的團隊成員可以考慮某些度量標準和度量標準，這些度量標準和度量標準可以幫助您在計劃從Web應用程式的頭開始進行自動化測試時，分析使用Selenium進行測試自動化時的ROI。這些指標可能因組織而異。為什麼？好吧，這是一個優先事項，有不同的度量標準，例如檢測到的缺陷數量，時間增益或測試覆蓋範圍會直接影響專案的風險，成本，質量和交付進度。一些組織可能會優先考慮發現的缺陷數量，因為他們可能認為數量會帶來質量。有些人可能會反之亦然，因為對於他們而言，質量意味著一切。你拿什麼 您認為在測試用例的質量與數量之爭中，更重要的是什麼。在下面的評論部分中讓我知道您的想法。
話雖如此，在您與高階管理層進行討論之前，確定關鍵指標以使用Selenium進行測試自動化計算ROI至關重要。
Selenium測試自動化的範圍
我們知道我們無法執行100％的測試自動化。那麼，您可以執行多少自動化的跨瀏覽器測試，這是一個需要大量思考過程的問題？如果您希望為您的Web應用程式執行自動跨瀏覽器測試，則必須考慮並確定優先順序，以及您應該在測試用例中涵蓋哪些作業系統？因為您無法涵蓋所有情況。可能的方案總數可能導致數百甚至數千個測試用例。如果您的自動化測試指令碼是如此之長，那麼每天可能需要花費相當多的時間評估您的Web應用程式或網站。
簡而言之，您需要在此處比較自動化測試用例的總數與可以實現自動化的測試用例的總數。
如果您希望減少使用複雜測試套件的時間，則還可以使用Selenium Grid進行並行測試。這樣，您可以同時執行多個測試指令碼。但是，為此，您可能還需要考慮多少個併發或並行會話足以滿足您的要求？您可以通過我們的併發計算器進行操作。
此指標的改進表明，團隊可以更快地發現缺陷並快速修復它們，從而在Selenium上實現自動化測試的風險低，投資回報率高。
您將節省多少時間？
使用敏捷，每週或每兩週交付一次，並且需求經常變化。在那種情況下，迴歸測試的重要性增加了。實施自動迴歸測試用例將減少測試所需的時間，從而獲得更多的時間來投資開發或進行另一個Sprint。節省時間是幾乎每個需要快速擴充套件其Web應用程式的組織（尤其是初創企業）的優先考慮。在評估測試自動化的投資回報率時，時間是您關注的問題之一嗎？
您的資源頻寬
我們知道，使用Selenium進行測試自動化將幫助您快速推銷Web應用程式。但是，沒有哪個組織願意在員工大部分時間都閒著等待指令碼完成的情況下使用它。要使用Selenium來計算測試自動化的ROI，需要對您所擁有的每個自動化和手動測試儀進行徹底的工作分析。
資源和工具的投資預算
測試自動化可以節省時間和精力。但是，這涉及到價格的權衡。您需要考慮可以為多少工具，每個組織（尤其是初創公司）輕鬆分配多少預算，這些工具需要快速擴充套件其Web應用程式。在評估測試自動化的投資回報率時，時間是您關注的問題之一嗎？
總缺陷數
每個迴歸週期完成後的總缺陷數表明了產品質量以及特定專案的有效自動化測試量。
找出自動化測試的真實投資回報率
根據在專案生命週期內需要執行的迴歸週期數，真實的ROI可以轉移到正值區域。ROI通常通過以下公式計算：
ROI =（手動測試成本–自動測試成本）/自動測試成本
但是隨著敏捷和DevOps進入市場，經典方法不再有效。另外，該度量標準也不現實，因為手動測試的次數永遠不會與自動測試的次數相同。用Selenium自動化基於數量計算測試自動化ROI的真實價值並不是很多人的選擇。但這也不是完全被忽視的。
缺陷質量
我認為，這是使用Selenium計算測試自動化的ROI時非常重要的指標。我相信，使用Selenium進行測試自動化的全部目的是不消除專案中對手動測試人員的需求。自動化測試的重點是減少測試人員狹窄的工作量，從而使他們可以提出更多的開箱即用的測試用例。提高測試用例的質量肯定會幫助您更好地構建Web應用程式。
在測試自動化上計算投資回報率時的一般錯誤
儘管計算ROI涉及使用一些簡單公式進行基本計算，但是如果您錯過了一些重要引數，則可能會發生錯誤。讓我們討論人們在計算ROI時常犯的一些錯誤。
您真的不是完全忽略手動測試嗎？
最大的錯誤之一就是僅保留自動化測試工作作為主要測量引數。手動測試將始終很重要。對於跨瀏覽器測試，可以自動執行某些方案，但是在某些領域中，您需要通過執行手動跨瀏覽器測試與Web應用進行實時互動。因為視覺缺陷比執行自動化指令碼更容易手動檢測。始終手動檢查網站是否在所有瀏覽器中都看起來不錯或某個導航選單在特定瀏覽器中是否正常執行等事實。如果您使這些測試自動化，它們將無法在使用Selenium進行測試自動化方面提供很高的投資回報率。即使您不計算手動工作量，您仍然必須花費時間和金錢。
總是想著更大的圖景
在使用Selenium測量測試自動化的ROI時，您必須考慮更長的時間。檢查某種測試方法在短時間內如何使組織受益的做法並不理想。從長遠來看，您必須檢查它如何影響組織和團隊。而不是幾個月，而是要計算3到5年內的影響。例如，您應該選擇左移測試嗎？左移測試是一種方法，可讓您集中精力從需求收集階段儘快進行測試。背後的想法是考慮錯誤並儘快發現它們，因為據信與最初階段發現的錯誤相比，在SDLC後期發現的錯誤會貴得多。
您是否同步了組織的功能？
您必須將組織的功能與測試自動化工具堆疊同步。為了成功實施自動化測試策略，既需要產品知識，又需要自動化知識。您的團隊應該對如何使用計劃的自動化工具以及應用程式的工作有清晰的瞭解。
測試維護是要考慮的重要因素
測試用例的維護是人們在使用Selenium測量自動化測試的投資回報率時往往會錯過的另一個因素。當您使用Selenium進行自動跨瀏覽器測試時，在成功實施測試策略之後，您將定期需要更新和維護測試用例。隨著您新增新頁面，增強或更新Web應用程式的功能，迴歸套件和測試用例將開始增長。確保這些測試用例在較長時間內的可用性將需要定期維護。
缺少正確的文件
這是一個非常常見的錯誤，不僅從自動化測試人員的角度來看，而且從管理角度來看。應將文件設定為每個組織的標準。當自動化測試人員編寫測試指令碼時，他們應該準備一份文件，解釋該指令碼的用途及其工作原理。應該提供一個公共知識庫來收集有關組織活動的每個自動化指令碼的文件。這將為參與該過程的每個萌芽資源奠定基礎。這也將有助於消除因缺少任何高階測試自動化工程師而導致的Web應用程式可能遭受的附帶損害，或者自動化測試人員打算從您的公司切換到另一家公司。
使用Selenium實現自動化測試時獲得最大投資回報的操作專案
到目前為止，我們已經意識到了常見的錯誤，即使用Selenium在測試自動化上計算ROI的指標。接下來是什麼？執行部分。使用Selenium在測試自動化上獲得最大投資回報的最佳方法是什麼？好了，這裡有一些值得注意的可行見解，可以幫助您從測試自動化中獲得最大的收益。
為新測試用例實現自動化
這是要考慮的非常重要的因素，尤其是當您從手動轉換為自動化時。假設您要介紹Selenium WebDriver，以在組織中進行自動跨瀏覽器測試。
- 計算需要自動化的測試用例的數量
在此步驟中，檢查哪些應該是自動化的，哪些應該保持手動。
不要將每個測試用例都轉換為自動化。有些事情只能手動測試。 - 計算執行您的測試用例的測試人員的小時成本。
- 如果某些測試人員沒有自動化經驗，那麼也要計算培訓成本。
優先考慮自動化新測試用例的過程
我們都知道，迴歸測試始終被放在首位，尤其是涉及跨不同瀏覽器的Web應用程式的視覺迴歸測試以檢查其跨瀏覽器相容性時。
迴歸測試主要涉及對舊測試用例的重複執行，以確保某些新新增的功能或增強功能不會引入任何新的或舊的缺陷。隨著時間的流逝，當您的Web應用程式在體系結構和功能方面不斷增長時，保留迴歸測試手冊的過程將證明是昂貴的。如果您想降低成本，則實施自動視覺迴歸測試很有意義。
- 在計算ROI時，假設每個新的測試用例都將很快成為迴歸測試的一部分。將它們保留為迴歸測試策略的一部分。
- 根據複雜性對測試用例進行排序，並在其中自動進行檢查。
- 如前所述，請考慮維護舊測試用例的成本。
跨瀏覽器和OS的不同測試配置的測試覆蓋率接近100％
自動化測試的主要目標是提高應用程式的質量。在計算投資回報率時，您還應該考慮以下事實：瀏覽網站的方式每天都在增加。市場上有成百上千的瀏覽器和裝置，人們可以在其中檢視您的Web應用程式，並且該數目正在定期增長。定義瀏覽器相容性測試矩陣。
擴大覆蓋率的最佳做法
通過執行煙霧測試，單元測試，迴歸測試，並注意缺陷洩漏，可以提高環境覆蓋率。
單元測試–單元測試在執行Web應用程式的測試階段時涵蓋了最多的數量。當您投資並行測試機制以節省時間時，這總是有意義的。
冒煙測試–將修補程式推送到應用程式中時，並行執行冒煙測試是覆蓋測試用例的最佳方法。自動化煙霧測試是每天評估Web應用程式的好方法。
迴歸測試–在當今的敏捷時代，快速部署需要越來越多的迴歸測試來測試版本控制。執行並行迴歸測試可確保每個最新版本都像以前的版本一樣完美執行，從而幫助您在短得多的時間內擴充套件測試範圍。
請記住缺陷洩漏–這是在生產週期中發生的錯誤數量，因為在先前的測試階段未檢測到它們。發生這些情況的原因可能是功能測試覆蓋範圍較小或測試環境不佳。
嘗試使用左移測試方法。這涉及測試人員在應用程式開發之前對其進行驗證。一旦完成特定模組的開發，開發人員還可以通過執行單元測試用例來參與其中。核心思想是儘早開始發現錯誤，最終將降低成本。
找出可重用和冗餘測試用例的數量
重複的測試用例是可能導致測試預算增加的重要因素。重新建立您先前用於不同模組的相同測試用例沒有任何意義。重用測試用例會導致測試速度提高和測試周期縮短。
計算此費用涉及檢查
- 重複測試用例數
- 具有重複元件的測試用例
- 檢測和開發所有這些冗餘測試用例所需的時間。
- 計算使用測試用例管理工具的成本
減少冗餘的最佳做法
- 使用測試用例管理工具查詢重複的指令碼。您可以使用這些工具來儲存帶有自定義欄位的測試，然後可以根據您的要求對其進行個性化設定。使用測試用例管理工具將幫助您快速搜尋冗餘。
- 您還可以開發模組化測試指令碼，以後可以重用。找出經常執行的測試。例如，登入我們的退出功能。為了檢查這兩個是否完美，您必須測試多種變體。建立一個模組化的測試用例，可用於每次登入和登出變體。
使用雲端的Selenium網格執行無憂的自動跨瀏覽器測試
執行方法圍繞著使用Selenium進行測試自動化計算ROI的必要領域。眾所周知，Selenium是一個開放原始碼測試自動化框架，旨在促進Web應用程式測試。現在，您可以自行在本地使用Selenium進行自動化測試，也可以使用提供Selenium Grid的基於雲的工具之一進行自動化測試。
當您通過自己的基礎結構使用Selenium執行自動化測試時，在擴充套件自動化測試套件時，您必須牢記預算。您將如何引入新裝置？新的瀏覽器版本？您現有的計算機還需要大量硬體升級，才能支援Selenium Grid的並行執行。但是，如果要通過雲上的Selenium Grid執行測試自動化，則可以隨專案需求輕鬆擴充套件。
Selenium本身不提供測試報告功能。您可以根據所使用的語言，使用測試自動化框架來提取測試報告。如果您使用的是LambdaTest基於雲的Selenium Grid，則可以通過我們的Open Selenium API提取這些報告。
兩種方法之間的另一個主要區別在於並行測試。使用在本地計算機上定義的Selenium Grid，您將只能在該本地計算機上安裝的瀏覽器上執行測試用例。但是，如果您使用的是基於雲的Selenium Grid（例如LambdaTest），則可以跨多種實際瀏覽器和瀏覽器版本進行測試。
ROI計算技術
現在，我們已經涵蓋了基礎知識，讓我們瞭解用於計算ROI的計算方法。
效率投資回報率
由於自動化測試用例可以全天候執行，因此ROI的計算以天為單位。另一方面，對於手動測試，僅計算測試人員的工作時間，平均為8個小時。構成計算投資回報率基礎的公式是
- （a）自動化測試指令碼開發時間=（每個測試的每小時自動化時間自動化測試案例數量）/ 8
- （b）自動化測試指令碼執行時間=（每個測試自動化測試執行時間自動化測試案例數量ROI週期）/ 18
- （c）自動化測試分析時間=（試驗分析時間 ROI的週期）/ 8
- （d）自動化測試維護時間=（維修時間ROI的週期）/ 8
- （e）手動執行時間=（手動測試執行時間的手動數測試用例*投資回報期）/ 8
注意： ROI的週期是要計算ROI的週數，如果需要手動操作，則除以8。只要完成自動化，就可以除以18。
在效率計算中，主要重點是對組織進行多少有效的自動化測試。金錢因素被認為是次要因素，並非必須包括測試人員的小時計費費率。
降低風險的投資回報率
這涉及獨立計算自動化的收益。我們將再次以使用WebDriver進行跨瀏覽器測試為例，以瞭解其工作原理。在手動測試期間，整個測試團隊過去通常會花費大量時間在多個瀏覽器上重複執行相同的測試用例。引入自動化之後，他們有很多額外的時間來執行生產性工作，例如設計測試用例，分析應用程式等。總之，降低風險的ROI解決了以前未解決的問題。
隨著自動化的實施，測試覆蓋率增加。完全取決於手動測試將導致不必要的錯誤，這些錯誤可能會在交付後出現。因此導致產品質量降低以及測試效率降低。這種可能的損失被認為是一種風險。投資成本沒有變化。僅計算組織可能在沒有實施自動化的情況下可能面臨的金錢損失。
- 鄭重宣告：文章禁止第三方（騰訊雲除外）轉載、發表，事情原委測試窩，首頁抄我七篇原創還拉黑，你們的良心不會痛嗎？
技術類文章精選
- java一行程式碼列印心形
- Linux效能監控軟體netdata中文漢化版
- 介面測試程式碼覆蓋率（jacoco）方案分享
- 效能測試框架第二版
- 如何在Linux命令列介面愉快進行效能測試
- 圖解HTTP腦圖
- 將swagger文件自動變成測試程式碼
- 五行程式碼構建靜態部落格
- 基於java的直線型介面測試框架初探
- JUnit中用於Selenium測試的中實踐
非技術文章精選
- 為什麼選擇軟體測試作為職業道路?
- 寫給所有人的程式設計思維
- 成為優秀自動化測試工程師的7個步驟
- 手動測試存在的重要原因
- 成為自動化測試的7種技能
- 自動化和手動測試，保持平衡！
- 自動化測試生命週期
- 如何在DevOps引入自動化測試
- Web端自動化測試失敗原因彙總