Web 測試需要驗證網站以確保其正常工作并實現其目的。這些活動可以包括檢查網站上的所有鏈接是否有效，以及網站是否與不同的瀏覽器、設備和操作系統兼容。測試網站還可以確保其安全并免受攻擊。

在這個技術互聯的世界中，網站無處不在。從坐在家里支付賬單或購買您長期以來想要的物品，我們都需要一個網站。甚至在登陸這些網站之前，我們都會在搜索引擎上搜索我們的查詢，比如谷歌，這是一個網站。

對于用戶而言，網站在他們的日常生活中扮演著不可或缺的角色。作為開發人員和測試人員，這直接轉化為維持業務并讓用戶參與我們的網站，我們需要確保用戶端沒有任何問題。實現這一目標的唯一方法是通過有效的 Web 測試，包括使用適當的方法和技術并了解這樣做的原因。

什么是網絡測試？

Web 測試過程可以概括為一句話“Web 測試是測試 Web 應用程序的過程”。然而，這個陳述過于龐大而難以理解，而且對于測試人員來說太混亂了，無法開始這個過程。我們知道我們想要測試網絡應用程序，但“測試”它意味著什么？

作為測試人員，您已通過驗證功能、應用程序的 UI、UX 和響應能力來完成網站測試。這些似乎是網絡的四大支柱。一切看起來都很好，代碼被推送到生產環境，并最終推送給所有用戶。

然后，幾天后，您收到有人滲透該網站并竊取用戶數據的消息。這是一個嚴重的問題，可能會導致整個業務崩潰。那么，這是測試團隊的責任嗎？這應該是網絡測試的一部分嗎？是的！

任何圍繞 web 應用程序的東西都適合放在 web 測試的圈子里。這包括 Web 應用程序的安全性、有助于通信的 API、測試性能指標、負載指標等。即使在單個瀏覽器上一切正常，測試人員也必須在每個目標瀏覽器上檢查相同的標志。

為什么 Web 測試很重要？

我們在上一節中與安全相關的風險的小例子很好地證明了 Web 測試的重要性。但是，在真正的威脅發生之前，例如入侵網站，用戶通常不會意識到這些情況。跳過這些區域，當我們討論清晰可見的區域時，比如用戶界面，測試網站和非測試網站的效果在用戶面前一目了然。

讓我們舉三個簡單但“昂貴”的例子來演示網絡測試對用戶的影響。

案例一：GFK（Growth From Knowledge）

第一個例子是圍繞“購買”CTA 按鈕，您可能一直注意到該按鈕將產品放在下方（或側面，具體取決于設備）。它會將您帶到結帳頁面，您可以在其中完成其他任務，例如付款。

作為用戶或測試人員，您認為設計不當且用戶難以點擊的“購買”按鈕的成本是多少？還是有時甚至不引人注意的？

GFK 是一家不得不花費大量資金進行用戶體驗研究的組織，因為他們想知道銷售不佳的原因。正如您可能已經猜到的那樣，這是一個“購買”按鈕，但位置不正確并且用戶沒有注意到。他們通過將此按鈕放置在更多位置并優化其代碼以使其流暢來對其進行更改。結果，他們的年銷售額高達 5 億美元。

案例二：微軟

從用戶體驗出發，我們現在舉一個用戶界面的例子。十年前，微軟在他們專注于 Bing 的演講中說，“搜索可以不僅僅是十個藍色鏈接。”

具有諷刺意味的是，“藍色”部分是微軟對其搜索結果進行測試時的主要問題之一。據透露，正如 Paul Ray（Bing 的用戶體驗經理）早些時候所說，藍色有點淺，“缺乏自信”。他們將其更改為 #0044CC，結果，他們的廣告收入躍升至額外的 8000 萬美元，告訴全世界單一顏色的重要性。

案例三：亞馬遜

我們舉的最后一個例子是網絡性能，它是網絡測試的一個組成部分。早在 2009 年，電子商務巨頭亞馬遜就曾直言不諱地忽視其網站的性能。他們透露，每 100 毫秒的延遲會使他們損失 1% 的銷售額。如果我們將此調整為亞馬遜 2014 年的收入，1% 的銷售額將超過 8 億美元。

