去年这个时候，我帮一个团队做了一次技术评审。他们的自动化用例有八百多条，但每次跑完，开发团队基本不看报告——太长了，全是英文堆砌，失败原因写着“Element not found”，没人知道是定位器变了还是页面没加载完。
上个月再见到他们，自动化用例已经砍到两百条，但通过率从72%涨到了94%。问他们怎么做到的，负责人说了一句话：“我们把重心从'写用例'挪到了'搭框架'。”
这件事让我想明白了一个道理：Web UI 自动化测试的问题，从来不是会不会写脚本。问题是你有没有一个能让你安心写脚本的框架。
目录
一、从零开始，到底需要什么
二、选 Selenium 还是 Playwright，本质是选一种工程方式
三、框架的核心机制，拆开看就三件事
四、一个真实的对比：有框架 vs 没框架
五、报告不只是给测试看的
六、你的框架，现在卡在哪一层？
一、从零开始，到底需要什么
很多人觉得 Web UI 自动化就是“打开浏览器、点按钮、填表单、关浏览器”。这话没错，但只对了一半。
真正从零开始搭一套能用的自动化框架，你需要回答的问题远不止这些：
测试代码放哪？页面元素怎么管理？不同浏览器怎么切换？测试数据写死在脚本里还是外置？跑完的测试结果谁来存？报告长什么样？失败了怎么定位？
这些问题不解决，写再多用例也是给自己挖坑。
自动化测试就像一个不知疲倦的测试助手，能自动执行预设用例、精准捕获异常、生成测试报告。但前提是——你得先把它的“工作环境”搭好。
二、选 Selenium 还是 Playwright，本质是选一种工程方式
这是每个从零开始的人都会遇到的第一个选择。
Selenium 是老牌选手，支持几乎所有编程语言，生态成熟。但它的代价是：你得单独下载浏览器驱动，版本还得跟浏览器严格匹配。每次 Chrome 自动更新，你的 CI 就可能挂掉一批用例。
Playwright 是微软开源的新一代框架，原生支持 Chromium、Firefox 和 WebKit 三大浏览器引擎。它的核心差异在于：采用进程外通信模型，通过 WebSocket 协议与浏览器驱动交互，而不是 Selenium 那种 HTTP 协议。这意味着更低的延迟和更稳定的连接。
Playwright 的“开箱即用”体验非常明显。你不需要单独装驱动，框架自己管理浏览器版本。内置的智能等待机制能自动检测元素的可交互状态——比如是否可见、是否可点击、是否被遮挡。你不再需要写一堆 time.sleep() 和 WebDriverWait。
选哪个？我的判断是：新项目直接用 Playwright，维护中的老项目继续用 Selenium。 这不是技术优劣的问题，是工程成本的问题。
三、框架的核心机制，拆开看就三件事
不管用哪个工具，一个可维护的 Web UI 自动化框架，核心就是三件事。
第一，页面对象模型（Page Object Model）
这是 UI 自动化里最经典的设计模式。每个页面封装成一个类，类里包含这个页面的元素定位和操作方法。测试用例只调用这些封装好的方法，不直接写定位器。
好处是什么？页面改了，你只改一个文件。而不是去几十个用例里找定位器。
第二，分层架构
测试代码、页面操作、配置数据，三层分开。
测试层放用例逻辑，页面层封装元素操作，配置层管环境地址、账号密码、浏览器选项这些可变的东西。三层之间通过接口调用，不互相依赖实现细节。
第三，等待策略
这是新手最容易踩的坑。元素还没加载完就开始操作，用例就挂了。
Playwright 的做法是：每个操作（click、fill）都内置智能等待，自动等到元素可操作为止。你不用手动加等待，框架替你处理。
这三件事做扎实了，框架就有了骨架。剩下的就是往里填用例。
四、一个真实的对比：有框架 vs 没框架
同一个登录功能的测试，两种写法。
没框架的写法（新手常见） ：
from selenium import webdriver
import time
driver = webdriver.Chrome()
driver.get("https://example.com/login")
time.sleep(3)
driver.find_element_by_id("username").send_keys("testuser")
time.sleep(1)
driver.find_element_by_id("password").send_keys("123456")
time.sleep(1)
driver.find_element_by_id("login-btn").click()
time.sleep(2)
assert"Welcome"in driver.page_source
driver.quit()
这段代码能跑，但问题一堆：到处是 time.sleep，定位器散落在脚本里，换个页面就要重写。
有框架的写法（Page Object） ：
login_page.py
class LoginPage:
def init(self, page):
self.page = page
self.username = page.get_by_label("用户名")
self.password = page.get_by_label("密码")
self.login_btn = page.locator("text=登录")
def login(self, user, pwd):
self.username.fill(user)
self.password.fill(pwd)
self.login_btn.click()
test_login.py
def test_login_success(login_page):
login_page.login("testuser", "123456")
expect(login_page.page).to_have_url("/dashboard")
区别在哪儿？前者把逻辑和细节混在一起，后者把细节封装起来。页面改了，你只需要改 login_page.py，测试用例一行不动。
这就是框架的价值——不是为了写得快，是为了改得快。
五、报告不只是给测试看的
很多团队的测试报告长这样：一个巨大的 HTML 文件，满屏英文，失败信息写着“AssertionError”。
这种报告，开发不看，产品不看，只有测试自己硬着头皮翻。
一份能用的报告，至少要做到三件事。
中文。 不是崇洋媚外，是降低阅读门槛。Allure 支持定制报告语言为中文。团队成员不需要懂英文也能看懂测试结果。
截图。 失败用例自动截图，附在报告里。开发拿到报告第一眼就知道页面长什么样，不用再去复现。
步骤清晰。 报告里能看到每一步执行了什么操作、传了什么参数、在哪个环节失败的。定位问题的时间从小时级降到分钟级。
Allure 是目前最成熟的方案。它支持绝大多数测试框架，能生成美观的可视化报告。配置不复杂，半小时能搞定。
报告做好，自动化测试的价值才能被团队看见。
六、你的框架，现在卡在哪一层？
从零到一搭一套 Web UI 自动化框架，技术门槛其实不高。Python 加 Playwright，半小时就能跑通第一个用例。
真正的门槛在后面——当你的用例从 10 条涨到 100 条的时候，框架还能不能撑住？
页面对象有没有规范？元素定位有没有统一策略？测试数据有没有外置？报告有没有人看？失败用例有没有人跟进？
这些问题，比“会不会写脚本”重要得多。
很多团队的自动化停在“能跑”的阶段，就因为只关注了“怎么写”，没关注“怎么长”。
你的框架，现在卡在哪一层？
是还没开始搭？是搭了一半发现维护不动？还是跑起来了但没人看报告？
欢迎在评论区聊聊你踩过的坑。
