【自動化測試】Web自動化測試 Selenium

?🔥個人主頁：?中草藥

?🔥專欄：【Java】登神長階史詩般的Java成神之路

測試分類

了解各種各樣的測試方法分類，不是為了墨守成規按照既定方法區測試，而是已了解思維為核心，并了解一些專業名詞

根據測試方法分類

白盒測試

白盒測試（又稱結構測試、透明盒測試）是一種基于對系統內部結構、代碼邏輯和實現細節充分了解的測試方法。測試人員需要查看代碼、算法或架構設計，針對性地設計測試用例，驗證內部邏輯的正確性。白盒測試主要分為兩類

靜態測試

通過人工或工具分析代碼的結構、規范、邏輯，不實際執行程序，發現潛在問題。包括：

桌面檢查：人工閱讀代碼 / 文檔，初步檢查邏輯錯誤、代碼規范等（最基礎的靜態自查）。
代碼審查：團隊（如評審會議）對代碼進行正式檢查，從邏輯、性能、安全等多維度發現缺陷。
代碼走查：模擬代碼執行流程（但不運行），“走讀” 代碼邏輯，檢查每一步的合理性。
代碼掃描工具：借助自動化工具（如 SonarQube、PMD 等），批量檢測語法錯誤、安全漏洞、代碼異味（如重復代碼、冗余邏輯）。

動態測試

動態測試通過執行測試用例，觀察代碼運行時的行為，驗證內部邏輯是否正確。主要包含以下六種，我們以代碼塊為例

if(A && B){func1();
}
if(C && D){func2();
}

語句覆蓋

每個語句至少執行一次。

針對A and B:A為T且B為T

針對C or D:C為T或者D為T

得出用例:

用例1: A為T，B為T，C為T，D為F

判定覆蓋

A and B 為 T? ? ? ? ->? ? ? ? A=T B=T? ? ? ? (1)

A and B 為 F? ? ? ? ->? ? ? ? A=T B=F 或?A=F?B=T?或?A=F?B=F? ? ? ? (2)

C or?D?為 T? ? ? ? ->? ? ? ? C=T D=T?或 C=T D=F 或 C=F D=T? ? ? ? (3)

C or D?為 F? ? ? ? ->? ? ? ? C=F?D=F? ? ? ? (4)

得出用例:

用例1:A=T B=T C=T D=F 滿足(1)(3)

用例2:A=T B=F C=F D=F 滿足(2)(4)

條件覆蓋

A????????T????????F

B? ? ? ? T????????F

C? ? ? ? T????????F

D? ? ? ? T????????F

? ? ? ? （5）（6）

得出用例:

用例1:A=T B=T C=T D=T?

用例2:A=F B=F C=F D=F

判定條件覆蓋

結合判定覆蓋和條件覆蓋

得出用例:

用例1:A=T B=T C=T D=T 滿足(1) (3) (5)

用例2:A=F B=F C=F D=F 滿足(2) (4) (6)

條件組合覆蓋

A? ? ? ? B? ? ? ? C? ? ? ? D

T? ? ? ? T? ? ? ? ?T? ? ? ? T

T? ? ? ? F? ? ? ? ?T? ? ? ? T

F? ? ? ? T? ? ? ? ?T? ? ? ? T

F? ? ? ? F? ? ? ? ?T? ? ? ? T

每一行都可以作為一個用例

路徑覆蓋

以冒泡排序為例

public static void sort(int[] array) {for (int i = 0; i < array.length - 1; i++) {for (int j = 0; j < array.length - 1 - i; j++) {if (array[j] > array[j + 1]) {int temp = array[j];array[j] = array[j + 1];array[j + 1] = temp;}}}
}

需要覆蓋的測試路徑:

1) 3,12

2) 3,4,3,12

3) 3,4,5,4,3,12

4) 3,4,5,678,4,3,12

黑盒測試

黑盒測試是一種不關注系統內部結構和實現細節的測試方法。

測試人員將系統視為一個 “黑盒子”，只通過輸入數據和觀察輸出結果來驗證系統是否符合需求規格說明書的要求。因此黑盒測試又稱為數據驅動測試，只注重軟件功能

優點：不需要了解程序內部的代碼以及實現，不關注軟件內部的實現。從用戶角度出發設計測試用例，很容易的知道用戶會用到哪些功能，會遇到哪些問題，鍛煉測試人員的產品思維

缺點：不可能覆蓋所有代碼

灰盒測試