Tabb Group 在他們題為“毫秒的價值：尋找交易基礎設施的最佳速度”的優秀研究論文中發表了類似的發現。專注于電子交易基礎設施的研究表明，如果平臺僅比競爭對手落后 5 毫秒，經紀商面臨的損失可能高達每毫秒 400 萬美元（是的，一秒的千分之一）。?

這三個示例探索了 web 測試的三個主要領域，作為測試人員或用戶，這些領域對我們來說可能看起來并不那么重要。它們展示了 Web 測試的重要性以及我們需要如何覆蓋它周圍的每個區域，因為我們可能永遠不知道哪個區域會反擊，從而導致高額收入損失。

Web 測試生命周期

Web 測試生命周期類似于軟件測試生命周期，這是合乎邏輯的，因為它們是同一過程的一部分。

清單準備

我們在 Web 應用程序測試中考慮的第一件事是根據 Web 應用程序標準創建清單。UI 測試、跨瀏覽器測試等。這是用于測試 Web 應用程序的通用清單。測試人員也可以從以前的項目中采用它。

需求收集

在安排了 Web 應用程序的通用和通用事物之后，我們專注于收集通常特定于項目的需求。這可能包括從客戶收集的功能或某些特定要求。一個好的做法是將它們安排成邏輯集群，以后可以將它們組合成一個套件。

測試計劃與設計

現在，我們繼續計劃和安排這些測試以有效地執行測試階段。在這里，我們創建了一個測試計劃、測試計劃文檔和測試設計，以及它的文檔以供后續階段使用。

測試執行技術

接下來，我們制定測試執行計劃，以及特定于項目、團隊或組織的測試執行技術。

測試執行

在這個階段，我們利用我們在早期階段所做的所有計劃來執行實際的測試執行。

報告

最后，我們對所有觀察結果和測試用例結果進行詳細報告，以便與團隊共享、進一步分析或未來。

Web 應用程序的類型及其測試點

由于高人氣和需求，Web 應用程序領域變得廣闊。因此，有時我們會用其他名稱來指代特定類型的網絡應用程序，這些名稱表示更大圖片的特定子域。例如，如果您在一個自動刷新的網站上觀看現場比分，它就變成了一個動態網站。如果網站在線銷售商品，它就會成為電子商務網站，依此類推。

如果我們查看這些小的子域，我們可能會得到一長串 Web 應用程序類型。實際上，我們只考慮四個大部門，并且只關注這些部門。

1. 靜態網絡應用

靜態 Web 應用程序僅包含靜態網頁。這些頁面本質上是靜態的（或固定的）并從服務器呈現給用戶，即所有用戶將看到相同的內容。靜態 Web 應用程序的一個示例是顯示您的簡歷的簡歷網站。

當性能和速度是主要關注點時，最好使用靜態 Web 應用程序。由于不是根據用戶輸入制作，不涉及數據庫查詢，所以可以直接快速展示。它們也很可靠，因為您無需擔心異常用戶輸入產生的不良行為。然而，不利的一面是，靜態網頁并不能為用戶提供太多東西。

在靜態 Web 應用程序中測試什么

由于靜態 Web 應用程序很簡單，因此不需要復雜的測試機制。主要關注領域是用戶界面測試和響應測試。

2. 動態網絡應用

動態 Web 應用程序與靜態 Web 應用程序相反。這里，網頁上的內容可能會根據用戶的輸入或交互而改變。動態 Web 應用程序具有編寫邏輯代碼的后端系統。當用戶提供輸入時，邏輯在后端運行，并將結果相應地發送到客戶端。

例如，Netflix 是一個動態網站，您和我會根據我們與它的互動行為看到不同的推薦。

在動態 Web 應用程序中測試什么

動態 Web 應用程序可以像定期更新板球評論一樣簡單，也可以像 Netflix 一樣復雜，具有數百個微服務和機器學習與 AI 集成。

它們還可能包含帶有每個用戶特定頁面的登錄模塊。所有這些都需要對 Web 測試和復雜技術有深刻的理解。例如，功能測試和可用性測試，僅舉幾例。由于涉及個人數據，此處可能還需要進行安全和API 測試。

