When a mobile test is recorded and its steps are successfully
run, response time is calculated and reported in the mobile web report
and statistical report.
Synchronization of start application and steps
The following options are available from the test editor.
Open a test with the test editor, click the Launch node or a step
in the script. The
Synchronization policy and
Time
out options are located in the
User actions
details pane. The think time option is available for script
steps only.
- Synchronization policy
- This option is available for native steps only; it is not applicable
to web UI steps. When a test script runs, it reproduces user actions
on Application Under Test (AUT). However it takes time for the application
to execute and react to the actions. A period of waiting might be
needed for the preceding actions to complete their execution before
the next action or the checking for a verification condition could
be done. This scenario is something that needs synchronization. An
example where synchronization is needed: A button must be activated
before you can click on it. For some actions or requests, you must
manually do the synchronization if UI interactions are not handled
in the test. The test report contains warnings that help you to find
the steps in the test that need synchronization. When a test is recorded
with Rational® Test Workbench Mobile
Client 8.6
or later, the synchronization policies that are set are in accordance
with the recorded data. Most of the time, the policies are set to Wait
for idle or Wait not busy. Modify
the synchronization policy where required. The synchronization policy
choices are available from the selected Launch node in the test script
you edit and from each selected step. The policies are the following
ones:
- None: Means that the test was recorded
with a release of the product earlier than 8.6.
- Wait for idle (default) policy: Indicates
that the playback waits for the application to accept new user input,
ignoring progress indicators. Example: No progress bar showing the
user how far the operation has progressed. When the policy is set
to default and the action is successful, the maximum think time is
taken into account during the test replay for the next step.
- Wait not busy policy: Indicates that the
playback waits until a background task progress indicator is complete
or is no longer displayed. The think time is cut in a step only if
the test is successful. Example: You can synchronize scrolling actions,
taps and other behaviors.
- Do not wait policy: Indicates that the
playback do not wait but goes on to the next step in the test, applying
the specified think time to the next step and ignoring the think time
preference. It repeatedly waits for the UI object of the next view
to be ready so that it can be replayed (example: it waits for a button
to be displayed). Think time and time out of the next step are, in
such a case, the only way to calculate how much time is needed by
the application to get ready for the new user inputs. No accurate
response time can be measured in this case and no response time is
reported.
After the synchronization of a successful step, the think
time period of the following step is cut to the maximum think time
value that is specified in the preferences (), if any. A message
is displayed in the web report to explain the actual think time period
that is applied. Warning messages can be displayed when an active
progress monitor (example: a progress bar) is detected and that it
automatically sets the synchronization policy to Wait for
idle or Wait not busy. In this
case, you can change the synchronization policy.
With the None and Do
not wait policies, no response times are measured, which
means that the execution of the test does not rely on any synchronization
action. Only think time periods apply, but they are not cut to the
maximum think time period that is indicated in the preferences. If
the execution of the next step fails, it means that the timeout or
the think time should be raised for the action and that the step is
no longer valid for the application, or that the application does
not respond for internal or external reasons.
- Time out
- You can modify the timeout, if it is indicated in any step that
timeout occurred while synchronizing the application for example.
This setting is used to specify the time interval allocated for an
action or request to complete before it is interrupted. The default
timeout is 10 seconds. To modify the timeout, check the option and
enter a new value.
- Think time
- Think time can be modified for the whole
application and/or for each step. This setting is for a delay in the
processing of a request allocated to reproduce the time that a human
would take to read or examine the data that is displayed from a previous
user action. Think time is calculated from the time that a request
is received (that is, the display is complete on the monitor) until
the time that the user clicks a key or link to perform an action.
The value can be modified for each step of the test script. You can
limit this time to speed up playback by activating a maximum test
execution think time in the preferences .