Appium principle and Version Change details

Summary of Appium principle

API interface calls Selenium interface, Android bottom with Android instrumentation (api2.3+ by binding another independent Selendroid project), Uiautomator interface (api4.2+ ), iOS UIAutomation interface with iOS underlying.

Client/serverarchitecture

Appium The server is written in node. js, and installing node. JS can be used directly with the NPM command or the Dmg,server-side function: Listen to a port, receive commands sent by the client, translate the command into a mobile device understandable form, send it to the mobile device, and then move After the device executes the command, it returns the execution result to Appium server,appium and returns the execution result to the client.

The client is actually the device that initiates the command, generally is the machine that executes the code, the machine that executes the Appium test code, can interpret the client as code, the code can be Java, Python, Ruby, JS, As long as the implementation of the Webdriver standard protocol is possible.

Cross-language: As long as support selenium Webdriver API and this language-related client libraries can. Server on any machine, even cloud servers (Appium and webdriver are inherently suitable 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 SessionID 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.

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.

Appium clients

The native Webdriver API was designed for Web-side, and Appium officially provided a set of Appium clients that could test their app for different language developers, and typically use these client libraries to replace native Webdriver libraries when testing. As a client, the native Webdriver has been extended to some mobile terminals.

Android Frame

iOS framework

The change from appium0.18.x to appium1.x

1. New Client library

Appium Client library replaces the original Webdriver client library

From Appium import Webdriver to replace Fromselenium import Webdriver

2. New capabilities Options

No longer use device, version, use PlatformName, Platformversion, DeviceName, Automationname ("selendroid" if it is api2.3 above to select, default can not fill) , Udid (iOS to specify device markings).

The capability of the previous app remains the same, but it's now used exclusively on non-browser types of apps, to test safari or chrome apps, to use standard Browsername, Both the app and the Browsername are dedicated options.

We also renamed the capabilities of our Appium server using the Camel name method. For example, the original app-package and app-wait-activity will be changed to Apppackage and appwaitactivity. Of course, since we can automatically detect the packages and activity of Android apps, you can ignore these options most of the time.

3. we removed the following control Finder policy:

Name

Tag name

We are now introducing the Accessibility_ ID This strategy to replace the original name of the Thing (translator Note: That is to say the original appiumdriver.findelementbyname will be replaced by the current Appiumdriver.findelementbyaccessibilityid). The details will vary depending on the Appium client you are using (Translator Note: client language).

The new class name will replace the original tag name (the Translator note: The original findelementbytagname will be replaced by the findelementbyclassname that is expected), So if you want to find out the control based on the UI type of a control, use the class name, the control finder.

Note the change in class name and XPath policy: You now need to use FQCN to describe your control. That is, if you are selected by an XPath, the following is said:

Table/cell/button

So now to change (translator Note: That is, the original Findelementbyxpath ("" "//textview[contains (@text, ' addnote ')]") will need to change to Findelementbyxpath ("// Android.widget.textview[contains (@text, ' Addnote ')]:

//UIATableView/UIATableCell/UIAButton

(So analogy: Button is now written Android.widget.Button)

At the same time we have added the following control locator strategy (translator note: That is, into Andoid added appiumdriver.findelementbyuiautomator):

Iosuiautomation

Androiduiautomator

Determine how to use the new control locator policy based on the client (depending on the language) library you are using.

4. Using XML instead of JSON

The format returned from the current window's source code (the translator note: the Appiumdriver.getpagesource function) will be converted from the original JSON to XML. So if your previous code has dependencies on the source of the analysis control must be updated accordingly.

5. Hybrid applications are supported through context rather than window

Today Appium supports a "context" that is more conceptually consistent (with the concept of switching contexts). To get all the available contexts or your app-specific context, use the following method:

# python driver. = driver. Context

Use the following method to switch:

# python driver. Switch_to. Context ("WEBVIEW")

6.   execute_script("mobile:xxx")Will disappear

All "Mobile:" Related methods will be removed and replaced by native methods of the Appium client library. For example, the original Driver.execute ("Mobile:lock", [5]) will be replaced by the current Driver.lock (5) (Here Lock this function has become the native customer method). Of course, the specific invocation method will vary depending on the client library you are using.

Specifically, the gesture-related methods will be replaced by the new Touchaction/multiaction API, which will combine these gestures to make the automation of your gesture operations more powerful and understandable. For more detailed touchaction/multiaction use please check your appium client.

Reference URL:

Website Description: Http://appium.io/slate/en/master/?python#appium

Forum: Http://automationtesting.sinaapp.com/blog/appium

Great God blog:http://blog.csdn.net/zhubaitian/article/details/39753945

Appium principle and Version Change details