问答 有关 h5 自动化进行 “功能测试”、“性能测试”、“兼容性测试” 的问题

南山老人i · 2022年07月25日 · 最后由 陈恒捷 回复于 2022年08月01日 · 8937 次阅读

各位大佬我有一个关于 h5 自动化的问题:
问题描述如下:
1、针对 h5 自动化测试的时候,大家是如何进行 “驱动” 的。使用浏览器驱动直接转到 web 端自动化?还是说使用原本的 app,在此之外进入一些需要测试的 h5 应用中。(因为面向的 h5 应用不一样,有些 h5 应用在 web 端无法打开,有些 h5 应用用浏览器打开的时候会无法加载一些用户 SDK,相当于无法使用。也就是说,用浏览器驱动直接转到 web 自动化的话,会有一部分限制)
2、针对兼容性测试有一个问题:我需不需要针对多浏览器内核进行测试兼容性,需不需要针对手机浏览器内核进行测试,需不需要针对一些微信/支付宝进行一些应用测试(挺迷茫的)
3、针对性能测试:假设现在用浏览器进行驱动,那能拿到的一些自动化性能数据的偏重点,可能就是响应速度等等,这些预想之中确实有手段去拿到,但是在这之外,我还可以输出些什么。
4、针对 h5“自动化”“功能测试”,由于本人对 web 端了解较少,web 端上有没有类似 Fastbot 的智能遍历工具(有最好,无则自己写一个瞎点也是可以的)
求教!!!!!!!!!

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 5 条回复 时间 点赞

1、先确定好你的测试目标,系统在实际的使用情况内是什么样子的,一般 H5 多应用于在移动端,那就考虑好移动端的测试范围,要兼容哪些移动端的机型/浏览器等。
2、一般做某种测试还是要先考虑好,你做这类测试是为了满足那个需求,如没需求则调研需求,不然就没法确保好你的测试目标。

  1. 如果是可以直接在浏览器运行的,可以直接用 selenium,结合 Chrome option 设置需要覆盖的浏览器分辨率比例作为模拟。
  2. 如果需要在 APP 里面运行,可以参考 appium,结合 native 与 hybird 的切换。

1、针对 h5 自动化测试的时候,大家是如何进行 “驱动” 的。使用浏览器驱动直接转到 web 端自动化?还是说使用原本的 app,在此之外进入一些需要测试的 h5 应用中。(因为面向的 h5 应用不一样,有些 h5 应用在 web 端无法打开,有些 h5 应用用浏览器打开的时候会无法加载一些用户 SDK,相当于无法使用。也就是说,用浏览器驱动直接转到 web 自动化的话,会有一部分限制)

一般根据实际使用场景来驱动,比如这个 h5 设计是放在 app 里用的,那就用 app 去启动。放在浏览器里用的,那就用浏览器去启动。

2、针对兼容性测试有一个问题:我需不需要针对多浏览器内核进行测试兼容性,需不需要针对手机浏览器内核进行测试,需不需要针对一些微信/支付宝进行一些应用测试(挺迷茫的)

这个看用户使用场景和线上问题情况。相对来说,h5 标准已经比较细,各家浏览器的实现差异已经没有以前 ie 和其他浏览器那么大了,只要不调用一些相对偏门或者特别新的 js api ,一般不怎么会有兼容问题。倒是不同 app 内置的 webview ,提供的调用 app 功能 api 差异比较大(比如调起微信的支付,和调起支付宝的支付,api 是不一样的,但界面按钮大概率是同一个),这块如果有涉及,最好验证下。

3、针对性能测试:假设现在用浏览器进行驱动,那能拿到的一些自动化性能数据的偏重点,可能就是响应速度等等,这些预想之中确实有手段去拿到,但是在这之外,我还可以输出些什么。

我一直觉得,如果你功能测试的时候没太感觉性能有很大问题,暂时可以先不用特别关注性能。先把前面兼容性这些搞好吧。真要搞,包括接口响应速度、界面帧率、白屏时间等都需要测试,还挺多的,这些通过 chrome 浏览器的开发者工具,大部分都可以捕获到。

4、针对 h5“自动化”“功能测试”,由于本人对 web 端了解较少,web 端上有没有类似 Fastbot 的智能遍历工具(有最好,无则自己写一个瞎点也是可以的)

fastbot 本身也支持遍历 app 内的 webview 吧,只要控件树能拿到里面的内容就可以支持。只是 web 端出问题不如 app 出问题直接 crash 那么明显且容易捕获,更多只是 js 报错,界面无响应而已,所以反而需要下功夫的是怎么捕获错误。不过确实没怎么见到有 web 端的智能遍历工具,可能是因为更新非常容易,所以质量要求没有 app 那么高?

实时更进这些天的进度与设计思想:
暂时设计有四种模式并选择了模式三:
1、web 上打开这个链接
2、手机浏览器打开这个链接
3、app 套壳打开链接

4、用对应应用打开

利弊排除法分析:
1、四种方式,首先排除方案四,因为我这边还有一个需求就是对应用进行自动化稳定性测试,类似在应用里跑 monkey,而且方案四太重,总不能测 url 的时候输入一个 url 一个应用包
2、然后排除方案一的原因:
a、有的应用没法在 web 上使用,拿微信举个例子,人家会提示你请在手机上打开
b、如果我这个 h5 里面需要拍照,那就需要唤起手机系统的照相机权限,web 上直接歇逼
c、内核有一丝丝区别,web 上 chromedriver 内核或者其他,app 上的真实环境是用 webview 渲染的,虽然说 app 是 web 挪过去的,但是多少有点场景不同。会对内核的功能进行一些阉割或者增加

南山老人i 回复

有点没太明白,为何会需要选择和排除其中一些方案呢?

如果是设计框架,想要通用性尽量强,那 4 个都得支持。
如果是业务项目的测试方案制定,那正常需求里就明确了需要支持的用户场景是什么,对应选择测试就行。

这 4 个场景,个人理解核心的差异:

1、web 打开和手机打开:内核的少许差异带来的渲染或特殊 api 调用差异 + 屏幕大小差异带来的布局改变 + 触屏和鼠标/键盘交互的差异(比如按钮要大一些之类的)。布局差异一般是大头,不过随着响应式布局的流行,不大复杂的网页一般都可以自动适配。

2、手机浏览器打开和 app webview 打开(你可以理解为 3 里面的套壳):内核的少许差异带来的渲染或特殊 api 调用差异(webview 用的内核一般是系统自带/app 自带,和手机浏览器自带的内核一般会有一些差异,但因为总体 h5 标准还是比较清晰的,所以差异一般不至于很大)+ app 额外提供的 api 差异(比如有的网页为何要求必须微信打开,就是因为要调用微信的特定 api ,比如获取用户信息 api 等)。api 差异一般是大头,这个只能用指定 app 打开解决,自己随便弄的套壳 app 也不会有这类 api 的。

南山老人i 关闭了讨论 11月07日 11:54
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册