Software Testing Automation Using Appium

Software Testing Automation using Appium
Chapter 1
INTRODUCTION
Software testing phase within the software development lifecycle is the phase which
ultimately determines how sellable our product is. It is in this sense that a lot is being
explored in terms of optimizing testing. With the advent and ever increasing use of mobile
technology, testing also has to keep up with the complexities in terms of both volume and
variety. The volume is in terms of the number of test cases involved while testing. The
variety is in terms of defining the test cases such that it accommodates the nuances of touch
screen, multitasking, mobile internet and other gesture recognitions. Automation is the
solution to deal with volume and ironically automation also is the challenge to deal with
variety. This is to emphasize on the need for automating testing for mobile technology. One
such open source tool for software automation is called Appium which will give us an insight
to providing solutions to the above mentioned challenges.
Learning from the tools available for automating testing for desktops, tools like MonkeyTalk,
KIF, Calabash, etc. were developed for mobile native applications. Most of these tools
required an extra agent that needed to be compiled along with the application code. The extra
agent was needed so that the tool can interact with the mobile application. The libraries of
this extra agent had to be removed at the time of submitting the application to the Store.
Appium, on the other hand, does not need any such extra agents to be included in the original
code. Appium can be termed as a revolutionary tool that can completely change the testing
process in a much efficient and swift way.
1.1 About Appium

Appium is an open-source tool for automating native, mobile web and hybrid applications
on iOS and Android platforms. Native apps are those written using the iOS or Android
SDKs. Mobile web apps are web apps accessed using a mobile browser. Hybrid apps have
a wrapper around a web view which is a native control that enables interaction with the
web content. Projects like Phone gap, make it easy to build apps using web technologies
Dept. of CSE, SVCE
2015-2016
Page 1

that are then bundled into a native wrapper, creating a hybrid app. Importantly, Appium is
a crossplatform which allows us to write tests against multiple platforms (iOS, Android),
using the same API. This enables code reuse between iOS and Android test suites. It is
built using node.js open-source environment and uses selenium JSON wired protocol for
running test cases on real device. It also tests all kind of applications on real devices as
well as on simulators with the help of simulator Web Driver apps. Appium is built on the
idea that testing native apps should not require including an SDK or recompiling your app
and has made design and tool decisions to encourage a vibrant contributing community.
1.2 History of Appium

Appium has been around in one or another form since 2012. It has been under the
direction of various individuals and organizations and its even been implemented in three
different programming languages. Dan Cuellar was the Test Manager at Zoosk in 2011. It
was maintained by Dan Cuellar, Jonathan Lipps and many other contributors. Appium in
its new incarnation was debuted at the Google Test Automation Conference 2013. Early in
2013 Android and Selenium support was released making Appium the first truly crossplatform automation framework. Later in 2013, Appium was presented at conferences and
meet ups all around the US as well as in England, Poland, Portugal and Australia.
In May 2014 Appium 1.0 was released which stood as a milestone in Appiums
development. Sauce Labs has increased the number of developers it donates to working on
Appium.
1.3 Overview of Appium

Mobile devices are rapidly taking over desktop computers and are becoming a very
important part of our life. As the users of the mobile devices are growing, so does the
importance of application quality. According to Gartner, by 2017, over 268 billion
downloads of mobile apps will generate cumulative revenue of $77 billion. The testing of
mobile application needs to focus on functional testing, security testing, performance
testing, usability testing, regression testing and compatibility testing.
Dept. of CSE, SVCE
2015-2016
Page 2

