企业官网建设流程全解析

做Web UI自动化测试超过十年，如果要我在所有设计模式里挑一个最值得先搞懂的，我会毫不犹豫选PO。不是因为它时髦，而是因为它特别能治“脚本越写越乱、一改就崩”的毛病。页面对象模式（Page Object Model，简称PO）说白了就是把一个页面的所有操作和元素定义收拢到一个类里，测试用例只关心业务动作，不跟CSS/XPath死磕。这篇文章会把PO模式从原理到落地完整过一遍，包括BasePage怎么写、页面对象怎么拆分、等待怎么处理、用例怎么维护，全都是我在真实项目里反复验证过的做法。不管你是刚接触Web UI自动化测试的新手，还是已经在脚本堆里挣扎的老手，照着这套思路都能少走不少弯路。

1. PO模式：Web UI自动化测试绕不开的设计套路

1.1 先厘清PO到底解决什么问题

我见到的第一个自动化测试项目是典型的线性脚本：打开浏览器，找到用户名输入框，输入账号，找到密码框，输入密码，点登录，然后写断言。听上去很顺，但脚本超过50条之后就开始失控。最常见的问题是页面结构稍微调整一下，比如登录按钮的class从btn-primary改成btn-danger，你就得把所有写死这个class的脚本翻出来改一遍。这种改法非常容易漏，漏了就是失败用例半夜报警。

PO模式的核心思路是拿空间换时间，把页面上的元素定位和操作逻辑全部集中到页面对象里。比如登录页，你定义一个class LoginPage，里面有一个login方法，输入用户名和密码，再点登录。测试用例这边只需要拿到LoginPage的实例，调用login方法，至于用户名框到底用什么定位符、登录按钮是button还是a标签，用例里一概不关心。以后登录按钮变了，你只需要改LoginPage一个地方。

不要小看这个转变。对于只有几十条用例的小项目，线性脚本和PO的区别可能不明显。但到了三四百条用例、五六个人协作的阶段，没有PO的项目基本就是定时炸弹。每个用例都在裸操作driver，定位符散落各地，重复代码成堆，一旦某个公共组件改版，整个测试集都会红成一片。

1.2 为什么它能成为行业标配

PO能成为行业标配，核心原因是它让自动化测试从“脚本编写”升级成了“工程建模”。你现在维护的不再是一堆机械执行步骤，而是一套能反映业务页面的对象体系。登录页是一个对象，首页是一个对象，订单列表页是一个对象，每个对象只负责自己的领域。测试用例变成了一连串业务动作的组合：登录、搜索、下单、支付。这跟手工测试人员理解业务的方式非常接近，新同学上手也会快很多。

它还顺带解决了几个焦虑。第一是复用，一个登录方法可以被一百条用例调用，不用每次重写。第二是稳定性，因为元素集中在页面对象里，你可以在页面对象这个层面统一处理等待和异常，而不是在每条用例里疲于奔命。第三是团队协作，每个人负责不同的页面对象，互不干扰，代码冲突概率大幅下降。

很多人以为用PO是为了省代码量，实际效果恰恰相反，初期代码量会多一些。你多写了BasePage、页面对象、定位符，但从长远看，维护成本是线性下降的。这就跟写项目代码要分层一样，controller、service、dao各司其职，测试代码同样需要分层。

1.3 适用场景与不适用场景

PO不是万能的。如果你只是临时验证一个页面、跑一次就扔的冒烟测试，没必要上PO，直接脚本反而更快。接口自动化测试也不适合套用PO，因为接口没有“页面”这个实体。另外，如果你的Web应用还在频繁改版阶段，比如布局每两周换一次，那PO的价值会打折扣，但即便如此，PO依然比裸脚本好维护，因为改动被限制在一个类里。

我的判断标准很简单：这批自动化脚本的生命周期会不会超过两周？会，就值得上PO。会不会被多个人共同维护？会，就强烈建议上PO。会不会覆盖的是核心业务链路，比如登录、注册、下单？会，那PO基本上是必选项。

2. 从零实现一个PO：核心组件与代码拆解

2.1 目录结构与依赖选型

真正动手之前，先把项目结构搭好。我常用的目录长这样：

