全面擁抱移動測試，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:

• David Burns (Mozilla) - website - twitter
• Dominik Dary (eBay) - website - twitter
• Jonathan Lipps (Sauce Labs) - website - twitter
• Jason ? (Facebook) - website - twitter
• François Reynaud (eBay) - website - twitter
• Simon Stewart (Facebook) - website - twitter
• Santiago Suarez Ordoñez (Sauce Labs) - website - twitter

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 [e-mail] 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