GUI(Graphical User Interface) Testing

To understand GUI Testing lets first understand!!!

What is GUI ?

There are two types of interfaces in a computer application.

Command Line Interface is where you type text and computer responds to that command.

GUI stands for Graphical User Interface where you interact with the computer using images rather than text.

Following are the GUI elements which can be used for interaction between the user and application:

GUI Elements

What is GUI Testing?

Graphical User Interface (GUI) testing is the process of testing the system’s GUI of the System Under Test. GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of bars – tool bar, menu bar, dialog boxes and windows etc.

What do you Check in GUI Testing ?

The following checklist will ensure detailed GUI Testing.

  • Check all the GUI elements for size, position, width, length and acceptance of characters or numbers. For instance, you must be able to provide inputs to the input fields.
  • Check you can execute the intended functionality of the application using the GUI
  • Check Error Messages are displayed correctly
  • Check for Clear demarcation of different sections on screen
  • Check Font used in application is readable
  • Check the alignment of the text is proper
  • Check the Color of the font and warning messages is aesthetically pleasing
  • Check that the images have good clarity
  • Check that the images are properly aligned
  • Check the positioning of GUI elements for different screen resolution.

Approach of GUI Testing:

GUI testing can be done through three ways:

Manual Based Testing

Under this approach, graphical screens are checked manually by testers in conformance with the requirements stated in business requirements document.

Manual Testing

Record and Replay

GUI testing can be done using automation tools. This is done in 2 parts. During Record , test steps are captured into the automation tool. During playback, the recorded test steps are executed on the Application Under Test. Example of such tools – QTP .

Record and PlayBack Testing

Model Based Testing

A model is a graphical description of system’s behavior. It helps us to understand and predict the system behavior. Models help in a generation of efficient test cases using the system requirements. Following needs to be considered for this model based testing:

  • Build the model
  • Determine Inputs for the model
  • Calculate expected output for the model
  • Run the tests
  • Compare the actual output with the expected output
  • Decision on further action on the model

Some of the modeling techniques from which test cases can be derived:

  • Charts – Depicts the state of a system and checks the state after some input.
  • Decision Tables – Tables used to determine results for each input applied

Model based testing is an evolving technique for the generating the test cases from the requirements.Its main advantage, compared to above two methods, is that it can determine undesirable states that your GUI can attain.


Success of a software product immensely depends on how the GUI interacts with the user and ease in using its various features. Hence GUI testing is very important. Manual GUI testing can sometimes be repetitive and boring and hence error prone. Automation is highly recommended for GUI testing.


Android Mobile Apps Automation using UI Automator

Currently as a Sr. QA Engineer , I have been spending most of the time at work writing automation scripts for Android apps rather than manual testing. I have already written automation scripts for three android mobile apps for my company.

I never really thought that this would be easy . Google has provided a tool named ‘UI Automator’ for executing Automation scripts for Android in a pretty simple manner. It comes under UI Testing. UI testing ensures that the app returns the correct UI output in response to a user actions on a device, say keyboard input or pressing toolbars, menus, dialogs, images, and other UI controls. It reduces a lot of manual testing job and saves a lot of time.

Android SDK provides with uiautomator , a java library to automate and run the tests. Along with this , it also provides a GUI tool called uiautomatorviewer to inspect the layout hierarchy and view the properties of the individual UI components on your test device.

‘uiautomatorviewer’ Overview –

[1] ‘uiautomatorviewer’ tool can be used to take a snapshot of the foreground UI screen on any Android device which is connected to your machine.

[2] Make sure ‘USB Debugging’ is ‘ON’ when using uiautomatorviewer. For that : Go to ‘Settings’ on your device -> ‘Developer Options’ -> check ‘USB debugging’ option.


[3] Keep your Android SDK updated to latest version. Open Eclipse -> Go to ‘Window’ in toolbar -> ‘Android SDK Manager’. It will display the updates there. Install all packages and keep it up-to-date.

[4] To take screen shot of foreground UI screen :

  • Connect your device to your development machine.
  • Open command prompt.
  • ‘uiautomatorviewer’ is a batch file which exists inside ‘tools’ folder of ‘sdk’. So you can go to your ‘tools folder inside ‘sdk’ in command prompt and type ‘uiautomatorviewer’ there :


or directly click on that batch file from your tools folder and use.

  • One empty window will open :


[5] Hover on the second ‘green’ button on the top. It shows ‘Device Screenshot’. Click    on it and you will get UI screen of what ever is open on your device :


Accessing  elements  through  uiautomatorviewer –

[1] Say , we open ‘Clock’ app in any Android device. So that screenshot would appear like :


[2] Hover on the screenshot to view elements hierarchy. As you keep hovering over        the elements on the screenshot -> you will observe that the ‘Node Detail’ (at right bottom) and the hierarchy (right top) keeps changing.

[3] Say , now I want to access the current date on clock app. So for that , I hover on the date :


[4] For reference , I have marked some element properties with red as shown in above screenshot. So from that , we get to know that :

Today’s date has :

  • resource id  :
  • text : Wed , April 23
  • content-desc : Wednesday , April 23
  • index : 0
  • class : android.widget.TextView
  • package :
  • enabled : true
  • other properties : false

We will create a demo script which shows how to access time on clock.

Frequently  used  Classes  in  UI Automator

