在 Web UI 自动化测试里元素定位一直是绕不开的基础话题。不管是刚入门 Selenium 没多久的新手还是写了好几年框架的老人儿几乎每天都要跟各种定位方式打交道。在 Selenium 的八大定位策略中By.CLASS_NAME 和 By.CSS_SELECTOR 的定位目标长得有点像——因为 CSS 选择器里也常用 class 做钩子所以不少测试同学会简单地认为“既然都是拿 class 定位那我随便用哪个都行”。但实际上这俩的底层逻辑、适用场景、稳定性表现完全不是一个量级的。这篇文章就把它们放在一起扒一扒讲清楚两者的本质区别和实战选择逻辑。我大概从三个方面展开先搞清楚两者的定位机制与语法本质再对比它们在复杂场景下的“能不能做”与“怎么做”最后结合我在实际项目中踩过的坑聊聊选型思路、性能差异以及如何借助前端约定提升定位的稳定性。无论你是刚准备上手 Selenium 的测试新人还是正在维护一套用例多到跑崩的自动化脚本这篇内容应该都能给你一些启发。1. 定位机制的本质差异一个是属性过滤一个是选择器匹配要真正理解 CLASS_NAME 和 CSS_SELECTOR 的区别不能只停留在“写起来一个是 classxxx另一个是 .xxx”这个层面得先看它们背后的匹配逻辑。1.1 CLASS_NAME 定位的本质按属性值“精确找元素”Selenium 中的 By.CLASS_NAME调用的底层其实是 find_element_by_class_name 这个方法。它走的逻辑很简单遍历整个 DOM找出所有 class 属性值与传入值完全相等的元素然后返回第一个匹配项。注意“完全相等”这四个字这是后面很多坑的根源。举个例子假如页面上有个元素是这样的div classcontent-card卡片内容/div那么通过 driver.find_element(By.CLASS_NAME, content-card) 就能定位到它。但假如实际 DOM 长这样div classcontent-card enabled卡片内容/div你再传 content-card 或 enabled 给 By.CLASS_NAME大概率会在控制台看到一条 NoSuchElementException。因为此时 class 属性的完整值是 content-card enabled它不等于 content-card也不等于 enabled。CLASS_NAME 做的是“全量相等匹配”只要 class 属性里存在多个类名单传其中一个就一定失败。这个特性在早期 Selenium 版本里有个细节区别——旧版 Selenium 在某些浏览器驱动下可能出现过部分匹配的行为但按官方文档和规范正确理解就是按完整属性值做匹配。所以在使用 By.CLASS_NAME 的时候几乎有一个隐含的前提你要定位的那个元素的 class 属性值必须只有一个类名且这个类名在页面里是唯一的。一旦前端的 CSS 类名设计比较丰富class 里挂着三四个语义化类名这个方法就基本用不了了。1.2 CSS 选择器定位的本质按选择器语法“规则匹配元素”By.CSS_SELECTOR 则完全不同。它接受的是一个 CSS 选择器表达式这和你在写前端样式时用的选择器是一模一样的语法。也就是说它支持类选择器、ID 选择器、标签选择器、属性选择器、层级选择器、伪类选择器等等然后把匹配这个表达式的所有元素返回回来。比如driver.find_element(By.CSS_SELECTOR, .content-card) driver.find_element(By.CSS_SELECTOR, .content-card.enabled) driver.find_element(By.CSS_SELECTOR, div[classcontent-card])这三行代码第一个匹配所有带 content-card 类名的元素第二个匹配同时带有 content-card 和 enabled 两个类名的元素第三个匹配 class 属性值精确为 content-card 的 div。同样的页面结构用 CLASS_NAME 传两个类名中的某一个会失败但用 CSS 选择器的组合类写法却能轻松命中。这正是两者最底层的差别CLASS_NAME 是“某属性等于某值”的过滤逻辑CSS_SELECTOR 是“满足选择器规则”的匹配逻辑。我也是做了几年自动化之后才慢慢体会到CSS 选择器的本质是把你对页面结构的理解翻译成一串可被浏览器原生解析的语法而 CLASS_NAME 只是其中一个极简子集。1.3 两者的语法复杂度与学习成本对比从学习曲线来说CLASS_NAME 显然是更友好的一方——不需要任何额外知识拿到一个类名直接传进去就完事。CSS 选择器则需要至少掌握类选择器、ID 选择器、属性选择器、子元素选择器和伪类的常见写法。很多测试同学一想到要学 CSS 选择器语法就觉得麻烦觉得这是前端才需要掌握的东西。这个认知说实话有点过时了。在 Selenium 的定位体系里XPath 和 CSS 选择器本身就是为复杂定位场景准备的class 没你想的那么万能ID 也不一定每个元素都有更别说现在很多前端框架的 class 都是动态拼接的。CSS 选择器的组合能力恰恰能解决 class 定位解决不了的场景而且它的可读性比 XPath 那一长串 //div[class...]//span[...] 好太多。2. 核心能力对比哪些场景 CLASS_NAME 能搞定哪些必须换 CSS光讲底层原理有点虚还是直接拉一个场景清单看看在实际页面里哪些情况 CLASS_NAME 还能用哪些情况它会当场翻车。2.1 简单场景页面元素 class 唯一且固定这是 CLASS_NAME 最舒服的适用区间。比如某个登录页只有一个 class 为 login-btn 的按钮且这个按钮不管状态怎么切换类名都不变那直接用 By.CLASS_NAME 定位是完全没有问题的。driver.find_element(By.CLASS_NAME, login-btn).click()这段代码运行起来非常稳定性能也不差因为底层本质上也是走选择器匹配。在这种场景下你非要用 CSS_SELECTOR 写一个 .login-btn 当然也可以但属于杀鸡用牛刀并不会带来额外的稳定性收益。2.2 多类名场景CLASS_NAME 失灵的重灾区这是我在实际项目里遇到最多的情况。现代前端框架比如 React、Vue 和一些组件库特别喜欢把一个元素上挂多个类名来表示不同的状态或样式用途。比如一个按钮button classel-button el-button--primary is-round提交/button这种元素我在某个后台管理系统的表单页里几乎天天见。如果我用 By.CLASS_NAME到底传哪个类名传 el-button匹配失败因为 class 属性值是三个类名拼接而成不等于 el-button。传 el-button--primary 呢同理还是失败。只有一种情况能成功——传 el-button el-button--primary is-round也就是把整个属性值原封不动地传进去。如果你写的代码是driver.find_element(By.CLASS_NAME, el-button)毫无疑问跑一次挂一次。在这种场景下正确的姿势是用 CSS 选择器的组合类driver.find_element(By.CSS_SELECTOR, .el-button--primary.is-round)前面这个点号代表类选择器两个点号贴在一起表示“同时具备这两个类”这样无论 class 属性里插了多少个类名、顺序怎么样只要目标类名都存在就能稳定命中。2.3 动态类名场景CSS 选择器的属性匹配优势再往前端框架技术好的项目里走一步你会发现很多元素的 class 是动态生成的。比如列表项li classitem item-3 active第三项/li这里的 item-3 里那个数字 3是根据数据索引动态拼出来的。如果你用 CLASS_NAME 传 item-3 去做定位下次列表顺序一变、数据一增删这个类名就变了脚本直接废掉。更聪明的做法是在 CSS 选择器里用属性匹配driver.find_element(By.CSS_SELECTOR, li.item.active)选择同时带 item 和 active 的 li 元素不依赖那个会变的数字后缀。或者干脆更灵活一点用前缀匹配driver.find_element(By.CSS_SELECTOR, li[class*item-]:not(.inactive))意思是找一个 class 属性中包含 item- 的 li且不是 inactive 状态的元素。这种定位能力CLASS_NAME 是完全不具备的它只能按照精确属性值去匹配连“包含某类名”这个概念都表达不出来。2.4 层级与结构定位CLASS_NAME 只能找“类名”CSS 能找“位置”还有一个 CLASS_NAME 无论如何都做不到的就是基于元素层级关系的定位。举个例子某个页面的左侧菜单所有的菜单项都是同一个 classmenu-item但二级菜单里只有某个特定父级下面的项才是你需要的div classmenu-group ul classmenu-list li classmenu-item首页/li li classmenu-item用户管理/li li classmenu-item span系统设置/span ul classsub-menu li classmenu-item权限配置/li /ul /li /ul /div这种情况下页面里有四个 menu-itemCLASS_NAME 永远只能定位到第一个完全没法表达“我想找 sub-menu 里的那个 menu-item”。但用 CSS 组合层级选择器一句话就搞定driver.find_element(By.CSS_SELECTOR, .sub-menu .menu-item)甚至你还可以用子元素选择器写 .menu-list .menu-item 来精确筛选。这就是 CLASS_NAME 的边界它只能帮你找“类名等于什么”的元素一旦需要表达“元素在哪里”这招就彻底失灵了必须换 CSS 选择器或者 XPath。2.5 其他常见对比场景速查我把平时最容易遇到的情况拉成一个表格方便大家对比场景CLASS_NAMECSS_SELECTOR单一固定类名可以写法最简单可以但略显多余多个类名同时匹配不行必须传全部类名可以.class1.class2class 里有动态后缀不行一旦变化就失效可以配合属性选择器按层级找子孙元素不行可以空格或 连接按属性值定位不行可以[typetext] 等找第几个同类型元素不行可以nth-child/nth-of-type按状态伪类筛选不行可以:hover/:disabled/:checked这个表应该能很直观地说明问题CLASS_NAME 是“能用但有边界”CSS_SELECTOR 是“想怎么定位就怎么定位”。3. 实操经验谈我从项目里总结的定位选型心得说实话理论层面看再多不如直接在项目里跑几个来回。下面这些经验有一部分是我一开始学的时候就没有意识到的有一部分是从别的测试开发同事那边学来的都有实战基础基本每一句都有对应的踩坑记忆。3.1 优先级的判断逻辑不是“能用就行”而是“改了不坏”我见过的自动化用例里用 CLASS_NAME 定位写出来的代码其实不少因为刚学的时候教材都爱用简单例子。但真正开始维护之后问题就暴露出来了。前端同学只要在 class 属性里加一个状态类名比如常见的是加一个 disabled 或 activeCLASS_NAME 定位的用例立刻红一片。这个滋味我体验过不止一次。后来我给自己定了个简单的选型原则如果目标是简单且稳定的——class 固定、唯一、不会变那 CLASS_NAME 无所谓怎么简单怎么来但只要这个 class 存在任何一丁点变动可能或者我要定位的元素在页面上有多个同类名我直接上 CSS_SELECTOR不再纠结。维护的稳定性比写起来省那几个字符重要太多了。3.2 关于性能的迷思CLASS_NAME 不一定比 CSS 快有不少同学觉得CLASS_NAME 定位的是简单属性匹配性能一定比 CSS_SELECTOR 这种复杂表达式要好。这个想法有道理但实际情况没那么绝对。Selenium 在调用 CLASS_NAME 定位时底层是通过浏览器驱动执行一段等价于 CSS 类选择器的查找逻辑而 CSS_SELECTOR 就是把你的选择器表达式直接交给浏览器原生的 querySelector 去执行。对于简单类名场景两者的耗时都在个位数毫秒级别肉眼和接口返回时长都感知不到差距。真正会拉跨性能的是那些写了特别长的 XPath比如靠 text() 和多层谓词堆出来的 xpath//div[classa]//span[contains(text(),xx)]//following-sibling::div[...] 这种每次定位都需要遍历大量 DOM 节点那才是明显的性能瓶颈。所以在 CLASS_NAME 与 CSS_SELECTOR 之间做选择时性能基本不需要作为一个决策因素。更值得关注的是稳定性和可维护性。当然如果你在一个循环里反复定位同一个元素可以先把元素对象缓存到变量里而不是每次循环都重新查找一次 DOM这一点比选择哪种定位方式的影响大得多。3.3 与前端约定的稳定性设计比定位技巧更重要的思路到项目后期我越来越意识到解决定位问题不能只靠测试端技巧更好的路径是跟前端团队建立约定。比如在需要自动化覆盖的重点功能区域约定使用固定的>button classbutton button-primary>driver.find_element(By.CSS_SELECTOR, [data-testidlogin-submit])很多大型项目的自动化测试团队都在采用类似的方案。因为 class 是给样式用的天然容易被调整而>driver.find_element(By.CSS_SELECTOR, #username)类选择器用 . 开头刚才反复提过。混合写法也很常见driver.find_element(By.CSS_SELECTOR, input#username.form-control)这里表示一个同时满足标签为 input、id 为 username、class 包含 form-control 的元素。组合条件越多定位的精确度越高误伤其他元素的概率越低。属性选择器用方括号可以按任意属性和属性值定位driver.find_element(By.CSS_SELECTOR, [placeholder请输入用户名]) driver.find_element(By.CSS_SELECTOR, input[namephone]) driver.find_element(By.CSS_SELECTOR, [class*error])第三种写法中的 * 是“包含匹配”的意思表示属性值里包含 error 就命中。这种匹配方式在处理动态 class 时特别实用。另外还有 ^ 表示开头匹配$ 表示结尾匹配按需使用。层级选择器包括后代选择器空格和子元素选择器driver.find_element(By.CSS_SELECTOR, .form-group input) driver.find_element(By.CSS_SELECTOR, .form-group input)前者的含义是找所有 .form-group 内部任意层级的 input后者的含义是找 .form-group 的直接子元素 input。两者的匹配范围不一样写错了可能会定位到不想选的元素或者什么都匹配不到。伪类选择器在测试里也会用到比如 :nth-child、:nth-of-type、:disabled、:checked、:notdriver.find_element(By.CSS_SELECTOR, ul li:nth-child(2)) driver.find_element(By.CSS_SELECTOR, input[typecheckbox]:checked) driver.find_element(By.CSS_SELECTOR, .item:not(.disabled))4.2 操作细节与注意点CSS 选择器写起来容易但实际运行的时候有几个细节容易翻车我列一下自己踩过的坑属性值如果包含空格必须用引号包起来。这个其实非常常见比如input placeholder请输入 用户名写成 [placeholder请输入 用户名] 没问题因为整体被引号包住了但如果你用不含引号的写法 input[placeholder请输入用户名]不光是空格问题包括其他特殊字符也会有解析风险。另外就是 class 属性里的空格问题。CSS 类选择器 .item.active 中间没有空格表达的是“一个元素同时具备 item 和 active 两个类”。但如果写成 .item .active中间有空格语义就变成“先找 class 为 item 的元素再找它内部 class 为 active 的后代元素”完全是两个意思。这个坑在写复杂页面定位时特别容易埋下报错出来还不太好查只能一点点比对选择器结构。还有一点就是不要想着一个选择器“一把梭”。有时候一个复杂页面直接把所有层级关系写成一个超长选择器看似万能但中间任何一层结构发生变化定位就挂掉。我的实践是尽量让选择器守住“目标元素最稳定的那部分特征”优先用 id、自定义属性、稳定类名作为锚点而不是把所有祖先元素全部堆上去。4.3 脚本侧执行策略首元素与多元素处理另外一个容易忽略但实际非常影响稳定性的是 Selenium 中 find_element 和 find_elements 的区别。CSS 选择器匹配到的元素个数可能不是一个find_element 返回第一个匹配元素find_elements 返回所有匹配元素的列表。我见过不少新手在定位一组同 class 的列表项时先用 find_elements 拿集合取索引操作这样没问题。但也见过一种情况同一个 CSS 选择器在页面上有多个匹配元素测试者误以为 find_element 会报错——实际上它不会报错只会静默地返回第一个元素导致后面断言和点击操作作用在错误的目标上。所以写定位代码之前建议先确认两点这个选择器在页面上到底会匹配几个元素我到底想要哪一个如果预期只有一个但实际匹配到多个说明选择器写宽了应该继续加限定条件。这种排查思路能省掉很多定位不准的诡异 bug。5. 两者混用时的维护策略与团队协作实践如果你维护的是一套有一定规模的自动化测试工程定位策略的选择还会涉及编码规范、用例可读性、团队协作效率等多个层面。这节单独拿出来说一下。5.1 定一个团队内部的“定位规范”我在项目里发现一个颇为现实的问题团队里每个人写定位的偏好不一样有人喜欢 XPath有人只用 CLASS_NAME有人觉得 CSS 选择器太“前端化”不想学。结果就是用例代码风格五花八门遇到报错排查大家互相看不懂对方的选择器在干嘛。后来我们内部约定了一个相对统一的规范原则很简单能用 CSS 选择器解决的不写 XPath能用 id 或自定义属性定位的优先使用CLASS_NAME 只允许用于那些绝对稳定且无多类名干扰的场景。这个规范后来确实帮助了不少新加入的同学减少了“这个定位表达式到底在表达什么”的沟通成本。5.2 定位表达式的可读性优化CSS 选择器虽然表达能力比 CLASS_NAME 强但也容易写成一长串天书。比如driver.find_element(By.CSS_SELECTOR, div.main div.content-wrapper div.table-container tbody tr:nth-child(3) td:nth-child(2) button)这种选择器虽然功能正确但读起来确实累。我通常的做法是给关键操作步骤加注释说明选择器的定位意图。如果有必要可以把复杂的定位表达式提取成变量甚至可以单独封装成 Page Object 中的方法让用例层只看到语义化的定位描述detail_button div.table-container tbody tr:nth-child(3) td:nth-child(2) button这样既保留了定位能力又让用例的可读性和可维护性都上来了。5.3 与前端团队的协作约定前面提到过>driver.find_element(By.CSS_SELECTOR, [data-testidmodal-confirm])这种字符串格式很难出错跟 CLASS_NAME 相比它的稳定性高出一大截。因为前端再怎么重构 class 名只要测试钩子属性不变脚本就还能跑。6. 常见问题与排查技巧速查最后整理一下我在实际调试过程中经常碰到的问题做成一个速查表方便大家定位排查的时候对照参考。常见现象可能原因排查思路CLASS_NAME 定位不到元素class 属性包含多个类名class 值是动态拼接的用浏览器开发者工具查看实际节点 class 属性值确认是否是多类名或动态后缀CLASS_NAME 能定位到但总点错页面存在多个相同类名元素find_element 返回第一个用 find_elements 确认匹配数量改用 CSS 限定层级或增加唯一属性CSS 选择器报语法错误类名组合写成了中间带空格 .a .b表达式带了多余引号之类的先拆短选择器逐个验证再拼回去用浏览器开发者工具 Console 执行 document.querySelectorAll 验证CSS 选择器匹配到多个元素选择器条件过宽比如只写了标签或单类名增加属性、层级、状态伪类等限定条件缩小范围动态数据导致定位失效class 或文本中包含索引、时间戳等可变值改用 class 包含匹配 [class*xxx]或使用稳定属性定位元素只在特定状态出现没有处理显隐、加载、disabled 等状态结合显式等待 WebDriverWait 等待元素出现或状态变化后再操作其中第二条“总点错”我深有感触这是 CLASS_NAME 最隐蔽的坑。因为定位本身不会报错脚本可以继续跑但点击的一直是页面上第一个同类元素。等断言失败再去查定位表达式看上去又没问题其实是选择器写的太宽了。另外补充一个增压技巧对于动态加载的内容用 CSS 定位写完之后不要急着跑到完整用例里去验证。先在浏览器开发者工具里直接执行 document.querySelectorAll(你的选择器)看一下返回的节点数和具体节点内容确认没问题再贴到脚本里。这一步能提前过滤掉一半以上的选择器错误省下大量来回调试的时间。7. 几点个人体会前前后后写了几年自动化关于 CLASS_NAME 和 CSS_SELECTOR 的选择我个人的体会是定位方式的选用从来不只是“哪个能工作”这么简单更关键的是“哪个在三个月后依然能工作”。CLASS_NAME 在面对简单固定页面时完全够用但一旦项目进入快速迭代期前端结构和类名频繁调整它的脆弱性就会立刻暴露。CSS 选择器表达能力强虽然刚开始要多记几个语法但一旦掌握基本上九成以上的定位场景都能覆盖而且不太会因为小改动就崩掉。如果你现在还在纠结这两个用哪个我建议直接尝试把复杂场景的定位都改成 CSS_SELECTOR 来写从动态类名、多类名、层级关系这几个常见痛点入手跑一两个迭代之后你自然能感受到差别。最后再分享一个小技巧遇到难搞的定位问题时在浏览器开发者工具里用 document.querySelectorAll 先验证一遍选择器比在自动化脚本里反复试错要快得多这个习惯真的能省出大把时间。 
长河君 · 2026/10/21 9:45:25 · 阅读 1.2k Selenium中CLASS_NAME与CSS_SELECTOR的定位区别与选型
在 Web UI 自动化测试里元素定位一直是绕不开的基础话题。不管是刚入门 Selenium 没多久的新手还是写了好几年框架的老人儿几乎每天都要跟各种定位方式打交道。在 Selenium 的八大定位策略中By.CLASS_NAME 和 By.CSS_SELECTOR 的定位目标长得有点像——因为 CSS 选择器里也常用 class 做钩子所以不少测试同学会简单地认为“既然都是拿 class 定位那我随便用哪个都行”。但实际上这俩的底层逻辑、适用场景、稳定性表现完全不是一个量级的。这篇文章就把它们放在一起扒一扒讲清楚两者的本质区别和实战选择逻辑。我大概从三个方面展开先搞清楚两者的定位机制与语法本质再对比它们在复杂场景下的“能不能做”与“怎么做”最后结合我在实际项目中踩过的坑聊聊选型思路、性能差异以及如何借助前端约定提升定位的稳定性。无论你是刚准备上手 Selenium 的测试新人还是正在维护一套用例多到跑崩的自动化脚本这篇内容应该都能给你一些启发。1. 定位机制的本质差异一个是属性过滤一个是选择器匹配要真正理解 CLASS_NAME 和 CSS_SELECTOR 的区别不能只停留在“写起来一个是 classxxx另一个是 .xxx”这个层面得先看它们背后的匹配逻辑。1.1 CLASS_NAME 定位的本质按属性值“精确找元素”Selenium 中的 By.CLASS_NAME调用的底层其实是 find_element_by_class_name 这个方法。它走的逻辑很简单遍历整个 DOM找出所有 class 属性值与传入值完全相等的元素然后返回第一个匹配项。注意“完全相等”这四个字这是后面很多坑的根源。举个例子假如页面上有个元素是这样的div classcontent-card卡片内容/div那么通过 driver.find_element(By.CLASS_NAME, content-card) 就能定位到它。但假如实际 DOM 长这样div classcontent-card enabled卡片内容/div你再传 content-card 或 enabled 给 By.CLASS_NAME大概率会在控制台看到一条 NoSuchElementException。因为此时 class 属性的完整值是 content-card enabled它不等于 content-card也不等于 enabled。CLASS_NAME 做的是“全量相等匹配”只要 class 属性里存在多个类名单传其中一个就一定失败。这个特性在早期 Selenium 版本里有个细节区别——旧版 Selenium 在某些浏览器驱动下可能出现过部分匹配的行为但按官方文档和规范正确理解就是按完整属性值做匹配。所以在使用 By.CLASS_NAME 的时候几乎有一个隐含的前提你要定位的那个元素的 class 属性值必须只有一个类名且这个类名在页面里是唯一的。一旦前端的 CSS 类名设计比较丰富class 里挂着三四个语义化类名这个方法就基本用不了了。1.2 CSS 选择器定位的本质按选择器语法“规则匹配元素”By.CSS_SELECTOR 则完全不同。它接受的是一个 CSS 选择器表达式这和你在写前端样式时用的选择器是一模一样的语法。也就是说它支持类选择器、ID 选择器、标签选择器、属性选择器、层级选择器、伪类选择器等等然后把匹配这个表达式的所有元素返回回来。比如driver.find_element(By.CSS_SELECTOR, .content-card) driver.find_element(By.CSS_SELECTOR, .content-card.enabled) driver.find_element(By.CSS_SELECTOR, div[classcontent-card])这三行代码第一个匹配所有带 content-card 类名的元素第二个匹配同时带有 content-card 和 enabled 两个类名的元素第三个匹配 class 属性值精确为 content-card 的 div。同样的页面结构用 CLASS_NAME 传两个类名中的某一个会失败但用 CSS 选择器的组合类写法却能轻松命中。这正是两者最底层的差别CLASS_NAME 是“某属性等于某值”的过滤逻辑CSS_SELECTOR 是“满足选择器规则”的匹配逻辑。我也是做了几年自动化之后才慢慢体会到CSS 选择器的本质是把你对页面结构的理解翻译成一串可被浏览器原生解析的语法而 CLASS_NAME 只是其中一个极简子集。1.3 两者的语法复杂度与学习成本对比从学习曲线来说CLASS_NAME 显然是更友好的一方——不需要任何额外知识拿到一个类名直接传进去就完事。CSS 选择器则需要至少掌握类选择器、ID 选择器、属性选择器、子元素选择器和伪类的常见写法。很多测试同学一想到要学 CSS 选择器语法就觉得麻烦觉得这是前端才需要掌握的东西。这个认知说实话有点过时了。在 Selenium 的定位体系里XPath 和 CSS 选择器本身就是为复杂定位场景准备的class 没你想的那么万能ID 也不一定每个元素都有更别说现在很多前端框架的 class 都是动态拼接的。CSS 选择器的组合能力恰恰能解决 class 定位解决不了的场景而且它的可读性比 XPath 那一长串 //div[class...]//span[...] 好太多。2. 核心能力对比哪些场景 CLASS_NAME 能搞定哪些必须换 CSS光讲底层原理有点虚还是直接拉一个场景清单看看在实际页面里哪些情况 CLASS_NAME 还能用哪些情况它会当场翻车。2.1 简单场景页面元素 class 唯一且固定这是 CLASS_NAME 最舒服的适用区间。比如某个登录页只有一个 class 为 login-btn 的按钮且这个按钮不管状态怎么切换类名都不变那直接用 By.CLASS_NAME 定位是完全没有问题的。driver.find_element(By.CLASS_NAME, login-btn).click()这段代码运行起来非常稳定性能也不差因为底层本质上也是走选择器匹配。在这种场景下你非要用 CSS_SELECTOR 写一个 .login-btn 当然也可以但属于杀鸡用牛刀并不会带来额外的稳定性收益。2.2 多类名场景CLASS_NAME 失灵的重灾区这是我在实际项目里遇到最多的情况。现代前端框架比如 React、Vue 和一些组件库特别喜欢把一个元素上挂多个类名来表示不同的状态或样式用途。比如一个按钮button classel-button el-button--primary is-round提交/button这种元素我在某个后台管理系统的表单页里几乎天天见。如果我用 By.CLASS_NAME到底传哪个类名传 el-button匹配失败因为 class 属性值是三个类名拼接而成不等于 el-button。传 el-button--primary 呢同理还是失败。只有一种情况能成功——传 el-button el-button--primary is-round也就是把整个属性值原封不动地传进去。如果你写的代码是driver.find_element(By.CLASS_NAME, el-button)毫无疑问跑一次挂一次。在这种场景下正确的姿势是用 CSS 选择器的组合类driver.find_element(By.CSS_SELECTOR, .el-button--primary.is-round)前面这个点号代表类选择器两个点号贴在一起表示“同时具备这两个类”这样无论 class 属性里插了多少个类名、顺序怎么样只要目标类名都存在就能稳定命中。2.3 动态类名场景CSS 选择器的属性匹配优势再往前端框架技术好的项目里走一步你会发现很多元素的 class 是动态生成的。比如列表项li classitem item-3 active第三项/li这里的 item-3 里那个数字 3是根据数据索引动态拼出来的。如果你用 CLASS_NAME 传 item-3 去做定位下次列表顺序一变、数据一增删这个类名就变了脚本直接废掉。更聪明的做法是在 CSS 选择器里用属性匹配driver.find_element(By.CSS_SELECTOR, li.item.active)选择同时带 item 和 active 的 li 元素不依赖那个会变的数字后缀。或者干脆更灵活一点用前缀匹配driver.find_element(By.CSS_SELECTOR, li[class*item-]:not(.inactive))意思是找一个 class 属性中包含 item- 的 li且不是 inactive 状态的元素。这种定位能力CLASS_NAME 是完全不具备的它只能按照精确属性值去匹配连“包含某类名”这个概念都表达不出来。2.4 层级与结构定位CLASS_NAME 只能找“类名”CSS 能找“位置”还有一个 CLASS_NAME 无论如何都做不到的就是基于元素层级关系的定位。举个例子某个页面的左侧菜单所有的菜单项都是同一个 classmenu-item但二级菜单里只有某个特定父级下面的项才是你需要的div classmenu-group ul classmenu-list li classmenu-item首页/li li classmenu-item用户管理/li li classmenu-item span系统设置/span ul classsub-menu li classmenu-item权限配置/li /ul /li /ul /div这种情况下页面里有四个 menu-itemCLASS_NAME 永远只能定位到第一个完全没法表达“我想找 sub-menu 里的那个 menu-item”。但用 CSS 组合层级选择器一句话就搞定driver.find_element(By.CSS_SELECTOR, .sub-menu .menu-item)甚至你还可以用子元素选择器写 .menu-list .menu-item 来精确筛选。这就是 CLASS_NAME 的边界它只能帮你找“类名等于什么”的元素一旦需要表达“元素在哪里”这招就彻底失灵了必须换 CSS 选择器或者 XPath。2.5 其他常见对比场景速查我把平时最容易遇到的情况拉成一个表格方便大家对比场景CLASS_NAMECSS_SELECTOR单一固定类名可以写法最简单可以但略显多余多个类名同时匹配不行必须传全部类名可以.class1.class2class 里有动态后缀不行一旦变化就失效可以配合属性选择器按层级找子孙元素不行可以空格或 连接按属性值定位不行可以[typetext] 等找第几个同类型元素不行可以nth-child/nth-of-type按状态伪类筛选不行可以:hover/:disabled/:checked这个表应该能很直观地说明问题CLASS_NAME 是“能用但有边界”CSS_SELECTOR 是“想怎么定位就怎么定位”。3. 实操经验谈我从项目里总结的定位选型心得说实话理论层面看再多不如直接在项目里跑几个来回。下面这些经验有一部分是我一开始学的时候就没有意识到的有一部分是从别的测试开发同事那边学来的都有实战基础基本每一句都有对应的踩坑记忆。3.1 优先级的判断逻辑不是“能用就行”而是“改了不坏”我见过的自动化用例里用 CLASS_NAME 定位写出来的代码其实不少因为刚学的时候教材都爱用简单例子。但真正开始维护之后问题就暴露出来了。前端同学只要在 class 属性里加一个状态类名比如常见的是加一个 disabled 或 activeCLASS_NAME 定位的用例立刻红一片。这个滋味我体验过不止一次。后来我给自己定了个简单的选型原则如果目标是简单且稳定的——class 固定、唯一、不会变那 CLASS_NAME 无所谓怎么简单怎么来但只要这个 class 存在任何一丁点变动可能或者我要定位的元素在页面上有多个同类名我直接上 CSS_SELECTOR不再纠结。维护的稳定性比写起来省那几个字符重要太多了。3.2 关于性能的迷思CLASS_NAME 不一定比 CSS 快有不少同学觉得CLASS_NAME 定位的是简单属性匹配性能一定比 CSS_SELECTOR 这种复杂表达式要好。这个想法有道理但实际情况没那么绝对。Selenium 在调用 CLASS_NAME 定位时底层是通过浏览器驱动执行一段等价于 CSS 类选择器的查找逻辑而 CSS_SELECTOR 就是把你的选择器表达式直接交给浏览器原生的 querySelector 去执行。对于简单类名场景两者的耗时都在个位数毫秒级别肉眼和接口返回时长都感知不到差距。真正会拉跨性能的是那些写了特别长的 XPath比如靠 text() 和多层谓词堆出来的 xpath//div[classa]//span[contains(text(),xx)]//following-sibling::div[...] 这种每次定位都需要遍历大量 DOM 节点那才是明显的性能瓶颈。所以在 CLASS_NAME 与 CSS_SELECTOR 之间做选择时性能基本不需要作为一个决策因素。更值得关注的是稳定性和可维护性。当然如果你在一个循环里反复定位同一个元素可以先把元素对象缓存到变量里而不是每次循环都重新查找一次 DOM这一点比选择哪种定位方式的影响大得多。3.3 与前端约定的稳定性设计比定位技巧更重要的思路到项目后期我越来越意识到解决定位问题不能只靠测试端技巧更好的路径是跟前端团队建立约定。比如在需要自动化覆盖的重点功能区域约定使用固定的>button classbutton button-primary>driver.find_element(By.CSS_SELECTOR, [data-testidlogin-submit])很多大型项目的自动化测试团队都在采用类似的方案。因为 class 是给样式用的天然容易被调整而>driver.find_element(By.CSS_SELECTOR, #username)类选择器用 . 开头刚才反复提过。混合写法也很常见driver.find_element(By.CSS_SELECTOR, input#username.form-control)这里表示一个同时满足标签为 input、id 为 username、class 包含 form-control 的元素。组合条件越多定位的精确度越高误伤其他元素的概率越低。属性选择器用方括号可以按任意属性和属性值定位driver.find_element(By.CSS_SELECTOR, [placeholder请输入用户名]) driver.find_element(By.CSS_SELECTOR, input[namephone]) driver.find_element(By.CSS_SELECTOR, [class*error])第三种写法中的 * 是“包含匹配”的意思表示属性值里包含 error 就命中。这种匹配方式在处理动态 class 时特别实用。另外还有 ^ 表示开头匹配$ 表示结尾匹配按需使用。层级选择器包括后代选择器空格和子元素选择器driver.find_element(By.CSS_SELECTOR, .form-group input) driver.find_element(By.CSS_SELECTOR, .form-group input)前者的含义是找所有 .form-group 内部任意层级的 input后者的含义是找 .form-group 的直接子元素 input。两者的匹配范围不一样写错了可能会定位到不想选的元素或者什么都匹配不到。伪类选择器在测试里也会用到比如 :nth-child、:nth-of-type、:disabled、:checked、:notdriver.find_element(By.CSS_SELECTOR, ul li:nth-child(2)) driver.find_element(By.CSS_SELECTOR, input[typecheckbox]:checked) driver.find_element(By.CSS_SELECTOR, .item:not(.disabled))4.2 操作细节与注意点CSS 选择器写起来容易但实际运行的时候有几个细节容易翻车我列一下自己踩过的坑属性值如果包含空格必须用引号包起来。这个其实非常常见比如input placeholder请输入 用户名写成 [placeholder请输入 用户名] 没问题因为整体被引号包住了但如果你用不含引号的写法 input[placeholder请输入用户名]不光是空格问题包括其他特殊字符也会有解析风险。另外就是 class 属性里的空格问题。CSS 类选择器 .item.active 中间没有空格表达的是“一个元素同时具备 item 和 active 两个类”。但如果写成 .item .active中间有空格语义就变成“先找 class 为 item 的元素再找它内部 class 为 active 的后代元素”完全是两个意思。这个坑在写复杂页面定位时特别容易埋下报错出来还不太好查只能一点点比对选择器结构。还有一点就是不要想着一个选择器“一把梭”。有时候一个复杂页面直接把所有层级关系写成一个超长选择器看似万能但中间任何一层结构发生变化定位就挂掉。我的实践是尽量让选择器守住“目标元素最稳定的那部分特征”优先用 id、自定义属性、稳定类名作为锚点而不是把所有祖先元素全部堆上去。4.3 脚本侧执行策略首元素与多元素处理另外一个容易忽略但实际非常影响稳定性的是 Selenium 中 find_element 和 find_elements 的区别。CSS 选择器匹配到的元素个数可能不是一个find_element 返回第一个匹配元素find_elements 返回所有匹配元素的列表。我见过不少新手在定位一组同 class 的列表项时先用 find_elements 拿集合取索引操作这样没问题。但也见过一种情况同一个 CSS 选择器在页面上有多个匹配元素测试者误以为 find_element 会报错——实际上它不会报错只会静默地返回第一个元素导致后面断言和点击操作作用在错误的目标上。所以写定位代码之前建议先确认两点这个选择器在页面上到底会匹配几个元素我到底想要哪一个如果预期只有一个但实际匹配到多个说明选择器写宽了应该继续加限定条件。这种排查思路能省掉很多定位不准的诡异 bug。5. 两者混用时的维护策略与团队协作实践如果你维护的是一套有一定规模的自动化测试工程定位策略的选择还会涉及编码规范、用例可读性、团队协作效率等多个层面。这节单独拿出来说一下。5.1 定一个团队内部的“定位规范”我在项目里发现一个颇为现实的问题团队里每个人写定位的偏好不一样有人喜欢 XPath有人只用 CLASS_NAME有人觉得 CSS 选择器太“前端化”不想学。结果就是用例代码风格五花八门遇到报错排查大家互相看不懂对方的选择器在干嘛。后来我们内部约定了一个相对统一的规范原则很简单能用 CSS 选择器解决的不写 XPath能用 id 或自定义属性定位的优先使用CLASS_NAME 只允许用于那些绝对稳定且无多类名干扰的场景。这个规范后来确实帮助了不少新加入的同学减少了“这个定位表达式到底在表达什么”的沟通成本。5.2 定位表达式的可读性优化CSS 选择器虽然表达能力比 CLASS_NAME 强但也容易写成一长串天书。比如driver.find_element(By.CSS_SELECTOR, div.main div.content-wrapper div.table-container tbody tr:nth-child(3) td:nth-child(2) button)这种选择器虽然功能正确但读起来确实累。我通常的做法是给关键操作步骤加注释说明选择器的定位意图。如果有必要可以把复杂的定位表达式提取成变量甚至可以单独封装成 Page Object 中的方法让用例层只看到语义化的定位描述detail_button div.table-container tbody tr:nth-child(3) td:nth-child(2) button这样既保留了定位能力又让用例的可读性和可维护性都上来了。5.3 与前端团队的协作约定前面提到过>driver.find_element(By.CSS_SELECTOR, [data-testidmodal-confirm])这种字符串格式很难出错跟 CLASS_NAME 相比它的稳定性高出一大截。因为前端再怎么重构 class 名只要测试钩子属性不变脚本就还能跑。6. 常见问题与排查技巧速查最后整理一下我在实际调试过程中经常碰到的问题做成一个速查表方便大家定位排查的时候对照参考。常见现象可能原因排查思路CLASS_NAME 定位不到元素class 属性包含多个类名class 值是动态拼接的用浏览器开发者工具查看实际节点 class 属性值确认是否是多类名或动态后缀CLASS_NAME 能定位到但总点错页面存在多个相同类名元素find_element 返回第一个用 find_elements 确认匹配数量改用 CSS 限定层级或增加唯一属性CSS 选择器报语法错误类名组合写成了中间带空格 .a .b表达式带了多余引号之类的先拆短选择器逐个验证再拼回去用浏览器开发者工具 Console 执行 document.querySelectorAll 验证CSS 选择器匹配到多个元素选择器条件过宽比如只写了标签或单类名增加属性、层级、状态伪类等限定条件缩小范围动态数据导致定位失效class 或文本中包含索引、时间戳等可变值改用 class 包含匹配 [class*xxx]或使用稳定属性定位元素只在特定状态出现没有处理显隐、加载、disabled 等状态结合显式等待 WebDriverWait 等待元素出现或状态变化后再操作其中第二条“总点错”我深有感触这是 CLASS_NAME 最隐蔽的坑。因为定位本身不会报错脚本可以继续跑但点击的一直是页面上第一个同类元素。等断言失败再去查定位表达式看上去又没问题其实是选择器写的太宽了。另外补充一个增压技巧对于动态加载的内容用 CSS 定位写完之后不要急着跑到完整用例里去验证。先在浏览器开发者工具里直接执行 document.querySelectorAll(你的选择器)看一下返回的节点数和具体节点内容确认没问题再贴到脚本里。这一步能提前过滤掉一半以上的选择器错误省下大量来回调试的时间。7. 几点个人体会前前后后写了几年自动化关于 CLASS_NAME 和 CSS_SELECTOR 的选择我个人的体会是定位方式的选用从来不只是“哪个能工作”这么简单更关键的是“哪个在三个月后依然能工作”。CLASS_NAME 在面对简单固定页面时完全够用但一旦项目进入快速迭代期前端结构和类名频繁调整它的脆弱性就会立刻暴露。CSS 选择器表达能力强虽然刚开始要多记几个语法但一旦掌握基本上九成以上的定位场景都能覆盖而且不太会因为小改动就崩掉。如果你现在还在纠结这两个用哪个我建议直接尝试把复杂场景的定位都改成 CSS_SELECTOR 来写从动态类名、多类名、层级关系这几个常见痛点入手跑一两个迭代之后你自然能感受到差别。最后再分享一个小技巧遇到难搞的定位问题时在浏览器开发者工具里用 document.querySelectorAll 先验证一遍选择器比在自动化脚本里反复试错要快得多这个习惯真的能省出大把时间。