在测试圈里经常有人问我一个问题Java技术栈做自动化测试到底该选Selenium还是Playwright我的回答通常是如果你们项目是Java写的又刚准备把UI自动化补起来Playwright的Java版本值得认真考虑。这个系列文章我打算从最不起眼、但实际最容易翻车的表单控件开始写第一篇就先说单选按钮和多选按钮。这两个控件在页面上看着就是一个小圆点、一个小方框好像没什么技术含量。但真的上手写自动化用例你会发现一堆问题元素明明能定位到点击就是不生效用Selenium点过去了断言又对不上页面里有隐藏的input直接用click()还会报元素不可交互。我这次用JavaPlaywright把radio和checkbox从头到尾过一遍包含环境搭建、定位方式、勾选逻辑、断言技巧和踩坑记录希望能帮你少走弯路。1. 为什么单选和多选按钮值得单独拿出来讲1.1 表单里的radio和checkbox看着简单翻车点多先讲个实际的场景。很多初学自动化的人都会拿注册页面练手性别选择、兴趣爱好、用户协议这些几乎全是radio和checkbox。一上手就发现这俩控件在HTML里长这样一个input标签type是radio或者checkbox外面再套个label。真正的视觉样式很多是CSS画出来的有些甚至把input藏起来只留一个背景图标。这种设计给自动化测试带来的麻烦是双重的。第一定位困难你看到的那个可点击区域往往不是input本身而是label或者某个span。第二交互语义特殊radio靠name属性分组同一组里只能选一个选多了自动互斥checkbox则是独立的开和关可以批量勾选也可以取消。如果你只是机械地写driver.findElement(By.id(xxx)).click()大概率会碰到两类问题要么点击事件没有触发到input节点上要么因为元素被其他节点遮挡Selenium直接抛ElementClickInterceptedException。Playwright这边处理得就聪明很多它引入了“可操作性检查”点击之前会确认元素可见、稳定、可交互、可编辑不满足就自动等待重试。这也是我推荐用它代替Selenium做表单类控件操作的最直接原因。1.2 Playwright的交互模型和Selenium差在哪里Selenium的WebDriver模型走的是“命令下发”路线你让浏览器做什么它就发一条HTTP指令过去浏览器照做。问题在于浏览器里元素的状态是动态变动的你以为点到了实际上那个时刻元素还在transition里位置还没稳定或者按钮正处于disabled状态。所以Selenium时代大家都养成了一个习惯写sleep先睡一秒再说。Playwright走的是另一条路它内置了自动等待机制。调用click()、check()这类动作时Playwright会先检查元素是否已经满足可操作条件不满足就一直等直到超时。这个机制不是靠穷举轮询硬试的而是基于浏览器底层事件和DOM状态变化来驱动的所以写出来的脚本非常干净几乎没有显式sleep。对于表单控件来说这个优势尤其明显因为你不需要在点击radio之前反复确认它是不是真的加载好了。生活里做个类比的话Selenium像是在打固定电话拨号之后不知道对方在不在只能干等Playwright则像微信通话接通后对方在线不在线、正在输入还是已经离开状态都是双向同步的。理解了这一层后面再用它的API很多迷惑行为就都能解释了。2. 把环境跑起来JavaPlaywright最小工程2.1 Maven依赖引入与浏览器内核下载想要在Java项目里用Playwright第一步是在pom.xml里加入依赖。我用的是1.47.0版本自己项目里锁定这个版本升级之前会先在测试环境验证。dependency groupIdio.playwright/groupId artifactIdplaywright/artifactId version1.47.0/version /dependency依赖加好之后Playwright并不会自动帮你下载浏览器内核。它需要单独执行一个安装命令把Chromium或者Firefox的二进制下载到本地缓存目录。Maven工程中可以直接用exec插件触发mvn exec:java -e -D exec.mainClasscom.microsoft.playwright.CLI -D exec.argsinstall如果想装完顺手把系统依赖也补上可以用install --with-deps。这个命令在Linux CI环境里特别常用Windows和macOS本地跑一般不需要。这里有个常见问题值得提前说如果你在公司内网或者下载受限的网络环境里执行install失败不要急着放弃。Playwright支持通过环境变量PLAYWRIGHT_DOWNLOAD_HOST指定下载源可以指向内部镜像或者本地的离线包目录。我司目前就是先把浏览器包放到内网对象存储再在CI脚本里设置这个环境变量下载速度和稳定性都有明显改善。如果不想用这种方式也可以手动下载对应版本的浏览器包放到用户目录的~/.cache/ms-playwright下再执行检查命令即可。2.2 一个能直接跑通的浏览器启动模板环境装好之后建议先写一个最小模板验证整个链路能跑通。Java版的Playwright核心接口有三个层级分别是Playwright入口、Browser浏览器实例和BrowserContext上下文页面Page则挂在上下文下面。import com.microsoft.playwright.*; public class DemoStart { public static void main(String[] args) { try (Playwright playwright Playwright.create()) { Browser browser playwright.chromium().launch( new BrowserType.LaunchOptions().setHeadless(false) ); BrowserContext context browser.newContext(); Page page context.newPage(); page.navigate(https://example.com); System.out.println(页面标题: page.title()); context.close(); browser.close(); } } }一个小知识点setHeadless(false)会让你本地调试时看到真实的浏览器窗口方便观察元素状态。而在CI里跑的时候建议改成默认的无头模式省资源也更快。BrowserContext这一步很多人会忽略它的隔离能力其实非常实用每个context相当于一个独立的浏览器会话cookie、localStorage、缓存都是隔离的你可以在多个context里并行跑不同测试数据互不干扰。2.3 代码跑起来了怎么确认它真的在用Playwright很多第一次接触Playwright的人会有个疑问我就是起了个浏览器打开了页面跟用Selenium好像没啥区别嘛。其实区别从这一行代码开始显现看下面这个例子page.locator(input[namegender][valuemale]).check();这一行代码放到Selenium里你可能需要先findElement再确保它是可见的再click再手动isSelected()断言。Playwright的check()把这一切合并成了一个意图明确的操作。它自己内部完成了可见性判断、滚动到视口、等待可交互、点击或设置checked属性这一整套流程。这就是我后文展开的核心理解了这套交互模型才算真正开始用Playwright。3. 单选按钮从“能点”到“点得对”3.1 页面里单选按钮的三种形态做测试久了会发现同一个页面上不同开发写的radio实现方式能差出三个时代。老的网站喜欢用原生input直接加name和value属性。稍微现代一点的页面用label包住inputlabel的for属性关联到input的id这样用户点文字也能选中。input typeradio namegender idmale valuemale label formale男/label进入框架时代后很多组件库开始做自定义渲染真正的input可能是隐藏的视觉上是一个div模拟的小圆点加一个span文字。面对这种页面靠样式定位很容易翻车因为点击div并不会自动更新表单状态必须触发底层的input事件才行。Playwright的解决办法比较优雅不要只盯着视觉元素而是通过行为定位。radio的语义角色就是radio不管外层怎么包装只要底层的input具备radio类型且可以被语义识别就能用getByRole来定位。我们做自动化时也建议优先用语义和结构定位而不是类名样式这是长期维护最省心的方式。3.2 用Locator精确定位并完成勾选针对单选按钮最稳妥的一组定位方式是这样的。如果有明确的id用id定位最直白如果有多组radio用name加value组合定位精准命中某一个选项。Locator maleRadio page.locator(input[namegender][valuemale]); maleRadio.check(); Locator femaleRadio page.getByLabel(女); femaleRadio.check();这里我提一下为什么推荐check()而不是click()。对于radio来说click()会产生完整的鼠标事件序列mousedown、mouseup、click这确实能选中元素。但check()语义更聚焦它明确表达“我要让这个radio处于选中状态”而且如果元素已经选中了check()会直接跳过不再重复点击。这个幂等特性在写循环和参数化用例时特别有用。如果页面里radio的id不固定但文字固定用getByLabel也是一种常见方案它会把label的关联关系解析出来定位到真正的input上。实际项目里我经常混用优先namevalue次选getByText相关的方案。3.3 勾选后的状态断言和反选处理单选按钮的核心业务逻辑是同一组内互斥。你从男的切到女的男的就会自动变成未选中。自动化用例里验证的就是这件事。PlaywrightAssertions.assertThat(page.locator(input[namegender][valuemale])).isChecked(); PlaywrightAssertions.assertThat(page.locator(input[namegender][valuefemale])).not().isChecked();这里有个值得说的细节Playwright的断言默认是会自动重试的不像JUnit那种硬比较。如果页面里radio的选中态是异步更新的比如点击后发起请求服务端返回才更新状态普通的assertEquals会立刻读完立刻失败而assertThat().isChecked()会等到状态稳定再判断默认等待时间可以配置。极端情况下如果你想明确验证radio没有被选中用not().isChecked()也很直观。涉及反选操作时要注意radio一旦选中就不能靠同一个元素再次点击取消这是浏览器原生行为决定的。自动化脚本不需要强行去复现这种物理不可能的操作而是应该去验证“同组内选中另一个原来的自动取消”这个粒度才是业务能接受的。4. 多选按钮勾选、取消、全选与批量断言4.1 check()和uncheck()成对使用别搞混checkbox和radio最大的区别就是“可逆”。一个checkbox可以反复勾选和取消所以Playwright为它专门提供了check()和uncheck()两个方法。用法不复杂Locator agree page.locator(input[nameagreement]); agree.check(); // 业务做了某些操作后 agree.uncheck();这里要提醒一个容易踩的坑uncheck()这个方法在radio上是不存在的或者说即使调用了也不会产生业务上的取消效果。有些同事刚上手时会把checkbox的操作封装通用函数radio和checkbox混在一起传参结果调试了半天才发现方法选择错误。建议在封装公共方法时先判断input的type再决定走check还是uncheck分支。另外checkbox在业务上经常有一种“半选”状态就是echarts这类组件树里的indeterminate状态。这种状态本质上是视觉半选DOM层面它的checked属性还是false。Playwright的isChecked()判断的就是原生checked属性遇到半选状态时不能直接拿它做结论。我目前的处理方式是如果业务需要验证半选就额外检查对应的类名或者aria-selected属性这个属于定制化断言框架给不了通用解。4.2 全选和部分勾选批量操作的落地写法自动化里最常见的checkbox需求是两个一个是全选一个是按组勾选。全选的写法很直白Locator checkboxes page.locator(input[typecheckbox]); ListLocator allBoxes checkboxes.all(); for (Locator box : allBoxes) { box.check(); }这里的all()方法会返回当前页面匹配到的全部元素然后逐个执行check。前面提到的幂等性在这里会发挥重要作用即使某些checkbox已经处于选中状态再调check()也不会报错或者产生额外的点击事件。这个特性比Selenium里那种无脑循环click()安全很多不容易因为重复点击导致页面状态错乱。部分勾选的场景也不复杂。我们有个消息通知设置页里面有十几类通知渠道测试时要勾选其中特定的几类。我的写法是先拿到所有checkbox的名称和值建立映射关系然后按测试数据来勾选。如果测试数据来自外部Excel或者JSON参数化的价值就会体现出来用例本身可以做到零改动换数据就能跑新场景。4.3 断言多选状态时的常见姿势多选断言比单选稍微麻烦一点因为需要验证的往往不止一个元素而是一批元素的组合状态。比如一个表单里既要求性别选择了、又要求用户协议勾了、还要至少选了两个兴趣爱好。我习惯的做法是组合断言PlaywrightAssertions.assertThat(page.locator(input[namegender][valuefemale])).isChecked(); PlaywrightAssertions.assertThat(page.locator(input[nameagreement])).isChecked();如果断言数量比较多可以再配合一个统计逻辑统计当前页面被勾选的checkbox数量然后和预期值比较。这个场景用手写循环加计数器就行不需要额外引入断言库读起来反而更清晰。还有一点是断言时机。checkbox的勾选状态会影响到按钮的可用性比如用户不勾选协议提交按钮永远是disabled。这种联动场景在测试用例里非常常见。我的建议是验证时不要只依赖某一个快照而是通过多次动作迭加验证比如先不勾选断言提交按钮不可用再勾选断言按钮可用。这样整个用例的语义是完整的也更接近真实用户的操作路径。5. 实操实录这些坑我基本都踩过5.1 点了按钮断言还是失败这是一个被问得最多的问题脚本执行时明明看到那个圆点已经被选中了但断言还是失败。排查下来的原因通常有三类。第一类页面里有重复的checkbox或radio定位器匹配到了隐藏的那个点击的是视觉元素但更新的是另一个DOM节点。第二类点击后状态是异步变化的需要一点时间让前端框架把checked属性同步过来。第三类元素被label包裹Playwright的check生效了但断言用错了节点。解决办法其实就一句话让定位器精确到不能再精确。排查时我一般先在Playwright的调试模式里跑一遍把实际匹配到的元素数量打出来再配合nth()或者filter()过滤到唯一。异步更新这个问题最好借助断言本身的重试机制去解决而不是手动加sleep前者在页面响应变慢时依然能稳定通过后者只会让用例跑得更慢。5.2 hidden input点不到是改页面还是该换定位法遇到开发把input隐藏起来、只展示一个自绘圆点的情况很多人第一时间想到用setChecked(true, new Locator.SetCheckedOptions().setForce(true))强行设置状态。这个API确实管用但我不建议把它当默认解法。forcetrue会绕过可操作性检查直接把checked属性写进去。这样做的副作用是它没有走真实的用户操作路径一些依赖于click事件来联动其他逻辑的页面比如点击后需要弹提示或者记录埋点就不会触发。用force相当于跳过了系统校验你要确保自己真的理解页面逻辑否则容易做出“测试通过但功能实际已经坏掉”的虚假结论。我一般先用getByLabel看看能不能通过关联label定位这样点击是真实发到input上的。如果页面结构实在没有label关联再考虑用page.evalOnSelector直接执行原生click或者dispatchEvent这样也能模拟出完整事件链。5.3 iframe里的radio和checkboxframeLocator解君愁现在很多后台管理系统都流行iframe嵌入。如果在iframe里操作radio和checkboxPlaywright也有专门方案。直接在page对象上定位是不行的你永远定位不到iframe内部的元素必须先切进frame。Locator agreeInFrame page.frameLocator(#agreementFrame).locator(input[typecheckbox]); agreeInFrame.check();注意frameLocator返回的对象在Java API里也是一种Locator类型后续的check、断言、等待行为都和普通Locator完全一致不需要额外处理跨frame状态。这让iframes操作成本变得很低。相比之下Selenium里要来回切换driver的焦点Java代码里动不动就要写switchTo().frame()维护起来又乱又容易漏掉切回逻辑。这也是我目前在新项目里坚持用Playwright的一个重要原因。5.4 Playwright安装阶段的问题汇总虽然安装问题不是写用例阶段的事但它卡住了很多人入门的第一步这里把高频问题一起列出来。如果你执行mvn exec:java -e -D exec.mainClasscom.microsoft.playwright.CLI -D exec.argsinstall失败先别慌。第一个常见问题是下载超时。Playwright默认从官方的CDN拉取浏览器包在公司网络环境下很容易失败。解决办法就是刚才提到的设置PLAYWRIGHT_DOWNLOAD_HOST环境变量指向内部镜像。第二个常见问题是权限不足Linux服务器上安装时需要写缓存目录如果用的是Jenkins这类CI账号经常因为目录权限装到一半退出。可以手动给用户目录授权或者设置PLAYWRIGHT_BROWSERS_PATH到项目团队有写权限的目标路径。第三个问题是版本不匹配。有时候pom里依赖的Playwright版本和你本地缓存的浏览器内核版本不一致启动时会直接报连接错误。处理方式也很简单清掉~/.cache/ms-playwright下对应的旧目录重新install即可。这里我补一句个人经验建议把Playwright依赖版本和浏览器安装版本一起锁成一个固定组合在pom里声明清楚团队协作时能减少很多莫名其妙的报错。6. 工程化建议把控件操作封装成Page Object6.1 为什么POM在JavaPlaywright里更顺手前面分享了这么多细节但要写成一个能长期维护的自动化测试体系还是得往工程化方向上走。很多Java工程师对Page Object Model都不陌生它的核心思想是给每个页面建立一个类把页面上元素和操作封装成方法测试用例只调用方法、不直接接触定位器。Playwright的Java API和POM配合得非常好因为Locator可以声明为类的字段不必在每次操作时都重新查询。而且Playwright的Locator是“惰性定位”的它不会在创建时就抓取DOM节点而是每次执行动作时再去解析。这样即使页面发生了跳转或者DOM刷新同一个Locator实例依然可以正常工作不会像Selenium的WebElement那样出现stale element异常。这对POM模式是很友好的你不用在每次页面切换后重新findElement写出来的页面类更简洁也更稳定。页面级别的方法返回void或者断言结果测试层只关心业务步骤维护成本基本都集中在了页面类里。6.2 一个注册页面的POM示例拿一个典型的注册页面举例包含性别单选、兴趣多选、协议勾选三类控件。定义一个RegisterPage类把定位和操作都封装起来。public class RegisterPage { private final Page page; private final Locator genderMale; private final Locator genderFemale; private final Locator hobbyBasketball; private final Locator hobbyFootball; private final Locator agreementCheckbox; public RegisterPage(Page page) { this.page page; this.genderMale page.locator(input[namegender][valuemale]); this.genderFemale page.locator(input[namegender][valuefemale]); this.hobbyBasketball page.locator(input[namehobby][valuebasketball]); this.hobbyFootball page.locator(input[namehobby][valuefootball]); this.agreementCheckbox page.locator(input[nameagreement]); } public void selectGenderMale() { genderMale.check(); } public void selectGenderFemale() { genderFemale.check(); } public void selectHobby(String hobby) { page.locator(input[namehobby][value hobby ]).check(); } public void checkAllHobbies() { page.locator(input[namehobby]).all().forEach(Locator::check); } public void agreeToTerms() { agreementCheckbox.check(); } public boolean isMaleSelected() { return genderMale.isChecked(); } public boolean isAgreementChecked() { return agreementCheckbox.isChecked(); } }测试用例调用起来就非常直观了RegisterPage registerPage new RegisterPage(page); registerPage.selectGenderFemale(); registerPage.checkAllHobbies(); registerPage.agreeToTerms(); PlaywrightAssertions.assertThat(registerPage.isMaleSelected()).not().isChecked();这里我用了一个selectHobby(String hobby)方法把兴趣爱好选项参数化这样测试数据可以来源于外部配置。跑不同的组合用例时只要改传入的hobby值就行不用为每个选项单独写一个方法。6.3 什么时候才需要自己写等待虽然前面一直在强调Playwright的自动等待很方便但工程里有些场景还是需要手动介入。比如页面跳转后要等某个控件出来这时候我习惯用page.waitForSelector()显式等待并配合timeout控制超时时长。还有一种情况是点击checkbox后触发了一个接口请求需要等接口返回后再进行后续操作这个用Playwright的page.waitForResponse()更精准比固定sleep可靠得多。写自动等待时要遵循一个原则尽量避免毫无依据的固定Thread.sleep()。它浪费时间而且在不同网络环境下结果不稳定。真要等待就等一个明确的条件元素可见、接口响应、URL变化、文本出现都可以Playwright把这些条件都封装好了不用白不用。最后再分享一个实际项目里的细节。我们有个老系统checkbox的状态是由后端回传的点击之后前端要等接口返回才会刷新为选中态。一开始同事写用例时习惯在click后加个sleep 3000用例又慢又不稳定。后来我改成了click后直接断言页面上的提交按钮变成可点击状态再用这个断言作为后续操作的同步点。这样不仅去掉了sleep整个用例的语义还更贴近业务逻辑执行速度也快了很多。遇到类似场景的读者我强烈建议你试试这个思路把业务联动关系当作同步信号让用例的每一步都像真实用户操作一样自然地衔接。