web_auto/ ├── pages/ │ ├── __init__.py │ ├── base_page.py │ ├── login_page.py │ └── home_page.py ├── tests/ │ ├── __init__.py │ └── test_login.py ├── conftest.py ├── pytest.ini └── requirements.txt

pages目录放页面对象，tests目录放测试用例，conftest.py放pytest的fixture。这个结构简单，但随着规模变大可以再拆，比如加components目录放组件对象、data目录放测试数据。

依赖选型方面，后端我选Python + Selenium，测试框架用pytest。Selenium是Web自动化事实标准，这点没什么好争的。pytest比unittest强在fixture机制和断言风格，参数化也更方便。浏览器驱动管理用webdriver-manager，省去手动下载driver的麻烦，还能避免driver版本跟浏览器版本对不上导致的问题。报告用allure-pytest，出错了看截图和日志都比较直观。

2.2 BasePage基类的设计要点

BasePage是整个PO体系的底座。它做的事很简单：把Selenium原生的driver操作包一层，让子类代码更简洁。但包这一层大有讲究，不是为了包而包，而是要把重复逻辑收进来。

from selenium.webdriver.remote.webdriver import WebDriver from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By class BasePage: def __init__(self, driver: WebDriver, timeout: int = 10): self.driver = driver self.timeout = timeout def find_element(self, locator): """封装查找元素，默认使用显式等待，避免元素未加载就操作""" return WebDriverWait(self.driver, self.timeout).until( EC.presence_of_element_located(locator) ) def click(self, locator): """点击元素前先等待元素可点击""" element = WebDriverWait(self.driver, self.timeout).until( EC.element_to_be_clickable(locator) ) element.click() def input_text(self, locator, text): """输入前先清空再输入，避免残留文本""" element = self.find_element(locator) element.clear() element.send_keys(text) def get_text(self, locator): element = self.find_element(locator) return element.text def wait_for_visible(self, locator): return WebDriverWait(self.driver, self.timeout).until( EC.visibility_of_element_located(locator) )

这里有个关键点：BasePage里不要把所有操作都封装一遍，只封装高频操作，比如find、click、input、get_text。低频操作你可以在具体页面对象里直接用driver，或者用到的时候再往BasePage里加。过度封装会让BasePage变成一个大杂烩，后期没人敢动。

另一个关键点是等待机制。为什么用显式等待而不是全局time.sleep？因为sleep是死等，等就等固定时间，不管元素是否已经出现，白白浪费好几秒。显式等待是轮询判断，元素一旦满足条件就立即继续。我见过一个项目为了稳，每个操作前都sleep 3秒，跑一条用例要十分钟，后来改成显式等待直接缩短到两分钟。

2.3 页面对象类怎么写才不飘

页面对象类不是把页面上的元素罗列一遍就完事，而是要建模成用户可以理解的动作。以登录页为例：

from selenium.webdriver.common.by import By from pages.base_page import BasePage class LoginPage(BasePage): username_input = (By.ID, "username") password_input = (By.ID, "password") login_button = (By.CSS_SELECTOR, "button[type='submit']") error_msg = (By.CLASS_NAME, "error-tip") def login(self, username: str, password: str): self.input_text(self.username_input, username) self.input_text(self.password_input, password) self.click(self.login_button) def get_error_message(self) -> str: return self.get_text(self.error_msg)

能看出来，页面对象里只出现了用户能理解的操作：login、get_error_message。没人希望看到click_login_button这样裸露的实现细节。我见过不少新手把页面对象写成这样：self.find_element(login_button).click()直接堆在测试用例里，那就失去了PO的意义。

页面对象的方法返回值也值得琢磨。登录成功后你大概率要跳到首页，那login方法要不要返回HomePage对象？我的习惯是不论成功失败，都返回当前页面对象。比如登录成功后返回HomePage，登录失败返回LoginPage本身，这样在用例里写链式断言非常舒服。后面实操会看到。

2.4 元素定位策略与等待机制

元素定位符是PO里最容易出问题的地方。优先级我永远是：id优先，然后name，然后CSS，最后才是XPath。id是页面元素的身份证，只要前端没有动态生成id，它就是最稳定的。CSS选择器效率高、语法简洁，适合复杂层级，比如input[name='keyword']。XPath虽然万能，但写长了就是灾难，尤其绝对路径那种/html/body/div[2]/div[3]/form/input[1]，前端稍微加一层div就全面崩盘。能用相对定位就用相对定位，能加测试专用属性就加测试专用属性。

