做了几年UI自动化的人，大概率都经历过这个阶段：脚本越写越多，维护成本越来越高，每次前端改版都像抽签，不知道哪些用例会挂。我之前带过一个项目，登录按钮的ID从login_btn改成了submit_btn，全仓库70多条用例，牵连了42条。当时大家的第一反应是"谁改的页面"，但冷静下来想，问题根源不在前端，在测试代码的架构。

后来我们把整套UI脚本按Page Object Model（POM）重写了一遍，同样的改动，维护量从42条用例变成了1个页面对象类。这篇文章就是我在这个过程中沉淀下来的完整思路和实操细节。POM不是一个高深的概念，它就是把页面抽象成对象，把操作动作封装成方法，让脚本像积木一样拼接复用。适合刚接触UI自动化的同学建立正确骨架，也适合已经写了大量杂乱脚本、正在寻求重构思路的测试开发。

1. POM到底是什么，为什么UI自动化离不开它

1.1 从“面条脚本”到分层架构的演变

先看一段我早期写的代码，大家感受一下：

def test_login_success(): driver = webdriver.Chrome() driver.get("https://example.com/login") driver.find_element(By.ID, "username").send_keys("tester") driver.find_element(By.ID, "password").send_keys("123456") driver.find_element(By.ID, "login_btn").click() assert "欢迎" in driver.page_source driver.quit()

单看一条用例，清爽利落。但项目一旦到了几十条用例，问题就全出来了。定位信息By.ID("username")散落在各处，改一次元素ID要全局替换；操作逻辑和断言逻辑搅在一起，脚本的可读性全靠程序员当时的发挥；更别提复制粘贴导致的冗余，同一个登录动作能有好几种写法，有人用page_source断言，有人用等待URL变化，标准极不统一。

这种"想写哪就写哪"的脚本，业内有个很形象的词——面条脚本。它最大的问题不是运行不稳定，而是维护成本随脚本数量指数上涨。前端只要调整一次页面结构，后面跟着的是一整片用例崩塌。

POM解决的就是这件事。它的核心思路是：把页面当成一个对象来建模，这个对象里的每个元素是属性，每个操作是方法。测试用例不再直接面对driver和By，而是面对一个像人一样"会操作页面"的对象。

1.2 核心思想：积木从哪儿来

天天喊"像积木一样复用"，积木到底是指什么？我理解的POM里有三种积木块。

第一块是元素定位积木。同一个页面上的ID、XPath、CSS选择器，统一收在页面对象类里，不要散落得到处都是。第二块是业务操作积木。把"输入用户名→输入密码→点登录"这种组合动作封装成一个login()方法，调用方只需要传两个参数。第三块是页面对象本身。一个页面一个类，登录页就是LoginPage，首页就是HomePage，每个页面对象提供自己的操作方法，页面之间的跳转通过方法的返回值串联。

这三层积木拼起来，测试用例就变得特别干净。拿上面的例子对比，用POM写法第一条用例会变成这样：

def test_login_success(): home_page = LoginPage(driver).login("tester", "123456") assert home_page.is_logged_in()

从用户视角看，它就是"打开登录页→登录→断言首页状态"。至于登录按钮的ID是什么、密码框怎么定位，这些细节全部被LoginPage内部消化掉了。前端改版的时候，改的是登录页这一块积木，其他所有用例都不受影响。

1.3 什么项目需要POM，什么项目不需要

我也见过有人说POM太重、是过度设计。这里我说句实话：如果只是临时跑几十条一次性脚本，用完就扔，那确实没必要上POM。但只要是会持续迭代的UI自动化工程，哪怕现在只有10条用例，我也建议按POM搭骨架。原因很简单，自动化测试项目的生命周期比大部分人预想的要长。脚本写完只是开始，后面半年、一年里，前端改版、新增功能、回归迭代，全都在往下滚。

用生活类比来说，面条脚本像是一张写满字的手抄笔记，写的时候痛快，但每次改一个字都要整页重新誊写；POM像是一套带卡扣的积木箱，每块积木可以单独拆卸、替换、重新组合。前期多花两天时间给积木做好接口，后期省下的是每个月维护脚本的成块时间，这笔账怎么算都不亏。

2. POM框架的经典分层与核心模块

2.1 BasePage：所有页面对象的地基

在搭建页面对象之前，第一步永远是先做一个BasePage基类。它是整个POM体系里最容易被低估的部分。很多人以为POM就是把定位器收进类里，实际上，真正决定脚本稳定性和可维护性的，是基类里封装的公共方法。

先看一个Java版本的BasePage骨架：

