Responses form the system are stored as the current response. All actions within .test which work with responses work on the most recent response. more⇛

The current response, for the current stage, is accessible via the %Response% object. This will always be exposed in a XML-like structure suitable for Xpath navigation. See below for specific types. more⇛

TestPlan has a few basic functions to manipulate DateTime variables. These will allow you to select time ranges for a fixed period, or relative to the current time. more⇛

In order to test the reception of emails you will generally need to have an email address and POP server available. While you could get away with testing on a single address you'll discover quickly the limits that has. more⇛

While testing websites the response time of a page can be troublesome for the automated tests. Additionally JavaScript and/or page redirections can mean the page doesn't finish loading in the first request. more⇛

If you are sending emails as part of your web application is quite likely you will also send links as part of those emails. Links are usually used for confirmation, account information, or other purposes to direct a user to a specific part of a web application. more⇛

A state refers to a particular point in the program, or step in processing, along with all the current data in the program. more⇛

This is a collection of parameters which can be altered to enable certain debugging aspects of TestPlan. This is useful if you are compiling or developing TestPlan but also if you need more details about an error your are getting. more⇛

TestPlan automation is organized into a series of scripts, call test units, and something known as a LogicalRoot→ which groups several scripts into a logical test. more⇛

This is a fairly simply example which simply submits a search at this site. It covers the very basic functions of TestPlan and is thus a good introduction to the test language. more⇛