說實話被公司臨時安排搞自動化測試時我第一反應(yīng)是有點慌的。雖然Java寫了兩年Selenium也聽人聊過但真正要把IDEA、Java、Selenium、TestNG、Maven這五樣?xùn)|西串起來的時候才發(fā)現(xiàn)網(wǎng)上教程要么是十幾年前的舊版本要么只講單個工具不講整體聯(lián)動。折騰了整整一個周末從環(huán)境配置到第一個用例跑通中間踩的坑比寫代碼的時間還多。這篇就順著我的實操路徑把這套組合從零到一怎么搭、為什么要這么配、哪些地方特別容易翻車一次性講清楚。不管你是剛接觸自動化測試的Java開發(fā)還是準(zhǔn)備給團隊搭一套框架的測試工程師照著走基本能少走一半彎路。1. 為什么是這套組合Selenium、TestNG、Maven在自動化里各管哪一段很多人一開始容易混淆一個問題Selenium和TestNG都是Java庫Maven是構(gòu)建工具IDEA是編輯器這四樣?xùn)|西加在一起到底是怎么協(xié)作的我習(xí)慣用一個類比來解釋——Selenium是手TestNG是大腦Maven是物流系統(tǒng)IDEA是工作臺。1.1 Selenium解決的是怎么操作瀏覽器的問題Selenium WebDriver通過瀏覽器原生的驅(qū)動接口ChromeDriver、GeckoDriver等和瀏覽器通信它可以模擬點擊、輸入、滾動、截圖、執(zhí)行JavaScript等一系列操作。它不關(guān)心你的用例該怎么組織不關(guān)心測試報告長什么樣也不關(guān)心依賴從哪下載。它的全部職責(zé)就是根據(jù)你寫的定位表達(dá)式找到頁面元素然后執(zhí)行操作。Selenium 4相比3.x最大的變化是把頁面相對定位Relative Locator和窗口管理做得更順手了同時把之前獨立的WebDriverManager思路做進(jìn)了官方庫的一部分。后面我會細(xì)說這套機制的運行原理這里先記住一句Selenium解決的是能不能操作的問題而不是該不該操作和怎么管理操作的問題。1.2 TestNG負(fù)責(zé)組織測試生命周期和執(zhí)行策略TestNG這個名字是Testing Next Generation的縮寫它借鑒了JUnit的優(yōu)點又增加了很多JUnit早期沒有的能力比如測試分組、依賴關(guān)系、參數(shù)化、并發(fā)執(zhí)行、失敗重跑。這些都是自動化測試框架的剛需。舉一個最簡單的場景你沒有TestNG只有Selenium你寫一個main方法從頭跑到尾一旦中間某個步驟失敗了后面的用例全部中斷而且沒有報告、沒有斷言統(tǒng)計。而TestNG能把每個測試方法獨立管理一個方法失敗不影響另一個方法的執(zhí)行執(zhí)行完統(tǒng)一生成測試報告數(shù)據(jù)驅(qū)動和分組過濾也都是自帶的。1.3 Maven管理依賴和構(gòu)建流程這是很多初學(xué)者忽略的關(guān)鍵。我見過太多人搭Selenium環(huán)境的時候手動下載jar包然后右鍵Add as Library搞了一堆依賴還老沖突。有了Maven所有依賴都在pom.xml聲明版本Maven自動去中央倉庫拉取自動傳遞依賴比如你引了selenium-java它會把selenium-api、selenium-remote-driver等子模塊一起帶上完全不用手工處理jar包。Maven還有一個作用經(jīng)常被忽略通過maven-surefire-plugin來執(zhí)行TestNG的 testng.xml讓自動化測試可以一鍵用命令行跑起來這一步是后面接入CI/CD流水線的基礎(chǔ)。沒有Maven你只能在IDEA里點Run換一個人換一臺電腦可能就跑不起來了。所以Maven在這里的真正價值是工程化不只是管理依賴文件。2. 環(huán)境準(zhǔn)備JDK、Maven、IDEA三方版本搭配和配置細(xì)節(jié)開始寫代碼之前先把環(huán)境處理干凈。這個階段看似簡單實際最容易出問題而且報錯信息五花八門新手很難排查。我建議按下面的順序安裝和配置。2.1 JDK版本選型不要盲目追新Selenium 4.x對Java版本的要求比較寬松Java 8以上都能跑TestNG 7.x最低也支持Java 8。但這里我要提醒一個Maven的兼容性問題Maven 3.9.x雖然官方聲明支持Java 8但部分功能在高版本JDK下表現(xiàn)更好。如果你想省事直接用JDK 11或JDK 17都行如果項目里還有其他老系統(tǒng)的約束只能用JDK 8那Maven建議用3.6.3或3.8.8這一檔別上3.9.x。我的建議是測試工程獨立的話JDK 17 Maven 3.8.8是當(dāng)前最穩(wěn)的組合。JDK 17是LTS長期支持版本Maven 3.8.8對上位穩(wěn)定IDEA 2022和2023版本都原生支持。安裝JDK時有一個特別容易踩的坑不要只裝JRE要裝完整JDK。Selenium可以不依賴Java編譯不是Selenium的代碼需要javac編譯JRE是不帶編譯器的。另外配置JAVA_HOME環(huán)境變量時路徑不要指到C:\Program Files\Java\jdk-17的bin目錄要指到JDK的根目錄。Path里再追加%JAVA_HOME%\bin。安裝完在命令行輸入java -version和mvn -version如果能正常輸出版本信息說明基礎(chǔ)環(huán)境沒問題。2.2 Maven下載和配置倉庫鏡像和本地倉庫路徑提前設(shè)好Maven下載地址不要隨便從第三方網(wǎng)站下直接去Apache官網(wǎng)的Maven項目頁面找到下載鏈接。Windows用戶下載apache-maven-3.8.8-bin.zip即可解壓到一個沒有空格和中文的路徑習(xí)慣上放D:\dev\apache-maven-3.8.8。解壓后需要改的核心文件是conf\settings.xml。這個文件里面有兩處必須配置第一處是本地倉庫路徑。默認(rèn)是C:\Users\xxx\.m2\repository我建議改到非系統(tǒng)盤比如D:\maven_repo這樣以后重裝系統(tǒng)不用重新下載所有依賴。localRepositoryD:\maven_repo/localRepository第二處是中央倉庫鏡像。不配鏡像的話下載依賴慢到你懷疑人生。國內(nèi)環(huán)境我建議直接用阿里云的鏡像mirror idaliyunmaven/id mirrorOf*/mirrorOf name阿里云公共倉庫/name urlhttps://maven.aliyun.com/repository/public/url /mirror這里要特別說明一下為什么用mirrorOf*/mirrorOf它的意思是所有倉庫請求都走阿里云鏡像包括中央倉庫、JCenter、自定義倉庫等等。對于自動化測試項目用公共鏡像就夠了。2.3 IDEA里的Maven設(shè)置用自帶的還是自己配置的IDEA自帶了Maven但我強烈建議在IDEA中指定我們剛安裝的Maven。因為IDEA自帶的Maven版本有時候比較舊而且它用的settings.xml是IDEA自己生成的不經(jīng)過你的配置。設(shè)置路徑是File - Settings - Build, Execution, Deployment - Build Tools - Maven。Maven home path選你解壓的目錄比如D:\dev\apache-maven-3.8.8User settings file選你改過的conf\settings.xmlLocal repositoryIDEA會自動讀settings.xml里的配置正常情況下顯示為D:\maven_repo還有一個容易被忽略的地方Maven - Importing里有個JDK選項確保選的是你安裝的JDK而不是IDEA內(nèi)置的JBR。IDEA 2022以后內(nèi)置了JetBrains Runtime它雖然是JBR 17但有時候會出現(xiàn)編碼或編譯級別不匹配的問題統(tǒng)一指到自己的JDK最省心。3. pom.xml實戰(zhàn)依賴管理配置和常見版本沖突環(huán)境配好之后新建一個Maven項目。這里有個細(xì)節(jié)創(chuàng)建項目時IDEA會讓你選骨架archetype不要選任何同步骨架直接選maven-archetype-quickstart然后點Next這是純Java工程模板。如果你不想用什么web骨架后面寫代碼時會被多余的目錄結(jié)構(gòu)干擾。3.1 最小可用pom.xml長什么樣我把我的pom.xml核心內(nèi)容貼出來你對照著看?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIdselenium-testng-demo/artifactId version1.0-SNAPSHOT/version properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.seleniumhq.selenium/groupId artifactIdselenium-java/artifactId version4.15.0/version /dependency dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version7.8.0/version /dependency dependency groupIdio.github.bonigarcia/groupId artifactIdwebdrivermanager/artifactId version5.6.3/version /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.2/version configuration suiteXmlFiles suiteXmlFiletestng.xml/suiteXmlFile /suiteXmlFiles /configuration /plugin /plugins /build /project這里我額外加了一個WebDriverManager依賴它是用來自動管理瀏覽器驅(qū)動版本的后面講原理時會展開。你暫時先加上不會錯。3.2 maven-surefire-plugin和testng.xml的執(zhí)行關(guān)系這個插件在pom.xml中配置了suiteXmlFile為testng.xml意味著你執(zhí)行mvn test的時候Surefire插件會去找項目根目錄下的testng.xml文件執(zhí)行里面定義的測試套件。為什么要做到這一步因為在IDEA里右鍵運行單個測試方法很方便但真正的自動化測試不能只在IDE里點。你需要在命令行、定時任務(wù)、Jenkins流水線里也能跑同樣的一套用例。配置好Surefire之后任何人拉下代碼執(zhí)行一條mvn test全部用例都能跑起來。TestNG的testng.xml支持靈活配置測試套件比如指定按包執(zhí)行、按類執(zhí)行、按方法執(zhí)行、配置監(jiān)聽器、配置并行模式等。這是一個單獨的文件放在項目根目錄比較直觀!DOCTYPE suite SYSTEM https://testng.org/testng-1.0.dtd suite name全部測試 parallelmethods thread-count3 test name核心流程 packages package namecom.example.tests/ /packages /test /suiteparallelmethods表示方法級別并行執(zhí)行thread-count3表示同時跑3個線程。這種配置能大幅縮短大規(guī)模用例的執(zhí)行時間但前提是每個用例的數(shù)據(jù)相互隔離這個后面細(xì)講。3.3 依賴版本沖突Selenium和TestNG的傳遞依賴坑依賴沖突這個問題我建議所有新手提前有個概念。Maven引入依賴時會自動帶入傳遞依賴比如selenium-java會引入selenium-api、selenium-chrome-driver等。如果不同庫依賴了同一個庫的不同版本Maven默認(rèn)按最近路徑優(yōu)先來仲裁但仲裁結(jié)果未必是你想要的。最常見的沖突是com.google.guava:guava和org.apache.commons:commons-lang3。Selenium的一些遠(yuǎn)程操作模塊會依賴Guava而TestNG可能通過其他模塊間接引入不同版本的Guava。如果你遇到了奇怪的NoSuchMethodError八九成是Guava版本沖突。解決辦法是直接用IDEA的Maven面板選中工程右鍵Show Dependencies或者Diagrams查看依賴樹找到有重復(fù)的地方然后在pom.xml里用exclusions排除舊版本的傳遞依賴。比如dependency groupIdorg.seleniumhq.selenium/groupId artifactIdselenium-java/artifactId version4.15.0/version exclusions exclusion groupIdcom.google.guava/groupId artifactIdguava/artifactId /exclusion /exclusions /dependency然后在下面單獨聲明一個你需要的Guava版本。這套做法可以推廣到任意依賴沖突場景。4. Selenium核心機制瀏覽器驅(qū)動原理、版本鎖定和元素定位優(yōu)先級環(huán)境、依賴都理順之后第一次寫Selenium代碼的體驗會很有意思代碼很簡單但處處有坑。要真正用好Selenium必須理解它底層是怎么和瀏覽器協(xié)作的。4.1 WebDriver不是直連瀏覽器驅(qū)動版本必須匹配Selenium WebDriver通過瀏覽器各自的驅(qū)動程序和瀏覽器通信。比如Chrome對應(yīng)chromedriverFirefox對應(yīng)geckodriver。驅(qū)動版本和瀏覽器版本不能差太多大版本必須一致否則會報SessionNotCreatedException或This version of ChromeDriver only supports Chrome version xxx。最原始的做法是手動下載對應(yīng)版本的驅(qū)動放到某個路徑并配置System.setProperty(webdriver.chrome.driver, 路徑)。這個做法維護成本很高因為瀏覽器升級你就得換驅(qū)動。我強烈建議用WebDriverManager來自動管理它會在運行前自動檢測本機瀏覽器版本下載匹配的驅(qū)動并緩存在本地import io.github.bonigarcia.wdm.WebDriverManager; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class DriverFactory { public static WebDriver createChromeDriver() { WebDriverManager.chromedriver().setup(); return new ChromeDriver(); } }WebDriverManager.chromedriver().setup()這一步會在第一次運行時去Google維護的版本表中查當(dāng)前Chrome版本對應(yīng)的驅(qū)動然后下載并保存到~/.cache/selenium目錄。之后每次運行都用緩存基本零開銷。這個方法從根源上解決了驅(qū)動和瀏覽器不匹配的痛點。4.2 Selenium 4的定位策略和使用優(yōu)先級Selenium 4支持8種內(nèi)置定位策略id、name、className、tagName、linkText、partialLinkText、xpath、cssSelector。我推薦的優(yōu)先級是優(yōu)先級定位方式適用場景為什么推薦1id表單輸入框、按鈕、div容器頁面結(jié)構(gòu)里id唯一性能最好2cssSelector有穩(wěn)定class屬性的元素簡潔、性能好比xpath輕量3xpath復(fù)雜層級、跨層級定位靈活但性能稍差可讀性不高4linkText超鏈接直觀但文本變更就掛5相對定位with相鄰元素4.x新特性適合特殊場景XPath盡量少用絕對路徑比如/html/body/div[2]/div[1]/div[3]/button這種一調(diào)整頁面就廢。要用就用相對XPath以穩(wěn)定的屬性或文本作為錨點// 不推薦 driver.findElement(By.xpath(/html/body/div[2]/div[3]/div[1]/button)); // 推薦 driver.findElement(By.xpath(//button[contains(class, submit) and text()登錄]));Selenium 4還新增了相對定位器Relative Locator可以用位置關(guān)系來定位元素。比如某個輸入框上方的人這種需求用with(By.tagName(input)).above(By.id(username))就能實現(xiàn)這個在復(fù)雜表格表單里非常好用。4.3 定位元數(shù)據(jù)集中管理頁面元素枚舉的設(shè)計思路在真正寫用例之前我強烈建議做一件很多教程不會提的事把定位信息從用例代碼里剝離出去統(tǒng)一管理。熱搜詞里有個selenium 頁面元素枚舉,僅存儲定位元數(shù)據(jù)這個思路非常實用。我通常用一個By類型的枚舉類來充當(dāng)頁面元素的元數(shù)據(jù)倉庫import org.openqa.selenium.By; public enum LoginPageElements { USERNAME_INPUT(用戶名輸入框, By.id(username)), PASSWORD_INPUT(密碼輸入框, By.id(password)), LOGIN_BUTTON(登錄按鈕, By.xpath(//button[contains(class, login)])); private final String desc; private final By by; LoginPageElements(String desc, By by) { this.desc desc; this.by by; } public String getDesc() { return desc; } public By getBy() { return by; } }在用例里使用時代碼就非常優(yōu)雅driver.findElement(LoginPageElements.USERNAME_INPUT.getBy()).sendKeys(admin);把定位元數(shù)據(jù)單獨放一個枚舉類有三個實際好處第一頁面元素變了只需要改一處第二寫用例時可以通過枚舉的desc屬性快速搜索到用戶名輸入框在哪個類里比在一個幾百行的類里找By定位正則舒服得多第三方便做一些元素級別的自動校驗——比如遍歷所有枚舉檢查定位是否有效。這個設(shè)計能讓測試代碼的可維護性上一個檔次。5. TestNG深度整合從Test注解到數(shù)據(jù)驅(qū)動、失敗重跑Selenium能打開瀏覽器干活了接下來真正的框架部分來了——如何用TestNG把這些操作組織成一套完整的測試體系。5.1 測試用例的注解Test的屬性不要只掛一個方法名Test注解是TestNG的入口但它遠(yuǎn)不止標(biāo)記一個測試方法那么簡單。常用屬性包括priority執(zhí)行優(yōu)先級、groups分組、dependsOnMethods依賴方法、enabled開關(guān)、timeOut超時、dataProvider數(shù)據(jù)提供者、retryAnalyzer重試器。我舉一個實際登錄測試的例子package com.example.tests; import org.openqa.selenium.WebDriver; import org.testng.annotations.AfterMethod; import org.testng.annotations.BeforeMethod; import org.testng.annotations.Test; public class LoginTest { private WebDriver driver; BeforeMethod public void setUp() { driver DriverFactory.createChromeDriver(); driver.get(https://example.com/login); } AfterMethod public void tearDown() { if (driver ! null) { driver.quit(); } } Test(priority 1, description 驗證正確的賬號密碼可以登錄成功) public void testLoginWithValidCredentials() { driver.findElement(LoginPageElements.USERNAME_INPUT.getBy()).sendKeys(admin); driver.findElement(LoginPageElements.PASSWORD_INPUT.getBy()).sendKeys(123456); driver.findElement(LoginPageElements.LOGIN_BUTTON.getBy()).click(); // 斷言跳轉(zhuǎn)到首頁 String currentUrl driver.getCurrentUrl(); org.testng.Assert.assertTrue(currentUrl.contains(/dashboard), 登錄成功后地址欄應(yīng)包含 /dashboard實際為 currentUrl); } }BeforeMethod在每個測試方法前執(zhí)行AfterMethod在每個測試方法后執(zhí)行這是標(biāo)準(zhǔn)的用例生命周期。這里要特別強調(diào)BeforeMethod和BeforeClass、BeforeSuite的執(zhí)行粒度完全不同新手容易搞混。BeforeSuite整個suite文件執(zhí)行前運行一次BeforeTest每個test標(biāo)簽前運行一次BeforeClass每個測試類運行前執(zhí)行一次BeforeMethod每個測試方法運行前執(zhí)行一次如果把driver初始化放在BeforeMethod里每個用例都是一個干凈的瀏覽器互不干擾雖然慢一點但最穩(wěn)定。如果放在BeforeClass里類內(nèi)所有用例共用一個瀏覽器速度快但用例之間可能有狀態(tài)殘留。5.2 斷言庫選擇TestNG自帶斷言和AssertJ的取舍TestNG自帶org.testng.AssertAPI夠用缺點是失敗信息需要自己拼接。比如Assert.assertTrue(false, 失敗原因)這種。如果你追求代碼更簡潔、閱讀性更強我推薦引入AssertJimport static org.assertj.core.api.Assertions.assertThat; assertThat(driver.getCurrentUrl()).contains(/dashboard); assertThat(driver.findElement(By.id(errorMsg)).isDisplayed()).isTrue();AssertJ的鏈?zhǔn)秸{(diào)用風(fēng)格讓斷言讀起來像英語自然語言而且失敗提示信息非常清晰會顯示實際值和期望值的diff。對于測試報告來說清晰的失敗信息極其重要否則定位問題的時間比寫代碼還長。這個取舍我建議測試團隊直接無腦選AssertJ。5.3 DataProvider數(shù)據(jù)驅(qū)動把測試數(shù)據(jù)從用例里拆出去一個登錄用例如果只測一組數(shù)據(jù)價值有限。真實項目中往往要測十幾組賬號密碼的組合正常登錄、密碼錯誤、用戶不存在、賬號鎖定等等。如果每個場景都復(fù)制一個Test方法代碼冗余到?jīng)]法看。TestNG的DataProvider就是解決這個問題的import org.testng.annotations.DataProvider; import org.testng.annotations.Test; public class LoginDataDrivenTest { DataProvider(name loginData) public Object[][] loginData() { return new Object[][] { {admin, 123456, true}, {admin, wrong, false}, {nonexist, 123456, false}, {locked, 123456, false} }; } Test(dataProvider loginData) public void testLogin(String username, String password, boolean expectSuccess) { // 打開頁面、輸入、點擊 // 斷言結(jié)果是否與expectSuccess一致 } }數(shù)據(jù)驅(qū)動最大的優(yōu)勢是把數(shù)據(jù)和代碼分離了。后續(xù)如果要加一組測試數(shù)據(jù)不需要改用例代碼只需要在DataProvider里加一行數(shù)組。更進(jìn)階的用法是配合Excel或YAML文件讀數(shù)據(jù)但思路都一樣用例邏輯只寫一次用參數(shù)跑多組數(shù)據(jù)。5.4 失敗重試ForUITesting這個重試器怎么自己寫UI自動化最大的痛苦不是代碼寫不出來而是環(huán)境不穩(wěn)定導(dǎo)致用例偶發(fā)失敗。明明功能沒有bug網(wǎng)絡(luò)抖動或者元素加載慢了幾百毫秒用例就掛了下一次跑又是綠的。這種flaky test對團隊信任的打擊極大。TestNG提供了IRetryAnalyzer接口可以自定義失敗重試邏輯import org.testng.IRetryAnalyzer; import org.testng.ITestResult; public class RetryAnalyzer implements IRetryAnalyzer { private int retryCount 0; private static final int maxRetryCount 2; Override public boolean retry(ITestResult result) { if (retryCount maxRetryCount) { retryCount; return true; } return false; } }然后在Test注解上指定retryAnalyzer RetryAnalyzer.class即可。更好的做法是通過監(jiān)聽器全局統(tǒng)一處理不在每個方法上重復(fù)標(biāo)注。實現(xiàn)IAnnotationTransformer接口來動態(tài)給所有Test方法加上重試器這樣就不會污染代碼了。重試策略設(shè)置成2次就夠了不要無限重試否則整個執(zhí)行時間可能被拖到不可接受。6. 踩坑實錄下拉框、動態(tài)加載、iframe切換的高頻事故現(xiàn)場Selenium本身不難難的是頁面各種非常規(guī)結(jié)構(gòu)。這一節(jié)我挑了幾個最常遇到、也是最容易卡住的問題。6.1 原生下拉框和divulli模擬下拉框的處理差異原生select標(biāo)簽的下拉框Selenium有專門的Select類處理import org.openqa.selenium.support.ui.Select; Select dropdown new Select(driver.findElement(By.id(province))); dropdown.selectByVisibleText(廣東省); dropdown.selectByValue(44);兩條select方法都行按需選擇。注意selectByVisibleText匹配的是下拉選項的可見文本selectByValue匹配的是option標(biāo)簽的value屬性值。但web頁面越來越多的下拉框不是select實現(xiàn)的而是用div套ul套li模擬出來的。這種控件在Selenium看來只是一堆普通divSelect類完全無效。搜索詞里selenium 定位獲取下拉框元素,不是原生下拉框,是divulli組合說的就是這種。處理思路也很明確先點擊觸發(fā)下拉框展開的按鈕等待下拉列表出現(xiàn)然后用普通定位方式點選目標(biāo)選項。public void selectCityByDivDropdown(String cityName) { // 1. 點擊觸發(fā)下拉框的輸入框或按鈕 driver.findElement(By.xpath(//div[contains(class, city-selector)]//input)).click(); // 2. 等待下拉列表可見 WebDriverWait wait new WebDriverWait(driver, Duration.ofSeconds(10)); WebElement dropdownList wait.until(ExpectedConditions.visibilityOfElementLocated( By.xpath(//div[contains(class, dropdown-menu)]))); // 3. 在下拉列表中點擊目標(biāo)文本 dropdownList.findElement(By.xpath(.//li[text() cityName ])).click(); }注意第三行里XPath開頭的.——這是相對路徑表示從dropdownList內(nèi)部查找而不是從整個頁面根節(jié)點查找。這個細(xì)節(jié)能避免頁面上存在多個相同文本時定位錯對象。這種div模擬下拉框由于沒有標(biāo)準(zhǔn)的option事件往往需要配合顯示等待確保下拉列表完全渲染否則很容易點擊不中。6.2 等待策略Thread.sleep是萬惡之源但完全不用的也不成熟新手最開始寫的代碼幾乎都是這樣點擊按鈕后立刻查找元素結(jié)果找不到于是加Thread.sleep(3000)。這個寫法能解決眼前的問題但后患無窮。Thread.sleep(3000)的問題在于它是無條件死等無論元素0.5秒就加載好了還是10秒還沒出來它都固定等3秒。慢的用例拖時間快的用例浪費時間而且一旦網(wǎng)絡(luò)變慢3秒不夠照樣失敗。正確的做法是使用Selenium的顯式等待輪詢等待某個條件成立超時時間到了再拋異常。import org.openqa.selenium.support.ui.WebDriverWait; import org.openqa.selenium.support.ui.ExpectedConditions; WebDriverWait wait new WebDriverWait(driver, Duration.ofSeconds(10)); wait.until(ExpectedConditions.visibilityOfElementLocated(By.id(submit)));WebDriverWait默認(rèn)每500毫秒輪詢一次元素出現(xiàn)了立刻返回10秒沒出現(xiàn)才報錯。這比固定sleep精準(zhǔn)得多。除了visibilityOfElementLocated還有很多內(nèi)置條件比如elementToBeClickable、presenceOfElementLocated、frameToBeAvailableAndSwitchToIt、stalenessOf等基本覆蓋了常見場景。那到底該不該用隱式等待driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10))設(shè)置的是全局等待findElement找不到元素時會等待一段時間。我的建議是項目里兩者不要混用。顯式等待和隱式等待疊加時等待時間可能不是你預(yù)期的總和反而導(dǎo)致偶發(fā)超時。如果要用隱式等待就統(tǒng)一用但更推薦的還是以顯式等待為主因為粒度更容易控制邏輯也更明顯。6.3 瀏覽器窗口和iframe切換WebDriver能操作的焦點是唯一的WebDriver操作的焦點是唯一的如果頁面上彈出新窗口或者頁面里嵌了iframe而你沒有切換焦點那findElement永遠(yuǎn)找不到目標(biāo)元素控制臺還會報NoSuchElementException。新窗口切換SetString handles driver.getWindowHandles(); String currentHandle driver.getWindowHandle(); for (String handle : handles) { if (!handle.equals(currentHandle)) { driver.switchTo().window(handle); break; } }iframe切換// 按索引或name或WebElement切換 driver.switchTo().frame(mainFrame); // 操作完之后一定要切回默認(rèn)內(nèi)容 driver.switchTo().defaultContent();這里最大的坑是很多數(shù)據(jù)報表類的頁面圖表外層包著多層iframe定位時經(jīng)常需要一層一層切進(jìn)去。如果切到某層之后點了按鈕頁面內(nèi)部又動態(tài)生成新iframe你還得重新獲取iframe元素再切換一次。我的經(jīng)驗是寫一個工具方法接收一個iframe的定位器自動切換并返回driver這樣至少代碼不會混亂。6.4 截圖失敗現(xiàn)場測試報告最需要的一張圖用例失敗時的現(xiàn)場截圖是排錯的第一手材料。TestNG的ITestListener接口能監(jiān)聽用例失敗事件我們可以在onTestFailure方法里調(diào)用Selenium截圖APIimport org.openqa.selenium.TakesScreenshot; import org.openqa.selenium.io.FileHandler; import org.testng.ITestListener; import org.testng.ITestResult; public class TestListener implements ITestListener { Override public void onTestFailure(ITestResult result) { Object driverInstance result.getTestContext().getAttribute(driver); if (driverInstance instanceof WebDriver driver) { try { File src ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); String dir target/screenshots/ result.getTestClass().getName(); File dest new File(dir / result.getName() _ System.currentTimeMillis() .png); FileHandler.copy(src, dest); } catch (Exception e) { // 截圖失敗不要影響用例狀態(tài)判定 System.out.println(截圖異常 e.getMessage()); } } } }把這個監(jiān)聽器注冊到testng.xml里suite name全部測試 listeners listener class-namecom.example.common.TestListener/ /listeners /suite注意我在截圖路徑里加了result.getName()和時間戳這樣多個用例的截圖不會互相覆蓋而且能直接根據(jù)截圖文件名定位到具體用例。截圖保存到target目錄還有個好處Maven構(gòu)建完target目錄是完整的產(chǎn)物CI流水線可以直接把target/screenshots目錄收集起來作為測試產(chǎn)物。7. 從能跑到能抗項目分層和CI前面要解決的事一個真正能拿到團隊里用的自動化測試項目光能跑起來是遠(yuǎn)遠(yuǎn)不夠的。我見過太多測試腳本寫到1000行以后就完全沒人敢改一改一個炸。這個問題的根源在于沒有做分層設(shè)計。7.1 BasePage抽取把重復(fù)代碼收斂到一個父類Selenium的操作其實高度重復(fù)等待元素可見、等待元素可點擊、輸入文本、清空輸入、點擊、獲取文本。如果不做封裝每個測試方法都要寫一遍可讀性極差。我建議做一個BasePage類讓所有頁面對象類繼承它把通用操作收斂到父類public class BasePage { protected WebDriver driver; protected WebDriverWait wait; public BasePage(WebDriver driver) { this.driver driver; this.wait new WebDriverWait(driver, Duration.ofSeconds(10)); } protected void click(By locator) { wait.until(ExpectedConditions.elementToBeClickable(locator)).click(); } protected void type(By locator, String text) { WebElement element wait.until(ExpectedConditions.visibilityOfElementLocated(locator)); element.clear(); element.sendKeys(text); } protected String getText(By locator) { return wait.until(ExpectedConditions.visibilityOfElementLocated(locator)).getText(); } protected boolean isDisplayed(By locator) { try { return driver.findElement(locator).isDisplayed(); } catch (NoSuchElementException e) { return false; } } }然后登錄頁面類這樣寫public class LoginPage extends BasePage { public LoginPage(WebDriver driver) { super(driver); } public void login(String username, String password) { type(LoginPageElements.USERNAME_INPUT.getBy(), username); type(LoginPageElements.PASSWORD_INPUT.getBy(), password); click(LoginPageElements.LOGIN_BUTTON.getBy()); } }測試用例里就非常干凈public class LoginTest { Test public void testLoginSuccess() { LoginPage loginPage new LoginPage(driver); loginPage.login(admin, 123456); assertThat(driver.getCurrentUrl()).contains(/dashboard); } }這種模式的思路就是Page Object Pattern頁面對象模式把頁面層和用例層徹底分離。頁面變了只改Page類用例邏輯不變業(yè)務(wù)流程調(diào)整只改用例頁面定位不受影響。長期維護的自動化項目這套分層是底線不是加分項。7.2 數(shù)據(jù)切片和測試隔離并行執(zhí)行前的必須檢查testng.xml里配置了parallelmethods之后用例會多線程并發(fā)跑。這時候最大的風(fēng)險是測試數(shù)據(jù)互相污染。比如多個線程同時用同一個賬號登錄可能觸發(fā)風(fēng)控導(dǎo)致登錄失敗。更隱蔽的是如果測試系統(tǒng)是同一個數(shù)據(jù)庫兩個用例同時對同一份數(shù)據(jù)進(jìn)行修改斷言必然出現(xiàn)隨機失敗。我的建議是并行執(zhí)行之前要么給每個線程分配獨立的測試賬號數(shù)據(jù)工廠方式要么在用例設(shè)計中保證數(shù)據(jù)只創(chuàng)建不修改、用后刪除。這也解釋了為什么我前面推薦BeforeMethod里每次新建driver而不是BeforeClass里共用driver——每個線程持有獨立的瀏覽器實例互不干擾是寫WebDriver并行用例的前提。7.3 Selenium Grid和Docker化當(dāng)用例量級上千后怎么辦當(dāng)用例數(shù)量從幾十條漲到上千條單機串行執(zhí)行是跑不完的。Selenium Grid允許把用例分發(fā)到多臺機器的多個瀏覽器節(jié)點上。理論上一個調(diào)度中心Hub帶多個節(jié)點Node每個節(jié)點可以是一臺裝了不同瀏覽器和驅(qū)動的機器甚至可以是Docker容器。如果你在用Docker官方提供了selenium/standalone-chrome鏡像一條docker run就能起一個帶VNC的Chrome環(huán)境。配合Maven里Surefire的并行配置可以做到一套用例同時在多個容器里跑docker run -d -p 4444:4444 --shm-size2g selenium/standalone-chrome:latest注意--shm-size2g不能漏。Chrome在容器里如果/dev/shm太小會頻繁崩潰報no space left這是Selenium容器化最常見的坑。這套環(huán)境的最后一個心得回頭看我搭環(huán)境那幾天最崩潰的時刻不是Selenium定位寫不出來而是Maven依賴沖突導(dǎo)致編譯都過不了。后來想明白了這套組合本質(zhì)上是一個約定大于配置的工程體系——Maven管好依賴的版本約定TestNG管好用例的執(zhí)行約定Selenium管好操作的交互約定IDEA只是把這一切可視化。每一個工具單獨拿出來都不難難的是理解它們的邊界Selenium不替你管用例TestNG不替你管依賴Maven不替你寫定位各司其職又互相咬合才能形成一套能跑、能報、能養(yǎng)的自動化測試體系。你現(xiàn)在照著這篇文章從環(huán)境開始搭一遍遇到問題多看看控制臺第一行的Exception類型多半就能猜到是哪一環(huán)沒對齊。