1. Perfecto’s CQ Lab using Selenium RemoteWebDriver & Appium
Introduction

2. 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).

3. 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).

4. 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

5. 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.

6. Understanding the Architecture
How does it work?

7. 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.

8. 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.

9. 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

10. References
Perfecto Mobile for Appium
Selenium RemoteWebDriver
What is Selenium?
Appium appium.io
Setup Perfecto Mobile Eclipse plugin
RemoteWebDriver vs WebDriver
Making Appium an Enterprise-Grade Mobile Quality Solution
Additional references:
Eclipse documentation on installing new software

11. Thank You