深夜调试：一个弹窗定位问题，暴露了90%UI自动化的通病

01 深夜的屏幕共享

凌晨零点四十二分，屏幕共享刚打开，一个应届生就迫不及待地展示他的毕业设计。

“企微信通讯录，目前我只做了一个添加成员的模块。”他的鼠标在代码和页面之间快速切换，“但做到添加部门的时候，这里就会显示一个元素覆盖的问题，不知道为什么。”

弹窗。又是弹窗。

做过UI自动化的人都知道，弹窗是新手最常见的拦路虎。但这一次，问题似乎没那么简单。

私教老师没有急着给答案，而是反问了一句：“能具体点吗？”

这是他一贯的风格——不替学员写代码，但帮学员建立解决问题的思维方式。

02 代码能跑通，但弹窗就是点不到

学员重新运行了测试。

页面上，添加部门的流程开始自动执行：点击加号、输入部门名称……然后，卡住了。

“它没有点击确定。”学员指着屏幕，“弹窗识别不到。”

代码逻辑看起来没问题：有等待时间、用了PO设计模式、定位元素也写了。但偏偏到了弹窗这一步，自动化就“瞎”了。

这是UI自动化中最让人头疼的场景：代码没报错，但就是没生效。

私教老师让他用debug模式逐行跑一遍。

断点打在每一个click、每一个输入上。单步执行，观察页面变化。

跑到第4步时，问题浮出水面——定位所属部门的那一行代码出错了。

03 Class重复了，WebDriver不知道该选哪个

“你看，”私教老师圈出代码，“你用的是class定位，但这个class在页面上出现了多次。WebDriver拿到第一个匹配的元素就操作了，那个元素根本不是你想要的弹窗里的选项。”

学员恍然大悟：“所以它点错了地方？”

核心问题浮出：定位器不唯一。

在UI自动化中，class、tagName这些定位方式很容易出现重复。页面越复杂，重复概率越高。一旦元素不唯一，自动化脚本就会“进错门”。

“那怎么办？”学员追问。

“用双重定位。”私教老师给出方案，“要么‘class + ID’组合，要么用XPath找更精确的路径。原则只有一个——确保你定位到的元素，就是你要操作的那个元素。 ”

页面上，弹窗里的选项虽然没有ID，但包含它的父级div有ID。通过父子层级关系定位，就能绕过class重复的问题。

04 弹窗为什么是自动化的“重灾区”？

其实，这次的bug还有一层隐藏原因：弹窗是动态渲染的组件 。

普通的页面元素，页面加载完就存在了。但弹窗不同——它是在用户点击某个按钮后，才被JavaScript动态创建出来。

如果你在弹窗还没完全渲染完成时就去定位元素，WebDriver自然找不到。

这也是为什么UI自动化中，弹窗、下拉框、树形菜单这类组件最容易出问题。它们不是“天生”就在页面上的，而是“后天”长出来的。

应对这类场景，除了精准定位，还需要配合显式等待 ，直到元素真正可操作为止。

05 从“添加部门”到“删除部门”：抽象思维是分水岭

解决了添加部门的问题，学员又问了一个更有价值的问题：

“我只写了添加部门，后面删除部门是不是类似的做法？”

“对，但有个关键步骤。”私教老师引导他推演流程，“首先定位到那个部门的三个点图标，点击展开菜单，然后找到‘删除’按钮，点击，最后处理确认弹窗。”

学员很快理解了：“那添加成员呢？如果我想在部门里添加成员，能复用之前写的添加成员方法吗？”

“当然可以。”私教老师给出了进阶建议，“你把添加成员这个流程抽象成一个公共方法 。不管用户是从哪个入口进入的，添加成员的弹窗内容是一样的。写好一次，到处调用。”

这就是测试代码和“能跑的代码”之间的分水岭。

普通新手写完一个功能就结束了；有工程思维的测试开发工程师会思考：哪些逻辑可以复用？哪些页面对象可以继承？代码的可维护性怎么保证？

06 学员的另一个困惑：实习只有功能测试，怎么提升？

技术问题解决后，学员问了一个更现实的问题：

“我现在找了个实习，做功能测试，纯手工的。公司除了带我的人，就剩我一个测试了。承诺实习五个月但不保证转正，我应该怎么提升？”

私教老师的回答很务实：

“先熟悉业务。大环境下找到一份工作不容易，业务理解本身也是一种能力。熟悉业务之后，再自己去想办法做效率提升——这就是你从‘功能测试’向‘测试开发’迈进的切入点。”

比如，当你发现某个回归场景每天都要手动执行，你可以尝试把它自动化。不需要大而全的工具，哪怕写几个简单的脚本，只要能帮团队节省时间，那就是你的价值。

至于转正问题，老师也给出了客观判断：

“没有公司能拍胸脯保证实习生转正，这取决于你的业务熟练度、实际产出和当时的HC情况。实习快结束时，主动和leader沟通就好。”

07 写在最后

这一小时的私教服务，解决的不仅是一个“元素覆盖”的报错。

学员学到了：

• UI自动化的核心难点 ：动态元素、定位唯一性、等待时机；
• 调试方法论 ：用debug模式逐行跑，观察每一行的实际效果，而不是靠“我感觉”；
• 代码工程思维 ：抽象公共方法、设计可维护的页面对象；
• 职业成长路径 ：在纯手工测试环境中，如何主动创造自动化机会。

而对于正在阅读这篇文章的你，如果也在为UI自动化反复踩坑而头疼，不妨问问自己：

写脚本的时候，有没有确认过每个定位器都是唯一的？ 处理弹窗之前，有没有等待它完全渲染？ 有没有想过把重复的逻辑抽象成公共方法？

这些“小问题”，恰恰是区分“会写脚本”和“会做测试开发”的关键。

霍格沃兹测试开发学社的私教服务，不只教你怎么写代码，更教你怎么思考问题。如果你也在某个技术点上卡了很久，欢迎来找我们聊聊——有时候，一小时的点拨，胜过三天的瞎摸索。