自动化工具 用了那么多 UI 自动化框架,为什么没有人尝试直接用 js 来做呢?

Karaser · 2019年04月25日 · 最后由 simonpatrick 回复于 2019年04月29日 · 2091 次阅读

直接把脚本注入在平台上面,异步跑就好了呀,最近在做 Vue 的项目,感觉这个想法很容易可以实现呀。

共收到 24 条回复 时间 点赞

个人觉得这个做法是可行的.
https://www.cypress.io/ 这个 UI 测试的,其实用在本机测试使用 Mock 会有比较好的效果.

我自己个人的感受,看了 angular 或者 vue 这种 model 和 view 自动绑定的前端,其实在运行层上面完全可以进行 model 和 view 绑定。
上面有点玄乎,举个例子来说:

  1. 页面的某个输入框 model 的名字是 name, 那么你的测试数据里面如果有一个属性也是 name, 那么默认应该就是这个属性 name 的值就应该输入到这个 model 名字是 name 的框中
  2. 大部分控件的默认操作就一种,输入框就是 input
  3. 结合以上两点,在运行 UI 测试的时候也可以做到 model 和 view 绑定,已 java 为例子,给一个对象实例,他有变量名,有变量的值, 通过这个变量名可以找到这个变量名在 page 中定义的定位元素,就可以直接操作了, 最后的测试用例其实就是变成类似:
login(String processNameList<Pages> pages, TestData data)

这个样子了. data 中包含所有需要测试的数据,变量名自动到 Page 里面去寻找这个流程需要的页面元素,selenium 里面的常用操作都可以在写测试用例的时候都需要知道,只要知道数据是什么就可以了。

可以参考老帖子: https://testerhome.com/topics/2788
这个就是当时看了 angular 想到的, 甚至通过解析页面元素 model 这样的东西,可以把生成一部分 PageObject 类。然后在反射关联页面的 model 和测试的数据,页面,定位,数据都可以分开,model 对业务系统来说是稳定的,页面元素变来变去,只要改 pageobject 就可以,页面操作什么都可以不用改,因为大部分都使用默认操作,默认操作封装在框架就好。

最后只能说没有什么用,因为其实大部分的测试越封装,效果就越不好,太多的概念分层都不如直接写 selenium 原生的 api 好用,什么稳定不稳定,自己没试过怎么有感受内,类似于在 json 对象里面找一个元素,如果在学习了一段时间后,还是要花很长时间才会用,什么框架都不管用。

具体的是可以参考: https://github.com/ideasfortester/mixed-first

还有一点其实个人觉得如果有类似于的埋点系统的话,完全可以把页面操作的所有动作都记录下来,直接通过埋点系统来完成录制回放。不过不好的地方就是这些都变成开发的事情了, 要测试做什么。 所以我也被 fire 了。 嗨找工作真难!

程航 回复

跨域机制是浏览器的不是 JS 的噢。另外你可能理解错了,在本应用里面测试是不需要跨域的,最多只是在本应用的同源不同路由而已。如果确实有跨域的验证需求,现在 HTTP,JS,Nginx 都有解决方案的~

因为 JS 的安全机制,不允许跨域访问资源,selenium 可以绕过这个安全机制。https://www.douban.com/note/201511627/

那跟 mock 没区别啊

cypress

Karaser 回复

实现上是没啥不可行的,但是你要考虑,会不会因为你的测试代码侵入导致被测应用的正确性问题

期待 demo 出来,浏览器测试是可以按这个思路的

槽神 回复

没有啥是肯定不行的,试试才知道😁

陈恒捷 回复

好,有空弄出来和大家分享。

建议楼主做个 demo 出来分享下,这样讨论起来也更具体?

用 vue 测试 vue 页面势必会有侵入,如果侵入肯定是不行的,除非你是工具性、框架性的小产品的测试
楼主可以看下 puppeteer,也是纯 js 的

你可以百度下为什么 selenium 弃用 js 而是用 webdriver

Karaser 回复

现实是有点规模的公司,测试都是独立团队。很难反向推动开发为了测试而去动代码结构,也不会让测试有权限动代码,毕竟能力参差不齐,能做的是从测试自己的角色出发,去做更多的扩展测试。

81—1 回复

我觉得是大家被耦合都搞怕了,什么框架都是为了解耦感觉有点盲目呢,解耦的缺点很明显的摆在了面前,咱们不能为了解耦而解耦吧~

simple 回复

提倡的发展方向不是将测试融入开发吗?弱化测试团队的概念。我觉得 UI 自动化就能当做前端的单元测试来看来,也挺好的。

jest 也能做 UI 验证,但是成本高,并且耦合,最终放弃。

最老的 selenium 就是用的 js 后来吸收了 webdriver 才改成现在的模式

不是有类似的工具吗, cypress

Karaser 回复

个人认为这种跟项目代码强耦合的做法是不值得提倡的。

simple 回复

我觉得是不一样的
1、selenium 使用一个其他语言再调用浏览器驱动,在注入 js 代码的方式,效率应该是被诟病最多的问题,也是因为中间有一个驱动,所以几个操作需要多次的访问,特别是查找元素和等待,呆呆坐在电脑面前的各位应该体验过吧。
2、是数据问题,也是定位元素这个 UI 最根本的问题,在用 selenium 的时候使用是通过元素路径或者元素层级关系定位的,但是如果结合现在前端框架使用数据驱动,双向绑定的特性,我觉得定位到一个元素的位置比路径的方式好太多了。
3、兼容问题,依赖于 selenium 版本和浏览器 driver 的版本,让测试组疏通版本问题就一直很费劲,我觉得直接用原生 js,直接写在项目里面,在项目里面开一个路由的方式,会好很多吧。

simple 回复

贴主说 直接使用

楼主你觉得 selenium 是怎么操作页面的呢?

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