Testing is one of the important factors in increasing application quality. The applications
written for mobile devices are becoming more and more advanced and complex, adjusting
to the constantly improving computational power of hardware. Software testing means
evaluating software by observing its execution and it encompasses majority of software
development life cycle making it a costly process to carry out.
Software testing is broadly divided into two main categories: manual and automation
testing. Manual testing is defined as the process of testing the system under test manually.
In this process, the tester interacts with the system posing as the end user and interacts
with different functionality present in the system to eliminate all possibility of errors. In
automation testing, we make use of software different from system being test to control
the execution of tests. Here, the output generated is compared to predefined output to
ensure the correct working of system.
The two approaches are complementary to each other, automated testing can perform a
large number of test cases in little time, whereas manual testing uses the knowledge of the
tester to target testing to the parts of the system that are assumed to be more error-prone.
Appium was designed to meet the mobile automation needs according to a philosophy
outlined by the following four tenets:
i.
You should not have to recompile your app or modify it in any way in order to
automate it.
ii.
You should not be locked into a specific language or framework to write and run
your tests.
iii.
A mobile automation framework should not reinvent the wheel when it comes to
automation APIs.
iv.
A mobile automation framework should be open source, in spirit and practice as

well as in name.
Dept. of CSE, SVCE
2015-2016
Page 3
1.4 Goals of Appium

Appium1.5 has been in the works for over half a year and is primarily a technical
architecture. It now aims at taking a hard look at the current code organization and reconceptualizes the relationship between different subsections of Appium. Rewrite the
entire codebase from ES5 Java Script to ES2015.Standardize the sub process
management. Appium is basically a combination API server and sub process manager and
standardizing makes code cleaner and more readable throughout the project. Also aims on
creating a friendlier environment for new devices to contribute to Appium. Appiums iOS
support and Android support are derived from the same common interfaces and the goal is
now to reduce duplication of work and boilerplate across Appiums different drivers.
Dept. of CSE, SVCE
2015-2016
Page 4
Chapter 2
SYSTEM DESIGN
The structures of the Appium project live out this philosophy. We meet the first requirement
by using vendor-provided automation frameworks under the hood. That way, we don't need
to compile in any Appium-specific or third-party code or frameworks to your app. This
means you're testing the same app you're shipping. The vendor-provided frameworks used
are as follows:
iOS: Apple's UIAutomation
Android 4.2+: Google's UiAutomator
Android 2.3+: Google's Instrumentation. (Instrumentation support is provided by
bundling a separate project, Selendroid)
We meet the second requirement by wrapping the vendor-provided frame works in one API,
the WebDriver API. WebDriver (aka "Selenium WebDriver") specifies a client-server
protocol (known as the JSON Wire Protocol). Given this client-server architecture, a client
written in any language can be used to send the appropriate HTTP requests to the server.
There are already clients written in every popular programming language. This also means
that you're free to use whatever test runner and test framework you want; the client libraries
are simply HTTP clients and can be mixed into your code anyway you please. In other
words, Appium & WebDriver clients are not technically test frameworks they are
automation libraries.
We meet the third requirement in the same way: WebDriver has become the de facto
standard for automating web browsers, and is a W3C Working Draft. Why do something
totally different for mobile? Instead we have extended the protocol with extra API methods
useful for mobile automation
Dept. of CSE, SVCE
2015-2016
Page 5
2.1 System Architecture
Fig 2.1: Basic Architecture of Appium

Appium finds its roots from the Selenium WebDrivers, which is the standard for browser
automation used by developers in large numbers for programming in any language of their
choice. Appium uses the Selenium WebDrivers to execute scripts. And being an open
source cross platform tool, scripts can be written in Java, Ruby, C, Python, Perl which
gives the programmers the liberty to use any language.
The architecture of Appium can be divided into four major components:
2.1.1 WebDrivers Scripts

Selenium WebDriver libraries and APIs is used to write the test case scripts. These scripts
are similar for both Android and iOS for a particular event of a similar application.
2.1.2 Appium Server

Appium Server Is an HTTP server which handles and creates the Web Driver sessions. It
starts a test case execution that spawns a server.
2.1.3 Instruments or UIAutomator

Appium server listens to and proxies commands, Instruments Command Server for iOS
apps and UIAutomator running on device for Android apps.
2.1.4 Real Devices or Simulators and Emulators

Dept. of CSE, SVCE
2015-2016
Page 6

A simulator is the replica of a real iOS device which is used for testing the app. Similarly,
an emulator is for Android. Appium executes the test scripts relatively faster on a real
device, without knowing the technicality of the application code, making it just the ideal
framework desire.
2.2 System Specification

