Checkpoints (Assertion)

Checkpoints are used to verify the expected page content and to make sure that the requested page is loaded correctly. If an HTTP request is completed successfully with HTTP OK code, it does not necessarily mean that the page content has loaded successfully. For example, logging in to a web application may fail and a failed login message may be displayed back. From an HTTP perspective, the page would be successful but from an application point of view, a page hit may be considered a failure. A successful login may be verified by checking the received page response. The presence or absence of certain text strings or text patterns may signify the success or failure of the page.

LoadTest checkpoints have been enhanced to support parameters. Users can now specify the evaluated value of a parameter (as the value to look for) as the checkpoint.

LoadTest checkpoints have been enhanced to support parameters. A user can now specify the evaluated value of a parameter (as the value to look for) as the checkpoint.

Types of Checkpoints

  • Positive checkpoint: Searching for expected string.
  • Negative checkpoint: Searching for string, which is not expected.

Note: Checkpoint can be added from ‘flow.c’ file or the ‘registrations.spec’ file of the script. If the user adds a checkpoint from ‘flow.c’ then it is also added in ‘registrations.spec’. Make sure that checkpoints are added in the ‘registrations.spec’ file of the recorded script.

Add Checkpoints in Script

  1. Open c/registrations.spec file of script. Right-click on the right pane of the file then go to Insert > Checkpoint.

  1. This displays the Checkpoint Parameters window.

  1. Click Add. This displays the Add Checkpoint Parameter window.

4. Provide required inputs (described later) in this window.

5. Click OK and then Close. An API is called inside the ‘spec’ file as below:

nsl_web_find(TEXT=”content string to be searched”, PAGE=*);

This is to search for unique content of a page in string format. For verification, the user can provide a user-defined message with ‘pass’ or ‘fail’ status for that page after content verification is done (execution of that page by Testrun). The user can verify this from Event Log with status CVFail or the detail status of cvfail in Event.log file of respective TEST RUN directory with the user-specified message given in the checkpoint parameter UI. The user can customize the execution of a page of a script using checkpoint by making fail or pass with text found or not found options present inside the checkpoint parameter dialog box. The user also can affect the execution of other pages by using the available Action option, choosing to continue on page error and stop on page error.

Options in Checkpoint Window

Match Criteria:

  • Search for Specific Text: Text-string that is to be searched for in the received response.
  • Search for Text by start and end of the string:
    • Start String Text: The left boundary for the search. This is the text immediately preceding the text string being searched.
    • End String Text: The right boundary for the search. This is the text immediately following the text string being searched.
  • Match complete response using contents of a file: The complete file whose content needed to be compared with the body content of the response. This file can be in either text or binary
  • Match CheckSum with:
    • Checksum: Checksum value, which is compared with the sum of responses.
    • Cookie Name: Checksum cookie name, which has to be compared with Checksum Cookie of response.
  • Match text in page response:
    • All pages: To match the responses on all the pages
    • Specified: To match the responses in user-specified pages
  • Save Occurrence Count in Parameter: The save occurrence count argument assigns the number of matches that were found to a parameter.
  • Failure Condition:
    • Match text not found: Checkpoint would fail if the text string or pattern were not found in the received response. If the FAIL argument is not specified, it is assumed to be NOT FOUND.
    • Match text found: Checkpoint would fail if the text string or pattern were found in the received response.
  • Message on failure: To provide a message if a checkpoint is failed.

  • Action on failure:
    • Stop Session: If the text/string being searched is not found, LoadTest mentions status as ‘CVFail’ in ‘progress.report’ and in ‘event.log’ and stops the session.
    • Continue Session: If the string being searched is not found, even then LoadTest continues its operations.

Finding String from Page Snapshot Window

  1. Go to snap shots options from tool bar in Script Manager UI.

2. This displays the Page snapshots.

  • Select the page.
  • Right-click and select View frame source / View page source.
  • Select the unique text which lies only on that page.

Example: <title> Mercury Tours </title>

Example: Frame Source of index.html Page

Checkpoints Added

Once the checkpoint is added in flow file, it gets added in the registrations.spec as well.

 Verify Checkpoints

To verify the checkpoint, click the icon and execute the script from the Test Script window.

Checkpoints in executed Test Run can be verified in four ways:

  • Debug Trace Log
  • Progress Report
  • Dashboard UI
  • Page Dump UI

Debug Trace log

Once the user executes the test script, this window is displayed automatically.

Example: There are two cases:

  1. Checkpoint is passed
  2. Checkpoint is failed

Page Dump UI

Go to Reports > Ready > Ready Application > Page Dump Report.

Example: Here, the page status ‘CVFail’ signifies that content validation is failed. The user can view the details by clicking the Page Status link.

Figure: Page Dump UI

Progress Report

Go to Reports > Ready > Ready Application > Progress Report.

Event Log in Web Dashboard

Go to View > System Logs > System Events.