等待机制前面提了显式等待，这里再具体一点。我推荐在页面对象里定义操作时先判断这个操作需要什么前置条件。比如点击按钮，前置条件往往是按钮可点击，那用element_to_be_clickable。获取文本，前置条件是元素可见，用visibility_of_element_located。单纯判断元素存在用presence_of_element_located。三个条件看起来很接近，但用错就出问题，比如元素在DOM里存在但还没渲染完成，你直接取text取出来是空的。

等待超时时间怎么设？我的经验是内网系统5秒足够，公网系统可以放宽到15秒，默认10秒。别把超时时间设成60秒，否则元素真不见了，一条用例要挂一分钟，CI排期直接爆炸。也别设成1秒，稍微慢一点就误报。这个值应当是个可配置项，我在BasePage里用timeout参数就是为了方便在fixture里统一调整。

3. 实操演练：以登录流程为例完成一个PO用例

3.1 需求描述与页面建模

这里我们做一个完整的登录模块自动化用例。假设某系统的登录页有一个用户名输入框、一个密码输入框、一个登录按钮，登录成功后跳转首页并显示用户昵称；登录失败则显示错误提示文本。这是最常见的场景，用它来做例子再合适不过。

页面建模分三步。第一步识别页面边界，登录页自成一个Page类，首页自成一个Page类。第二步识别关键元素，登录页需要用户名、密码、登录按钮、错误提示；首页需要用户昵称。第三步设计操作流程，login操作对应输入用户名、输入密码、点击登录，get_user_nickname对应获取首页昵称文本。

建模这一步是PO的灵魂，建模建得好，后面写代码就是填表格。模特建得烂，后续维护会非常痛苦。我见过有人把页面对象建成了“元素仓库”：一个类放几十个定位符，方法全是find_element，没有业务动作。那不是PO，那是帮倒忙。

3.2 编写页面对象和用例代码

先写BasePage，前面已经给过。再写LoginPage：

from selenium.webdriver.common.by import By from pages.base_page import BasePage from pages.home_page import HomePage class LoginPage(BasePage): username_input = (By.ID, "username") password_input = (By.ID, "password") login_button = (By.CSS_SELECTOR, "button[type='submit']") error_msg = (By.CLASS_NAME, "error-tip") def login(self, username: str, password: str): self.input_text(self.username_input, username) self.input_text(self.password_input, password) self.click(self.login_button) def login_success(self, username: str, password: str) -> HomePage: self.login(username, password) return HomePage(self.driver) def get_error_message(self) -> str: return self.get_text(self.error_msg)

HomePage最简单，只负责展示用户昵称：

from selenium.webdriver.common.by import By from pages.base_page import BasePage class HomePage(BasePage): nickname = (By.CLASS_NAME, "user-nickname") def get_user_nickname(self) -> str: return self.get_text(self.nickname)

测试用例写起来就很清爽了：

import pytest from pages.login_page import LoginPage def test_login_success(login_page): home_page = login_page.login_success("test_user", "pass_123") assert home_page.get_user_nickname() == "测试用户" def test_login_wrong_password(login_page): login_page.login("test_user", "wrong_password") assert login_page.get_error_message() == "用户名或密码错误"

等等，这里我直接用login_page这个fixture，还没写conftest.py。补上：

import pytest from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service from pages.login_page import LoginPage @pytest.fixture def driver(): service = Service(ChromeDriverManager().install()) driver = webdriver.Chrome(service=service) driver.get("https://example.com/login") driver.maximize_window() yield driver driver.quit() @pytest.fixture def login_page(driver): return LoginPage(driver)

这套代码跑起来的前提是前端页面确实有对应的元素。真实项目中我一般会建议前端同学给关键交互元素加上带test-前缀的专用属性，比如>@pytest.fixture def user_data(): return { "username": "test_user", "password": "pass_123", "nickname": "测试用户", } def test_login_success(login_page, user_data): home_page = login_page.login_success(user_data["username"], user_data["password"]) assert home_page.get_user_nickname() == user_data["nickname"]

4. 常见问题与排查技巧实录

