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

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

背景

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

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

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

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

思考

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

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

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

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

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

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

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

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

共收到 11 条回复 时间 点赞

这是想从需求一揽子生成测试报告的节奏呀。痛点的分段解决,这个最多算个方向了。

测试新人 回复

方向对了, 就干~

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

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

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

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

陈恒捷 回复

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

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

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

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

陈恒捷 回复

非常感谢指点。

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

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

测试新人 回复

谢谢~

文中图的左边确实很难实现,而且 ROI 也不高,甚至可以说是无。
右边的话,价值 (只要能通过 OCR 识别到元素是什么:button、hyperlink、img...) 还是可以的,目前进度来看,是可以实现的。

叉叉敌 回复

第一个点,能举个带有具体代码(你的自动化脚本 + 网页的 html 代码)的例子么?

新加一个题型,会导致大部分元素定位都要改,只能看出你的定位方法对新增题型自适应能力比较差,但看不出具体是啥原因、可以怎么优化。

王稀饭 回复

感谢建议~

对于敏捷团队,NLP 确实行不通,如果是类似金融、存储之类的,亦或是测试用例非常详细的,还是可以考虑下喃?

叉叉敌 回复

上定位代码,上 dom 结构😎

叉叉敌 回复

插一句,都详细到这程度了,与其用无法保障百分百准确且需要高成本建模的 NLP,不如直接用 BDD 呗?比如 calabash 这类 bdd 框架写出来的用例,本身就比较接近自然语言,且确保了可直接运行。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册