Understanding the PTF Test Structure
This chapter provides an overview of the PeopleSoft Test Framework (PTF) test structure and discusses the PTF test language.
Understanding the PTF Test Structure
A PTF test is composed of a series of steps. This example shows the steps in a simple test.
Each step in a test is composed of eight fields, as defined in the following table:
|
Seq (sequence) |
A system-generated sequence number. Test steps execute according to the Seq order. When you move, add, or delete a step, Seq is refreshed. |
|
ID |
A system-generated unique identifier for each line, or step, in a test. The ID value does not change when you move, add, or delete a step. Test maintenance reports use the ID value. |
|
Active |
Deselect this field to inactivate a step. PTF will skip inactive steps when the test runs. Each step is active by default. This field is grayed for inactive steps. |
|
Scroll ID |
This field is required only for scroll handling. |
|
Type |
The type of application object to take an action on or to validate. Common object types are Text, Checkbox, Browser, and so on. |
|
Action |
The action the test is to take on the object. The two most common actions used on a Text object, for example, would be Set_Value and Verify. |
|
Recognition |
The means that PTF uses to identify the object within the application. Commonly, this is the HTML ID property. |
|
Value |
In a typical recorded step, this is the value the tester entered for an object. In a step recorded in field check mode, this would be the value that was present in the object when it was checked. |
As a rule, a test has a single step for each instruction in a manual test case. For example, consider the following manual test instruction:
12. Enter the value "KU0001" into the text box labeled "Employee ID".
This test instruction could be represented in PTF as a step, as shown in this example:
Example of a PTF test step
The PTF test language syntax and vocabulary are designed to read like a technical version of English. As a result, the function of most steps should be apparent from their construction and the context of surrounding steps.
The following chapter, “Test Language Reference,” is a reference for all the PTF object types and actions.
PTF Test Language
This section discusses:
Validation
Parameters
Variables
Reserved words
Validation
Each object type allows only certain actions. Similarly, each action can only be used with certain object types.
The PTF Test Editor automatically limits your choice of actions based on the object type selected.
For example, if a step has the Type field set to Text and the Action field set to Set_Value, you can change the Action field to Verify since it is included in the list of available values for a text object.
This example shows a drop-down list with Verify as one of the values for the Action field when the Type field is set to Text:
Action drop-down list for Text
Conversely, if you have a step with the Type field set to Text and the Action field set to Set_Value, you can change the Type field to Pwd since Set_Value is a valid action for both Text and Pwd object types.
However, if you change the Type field to Link, the Test Editor automatically changes the Action field value to Click and limits the values in the drop-down list to the valid actions for Link.
This example shows a step using the Link type and a drop-down list with the valid actions for Link:
Actions drop-down list for Link
Parameters
Typically, you place parameters in the Recognition field and use the following structure:
param=value;
Separate parameters with a semi-colon.
For example:
prcname=RCOM01; wait=true;
With a Radio object, you can also place parameters in the Value field.
See Radio.
Steps that return a value require the parameter ret=&variable;
For example:
ret=&chart_val;
The system ignores unneeded parameters. For example, Browser.Start and Browser.Start_Login do not take any parameters, so the system ignores any values in the Recognition field for Browser.Start or Browser.Start_Login.
Variables
Variables enable you to work with steps in which the information or values are not known when you create the test or the information or values for a step change each time the test executes.
You prefix variables with an ampersand (&).
In this example, the first step stores the value in the OPRID field to the variable &OPRID. The second step populates the field OPRDEFNDESC with the value in the variable &OPRID.
See Also
Developing and Debugging Tests
Reserved Words
Similar to variables, you use reserved words to supply information that is not known until a test executes.
Prefix reserved words with a pound sign (#) and use them in the Value field of a test to verify a condition, change the value in an application field, or both. In this example, the #TODAY reserved word sets the EFFDT_FROM field to the current date.
See Also