3.電子商務網絡應用

當今最流行的 Web 應用程序，尤其是在后 COVID 世界中，是電子商務。這些 web 應用程序專注于將商品銷售到買家的位置，例如付款、用戶數據等。

在動態 Web 應用程序中測試什么

電子商務 Web 應用程序是動態應用程序的一部分，但單獨涉及它的原因是它要經過大量的研究和審查。根據eCommerceDB 的數據，2021 年美國電子商務市場產生了 8620 億美元的收入。這意味著即使是 CTA 按鈕的顏色也至關重要，因為它可以影響數百萬美元。因此，在電子商務測試方面，我們必須保留所有測試方法。

主要的測試方法包括安全測試、功能測試、用戶界面測試和性能測試，僅舉幾例。

4. 移動網絡應用

另一個主要的 Web 應用程序部分是移動 Web 應用程序，它是在移動設備上查看的 Web 應用程序。早些時候，只需重新縮放網頁就足夠了。但現在，根據Statista 的數據，移動用戶將占網站訪問者總數的 60%，這使得移動優先設計成為當務之急。

上圖顯示了 LT 瀏覽器中顯示的移動網站和桌面網站之間的區別。它是 LambdaTest 平臺的一款適合移動設備的測試工具，可讓您跨 53 種以上的預裝設備視口測試網站的響應能力，適用于移動設備、平板電腦、臺式機和筆記本電腦。

一個適合移動設備的網站需要快速、輕松地導航，并具有出色的用戶體驗和界面，即使這意味著為移動用戶開發一個單獨的網站。

在移動 Web 應用程序中測試什么

雖然每種類型的測試對于移動 Web 測試都是必要的，但測試人員需要在這里優先考慮響應式和跨瀏覽器測試。由于移動設備數量眾多，我們無法針對每個設備開發特定的頁面。

這就是響應式測試通過根據視口自動工作并確保無論用戶使用什么設備，體驗都將與桌面用戶保持一致，從而使事情變得更容易的地方。

Web 測試的要素

當我們著手測試 Web 應用程序時，我們通常會考慮以下將幫助我們順利通過旅程的重要元素。

瀏覽器

第一個也是最關鍵的元素是瀏覽器。由于我們處理的是“網絡”應用程序，因此它只會在瀏覽器上顯示給用戶，無論是在臺式機、平板電腦還是移動設備上。但問題是，如果我們也考慮它們的版本，瀏覽器太多了。

Google Chrome 目前的版本是 110，Firefox 是 108，Opera 是 96。每個版本都會棄用一些東西，并添加一些新東西，這讓開發人員清楚地知道我們無法滿足所有瀏覽器。因此，在開始測試部分之前，我們需要列出顯示網站所需的瀏覽器。它們也被稱為“目標瀏覽器”。

這些是唯一應該參與您的測試狂潮的瀏覽器。如果對舊瀏覽器有特定要求，測試人員可以將它們保留為特殊要求，并僅為這些功能創建測試用例。

設備

一旦我們涵蓋了瀏覽器，我們就會到達用戶打開瀏覽器的設備。與“目標瀏覽器”一樣，我們完全測試網站的設備稱為“目標設備”。由于設備在市場上不斷被淘汰，而更新的設備不斷出現，我們總是需要相應地更新我們的列表。

測試工具

我們的 Web 測試結構中第三個最重要的元素是測試工具（或多個工具）。如果沒有好的工具，我們在本教程中討論的任何內容以及我們為測試計劃的任何內容都無法實現。

雖然一個完美的工具非常適合您的場景，但一般來說，勾選以下復選框的工具才被認為值得選擇用于 Web 測試：

