全面拥抱移动测试，Mobile JSON Wire Protocol Specification文档翻译

Selenium3已经宣布不支持移动化测试。对于老牌测试工具selenium来说这是以退为进，因为移动自动化测试工具的标准还在selenium团队手上。

本文轻度翻译了这个标准，看得懂的人不用翻译也能看懂，看不懂的人翻的天花乱坠也是一头雾水。

注意，这个规格是给工具的开发者定义的条条框框，对于使用者来说，只要知道哪些是必须工具必须支持的，且支持的细节是什么就可以了，其他可以不去深究。

这个标题就不翻译了


Mobile JSON Wire Protocol Specification


源地址

DRAFT草稿(注意，这是草稿，也就是说会变的)


Introduction简介

下面这段的大意是以前的JsonWireProtocol现在需要进行扩展了。因为要支持移动化了。

This specification is designed to extend the JSON
Wire
Protocol (JSONWP),
a W3C working draft for web browser
automation. The JSONWP has been greatly
successful for that purpose. The need
for automation of native and hybrid
mobile applications can be met by the
extension of the JSONWP, which already
has a proven basic automation
framework (architecture, interaction model,
etc...).

最初的版本是由下面一群牛人在Mozilla的办公室里捣鼓出来的。

The initial details of this specification were worked out at a series
of
meetings held in Mozilla‘s offices in London in August of 2013.
The
participants were:


Sessions 会话

跟webdriver一样，POST
/session这个URI，然后server给你返回一个sessionId。
然后通过这个sessionId，你可以得寸进尺，为所欲为。

如果server没办法start session，那么返回的状态码是500。

Session通过DELETE /session/:id这个URI进行销毁，跟webdriver一样。

下面一段是关于AUT的，有兴趣自研。

Sessions work just like WebDriver: you POST to /session and receive a
sessionId
as a response if the server can give you one, at which point you
can send
further automation commands. If the server can‘t start a session,
for example
if another session is running and only one session can be handled
at a time,
the server must return the appropriate 500 response. Sessions are
ended with
a DELETE to /session/:id as per the original WebDriver spec.

The server may but is not required to launch the AUT or a device/simulator
in
the process of creating a session. It may but is not required to perform
some
kind of cleaning or resetting of the AUT in order to provide a clean
test
environment. It may but is not required to stop the running AUT at the
session
end. It may but is not required to remove the AUT from the device or
otherwise
reset the device state after the session is complete. In general,
it is the
responsibility of the user to manage the test environment; it is
not a part of
this specification. But a server conforming to this
specification may by other
means provide that functionality as a
convenience.

Desired Capabilities 不知道怎么翻，反正就是做配置的

有一些新的key了

  • automationName:
    用来指定测试工具，是 appium呢？还是 ios-driver或者是 selendroid

  • platformName: 测试平台。
    e.g., Android, iOS

  • platformVersion: 平台版本 e.g., 4.3 (for
    Android) or 6.1 (for iOS)

  • deviceName: 测试设备名称，要有版本信息的。, e.g., Nexus
    4    , iPhone 4S, iPhone
    Simulator    ,iPad Mini

  • app (可选): AUT的路径或者是uri

  • browserName (可选): 浏览器，其实就是webdriver的session,
    e.g., Safari, Chrome

New desired capability keys:

  • automationName: specific automation tool,
    e.g., appium, ios-driver, selendroid

  • platformName: platform to automate,
    e.g., Android, iOS

  • platformVersion: platform version
    e.g., 4.3 (for Android)
    or 6.1 (for iOS)

  • deviceName: specific device names including version
    information, e.g., Nexus 4, iPhone
    4S    , iPhone Simulator, iPad
    Mini

  • app (optional): path or uri to AUT

  • browserName (optional): web browser to automate as a
    webdriver session,
    e.g., Safari, Chrome

Locator Strategies 新的定位策略，重点