public abstract class BasePage { protected WebDriver driver; protected WebDriverWait wait; public BasePage(WebDriver driver) { this.driver = driver; this.wait = new WebDriverWait(driver, Duration.ofSeconds(10)); } protected WebElement findElement(By locator) { waitForElementVisible(locator); return driver.findElement(locator); } protected void click(By locator) { WebElement element = wait.until(ExpectedConditions.elementToBeClickable(locator)); element.click(); log("click " + locator.toString()); } protected void type(By locator, String text) { WebElement element = findElement(locator); element.clear(); element.sendKeys(text); log("type " + locator.toString() + " -> " + text); } protected boolean isElementVisible(By locator) { try { wait.until(ExpectedConditions.visibilityOfElementLocated(locator)); return true; } catch (TimeoutException e) { return false; } } protected void waitForUrlContains(String keyword) { wait.until(ExpectedConditions.urlContains(keyword)); } }

这个基类有几个设计要点值得讲透。

第一，统一等待策略。所有元素查找都走显式等待，默认超时10秒，内部按需拓展。不要让每个页面对象自己写WebDriverWait，也不要让业务层代码里出现Thread.sleep。等待策略收敛在基类，意味着全项目的行为是一致的，排查问题时只需要看一处。

第二，操作即日志。我在click和type里都埋了日志，每次操作都会记录操作类型和定位器。这些日志在调试用例时价值巨大——用例失败后翻日志，能精确看到是执行到哪一步挂的，而不需要人肉去猜脚本执行到了哪个环节。

第三，方法粒度有讲究。findElement是protected的，意味着外部不能直接拿元素，但页面对象内部可以用。这层约束是刻意设置的，目的是防止有人绕过页面对象的封装，直接在测试用例里写driver.findElement。

2.2 Page Object：一个页面一个类

BasePage打好底子之后，真正的页面对象类就简单多了。每个页面一个类，类里只做两件事：定义页面上关心的元素定位器，定义这个页面能完成的业务动作。

以登录页为例，完整的写法是下面这样：

public class LoginPage extends BasePage { private By usernameInput = By.id("username"); private By passwordInput = By.id("password"); private By loginButton = By.id("login_btn"); private By errorMsg = By.cssSelector(".login_error"); public LoginPage(WebDriver driver) { super(driver); } public HomePage login(String username, String password) { type(usernameInput, username); type(passwordInput, password); click(loginButton); return new HomePage(driver); } public String getErrorMessage() { return findElement(errorMsg).getText(); } }

这个类看着简单，但里面有几个经验值得展开。

定位器用了By类型的成员变量，而不是散落在方法里的字符串常量。这样做的直接好处是类顶部罗列了当前页面所有依赖的元素，评审代码和排查问题时一眼就能看全。红色感叹号对不对、密码框之类的常见定位错误，扫一眼就能发现。

login()方法返回的是HomePage，不是void。这是POM里非常关键的设计决策——方法的返回值代表页面跳转。登录成功之后，当前页面已经变成了首页，那么返回首页对象，让调用方可以直接在首页上继续操作。这个设计让页面之间的导航关系在代码层面一目了然，测试用例读起来就是一条清晰的用户旅程。

2.3 Test Case：只讲业务，不谈实现

在POM框架里，测试用例是最薄的一层，它只描述业务场景，不关心页面实现。

public class LoginTest extends BaseTest { @Test public void testLoginSuccess() { HomePage homePage = new LoginPage(driver).login("tester", "123456"); Assert.assertTrue(homePage.isLoggedIn()); } @Test public void testLoginWithWrongPassword() { LoginPage loginPage = new LoginPage(driver); loginPage.login("tester", "wrong_password"); Assert.assertEquals("用户名或密码错误", loginPage.getErrorMessage()); } }

注意第二个用例：登录失败之后页面还在登录页，所以login()方法在业务上是"登录失败"的场景下并没有发生跳转，但我们的login()方法写死了返回HomePage，这就出现了一个设计矛盾。

实际项目里我会做一点妥协：登录方法不写死返回HomePage，而是根据业务需要返回LoginPage本身或者提供LoginPage与HomePage两个方法。比如拆成loginSuccess()返回HomePage、loginWithError()返回LoginPage并暴露错误信息。这样用例读起来既清晰又不违背页面跳转的客观事实。这个小坑，很多POM教程不会提到，但实际写代码时几乎一定会撞上。

3. 手把手搭建一套可落地的POM框架

3.1 目录结构怎么摆，从第一天就别乱

POM框架落地，第一步是规划目录结构。这不是形式主义，而是为了让"谁该放哪儿"这种问题不再需要讨论。

以Java工程为例，我常用的结构是：

