Chapter Appium Introduction

With the popularization of mobile terminals, more and more mobile phone applications, but also more and more important. And as a test we also have to keep up with the times, to learn about the mobile phone app related testing, some time ago we introduced the Robotium mobile phone automation testing framework, starting from this chapter, we introduce another mobile phone automation test framework appium. So what exactly is Appium? We quote the Appium website as follows:

British Civil Service Network: Http://appium.io/introduction.html?lang=zh

1.1 AppiumIntroduction

Appium is an open source automated testing tool that supports native, mobile-browser-based, hybrid applications on iOS and Android platforms.

native app : Apps written only with iOS and Android Standard SDK

Mobile browser-based apps : Apps accessed with a mobile browser (Appium support for Chrome on iOS and Android or embedded "browser" app)

Hybrid Application : Wrapping all functions based on a WebView implementation into an application, WebView is a native control that can interact with various elements of a webpage (translator note: Because all mobile platforms will have a browser, Therefore, the application based on browser encapsulation can be easily cross-platform. PhoneGap These projects can be easily packaged into a hybrid application with Web-based capabilities.

Importantly, Appium is cross-platform: it allows you to write test code on different platforms (ios,android) using the same set of APIs. This makes it possible for the test suite to implement code reuse on iOS and Android platforms.

For Appium cross-platform support and test automation modularity, please refer to platform supported Doc.

1.2 AppiumPhilosophy

Appium is based on the following four concepts designed to meet the requirements of mobile platform test automation:

(1) You should not have to recompile or modify your app in any way because you need to automate testing your app.

(2) You should not fix yourself in a specific language and a specific framework to implement and run your tests.

(3) When it comes to testing automation APIs, a mobile testing framework should not do things like "reinvent the wheel."

(4) A mobile test automation framework should be open source, both mentally, in fact, and nominally!

1.3 AppiumDesign

So how does the architecture of the Appium Project meet the requirements of these concepts? In order to achieve the requirements, we are using the standard automated testing framework provided by mobile platform providers (Translator Note: iOS UIAutomation and Android Instrumentation and Uiautomator). This way, we don't need to compile any appium-related or third-party code or framework into your app. This means "You're testing the app you're going to publish." We use the framework provided by the mobile platform vendor as follows:

? IOS: Apple Inc. 's uiautomation.

? Android 4.2+: Google Inc. 's Uiautomator.

? Android 2.3+: Google Inc. 's instrumentation. (Instrumentation support is implemented by binding another independent Selendroid project).

In order to meet the requirements, we are doing a higher-level encapsulation of the automated testing framework for different mobile platform vendors, exposing a unified set of APIs, which is what we want to call the Webdriver API. Webdriver (also called "Selenium Webdriver") specifies that a set of client-server-side protocols (that is, JSON wire Protocol) is used, based on this set of protocols, The client can send the HTTP request to the server appropriately, regardless of the language it is written in. In fact, there are now clients written in different popular languages. This means that you can use any of your favorite test execution process management platform and test framework, because you use the Appium client's library is just an HTTP client, you can use any of the way you like to embed it in your code. In other words, appium&webdriver clients are not really "test frameworks", but "automated test libraries" that you can use to build and manage your test environment in the way you like.

We used the same method to achieve the first requirement: Given that webdriver is in fact already a standard for Web browser automation testing and is already a working draft, what is the need to re-establish a set of standards for mobile devices? No need! We just need to extend the appropriate Webdriver API to facilitate the use of mobile platform test automation.

As far as the first point is self-evident-you are now reading this article because Appium is open source.

1.4 AppiumConcept1.4.1 Client/server-side architecture

The core of Appium is a network server that exposes the rest API. It receives the connection from the client, listens (the client's) command, runs the command on the mobile device, and then sends the HTTP response packets that represents the result of the command back to the client.

The fact that we use the client/server segment architecture actually opens up a lot of possibilities for us: we can implement our test code on any language that supports the HTTP client API, and of course it will be more convenient and efficient to use the "Apppiu client library" we provide. We can put the server side on a machine that is completely different from our test run machine. We can write test cases with confidence and rely on remote cloud service platforms such as "Sauce Labs" to receive and translate our test commands.

1.4.2 Session

Automation is often done in the context of an owning session. The way the client initiates a session to the server is different depending on the library, but the same is when they eventually send a post/session request to the server that contains the so-called "desired capabilities" JSON object. This allows the server to open an Automation session and send the session ID back to the client for subsequent continuous command delivery.

1.4.3 Desired capabilities (not good translation, so do not translate as a special term)

Desired capabilities is a set of key-value pairs that the client sends to the Appium server to tell the server what kind of session we want to start. There are also key-value pairs that are used to modify the behavior of the server side in the process of automation.

For example, we can set the value of the capability with the key platformname to iOS to tell the server that we want to open an iOS session, not a anddroid session. Or we can set the value of the capability with the key safariallowpopups to true to ensure that we can use JavaScript to pop up a new window during the Safari automation session. To view the full list of capabilities supported by Appium, see capabilities Doc.

1.4.4 AppiumServer

Appium is a server written by node. js. Can be compiled and installed via source or NPM.

1.4.5 AppiumClient

There are many Appium client libraries that extend to the Webdriver protocol (libraries for the following languages: Java,python,php,javascript, and C #). When using Appium, Relatively conventional (translator note: no extended) Webdriver Library, I believe you will choose to use these expanded libraries. You can view all the libraries here.

1.4.6 Appium.app, Appium.exe

The GUI package version of these Appium servers is available for download. In fact these are packaged and installed with other things when configuring the Appium server to run the environment, so you don't have to worry about using node to download the installation. One of the inspector will also be installed together, you can use it to view the structure of your app, so that you can easily with its assistance to write test scripts.

Begin

Congratulations! Now that you have enough knowledge to start using Appium, why not go to getting Started doc for more detailed requirements descriptions and recommendations?

1.5Summary of this chapter

in this chapter we cite the introduction of the Appium website as the beginning of this tutorial, let us have a certain understanding of the framework, and then in the following chapters, we will explain in detail if you use this test framework to write our automated test cases. In the language we use Python, and of course we have java. We introduce Python+appium first, if we have the demand, we will introduce Java+appium later, hope that everyone's learning to help.

Chapter Appium Introduction