Selenium WebDriver与Java自动化测试：从环境搭建到POM框架设计

1. 项目概述：为什么是Selenium WebDriver与Java？

如果你正在寻找一个稳定、强大且生态成熟的Web自动化测试方案，那么“Selenium WebDriver + Java”这个组合，大概率是你绕不开的终点。我接触过不少测试框架和语言组合，从早期的QTP到后来的Cypress、Playwright，但每当项目需要构建一个长期、稳定、可维护且需要深度集成的企业级自动化测试体系时，我依然会首选这个“经典搭档”。它可能不是最时髦的，但绝对是经过无数项目验证、最值得信赖的基石。

简单来说，这个组合的核心价值在于：用Java的严谨和生态，来驱动Selenium WebDriver这个浏览器自动化的“事实标准”，从而实现对Web应用从UI到业务流程的可靠验证。它解决的不仅仅是“点击按钮”的问题，更是如何将自动化测试无缝嵌入到持续集成（CI/CD）流程、如何管理成千上万个测试用例、如何生成权威的测试报告等一系列工程化难题。无论是应对日常的回归测试，还是支撑敏捷开发中的快速反馈，这套组合拳都能提供坚实的保障。对于测试工程师、开发工程师（尤其是后端Java开发）以及任何需要确保Web应用质量的团队成员来说，掌握它都是一项极具价值的核心技能。

2. 环境搭建与核心依赖解析

工欲善其事，必先利其器。搭建一个清晰、可复现的自动化测试环境，是后续一切工作的基础。这里我分享一套经过多年实践验证的标准化环境配置方案。

2.1 Java开发环境与构建工具选型

首先，Java环境是基石。我强烈建议直接使用JDK 11 或 JDK 17（LTS版本）。这两个版本拥有长期支持，稳定性极高，且社区和各类构建工具兼容性最好。避免使用过于前沿的非LTS版本，以免遇到依赖库不兼容的“坑”。

安装完成后，通过命令行验证：

java -version javac -version

接下来是构建工具的选择。这直接决定了你项目的依赖管理、编译和运行方式。主流选择有三个：

1. Maven：老牌且经典，采用声明式的pom.xml进行配置。它的约定大于配置，目录结构清晰，对于依赖管理（特别是传递性依赖）的处理非常成熟。如果你的团队或项目已经使用Maven，或者你希望有一个标准化的项目结构，选它准没错。
2. Gradle：基于Groovy或Kotlin DSL，配置更灵活、更简洁。构建速度通常比Maven快，特别是增量构建。它正在成为许多新项目的首选，尤其是在Android和Spring Boot生态中。
3. 传统JAR包管理：手动下载所有jar包并添加到项目Classpath。极其不推荐，会迅速陷入“依赖地狱”，且无法进行版本管理。

对于新手和大多数企业项目，我建议从Maven开始。它的学习曲线平缓，网络上的资源也最丰富。在IDE（如IntelliJ IDEA或Eclipse）中新建一个Maven项目，它会自动生成标准的目录结构（src/main/java,src/test/java等）。

2.2 Selenium WebDriver与浏览器驱动

这是自动化测试的“发动机”和“方向盘”。

1. Selenium Java Client：这是我们要在项目中引入的核心依赖。在Maven的pom.xml中，添加以下依赖（建议使用当时的最新稳定版，例如4.x）：

   <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>4.11.0</version> <!-- 请检查并使用最新版本 --> </dependency>

   这个selenium-java包实际上是一个“聚合依赖”，它会自动引入selenium-api（接口）、selenium-chrome-driver、selenium-edge-driver、selenium-firefox-driver等所有必要的组件。

2. 浏览器驱动（WebDriver）：Selenium通过一个名为“WebDriver”的独立组件与真实浏览器进行通信。你需要为你要自动化的浏览器下载对应的驱动。

   • Chrome：ChromeDriver
   • Firefox：geckodriver
   • Edge：Microsoft Edge WebDriver

   关键操作心得：

   • 版本匹配：驱动版本必须与本地安装的浏览器主版本号一致或兼容。不匹配是导致“无法启动浏览器”最常见的原因。
   • 环境变量PATH：将下载的驱动（如chromedriver.exe）所在目录添加到系统的PATH环境变量中。这是最推荐的方式，代码中只需new ChromeDriver()即可，Selenium会自动在PATH中查找。
   • System.setProperty：也可以在代码中硬指定驱动路径：System.setProperty(“webdriver.chrome.driver”, “/path/to/chromedriver”);。这种方式灵活性差，不利于团队协作和CI/CD环境。

