关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集去年这个时候我帮一个团队做了一次技术评审。他们的自动化用例有八百多条但每次跑完开发团队基本不看报告——太长了全是英文堆砌失败原因写着“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) assertWelcomein 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 条的时候框架还能不能撑住页面对象有没有规范元素定位有没有统一策略测试数据有没有外置报告有没有人看失败用例有没有人跟进这些问题比“会不会写脚本”重要得多。很多团队的自动化停在“能跑”的阶段就因为只关注了“怎么写”没关注“怎么长”。你的框架现在卡在哪一层是还没开始搭是搭了一半发现维护不动还是跑起来了但没人看报告欢迎在评论区聊聊你踩过的坑。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。