Mobile Automation: Touching the Mobile World through code - PowerPoint Presentation

Slide1

Mobile Automation: Touching the Mobile World through code

Jason Edstrom

5.18.2016Slide2

Developing software to automate UI interactions with a mobile application

With so many device configurations to account for, Mobile Automation provides an approach to efficiently test different configurations

Still maturing, but new developments happen fastAs the industry matured, hosting companies started to fill the gap by supplying emulators and real devices to automate as a service

Mobile Automation OverviewSlide3

3 main categories of mobile automation

implementationExternal

Internal

Image Based Recognition / Optical Character Recognition (OCR)

Types of ToolsSlide4

Uses the internal native libraries to allow automation via an external server

No need to have access to the code basePredictable and well accepted by the community

ToolsAppium

Selenium

ExternalSlide5

Uses a vendor library that is compiled into the app to allow the tool to see and interaction with UI elements

Need access to the code base to implement the automation libraries

Remember to remove the library before production builds

Tools

Telerik

Ranorex

Monkey Talk

TestComplete

InternalSlide6

The “Hail Mary Pass” of mobile automationUnstable and Unpredictable

Dependent on assets loading in a timely fashion to continue interactionTools

SeeTestSikuli

Image Based / Optical Character RecognitionSlide7

Not all mobile apps are created equal

FrameworksXamarin

CordovaFlex MobileSDK Versions

Enterprise Architecture

Mobile Device Management

Mobile Application Management

XenMobile

AirWatch

Inventory

Poor QA process scenarios

ConsiderationsSlide8

Appium was designed to meet mobile automation needs according to a philosophy outlined by the following four tenets:

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 APIs.A mobile automation framework should be open source, in spirit and practice as well as in name!

Appium PhilosophySlide9

Uses a client/server architecture approach

An external webserver instance written in Node.jsDifferent drivers depending on your language and OS preferences

Real Device and EmulatorUses Mobile Element objects for validation and navigationCross-Platform (iOS & Android)

Supports most major languages

Java

PHP

Objective-C

Python

Ruby

JavaScript

C#OthersSupports Native, Web and Hybrid appsLarge Support Community and consistently evolving

Predictable and relatively easy to troubleshoot

Appium StrengthsSlide10

Uses the same JSON Wire Protocol as SeleniumAppium driver and its children, iOS Driver and Android Driver, are just extensions of Selenium’s Remote Web Driver

Enhanced with Mobile related interactions

TapSwipeLong Press

Shake

App Installation and Close

Multi-Finger

Etc.

The differences are more so related to the server and its setup

Appium / SeleniumSlide11

Appium is rather strict on configuration parameters in order to coordinate between all of the devices.

iOSApp that is signed as development buildAirSign

and iReSignOS X is needed to execute the tests and inspect the app, but not required the write the automation code

Xcode

Instruments is what drives the native UIAutomation library.

Android

If apk is on hand, Appium GUI can auto populate most of the needed fields.

If apk is no available, then the app needs to be decompiled to find the needed info.

Appium RequirementsSlide12

Device FarmsPerfecto Mobile

Able to be used in a GRID configurationEmulation

Sauce LabsAlong with the server implementation, there is a standalone appWindows -> v 1.4.16

OSX -> v

1.4.13 (with the option to upgrade to 1.5.2)

Server -> v

1.5.2

Appium EnvironmentsSlide13

Appium

GUI: WindowsSlide14

Appium

GUI: WindowsSlide15

Appium

GUI: OS XSlide16

Appium GUI: OS XSlide17

Mobile Selectors: AndroidSlide18

Mobile Selectors: Android

Selectors

come directly

from the layout XMLs that define the app’s

UI.

Resource IDs provide unique element identification

Examples

Checkbox

//*/

android.widget.Checkbox

[@resource-id

=‘

crime_solved

’]

Editable Text Field

//*/

android.widget.EditText

[@resource-id=‘

crime_title

’]Slide19

iOS is not as direct as AndroidUI Automation JavaScript framework defines the element type

UI Automation framework taps into the Accessibility frameworkSame framework that is used by

Xcode Instruments to do automation.https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/UIAutomationRef

/

True unique

i

dentifiers require specific UI element attribute changes from the developer.

Mobile Selectors: iOSSlide20

Mobile Selectors: iOSSlide21

Mobile Selectors: iOS

var

target = UIATarget.localTarget

();

target.frontMostApp

().

mainWindow

().

textViews

()[0].

tapWithOptions({tapOffset

:{x:0.58, y:0.98

}}).tap();

target.frontMostApp

().keyboard().

typeString

(“The Sun is out! It feels great!");

IOSElement

element =

this.appiumDriver.FindElement

(

By.Xpath

(“//*/

UIATextView

[1]”));

e

lement.SendKeys

(“

The Sun is out! It feels great

!");

DiaryEntryPage

diaryEntry

= new

DiaryEntryPage

();

diaryEntry.setDiaryEntryBodyText

(“The Sun is out! It feels great!”);Slide22

Android and iOS element attributes are differentEach OS has element attributes that the other does not which leads to different paths to find the element.

App Switching

Currently can’t automate outside of the target app’s “sandbox” in iOSAndroid has issues with this as well, but for different reasons.App Switching breaks the automation session and stops the automation

Recent developments could lead to this no longer being an issue

Quirks and NuancesSlide23

Supports Mobile Chrome and SafariMost desktop automation test should be transferrable to a mobile browser automation stack

Mobile Browser AutomationSlide24

Setup is easier due to how Android permissions system level appsStandard Appium device configuration

Add the browser name parameter (Chrome or Internet)Uses a variation of chrome driver

Node.js wrapper

Mobile Browser Automation: AndroidSlide25

Currently has a number of requirements and moving partsiOS does not allow Appium to open system level apps

We don’t have developer level ownershipSettings

CalculatorCalendarSafari Launcher is required

Developer-signed

Since there is not an Appium wrapper safari driver, we need to get creative.

iOS

WebKit

Debug Proxy

Mobile Browser Automation: iOSSlide26

Mobile Automation paired with Services automationGives the ability to generate and manipulate data, then test the application to see if the changes are properly reflected

Regression and Smoke Tests

Let a machine do the repetitive stuffSystem stability check Unexpected scenario/data

changes

Reinforcements!Slide27

Quick proof of capability with Selenium GRIDTests

Invalid Login

Login portal loadsSuccessful login

4 iOS Devices

iPhone 5s – iOS 8.1.4

iPhone 6s – iOS 9.0.2

iPhone 6 Plus – iOS 8.0.4

iPhone 6s Plus – iOS 9.3.2

App State managed by uninstalling and reinstalling the app on each test execution

Short VideoSlide28

Short Video