非HTML平台，下面的这些策略是需要支持的。

  • class name:就是个字符串，其实就是SDK里控件的类名。注意，android里要带包名的。,
    e.g.,UIAPickerWheel for iOS
    or android.widget.Button for Android
    • 这些应该完全匹配由基础自动化框架提供的类名(via google翻译)

  • accessibility id: 就是代表元素可访问的id或者是label的字符串。, e.g., for iOS
    the accessibility identifier and for Android the content-description

  • xpath: 老熟人了，不罗嗦

The following locator strategies must be supported for non-HTML-based
platforms:

  • class name: a string representing the UI element type for a
    given platform, e.g., UIAPickerWheel for iOS
    or android.widget.Button for Android
    • These should exactly match the class names given by the underlying
      automation frameworks

  • accessibility id: a string representing the accessibility id
    or label attached to a given element, e.g., for iOS the accessibility
    identifier and for Android the content-description

  • xpath: a valid xpath string applied to the XML document that
    would be retrieved using the page source command

下面这些是可选的，也就是说想支持就支持，不想就算了

The following locator strategies may be supported, depending on the
automation
platform:

  • id: 字符串，代表对象的resource ID

  • -android uiautomator: 字符串，就是 UiAutomator的定位符 (Android only)
    • TODO: 具体描述一下

  • -ios uiautomation: 字符串，也就是 UIAutomation 的定位符 (iOS-only)

  • TODO: 指出server是否需要指明其支持这些策略。

如果是用webdriver的模式或者是使用了HTML的平台，那么需要支持webdriver的定位策略。不罗嗦。

  • id: a string corresponding to a resource ID

  • -android uiautomator: a string corresponding to a recursive
    element search using the UiAutomator library (Android only)
    • TODO: specify this

  • -ios uiautomation: a string corresponding to a recursive
    element search using the UIAutomation library (iOS-only)

  • TODO: figure out whether server should report support of these
    strategies

If automating a mobile browser in WebDriver mode, or a platform that uses
HTML
as its element hierarchy, the usual array of WebDriver commands must
be
supported instead, with their usual semantics.

Page Source 页面源码，真牵强

所有的平台必须支持GET source命令。返回代表其UI层级的xml(html)。

其他的不翻了。

All platforms must respond to the GET source command
with an XML (or HTML in
the case of HTML-based platforms) document
representing the UI hierarchy. The
precise structure of the document may
differ from platform to platform. Schemas
that must be followed for iOS and
Android automation are as follows:

TODO: get together schemas for UIAutomation (iOS), Instruments (Android),
and
UiAutomator (Android).

The elements in these documents may be augmented with such attributes as,
for
example, ids, in order to support internal behaviors.

Touch Gestures 触摸手势

所有平台都要支持Mozila提出的Multi-Action API（这个谁能告诉我怎么翻），在一些情况下如果无法支持，直接返回500.

All platforms must adopt the Multi-Action API pioneered by Mozilla. In
some
cases it will not be possible to support the full range of gestures
potentially
described by this API on a given platform. In this case, the
platform should
respond with a 500 when it cannot faithfully render the
requested gesture.

TODO: show what the gestures API actually looks like in terms of
server
endpoints that must be supported.

Device Modes 设备模式

设备有很多的网络连接状态，为了能够精准控制，我们提供了下面的endpoints。

  • GET /session/:sessionid/network_connection
    • 返回 ConnectionType

  • POST /session/:sessionid/network_connection
    • 接受一个 ConnectionType

    • 返回 ConnectionType

Remote端必须相应"networkConnectionEnabled"这个capability。

其他的自己看。

Devices have various states of network connectivity. In order to
control
those states we have the following endpoints:

  • GET /session/:sessionid/network_connection
    • returns ConnectionType

  • POST /session/:sessionid/network_connection
    • accepts a ConnectionType

    • returns ConnectionType

Setting the network connection in the POST returns the ConnectionType
because
the device might not be capable of the network connection type
requested.

The remote end MUST reply with the capability "networkConnectionEnabled"

ConnectionType - 连接类型

这里是指定了具体的值，可以不用理解。