4.1 定位不到元素的经典原因

定位不到元素是Web UI自动化测试里出现频率最高的报错，NoSuchElementException一出来，新手就慌。我总结过几个经典原因，顺序排查能解决九成问题。

第一是动态id。前端框架比如某前端框架，经常生成类似input_12345这种带数字后缀的id，每次刷新都变。这属于绝对不能用id定位的情况，要改用name、class或者别的方式。第二是元素在iframe里。如果你没有切到iframe里面，driver是万万找不到里面元素的。排查方法很简单，在浏览器DevTools里选中元素，查看它的层级是不是被iframe包着，是的话就要先driver.switch_to.frame()。第三是元素不在当前页面，可能是弹窗遮住了，也可能是滚动条没滚到可见区域，用element_to_be_clickable比presence_of_element_located更能发现这个问题。

还有一个隐蔽原因：元素在Shadow DOM里面。普通XPath和CSS选择器默认进不了Shadow DOM，需要专门的处理方式。如果项目里用了Web Component，你要提前了解这块。

我习惯的排查动作是先打开DevTools，按Ctrl+F输入定位符，看能匹配几个元素。能匹配但脚本报找不到，问题多半出在frame或者窗口切换上。匹配不到，那就是定位符写错了。

4.2 页面对象爆炸与过度封装

PO模式用得激进也会出事。我见过一个项目，每个页面建了超过十个Page类，一个测试模块就拆得稀碎，页面对象之间互相继承，看得人头大。这种情况叫“页面对象爆炸”。

爆炸的原因是把PO用错了方向。PO应该按“用户视角的页面/组件”划分，不是按“页面上的每个区块”划分。比如登录页是一个Page类，这个没问题。但登录页里有个导航栏，导航栏里又有个用户头像下拉菜单，如果你为每个区块都建一个Page类，最后类数量肯定爆炸。

解法是引入组件对象（Component Object）的概念。当一个页面对象内部有多个可复用的区块时，可以把区块封装成组件类，页面对象持有组件实例。比如有个Header组件，负责整个系统顶部的导航，那多个页面只要复用这个Header组件就行。注意组件对象不是独立页面，它依然是页面对象的组成部分。

另一头是过度封装。有的团队为了让代码“优雅”，把send_keys包装成input_text_with_retry，把click包装成click_with_report，层层套娃。结果就是排查问题时要翻好几层源码，特别累。我建议封装最多两层，BasePage一层，具体操作一层，再多就不值得了。

4.3 测试数据与页面对象解耦

页面对象负责动作，测试数据负责输入，这两个东西必须分开。哪有直接把账号密码写死在页面对象方法里的？我确实见过，比如login()方法内部默认就是admin/123456，别人想换个账号登录还得把源码改一遍，这种设计基本没考虑复用。

解耦的正确姿势包括三类数据。第一类是静态用户数据，就是账号密码、昵称、邮箱这种，放在数据文件里，通过fixture读取。第二类是业务参数，比如搜索关键词、订单金额，用pytest的参数化机制传进用例。第三类是环境相关配置，比如不同环境的URL和超时时间，放环境变量或者独立配置文件里。

import pytest @pytest.mark.parametrize("keyword", ["手机", "笔记本电脑", "耳机"]) def test_search(home_page, keyword): result = home_page.search(keyword) assert result.has_items()

页面对象本身只接受入参，不自己造数据。这样以后数据调整了，用例和页面类都能保持稳定。这是PO能长期维护下去的重要前提。

4.4 并发执行时的PO陷阱

以前吃过大亏，所以这块必须单独拿出来说。团队为了提升执行速度，把测试用例扔到多进程或多线程里跑，结果速度没提升多少，失败率倒是暴涨。原因很简单：driver不是线程安全的。

每个线程/进程必须使用独立的浏览器driver实例，不能让多个用例共享同一个driver。在pytest里，fixture默认是function级别，也就是每个用例一个driver实例，这点是安全的。但如果有人图省事，把driver设置为模块级别或类级别的变量，并发跑就会出现一个用例关掉了浏览器，另一个还在操作旧页面的情况。

我见过最离谱的写法是在Page类里用类属性存driver：

class LoginPage(BasePage): driver = webdriver.Chrome() # 错误示范，千万别这样