Some most common frequently used classes in UI Automator are :

[1] UiDevice :

Provides access to device state , serving purpose like  :

i) ‘Home’ button press :


ii) Click on something using (x,y) coordinates : x , int y);

iii) ‘Back’ button press :


Full details can be found here for this class here.

[2] UiSelector :

Used to mention search criteria for an element , refining elements based on text , content-desc , class etc. If more than one matching element is found : it returns the first matching element in the hierarchy. If no matching element is found : ‘UiAutomatorObjectNotFoundException’ is thrown. ‘childSelector()’ method ca be used here for nested UiSelector instances.

Some examples to access elements through :

i) text :

new UiObject(new UiSelector().text("abcd");

ii) resource-id:

new UiObject(new UiSelector().resourceId("com.example.abcd");

iii) Nested : Find the first ListView in the currently displayed UI, then search within that ListView to find a UI element with the text property Apps :

UiObject appItem = new UiObject(new UiSelector().className("android.widget.ListView").
instance(1) .childSelector(new UiSelector().text("Apps")));

Full details can be found here for this class here.

[3] UiObject :

Represents a UI element. UiSelector is used to create a UiObject instance showing how to search for element.

Instances can be created as :

UiObject yes_button = new UiObject(new UiSelector().text("YES");
//searching for button on screen
if (yes_button.exists()) {;

UiObject instances can be reused in code.

Full details can be found here for this class here.

[4] UiScrollable :

Can be used for horizontal/vertical scroll on screen. Can be useful when you need to swipe on screen to bring any specific element into view.

Example : how to simulate scrolling down the Settings menu and clicking on an ‘About phone’ option:

UiScrollable settings = new UiScrollable(new UiSelector() .

UiObject about = settingsItem.getChildByText(new UiSelector() .
className("android.widget.LinearLayout"), "About phone");; 

Full details can be found here for this class here.

Executing  Basic  Script –

FIRST  STEP : Creating  a  new  project

[1] Create a new java project in Eclipse :

  • Go to ‘File’ -> ‘New’ -> ‘Java Project’


[2] Add project name and click ‘Next’ –


[3] Click ‘Finish’ –


[4] Expand your project. Right click on src folder -> ‘New’ -> ‘Class’ –


[5] Enter ‘Name’ for class. Also mention ‘Package’ and then click ‘Finish’ –


[6] You will see something like –


SECOND  STEP : Adding  required  jar  files

[1] We need to add uiautomator and android jar files along with JUnit library. For that :

  • Right click on your project -> open ‘Properties’.
  • Go to ‘Java Build Path’ from left menu.
  • Open ‘Libraries’ section –


[2] Click on ‘Add External JARs’ . Navigate to your platforms folder inside sdk say like ‘../android-sdk/platforms’ . Select your highest platform here say platform-19 : you will find uiautomator.jar and android.jar. Just select both and add them –


[3] Now click -> ‘Add Library’ -> select JUnit –


[4] Click ‘Next’ -> then ‘Finish’. Then ‘Ok’. You will see that the jar files and JUnit are added to your project –


THIRD  STEP : Writing  script

Now we will be writing basic script say to view current date and time on clock app –

package com.bharath.firsttest;


public class FirstTestCases extends UiAutomatorTestCase {

  public void testDemo() throws UiObjectNotFoundException,
      InterruptedException {

    // Simulate a short press on the HOME button.

    // simulate click on All Apps screen.
    // All Apps button’s content-description property has the value “Apps”
    UiObject allAppsButton = new UiObject(
        new UiSelector().description("Apps"));

    // Simulate a click to bring up the All Apps screen.

    // Simulate click on 'Apps' section
    UiObject appsTab = new UiObject(new UiSelector().text("Apps"));

    // Simulate a click to enter the Apps tab.;

    // Simulate a user swiping until they come to the Clock app icon
    UiScrollable appViews = new UiScrollable(
        new UiSelector().scrollable(true));

    // Set the swiping mode to horizontal - default is vertical

    // Create a UiSelector to find the Clock app and simulate
    // a user click to launch the app.
    UiObject clock_app = appViews.getChildByText(new UiSelector()
        .className(android.widget.TextView.class.getName()), "Clock");

    // Validate that the package name is the expected one
    UiObject clock_validation = new UiObject(
        new UiSelector().packageName(""));
    assertTrue("Unable to detect Clock App", clock_validation.exists());
    System.out.println("Clock App launched");

    // adding 5sec delay after app is launched

    // get current time
    UiObject time = new UiObject(
        new UiSelector().resourceId(""));
    String current_time = time.getContentDescription();
    System.out.println("Current Time : " + current_time);

    // get current date
    UiObject date = new UiObject(
        new UiSelector().resourceId(""));
    String todays_date = date.getText();
    System.out.println("Today's Date : " + todays_date);
FOURTH  STEP : Building  and  Deploying  test

Once you have written your test script , you need to build and deploy your JAR. We can mention all the steps in one batch file and just execute that.

  • Open a text file and write the following steps :
Echo build output jar file
call android.bat create uitest-project -n FirstTest -t 13 -p

Echo set home variable
set ANDROID_HOME=D:\Android Development\android-sdk

Echo navigating to project directory where build.xml file is located
cd D:\Android_Workspace1\FirstTest

Echo build test JAR
call ant build

Echo navigating to platform-tools directory
cd D:\Android Development\android-sdk\platform-tools

Echo deploying generated test JAR file to device
adb push D:\Android_Workspace1\FirstTest\bin\FirstTest.jar /data/local/tmp/

Echo running script
adb shell uiautomator runtest FirstTest.jar -c com.smriti.firsttest.FirstTestCases

Echo Test Complete

  • Save text file as “.bat” extension inside your sdk tools folder.
  • Open cmd now and navigate to your tools folder :
  • run_batch_file
  • Write your batch file name and press ‘Enter’.
  • Script will start and finally output will appear :output

This is how anyone can run a sample script.

It didn’t seem so easy at first but now I am comfortable writing automation scripts for Android and I keep sending automated emails to my team members whenever I run my script on any app builds :)

Automating hybrid apps

One of the core principles of Appium is that you shouldn’t have to change your app to test it. In line with that methodology, it is possible to test hybrid web apps (e.g., the UIAWebView elements in an iOS app) the same way you can with Selenium for web apps. There is a bit of technical complexity required so that Appium knows whether you want to automate the native aspects of the app or the web views, but thankfully, we can stay within the WebDriver protocol for everything.

Here are the steps required to talk to a web view in your Appium test:

  1. Navigate to a portion of your app where a web view is active
  2. Call GET session/:sessionId/contexts
  3. This returns a list of contexts we can access, like ‘NATIVE_APP’ or ‘WEBVIEW_1’
  4. Call POST session/:sessionId/context with the id of the context you want to access
  5. (This puts your Appium session into a mode where all commands are interpreted as being intended for automating the web view, rather than the native portion of the app. For example, if you run getElementByTagName, it will operate on the DOM of the web view, rather than return UIAElements. Of course, certain WebDriver methods only make sense in one context or another, so in the wrong context you will receive an error message).
  6. To stop automating in the web view context and go back to automating the native portion of the app, simply callcontext again with the native context id to leave the web frame.
// javascript
// assuming we have an initialized `driver` object for an app
    .contexts().then(function (contexts) { // get list of available views. Returns array: ["NATIVE_APP","WEBVIEW_1"]
        return driver.context(contexts[1]); // choose the webview context

    // do some web testing

    .context('NATIVE_APP') // leave webview context

    // do more native stuff here if we want

    .quit() // stop webdrivage
// java
// assuming we have a set of capabilities
driver = new AppiumDriver(new URL(""), capabilities);

Set<String> contextNames = driver.getContextHandles();
for (String contextName : contextNames) {
    System.out.println(contextNames); //prints out something like NATIVE_APP \n WEBVIEW_1
driver.context(contextNames.toArray()[1]); // set context to WEBVIEW_1

//do some web testing
String myText = driver.findElement(By.cssSelector(".green_button")).click();


// do more native testing if we want

# ruby
# assuming we have a set of capabilities
@driver = Selenium::WebDriver.for(:remote, :desired_capabilities => capabilities, :url => SERVER_URL)

# I switch to the last context because its always the webview in our case, in other cases you may need to specify a context
# View the appium logs while running @driver.contexts to figure out which context is the one you want and find the associated ID
# Then switch to it using @driver.switch_to.context("WEBVIEW_6")

Given(/^I switch to webview$/) do
    webview = @driver.contexts.last

Given(/^I switch out of webview$/) do

# Now you can use CSS to select an element inside your webview

And(/^I click a webview button $/) do
    @driver.find_element(:css, ".green_button").click
# python
# assuming we have an initialized `driver` object for an app

# switch to webview
webview = driver.contexts.last

# do some webby stuff
driver.find_element(:css, ".green_button").click

# switch back to native view

# do more native testing if we want

// php
// assuming we have an initialized `driver` object in an AppiumTestCase

public function testThings()
        $expected_contexts = array(
                0 => 'NATIVE_APP',
                1 => 'WEBVIEW_1'

        $contexts = $this->contexts();
        $this->assertEquals($expected_contexts, $contexts);

        $context = $this->context();
        $this->assertEquals('WEBVIEW_1', $context);

        // do webby stuff


        // do mobile stuff

Automating hybrid Android apps

Appium comes with built-in hybrid support via Chromedriver. Appium also uses Selendroid under the hood for webview support on devices older than 4.4. (In that case, you’ll want to specify "automationName": "selendroid" as a desired capability).

Make sure setWebContentsDebuggingEnabled is set to true as described in the remote debugging docs.

Once you’ve set your desired capabilities and started an appium session, follow the generalized instructions above.

Automating hybrid iOS apps

To interact with a web view appium establishes a connection using a remote debugger. When executing against a simulator this connection is established directly as the simulator and the appium server are on the same machine.

Once you’ve set your desired capabilities and started an appium session, follow the generalized instructions above.

Execution against a real iOS device

When executing against a real iOS device appium is unable to access the web view directly. Therefore the connection has to be established through the USB lead. To establish this connection we use the ios-webkit-debugger-proxy.

For instruction on how to install and run ios-webkit-debugger-proxy see iOS webkit debug proxy documentation.

Now you can start an appium test session and follow the generalized instructions above.

Android Automation using Appium in Windows

Advantages  of  using  Appium :

  • It uses WebDriver API (i.e ‘Selenium WebDriver‘) which provides a client-server protocol (known as the JSON Wire Protocol) thus making it possible to write the test code in any language.
  • Appium is a server which is written in node.js and can be built and installed from source or directly from npm.
  • There are client libraries (in Java, Ruby, Python, PHP, JavaScript, and C#) which can be used instead of regular WebDriver client.
  • Last but not the least – it is Open-Source.

Appium  on  Windows  (Requirements) :

Following things will be required as we work on appium android automation on windows platform –

  1. Appium.exe
  2. Android SDK API >= 17
  3. Java JDK
  4. Apache Ant
  5. Eclipse
  6. Android Emulator or an Android Device
  7. Selenium Server (formerly the Selenium RC Server) version (download link)
  8. Appium Client Library jar file (according to your language choice) (download link)
  9. .apk‘ file of the app on which tests will be executed.

We would be using java-client here for client library as we discuss further.

 Pre – Conditions –

[i]  Set  Environment  Variables –

Make sure you set up environment variables correctly before executing any script. All these variables should be set under ‘System variables’ not in ‘User variables’.

Depending on the location where you have jdk, android-sdk and ant installed in your machine, path should be specified . For example ,in my machine , path is specified as –

    • C:\Program Files\Java\jdk1.8.0_25
    • D:\Android_Development\android_sdk
    • C:\apache-ant-1.9.4
  • PATH variable (would contain System32 , platform-tools , tools ,ant bin and jdk bin set) –
    • C:\Windows\System32;D:\Android_Development\android_sdk\platform-tools;%JAVA_HOME%\bin;D:\Android_Development\android_sdk\tools;%ANT_HOME%\bin;
[ii]  USB Debugging ‘ON’ –

Make sure the device which you are connecting to your PC to run tests on has Developer Options enabled and USB debugging option is checked there as shown below –


Executing   Basic   Script –

FIRST   STEP  :  Creating   a   new   project

[1] Create a new java project in Eclipse :

  • Go to ‘File’ -> ‘New’ -> ‘Java Project’

[2] Add project name and click ‘Next’ –

[3] Click ‘Finish’ –

[4] Expand your project. Right click on src folder -> ‘New’ -> ‘Class’ –

[5] Enter ‘Name’ for class.  Also mention ‘Package’ and then click ‘Finish’ –

[6] You will see something like –

SECOND   STEP  :  Adding   required   jar   files

[1] You will need to export required selenium jar files in your project.

  • Selenium Server (formerly the Selenium RC Server) version here.
  • Appium Client Library jar file (according to your language choice) from here.

[2] Import all these jar files in your project.

  • Right click on your project -> Properties.
  • Go to Libraries section -> Add External JARs (Note: I am using java client here)
  • Select both jar files which needs to be added -> click on ‘Open’ -> then tap ‘OK’.

THIRD   STEP  :  Download  Appium

Download Appium for Windows zip file here and extract the zip file contents. After Appium is downloaded , you will find an “Appium.exe” application inside extracted ‘Appium’ folder.

FOURTH   STEP  :  Understanding   Appium   Parameters
  1. Launch Appium.exe and you would see following buttons –
    1. Android button
    2. Settings button
    3. Developer Settings
    4. About
    5. Inspector (magnifying glass icon)
    6. Launch/Stop button
    7. Delete (trash icon)
  2. launch_appiumHover over gear icon and you would see “General Settings”. Tap on it. Some important points to note here –general_settings_appium
    1. You would see “Server Address” (IP address on which you want the Appium server to run) and “Port” (port on which the Appium server will listen for WebDriver commands)  as it shows “” (localhost) and “4723” respectively here –
    2. “Check for Updates” is to check regular Appium updates.
    3. “Pre-Launch Application” is to prelaunch the application before any commands start executing.
    4. “Override Existing Session” can be checked to override any existing Appium sessions(if any).
  3. Now hover over android icon and you would see “Android Settings. Tap on it and you will see a window opens up with too many fields.
  4. Under “Application” section , some fields which we can consider here –
    1. “Application Path” – You should check this option and can tap on ‘Choose’ and give the path of your ‘.apk’ file downloaded which you want to test.
    2. “Package” – This is the package name of your test application (ex – com.example.testApp)
    3. “Launch Activity” – Activity name for the Android activity which needs to be launched from your package.
  5.  Under “Capabilities” section –
    1. “Platform Name” – mobile platform.
    2. “Automation Name” – automation tool (Android or Selendroid).
    3. “Platform Version” – mobile platform version.
    4. “Device Name” – name of the device you would be testing on.
  6.  Hover on the magnifying glass and you can all the elements accessible on the screen. Appium should be running for inspector to work. An example screenshot of “Settings” section of an android device can be viewed in Inspector as –inspector_window
  7. Through appium inspector – you can view name , value , label , xpath of different elements on the screen. Given below are some examples how to use elements from the screen using xpath , tagName, name, attribute etc .
//webdriver declaration
  public WebDriver driver ;      

  //using xpath

  //using name

  //using attribute –
  WebElement x = driver.findElement( By.xpath("//window[1]/tableview[1]/cell[2]/text[1]");
  x.getAttribute("name"); //get name of the element

  //using tagName

  //sendkeys can be used for giving some input in any field
  WebElement login_email =  driver.findElement(By.xpath("//window[1]/scrollview[1]/textfield[1]"));;

  //provide delay between two event clicks
  Thread.sleep(time in milliseconds);

Note – You can run your test scripts either in simulator or on real device. Refer about Appium parameters detailed information here.

FIFTH   STEP  :  Writing  Script

Now we will have a look at one sample script.

Following desired capabilities need to be taken care of while writing script for android automation (Desired capabilities are a set of keys to communicate with Appium server to tell the server what kind of automation session you are interested in) –

  • platformName (mobile platform)
  • platformVersion (mobile platform version)
  • deviceName (name of device on which you are running test)
  • app (path to your ‘.apk’ file)
  • appPackage (app package)
  • appActivity (main activity class)
package com.bharath.firsttest;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;

public class FirstTestCases {

  // webdriver declaration
  public WebDriver driver;

  public static void main(String[] args) throws Exception {

    // creating a class object
    FirstTestCases testcases = new FirstTestCases();

    // call launch app method

    // call add name method

  public void launchApp() throws Exception {

    System.out.println("Launching App");
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability("platformName", "Android");
    capabilities.setCapability("platformVersion", "4.3");
    capabilities.setCapability("deviceName", "S3");
    capabilities.setCapability("app", "D:\\Apps\\TestApp.apk");
    capabilities.setCapability("app-package", "com.example.testApp");
    capabilities.setCapability("app-activity", ".SplashActivity");
    driver = new RemoteWebDriver(new URL(""),
    Thread.sleep(20000); // delay of 20s
    System.out.println("App Launched");

  public void addName() throws InterruptedException {

    System.out.println("Adding Name");
    String myname = "Smriti";
    Thread.sleep(5000); // 5s delay

    // write all your tests here

SIXTH   STEP  :  Run  Script

After writing the test script , follow these steps to run your test –

  1. Open Appium.exe.
  2. Go to ‘General Settings’ and check that ‘Server Address’ and ‘Port’ should be set as “” and “4723” respectively.
  3. Go to ‘Android Settings’ add your ‘.apk’ file path(path where you downloaded the apk file in your machine) under “Application Path”. You will notice that it takes up ‘Package’ and ‘Launch Activity’ paths automatically when you enter the apk file path.
  4. Under ‘Capabilities’ section –
    1. Make sure ‘Platform Name’ and  ‘Automation Name’ are set to ‘Android’ and ‘Appium’ respectively considering you aren’t using older android versions. If yes , chose ‘Selendroid’.
    2. Select ‘PlatformVersion’ based on mobile platform version you are working on.
    3. Select checkbox next to Device Name and mention your device name there say “S3” if my Samsung S3 device name is S3.
  5. Now trigger Appium server by tapping on launch button.
  6. Now go to Eclipse and run your project as a ‘Java Application’ –
  7. run_java_fileOnce Appium server is triggered and your test app launches , you can tap on Appium Inspector and view all accessible elements on any active screen and write test cases accordingly and execute.

There you go running your first test script in Android platform using Appium in Windows 😀

So this was all about Android Mobile Automation using Appium tool on Windows platform. Stay tuned for more posts!!

iOS Mobile Automation using Appium

Appium – an open source, cross-platform test automation tool which can be used for native, hybrid and mobile web apps. It requires :

  • Mac OS X 10.7 or higher, 10.8.4 recommended
  • XCode >= 4.6.3

It drives various native automation frameworks and provides an API based on Selenium’s WebDriver JSON wire protocol. It drives Apple’s UIAutomation library for iOS support.

Appium can be useful for automation as :

  • We can write tests with Selenium WebDriver API and language specific client libraries with any of the WebDriver compatible language say Java , Objective-C , Javascript , PHP , Python , C# , Ruby , Clojure or Perl.
  • Any testing framework can be used.

So I thought of trying this tool out with Java language in Eclipse as I have been using the same for my Android automation as well and I chose TestNG framework. Testing framework will be required if you want any way to log your results for your purpose otherwise you can even skip this.

To start with , you will be need :

  • Selenium Server in order to run either Selenium RC style scripts or Remote Selenium Webdriver ones.
  • Language specific client drivers
  • TestNG framework (optional)
  • Appium app to launch appium server
  • Eclipse
How  to  use  Appium –

  • Appium uses ‘Appium Inspector’ to view the elements similar to what we have as ‘uiautomatorviewer’ tool to view UI components in Android in UI Automator. You can access elements using name , xpath or tagName as visible through appium inspector.
  • Appium Inspector can be launched by clicking on the blue ‘i’ button besides ‘Launch’ button from appium app.
  • Through appium inspector – you can view name , value , label , xpath of different elements on the screen.

Some examples how to use elements from the screen using xpath , tagName, name, attribute is here –

  1. //webdriver declaration
  2. public WebDriver driver ;
  3. //using xpath
  4. driver.findElement(By.xpath(“//window[1]/scrollview[1]/button[1]”));
  5. //using name
  6. driver.findElement(“Go”));
  7. //using attribute –
  8. WebElement x = driver.findElement(By.xpath(“//window[1]/tableview[1]/cell[2]/text[1]”));
  9. x.getAttribute(“name”); //get name of the element
  10. //using tagName
  11. driver.findElement(By.tagName(“button”));
  12. //sendkeys can be used for giving some input in any field
  13. WebElement login_email = driver.findElement(By.xpath(“//window[1]/scrollview[1]/textfield[1]”));
  15. login_email.sendKeys(“”);
  16. //provide delay between two event clicks
  17. Thread.sleep(time in milliseconds);

NOTETo run automation scripts for iOS , you need a Mac machine. It can’t be done on Windows as Xcode needs to be present for Appium to work. 

You will not be able to test iOS apps on a locally hosted server, because Apple’s instruments binary, which Appium uses to launch the iOS simulator by default uses the currently-selected Xcode, and the highest iOS SDK installed with that version of Xcode.

Executing  Basic  Script –

FIRST  STEP : Creating  a  new  project

[1] Create a new java project in Eclipse :

  • Go to ‘File’ -> ‘New’ -> ‘Java Project’


[2] Add project name and click ‘Next’ –


[3] Click ‘Finish’ –


[4] Expand your project. Right click on src folder -> ‘New’ -> ‘Class’ –


[5] Enter ‘Name’ for class. Also mention ‘Package’ and then click ‘Finish’ –


[6] You will see something like –


SECOND  STEP : Adding  required  jar  files

[1] You will need to export required selenium jar files and install your testing framework (if required) in your project.

For that , download :

i) Selenium Server (formerly the Selenium RC Server) version and

ii) Required client driver (according to your language choice) under – Selenium Client & WebDriver Language Bindings.

Selenium server and client drivers can be downloaded from here – .

[2] Import all these jar files in your project.

Right click on your project -> Properties -> Libraries -> Add External JARs. Add all three selenium jar files here.


Optional – If you want to use TestNG  :  Go to Help -> install new software -> use :



Download Appium app depending on your platform either Mac/Win – 

You can use  ‘IP Address’ as ‘’ and port ‘4723’.


To run scripts on real device , you will need “UDID” (Device ID) and “Bundle ID” (Application Bundle ID) of your app :


To run scripts on simulator , you will need “.app” and “Bundle ID” of your app (Force device also can be left unchecked)  :


NOTE : You can run your test scripts either in simulator or on real device but I would recommend using iOS simulator as it responds faster than real device. Desired capabilties need to be updated depending on whether you run on simulator or real device.

(Desired capabilities are a set of keys to communicate with Appium server to tell the server what kind of automation session you are interested in).

To Run on Simulator –
public WebDriver driver = null;
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(CapabilityType.BROWSER_NAME, "iOS");
capabilities.setCapability(CapabilityType.VERSION, "6.1");
capabilities.setCapability(CapabilityType.PLATFORM, "Mac");
capabilities.setCapability("device", "iPhone");
driver = new RemoteWebDriver(new URL(""), capabilities);
To Run on Real Device –
public WebDriver driver = null;
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability("device", "iPhone");
capabilities.setCapability("udid", "1234567890abcdef");
capabilities.setCapability("bundleid", "com.example.appiumiphonetest");
capabilities.setCapability("ipa", "MyiOSApp.ipa");
driver = new RemoteWebDriver( new URL(""), capabilities);

There are two ways to get the “.app” of your application :

[1] You can build your app using xcode. Not down the build path of your application – that would be the location where your ‘.app’ file will be created.

Ex – I ran my build on iPhone simulator 4-inch , 7.0.3. My ‘.app’ was generated at the following path :

‘/Users/Library/Application Support/iPhone Simulator/7.0.3/Applications/’.

[2] If your app is in store :

– Download app from itunes store. Then open that file in finder.

– There will be one plist file -> you can get bundle id from there.

package com.bharath.firstest;

import java.util.List;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.remote.CapabilityType;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class FirstTest {

  public WebDriver driver = null;

  public void setUp() throws Exception {

    // set up appium

    File appDir = new File("/Users/abc/Desktop/smriti/iPhoneSimulator");

    File app = new File(appDir, "");

    DesiredCapabilities capabilities = new DesiredCapabilities();

    capabilities.setCapability(CapabilityType.BROWSER_NAME, "");

    capabilities.setCapability(CapabilityType.VERSION, "7.1");

    capabilities.setCapability(CapabilityType.PLATFORM, "Mac");

    capabilities.setCapability("app", app.getAbsolutePath());

    driver = new RemoteWebDriver(new URL(""),

    System.out.println("App launched");


  public void tearDown() throws Exception {

  public void testCases() throws InterruptedException {

    String myname = "Smriti";



    // write all your tests here

  • I copied my ‘.app’ file from that location to a folder in my local here – ‘/Users/abc/Desktop/smriti/iPhoneSimulator. That is what it shows in code :
    1. File appDir = new File(“/Users/abc/Desktop/smriti/iPhoneSimulator”);
    2. File app = new File(appDir, “”);
  • @BeforeMethod is for appium setup and app launch.
  • @Test is for writing all test cases after app launch .
  • @AfterMethod is after test cases are complete.

I have started using appium for native mobile iOS apps automation. Let’s see how it goes.

Monkey Way Of Testing – Monkey Runner


The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events.

You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner.


The Monkey is a command-line tool that that you can run on any emulator instance or on a device. It sends a pseudo-random stream of user events into the system, which acts as a stress test on the application software you are developing.

The Monkey includes a number of options, but they break down into four primary categories:

  • Basic configuration options, such as setting the number of events to attempt.
  • Operational constraints, such as restricting the test to a single package.
  • Event types and frequencies.
  • Debugging options.

When the Monkey runs, it generates events and sends them to the system. It also watches the system under test and looks for three conditions, which it treats specially:

  • If you have constrained the Monkey to run in one or more specific packages, it watches for attempts to navigate to any other packages, and blocks them.
  • If your application crashes or receives any sort of unhandled exception, the Monkey will stop and report the error.
  • If your application generates an application not responding error, the Monkey will stop and report the error.

Depending on the verbosity level you have selected, you will also see reports on the progress of the Monkey and the events being generated.

Basic Use of the Monkey

You can launch the Monkey using a command line on your development machine or from a script. Because the Monkey runs in the emulator/device environment, you must launch it from a shell in that environment. You can do this by prefacing adb shell to each command, or by entering the shell and entering Monkey commands directly.

The basic syntax is:

$ adb shell monkey [options]

With no options specified, the Monkey will launch in a quiet (non-verbose) mode, and will send events to any (and all) packages installed on your target. Here is a more typical command line, which will launch your application and send 500 pseudo-random events to it:

$ adb shell monkey -p -v 500

Command Options Reference

The table below lists all options you can include on the Monkey command line.

Category Option Description
General –help Prints a simple usage guide.
-v Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little information beyond startup notification, test completion, and final results. Level 1 provides more details about the test as it runs, such as individual events being sent to your activities. Level 2 provides more detailed setup information such as activities selected or not selected for testing.
Events -s Seed value for pseudo-random number generator. If you re-run the Monkey with the same seed value, it will generate the same sequence of events.
–throttle Inserts a fixed delay between events. You can use this option to slow down the Monkey. If not specified, there is no delay and the events are generated as rapidly as possible.
–pct-touch Adjust percentage of touch events. (Touch events are a down-up event in a single place on the screen.)
–pct-motion Adjust percentage of motion events. (Motion events consist of a down event somewhere on the screen, a series of pseudo-random movements, and an up event.)
–pct-trackball Adjust percentage of trackball events. (Trackball events consist of one or more random movements, sometimes followed by a click.)
–pct-nav Adjust percentage of “basic” navigation events. (Navigation events consist of up/down/left/right, as input from a directional input device.)
–pct-majornav Adjust percentage of “major” navigation events. (These are navigation events that will typically cause actions within your UI, such as the center button in a 5-way pad, the back key, or the menu key.)
–pct-syskeys Adjust percentage of “system” key events. (These are keys that are generally reserved for use by the system, such as Home, Back, Start Call, End Call, or Volume controls.)
–pct-appswitch Adjust percentage of activity launches. At random intervals, the Monkey will issue a startActivity() call, as a way of maximizing coverage of all activities within your package.
–pct-anyevent Adjust percentage of other types of events. This is a catch-all for all other types of events such as keypresses, other less-used buttons on the device, and so forth.
Constraints -p If you specify one or more packages this way, the Monkey will only allow the system to visit activities within those packages. If your application requires access to activities in other packages (e.g. to select a contact) you’ll need to specify those packages as well. If you don’t specify any packages, the Monkey will allow the system to launch activities in all packages. To specify multiple packages, use the -p option multiple times — one -p option per package.
-c If you specify one or more categories this way, the Monkey will only allow the system to visit activities that are listed with one of the specified categories. If you don’t specify any categories, the Monkey will select activities listed with the category Intent.CATEGORY_LAUNCHER or Intent.CATEGORY_MONKEY. To specify multiple categories, use the -c option multiple times — one -c option per category.
Debugging –dbg-no-events When specified, the Monkey will perform the initial launch into a test activity, but will not generate any further events. For best results, combine with -v, one or more package constraints, and a non-zero throttle to keep the Monkey running for 30 seconds or more. This provides an environment in which you can monitor package transitions invoked by your application.
–hprof If set, this option will generate profiling reports immediately before and after the Monkey event sequence. This will generate large (~5Mb) files in data/misc, so use with care. See Traceview for more information on trace files.
–ignore-crashes Normally, the Monkey will stop when the application crashes or experiences any type of unhandled exception. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.
–ignore-timeouts Normally, the Monkey will stop when the application experiences any type of timeout error such as a “Application Not Responding” dialog. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.
–ignore-security-exceptions Normally, the Monkey will stop when the application experiences any type of permissions error, for example if it attempts to launch an activity that requires certain permissions. If you specify this option, the Monkey will continue to send events to the system, until the count is completed.
–kill-process-after-error Normally, when the Monkey stops due to an error, the application that failed will be left running. When this option is set, it will signal the system to stop the process in which the error occurred. Note, under a normal (successful) completion, the launched process(es) are not stopped, and the device is simply left in the last state after the final event.
–monitor-native-crashes Watches for and reports crashes occurring in the Android system native code. If –kill-process-after-error is set, the system will stop.
–wait-dbg Stops the Monkey from executing until a debugger is attached to it.

Please let me know your queries


How to Proxying Charles on Android/iOS Devices

Proxy Configuration.


    • Enter Settings.
    • Tap on Wi-Fi
    • Tap & hold on the network you are connected.
    • Tap Modify network.
    • Check the Show advanced options.
    • From Proxy settings dropdown, choose Manual.
    • Set your IP as Proxy hostname.
    • Set a port that you use in charles to log (Example: 8888)
    • Save & Start your app.


    • Enter Settings.
    • Tap on Wi-Fi
    • Scroll down to see Proxy settings
    • Tap on Http Proxy.
    • Set your IP as Proxy hostname.
    • Set a port that you use in charles to log (Example: 8888)

After starting app, application Charles running in PC/Mac will show warning for connection. Allow connection from the device. Application logs will appear in charles.

Please let me know any queries


How to get device logs for Android Devices


USB Debugging:

To take android device log from PC/Mac, USB debugging should be enabled
in device. Following are the steps to enable USB debugging:

USB debugging in Android 4.0.x (Ice cream sandwich)
  • Go to settings.
  • Enter ‘Developer options’.
  • Check on ‘USB Debugging’.
  • Warning popup ‘Allow USB debugging?’ will appear.
  • Tap ‘Ok’ to confirm.

With USB debugging enabled, after connecting device to any PC/Mac, device will be connected as a media device.

Enable USB Debugging in Android Devices
  • Go to Settings > About phone.
  • Then move on to Build number option
  • Tap on Build number repeatedly about 7 times.
  • After touching 7th time you will see a message that, you are now a developer.
  • Now the ‘Developer options’ will be placed in Settings menu.
  • Enter ‘Developer options’.
  • Check on ‘USB Debugging’.
  • Wanring popup ‘Allow USB debugging?’ will appear.
  • Tap ‘Ok’ to confirm.

Getting device log:

Getting device log from PC/Mac:
  • Download android SDK tools. Android SDK tools can be downloaded from here:
  • In tools folder, there is a tool ‘monitor’. Open monitor.
  • Connect the device with PC/Mac. Make sure USB debugging is enabled in device.
  • Device will appear at top right ‘Device’ panel. Select the device (i.e. Nexus 5.1).
  • Device log should appear at the bottom ‘Logcat’ panel.
  • Device log can be filtered with log tag or other parameters.
  • Select the necessary logs.
  • Tap on ‘Save’ button to save.
  • Device log will be saved as text file.

As numerous logs are recorded, clearing logs after saving would save redundancy in saved logs.

Getting device log from device:

There are many apps to record device log in google play store. The app CatLog’ is a convenient one. Note that rooting might be required for devices to record logs using CatLog. Following are steps to record device log using CatLog:

  • Download ‘CatLog’ from google play store.
  • Open CatLog. Keep this app in background while testing app.
  • When device log needs to be saved, open CatLog.
  • Tap on android options button on device.
  • From these options device log can be saved in device or can be sent to =
    an email address as text file.

Please let me know your queries


How to install .apk in Android devices

                                               Install App

Builds transfer

Builds can be transferred to/from android device to PC/Mac using USB cable or Wi-fi. To transfer files using USB cable, make sure UBS debugging is enabled in device.

Builds transfer through USB:

Android file transfer for mac
  • Download & install Android File Transfer
  • Plug the device to Mac with a USB cable.
  • Android file transfer window should launch automatically.
  • Drag & drop builds to/from finder to transfer.
Android file transfer in PC:
  • Plug the device to PC using USB cable.
  • Device should be detected as a media device.
  • Open device in explorer & simply copy paste builds.

Build transfer through Wi-fi:

Files can be transferred over Wi-fi using apps from google play store.
Air Droid’ is a convenient one to use. Following are steps to transfer files through Air droid:

  • Install Air Droid from google play store.
  • Open Air Droid.
  • Open browser & enter address
  • When page opens, enter the code showed in device or scan QR code from the PC/Mac monitor.
  • Device will be connected to PC/Mac. Upload build to device from any location in PC/Mac.

Note: Device & PC/Mac should be in one Wi-fi network.

Installing build:

Install from unknown sources:
  • Before installing build, installation of app from unknown sources should be enabled in device.
  • To do so, enter settings/security.
  • From ‘Device Administration’ section, check on ‘Unknown Sources’.
Install builds:
  • Installing build will require any file manager app. This app does not comes with OS bundle.
  • Download & install any free File Manager app from google play store.
  • Browse to the build location from file manager app.
  • Tap on the build.
  • Installation popup appear.
  • Tap ‘Install’ button & proceed.
  • Build is installed in device.

Installing builds from testflight:

Install Testflight:
  • From the device, open browser & go to
  • Download Testflight App for android.
  • After download & install, create an account or sign in with existing account to access available build. Note that to get a build, the testflight account should should be invited to the project.
Install builds from Testflight:
  • Launch TestFlight in device.
  • Available builds shows in the app.
  • Tap ‘Install’ button & confirm to install the build

Installing builds from ADB:

– Make sure you have installed Eclipse
– Make sure you have installed ADT plug-in
– Make sure you have installed ADB in your machine
– Make sure you have enabled USB debugging

1. Connect Android device to your Machine
2. Open terminal/command prompt
3. Enter command “adb devices” (to verify device is connected with your machine and remote quotes in command line)
4. Enter command “adb install <file name>” (remove text ‘File’ and run)

Please let me know if you have any queries


Software Testing Types

                                                              Testing Types

Black box testing – Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.

White box testing – This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing – Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.

Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing – This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.

System testing – Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.

End-to-end testing – Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing – Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Regression testing – Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing – Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.

Performance testing – Term often used interchangeably with ‘stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.

Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.


Install/uninstall testing – Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products.

Alpha testing – In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing – Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

Please leave comments and doubts, I will try to figure it out.

After all we are Brothers 🙂

Happy Testing!!!