chrome mobile emulation 及周边漫谈和相关应用+想法

写在前面的一些废话

首先，感谢各位一直以来对我个人的帮助和支持，很久没有在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 webdrivermobile_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 webdriverfrom selenium.webdriver.chrome.options import Optionsmobile_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触屏版形态的展现非常主流（特别是一些互联网产品），掌握这些务实的技巧就显得很有必要。为此，我一直觉得：测试人员的思路只要稍微发散一些，可以带来无尽可能，不必钻牛角尖，最后得不偿失。

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

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'}}};vardriver = new webdriver.Builder().withCapabilities(capabilities).build();driver.get('http://taobao.com');

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

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

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

送梯子一把

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

最后才是广告

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

PS

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

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

来自 @思寒

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

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