Value (Alias) | Data | Wifi | Airplane Mode

1 (Airplane Mode) | 0 | 0 | 1
6 (All network on) | 1 | 1 | 0
4 (Data
only) | 1 | 0 | 0
2 (Wifi only) | 0 | 1 | 0
0 (None) | 0 | 0 | 0

如果是飞行模式，那么就返回:

{ "name": "network_connection", "parameters": { "type": 1 } }

以后将支持更多的类型，比如3G，4G，LTE。

Is a bit mask that should be translated to an integer value when
serialized.

Value (Alias) | Data | Wifi | Airplane Mode

1 (Airplane Mode) | 0 | 0 | 1
6 (All network on) | 1 | 1 | 0
4 (Data
only) | 1 | 0 | 0
2 (Wifi only) | 0 | 1 | 0
0 (None) | 0 | 0 | 0

Example payload for setting "Airplane Mode":

{ "name": "network_connection", "parameters": { "type": 1 } }

Data is the upper bits since in the future we may want to support
setting
certain types of Data the device is capable of. For example 3G, 4G,
LTE.

Other Device Features

Mobile devices have a variety of sensors and input methods. These are
automated
as follows:

  • The virtual keyboard: use sendKeys

  • acceleromator: TODO @mdas is
    working on this

  • geolocation: use regular webdriver endpoints

  • rotation (different from orientation): TODO

  • battery level: not in spec, perhaps exposed via executeScript

  • network speed: not in spec, perhaps exposed via executeScript

WebViews and Other Contexts

One common feature of mobile platforms is the ability to embed a
chromeless
webbrowser inside of a ‘native‘ application. These are called
‘webviews‘, and,
if possible, a server for a given platform should implement
support for
automating the webview using the full, regular, WebDriver
API.

