移动测试基础 chrome mobile emulation 及周边漫谈和相关应用+想法

Archer_小A · December 15, 2014 · Last by anita replied at November 21, 2015 · 3050 hits
本帖已被设为精华帖!

写在前面的一些废话

首先,感谢各位一直以来对我个人的帮助和支持,很久没有在Testerhome发一弹技术帖了,最近总给人一种不务正业的感觉......大家都知道我目前已经转向苦逼的前端开发,在这个转变的过程中,我个人对移动端的一些测试形态有了一些新想法,今天就来聊聊如题所说的这些事儿。

以下一些实例中涉及到了我目前所在公司的网站及其产品,确实有广告嫌疑,但是产品的h5端是由我本人开发,所以我觉得我暂时找不到更合适的例子了......

首先还是来谈谈chrome mobile emulation

OK,我还是先来聊聊chrome的mobile emulation,其实做前端开发的童鞋应该都知道他在chrome里的位置,比较害羞,比较隐蔽,而且只有在chrome 32之上的版本才能看到她,现在越来越强大了,他最直观的作用是模拟各种主流移动设备及其相关参数:通用尺寸,pixelRatio设备像素比(这也是一个大话题,暂时不用关注)等,举一个最简单的例子,当你直接打开某网站的时候默认看到的是pc版:

但是,众所周知的原因,现在几乎所有的主流网站都会配备一个移动设备适配版,一般称之为“触屏版”,技术上采用html5开发,其实今天我们需要解决的主要问题就是如何来测试这种形态下产品的兼容性以及如何自动化。

一切从我们按下著名的F12键开始......

注意左上角类似手机的图标,当这个图标激活之后,我们将看到我们的"触屏版"在不同设备下的表现:

大家可以试着打开淘宝网简单地体验一下。
我们可以看到,它可以模拟出当前的一些主流设备,从手机到平板,应有尽有,连我们最近的土豪6plus都赫然在列:

值得一提的是,它还有一些令人兴奋的调试参数,比如右上角可以模拟网络类型,这无论对于研发还是测试来说都是不可多得的好工具:

当你调节完你所需要的所有场景参数时,你就可以慢慢体验了,说再多也抵不过一张动态图:

ps:在emulation中,所有的移动端touch事件将开始生效,也就是说,前端开发人员所写的一些只为适配移动设备的事件在这里可以完美运行。

从测试角度而言,我们可以利用它做什么?

从手工测试角度来说,这款工具无疑给我们带来了很多好处。不必再次强调之。
从自动化角度来说,chrome emulation能为我们带来遐想空间,并驱动我们去实现它。

从价值来说,利用chrome emulation,我们可以做到web产品"触屏版"在各个主流设备及相关浏览器下的表现能力,并利用持续集成平台完成这个伟大的目标。

how do?

要完成这样的一个自动化,我们首先不该沉溺在一些老的资料里,而是应该多关注官方的一些文档。不用担心找不到,因为一旦有了想法,这些资料自然会被你挖掘到,看你想不想......这不,我在ChromeDriver website上,找到了这样一个官方说明:

在chromedriver >= 2.11的release版本中才开始加入对这一特性的支持。注意:最新的chromedriver的release版本号为2.13,这也意味着,这个特性刚支持不久,各位可以尽情发挥。

链接:https://sites.google.com/a/chromium.org/chromedriver/mobile-emulation

Mobile Emulation
Chrome allows users to emulate Chrome on a mobile device (e.g. a “Google Nexus 7” tablet, or an “Apple iPhone 5”) from the desktop version of Chrome, by enabling the Mobile Emulation feature in Chrome DevTools. This feature speeds up web development, allows developers to quickly test how a website will render in a mobile device, without requiring a real device. ChromeDriver can also enable Mobile Emulation, via the “mobileEmulation” capability, specified with a dictionary value.

Just as in the DevTools Emulation panel, there are two ways in ChromeDriver to enable Mobile Emulation: by specifying a known device, or by specifying individual device attributes. The format of the “mobileEmulation” dictionary depends on which method is desired.
Specifying a Known Mobile Device
To enable Mobile Emulation with a specific device name, the “mobileEmulation” dictionary must contain a “deviceName.” Use a valid device name from the DevTools Emulation panel as the value for “deviceName.”

