AI测试 AI 测试可以这样做么？

叉叉敌 for 成都测试圈 · 2021年11月09日 · 最后由陈恒捷回复于 2021年12月03日 · 3563 次阅读

背景

App 测试、H5、以及小程序测试，现在大部分程序都是千人前面，导致元素动态的变化，写出来的测试脚本不稳定。我想这也是为什么 WebUI 自动化难于落地，也是大家经常谈到的问题。

最近在做「XX 调研」项目，大部分是前端工作，用 playwright 来做了主流程的自动化回归测试，偶尔一些小的变化，功能优化等，不影响主流程元素定位，自动化用起来也非常的顺畅。

愿与事违，经常在调研题型里面，会有改动，导致元素定位不准确。自动化脚本自然就运行失败，维护起来成本颇高。

没有一个相对简单，一劳永逸的方法。

思考

自己想有没有办法用机器学习来完成，这个工作喃？

大致思路是：用 OCR 等算法，定位元素的位置、是什么组件、文字等，目前就三个属性，其他的属性目前还没有用到。

比如一个「单选题」按钮，输出的信息：(300，200)， button， "单选题"。

上面这样包含了：坐标、属性、文字。

坐标 : 用于自动化脚本执行，点击坐标位置；
属性：属性有对应一些方法，比如 radio，可以 selected、unelected 等；
文字：用于对用户写的用例，进行分析，这里考虑用 NLP 来实现，转化为自动化的用例；

人工用例-> NLP分析后的用例-> OCR定位-> 执行-> 报告

OCR 这一步相对比较简单，市面上之前也看到过类似的方法，可以实现。
难的是人工用例要求很高，因为每个人写用例思路，措辞都可能不一样，怎么实现从人工用例-> 自动化用例。

对于这个大家有没有什么建议或者意见哇？欢迎留言交流。谢谢

共收到 11 条回复时间点赞

陈恒捷 #3 · 2021年11月16日 3 个赞

先表达一个个人观点：OCR、NLP 个人觉得严格意义上不属于 AI ，我更偏向 AI=机器学习，而非 AI=算法。

然后，针对你这个维护成本问题，想先问几个点：

1、经常在调研题型里面，会有改动，导致元素定位不准确 ，这个改动是怎样的改动？非自动化的人工用例，对这些改动是怎么适配的？
2、你想核心解决的点，是元素变动后脚本可以做到无需人工维护自适应，还是从人工用例直接转换生成脚本？这两个点技术关注点是不一样的，前者关注的是元素识别的容错性，后者关注的是自然语言的语义识别。我看你前言是第一个，正文变成了第二个，没太看懂你的核心关注点是啥。

个人对于这种基于 NLP 生成脚本的，不是太感冒，核心原因是日常接触中，人工用例会写得非常详细，详细到达到 “是个人都能执行” 的并不多，大部分实际操作步骤都需要自行脑补或者问人。连人都无法准确判断的，NLP 就更难了。而且写得很详细的用例编写成本并不低（参考 BDD 写法的用例，详细到每个具体操作步骤了，但编写成本也高了很多），从投入产出比角度并不划算。

测试新人 #4 · 2021年11月17日

对

陈恒捷回复

OCR 和 NLP 很多都是通过机器学习训练过的，就算是吧。现在 AI 外延应该很大的，咱就不用纠结这个了。
不过维护成本的论述还是非常认可的，ROI 不高的，在组织内实施，肯定要找其他原因了。毕竟技术宅有时不用太考虑工程上的东西

叉叉敌 #2 · 2021年11月16日 Author

对

测试新人回复

方向对了，就干~

王稀饭 #5 · 2021年11月17日

3 楼恒捷的观点表示认可，首先需要明确到底是什么原因导致 元素动态的变化，写出来的测试脚本不稳定 ，如果这个点没调研清楚，那上面的想法不能否认没有价值，只能说有点自嗨。

另外，NLP 将人工用例转化为代码用例这一 part 是最不靠谱的，要实现这一点的前提是用例格式是统一规范的（要推动全部人遵循规范，这个成本已经劝退了），否则我觉得 NLP 再牛逼都实现不了。

所以很多时候，大家的思路更多是从降低编写 o 或维护用例的成本出发来做这个事，比如做一个用例编写的 ide，支持通过 UI 点击拖拽的方式快速编写用例、或者有更好的用例工程代码封装来达到最大复用等

叉叉敌 #6 · 2021年12月03日 Author

对

陈恒捷回复

非常感谢指点。

定位不准确。写好了自动化脚本，由于新加一个题型后，导致大部分的元素定位都需要修改 (目前没有找到好的定位方式)，这个应该是也是 webUI 的通病吧。
手动用例。基本上是场景类描述，没有太大的变化。
核心就是解决定位的问题，减少维护的工作。不好意思，这篇文章就是临时起意，写下了自己的一个想法。所以后一个 NLP 是自己想加的，因为在做储存的时候，发现用例超级详细，精确到按钮在什么位置。

期待对元素定位或者其他有没有什么好的建议，谢谢~