2.3 测试框架集成：JUnit 5 vs TestNG

单纯的Selenium只能操作浏览器，我们需要一个测试框架来组织测试用例、管理生命周期（如@BeforeEach,@AfterEach）、进行断言和生成报告。两大主流选择是JUnit 5和TestNG。

JUnit 5：目前Java单元测试的事实标准，生态极其繁荣。它与Spring Boot等框架集成无缝。如果你是从开发转测试，或者项目以单元测试为主，JUnit 5是自然的选择。它的注解（如@Test,@BeforeEach,@AfterEach,@DisplayName）清晰易懂。

TestNG：设计之初就考虑了更复杂的集成和端到端测试场景。它提供了JUnit早期版本所没有的强大功能，例如：

• 灵活的测试套件（XML配置）：可以轻松地分组、包含、排除测试类。
• 依赖测试：指定测试方法之间的依赖关系（dependsOnMethods）。
• 参数化测试：支持通过@DataProvider从方法或外部文件（如Excel、CSV）提供多组测试数据。
• 并行测试：原生支持在方法、类、套件级别进行并行执行，大幅缩短测试总时间。

我的选择建议：对于纯粹的、大规模的Web自动化测试项目，我倾向于使用TestNG。它的参数化、依赖管理和并行化特性，对于自动化测试脚本的编排和数据驱动测试（DDT）支持得更好，报告也更详细。当然，JUnit 5通过扩展也能实现大部分功能，但TestNG是“开箱即用”的。

在pom.xml中添加TestNG依赖：

<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.8.0</version> <!-- 请检查并使用最新版本 --> <scope>test</scope> </dependency>

3. 核心API与页面交互实战

环境就绪后，我们进入实战。Selenium WebDriver的核心是一套面向对象的API，其设计思想是模拟真实用户的操作。理解这些API是编写稳定脚本的关键。

3.1 WebDriver实例管理与浏览器操作

一切始于WebDriver对象，它是你与浏览器会话的控制器。