真是令人兴奋的一段描述,官方还给出了两个example,这里我只以python为例讲解:

直接模拟一个已存在的主流设备

from selenium import webdriver
mobile_emulation = { "deviceName": "Google Nexus 5" }
chrome_options = webdriver.ChromeOptions() # ChromeOptions实例,也算非常常用的一个类了。
chrome_options.add_experimental_option("mobileEmulation", mobile_emulation)
driver = webdriver.Remote(command_executor='http://127.0.0.1:4444/wd/hub',
desired_capabilities = chrome_options.to_capabilities())

完全自定义一个带参数的设备

当我们需要模拟一些通用参数或者不存在的设备浏览器类型时,可以采用这种高度自定义的方法:

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
mobile_emulation = {
"deviceMetrics": {"width": 360, "height": 640, "pixelRatio": 3.0}, # 定义设备高宽,像素比
"userAgent": "Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) " # 通过ua来模拟
"AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19"}

chrome_options = Options()
chrome_options.add_experimental_option("mobileEmulation", mobile_emulation)
driver = webdriver.Chrome(chrome_options = chrome_options)

driver.get("http://www.taobao.com")

我们运行起来看看,It works!

到这里,我们顺利地通过chrome driver拉起了一个触屏版demo,这个例子中,需要强调的是UA参数。

在主流的前端开发技术中,为了适配各种第三方移动端浏览器,一般都是通过其特定的UA头来进行判断的,通过UA头再给出对应容器下的展现。这也意味着,我们使用这种方法,可以模拟我们的产品在微信/UC浏览器/QQ手机浏览器等国产环境下的表现......

总结与想法

目前而言,web触屏版形态的展现非常主流(特别是一些互联网产品),掌握这些务实的技巧就显得很有必要。为此,我一直觉得:测试人员的思路只要稍微发散一些,可以带来无尽可能,不必钻牛角尖,最后得不偿失。

推荐的发散思路、工具等

下面是一些想法,工具,有兴趣的同学可以自行往下研究。

首先,我觉得了解web触屏版开发中,那些为了支持移动设备特性,前端开发人员常用的基础技巧很重要。
其次:

  1. 适当了解一下ua,js针对移动设备的主流事件,webkit独有的一些特性,了解常用移动端浏览器引擎(通常指渲染引擎)
  2. 最大化节约测试成本是得到自动化成果的最务实手段。
  3. 了解PhantomJS等工具,了解webkit的自动化测试的特点。
  4. 了解一些常用的前端debug工具和远程调试工具(weinre等)
  5. 时刻关注自动化主流工具/技术的最新版本和最新官方资讯(极为重要,对一些特性猜测保持技术敏感)
  6. 当然,我始终认为,第五点是建立在有把梯子的基础上的......
  7. 适当了解一些性能测试的思路和意识,而不仅仅总是那几款工具(lr,jmeter)

可以戳我在SegmentFault上的一篇帖子:
《前端测试自动化工具 + 页面性能分析工具 BerserkJS 试用小记》
http://segmentfault.com/blog/diggerplus/1190000000695819

解答一些群里有人问我的问题

Q: 移动端/web自动化的client能否用javascript编写?

A:了解一下Node.js,npm包中有selenium webdriver的模块,上述的例子用js写,大概长这样:

var webdriver = require('selenium-webdriver');
var capabilities = {
browserName: 'chrome',
chromeOptions: {
mobileEmulation: {
deviceName: 'Apple iPhone 5'
}
}
};
var
driver = new webdriver
.Builder()
.withCapabilities(capabilities)
.build();

driver.get('http://taobao.com');

至于appium,npm里躺着的就更多了,但是多数是服务端。

Q: 提问者自认为小白的一些问题

A: 这个,我个人建议去看我的另外一篇帖子《重拾提问的艺术》,不装逼地讲,这篇文章我认为逼格还是可以的,而且务实。

送梯子一把

作为一名长期技术工作者,梯子已经成为了一个必备工具,之前我可能还会推荐朋友使用wallproxy之类的开源项目,不过gae的速度简直......所以我决定隆重推荐国内的一个***产品,想要了解的同学可以戳我的邀请链接:
http://findtizi.com/?r=97d149bebfb3f3f8

最后才是广告

