前言
在之前的文章中，我们介绍过APP自动化测试的相关文章：
本篇文章的主体，通过提取文章标题关键词可知：：
- Web自动化：在浏览器上运行的Web自动化测试
- Selenium4：使用Selenium4工具
- PageObject模式：使用面向页面对象模式进行设计
一、什么是PO模式？
1.PO模式简介
Page Object 模式是一种在Web或APP的GUI自动化测试中广泛使用的设计模式，它将页面的元素和操作封装在一个对象中，将测试代码与页面细节分离，提高测试代码的可维护性、可读性和可重用性。
核心概念
- 页面封装：将每个网页页面封装为一个对象，该对象包含页面上的元素和对这些元素的操作。例如，一个登录页面可以封装为一个 LoginPage 对象，其中包含用户名输入框、密码输入框、登录按钮等元素，以及输入用户名、输入密码、点击登录按钮等操作。
- 元素定位和操作分离：将元素的定位和操作分离，元素的定位信息（如 XPath、CSS 选择器）存储在页面对象中，而测试用例只调用页面对象的操作方法，不关心元素的定位细节。
优点
可维护性：如果页面的元素发生变化（例如元素的 ID、XPath 改变），只需要在页面对象中修改元素的定位信息，而无需修改测试用例。
可读性：测试用例更加简洁，只需要调用页面对象的操作方法，使测试逻辑更加清晰，易于理解。 可重用性：可以在不同的测试用例中重用页面对象，减少代码冗余。
2.PO模式几大原则
- 公共方法表示页面提供的服务
- 尽量不要暴露页面的内部实现
- 页面中不要加断言，断言加载
- 方法返回另外的页面对象
- 不需要封装全部的页面元素
- 相同的行为、不同的结果，需要封装成不同的方法
3.PO分层模型设计
业内常见的有3层模型和4层模型。两者的主要区别在于：
- 4层模型把元素层和page页面层进行了隔离，元素层只存储元素，在page页面层封装一个个的元素对象，各个元素对象引用元素层中的对应元素，这样做的好处是如果页面发生改动，只需要修改元素层即可；
- 3层模型把元素层和页面层绑定在一起，这样减少了层级调用；
按照上述思路，你甚至可以分成5层也没人管你，比如在页面层的基础上再加上个“操作层”，例如：页面层只封装 元素对象，操作层里封装各个页面对象的操作：click、scroll、send_keys等。当然也有把对页面对象的操作放在测试用例中进行调用的，这个就因人而异了。不过尽量还是别搞得太复杂，层级越多、调用链路越长，可维护性和运行效率就越差。
二、项目分析与设计
1.业务分析
见过太多的文章、课程、书籍，不管是功能测试，还是自动化测试设计，都喜欢使用“登录”这个经典案例来进行举例，真的是要审美疲劳了......因为在真实的业务场景中，遇到的问题远比登录要复杂得多。
这里我们选用一个真实的业务场景：物流系统的发布货单流程来进行示例。
这个业务流程就3个页面，大致操作步骤如下：
- 登录界面：打开登录界面->输入账号密码、密码->点击登录按钮进行登录
- 主页：进入货单管理->点击货单发布按钮
- 发布货单页面：填写各个字段信息->点击保存按钮
2.项目结构设计
这里我们选用的是工具是Selenium。其实不管是用Selenium还是最近比较火的Playwright，亦或是其他自动化测试工具（注意：这里仅把他们叫作工具，而不是框架，后续会有专门一篇文章进行介绍为什么这样划分），设计思路和实现方法都是相同的，并没有什么本质上的区别。
- common包：用于存放一些公共方法模块，例如二次封装元素定位的基类、异常处理模块等；
- pages包：存放各个页面元素对象，不同的页面封装到不同的模块中；
- config包：存放项目的配置文件，例如页面地址、登录账号密码等；
- test_case包：测试用例文件；
- lib包：存放一些第三方库，可以直接引用lib中的第三方库，这样即使把整个工程复制到其他电脑使用，也不用再次安装依赖，极大减少环境问题；
- report、log目录：注意是目录，不是包，用于存放报告、日志文件；
三、基于PO模式设计的Web自动化测试实战
这里我们选用3层模型，将元素层和页面层绑定在一起。整个项目结构如下：
1.二次封装元素定位方法
在common下新建“base_page.py”模块，对Selenium webdriver中元素定位方法进行二次封装。在元素操作方法中，使用 WebDriverWait 和 expected_conditions 确保元素可见或可点击，避免元素未加载完成就进行操作，提高测试的稳定性。
注意：Selenium4中使用的元素定位方法为“self.driver.find_element(By.ID, " ")”，类似“
self.driver.find_element_by_id(" ")”已被弃用。
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.action_chains import ActionChains
DEFAULT_TIME_OUT = 10
class BaseLocator(object):
def __init__(self, driver):
self.driver = driver
def by_css_selector(self, css_selector):
"""CSS选择器"""
locator = (By.CSS_SELECTOR, css_selector)
WebDriverWait(self.driver, DEFAULT_TIME_OUT).until(EC.visibility_of_element_located(locator))
return self.driver.find_element(*locator)
def by_id(self, id):
locator = (By.ID, id)
WebDriverWait(self.driver, DEFAULT_TIME_OUT).until(EC.visibility_of_element_located(locator))
return self.driver.find_element(*locator)
def by_class_name(self, class_name):
locator = (By.CLASS_NAME, class_name)
WebDriverWait(self.driver, DEFAULT_TIME_OUT).until(EC.visibility_of_element_located(locator))
return self.driver.find_element(*locator)
def by_xpath(self, xpath):
locator = (By.XPATH, xpath)
WebDriverWait(self.driver, DEFAULT_TIME_OUT).until(EC.visibility_of_element_located(locator))
return self.driver.find_element(*locator)
def by_link_text(self, link_text):
locator = (By.LINK_TEXT, link_text)
WebDriverWait(self.driver, DEFAULT_TIME_OUT).until(EC.visibility_of_element_located(locator))
return self.driver.find_element(*locator)2.封装页面元素对象
不同的页面创建多个模块，以上面业务分析来看，我这个业务流程就3个页面：login_page.py（登录）、home_page.py（主页）、publish.py（发布货单）。
注意：
- 模块及类的命名，尽量和实际的页面进行对应，让人一眼就能看出来这是个什么页面；
- 各个模块中只封装这个页面的元素对象，便于后期查找；
- 用到多少，封装多少，不要全部封装；
- 方法的命名也尽量贴合实际，例如：input_password，一下就知道是输入密码
- 因为是3层模型，所以我们直接在页面对象各个方法中将元素与元素的操作放在一起（当然放在测试用例中进行调用click()、send_keys()一类的操作函数也可以）；
① 登录页面
from common.base_page import BaseLocator
class LoginPage(BaseLocator):
"""登录页面"""
def input_username(self, username):
"""用户名输入框"""
return self.by_css_selector("[placeholder='请输入账户/手机号']").send_keys(username)
def input_password(self, password):
"""密码输入框"""
return self.by_css_selector("[placeholder='请输入你的密码']").send_keys(password)
def click_login_btn(self):
"""登录按钮"""
return self.by_id("loginButton").click()② 主页
from common.base_page import BasePage
class HomePage(BaseLocator):
"""登录页面"""
def click_menu(self):
"""点击货单管理"""
return self.by_xpath("//span[text()='货单管理']").click()
def click_order_publish(self):
"""点击货单发布入口"""
return self.by_link_text("货单发布").click()③ 货单发布页面
from common.base_page import BasePage
class PublishOrderPage(BaseLocator):
"""货单发布页面"""
def click_shipper(self):
"""点击托运方下拉框"""
return self.by_css_selector(css_selector="[placeholder='请选择发货客户']").click()
def select_shipper(self):
"""选择货主"""
return self.by_css_selector(css_selector="tbody tr:first-child").click()
def input_trans_price(self, price=35):
"""输入运输单价"""
return self.by_css_selector(css_selector="[placeholder='请输入运输价格']").send_keys(price)
def click_price_unit(self):
"""点击单位下拉框"""
return self.by_css_selector_es(css_selector="[placeholder='请选择']")[0].click()
def select_price_unit(self):
"""选择单位"""
return self.by_xpath(xpath="//span[contains(text(), '元/吨/公里')]").click()
def click_submit_btn(self):
"""点击提交按钮"""
return self.by_xpath(xpath="//button/span[text()='提交']").click()3.定义测试用例模块
测试用例就比较简单了，就是导入各个页面对象类并进行初始化，在测试用例方法中调用各个页面元素对象，模拟实际业务场景中的人工操作步骤，按顺序进行组装。
注意：
- 模块的命名：也要尽量贴合实际，比如：test_publish_order就是测试发布货单流程，test_add_goods就是测试添加商品，不同的模块承载着不同的功能；
- 像页面url地址、登录账号密码这类的，最好把它存放于一个公共配置文件中；
- 既然是测试用例，就要添加断言，我后面图省事、先省略了断言；
- 断言一定要在测试用例中添加，页面中不要加载断言；
# coding: utf-8
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
class TestPublishOrder(object):
def setup_method(self):
self.service = Service(executable_path="../lib/chromedriver")
self.driver = webdriver.Chrome(service=self.service)
self.login_page = LoginPage(self.driver)
self.home_page = LoginPage(self.driver)
self.publish_page = PublishOrderPage(self.driver)
self.driver.get("http://xxx.xxx.com")
self.driver.maximize_window()
# 使用 JavaScript 调整缩放比例
self.driver.execute_script("document.body.style.zoom='90%'") # 设置缩放比例
def test_publish_order(self):
self.login_page.input_username("15252188888") # 输入用户名
self.login_page.input_password("123456") # 输入密码
self.login_page.click_login_btn() # 点击登录按钮
self.home_page.click_menu() # 点击菜单栏
self.home_page.click_order_publish() # 点击货单发布
self.publish_page.click_shipper() # 点击货主下拉框
self.publish_page.select_shipper() # 选择货主
self.publish_page.input_goods_number() # 输入货单号
self.publish_page.click_null_area() # 点击空白区域(为了让悬浮框消失)
self.publish_page.click_goods_frame() # 点击发货产品下拉框
self.publish_page.select_goods() # 选择发货产品
self.publish_page.input_trans_price() # 输入运输单价
self.driver.execute_script("window.scrollBy(0, 300);") # 屏幕向上滚动300个像素
self.publish_page.click_price_unit() # 点击运输价格的单位下拉框
self.publish_page.select_price_unit() # 选择运输单价的单位
self.publish_page.input_trans_number() # 输入运输数量
self.publish_page.click_is_invoicing() # 点击是否开票
self.publish_page.select_is_invoicing() # 选择是否开票(默认选择"开票")
self.publish_page.click_payment_method() # 点击结算方式
self.publish_page.select_payment_method() # 选择结算方式(默认选择"装货吨数")
self.publish_page.input_remark() # 选择结算方式(默认选择"装货吨数")
self.driver.execute_script("window.scrollBy(0, 300);") # 屏幕向上滚动300个像素
self.publish_page.click_line_name() # 点击线路名称
self.publish_page.select_trans_line() # 选择线路名称
self.driver.execute_script("window.scrollBy(0, 800);")
self.publish_page.click_save_btn() # 点击保存按钮
# 后面加上断言的代码4.执行测试
注意：Selenium4中对于chromedriver路径的声明引用进行了改版，之前在Selenium3中，指定chromedriver路径的方式是“webdriver.Chrome(executable_path=os.path.join(path, BrowserType.chrome.value))”，而在Selenium4中，则需要通过如下形式实现。
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
service = Service(executable_path="../lib/chromedriver")
driver = webdriver.Chrome(service=self.service)
整个执行用时18.88s，效率还算能接受。由于涉及内部隐私，执行过程的视频就不放上来了，只贴出执行结果截图：
四、总结
1.PO模式的优点
通过上述整个PO模式的设计与实现过程可以看出：
- 运行稳定：对元素定位方法进行二次封装，使用 WebDriverWait 和 expected_conditions 确保元素的状态，避免元素未加载完成就进行操作，不需要使用time.sleep()这种强制等待的形式，提升了运行效率和稳定性。
- 可维护性高：将元素的定位和操作分离，元素的定位信息（如 XPath、CSS 选择器）存储在页面对象中，而测试用例只调用页面对象的操作方法，不关心元素的定位细节。这样，就算是页面的元素发生变化（例如元素的 ID、XPath 改变），只需要在页面对象中修改元素的定位信息，而无需修改测试用例。
- 可读性高：使用了PO模式的代码非常简洁，测试用例也更加简洁，只需要调用页面对象的操作方法，使测试逻辑更加清晰，易于理解。
- 可重用性：可以在不同的测试用例中重用页面对象，减少代码冗余。
2.GUI自动化测试的缺点
- 页面元素变动：页面可能会频繁变动，一旦变动，我们就要修改页面元素；
- 运行效率低：相较于API测试，GUI测试运行时间要长很多；
- 运行可靠性：同样的脚本，不同浏览器、操作系统、屏幕分辨率都会影响到测试结果
- 业务逻辑局限性：对于一些复杂的业务逻辑，无法通过GUI来实现。
3.GUI自动化测试的注意事项
- 考虑投入产出比：不要为了自动化而自动化，投入产出比高的业务才适合做自动化，尤其是上述那种主业务流程，最适合用来做GUI自动化。
- GUI自动化测试就是用来保障核心场景的，千万别用来做那些边角料场景和异常场景，更别对一个登录功能设计十几种情况、然后用GUI自动化来实现，这种简直就是在遭罪。
- 对于测试数据，能自动模拟生成的尽量自动化模拟，无法模拟的固定数据，包括配置文件，直接存放在py文件中即可。千万别搞个ini配置文件存放配置，或是Excel表格存放页面元素，这样不仅需要开发读取这类文件的方法，还不利于维护，更导致运行和调试变得复杂。
4.GUI自动化测试的价值
很多人觉得GUI自动化测试没什么价值，但存在就是合理的。就拿上面的发单流程来说吧，如果调用通了一连串的接口，实现了接口层面的发布订单，但你敢保证页面操作就是通的吗？
GUI自动化确实只适用于回归测试，不适合主动发现bug。但如果将其与CICD进行结合，开发每提交一次代码，就自动触发执行各个核心业务场景，可以很大概率避免低级问题的出现。
我遇到过多次后台代码刚发布测试环境就导致系统崩溃、前端页面都无法登录的情况，如果流水线上有GUI自动化的加持，那是不是就可以保证起码页面是能正常登录的、起码发布订单的主业务流程是通的，其他小问题就算存在，也不是致命的不是？