一旦并发，这个driver会被不同线程抢着用，轻则NoSuchElementException，重则整个测试进程挂掉。正确做法是driver作为实例属性传递，通过fixture在每个用例中创建。

另外，并发执行时如果使用同一个测试账号，容易互相踢下线。比如A用例登录把B用例的服务端session挤掉了，B用例就莫名失败。解决办法是数据隔离，每个并发用例使用独立账号，或者对测试环境做会话隔离处理。

5. 经验沉淀：让PO在你团队里真正落地

5.1 从脚本到框架的演进路线

如果你现在还在写裸脚本，不要想着一步到位搭一个完美的PO框架，那只会让团队陷入长时间的重构。我推荐的路径是先养活脚本，再逐步引入PO。

第一阶段是写“能跑”的脚本，把核心业务链路跑通，哪怕代码丑一点也没关系。第二阶段是在这些脚本里找出变化最频繁的页面，把它们的元素定位和操作抽成Page类。这个过程不需要推到重来，抽一个类就替换对应的脚本调用。第三阶段是统一BasePage，把等待、点击、输入这些公共操作收敛好，同时补齐fixture和目录结构。第四阶段才是组件化、数据驱动、并发执行这些进阶能力。

很多人问为什么要这么慢。因为PO改造本身不产生直接的功能价值，它提升的是维护效率。如果你一次性重写所有脚本，期间没人能跑回归测试，业务方就会对自动化失去信心。小步快走，每周重构几个页面，反而能让团队成员逐渐理解PO的好处。

5.2 代码评审时重点看什么

PO代码同样需要评审，但评审重点和业务代码不一样。我看PO代码时有一套自己的清单。

第一看定位符。如果出现//*[@id="app"]/div[3]/div[1]/div/div[2]/form/div[1]/input这种绝对路径，直接打回，要求改成相对定位或添加测试专用属性。第二看方法命名。页面对象方法必须是业务动作，login、search、add_to_cart，如果看到click_button_1这种命名，说明建模存在问题。第三看等待处理。有没有到处用sleep？有没有点击前根本不等待？这些都是隐患。第四看返回对象。页面跳转对不对，链式调用是否清晰。第五看是否把断言写进了页面对象。

页面对象里不能有assert，这是硬性规定。页面对象负责“做什么”，断言是“验证什么”，验证逻辑属于测试用例层。一旦把断言写进页面对象，同一个页面在不同场景下的期望结果不同，这个类就没法复用了。

5.3 我踩过的几个坑

这一节就全是真金白银了。我有一次负责某系统的自动化重构，一个同事很勤快，给每个页面都写了Page类，但元素定位符写得很随意，比如用class写form-control这种会被复用的样式类。结果前端一改版，几十个页面类同时挂，定位到的全是无关元素，修了一个礼拜。后来我强制要求所有关键元素必须有稳定的语义化定位符，要么id，要么data-testid，要么配合业务逻辑的CSS选择器。定位符稳定，PO才能稳。

第二个坑是关于加载等待的。以前我喜欢在BasePage里默认给所有元素操作加sleep(1)，认为这样可以减少误报。事实证明这就是给CI挖坑，本来就该3秒完成的用例硬生生拖到30秒。后来我明白了，等待不是越久越稳，而是要“等得准”。元素可交互了就该立刻操作，等太久只会掩盖真正的问题。

第三个坑和首页对象相关。有段时间我们把首页的所有功能都塞进HomePage一个类里，结果HomePage越来越庞大，上千行代码，谁都不敢动。后来拆成了多个组件类，比如HeaderComponent、SidebarComponent、ContentComponent，HomePage只负责组装和调度。从那以后我深刻理解了一个词：单一职责。页面对象也一样，一个类最好只做一件事，做太多就是在给自己挖坑。

最后再分享一个我每次都会用到的小技巧：页面对象不要直接暴露driver。很多同学图方便，在用例里直接page.driver.find_element(...)绕过封装，一旦出了问题，封装等于白做。我在BasePage里没有暴露driver的公开属性，只提供封好的方法。如果确实要扩展，子类内部使用self.driver，但测试用例永远不应该看到driver的痕迹。这个习惯能逼着所有团队成员遵守PO纪律，长期下来代码质量会提升一大截。