Official documentation Introduction to Appium Appium Introduction
Appium is a mobile-based automation framework that can be used to test native applications, mobile Web applications and hybrid applications, and is cross-platform. Available for iOS and Android as well as for Firefox operating systems. Native apps are apps written using an Android or iOS SDK, which is a web app that resembles a safari app or Chrome app or class browser app in iOS. Hybrid application refers to the application of WebView, which is applied to web content interactivity.
What's important is that Appium is cross-platform and cross-platform, meaning that you can use a set of APIs for different platforms to write test cases. the philosophy of Appium
Appium follows several principles (in fact, the Appium feature):
1. Use Automation to test an app, but don't need to recompile it
2. Write an automated case, no need to learn a specific language
3. An automated framework does not require a repetitive wheel build
4. An automated framework requires open source, the spirit and practice of open source appium design
In order to follow the above principles, the Appium solution is as follows:
Article One: Use the automation framework provided by the underlying driver.
IOS: Apple's UIAutomation
Android 4.2+: Google's Uiautomator
Android 2.3+: Google's instrumentation (has been selendroid taken
Article two: Using the underlying driver to provide a unified API, is the Webdriver API.
Webdriver (also known as Selenium webdriver) is actually a C/S architecture protocol called JSON Wire Protocol. With this protocol, clients written in any language can send HTTP requests to the server. This means that you are free to choose the test framework and executor you want to use, or you can add any library files that contain HTTP clients to your code. In other words, Appium's webdriver is not a technical testing framework, but an automated library.
Article three: Because Webdriver is a very mature web protocol and is already drafting the standard. Why do we have to create something else? Instead, we have expanded some APIs for mobile-based automation protocols on the basis of webdriver.
Fourth: You can read this article, because we open source. Appium Concept c/S architecture
The core of Appium is a Web server that adheres to the rest design style, accepts the client's connection, receives commands from the client, executes commands on the mobile device, and collects the results of the command execution through the HTTP response. This architecture provides us with a very good opening feature: As long as a language has an HTTP client API, we can write our test code in this language, of course, for the convenience of everyone, we provide the following client library for use:
We can also put servers in the remote, such as the cloud, so that we can use the cloud service to accept commands and parse commands. Session
The process of automating is usually performed in the context of the session. The client initializes a session, although different languages are initialized in different ways, but they all send post/session requests to the server side, and these requests will have an object: desired capabilities, At this point the server will start the automation session and then return a session ID, which will be matched with this seesion ID. Desired Capabilities
Desired capabilities This object is actually a Key-value collection, which contains a variety of information, sent to the server side, the server to resolve this information to know what kind of session the client is interested in, and then start the corresponding session. This information can affect the type of server-side startup session. For example, your PlatformName value is iOS, which tells the server to start an iOS session instead of Android Seesion. If the value of Safariallowpopups is true, this is the automation session that tells the Safari class, you can use JS to open a new window. See Capabilities Doc for detailed information. Appium Server
Appium server uses the HTTP server that is written by node. JS and follows the rest style Appium clients
The client's concept is not the client in our traditional sense, where the client's better understanding is a library that extends the Webdriver protocol, and when you write a case in your preferred language, add the language extension webdrvier library to your environment and you can understand that this is a client. The specific library can be found in the following sections:
language |
Library Address |
Ruby |
Https://github.com/appium/ruby_lib |
Python |
Https://github.com/appium/python-client |
Java |
Https://github.com/appium/java-client |
JavaScript (node. js) |
Https://github.com/admc/wd |
Objective C |
Https://github.com/appium/selenium-objective-c |
Php |
Https://github.com/appium/php-client |
C # (. NET) |
Https://github.com/appium/appium-dotnet-driver |
Robotframework |
Https://github.com/jollychang/robotframework-appiumlibrary |
Appium.app,appium.exe
Under different operating systems, there are different GUI programs
system |
GUI |
git address |
windows |
Appium.exe |
https://github.com/appium/appium-dot-exe |
OS x< /td> |
appium.app |
https://github.com/appium/appium-dot-app |