Your environment needs to be setup for the particular mobile platforms that you want to
run tests on. If you want to run Appium via an npm install, hack with or contribute to
Appium, you will need node.js and npm0.10 or greater (use n or brew install node to
install Node.js. Make sure you have not installed Node or Appium with sudo, otherwise
you'll run into problems). We recommend the latest stable version.
To verify that all of Appium's dependencies are met you can use appium-doctor. Run
appium-doctor and supply the iOS or android flags to verify that all of the
dependencies are setup correctly. If running from source, you may have to
use./bin/appium-doctor.js or node bin/appium-doctor.js.
You also need to download the Appium client for your language so you can write tests.
The Appium clients are simple extensions to the WebDriver clients. You can see the list of
clients and links to download instructions at the Appium clients list.
2.2.1 iOS Requirements

o
Mac OS X 10.7 or higher, 10.9.2 recommended
XCode >= 4.6.3, 5.1.1 recommended
Apple Developer Tools (iPhone simulator SDK, command line tools)
2.2.2 Android Requirements

o Android SDK API >= 17 (Additional features require 18/19)
o Appium supports Android on OS X, Linux and
Windows
Dept. of CSE, SVCE
2015-2016
Page 7
Essentially, we support a subset of the Selenium WebDriver JSON Wire Protocol and
extend it so that we can specify mobile-targeted desired capabilities to run our test
through Appium.
2.3 Components of Appium

There are three major components in Appium:
2.3.1 Inspector
The Appium Inspector records and plays native application behavior by inspecting DOM
and generates the test scripts in any desired language. However, currently there is no
support for Appium Inspector for Microsoft Windows. In Windows, it launches the
Appium Server but fails to inspect elements. However, UIAutomator viewer can be used
as an option for Inspecting elements. It helps the test engineer to detect, inspect and
interact with user interface elements. Inspector provides the test engineer with the path of
every single element present of the current screen on simulator or a real device. Inspector
has a record function which helps in generating scripts automatically upon interaction
with UI elements. Inspector provides different ways of interacting with the GUI of the
application under test.
Fig 2.2: Appium Inspector

Dept. of CSE, SVCE
2015-2016
Page 8
2.3.2 Doctor
Appium provides a doctor for a very simple task i.e. to run a check whether all the
components required for the running of test and simulators are met before hand. It shows an
error if one or more components required are missing and without that the test cannot be
run. The results of the doctors inspection of requirements are shown on the Appium server
window. If all conditions are met, there is a green tick in front of each requirement.
Fig 2.3: Appium Doctor
2.3.3 Appium Server

Appium is a server written in Node.js. It can be built and installed from source or installed
directly from NPM. We can modify capabilities of the server according to the test
requirements. Appium server handles the execution of script and linking it with the
simulator or emulator.
Fig 2.4: Appium Server

Dept. of CSE, SVCE
2015-2016
Page 9
2.4 Appium Concepts

2.4.1 Client/Server Architecture
Appium is at its heart a web server 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. The
fact that we have a client or server architecture opens up a lot of possibilities: we can
write our test code in any language that has a http client API, but it is easier to use one of
the Appium client libraries. We can put the server on a different machine than our tests are
running on. We can write test code and rely on a cloud service like Sauce Labs to receive
and interpret the commands.
2.4.2 Session
Automation is always performed in the context of a session. 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 capabilities object. At this
point the server will start up the automation session and respond with a session ID which
is used for sending further commands.
2.4.3 Desired Capabilities

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 were interested in starting up.
There are also various capabilities which can modify the behavior of the server during
automation. For example, we might set the platform Name capability to iOS to tell Appium
that we want an iOS session, rather than an Android one. Or we might set the safari Allow
Popup capability to true in order to ensure that, during a Safari automation session, we are
allowed to use JavaScript to open up new windows. See the capabilities doc for the
complete list of capabilities available for Appium.
Dept. of CSE, SVCE
2015-2016
Page 10
2.4.4 Appium Server

Appium is a server written in Node.js. It can be built and installed from source or installed
directly from NPM: $ npm install -g appium $ appium.
2.4.5 Appium Clients

There are client libraries (in Java, Ruby, Python, PHP, JavaScript, and C#) which support
Appiums extensions to the WebDriver protocol. When using Appium, you want to use
these client libraries instead of your regular WebDriver client. You can view the full list
of libraries here.
2.4.6 Appium.app and Appium.exe

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 dont 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 tests.
Dept. of CSE, SVCE
2015-2016
Page 11
Chapter 3
IMPLEMENTATION
3.1 Working of Appium
The scripts and the desired capabilities can be written in any programming language
including Python, Perl, Java, Ruby, C#. Here, an eclipse IDE is used to write capabilities
and scripts both on Windows platform. The capabilities for Android app are being tested on
the emulator. For an iOS app, just the desired capabilities need to be changed, for instance,
device name will become iPhone and platform name will become iOS.
Fig 3.1: Desired capabilities of Android App Testing

While testing the GUI of the applications, the elements are identified automatically by
Appium inspector including the element name, type; Xpath and class. Xpath is finding the
element by the path with which that particular element is navigated to. Appium provides the
facility to record this script and directly use them while running the test case. A specific
recording of an event will have a unique script for that specific path.
Dept. of CSE, SVCE
2015-2016
Page 12

The test cases are written in Junit. Appium Inspect or captures a screenshot of the
application screen. Record will generate the script for the command you click or tap on the
screen. When a tap or a click command is given, the following screenshot of the next screen
can be captured. A script for this command is then subsequently recorded. Coming to the
very important property of automated testing, that is, reusability, can be achieved using
appium. The same set of scripts can be used for testing a particular test case against
hundreds of values. The effort and the time required to test manually with a hundred values
will require hours of work, but with appium it can be completed in minutes automatically.
Dept. of CSE, SVCE
2015-2016
Page 13
3.1.1 Finding an element in a UI screenshot

By Xpath: Xpath is an abstract representation of a path of an element. In theFig3.2the
elements for user name and password is found by navigating to a particular element on the
screen forming a hierarchy.
For entering a username the Xpath used is android.view.View / android.widget.ListView /
android.view.View. Similarly for entering password only the android.view.View changes
in the Xpath.
By ID: The appium inspector recognizes the id of a particular UI element. This id is used
to locate the element while generating the script.
By Name: The element is recognized by its name. The Login button is recognized by the
name Login.
Fig 3.2: Login screen of an Android app
Dept. of CSE, SVCE
2015-2016
Page 14
3.1.2 Issuing a Command to the Appium Server

Events that can be tested using Appium: Selenium WebDrivers allows the usage of
various methods for testing the UI elements. Selenium WebDriver recognizes a command
from the code and sends it in the form of Json via a HTTP request to the Appium Server.
UI functional testing of events such as click, adding texts, tap and scroll is supported by
Appium.
Click event: Elements.click () event is used to send a click command to Appium, which
interfaces with the client device and executes the command. After its execution, a log
report is sent to the Appium Server. Thereafter Appium is ready to interface further
command.
Tap event: A tap event is like a click event but it is used to tap anywhere on the UI to get
to a particular screen or tap in a textbox just before sending any key onto the textbox.
Send Keys event: A piece of text called keys is sent from the code to be typed on to the
textbox in the client device.
3.2 Working of Appium in iOS
Fig 3.3: Appium working in iOS

Dept. of CSE, SVCE
2015-2016
Page 15

On iOS, Appium proxies command to a UIAutomation script running in Mac Instruments
environment. Apple provides this application called instruments which is used to do lot
activities like profiling, controlling and building iOS apps but it also has an automation
component where we can write some commands in JavaScript which uses UIAutomation
APIs to interact with the App UI. Appium utilizes these same libraries to automate iOS
Apps.
In the above figure, we can see the architecture of the Appium in context to the iOS
automation. A command life-cycle goes like; Selenium WebDriver picks a command from
the code like (Element.click) and sends it in form of JSON via http request to the Appium
server. Appium server knows the automation context like the iOS and Android and sends
this command to the Instruments command server which will wait for the Instruments
command client (written in node.js) to pick it up and execute it in bootstrap.js within the
iOS instruments environment. Once the command is executed the command client sends
back the message to the Appium server which logs everything related to the command in
its console. This cycle keeps going till the time all the commands gets executed.
To setup Appium for iOS automation, you will need Xcode. That means Appium iOS
setup can only be done in MacOS. Automation is possible on actual iOS device or
simulator. In our example, we will automate UI Catalog app on simulator. But you can as
easily use your actual iOS device. Its just a matter of changing one of the capabilities. As
for programming language, we will be using Java.
Dept. of CSE, SVCE
2015-2016
Page 16
3.3 Working of Appium in Android
Fig 3.4: Appium working in Android

The situation is almost similar in case of Android where Appium proxies command to a
UIAutomator test case running on the device. UIAutomator is Androids native UI
automation framework which supports running JUnit test cases directly in to the device
from the command line. It uses java as a programming language but Appium will make it
run from any of the WebDriver supported languages.
In the above diagram we can see, here we have Bootstrap.jar in place of bootstrap.js
which represents out test case when compiled in java. As soon as it gets launched it
spawns a TCP server. Here the TCP server resides inside the device and client is in the
Appium process which is just opposite to the way it is in iOS.
Dept. of CSE, SVCE
2015-2016
Page 17
3.4 Appium Platform Support

Appium supports a variety of platforms and testing modalities ( native, hybrid, web, real
devices, simulators, etc ). This document is designed to make explicit the level of support
and requirements for each of these.
3.4.1 iOS Support

See Running on OS X: iOS for iOS requirements and setup instructions.
o Versions: 7.1, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1 and 9.2.
o Devices: iPhone Simulator, iPad Simulator, and real iPhones and iPads.
o Native app support: Yes, with debug version of .app (simulator), or correctlysigned .ipa (real devices). Underlying support is provided by Apples UI
Automation framework.
o Mobile web support: Yes, via automation of mobile Safari. For real devices, iOSweb kit- remote-debugger is required, and automation of native aspects of the Safari
interface is not possible. See the mobile web doc for instructions.
o Hybrid support: Yes. For real devices, iOS-web kit-remote-debugger is required.
See the hybrid doc for instructions.
Support for automating multiple apps in one session: No. Support for automating
multiple devices simultaneously: No. Support for automating vendor-provided or thirdparty apps: Only vendor-provided apps (Preferences, Maps, etc), and only on the
simulator. Support for automating custom, non-standard UI controls: Minimal. You
need to set accessibility information on the control which enables some basic
automation.
Dept. of CSE, SVCE
2015-2016
Page 18
3.4.2 Android Support

See Running on OS X: Android, Running on Windows, or Running on Linux for Android
requirements and setup instructions.
o Versions: 2.3 through 4.2 are supported via Appiums bundled version of Selendroid,
which utilizes Instrumentation. Selendroid has a different set of commands than the
default Appium (though this is rapidly being minimized) and a different support
profile. To access this automation back end, use the automation Name capability with
the value Selendroid. Versions 4.2 and up are supported via Appiums own
UIAutomator libraries. This is the default automation back end.
o Devices: Android emulators and real Android devices.
o Native app support: Yes.
o Mobile web support: Yes (but not when using Selendroid backend). Automation is
effected using a bundled Chrome driver server as a proxy. With 4.2 and 4.3,
automation works on official Chrome browser or Chromium only. With 4.4+,
automation also works on the built- in Browser app. Chrome/Chromium/Browser
must already be installed on the device under test. See the mobile web doc for
instructions.
o Hybrid support: Yes. See the hybrid doc for instructions.
With default Appium automation backend: versions 4.4 and up.
With Selendroid automation backend: versions 2.3 and up.
Support for automating multiple apps in one session: Yes (but not when using the
Selendroid backend).
Support for automating multiple devices simultaneously: Yes, though Appium must
be started using different ports for the server parameters --port, --bootstrap-port (or -selendroid-port) and chrome driver-port.
Dept. of CSE, SVCE
2015-2016
Page 19
3.5 Appium System Setup

3.5.1 System Setup (iOS)
Appium requires Mac OS X 10.7 or greater. Mostly recommended is OS X 10.10.
We must make sure to have Xcode and the iOS SDK(s) installed. Xcode version 7.1 is
recommended as earlier versions of Xcode are limited in which versions of iOS they can
test against. We need to authorize use of the iOS Simulator. If Xcode 7.x, Instruments
Without Delay (IWD) does not work. We should enable IWD (which will significantly
speed up your tests) using this method.
If Xcode 6, we need to launch each simulator we intend to use with appium in advance and
change the default to actually show the soft keyboard if we want send Keys to work. We
can do this by clicking on any text field and hitting command-K until we notice the soft
keyboard show up.
If Xcode 6, we have a feature in Xcode called Devices (command-shift-2). We need to
make sure that whichever deviceName we choose to use with Appium in our capabilities,
there is only one of those per sdk version. In other words, if we send in a deviceName cap
of iPhone 5s and a platform Version cap of 8.0, we need to make sure that there is exactly
one device with the name iPhone 5s and the 8.0 sdk in our devices list. Otherwise, Appium
wont know which one to use.
In iOS8, devices each have their own setting which enables or disables UIAutomation. It
lives in a Developer view in the Settings app. We need to verify that UIAutomation is
enabled in this view before the simulator or device can be automated.
Dept. of CSE, SVCE
2015-2016
Page 20
3.5.2 System Setup (Android)

Install node.js (v.0.12 or greater). We need to use the installer from nodejs.org. Install the
Android SDK. We will need to run the android tool (included in the SDK, in the tools
folder) and make sure we have an API Level 17 or greater API installed. We need to Set
ANDROID_HOME to be our Android SDK path and add the tools and platform-tools
folders to our PATH variable and also install the Java JDK and set JAVA_HOME to our
JDK folder.
We need to install Apache Ant or use the one that comes with the Android Windows SDK in
the eclipse\plugins folder and add the folder containing Ant to your PATH variable. Install
Apache Maven and set the M2HOME and M2 environment variables. Set M2HOME to the
directory maven is installed in and set M2 to %M2HOME\bin. Add the path we used for
M2 to our PATH.
Install Git Be sure to install Git for windows to run in the regular command prompt. Install
cURL. To run tests on Windows, we will need to have the Android Emulator booted or an
Android Device connected that is running an AVD with API Level 17 or greater. Then run
Appium on the command line (via the appium command) or if you are running from source
inside the folder where you installed appium using node.js.
3.6 Appium Calculator Example

3.6.1 Source Code
package calculator;
import java.net.MalformedURLException;
public class StartApplication {
WebDriver driver;
public void setup() throws MalformedURLException, InterruptedException {
DesiredCapabilities capabilities= new DesiredCapabilities();
Dept. of CSE, SVCE
2015-2016
Page 21

capabilities.setCapability(CapabilityType.BROWSER_NAME, Android);
capabilities.setCapability(deviceName, HTC Desire 500);
capabilities.setCapability(platformVersion, 4.2.2);
capabilities.setCapability(platformName, Android);
capabilities.setCapability(appPackage, com.android.calculator2);
capabilities.setCapability(appActivity, com.android.calculator2.Calculator);
driver = new RemoteWebDriver(new URL(http://127.0.0.1:4723/wd/hub), capabilities);
driver.manage().timeouts().implicitlyWait(80, TimeUnit.SECONDS);
}
@Test
public void method() throws InterruptedException {
WebElement two=driver.findElement(By.name(2));
two.click();
WebElement plus=driver.findElement(By.name(+));
plus.click();
WebElement eight=driver.findElement(By.name(8));
eight.click();
WebElement equal=driver.findElement(By.name(=));
equal.click();
Thread.sleep(5000);
}
@AfterClass
public void stop() {
driver.quit();
}
}
Dept. of CSE, SVCE
2015-2016
Page 22
3.6.2 Snapshots
Snapshot 1
The fig 3.5shows the home screen of Appium.
Fig 3.5: Appium Home screen

Snapshot 2
The fig 3.6 shows the android settings in Appium.
Fig 3.6: Android settings in Appium
Dept. of CSE, SVCE
2015-2016
Page 23

Snapshot 3
The fig 3.7 depicts verification of the Package Name and Activity Name.
Fig 3.7: Package name and Activity name

Snapshot 4
The fig 3.8 depicts running the source code as Java application and viewing the output.
Fig 3.8: Execution and Result
Dept. of CSE, SVCE
2015-2016
Page 24
3.7 Appium Advantages and Disadvantages

3.7.1 Advantages
The beauty of Appium is that, all the complexities are under the hood of Appium
server and for an automation developer the programming language and the whole
experience would remain same irrespective of the platform automating (iOS or
Android).
It opens the door to cross-platform mobile testing which means the same test would
work on multiple platforms.
Unlike other tools Appium doesnt require you to include some extra agents in your
app to make it automation friendly.
It believes in the philosophy of testing the same app which we are going to submit
in the app store.
It is developed and supported by Sauce Labs and it is getting picked really fast with
in the WebDriver community for mobile automation.
It can automate Web, Hybrid and Native mobile applications.
3.7.2 Disadvantages
Scaling up is an important consideration with Continuous Integration and

Appium comes across as a great tool to fulfill this expectation.
If we want to run our tests on multiple iOS devices at the same time then we
would need to arrange the same number of Mac machines, which would be
costly affair. But this limitation can be resolved if we execute our scripts in
Sauce Labs mobile cloud which at present supports running scripts on
multiple iOS simulators at the same time.
Appium uses UIAutomator for Android automation which only supports
Android SDK Platform, API 16 or higher so to support the older APIs they
have used another open source library called Selendroid. It is not a limitation
but it is definitely an overhead on the configuration side.
Dept. of CSE, SVCE
2015-2016
Page 25
CONCLUSION
Continuous advancements in mobile applications is taking place and today we need high
performance applications designed, developed and developed as quickly as possible
Testing is the most important step before launching such applications especially when
developed for use in critical areas of the market where a small error can lead to a huge
failure. Thus, automation of software testing is the new trend taken up by developers to
ensure a high performance application in a short period. Appium seems to be much more
promising in this aspect as it delivers powerful features to test engineers which can save a
lot of time, labor and cost of the project. Thus, Appium provides a complete new
revolution in automation testing this promises efficient, bug-free and quality-rich
applications.
Dept. of CSE, SVCE
2015-2016
Page 26
BIBLIOGRAPHY
[1] Hyungkeun Song, Seokmoon Ryoo, Jin Hyung Kin, An Integrated Test Automation
framework for testing on heterogeneous mobile platforms - IEEE (2011)
[2] Domenico Amalfitano, Anna Rita Fasolino, Portfirio Tramontana, A GUI Crawlingbased technique for Android mobile application Testing IEEE (2011)
[3] Pallavi Raut, Satyaveer Tomar, Android Mobile Automation Framework IJECS
(2014)
[4] Anuja Jain, Swarnalatha P, M R. Ghalib, S. Prabhu, Web-Based Automation Testing
Framework IJCA (2012)
[5] www.appium.io 2014
[6] https://github.com/saucelabs/appium-tutorial 2014
[7] Leckraj Nagowah and Gayshree Sowamber, A Novel Approach of Automation
Testing on Mobile Devices IEEE(2012)
[8] Gaurang Shah, Prayag Shah, and Rishikesh Muchhala, Software Testing Automation
using Appium, IJCET (2014)
Dept. of CSE, SVCE
2015-2016
Page 27

Software Testing Automation Using Appium

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Testing Automation Using Appium

Transféré par

Droits d'auteur :

Formats disponibles

Software Testing Automation using Appium

1.1 About Appium