灰盒測試是介于黑盒測試和白盒測試之間的一種測試方法。測試人員不需要完全了解系統內部的所有細節，但會基于部分內部結構信息（如接口設計、數據庫結構、模塊交互邏輯）來設計測試用例，兼顧功能驗證和內部邏輯檢查。

灰盒測試多用于集成測試階段，不僅關注輸入輸出的正確性，也關注程序內部的情況

根據測試階段分類

單元測試

與編碼同步進行，針對軟件的最小組成單元（通常是函數、方法、類或模塊）進行測試，主要采用白盒測試方法，從被測對象的內部結構出發設計測試用例。它是測試金字塔（單元測試→集成測試→系統測試）的基石，也是敏捷開發、持續集成（CI）等流程的核心支撐。

核心目標

驗證單元功能正確性：確保單個函數 / 方法在各種輸入下返回預期結果，符合設計邏輯。
早期發現缺陷：在開發初期（編碼階段）暴露問題，避免缺陷流入后續集成或系統測試階段，降低修復成本。
支持快速迭代：為代碼重構、優化或需求變更提供 “安全網”，確保修改后原有功能不受影響。

java中提供很多單元測試框架，如Junit提供很多注解與斷言函數，有效提升開發單元測試腳本效率

測試階段：編碼后或者編碼前(TDD)

測試對象：最小模塊

測試人員：白盒測試工程師或開發工程師

測試依據：代碼和注釋+詳細設計文檔

測試方法：白盒測試

測試內容：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試

集成測試

集成測試（也稱 “組裝測試”）是在單元測試通過后，將多個已測試的模塊（或組件）按照設計要求組合起來，驗證模塊之間的接口、交互邏輯是否正確的測試過程。

核心目標

發現模塊間交互的問題：例如模塊 A 傳遞給模塊 B 的數據格式錯誤、接口參數不匹配、依賴關系沖突（如模塊 A 未完成時模塊 B 提前調用）等。
驗證 “模塊組合” 是否符合設計預期：單個模塊功能正確≠組合后功能正確，集成測試確保模塊協作時整體邏輯無誤。

測試階段：一般單元測試之后進行

測試對象：模塊間的接口

測試人員：白盒測試工程師或開發工程師

測試依據：單元測試的模塊+概要設計文檔

測試方法：黑盒測試與白盒測試相結合

測試內容：模塊之間數據傳輸、模塊之間功能沖突、模塊組裝功能正確性、全局數據結構、單模塊缺陷對系統的影響

系統測試

系統測試是在集成測試通過后，將整個軟件系統作為一個完整的實體，在接近真實的環境中，驗證系統是否滿足需求規格說明書（用戶需求）的測試過程。

測試階段：集成測試通過之后

測試對象：整個系統(軟、硬件)

測試人員：吳黑盒測試工程師

測試依據：旁需求規格說明文檔

測試方法：黑盒測試

測試內容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

冒煙測試

冒煙測試起源于硬件測試：如果電路板通電后 “冒煙”（無法正常啟動），就無需進行后續復雜測試。在軟件中，它是對軟件最核心、最基礎功能的快速驗證。

通常在軟件開發早期階段進行，目的是判斷軟件是否 “可測”—— 即是否穩定到足以支持后續更詳細的測試（如集成測試、系統測試）

核心目標

快速排查阻斷性缺陷：驗證軟件的核心流程是否能跑通，是否存在導致測試無法進行的嚴重問題（如無法啟動、登錄失敗、核心功能崩潰等）。
過濾 “無效版本”：避免將時間浪費在明顯不穩定的版本上（例如開發剛提交的版本連基本功能都用不了，就無需進行耗時的系統測試）。

回歸測試

回歸測試是指在軟件發生修改（如修復 bug、新增功能、優化代碼）后，重新驗證原有功能是否依然正常的測試過程。其核心邏輯是：“修改可能引入新問題，需要確認歷史功能未受影響”。

在軟件開發的后期，通常在每次代碼修改或新增功能后執行

核心目標

發現 “修改后遺癥”：防止因代碼變更（即使是微小修改）導致原有正常功能出現異常（例如修復了支付 bug，卻導致訂單狀態更新失敗）。
保障軟件穩定性：確保軟件在迭代過程中，歷史功能的正確性不被破壞，維持整體質量。

根據實施組織分類

α 測試（Alpha Testing）

α 測試是軟件開發接近完成時，由開發團隊內部或指定的內部用戶（如公司員工、QA 團隊）在模擬的用戶環境中進行的測試。

核心特點：