import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class BasicTest { public static void main(String[] args) { // 1. 启动浏览器（如果chromedriver已在PATH中） WebDriver driver = new ChromeDriver(); // 2. 浏览器窗口最大化（非必须，但有利于测试稳定性） driver.manage().window().maximize(); // 3. 导航到目标网址 driver.get(“https://www.example.com”); // 4. 获取当前页面标题和URL，常用于断言 String title = driver.getTitle(); String currentUrl = driver.getCurrentUrl(); System.out.println(“页面标题: ” + title); System.out.println(“当前URL: ” + currentUrl); // 5. 浏览器导航操作 driver.navigate().to(“https://www.google.com”); // 与get()类似 driver.navigate().back(); // 后退 driver.navigate().forward(); // 前进 driver.navigate().refresh(); // 刷新 // 6. 关闭浏览器 driver.quit(); // 关闭所有窗口并结束WebDriver会话 // driver.close(); // 仅关闭当前窗口，如果只有一个窗口，则结束会话 } }

重要注意事项：

• driver.quit()与driver.close()：务必在测试结束时调用driver.quit()。quit()会关闭所有关联窗口，终止WebDriver会话，并释放资源（如chromedriver进程）。close()只关闭当前标签页，如果这是最后一个标签页，行为类似quit，但为了代码清晰和避免资源泄漏，统一使用quit()。
• 隐式等待（Implicit Wait）：在查找元素时，如果元素没有立即出现，WebDriver会等待一段时间再抛出异常。这是一个全局设置。

  driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

  慎用隐式等待：它会对所有的findElement操作生效。如果与显式等待混用，可能导致总等待时间变长，行为难以预测。在现代Selenium实践中，更推荐使用显式等待（Explicit Wait）。

3.2 元素定位八大策略与最佳实践

定位页面元素是自动化测试的基石。Selenium提供了8种主要的定位策略（Locator Strategies）。

import org.openqa.selenium.By; // 假设页面有：<input id=”username” name=”user” class=”login-input”>...</input> // 和 <button type=”submit”>登录</button> WebElement element; // 1. ID定位 (最优先，最快速，最稳定) element = driver.findElement(By.id(“username”)); // 2. Name定位 element = driver.findElement(By.name(“user”)); // 3. Class Name定位 (注意：class属性可能包含多个值，需匹配完整或其中一个) element = driver.findElement(By.className(“login-input”)); // 4. Tag Name定位 (通常用于找多个同类元素，如<table>, <tr>) List<WebElement> inputs = driver.findElements(By.tagName(“input”)); // 5. Link Text (精确匹配超链接文本) 和 Partial Link Text (部分匹配) element = driver.findElement(By.linkText(“忘记密码？”)); element = driver.findElement(By.partialLinkText(“忘记”)); // 6. CSS Selector (强大且灵活，是XPath的轻量级替代) element = driver.findElement(By.cssSelector(“input#username”)); // ID element = driver.findElement(By.cssSelector(“input.login-input”)); // Class element = driver.findElement(By.cssSelector(“input[name=’user’]”)); // 属性 element = driver.findElement(By.cssSelector(“form > div > input”)); // 层级 // 7. XPath (功能最强大，可以遍历XML/HTML文档树) element = driver.findElement(By.xpath(“//input[@id=’username’]”)); // 属性 element = driver.findElement(By.xpath(“//button[text()=’登录’]”)); // 文本 element = driver.findElement(By.xpath(“//div[@class=’container’]//input”)); // 相对路径

定位策略选择的心得：

1. 优先级：ID>Name>CSS Selector>XPath。只要元素有稳定且唯一的id或name，就绝对优先使用。
2. CSS Selector vs XPath：对于大多数场景，CSS Selector性能更优，语法更简洁，且被浏览器原生支持。优先使用CSS Selector。仅在需要根据文本内容定位（text()）或进行复杂的轴向定位（如parent::,following-sibling::）时，才使用XPath。
3. 绝对路径 vs 相对路径：永远避免使用包含完整HTML结构的绝对XPath（如/html/body/div[5]/div[2]/form/input[1]）。页面结构稍有变动，脚本就会崩溃。使用基于ID、Class或特征元素的相对路径。
4. findElementvsfindElements：findElement返回第一个匹配的元素，如果没找到则抛出NoSuchElementException。findElements返回一个元素列表（可能为空），不会抛出异常。根据你的意图选择。

3.3 显式等待（Explicit Wait）：解决动态加载的银弹

现代Web应用大量使用Ajax和前端框架，元素不会在页面加载完成后立即出现。隐式等待不够智能，这时就需要显式等待。它允许你为某个特定条件设置等待，条件满足则立即继续，超时则抛出异常。

import org.openqa.selenium.support.ui.ExpectedConditions; import org.openqa.selenium.support.ui.WebDriverWait; import java.time.Duration; // 创建一个WebDriverWait对象，设置最大等待时间10秒，轮询间隔500毫秒 WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10)); // 等待元素可见并可点击 WebElement loginButton = wait.until(ExpectedConditions.elementToBeClickable(By.id(“login-btn”))); loginButton.click(); // 等待元素出现在DOM中（不一定可见） WebElement dynamicElement = wait.until(ExpectedConditions.presenceOfElementLocated(By.id(“dynamic-content”))); // 等待元素从DOM中消失（例如等待加载动画结束） wait.until(ExpectedConditions.invisibilityOfElementLocated(By.id(“loading-spinner”))); // 等待页面标题包含特定文本 wait.until(ExpectedConditions.titleContains(“Dashboard”)); // 自定义等待条件（Lambda表达式，非常灵活） wait.until(d -> { WebElement elem = d.findElement(By.cssSelector(“.progress-bar”)); String width = elem.getCssValue(“width”); return width != null && width.equals(“100%”); });

显式等待的核心优势：它针对特定条件进行等待，而不是盲目等待固定时间。这大大提高了测试脚本的稳定性和执行速度。最佳实践是：在每一个与动态元素交互之前，都使用显式等待来确保元素就绪。

3.4 丰富的用户交互模拟

定位到元素后，我们可以模拟几乎所有的用户交互。

WebElement inputBox = driver.findElement(By.id(“search”)); WebElement button = driver.findElement(By.name(“submit”)); WebElement checkbox = driver.findElement(By.xpath(“//input[@type=’checkbox’]”)); Select dropdown = new Select(driver.findElement(By.id(“country”))); // 1. 输入文本 (sendKeys) inputBox.sendKeys(“Selenium自动化测试”); // 清空输入框 inputBox.clear(); inputBox.sendKeys(“新的文本”); // 2. 点击 (click) button.click(); // 3. 复选框和单选框 (isSelected, click) if (!checkbox.isSelected()) { checkbox.click(); // 如果未选中，则选中 } // 4. 下拉列表 (Select类) dropdown.selectByVisibleText(“中国”); // 根据文本选择 dropdown.selectByValue(“CN”); // 根据value属性选择 dropdown.selectByIndex(1); // 根据索引选择（从0开始） // 5. 获取元素状态和信息 String text = button.getText(); // 获取元素内部文本 String attr = inputBox.getAttribute(“placeholder”); // 获取属性值 String cssValue = inputBox.getCssValue(“font-size”); // 获取CSS样式 boolean isDisplayed = button.isDisplayed(); // 是否可见 boolean isEnabled = button.isEnabled(); // 是否可用（可交互） boolean isSelected = checkbox.isSelected(); // 是否被选中 // 6. 高级交互：动作链 (Actions) - 用于模拟鼠标悬停、拖放、右键菜单等 Actions actions = new Actions(driver); WebElement menu = driver.findElement(By.id(“menu”)); WebElement subMenu = driver.findElement(By.id(“submenu”)); actions.moveToElement(menu).perform(); // 鼠标悬停 // 复杂的组合操作：点击并按住，移动到另一个元素，释放（模拟拖放） actions.clickAndHold(sourceElement).moveToElement(targetElement).release().perform(); // 右键点击 actions.contextClick(element).perform(); // 双击 actions.doubleClick(element).perform();

交互注意事项：

• click()失败常见原因：元素被遮挡、未处于可交互状态（需wait.until(ExpectedConditions.elementToBeClickable(...))）、坐标点不在元素上（对于某些复杂渲染的元素，可能需要用Actions点击或执行JavaScript点击）。
• sendKeys()前最好先clear()，避免在已有文本后追加，除非这是你的测试意图。
• 对于文件上传，如果页面是使用<input type=”file”>，直接对其使用sendKeys(“文件的绝对路径”)即可。如果是需要打开系统文件对话框的复杂控件，则需要借助AutoIT或Robot类等工具，这属于高级话题。

4. 高级技巧与框架设计

掌握了基础API，可以编写脚本了。但要写出健壮、可维护、可复用的自动化测试代码，就需要上升到框架设计的层面。

4.1 Page Object Model (POM) 设计模式

这是Selenium自动化测试中最重要的设计模式，没有之一。POM的核心思想是将页面对象和测试逻辑分离。

• 页面对象（Page Object）：代表一个页面（或页面中的一个可重用组件，如Header、Sidebar）。它封装了该页面的所有元素定位符（Locators）和基本的页面交互方法（如login(String user, String pass)）。
• 测试脚本（Test Script）：包含具体的测试步骤和断言，它通过调用页面对象提供的方法来操作页面，而不关心页面元素是如何定位的。

一个简单的登录页面对象示例：

// LoginPage.java - 页面对象类 public class LoginPage { private WebDriver driver; private WebDriverWait wait; // 1. 定义页面元素定位符（推荐使用By对象） private By usernameInput = By.id(“username”); private By passwordInput = By.id(“password”); private By loginButton = By.id(“loginBtn”); private By errorMessage = By.cssSelector(“.alert.error”); // 2. 构造函数，接收驱动 public LoginPage(WebDriver driver) { this.driver = driver; this.wait = new WebDriverWait(driver, Duration.ofSeconds(10)); } // 3. 封装页面动作/行为 public void enterUsername(String user) { wait.until(ExpectedConditions.visibilityOfElementLocated(usernameInput)).sendKeys(user); } public void enterPassword(String pass) { driver.findElement(passwordInput).sendKeys(pass); } public void clickLogin() { driver.findElement(loginButton).click(); } // 一个组合的业务方法 public HomePage loginWithValidCreds(String user, String pass) { enterUsername(user); enterPassword(pass); clickLogin(); // 通常，登录成功会跳转到新页面，这里返回新页面的Page Object return new HomePage(driver); } // 获取错误信息，用于断言 public String getErrorMessage() { return wait.until(ExpectedConditions.visibilityOfElementLocated(errorMessage)).getText(); } // 判断是否在登录页面 public boolean isAt() { return driver.getTitle().contains(“登录”); } }

对应的测试脚本：

// LoginTest.java - 测试类 public class LoginTest { WebDriver driver; LoginPage loginPage; @BeforeMethod public void setUp() { driver = new ChromeDriver(); driver.manage().window().maximize(); driver.get(“https://your-app.com/login”); loginPage = new LoginPage(driver); } @Test public void testLoginSuccess() { HomePage homePage = loginPage.loginWithValidCreds(“validUser”, “validPass”); // 断言：是否成功跳转到首页 Assert.assertTrue(homePage.isAt(), “登录后未跳转到首页”); Assert.assertTrue(homePage.isUserLoggedIn(“validUser”), “用户登录状态异常”); } @Test public void testLoginWithInvalidPassword() { loginPage.enterUsername(“validUser”); loginPage.enterPassword(“wrongPass”); loginPage.clickLogin(); // 断言：是否显示了正确的错误信息 String actualError = loginPage.getErrorMessage(); Assert.assertEquals(actualError, “密码错误”, “错误信息不匹配”); } @AfterMethod public void tearDown() { if (driver != null) { driver.quit(); } } }

POM模式带来的巨大好处：

• 高可维护性：当页面UI发生变化时（例如元素ID改了），你只需要在一个地方（Page Object类）修改定位符，所有相关的测试脚本都自动生效。
• 高可读性：测试脚本读起来就像业务需求文档（“用有效凭证登录”），而不是一堆findElement和click的技术细节。
• 低冗余：页面交互逻辑被封装复用，避免了测试脚本中的代码重复。

4.2 数据驱动测试（DDT）

将测试数据与测试逻辑分离。同一套测试流程，可以用多组不同的输入数据和预期结果来执行。TestNG对此有原生支持。

// 使用 @DataProvider 提供测试数据 public class DataDrivenLoginTest { @DataProvider(name = “loginData”) public Object[][] provideLoginData() { return new Object[][] { { “admin”, “admin123”, true, “登录成功” }, // 用户名，密码，是否成功，描述 { “admin”, “wrong”, false, “密码错误” }, { “”, “admin123”, false, “用户名为空” }, { “admin”, “”, false, “密码为空” }, }; } @Test(dataProvider = “loginData”) public void testLoginWithData(String username, String password, boolean expectedSuccess, String description) { LoginPage loginPage = new LoginPage(driver); loginPage.enterUsername(username); loginPage.enterPassword(password); loginPage.clickLogin(); if (expectedSuccess) { Assert.assertTrue(new HomePage(driver).isAt(), “用例失败: ” + description); } else { // 假设失败时会停留在登录页并有错误提示 Assert.assertTrue(loginPage.isAt(), “用例失败: ” + description); Assert.assertFalse(loginPage.getErrorMessage().isEmpty(), “用例失败: ” + description); } } }

更高级的做法是从外部文件（如Excel、CSV、JSON或数据库）读取测试数据，使数据管理完全独立于代码。

4.3 测试报告与日志

“测试通过了”和“测试为什么通过/失败了”是两回事。好的报告和日志能让你快速定位问题。

1. TestNG原生报告：TestNG执行后会生成一个test-output文件夹，里面的index.html就是一份详细的测试报告，包含了通过率、失败原因、执行时间等。
2. ExtentReports：这是目前最流行、最强大的第三方测试报告库之一。它可以生成非常美观、交互式的HTML报告，支持截图附件、步骤日志、分组、图表等。

   // 简化的ExtentReports集成示例 ExtentReports extent = new ExtentReports(); ExtentSparkReporter spark = new ExtentSparkReporter(“target/Spark.html”); extent.attachReporter(spark); @Test public void testWithFancyReport() { ExtentTest test = extent.createTest(“我的第一个Extent测试”); test.log(Status.INFO, “打开浏览器”); // ... 测试步骤 test.log(Status.PASS, “登录成功验证通过”); // 在失败时附加截图 // test.addScreenCaptureFromPath(screenshotPath); // test.fail(“失败详情”, MediaEntityBuilder.createScreenCaptureFromPath(screenshotPath).build()); } @AfterSuite public void tearDownSuite() { extent.flush(); // 将报告写入文件 }

3. 日志框架：在测试代码中合理使用SLF4J + Logback或Log4j2记录运行时的详细信息（DEBUG, INFO, ERROR级别），这对于在CI服务器上排查无头运行的测试失败至关重要。

4.4 集成持续集成（CI/CD）

自动化测试的价值在CI/CD流水线中才能最大化体现。常见的做法是：

• 将测试代码放入版本控制系统（如Git）。
• 在CI服务器（如Jenkins, GitLab CI, GitHub Actions）上配置一个Job。
• Job的步骤通常是：拉取代码 -> 构建（mvn clean compile）-> 运行测试（mvn test或mvn verify）。
• 配置测试失败时发送通知（邮件、钉钉、Slack）。
• 将测试报告（如ExtentReports生成的HTML）归档并发布，供团队查看。

在CI中运行的关键配置：

• 无头模式（Headless）：CI服务器通常没有图形界面，需要以无头模式运行浏览器。

  ChromeOptions options = new ChromeOptions(); options.addArguments(“--headless”); // 无头模式 options.addArguments(“--disable-gpu”); // 禁用GPU加速（在某些环境下需要） options.addArguments(“--window-size=1920,1080”); // 设置窗口大小 WebDriver driver = new ChromeDriver(options);

• 并行执行：在TestNG的testng.xml中配置parallel=”methods”或parallel=”tests”，并设置thread-count，可以大幅缩短测试套件的总执行时间。

5. 常见问题排查与性能优化

即使按照最佳实践编写，在实际运行中还是会遇到各种问题。这里记录一些高频“坑点”和解决思路。

5.1 元素定位失败问题排查表

5.2 脚本执行不稳定（Flaky Tests）

这是自动化测试的“顽疾”，指测试有时成功有时失败，非确定性。

主要原因和应对策略：

1. 异步加载/动画：这是头号原因。全面使用显式等待（WebDriverWait）替代Thread.sleep()。sleep是脆弱的，固定等待时间无法适应网络或机器性能波动。
2. 依赖外部服务或数据：测试依赖于一个不稳定的第三方API或特定的测试数据状态。使用测试替身（Test Double）如Mock Server，或者在测试前通过API准备好确定的测试数据，测试后清理。
3. 并发问题：在多线程并行执行测试时，共享资源（如测试用户账号）冲突。为每个线程或测试用例创建独立的、隔离的测试数据（如使用唯一用户名”user_” + Thread.currentThread().getId()）。
4. 环境差异：本地开发环境、测试环境、CI环境不一致。使用配置化（如.properties文件或环境变量）来管理不同环境的URL、账号等，确保测试环境稳定且与运行环境匹配。

5.3 性能与可维护性优化

1. 定位器优化：
   • 优先使用ID、Name等原生属性。
   • 使用简洁的CSS Selector，避免过于复杂的XPath，后者解析更慢。
   • 对于频繁使用的元素，可以在Page Object中缓存By定位器对象，而不是字符串。
2. 等待策略优化：
   • 为不同的操作设置合理的超时时间。对于主要交互可以长一些（10-15秒），对于次要元素可以短一些（3-5秒）。
   • 避免在@BeforeMethod/@AfterMethod中使用隐式等待，以免影响所有步骤。
3. 浏览器管理：
   • 对于不需要Cookie隔离的测试，考虑复用浏览器实例（但要注意测试间的状态清理）。
   • 在CI中，使用无头模式可以节省资源。
   • 测试结束后，务必调用driver.quit()，防止chromedriver进程残留。
4. 测试用例设计：
   • 遵循“一个测试用例验证一个业务点”的原则，保持用例简短独立。
   • 利用@BeforeMethod进行最小化的前置准备（如打开登录页），@AfterMethod进行清理。复杂的准备（如创建测试订单）可以放在具体的@Test方法里或通过API预先准备。

这套“Selenium WebDriver + Java”的组合，其强大之处不在于某个炫酷的特性，而在于它的稳定性、可控性和深厚的生态。它允许你从简单的脚本开始，逐步构建起一个覆盖关键业务流程、集成到CI/CD管道、能够快速反馈质量状态的自动化测试体系。这个过程本身，就是对软件质量和开发流程的深刻塑造。