Edit Mobile tests

This topic describes optional editing steps you can perform in the Editor or the Keyword view to modify your Mobile test.

Add simulated events and gestures

Manually add steps to your tests that simulate events and gestures that occur on real mobile devices, such as incoming calls, or a Swipe gesture.

For example:

Simulated incoming SMS

Device("Device").IncomingSMS "1800859645","Hello There",5,False       

Simulated incoming phone call

Device("Device").IncomingCall "180080808080",5,False     

Simulated GPS location change

Device("Device").GPSRelocate 37.500000,-120.300000,5,False        

Back to top

Add steps to open the remote access window

Keep your remote access window closed during a test to maintain performance, and use Device.OpenViewer and Device.CloseViewer steps to open and close it only as needed.

To control the remote access window during the run:

  1. In the UFT One Options dialog, clear the Show application during test run option.

    For details, see Connect to Digital Lab or local mobile devices.

  2. In your test, define the steps where UFT One must "see" the object in order to run.

    Before each of these steps, add a Device.OpenViewer step to open the remote access window.

    After each of these steps, add a Device.CloseViewer step to continue the run session silently.

  3. Ensure that the app to open is defined in one of the following:

    • The Record and Run Settings dialog box; or

    • A preceding step. For example:

      Device("MyDevice").App("MyApp").Launch
      Device("MyDevice").OpenViewer

For more details, see the Mobile section of the UFT One Object Model Reference for GUI Testing

Back to top

Add steps to open different devices

Run each step in your test on different devices by creating unique Device test objects and then modifying your test steps accordingly.

To run steps on different devices:

Create unique Device test objects

Repeat the following steps for each device you want to include in your test.

  1. Define your Record and Run Settings and record your test.

  2. In the Object Repository window (Resources > Object Repository), rename the Device test object with a descriptive name, such as Device_1 or Device_2.

    Your test is automatically updated with the new Device test object name.

  3. In the object repository, define the id description property and value for your Device test object.

    In the Test Object Details pane, select the Device object, and click to open the Add Properties dialog box.

    Define the id property value as the Digital Lab device ID.

    Tip: Enable more flexibility by linking the id description property value to an Environment variable or Data Table parameter.

Edit your test steps for each device

In your test, ensure that each step is configured to use the correct device and app. For example:

Device("Device_1").App("MyApp").Launch DefaultInstallBehavior, DefaultRestartBehavior
Device("Device_1").App("MyApp").MobileList("tableManFirst").Select 5,0
Device("Device_1").App("MyApp").MobileDropDown("RegularPicker").Select "Arman",0
...
...
Device("Device_2").App("AnotherApp").Launch DefaultInstallBehavior, DefaultRestartBehavior
...

Back to top

Add steps to open additional apps

If your test needs to open multiple apps in a single run session, add steps to open each app separately and bring it to the foreground.

Open multiple apps using one of the following methods:

Record Insight steps to open your apps

For details, see Record Insight steps for web apps on your mobile device.

 

Switch apps when recording

For details, see Switch apps.

Use the uiAutomatorViewer

(Android only)

Use the uiAutomatorViewer to do the following:

  1. Identify the device's app launcher and add an App test object to the object repository. For details, see Add an App test object to the object repository.

  2. Create a MobileView test object for the icon of the app you want to open. For details, see Add non-recordable objects to the object repository.

In your test, add steps to open the new app before each relevant step.

For example:

Device("Device").Home
Device("Device").App("Launcher").MobileView("App2").Tap

Back to top

BPT: Add steps to open a browser

In addition to specifying the device and browser in your tests application areas, we recommend adding a step to open the browser on your device in any relevant components in your business process test.

Add a WebUtil.LaunchBrowser step to open the browser, and specify the relevant arguments as needed.

For example, the following step opens the Chrome browser on a Mobile device located in an AWS device farm:

WebUtil.LaunchBrowser "MOBILE_CHROME", "lT-1", "cube", "ANDROID", "5.1", "AWS"

For more details, see the LaunchBrowser Method topic in the UFT One Object Model Reference for GUI Testing.

Back to top

Avoid consecutive Browser.Navigate steps