我的全新个人博客 http://xiaoa.name 悄然上线了,虽然文章目前都是假的,功能还在完善中......
托管在国内的gitcafe,代码同步在gitcafe和github,欢迎交流。

PS

这个帖子总共经历我几块牛排,一碗鱼汤,一碗蛋炒饭,几颗草莓的时间,所以,我认为信息量还是可以的。
语句不通顺之处可以指出,我会持续更新和优化。

补刀内容赏析,欢迎热烈讨论。

来自 @思寒

我这边补刀下.
优点

  1. 这个方法基于chrome, 可以便捷的识别跨尺寸的兼容问题. 简直就可以分分钟帮企业做个自动化服务了.
  2. 获取响应速度的瀑布流图也非常的容易. 很容易做性能测试和瓶颈分析

缺点

  1. 方法基于chrome引擎, 考虑到不同浏览器的版本, 以及不同设备上浏览器引擎差异, 所以有些css的兼容性问题仍然需要验证. 所以尺寸兼容性可以解决, 但是设备的兼容性测试仍然需要做. 好消息是大部分企业的h5一般都是布局不合理占多数.
共收到 21 条回复 时间 点赞

写的太赞了. 赶紧占住广告位.

我这边补刀下.
优点

  1. 这个方法基于chrome, 可以便捷的识别跨尺寸的兼容问题. 简直就可以分分钟帮企业做个自动化服务了.
  2. 获取响应速度的瀑布流图也非常的容易. 很容易做性能测试和瓶颈分析

缺点

  1. 方法基于chrome引擎, 考虑到不同浏览器的版本, 以及不同设备上浏览器引擎差异, 所以有些css的兼容性问题仍然需要验证. 所以尺寸兼容性可以解决, 但是设备的兼容性测试仍然需要做. 好消息是大部分企业的h5一般都是布局不合理占多数.

#1楼 @seveniruby 思寒说的没错,h5在各种内核下的表现实在太多坑,不过另一个好消息是,国内主流都是webkit

#1楼 @seveniruby 我把你补刀内容放到帖子里

这种技术可以实现原生app自动化测试?

#4楼 @tspring 正如我在文中提到的适用场景,其比较适合用于h5端移动web网站的测试,原生app的自动化测试是无法胜任的。

digger plus还继续维护吗?

#5楼 @qddegtya 那你哪些自动化脚本是用webdriver实现的还是jQuery写的?

这个我也研究过一阵子,我对比过真实设备和用chrome模拟该设备时的差异,很多地方页面的表现还是存在较大差异的..如果实现目的对UI本身相关内容关注度比较高的话,估计要做进一步考虑

支持楼主,还真没发现这个功能。。。。

#6楼 @ansonwoo 当然,不过今年更新力度很小,团队内部考虑上线全新版本

#8楼 @tobytang 拿这个跟真实设备比是不现实的,只能说,可以利用这种方法或者思路来获取必要价值

print "nb"

有这个工具,仅限于web移动端的自动化测试,就不需要再重新学习appium啦,_^ ,直接使用selenium的环境,操作web页面的元素就OK。

#12楼 @xie_0723 具体问题具体分析,仅此而已。这样,我们能够始终覆盖产品测试的方方面面

#12楼 @xie_0723 这个点赞方式我喜欢. 可以在论坛提倡. 纯web app的测试, 可以不用appium了. 这种方式更轻量级.

#14楼 @seveniruby 透过现象看本质,往往能让测试少走很多弯路。

#15楼 @qddegtya 是的, 有很多工作其实用逻辑思维, 可以避免的.

终于抽时间细读了啊。
强赞。
最近对于周期非常短的专题类型的触屏应用的兼容行测试非常头疼..

#17楼 @anikikun 就是那一堆堆运营页面,如今,single page遍地,继续深入研究,还会有更多干货产出。

@qddegtya 强赞!!
但现在有一类h5是内嵌在app应用里的,并且js方法还是由app传进去的,这种情况应该很难用这种方法实现吧,只能用appium。

#19楼 @yangeren 俗称Hybrid,app里的页面要想获得原生能力就要由原生app往webview里注入一段js

如何用selenium在chrome模拟触屏操作?

恒温 Appium 中 iOS 下的 Hybrid 中提及了此贴 26 Sep 11:27
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up