• 所有主要瀏覽器及其版本。
• 所有主要設備。
• 所有主要的移動操作系統及其版本。
• 所有主要的桌面操作系統及其版本。
• 多種分辨率覆蓋最大范圍。
• 該工具應在 Android 模擬器或真實設備上打開瀏覽器。應避免使用 iOS 模擬器進行完整的網絡測試（某些區域除外）。
• 應提供自動化測試支持。
• 如果該工具必須用于組織，則需要將大量不同的集成與該工具相關聯。對于個人來說，這一點可以忽略不計。
• 測試特定功能對于 Web 測試工具來說是絕對必要的。例如，屏幕截圖捕獲、記錄測試會話、與隊友共享選項等。
• 預計該工具是可行的，尤其是對個人和初創公司而言。
• 為了進行分析和進一步調試，該工具應該有一個很好的報告系統和儀表板，用于總結測試運行和其他信息。

對 Web 測試的關注提高了當今使用的測試工具或平臺的標準。在 LambdaTest 平臺上開始 Web 測試很容易。讓我們看看如何執行它：

• 免費注冊并登錄到您的 LambdaTest 帳戶。
• 從左側邊欄菜單中，訪問“實時測試”>“瀏覽器測試”。

• 輸入測試 URL，然后選擇桌面或移動設備。如果要在桌面上測試，請選擇瀏覽器的“ RESOLUTION ”、“ OS ”和“ VERSION ”。點擊“開始”。
  

  

它將帶您進入基于云的操作系統，您可以在其中運行 Web 測試。

現在我知道你可能在想什么。如果我們從未發布過 Web 應用程序或購買過域名，會發生什么情況？這是一個常見的問題，因為開發人員經常從較低級別測試他們的應用程序以使調試更容易。

如果一次測試所有 Web 應用程序，調試和糾正錯誤的時間可能會成倍增加。在這種情況下，我們使用 LambdaTest Tunnel 功能進行本地頁面測試。它有助于通過 SSH 連接本地系統上托管的 Web 應用程序，并在 LambdaTest 的云基礎設施上進行測試。

經驗

在測試之前通常不考慮的最后一個因素是隊友的經驗。無論我們使用多么出色的工具，無論我們通過在線閱讀理論書籍和博客嘗試進行多少計劃，經驗豐富的測試人員仍然可以指出系統中的某些錯誤區域。復雜系統（例如 Web 應用程序）中的經驗價值非常重要。隊友之間應該始終考慮到這一點。

Web 測試的角度

Web測試的角度是指針對應用程序的各個角度的不同類型的測試方法。它們中的大多數對于 Web 測試是強制性的，除了少數可能取決于項目。

功能測試

Web 應用程序的功能測試旨在測試 Web 應用程序的功能，這可以說是重中之重。如果這些功能不起作用，那么 Web 應用程序對于最終用戶來說就等于沒有了。

作為測試人員，我們需要覆蓋所有為 Web 應用程序提供一個或多個功能的部分，如上圖所示。這還將包括應用程序的用戶界面和用戶體驗。這種測試類型的最終目標是確保，除了功能之外，Web 應用程序作為一個單元運行，即一個完整的系統。這在定義上類似于端到端測試。

接口測試

該應用程序包含多個接口，使它們協同工作。根據項目的不同，這可能會有所不同。通常，以下四個接口涵蓋了完整的系統：

1. 在服務器端邏輯上工作的服務器端接口。
2. 應用程序編程接口 (API) 工作在系統的通信部分。p
3. 數據庫接口工作于數據庫的數據存儲、檢索、更新等部分。
4. 用于應用程序和用戶之間交互的用戶界面。

涵蓋了這四個方面，接口測試部分就結束了。

可用性測試

可用性測試旨在確定 Web 應用程序對最終用戶的“友好性”。這種類型的測試挖掘出開發人員或測試人員可能看不到的缺陷。

例如，您能否輕松瀏覽 Web 應用程序？作為開發人員和測試人員，由于我們已經通過每天處理應用程序而知道所有選項和按鈕的位置，因此他們所做的可用性測試可能不會獲得太多好處。

通過可用性測試的最佳方式是通過最終用戶自己。他們可能探索的領域是：

• 操作 Web 應用程序有多容易。
• 在電子商務 Web 應用程序中記住基本選項（例如“您的訂單”）是多么容易。
• 申請體驗的滿意度如何？
• 您是否覺得 Web 應用程序令人滿意，或者是否有任何顏色或部分位置錯誤？

這些問題應該在生產前擺在最終用戶面前，以深入了解應用程序的可用性。

