What is Appium?
• Appium is an open source test automation
framework for use with native, hybrid and
mobile web apps.
• Appium is “cross-platform”, means it allows
you to write tests against multiple platforms
(iOS, Android, Windows), using the same API
(WebDriver API). This enables code reuse
between iOS, Android, and Windows test
What are different App Types
• Native apps are those written using the iOS,
Android, or Windows SDKs.
• Mobile web apps are web apps accessed
using a mobile browser (Appium supports
Safari on iOS and Chrome or the built-in
‘Browser’ app on Android).
• Hybrid apps have a wrapper around a
“webview” – a native control that enables
interaction with web content.
• You shouldn’t have to recompile your app or
modify it in any way in order to automate it.
• You shouldn’t be locked into a specific language
or framework to write and run your tests.
• A mobile automation framework shouldn’t
reinvent the wheel when it comes to automation
• A mobile automation framework should be open
source, in spirit and practice as well as in name!
• An HTTP server written in Node.js that creates
and handles WebDriver sessions.
• Appium web server follows same approach as
• Receives HTTP requests from client libraries
• Handles received requests in different ways,
depending on platform it is running on.
Appium is at its heart a webserver that exposes
a REST API. It receives connections from a client,
listens for commands, executes those
commands on a mobile device, and responds
with an HTTP response representing the result
of the command execution.
• Automation is always performed in the context of
• Clients initiate a session with a server in ways
specific to each library, but they all end up
sending a POST /session request to the server,
with a JSON object called the ‘desired
• At this point the server will start up the
automation session and respond with a session
ID which is used for sending further commands.
• Desired capabilities are a set of keys and values
(i.e., a map or hash) sent to the Appium server to
tell the server what kind of automation session
we’re interested in starting up.
• There are also various capabilities which can
modify the behavior of the server during
• Example: Set the platformName capability
to iOS to tell Appium that we want an iOS
session, rather than an Android or Windows one.
used by Appium
The vendor-provided frameworks used by Appium:
• iOS: Apple's XCUITest (iOS 9.3 and up)
• iOS: Apple’s UIAutomation (iOS 9.3 and below)
• Android 5.0+: Google’s UiAutomator V2
• Android 4.2+: Google’s UiAutomator
• Android 2.3+: Google’s Instrumentation
(Instrumentation support is provided by bundling
a separate project, Selendroid)
• Windows: Microsoft’s WinAppDriver
• For iOS automation, Appium relies on system
frameworks provided by Apple.
• For iOS 9.2 and below, Apple's only automation
technology was called UIAutomation, and it ran in
the context of a process called "Instruments".
• Apple introduced a new automation technology,
called XCUITest, beginning with iOS 9.3.
• For iOS 10 and up, this will be the only supported
automation framework from Apple.
• with iOS 10 / Xcode 8, Apple has removed the
older UIAutomation framework, which powered
Appium's iOS automation up to this point.
• When you specify a platformVersion of 10 or
higher, Appium will automatically use the
XCUITest automation backend.
• If you would like to run the XCUITest automation
backend with iOS 9.3, simply
specify automationName: XCUITest in your
• The Eclipse IDE
• Xcode (8.0 or later)
• Xcode Apple Developer Tools (iPhone simulator
SDK, command line tools)
• Node and npm
• The Appium Server
• The Appium Client Library (Java)
• Selenium WebDriver Java library
• Java - Download & install Java SE
Development kit 8 for Mac OS X
The Eclipse IDE
• Download & install Eclipse IDE for Java
• Install Xcode (Version 8.0 or above)
• Xcode can be downloaded free from Mac App
Note: To test an app in iOS 10 or above with
Appium, we have to use Xcode 8 or newer with
Appium 1.6 or newer.
The Appium Server
• You can install & run an Appium server using
o using the application
Before You install Appium Server…
Before you install Appium using node.js, you
• NPM - node.js package manager
The Appium server is written in Node.js; that's
why we need it to download Appium
• A package manager for macOS that complements
• Homebrew helps you install applications that are
not installed by default on your MAC.
• It's all git and ruby underneath.
• The standard script installs Homebrew
to /usr/local so that you don’t need sudo when
you brew install
• Homebrew is designed to work without using
(commands for terminal)
• Installing Homebrew ruby -e "$(curl -fsSL
• How do I uninstall Homebrew?
To uninstall Homebrew, paste the command below in a
ruby -e "$(curl -fsSL
• How to check available options on brew:
brew help, man brew
• After installing the Homebrew, run command
• You'll get the message: your system is
ready to brew.
• If you don't get above message then try to fix
warnings and errors using the brew doctor
• npm is a Node.js package manager
• It is an online repository of open source
• It is command-line utility to package
Installing Node.js and/or npm
• Install node.js using brew.
brew install node
• Once you install node, you can check version:
Note: Don’t use the big green install button on
nodejs.org website or all npm commands will
Installing Appium using Node.js
• Install appium using node.js
$ npm install -g appium
Alert: Make sure you have not installed Node or
Appium with sudo, otherwise you’ll run into
• To run Appium
$ appium (Run Appium)
• Now Appium server will be ready for
accepting requests of client.
[Appium] Welcome to Appium v1.6.0
[Appium] Appium REST http interface listener started on
• To verify that all of Appium’s dependencies
are met you can use appium-doctor.
• Install it with:
$npm install -g appium-doctor
• run appium-doctor and supply the --ios or --
android flags to verify that all of the
dependencies are set up correctly.
Stopping Appium Server
• Simply press CTRL+C in the same terminal
window to stop the Appium server.
• There exist GUI wrappers around the Appium
server that can be downloaded.
• These come bundled with everything required
to run the Appium server, so you don’t need
to worry about Node.
• They also come with an Inspector, which
enables you to check out the hierarchy of your
app. This can come in handy when writing
Installation using the APP
• Download the latest version from Appium.io.
• Mount the disk image.
• Drag Appium.app to your Applications folder.
• Run it!!!
• Currently logging is based on idevicesyslog,
and port forwarding is based on iProxy, both
of which are part of libimobiledevice, so you
need to install it with Homebrew
brew install libimobiledevice
• In order to run the WebDriverAgent bootstrap
script you will need to install
the Carthage dependency manager
brew install carthage
• Installing deviceconsole
• An iOS system log trailer to debug problems
• Allows analyzing Crash Logs and Console output from
npm install deviceconsole
• Installing ios-deploy
iOS deploy is used to deploy your app to a
npm install -g ios-deploy
Installing dependencies using HEAD
• head URLs (activated by passing --HEAD) build
the development cutting edge. By passing
the --HEAD option allows installing software
directly from a branch of a version-control
npm install ios-deploy –HEAD
npm install deviceconsole –HEAD
Installing Xcode Command line tools
• To install Xcode command line tools run:
$ xcode-select --install
Install following Selenium components
• Selenium Standalone Server
• Get selenium WebDriver language binding
library for Java from section 'Selenium Client
& WebDriver Language Bindings' present on
• There are client libraries (in Java, Ruby, Python,
extensions to the WebDriver protocol.
• When using Appium, you need to use these client
libraries instead of your regular WebDriver client.
Authorize use of iOS Simulator
• You need to authorize use of the iOS Simulator
by running the authorize-ios binary made
available through npm.
• Install the program by running
npm install -g authorize-ios
Authorize use of the iOS Simulator
• You can invoke the program using
• If you are running Appium.app, you can
authorize iOS through the GUI.
Note: You need to do this every time you install
a new version of Xcode.
What is Sudo?
• sudo (/ˈsuːduː/ or /ˈsuːdoʊ/) is a program for Unix-like computer
operating systems that allows users to run programs with the
security privileges of another user, by default the superuser.
• It originally stood for "superuser do" as the older versions
of sudo were designed to run commands only as the superuser.
• Mac OS X: sudo command requires a non-blank admin password.
The sudo Terminal command can be used by administrators to
execute commands as a different user (for example, as root).
Alert: Be extra careful when using the sudo command. You will usually
have to enter your OS X system password and any mistakes can
permanently mess up your system for good. When in doubt, leave it
• Refer to the official documentation for
Appium versions 1.6 to see all the capabilities
you can choose from.
• There are some common capabilities and
then there are also separate Android only and
iOS only capabilities.
Testing on real iOS Device
Why testing on real devices?
• There could be bugs that only show up when
your app is running on an actual iPhone or iOS
• Testing your iOS app on a device is the best
way to gauge performance issues before you
go too far down the road.
Appium on real iOS devices
To get started on a real device, you will need the
• An Apple Developer ID and a valid Developer Account
with a configured distribution certificate and
• An iPad or iPhone. Configure the device for
development and add the device to the member
• A signed .ipa file of your app, or the source code to
• A Mac with Xcode and the Xcode Command Line
Testing on real iOS Device
• Enroll in the Apple iOS Developer Program
– You’re going to need to enroll in the Apple iOS
developer program which is $99 a year.
– You’ll also need an actual iOS device.
• Your certificate is used to code sign the apps and they
uniquely identify you. In this step, you have to generate
and request two certificates: one for development and
one for distribution. You only need to do this once (not
for each app!).
• The development one is used for testing while the
distribution certificate is used to sign your app bundle
for distribution in the App Store once it’s ready.
Why Code Signing?
• Apple cares that it can identify who created the
app and that it can tell if the app has been
tampered with or not.
• These security measures are ensured by a
process known as code signing. When you create
an app package (binary) to put on a device, you
have to put your “digital signature” on it by code
signing it. Otherwise, Apple won’t let that app be
deployed on any device.
Running your test
• Once your device and app are configured, you
can run tests on that device by passing the -
U or --udid flag to the server or
the udid desired capability, and the bundle ID
(if the app is installed on the device) or the
path to the .ipa or .apk file via the --app flag or
the app desired capability.
XCUITest API vs UIAutomation API
• Unfortunately, the XCUITest API and the UIAutomation API
are not equivalent. In many cases (like with tap/click), the
behavior is identical. But some features that were available
in the UIAutomation backend are not yet available in the
new XCUITest backend. These known lacking features
• Geolocation support (e.g., driver.location)
• Shaking the device
• Locking the device
• Rotating the device (note that this
is NOT device orientation, which is supported)
Appium has a plan to add these features back in future
releases of Appium.
Changes to make in existing script
Here are the changes that you will have to make to your
existing scripts to run automated tests on iOS10:
• Apple has given different class names to UI elements
and changed the application hierarchy. If you use
XPaths in your test, it will be necessary to rewrite them
to account for these changes.
• Apple has removed native support for XPath selectors,
making XPath significantly slower. When using
XCUITest, you can improve performance by using other
locators instead, such as accessibility id.
Avoid using Xpath locators
• Try not to use XPath locators unless there is
absolutely no other alternatives.
• In general, xpath locators might be times
slower, than other types of locators like
accessibility id, class name and predicate (up
to 100 times slower in some special cases).
• They are so slow, because xpath location is not
natively supported by Apple's XCTest
Migrating to XCUITest
• The Appium team has also published a doc
which might be helpful in helping users
migrate their tests:
xcuitest.md. (Released Oct 2016)
Offenbar haben Sie einen Ad-Blocker installiert. Wenn Sie SlideShare auf die Whitelist für Ihren Werbeblocker setzen, helfen Sie unserer Gemeinschaft von Inhaltserstellern.
Sie hassen Werbung?
Wir haben unsere Datenschutzbestimmungen aktualisiert.
Wir haben unsere Datenschutzbestimmungen aktualisiert, um den neuen globalen Regeln zum Thema Datenschutzbestimmungen gerecht zu werden und dir einen Einblick in die begrenzten Möglichkeiten zu geben, wie wir deine Daten nutzen.
Die Einzelheiten findest du unten. Indem du sie akzeptierst, erklärst du dich mit den aktualisierten Datenschutzbestimmungen einverstanden.