最近在学习 UI 自动化，大致看下来发现基本上都是靠元素定位实现点击、滑动、传值等交互操作。如果是对一个完全未开发的页面来做自动化测试前的准备，似乎无从入手。想请教一下各位有自动化经验的朋友们，你们在进行 UI 自动化的时候都主要是通过定位元素实现交互吗？有没有一个其他的应用场景呢？亦或是有和其他的技术结合一起使用呢
自动化测试，不是为了发现 bug，而且为了回归功能，是否会有问题，不用每次人工去点一遍。
自动化测试本身就是用来回归测试解放重复劳动的把，新需求还是得手工
新业务的自动化，可能只有接口自动化是有完成角度的了，因为在新业务中包括接口和 UI 在内不到发布前，你永远不知道他还会不会变，不管是 ui 变化，你后端接口有调整的话，你可能用例都要改，那之前不就存在大量浪费工作时长了吗
我的建议是，不要学 UI 自动化，卵用没有
1、冒烟测试用例，提高自测通过率。
2、回归用例集，降本增效。
前提有一套机制，能够对失败的用例进行自判断。
页面未开发，为什么这个时间点就要进入到 UI 自动化测试准备了？写用例，接口测试这些直接跳过吗
可以关注一下大厂的自动化方案，他们将市面上主流的框架都进行了封装，除了控件获取外，还有抓图找色，OCR，图像处理，游戏控件获取等，另外他们也会封装一些常用的库，比如弹框处理，性能监控等，一定不要自己造，有条件的话还是要引入大厂的方案。
以国内大部分这种流线是做不了先编写自动化脚本的，只能用来做回归测试，就算你在测试前在前端页面交互开发完成入场开始写也免不了一直受修改变动，当然是你只专项自动化开发工作不用其它功能测试编写用例等繁琐状态下
不定位元素怎么操作？
也不是不行，你要先解决一个问题，在页面还没开发之前，你人是怎么思考的，你准备如何着手 UI 测试，这里说的不是自动化，仅是 UI 测试。如果你本身都不知道怎么做，何谈自动化。
如果是做准备的话可以根据 UX 和需求文档把大致逻辑捋顺，mock 一些 xpth，后续再对接上真实的。
从理想的模型来说，这完全是可行的：
- 需求明确下来了，可以编写完整的测试用例，并且从里面挑选需要做自动化的用例。
- 用例编写：先写结构，元素的 locator 可以两种方式处理： 2.1 待定，先留空。等开发的页面出来之后，补充上对应的 locator。这时候理论上用例就可以执行了。 2.2 如果做得细致一点，可开发沟通好每个主要元素的定义，比如 ID，name 或者是自己添加专门用来做自动化的自定义属性，比如 @testdataID 。只要开发和测试都把这些属性加完整，那么用例可以事先编写完整，等页面开发出来可以直接执行。
在实际场景下，尤其是快速迭代的产品，你很难在需求测试阶段就完全保证自动化建设跟上脚步，所以实操下来经常自动化是后置建设的，或者在需求测试之后在花一些时间来完善这样。
这样也是因为，不是所有需求都有自动化的必要，给一些时间再观察。
可以和 AI 结合一下。我们目前正在尝试 UI 自动化、前端开发、后端开发同步进行，当有了设计稿之后，就可以对着设计稿来进行开发了 UI 自动化了，结合 AI 生成自动化脚本，比如告诉他利用 playwright+pytest 实现 ，告诉他每一步的操作步骤，自动生成脚本，和前端约定好关键元素的定位 ID，替换元素定位即可
功能稳定的情况下才使用自动化测试进行回归，如果你要在功能实现初期，建议就接口自动化，问开发要一个接口文档，然后接口自动化覆盖 一遍，如果没问题了，等功能完成打包好，就基本是前端的问题了
楼主这个问题我考虑过，问题的根本是如何抢先在页面未完成之前先写好脚本。
你可以以一个个函数的形式去规定好路径，然后再在页面出来之后去补充函数里面的元素定位。
即做到流程与元素定位的分离，其实说白了就是那个 OP 模式。
再进一步，安卓，我其实有想过去维护一个自己的布局文件，按照自己的布局文件内的 ID 命名进行编写，等开发发布之后去进行替换 + 重新打包，自己测自己的包。
不过话最后说回来，这些都是刷绩效的方案而已，自动化本身的目的是回归，如果是真心喂了质量考虑的话，还是应该等项目上线之后再去进行脚本编写才是正道。