Appium Python II: Theoretical Conceptual understanding

Brief introduction

Appium is an open source automated testing tool that supports native applications, Web applications, and hybrid applications on IOS and Android platforms.

"Mobile native apps" refers to apps written using IOS or the Android SDK.

"Mobile web Apps" refers to apps that are accessed using a mobile browser (Appium supports both Safari on IOS and Chrome on Android).

"Hybrid apps" refers to native code encapsulating Web page views-native code and Web content interaction.

Appium can run tests on the emulator and on the real machine.

Supported platforms are: IOS, Android, Windows, Firefoxos.

Idea

1. You don't need to recompile or modify your app for automation. (Only a compiled apk file is needed here)
2. You don't have to be confined to a language or framework to write and run test scripts. (supports multiple languages, such as Python, Java, Ruby, and so on; Appium is an automated library, so we can use the framework without restriction)
3. A mobile automation framework should not reinvent the wheel on the interface. (Appium expands the browser's Webdriver protocol and adds a mobile automation-related API method)
4. Both mentally and nominally, it must be open source. (Appium is open source)

Appium Server and Client

Appium server: Is the place to install Appium. You can see from the settings in Appium that the default address is "Http://127.0.0.1:4723/wd/hub".

Appium client: Is where the script is run. The script may be written in Java or in Python. The Appium client has many language libraries, such as Java, Ruby, Python, PHP, JavaScript, and C #.

When we write a script, we define "DRIVER = Webdriver." Remote (' Http://localhost:4723/wd/hub ', Desired_caps) ", the first parameter here is actually telling the client which server to connect to.

The core of Appium is a Web server, which provides a set of REST interfaces.

After we have written the script in the Appium client, we will establish a client-to-server connection, appium the service side to hear the command, execute the commands on the mobile device, and then put the execution results back to the client in the HTTP response.

Here is the log printed on the Appium server, which executes the "Driver.find_element_by_name (" 1 ")" Statement:

post/wd/hub/session/xxxxxxxxxxxxxxxxxxxxxxxx/element {"value":"1","sessionId":"xxxxxxxxxxxxxxxxxxxxxxxx","using":"name"}> Warn: [DEPRECATED] The name locator strategy has been DEPRECATED andwould be removed. Please use the Accessibility ID locator strategy instead.> Info: [debug] waiting up to 0ms forcondition> Info: [debug] pushing command to appium work queue: ["Find",{"Strategy":"name","selector":"1","Context":"","multiple": false}]> Info: [Debug] [BOOTSTRAP] [debug] Got data fromClient: {"cmd":"Action","Action":"Find","params":{"Strategy":"name","selector":"1","Context":"","multiple": false}}>info: [Debug] [BOOTSTRAP] [debug] Got command of type ACTION>info: [Debug] [BOOTSTRAP] [debug] Got command Action:find> Info: [Debug] [BOOTSTRAP] [debug] Finding 1using NAME with the ContextId:multiple:false> Info: [Debug] [BOOTSTRAP] [debug] using:uiselector[description=1, instance=0]> Info: [Debug] [BOOTSTRAP] [debug] using:uiselector[text=1, instance=0]> Info: [Debug] [BOOTSTRAP] [debug] returning result: {"value":{"ELEMENT":"1"},"Status": 0}> Info: [Debug] Responding to client with success: {"Status"70A"value":{"ELEMENT":"1"},"sessionId":"xxxxxxxxxxxxxxxxxxxxxxxx"}

This server/client architecture has many benefits. For example, I installed Appium on machine A, then I can write scripts and execute them on machine B, Machine C, and of course scripts can be written in different scripting languages.

Session

Automation is always done around a session.

The client initializes a seesion (session) to interact with the server, different languages have different implementations, but eventually they are sent as a POST request to the server, and the request contains a JSON object called "desired capabilities". At this point, the server will open an automated session, and return a session id,session ID will be used by the client to send subsequent commands.

The following is a printout of the log on the Appium server, which reflects the process by which the client begins executing code to return SessionID to the server:

> Info:-post/wd/hub/session {"desiredcapabilities":{"PlatformName":"Android","Apppackage":"Com.android.calculator2","devicename":"Android Emulator","platformversion":"4.2.2","appactivity":". Calculator"}}.........>info: [Debug] Creating new Appium session xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>info:starting android Appium ......> Info: [Debug] Appium session started with SessionId Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Appium Python II: Theoretical Conceptual understanding