This creates a situation where there are two potential contexts for
automation
in a given AUT: the native layer and the webview layer. If
providing webview
support, the server must have the following endpoints:

  • GET /session/:sessionid/contexts
    • returns an array of strings representing available contexts, e.g.
      ‘WEBVIEW‘, or ‘NATIVE‘

  • GET /session/:sessionid/context
    • returns one of:

    • a string representing the current context

    • null, representing the default context ("no
      context")

  • POST /session/:sessionid/context
    • accepts one of:

    • a string representing an available context

    • null, signifying a return to the default
      context

The first endpoint must return a possibly-empty array of strings. Each
string
must be the arbitrary name of an available context, e.g., one of
possibly
multiple webviews. The second must interpret the body of the request
as the
name of an available context. If that context is not found, a
NoSuchContext
error must be returned. If the context is available, the server
must switch
automation to that context, such that all subsequent commands are
taken to
apply to that context. If the body of the POST
is null, the server must
return to the original
context.

If a server receives a request at an endpoint which is valid in some
context
but not the currently active context (for example if a user
calls
driver.get() in a native context instead of a webview
context), the server
must respond with an InvalidContentException.

Waiting for Conditions

The server must respond to the management commands for implicit wait
timeouts,
such that when a user sets an implicit wait timeout and tries to
find an
element(s), the server keeps trying to find the element(s) until that
timeout
expires, rather than responding with the first failure to find the
element(s).

TODO: figure out what the serversidewait implementation will be and talk
about
it.
Hide details
Change log
2a302804fc1d by Luke Inman-Semerau
linman-s...@salesforce.com
on May 5, 2014 Diff
using "network_connectivity" enpoint
instead of
toggling just airplane mode

passing a ‘bitmask‘ for the types of
network connectivity desired
Go
to:

Double click a line to add a comment
Older
revisions
7a8d40f61557 by Jonathan Lipps <jlipps> on Apr 2, 2014
Diff 
ba61c96e26c8 by Jonathan Lipps <jlipps> on Mar 27, 2014
Diff 
5432d87357e0 by Jonathan Lipps <jlipps> on Feb 25, 2014
Diff 
All revisions of this file
File info
Size: 9179 bytes, 198
lines
View raw file

全面拥抱移动测试，Mobile JSON Wire Protocol Specification文档翻译,布布扣,bubuko.com

时间： 2024-10-05 04:58:25

全面拥抱移动测试，Mobile JSON Wire Protocol Specification文档翻译的相关文章

Redis Protocol specification

Redis Protocol specification Redis clients communicate with the Redis server using a protocol called RESP (REdis Serialization Protocol). While the protocol was designed specifically for Redis, it can be used for other client-server software projects

[译] QUIC Wire Layout Specification - Frame Types and Formats | QUIC协议标准中文翻译(4) 帧类型和格式

欢迎访问我的个人网站获取更好的阅读排版体验: [译] QUIC Wire Layout Specification - Frame Types and Formats | QUIC协议标准中文翻译(4) 帧类型和格式 | yoko blog (https://pengrl.com/p/47156/) 目录 Frame Types | 帧类型 STREAM Frame | 流类型帧 ACK Frame | ACK帧 STOP_WAITING Frame | 停止等待帧 WINDOW_UPDATE

protobuf的简单应用，json和protocol Buffer的转换简单例子

Google Protocol Buffer 的使用和原理 Protocol Buffers 是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,很适合做数据存储或 RPC 数据交换格式.它可用于通讯协议.数据存储等领域的语言无关.平台无关.可扩展的序列化结构数据格式.目前提供了 C++.Java.Python 三种语言的 API. 简介 什么是 Google Protocol Buffer? 假如您在网上搜索,应该会得到类似这样的文字介绍: Google Protocol Buffe

postman测试传入json

原文地址:https://www.cnblogs.com/angdh/p/9787424.html

中文Appium API 文档

该文档是Testerhome官方翻译的源地址:https://github.com/appium/appium/tree/master/docs/cn官方网站上的:http://appium.io/slate/cn/master/?ruby#about-appium 中文Appium API 文档 第一章:关于appium1.1 appium客户端客户端类库列表及Appium服务端支持 这些类库封装了标准Selenium客户端类库,为用户提供所有常见的JSON 格式selenium命令以及额外的

appium简明教程(转)

转:http://www.yangyanxing.com/article/1266.html appium简明教程(1)——appium和它的哲学世界 什么是appium? 下面这段介绍来自于appium的官网. Appium is an open-source tool you can use to automate mobile native, mobile web, and mobile hybrid applications on iOS and Android platforms. “

appium简明教程（10）——控件定位基础

狭义上讲,UI级的自动化测试就是让机器代替人去点来点去的过程. 但机器去点什么(点上面还是点左边),怎么点(是长按还是轻触),这些东西是必须由代码的编写者所指示清楚的. 控件定位就是解决机器点什么的问题的. 一般说来,我们可以这样告诉机器:去点登陆按钮. 机器很笨,它并不知道什么是登陆按钮.因为登陆按钮是自然语言的描述. 如果你让一个人去点登陆按钮,那么他其实也是要经过一系列的脑补以后才可以做这件事的. 这个脑补的过程还原如下: 这个一定是个按钮 这个按钮一定在被测的应用上 这个按钮大概上面有登

Appium的一点一滴

Appium的一点一滴 1.如果通过uiautomatorviewer获取app的element (Windows)uiautomatorviewer是andriod自带的处在andriodsdk安装目录下的tools里面(uiautomatorviewer.bat) 1.1 uiautomatorviewer:分析Android应用UI组件 uiautomatorviewer:分析Android应用UI组件 uiautomator测试框架是Android SDK自带的App UI自动化测试Ja

Appium（1）简介

appium介绍 官方网站 1.特点 appium 是一个自动化测试开源工具,支持 iOS 平台和 Android 平台上的原生应用,web应用和混合应用. "移动原生应用"是指那些用iOS或者 Android SDK 写的应用(Application简称app). "移动web应用"是指使用移动浏览器访问的应用(appium支持iOS上的Safari和Android上的 Chrome). "混合应用"是指原生代码封装网页视图--原生代码和 we