src/test/java/com/example/autotest/ ├── base/ │ ├── BasePage.java # 页面对象基类 │ └── BaseTest.java # 测试基类，管理driver生命周期 ├── pages/ │ ├── LoginPage.java │ ├── HomePage.java │ ├── ProductPage.java │ ├── CartPage.java │ └── ... ├── components/ # 页面碎片组件 │ ├── HeaderComponent.java │ └── SearchComponent.java ├── testcases/ │ ├── LoginTest.java │ └── OrderTest.java ├── data/ # 测试数据文件 ├── utils/ # 工具类 └── config/ # 环境配置

pages放页面对象，components放可复用的页面碎片，testcases放用例，base放基类。这个划分是POM社区经过多年实践沉淀下来的标准，尽量不要发明新结构。页面对象和测试用例严格分开，这一点是雷打不动的——如果有人把用例写在pages包里，代码评审时我会直接打回。

Python版本的工程结构类似，只是包名换成base、pages、testcases，用例通常用pytest管理。无论用什么语言，结构思路是一样的：分层清晰，依赖方向从用例指向页面对象，页面对象指向基类，不允许反向依赖。

3.2 BaseTest：把driver生命周期管起来

页面对象里的driver从哪来？规范做法是放在BaseTest里统一管理。每次用例运行前创建driver，运行结束后清理，中间把driver注入到页面对象里。

