背景
App 测试、H5、以及小程序测试，现在大部分程序都是千人前面，导致元素动态的变化，写出来的测试脚本不稳定。我想这也是为什么 WebUI 自动化难于落地，也是大家经常谈到的问题。
最近在做「XX 调研」项目，大部分是前端工作，用 playwright 来做了主流程的自动化回归测试，偶尔一些小的变化，功能优化等，不影响主流程元素定位，自动化用起来也非常的顺畅。
愿与事违，经常在调研题型里面，会有改动，导致元素定位不准确。自动化脚本自然就运行失败，维护起来成本颇高。
没有一个相对简单，一劳永逸的方法。
思考
自己想有没有办法用机器学习来完成，这个工作喃？
大致思路是：用 OCR 等算法，定位元素的位置、是什么组件、文字等，目前就三个属性，其他的属性目前还没有用到。
比如一个「单选题」按钮，输出的信息：(300，200)， button， "单选题"。
上面这样包含了：坐标、属性、文字。
- 坐标 : 用于自动化脚本执行，点击坐标位置；
- 属性：属性有对应一些方法，比如 radio，可以 selected、unelected 等；
- 文字：用于对用户写的用例，进行分析，这里考虑用
NLP来实现，转化为自动化的用例；
人工用例-> NLP分析后的用例-> OCR定位-> 执行-> 报告
OCR 这一步相对比较简单，市面上之前也看到过类似的方法，可以实现。
难的是人工用例要求很高，因为每个人写用例思路，措辞都可能不一样，怎么实现从人工用例-> 自动化用例。
对于这个大家有没有什么建议或者意见哇？欢迎留言交流。谢谢
这是想从需求一揽子生成测试报告的节奏呀。痛点的分段解决，这个最多算个方向了。
先表达一个个人观点：OCR、NLP 个人觉得严格意义上不属于 AI ，我更偏向 AI=机器学习，而非 AI=算法 。
然后，针对你这个维护成本问题，想先问几个点：
1、经常在调研题型里面，会有改动，导致元素定位不准确 ，这个改动是怎样的改动？非自动化的人工用例，对这些改动是怎么适配的？
2、你想核心解决的点，是元素变动后脚本可以做到无需人工维护自适应，还是从人工用例直接转换生成脚本？这两个点技术关注点是不一样的，前者关注的是元素识别的容错性，后者关注的是自然语言的语义识别。我看你前言是第一个，正文变成了第二个，没太看懂你的核心关注点是啥。
个人对于这种基于 NLP 生成脚本的，不是太感冒，核心原因是日常接触中，人工用例会写得非常详细，详细到达到 “是个人都能执行” 的并不多，大部分实际操作步骤都需要自行脑补或者问人。连人都无法准确判断的，NLP 就更难了。而且写得很详细的用例编写成本并不低（参考 BDD 写法的用例，详细到每个具体操作步骤了，但编写成本也高了很多），从投入产出比角度并不划算。
陈恒捷
回复
OCR 和 NLP 很多都是通过机器学习训练过的，就算是吧。现在 AI 外延应该很大的，咱就不用纠结这个了。
不过维护成本的论述还是非常认可的，ROI 不高的，在组织内实施，肯定要找其他原因了。毕竟技术宅有时不用太考虑工程上的东西
3 楼恒捷的观点表示认可，首先需要明确到底是什么原因导致 元素动态的变化，写出来的测试脚本不稳定 ，如果这个点没调研清楚，那上面的想法不能否认没有价值，只能说有点自嗨。
另外，NLP 将人工用例转化为代码用例这一 part 是最不靠谱的，要实现这一点的前提是用例格式是统一规范的（要推动全部人遵循规范，这个成本已经劝退了），否则我觉得 NLP 再牛逼都实现不了。
所以很多时候，大家的思路更多是从降低 编写 o 或维护用例的成本 出发来做这个事，比如做一个用例编写的 ide，支持通过 UI 点击拖拽的方式快速编写用例、或者有更好的用例工程代码封装来达到最大复用等
陈恒捷
回复
非常感谢指点。
- 定位不准确。写好了自动化脚本，由于新加一个题型后，导致大部分的元素定位都需要修改 (目前没有找到好的定位方式)，这个应该是也是 webUI 的通病吧。
- 手动用例。基本上是场景类描述，没有太大的变化。
- 核心就是解决定位的问题，减少维护的工作。不好意思，这篇文章就是临时起意，写下了自己的一个想法。所以后一个 NLP 是自己想加的，因为在做储存的时候，发现用例超级详细，精确到按钮在什么位置。
期待对元素定位或者其他有没有什么好的建议，谢谢~
40岁的测试小学生
回复
谢谢~
文中图的左边确实很难实现，而且 ROI 也不高，甚至可以说是无。
右边的话，价值 (只要能通过 OCR 识别到元素是什么：button、hyperlink、img...) 还是可以的，目前进度来看，是可以实现的。
叉叉敌
回复
第一个点，能举个带有具体代码（你的自动化脚本 + 网页的 html 代码）的例子么？
新加一个题型，会导致大部分元素定位都要改，只能看出你的定位方法对新增题型自适应能力比较差，但看不出具体是啥原因、可以怎么优化。
叉叉敌
回复
插一句，都详细到这程度了，与其用无法保障百分百准确且需要高成本建模的 NLP，不如直接用 BDD 呗？比如 calabash 这类 bdd 框架写出来的用例，本身就比较接近自然语言，且确保了可直接运行。