測試人員：以內部人員為主，不對外開放。
測試環境：通常是開發方搭建的 “模擬用戶環境”（盡量接近真實使用場景，但仍受開發方控制）。
測試階段：在軟件功能基本完成、但可能仍有較多缺陷時進行（早于 β 測試）。
主要目的：發現軟件的功能性缺陷、邏輯錯誤、界面問題等，驗證核心功能是否可用，排除明顯的 “硬傷”。
結果處理：測試中發現的問題會直接反饋給開發團隊，快速修復后再進入下一階段。

β 測試（Beta Testing）

β 測試是軟件基本完成開發、經過 α 測試修復主要問題后，由真實用戶在實際使用環境中進行的測試，相當于 “公開試用”。

核心特點：

測試人員：外部用戶（可能是特定用戶群體，也可能是公開招募的試用者）。
測試環境：用戶自己的真實環境（如個人電腦、手機等），不受開發方控制。
測試階段：晚于 α 測試，是發布前的最后一輪大規模測試。
主要目的：收集用戶實際使用中的反饋，發現 α 測試中未暴露的問題（如兼容性問題、性能瓶頸、用戶體驗缺陷等），驗證軟件在真實場景下的穩定性。
結果處理：用戶反饋的問題會被整理后交給開發團隊，作為最終優化的依據，修復后即可正式發布。

自動化測試

自動化測試是指通過工具、腳本或代碼自動執行測試用例，替代或輔助人工測試的過程。其核心是將重復、機械的測試操作（如點擊按鈕、輸入數據、驗證結果等）轉化為可自動運行的程序，從而提高測試效率、降低人為誤差，并支持軟件在快速迭代中持續驗證質量。

Web自動化測試

Web 自動化測試是指通過自動化工具或腳本模擬用戶在 Web 瀏覽器中的操作（如點擊按鈕、輸入文本、跳轉頁面等），對 Web 應用的功能、兼容性、性能等進行自動化驗證的測試手段。

要實現Web的自動化測試我們需要 Web+驅動+Selenium

這三者的交互關系如下所示

1. 通過selenium編寫的自動化腳本代碼中在ChromeDriverService中創建一個服務

2.通過創建好的服務打開webdriver，安裝在本地的驅動服務IP為localhost，PORT為ChromeDriverService中創建的端口號，該服務地址為selenium向webdriver發送請求的服務地址。

3.向瀏覽器驅動程序發送HTTP請求，瀏覽器驅動程序解析請求，打開瀏覽器，并獲得sessionid，如果再次對瀏覽器操作需攜帶此id

4.打開瀏覽器后，所有的selenium的操作(訪問地址，查找元素等)均通過創建好的服務鏈接到webdriver，然后使用execute發送請求

5.驅動收到請求并對請求進行解析，轉成瀏覽器能夠解析的腳本并發送給瀏覽器，瀏覽器通過請求內容執行對應動作

6.瀏覽器再把執行的動作結果通過瀏覽器驅動程序返回給測試腳本

<dependencies><dependency><groupId>io.github.bonigarcia</groupId><artifactId>webdrivermanager</artifactId><version>5.8.0</version><scope>test</scope></dependency><dependency><groupId>org.seleniumhq.selenium</groupId><artifactId>selenium-java</artifactId><version>4.0.0</version></dependency>
</dependencies>

WebDriverManager是一個開源Java庫，以完全自動化的方式對Selenium WebDriver所需的驅動程序(如chromedriver、geckodriver、msedgedriver等)進行管理(即下載、設置和維護)，自版本5起，WebDriverManager還提供了其他相關功能，如發現本地系統中安裝的瀏覽器的能力，構建WebDriver對象(如ChromeDriver、FirefoxDriver、EdgeDriver等)

Selenium 是目前最流行的開源 Web 自動化測試框架，由一系列工具組成，支持跨瀏覽器、跨平臺、多編程語言，廣泛用于 Web 應用的功能測試和回歸測試。

用一個demo來驗證它的功能

import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;public class AutoTest {public void test01(){WebDriverManager.chromedriver().setup();ChromeOptions options = new ChromeOptions();//允許訪問所有連接options.addArguments("--remote-allow-origins=*");WebDriver driver = new ChromeDriver(options);//請求地址driver.get("https://www.baidu.com/");driver.findElement(By.xpath("//*[@id=\"chat-textarea\"]")).sendKeys("Java");driver.findElement(By.xpath("//*[@id=\"chat-submit-button\"]")).click();driver.quit();}
}