非功能測試

功能測試未涵蓋的 Web 應用程序的屬性通常使用非功能測試進行測試。本節可能包括以下內容：

• 負載測試
• 性能測試
• 壓力測試
• 跨瀏覽器測試
• 瀏覽器兼容性測試

根據項目可以有其他的。

安全測試

Web 應用程序的安全測試在當今世界是絕對必要的。據Cybersecurity Hub稱，2022 年發生了 4100 起數據泄露事件。這些只是那些公開披露的。如果我們考慮對 Web 應用程序的黑客攻擊，2022 年每天有 30,000 個網站遭到黑客攻擊，影響了 64% 的在線網站。

您的網站很容易成為其中之一。為避免此類情況，請始終構建高安全性的網站，并測試其是否存在任何泄漏、后門、注入防護和您的網站在現實世界中可能經歷的其他攻擊。

自動化在 Web 測試中的作用

自動化測試從一開始就是所有測試人員的朋友。它快速移動事物、執行事物并快速包裝事物。隨著當今 Web 應用程序的規模，自動化測試已成為 Web 測試的必需品，而不是一種選擇。

我們第一次接觸自動化測試是在開發產品并用它編寫單元測試時。隨著新功能的開發，這些單元測試不斷增加，通常達到數千個。

然后，我們提交回歸測試代碼，對集成代碼運行回歸測試以檢查是否有任何問題。最后，我們繼續討論 CI/CD 管道，它包含自己的測試并考慮構建的穩定性和其他方面。當我們選擇自動化測試時，所有這些事情都不需要人工干預。我們編寫腳本，然后在新集成的代碼上重復執行它們。

我們在自動化 Web 測試中面臨的唯一挑戰是投資回報，這可能需要自己的時間。一開始，我們可能不得不在自動化測試上投入大量資金。這包括聘請自動化工程師、設置自動化基礎設施、編寫自動化腳本所花費的時間，以及開發支持自動化測試的 Web 測試工具。

但好在這都是一次性投資。使用自動化 Web 測試的主要動機是從手動測試域中刪除重復性任務，讓它專注于探索性測試部分。因此，即使在今天，一次測試運行的成本更高，相同的測試也會運行數千次，從而為我們提供下圖。

如果組織的未來目標是長期進入市場并不斷推出新功能，那么自動化測試可能是一個很好的武器。

Web 測試面臨的挑戰

盡管到目前為止，通往網絡測試的道路可能看起來一帆風順，但中間還是有一些小插曲。測試人員可能面臨的主要挑戰如下：

確保應用程序的安全

Web 應用程序的安全性是一個領域，在有人利用安全性之前，沒有人可以保證并宣稱“此 Web 應用程序是完全安全的”。雅虎認為他們進行了安全測試并且他們的網站是完全安全的，直到有人在 2013 年 8 月入侵并竊取數據。

然后，他們再次認為他們現在擁有一個完全安全的網站，直到有人在 2014 年再次從 5 億個帳戶中竊取數據。所以你永遠無法確定安全性，并且總是希望它沒有受到攻擊。這是執行和報告 Web 測試分析時的主要挑戰。

瀏覽器中的碎片

另一個主要的網絡測試挑戰是網絡瀏覽器的碎片化。一個 Web 瀏覽器有數百個版本，每個版本都會棄用一些 API 或其他功能，并添加一些。

如果該 API 深入到您的應用程序中，則刪除它及其依賴項將成為一項艱巨的任務。考慮到瀏覽器如何每十五天發布一個新版本，這就成為使網站與最新技術保持一致的主要挑戰，尤其是當網站龐大而復雜時。

應對用戶期望

隨著新技術和快速互聯網在全球范圍內可用，用戶的期望已經提高到十年前的水平。

在 2022 年的一項調查中，46% 的用戶永遠不會返回到加載緩慢的網站，預期時間約為 4 秒。六年前，這個數字還是35% 。

滿足用戶的期望意味著在每個域中匹配加載時間和其他方面，例如更快的性能，或者與新的 UI、UX 和可用性方面并駕齊驅。用戶對他們訪問的每個網站都有更高的期望，而在每個部門應對這些期望是團隊今天面臨的主要挑戰。

