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

Software Testing Automation using Appium that are then bundled into a native wrapper, creating a hybrid app. Importantly, Appium is a cross- platform 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 it’s 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 Appium’s 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

Software Testing Automation using Appium 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

Software Testing Automation using Appium

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. Appium’s 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 Appium’s different drivers.

Dept. of CSE, SVCE

2015-2016

Page 4

Software Testing Automation using Appium

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

Software Testing Automation using Appium

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

Software Testing Automation using Appium 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

o

XCode >= 4.6.3, 5.1.1 recommended

o

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

Software Testing Automation using Appium

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

Software Testing Automation using Appium

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 doctor’s 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

Software Testing Automation using Appium

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 we’re 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

Software Testing Automation using Appium

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 Appium’s 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 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 tests.

Dept. of CSE, SVCE

2015-2016

Page 11

Software Testing Automation using Appium

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

Software Testing Automation using Appium 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

Software Testing Automation using Appium

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

Software Testing Automation using Appium

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

Software Testing Automation using Appium 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. It’s 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

Software Testing Automation using Appium

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 Android’s 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

Software Testing Automation using Appium

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 Apple’s 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

Software Testing Automation using Appium

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 Appium’s 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 Appium’s 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

Software Testing Automation using Appium

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 won’t 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

Software Testing Automation using Appium

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

Software Testing Automation using Appium 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

Software Testing Automation using Appium

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

Software Testing Automation using Appium 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

Software Testing Automation using Appium

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 doesn’t 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 Lab’s 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

Software Testing Automation using Appium

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

Software Testing Automation using Appium

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