Perfecto’s CQ Lab using Selenium RemoteWebDriver & Appium Introduction

Mobile Application Types Understanding the Architecture Agenda Mobile Application Types Understanding the Architecture Automation Types Selenium RemoteWebDriver & Appium Drivers Application frameworks & Objects Perfecto Mobile Solutions & Recommendations Before getting started with the technical implementation of our solution, let’s begin with an introduction to the types of mobile applications, and automation testing using Selenium RWD and Appium. Next we will take a look at the Perfecto Mobile RWD extension to mobile devices (for web and hybrid applications) and Appium implementation (for native applications).

Automation Testing Selenium RemoteWebDriver Appium “Selenium automates browsers” Browser testing Perfecto Mobile extends Selenium to support mobile device browsers and applications Multi-language support Appium “Aims to automate any mobile app from any language and any test framework” Extends Selenium for native applications Supports iOS and Android Testing on real devices in the cloud In this course we will focus on two testing environments, supported by Perfecto Mobile: Selenium RemoteWebDriver and Appium. Selenium RemoteWebDriver Selenium is an open-source tool used for automating browser testing. (For more advanced users, familiar with WebDriver: RemoteWebDriver is an implementation class of the WebDriver interface that a test script developer can use to execute their test scripts via the RemoteWebDriver server on a remote machine.) Perfecto Mobile has extended RemoteWebDriver to support mobile web and hybrid applications (in the Perfecto Mobile Continuous Quality Lab – CQ Lab). Language support includes Java, Ruby, Python, C#... Appium Appium is an open-source automation testing framework that is based on the Selenium WebDriver; that’s extended with new classes to support mobile application testing. It contains specific classes for iOS and Android application testing. Perfecto Mobile supports the complete suite of Appium tools, in the CQ Lab, making it an Enterprise Grade Quality Solution. Also, Perfecto Mobile has extended the support to include proprietary Perfecto Mobile functionalities (that are not available in Selenium).

Mobile Application Types Standard testing tool sets Use Selenium RWD for web applications Use Selenium RWD for hybrid apps Use Appium for native apps As we have already established, there are three types of mobile applications – Web (regular/mobile browsers), Hybrid and Native. The standard Selenium RemoteWebDriver allows us to test desktop browsers; and Perfecto Mobile has extended this to include browsers running on mobile devices. Perfecto Mobile recommends using: Selenium RemoteWebDriver for testing web applications (regular and mobile browsers) Appium for native applications, and Selenium RemoteWebDriver for hybrid applications

Website & Application Objects DOM Perfecto Mobile Web Objects Standard for all browsers DOM Native Application Objects Appium automation framework Separate naming for Android and iOS Hybrid Application PM automation framework Mix of Native and DOM objects Appium Identifying objects on the different types of mobile applications can be done in many ways. In this course we will focus on using the following frameworks, according to Perfecto Mobile best practices: the DOM objects for testing web applications Appium framework for testing Native applications, and the Perfecto Mobile framework for testing hybrid applications This enables us to find, view properties, and perform interactions on the application using objects (such as a clicking on something on the device screen, selecting an image or text element, and setting text to an edit field). (For beginner users, a little more about identifying objects: Application User Interfaces are drawn to the screen based on a definition (that’s provided by the application) of how and where to draw the different UI Elements. The definition is a hierarchy of available UI Elements that can be described as an Object Tree. The Object Tree for Web applications uses a standard set of UI Element types to describe how to draw the User Interface. This is the DOM tree and the UI Elements in the standard can be used to describe any website or web application.) The Perfecto Mobile and Appium Frameworks: In the world of mobile applications, it is not as simple. Apple has its own proprietary set of UI Elements and this is different from the proprietary set used by Android. Perfecto Mobile created a framework that allows us to translate the competing UI Elements of the different application UI sets into a “canonical” set of UI Elements and describe the UI structure of an application using these generic UI Elements. This is the Perfecto Mobile framework Object Tree. Appium, that we will be using in the latter part of the course to test native apps, references the UI Elements using the names provided by the proprietary description files. This is the Appium framework Object Tree. The Perfecto Mobile framework identifies the objects in the application with the same standard. This means that the object tree representation of the elements will be the same on both iOS and Android applications. The Appium framework uses two different object tree representations – UI Automator for Android and UI Automation for iOS. This means that when we develop our automation test, according to this mode of work, we will need to create two separate tests (one for Android and another for iOS). (For advanced users, the Perfecto Mobile framework supports identification of the objects either with the application classes or based on a translated generic set of classes. This enables using the same objects for both Android and iOS applications, also referred to as ScriptOnce. This will be covered in later modules.) The framework we choose to work with will determine the object tree representation, in XML format, that we see and work with when using the Perfecto Mobile Object Spy. (For beginner users, each object is refined by a set of attributes that define what is actually displayed. For example, the text attribute defines the text to display.) * This information will be described in more detail and become useful in the later modules where we will describe what the Perfecto Mobile best practices are for identifying objects.