同一用戶的跨平臺一致性

單個用戶很可能擁有不止一臺個人設備。在擁有多臺設備的用戶中，40%的用戶在一臺設備上開始一項活動，然后在另一臺設備上完成。這是一種常見的做法，各個國家/地區的數字可能會有所不同，在英國等發達國家安全地超過 50% 大關，其數字為 60%。這些活動通常是多天的活動，所有這些用戶都希望他們的數據能夠跨設備保持一致。他們想要的不僅僅是 cookie，還有實際數據。

例如，亞馬遜提供了一個“愿望清單”功能，用戶通常可以在其中添加他們希望在未來購買的產品。幾天后，在他們的桌面上瀏覽時，用戶希望他們的愿望清單在該平臺上可用，即使產品是通過移動設備添加的。

這是一個小例子。跨平臺一致性可以超越可見的數據，比如用戶行為一致性，在各個平臺上等等，這可能涉及到跨設備的建議和推薦。

這成為網絡測試部分的主要挑戰，因為它增加了一層審查，這需要大量的人工干預。這需要時間并給測試人員和 QA 帶來壓力。

Web 測試中應遵循的最佳實踐

在本綜合指南的最后，讓我們重點介紹在運行 Web 測試時應遵循的最佳實踐。

不要錯過跨瀏覽器測試

很多時候，測試人員可能會覺得在單一類型的瀏覽器上進行測試可以滿足其所有版本。因此，他們可能會通過在所有瀏覽器的最新瀏覽器版本上執行測試來結束測試。這可能會在用戶端造成問題，因為很多用戶在日常生活中不使用最新版本。

這里的最佳實踐始終是跨不同版本和瀏覽器執行跨瀏覽器測試。這將提供主要但不是最新版本的見解和錯誤。

始終包括探索性測試

探索性測試，顧名思義，是在沒有任何指導方針或嚴格的預定義計劃的情況下，專注于探索 Web 應用程序的測試。我們只是像最終用戶一樣打開網絡應用程序，并以敏銳的眼光觀察應用程序的行為，不斷探索所有模塊。

在這里，我們發現了許多可能永遠不會被自動化覆蓋或永遠不會被覆蓋的錯誤。將它包含在我們的測試階段可以幫助我們調試可能直接從最終用戶那里出現的問題。

認真對待績效指標

您最終將通過經驗學習的最佳實踐是與您的 Web 應用程序相關的性能指標的嚴肅性。僅僅運行性能測試是不夠的。我們還應該根據標準分析這些指標。

如果您的網站以前加載時間為 0.2 秒，現在為 0.5 秒，則它仍在安全范圍內。但是，我們應該知道這些變化的原因，因為如果不認真對待它們最終會破壞系統。

知道你的系統在哪里崩潰

一個對您總是有用的額外最佳實踐是了解您的系統的局限性。無論您在市場上的知名度有多大，網站有多復雜和強大，它總會有一定的局限性。它可以接受的最大請求數是多少？各個地區的延遲是多少？一次可以接待多少訪客？

回答更多此類問題將使您在災難發生前做好準備。

結論

在 1900 年代初期，沒有人會想到賣家可以在不與買家會面或交談的情況下將他們的商品銷往全球任何國家。當這樣的場景在今天每一秒都發生時會發生什么？想要出售物品的人在搜索引擎上搜索“如何出售物品”。

然后在找到答案后，他們訪問一個平臺，注冊并上傳必要的產品信息。在世界的另一端，有人想購買商品并在另一個搜索引擎上搜索“在線購買 XYZ”。他們獲得鏈接并通過第三方網站 Paypal 購買。然后賣家發送包裹并提供快遞頁面的鏈接以跟蹤包裹。

如上所述，在一個簡單的交易中，我們需要五個在不同領域工作的網站。當一個東西擁有如此強大的力量，而我們是背后的力量時，我們能冒險不經測試就發布網站嗎？我們絕對不能！

Web 測試是一門藝術，考慮到它在這個過程中需要多少角度和曲折。它需要高度的奉獻精神，中間有很多意想不到的事情。