How do I cause a Test Composition to stop or abort based upon my own custom logic or criterion?

Document created by DPM Admin on Jul 21, 2017
Version 1Show Document
  • View in full screen mode

General methodology

Write one or more Scripts that perform whatever custom logic you desire in order to determine whether the Test Composition should be stopped or aborted.

Place instances of your Script(s) at points within the Test Composition where you wish to check whether it should be stopped or aborted.

Your Script may access any previously completed Message or Browser Action. For example, you can compare the results of multiple Messages or Browser Actions, or compute cumulative response time.

Your Script can place error and informational messages into the Result, and/or it can cause the Test Composition to stop or abort.

 

Key related Scripting topics

Navigating the Test Composition object hierarchy.

Your Script can traverse the object hierarchy of the Test Composition to find the items in the Test Composition, such as Messages or Browser Actions that have completed prior to Script play. The Test Composition is at the top level. It contains Bands, which contain Tracks, which contain Test Clips, which contain all other items.

For example, the following statement retrieves the item in the Test Clip that precedes the current Script:

var priorItem = $context.currentItem.previousItem;

Properties of $context useful for navigating the object hierarchy include:

  • currentItem
  • currentBand
  • currentTrack
  • currentClip
  • currentChain
  • currentMessage
  • currentBrowserAction
  • currentScript
  • currentTarget

Properties of items in the object hierarchy useful for navigation include::

  • parent
  • children
  • nextItem
  • previousItem
  • name
  • type

Refer to the Scripting documentation for more information.

 

Accessing Messages and Browser Actions

For Messages that have completed previously, you can obtain the response (or a portion of the response), response time, count of bytes received, and other information. Refer to the Scripting documentation on the Message object.

For Browser Actions that have completed previously, you can obtain the outputs from the response. Refer to the Scripting documentation on the BrowserAction object.

 

Custom, System, and Global Properties

You can also access Custom Properties, System Properties, and Global Properties. Refer to the Scripting documentation on the $prop, $sysprop, and $globalprop variables.

Among other uses, Custom or Global Properties could be used for the instances of your Script to relay data, or save data from instance to instance. (However, be aware that there is no locking on access to Custom or Global Properties, so beware of the potential problems that might occur if more than one Script attempts to set the same property at the same time.)

 

Accessing external data

If your Script needs data from outside of SOASTA CloudTest, you will need to make that data available through Web Service calls. Make a Target for the Web Service, and then insert one or more Messages into your Test Composition to retrieve the necessary data. Ensure that the data retrieval Messages are played before the data is needed. Your Script can then access the responses to the data retrieval Messages.

If your Script needs data from outside of SOASTA CloudTest that does not change often, you could manually enter that data into Global Properties, and then access the Global Property values from your Script.

 

Parameterization

If you want to parameterize your Script so that it behaves differently each time the Test Composition is played, without having to edit the Test Composition each time, then write your Script to change its behavior according to one or more Global Property values. By editing the values of the Global Properties before the Test Composition is played, you can change the behavior. The Global Properties accessed by the Script could contain "flags" or "commands" that the Script interprets, or simply values that it uses in its logic.

Another way to parameterize your Script so that it behaves differently each time the Test Composition is played, would be to have your Script access data outside of SOASTA CloudTest and change its behavior according to that data. (See the paragraph above about accessing external data.)

 

Posting messages to the Result

When your Script plays, it can log both informational and error messages to the Result. Refer to the $context.result object, and the postMessage method of that object in the Scripting documentation.

 

Aborting or stopping the Test Composition

Your Script can cause the Test Composition to abort or be stopped. Refer to the Test Composition object's abort and stop methods in the Scripting documentation.

 

Attachments

    Outcomes