Understanding the Architecture How does it work?

MobileCloud Architecture Manager (MCM) Handset Server (HSS) Real Device Operations Before we get started with the Perfecto Mobile Selenium Plugin technical details and the RemoteWebDriver, let’s take a quick peek at the architecture that defines this solution. First, we should note that we have real devices connected, via a USB cable, to the Perfecto Mobile server (also known as the Handset Server or HSS). Through this USB cable we get a live streaming from the devices and are able to control the devices; including any device real user commands/gestures (such as tap, swipe, click etc.). The HSS, which is responsible for managing all device connectivity, gets its commands from the MobileCloud Manager (MCM) server. The MCM is the component responsible for executing all of the scripts as well as storing within its repository and reports. The MCM gets its commands from the clients via the standard JSON WebDriver protocol. *Represents a classic deployment type. Other deployment types may be slightly different.

Perfecto Mobile Extension Architecture Manager (MCM) Selenium/Appium Client (Test Script) 1 Create Driver Remote WebDriver Server Start Execution 2 Open Device Handset Server (HSS) Get RemoteWebDriver 3 4 Test Execution Run Commands 5 Device Operations Real Device Operations Return Result 6 7 Close Device Download Report 8 Generate Reports 9 Close Driver Now, let’s translate this to our work with the Selenium RemoteWebDriver and Appium clients. Each line in the code is translated into JSON packets that are transmitted following the standard Selenium JSON Wire Protocol to the RemoteWebDriver Server that is hosted on the Perfecto Mobile MCM (MobileCloud Manager). The MCM translates these commands into directives to the HSS that controls the actual devices. RemoteWebDriver has several available testing implementations, that all implement desktop browsers (such as Chrome, FF and IE) to run your test on remote machines. Perfecto Mobile extends this scope to include executing the test script on mobile devices. Perfecto Mobile extended the RWD and Appium server to include: support APIs for testing not only DOM (web site) objects but also Native and Visual objects parallel test execution system level control environment-based interoperability testing (incoming device events, such as calls/messages and pop-ups, can be integrated into the test code) device level vitals around CPU, memory and other device conditions. *Represents a classic deployment type. Other deployment types may be slightly different. * The Perfecto Mobile Appium solution does not use the Appium server. A Detailed description of the Steps in this slide: Your test script creates an instance of the Selenium RemoteWebDriver (or Appium Driver). The capabilities include a specification of the device to be used for the testing and the browser (or application) to activate. As part of creating the new instance – RWD establishes a session between your client and the RWD-server hosted on the Perfecto Mobile MobileCloud Manager (MCM). The RWD server uses the information in the Capabilities to select the device from the MobileCloud to run the tests on. Allocates the device from the MobileCloud Handset Server (HSS). Unlocks the device Starts the browser (for RWD clients)/application (for Appium clients) RWD Server completes the creation of the instance. RWD Client performs driver actions that are translated to JSON messages sent to the MCM-RWD server over the session connection established in (#1). The device requests are translated by the MCM into HTTP requests and transmitted to the HSS for execution on the device. HSS translates the requests to Real Device Operations performed on the actual device. As each operation is completed the result is reported back to the script. Steps 4,5,6 are repeated until the script is completed Script performs driver.close() method that: Closes the device in the cloud. Disconnects the connection between the RWD-server and the HSS for this session. Generates the report of the testing session. The report together with screenshots and complete video is transmitted back to the script. Script performs driver.quit() method that disconnects the session from the RWD Server and frees the resources of the driver.

RemoteWebDriver for Web Applications Objects Course Overview RemoteWebDriver for Web Applications Writing your first test Objects RWD for Hybrid Applications Appium for Native Applications Best practices This course will cover: Getting started with your Perfecto Mobile Eclipse plugin (connecting to the MobileCloud and writing your project) and writing your first test Best practices using RemoteWebDriver and Appium Objects and object tree (XML, XPath, frameworks) Perfecto Mobile extensions and best practices for using visual tools and user environments to make your test scripts complete

References Perfecto Mobile for Appium https://community.perfectomobile.com/series/23054 Selenium RemoteWebDriver https://community.perfectomobile.com/series/20208 What is Selenium? www.seleniumhq.org Appium appium.io Setup Perfecto Mobile Eclipse plugin https://community.perfectomobile.com/posts/914447 RemoteWebDriver vs WebDriver https://community.perfectomobile.com/posts/992642 Making Appium an Enterprise-Grade Mobile Quality Solution https://community.perfectomobile.com/posts/1011531 Additional references: Eclipse documentation on installing new software http://help.eclipse.org/juno/index.jsp?topic=%252Forg.eclipse.platform.doc.user%252Ftasks%252Ftasks-124.htm

Thank You