Appium----Basic Concepts

Ext.: http://www.cnblogs.com/nbkhic/p/3803830.html

Client/server Architecture

The core of Appium is actually a server that exposes a series of rest APIs.

The functionality of this server is very simple: listen to a port and then receive a command sent by the client. Translate these command, turn these command into a mobile device understandable form sent to the mobile device, and then the mobile device executes these command after the execution results are returned to the Appium Server,appium server and then return the execution results to the client.

In this case, the client is actually the device that initiates the command, which is generally the machine that our code executes, the machine that executes the Appium test code. In a narrow sense, the client can be understood as a code, and the code can be java/ruby/python/js, as long as it implements the Webdriver standard protocol.

This design idea brings some benefits:

• 1, can bring multi-lingual support;
• 2, you can put the server on any machine, even the cloud server can be; (yes, appium and Webdriver are natural for cloud testing)

Session

Session is a conversation, in Webdriver/appium, all your work is always after the session start can be done. In general, by post/session this URL, and then passed in desired capabilities can open the session.

When the session is opened, a globally unique session ID is returned, and almost all requests must be brought with the session ID, since the seesion ID represents the browser you opened or the emulator for the mobile device.

Think further, since session ID is globally unique, it becomes possible to start multiple sessions on the same machine, which is the specific theoretical basis that selenium gird relies on.

The copyright of this article is owned by ethanol, welcome reprint, but please specify the author and source, strictly prohibited for any commercial use

Desired capabilities

Desired capabilities carries some configuration information. In essence, this is an object in the form of Key-value. You can think of it as a dictionary in Map,python in Java, a hash in Ruby, and a JSON object in JS. In fact desired capabilities is a JSON object when it is transmitted.

The most important role of desired capabilities is to tell the server the context of this test. Do you want to do a browser test or a mobile test this time? If it's a mobile test, Android or iOS, what app do we test if we test Android? Server of these questions desired capabilities must answer, otherwise the server does not buy, nature will not be able to complete the mobile app or browser launch.

Specific examples are as follows:

For example, we might set the " platformName capability iOS to" Appium that we want an iOS session, rather than an Android One. Or we might set safariAllowPopups the capability to on order to ensure that true , during a Safari automation session, we ' re allowed to Use JavaScript to open up new windows. See the capabilities doc for the complete list of capabilities available for Appium

Appium Server

This is what we open with the Appium command at the command line every time.

Appium Clients

Because the native Webdriver API is designed for the web, it is a bit nondescript to use on the mobile side. Appium official provides a set of Appium client, covering a variety of language ruby/java/python, in my opinion, Ruby client is to achieve the best. In testing, it is common to use these client libraries to replace the native Webdriver library. This is not actually a replacement, as the client has some mobile extensions to the native Webdriver, including some handy methods, such as swipe, Appium client makes it easier to write better-readable test cases.

Appium.app, Appium.exe

The GUI version of Appium server is used on OSX, which is on Windows. Visualization, no need to install node, you can see the UI structure of the app is the selling point of this stuff.

Appium----Basic Concepts