public class BaseTest { protected WebDriver driver; @BeforeMethod public void setUp() { driver = new ChromeDriver(); driver.manage().window().maximize(); driver.get("https://example.com"); } @AfterMethod public void tearDown() { if (driver != null) { driver.quit(); } } protected void captureScreenshot(String name) { // 失败截图统一处理 } }

这里有个很容易踩的坑：driver的创建和销毁必须配对。我见过不少脚本，用例执行失败抛异常后，driver没有正常退出，Chrome进程残留一堆，后面用例越跑越慢，最后整个环境卡死。解决方法是把driver.quit()放在tearDown或fixture的清理阶段，无论用例成功失败都会执行。

3.3 页面对象类的实现细节，用登录页举例

有了基类和driver管理，写页面对象类就只剩下往里面填东西了。拿最经典的登录页走一遍完整流程。

第一步，确定页面上哪些元素是测试关心的。登录页通常有关键输入框、登录按钮、错误提示、验证码区域——注意，验证码区域如果测试环境关不掉，就要考虑走后端绕过或者专门处理，不要硬写在页面对象里。

第二步，把元素定位器定义为成员变量：

private By usernameInput = By.id("username"); private By passwordInput = By.id("password"); private By loginButton = By.id("login_btn"); private By rememberCheckbox = By.name("remember");

第三步，封装业务动作。这里有个命名规范很关键：方法名要像人话，不要像操作。别写click_username_input()这种，要写input_username()；别写click_login_btn()这种，要写login()。方法的意义在于表达意图，而不是描述动作细节。

public HomePage login(String username, String password) { inputUsername(username); inputPassword(password); clickLoginButton(); return new HomePage(driver); } private void inputUsername(String username) { type(usernameInput, username); }

第四步，处理可能需要复用的判断逻辑，比如isLoginErrorShown()、isRememberChecked()，把这些状态判断方法也放到页面对象里。

Python版本我平时也常用，写法上定位器用元组，结构同样清晰：

class LoginPage: def __init__(self, driver): self.driver = driver self.username_input = (By.ID, "username") self.password_input = (By.ID, "password") self.login_button = (By.ID, "login_btn") def login(self, username, password): self.driver.find_element(*self.username_input).send_keys(username) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_button).click() return HomePage(self.driver)

无论哪种语言，页面对象本质上就是"页面元素字典 + 业务动作方法集合"。写页面对象的时候心里要有一个标尺：这块逻辑是某个页面私有的，就写进页面对象里；是多个页面共用的，就下沉到BasePage或组件类里。

3.4 测试用例怎么用“积木式”组合

页面对象做好了，测试用例就变成了一块一块组件拼接的过程。

比如一个完整的下单流程，可以这样串联：

public class OrderFlowTest extends BaseTest { @Test public void testSubmitOrder() { HomePage home = new LoginPage(driver).login("tester", "123456"); ProductPage product = home.searchProduct("无线耳机"); CartPage cart = product.addToCart(); OrderPage order = cart.checkout(); Assert.assertTrue(order.isOrderSubmitted()); } }

每条方法都返回下一个页面的对象，调用链就是用户旅程。这就是"积木式复用"最直观的体现：登录是一块积木，搜索是一块积木，加购是一块积木，结算是一块积木。测试用例描述的是积木怎么拼，页面对象封装的是积木本身怎么实现。

更重要的是，这种结构让维护变得极其精准。前端改了购物车的结算按钮，我只需要改CartPage里一个定位器或一个方法，OrderFlowTest一行都不用动。前端改了登录逻辑，我只改LoginPage，所有依赖登录的用例自动跟着变。一个改动波及的范围被压缩到了最小。

4. 实战中的常见问题与排查技巧

4.1 动态元素定位失效，怎么定位最稳

POM落地后，遇到最多的实战问题是定位器失效。特别是现在的前端框架普遍带动态渲染，元素的ID会带上随机数，比如id="user_name_ab3f2d"，每次刷新都不一样。遇到这种页面，把ID直接写死必挂。

我的排查思路有优先级。先看HTML里有没有稳定的业务属性，比如>public class HeaderComponent { private WebDriver driver; private By searchInput = By.cssSelector(".header input[name='q']"); private By userAvatar = By.cssSelector(".header .avatar"); public HeaderComponent(WebDriver driver) { this.driver = driver; } public void search(String keyword) { driver.findElement(searchInput).sendKeys(keyword); driver.findElement(searchInput).sendKeys(Keys.ENTER); } } public class HomePage extends BasePage { private HeaderComponent header = new HeaderComponent(driver); public ProductPage searchProduct(String keyword) { header.search(keyword); return new ProductPage(driver); } }

页面碎片的作用是让组件在自己的类里闭环维护。顶部搜索框的定位器改了，只需要改HeaderComponent，所有嵌入了这个组件的页面对象都不受影响。这相当于积木层面又往下细了一层——大的积木块内部，还有更小的积木块，每一层都做到独立替换。

顺带说一句，有团队会把页面碎片单独建包，比如项目结构里的components目录。如果你的项目已经有大面积重复模块，强烈建议在POM基础上引入组件化。它和POM不冲突，是POM的延伸和细化。

5. POM不是孤岛——如何跟数据驱动、CI无缝衔接

5.1 把行为和数据分开，POM只管操作

POM把"页面细节"和"用户操作"分开之后，数据驱动自然就顺理成章了。页面对象里的方法接收参数，参数从哪来？从配置文件、Excel、YAML、接口返回，都可以。

登录用例的参数化是一个典型例子。登录场景要跑正常用户、错误密码、空密码、锁定账号等多组数据，如果用@DataProvider实现：

@DataProvider(name = "loginData") public Object[][] loginData() { return ExcelUtil.load("data/login_cases.xlsx"); } @Test(dataProvider = "loginData") public void testLogin(String username, String password, String expectedMsg) { LoginPage page = new LoginPage(driver); page.login(username, password); if ("success".equals(expectedMsg)) { Assert.assertTrue(new HomePage(driver).isLoggedIn()); } else { Assert.assertEquals(expectedMsg, page.getErrorMessage()); } }

POM在这里承担的角色是"动作执行器"。数据驱动决定"用哪组数据跑哪个场景"，POM负责"这些数据怎么作用于页面"。两者各司其职，一份测试数据可以驱动多套页面对象，页面对象改了测试数据不用动，测试数据改了页面对象也不用动。

5.2 与关键字驱动结合，让测试用例更接近业务语言

还有一种常见的演进制是把POM继续包装成关键字驱动。测试用例不再直接调用页面对象方法，而是读取一套"关键字用例"，每个关键字映射到页面对象的一个方法。

比如在Excel里定义：

框架里做一个KeywordExecutor，解析每一行的关键字，反射调用对应页面对象的方法。这样测试用例本身连代码都不需要写，业务同学也能维护用例。POM在这里的作用是关键字执行器底层的"零件库"，每个关键字背后都对应着实际的页面操作实现。这种模式在大规模回归场景下特别有用——用例数量多、执行频率高、每次改动范围小。

5.3 怎么让POM和CI流水线配合得更好

POM结构清晰之后，CI上跑自动化测试的体验也会好很多。因为用例日志天然以"业务动作"为粒度，失败时能很清楚地看到是登录失败了、还是搜索失败了、还是下单流程断言挂了。

我的实践是在CI的失败处理里加一个通用策略：用例失败自动截图，截图命名带上页面对象类名和方法名。因为POM框架里每个动作都有日志，配合截图，一张失败截图就能还原出执行到哪一步出了什么问题。

另外，POM也天然适合做或多或少的失败自动重试。如果某个用例挂在了click之后跳转没有发生，大概率是环境波动而不是业务缺陷，重试一次往往就过了。在测试基类里加一个简单的重试机制，重试超过两次仍然失败才上报。这部分和POM本身无关，但POM的打底日志和动作级定位能力，让重试策略不会误伤真正的缺陷。

我个人的体会是，POM这个模式本身不难，难的是在项目里坚持分层、坚持封装、坚持不让定位器和driver泄漏到用例层。这套框架搭完之后，后续的工作重心就从"修脚本"变成了"加积木"——新功能来了，写一个页面对象，写一条用例，完事。希望这篇文章能帮你把地基打牢，少走我当年走过的弯路。