web自动化po设计模式

写Web自动化测试，动化绕不开PO。设计这不是模式什么高深理论，是动化踩坑踩出来的经验。PO全称Page Object，设计翻译过来叫页面对象。模式核心就一句话：把页面元素和操作从测试脚本里抽出来，动化单独放一个类里。设计测试脚本只负责调方法，模式不直接碰元素定位。动化

我见过太多人写自动化，设计上来就是模式driver.find_element(By.ID, "username").send_keys("admin")。一个登录流程写三遍，动化改个ID全盘崩溃。设计PO就是模式治这个病的。

一个登录页的对比

不用PO的写法：

driver.find_element(By.ID, "username").send_keys("admin") driver.find_element(By.ID, "password").send_keys("123456") driver.find_element(By.CLASS_NAME, "login-btn").click()

用PO之后：

login_page.input_username("admin") login_page.input_password("123456") login_page.click_login()

区别在哪？元素定位变了，只改LoginPage类，测试脚本一行不动。三个测试用例用同一个页面，不用复制粘贴定位代码。

PO到底怎么分层

我的习惯是分两层。一层是BasePage，放公共方法——等待元素、点击、输入、截图。所有页面类继承它。另一层是具体页面类，比如LoginPage、OrderPage，每个类里只放这个页面的元素和方法。

BasePage长这样：

class BasePage: def __init__(self, driver): self.driver = driver def find(self, locator): return self.driver.find_element(*locator) def click(self, locator): self.find(locator).click()

LoginPage继承它：

class LoginPage(BasePage): username = (By.ID, "username") password = (By.ID, "password") login_btn = (By.CLASS_NAME, "login-btn") def login(self, user, pwd): self.find(self.username).send_keys(user) self.find(self.password).send_keys(pwd) self.click(self.login_btn)

测试用例里就变成LoginPage(driver).login("admin", "123456")。干净。

别过度设计

有人把PO搞成三层四层，BasePage、CommonPage、BusinessPage、TestPage，最后自己都绕晕。我的判断标准很简单：页面元素超过五个、或者同一个页面被三个以上用例引用，就抽PO。否则直接写，别为了模式而模式。

还有个坑。PO里不要写断言。断言是测试用例的事，页面对象只负责“操作”和“取数据”。比如登录后要验证是否成功，PO提供get_error_message()方法返回文本，用例里再assert。混在一起，页面类就脏了。

实际项目里的样子

我之前做一个电商后台，订单列表页有筛选、翻页、批量操作。如果不用PO，每个用例都要写一遍筛选逻辑。用了PO之后，OrderListPage里封装filter_by_status()、go_to_page()、select_first_order()。新增用例直接组合这些方法，写起来像搭积木。

维护成本也降了。有次前端把“搜索”按钮的class从search-btn改成btn-search，只改了OrderListPage里一行定位，二十多个用例全跑通。没用PO的话，得改二十多处。

PO不是银弹。页面结构频繁大改、或者项目周期极短，硬套PO反而拖慢进度。但只要是长期维护的Web自动化项目，PO基本是标配。它解决的是“改一处、崩一片”的问题，这个痛点太真实了。

说到底，PO就是一种职责分离。页面的事归页面，测试的事归测试。写多了会发现，代码可读性上来了，新人接手也快——看页面类就知道这个页面能干什么，不用翻几百行测试脚本找定位。