Avoid adding a Browser.Navigate as the first step in your test, especially if the Record and Run Settings are set to open a specific browser page when starting the test.

For example, if the URL in the Record and Run Settings is set to www.bing.com, do not have the following as the first line in your script:

Browser.navigate "www.google.com"

Instead, modify the URL to www.google.com, and remove the first step in your script.

Additionally, if you have two consecutive Browser.Navigate steps, such as:

Browser.navigate "www.google.com"
Browser.navigate "www.baidu.com"

add a Wait statement between the two steps, or simply remove the first Navigate step.

Back to top

Runtime property values and mobile testing

UFT One does not have a runtime object that can be bound to the mobile test object. Therefore, any UFT action that takes values from the bounded runtime object will not have values.

For example:

Description properties

When adding description properties to the object repository, initial values are either blank or they have default values (for example, Boolean property values such as True/False).

Standard checkpoints

When adding a standard checkpoint, initial property values are blank.

Values of runtime properties are taken from the Digital Lab application details.

Back to top

Simulate authentication

Add steps to your test manually to simulate a fingerprint authentication, or facial recognition on iOS devices.

Authentication simulation is supported for test replay only.

When recording your test, do one of the following to authenticate:

  • If you have access to the physical device, manually perform the fingerprint or facial recognition authentication. This authentication will not be recorded.
  • If the device is not accessible, perform an alternative authentication.

Then, before playing your test, manually add a SimulateAuthentication step at the point in the test where fingerprint authentication occurs.

Use the following syntax:

Device("<device_ID>").App("<app_name>").SimulateAuthentication ("<Result>","<Reason>")

For details, see SimulateAuthentication in the UFT One Object Model Reference and the Digital Lab Help.

Sample authentication simulation

The following steps show a failed authentication due to a lockout.

Device("Device").App("UICatalog8INJ").MobileButton("UICatalog").Tap

Device("Device").App("UICatalog8INJ").MobileList("MobileList").Scroll 5,0

Device("Device").App("UICatalog8INJ").MobileList("MobileList").Select 21,0

Device("Device").App("UICatalog8INJ").MobileButton("Try to authenticate").Tap

Device("Device").App("UICatalog8INJ").SimulateAuthentication "Failure", "Lockout"

Note: When you run the simulation in replay, the Digital Lab Simulation Authentication dialog box will not open.

Back to top

Edit mobile tests using standard UFT One features

Use standard UFT One features to edit your mobile tests, such as conditional and loop statements, descriptive programming, and the Object Spy.

For more details, see:

Descriptive programming

For example, manually edit object names to use descriptive programming instead of the object's name.

Note: We recommend adding the class property to any descriptive programming statements to enable Digital Lab to identify the object.

For more details, see Programming Tests.

Synchronize your test and verify your app response

Manually add any of the following types of steps to help your test run smoothly and verify that your app responds correctly.

Launch method

Use the App test object's Launch method to open an application without performing any steps on it.

For example, you may want to use the Launch method if it takes a long time to open an application, and this causes the 1st step to fail because the object is not found.

To use the Launch method, insert a Launch step as the first step on a device.

Wait statements

Insert the VBScript Wait statement between steps to ensure that the previous step is completed before running the next step.

WaitProperty steps

Use a WaitProperty step to instruct UFT One to wait until a specified runtime property is set to a specific value (or until an optional timeout expires).

For more details, see the Mobile section of the UFT One Object Model Reference for GUI Testing

Exist method

Use the Exist method to wait until the specified test object is found in the current view (or until an optional timeout expires), and to verify that the app displays the expected controls.

For example:

  • Device test object: Checks if the device is connected to the current Digital Lab server.

    Values of location runtime properties (left, top, right, and bottom) are taken from the corresponding remote access window. Values of other runtime properties are taken from the Digital Lab device details.

  • Apptest object: Checks if the application is loaded to the current Digital Lab server.

    Values of runtime properties are taken from the Digital Lab application details.

GetROProperty

Retrieve the value of properties such as text, and then check the value of this property.

Reporter.ReportEvent

Send data to the run results.

Back to top

See also: