第4章 Page Object模式实战

第4章：Page Object模式实战：POM设计思想、BasePage封装、Page层与TestCase层分离

好，咱们进入实战环节。

前面几章我们聊了自动化测试的基础框架、元素定位、等待策略。说实话，那些都是基本功。但真正让测试代码变得可维护、可复用的，就是这一章要讲的——Page Object模式。

我个人习惯把POM比作「给页面建个模型」。你想想看，如果每个测试用例里都直接写driver.findElement(By.id("xxx")).click()，那页面一改，所有用例都得跟着改。这谁受得了？

4.1 POM设计思想：为什么需要它？

Page Object模式，说白了就是把页面抽象成一个对象。每个页面对应一个类，页面上的元素和操作都封装在这个类里。测试用例只跟这些类打交道，不直接操作浏览器。

我在项目中遇到过最典型的反面教材：一个登录功能，20个测试用例里写了40次driver.findElement。后来登录按钮的id变了，改代码改到凌晨三点。嗯，从那以后，我强制团队必须用POM。

核心原则：

封装变化：页面元素变了，只改Page类，不改TestCase
复用操作：一个页面操作（比如登录）可以被多个用例调用
降低耦合：测试用例不关心元素怎么定位，只关心业务逻辑

4.2 BasePage封装：把重复劳动干掉

BasePage是什么？是所有Page类的父类。它封装了最常用的操作，比如点击、输入、等待、截图等。

为什么要做这层封装？你想想看，每个页面都要等待元素可见、都要处理异常、都要截图。如果每个Page类都自己写一遍，那跟没封装有什么区别？

我曾经在项目里看到有人写了30个Page类，每个类里都有wait.until()的重复代码。后来我重构了一下，把公共方法抽到BasePage里，代码量直接砍掉40%。

我的习惯：BasePage里至少包含以下方法：

click(By locator) — 带等待的点击
sendKeys(By locator, String text) — 带清空的输入
getText(By locator) — 获取文本
isDisplayed(By locator) — 判断元素是否存在
waitForElementVisible(By locator) — 显式等待
takeScreenshot() — 失败时截图

来看一个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) {
        waitForElementVisible(locator);
        driver.findElement(locator).click();
    }

    protected void sendKeys(By locator, String text) {
        waitForElementVisible(locator);
        WebElement element = driver.findElement(locator);
        element.clear();
        element.sendKeys(text);
    }

    protected String getText(By locator) {
        waitForElementVisible(locator);
        return driver.findElement(locator).getText();
    }

    protected boolean isDisplayed(By locator) {
        try {
            return driver.findElement(locator).isDisplayed();
        } catch (NoSuchElementException e) {
            return false;
        }
    }

    protected void waitForElementVisible(By locator) {
        wait.until(ExpectedConditions.visibilityOfElementLocated(locator));
    }

    protected void takeScreenshot(String fileName) {
        // 截图逻辑，这里省略具体实现
        System.out.println("截图保存为: " + fileName);
    }
}

你看，这些方法都加了等待和异常处理。每个子类继承BasePage后，直接调用click()、sendKeys()就行，不用再写等待逻辑了。

4.3 Page层封装：把页面变成对象

有了BasePage，我们来写具体的Page类。以登录页面为例：

public class LoginPage extends BasePage {
    // 元素定位器
    private By usernameInput = By.id("username");
    private By passwordInput = By.id("password");
    private By loginButton = By.id("loginBtn");
    private By errorMsg = By.className("error-message");

    public LoginPage(WebDriver driver) {
        super(driver);
    }

    // 页面操作：登录
    public void login(String username, String password) {
        sendKeys(usernameInput, username);
        sendKeys(passwordInput, password);
        click(loginButton);
    }

    // 页面操作：获取错误信息
    public String getErrorMessage() {
        return getText(errorMsg);
    }

    // 页面操作：判断是否登录成功
    public boolean isLoginSuccess() {
        return wait.until(ExpectedConditions.urlContains("/dashboard"));
    }
}

这里要注意几个点：

元素定位器统一放在类顶部，方便维护
每个方法只做一件事，比如login()只负责登录，不负责断言
方法名要见名知意，比如getErrorMessage()一看就知道是获取错误信息

避坑指南：我曾经见过有人把断言写在Page类里。比如login()方法里直接Assert.assertTrue(...)。千万别这么干！Page类只负责操作和获取状态，断言是TestCase的事。否则你的Page类就没法复用了。

4.4 TestCase层：只关心业务逻辑

TestCase层是测试用例的集合。它只做三件事：

创建Page对象
调用Page对象的方法
断言结果

来看一个完整的测试用例：

public class LoginTest extends BaseTest {
    @Test
    public void testLoginSuccess() {
        // 1. 创建Page对象
        LoginPage loginPage = new LoginPage(driver);

        // 2. 执行操作
        loginPage.login("admin", "password123");

        // 3. 断言结果
        Assert.assertTrue(loginPage.isLoginSuccess());
    }

    @Test
    public void testLoginWithWrongPassword() {
        LoginPage loginPage = new LoginPage(driver);
        loginPage.login("admin", "wrongpass");

        String errorMsg = loginPage.getErrorMessage();
        Assert.assertEquals("用户名或密码错误", errorMsg);
    }
}

你看，TestCase里没有任何driver.findElement，没有任何等待逻辑。代码干净得像刚擦过的白板。这就是POM的魅力。

4.5 分层的好处：改一处，全盘活

假设有一天，登录按钮的id从loginBtn变成了submitBtn。怎么办？

只需要改LoginPage类里的private By loginButton = By.id("loginBtn");这一行。所有用到这个按钮的测试用例，自动生效。

我算过一笔账：在一个有100个测试用例的项目里，如果不用POM，改一个元素定位平均需要改30-50个文件。用了POM，只改1个文件。效率差距是30倍以上。

总结一下POM的核心价值：

维度	不用POM	用POM
代码复用	低，每个用例重复写定位	高，Page类统一管理
维护成本	高，改一处要改所有用例	低，只改Page类
可读性	差，定位代码和业务逻辑混在一起	好，TestCase只关心业务
团队协作	难，每个人写法不一样	易，统一规范

4.6 实战建议：从一个小模块开始

如果你刚开始用POM，别想着把所有页面都重构一遍。我建议你：

选一个最常用的页面，比如登录页，先做封装
写一个BasePage，把公共方法放进去
写3-5个测试用例，验证封装是否好用
逐步推广到其他页面

嗯，这里要注意：POM不是银弹。如果页面逻辑特别简单（比如只有一个按钮），强行封装反而增加复杂度。灵活运用才是王道。

我的个人经验：在团队里推行POM时，不要一上来就讲理论。直接拿一个真实页面，现场演示「不用POM改一个元素要改10个文件」vs「用POM改1个文件」。效果立竿见影。

好了，这一章就到这里。下一章我们会聊数据驱动测试——怎么把测试数据从代码里抽出来，用Excel或YAML管理。到时候你会发现，POM加上数据驱动，才是自动化测试的完全体。

📚 课程目录