APPLICATION STATES & TEST PLANS

SILK TEST 7.5

Jagan Mohan Julooru

 OVERVIEW OF APPLICATION STATES

When testing an application, you’re likely to have a number of testcases that have
identical setup steps. Rather than record the same steps over and over again you can
record the steps as an application state and then associate the application state with the
relevant testcases.

An application state is the state you want your application to be in after the base state is
restored but before you run one or more testcases. By creating an application state, you
are creating reusable code that saves space and time. Furthermore, if you need to modify
the Setup stage, you can change it once, in the application state routine.

A testcase can have, at most, one application state associated with it. However, that
application state may itself be based on another previously defined application state. For
example, assume that:

• The testcase Find is associated with the application state Setup

• The application state Setup is based on the application state OpenFile

• The application state OpenFile is based on the built-in application state,

DefaultBaseState

• SilkTest would execute the programs in this order:

1 DefaultBaseState application state

2 OpenFile application state

3 Setup application state

4 Find testcase

If a testcase is based on a single application state, that application state must itself be
based on DefaultBaseState in order for the testcase to use the recovery system. Similarly,
if a testcase is based on a chain of application states, the final link in the chain must be
DefaultBaseState. In this way, SilkTest’s built-in recovery system is still able to restore
the application to its base state when necessary.

DefaultBaseState

Built-in application state function that returns your application to its base state. By
default, the built-in DefaultBaseState ensures that the application is running and is not
minimized, the main window of the application is open, and all other windows (for
example, dialogs and messages boxes) are closed.

Jagan Mohan Julooru

BASESTATE

The known, stable state you expect the application to be in at the start of each testcase.

APPLICATION STATE BASED ON NONE

If an application state is based on the keyword NONE, SilkTest executes the application
state twice: when the testcase with which it is associated is entered and when the testcase
is exited.

On the other hand, if an application state is based on DefaultBaseState, SilkTest executes

the application state only when the associated testcase is entered.

The following example code defines the application state InvokeFind as based on the
NONE keyword and associates that application state with the testcase TestFind.

Appstate InvokeFind () basedon none

xFind.Invoke ()
print ("hello")

testcase TestFind () appstate InvokeFind

print ("In TestFind")
xFind.Exit.Click ()

When you run the testcase in SilkTest, in addition to opening the Find dialog, closing it,
and reopening it, the testcase also prints:

hello
In TestFind
hello

The testcase prints hello twice because SilkTest executes the application state both as the
testcase is entered and as it is exited.

RECORDING AN APPLICATION STATE

You define an application state before recording the testcase(s) associated with it. As
with testcases, you can write an application state routine from scratch or you can use the
Application State command on the Record menu.

• Open the file in which you want to place the application state. This can either be
the test frame file for the application or the script file where the associated
testcases are defined. If you put the application state in the test frame file, it will
be available to all testcases. If you put it in the script file, it will be available only
to testcases in that script file.

Jagan Mohan Julooru

 • Open the application you want to test.

• Select Record/Application State to display the Record Application State dialog.

• Type the name of your new application state in the Application State Name field.

• Select an application state from the Based On drop-down list.

• Click the Start Recording pushbutton. SilkTest closes the Record Application
State dialog and displays the Record Status window. The Status field flashes
Recording.

• Drive your application to the state you want to record. At any point, you can
record a verification by pressing Ctrl+Alt.

• When you have finished recording an application state, click Done on the Record
Status window. SilkTest redisplays the Record Application State dialog. The
Application State Code field contains all the 4Test code you’ve just recorded.
You can take the following actions:

If Then
All the information in the window is Click Paste to Editor. SilkTest closes
complete and what you expect. the Record Application State dialog
and places the new application state in
your file.
You want to alter the code. Edit the Application State Code field.
The application state name is not what Edit the name in the Application State
you want. Name field.
The application state on which this Delete the code in the Application
application state is based is not the one State Code field, select a new
you want. application state from the drop-down
list, and click Resume Recording to
rerecord the application state.
The application state routine is not Click Resume Recording. SilkTest
finished. opens the Record Status window.

TESTING AN APPLICATION STATE

• Before you run a testcase that is associated with an application state, you should
make sure the application state compiles and runs without error.

• Make active the window that contains the application state and select
Run/Application State.

Jagan Mohan Julooru

 • On the Run Application State dialog, select the application state you want to run
and click Run. If there are compilation errors, SilkTest displays an error window.
Fix the errors and rerun the application state.

USING APPSTATELIST

To display a list of currently defined application states

1. Within your script (.t or .g.t) or include file, type your testcase declaration,
followed by the keyword appstate and then press space; for example, testcase foo
( ) appstate . A list of currently defined application states appears.
You can also type the keyword basedon followed by a space; for example
appstate MyAppState () basedon .

2. Use one of the following methods to select the appropriate member and paste it to
the Editor:

a. type the first letter or the first few letters of the member and then press
Enter or Tab

b. use your arrow keys to locate the member and then press Enter or Tab

c. scroll through the list and select a member with your mouse

OVERVIEW OF TEST FRAMES

Before you begin recording testcases, you first record a test frame for your application.
The test frame is the backbone that supports your testcases and scripts. It is an include
file (.inc) that contains the 4Test declarations for the main window and all its menus, as
well as a generic declaration that is valid for each of the standard message boxes in the
application. (In some instances, you may want to modify the recorded identifiers or tags
in your test frame file. You can do this by editing the file directly.)

When you record a test frame, the full path of the test frame file is added to the Use Files
field of the Runtime Options dialog. This means that SilkTest can use all of the
information contained in the declarations and recognize the GUI objects in your
application when you record testcases.

A constant called wStartup is created when you record the test frame. By assigning the
identifier of the login window to wStartup and by recording a new invoke method, your
tests can start the application, enter any required information into the login window, then
dismiss the login window.

Jagan Mohan Julooru

TEST FRAME FILE

Contains all the data structures that support your scripts: window declarations, user-
defined classes, utility functions, constants, and variables, as well as other include files.

OVERVIEW OF TESTPLANS

A testplan is a structured, usually hierarchical, document that descibes the test

requirements and contains the statements (4Test scripts and testcases) that implement the
test requirements. A testplan is displayed in an easy-to-read outline format, which lists
the test requirements in high-level prose descriptions. The structure can be flat or many
levels deep.

Indentation and color indicate the level of detail and various testplan elements. Large
testplans can be divided into a master plan and one or more subplans. A testplan file has a
.pln extension, such as find.pln.

When you structure your testplan as a hierarchical outline you:

1. Assist the testplan author in developing thoughts about the test problem by
promoting and supporting a top-down approach to test planning

2. Yield a comprehensive inventory of test requirements, from the most general,

through finer and finer levels of detail, to the most specific

3. Allow the statements that actually implement the tests to be shared by group
descriptions or used by just a single test description

4. Provide reviewers with a framework for evaluating the thoroughness of the plan
and for following the logic of the testplan author

5. If you are using the testplan editor, the first step in creating automated tests is to
create a testplan. (If you are not using the testplan editor, the first step is creating
a test frame.)

LINKING A DESCRIPTION TO A SCRIPT OR TESTCASE USING THE

TESTPLAN DETAIL DIALOG

1. Place the insertion cursor on either a test description or a group description.

2. Select Testplan/Detail. The testplan editor invokes the Testplan Detail dialog,
with the Test Execution tab showing:

The multi-line list box at the top of the dialog displays the line in the testplan that
the cursor was on when the dialog was invoked, as well as its ancestor lines. The

Jagan Mohan Julooru

 black arrow icon indicates the current line. The current line appears in black and
white, and the preceding lines appear in blue.

3. If you:
-- know the names of the script and testcase, enter them in the Script and Testcase
fields, respectively
-- are unsure of the script name, click the Scripts button to the right of the Script
field to browse for the script file

4. On the Testplan Detail - Script dialog, navigate to the appropriate directory and
select a script name by double-clicking or by selecting and then clicking OK.
SilkTest closes the Testplan Detail Script dialog and enters the script name in the
Script field.

5. Click the Testcases pushbutton to the right of the Testcase field, to browse for the
testcase name: The Testplan Detail – Testcase dialog shows the names of the
testcases that are contained in the selected script. Testcases are listed
alphabetically, not in the order in which they occur in the script.

6. Select a testcase from the list and click the OK pushbutton.

7. Click OK. The script and testcase statements are entered in the plan.

If you feel comfortable with the syntax of the testplan editor statements and know the
locations of the appropriate script and testcase, you can enter the script and testcase
statements manually.

Linking to a testplan manually

If you feel comfortable with the syntax of the testplan editor statements and know the
locations of the appropriate script and testcase, you can enter the script and testcase
statements manually.

1. Place the insertion cursor at the end of a test or group description and press Enter
to create a new line.

2. Indent the new line one level.

3. Enter the script and/or testcase statements using the following syntax:
script: scriptfilename.t
testcase: testcasename

Where script and testcase are keywords followed by a colon and scriptfilename.t is the
name of the script file and testcasename is the name of the testcase.

Jagan Mohan Julooru

Note If you enter a statement correctly, it appears in dark red, the default color used for
statements. If not, it will either appear in blue, indicating the line is being interpreted as a
test description, or black, indicating it is being interpreted as a group description.

INDICATING MANUAL TESTS IN A TESTPLAN

Your QA department might do some of its testing manually. You can document the
manual testing in the testplan. In this way, the planning, organization, and reporting of all
your testing can be centralized in one place. You can describe the state of each of your
manual tests. This information is used in reports.

To indicate that a test description in the testplan is implemented with a manual test, use
the value manual in the testcase statement, as in:

testcase: manual

By default, whenever you generate a report, it includes information on the tests run for
that results file, plus the current results of any manual tests specified in the testplan. If the
manual test results are subsequently updated, the next time you generate the report, it
incorporates the latest manual results. However, this might not be what you want. If you
want the report to use a snapshot of manual results, not the most recent manual results,
merge the results of manual tests into the results file.

CREATING A NEW TESTPLAN

1. Select File/New.

2. Select Testplan and click OK. An empty testplan window opens.

3. Create your testplan and then click File/Save.

4. Specify the name and location in which to save the file, and then click OK.

5. If you are working within a project, SilkTest prompts you to add the file to the
project. Click Yes if you want to add the file to the open project, or No if you do
not want to add this file to the project.

Before you can begin testing, you must enable extensions for applications you plan to test
on both the target machine and the host machine.

ENABLING EXTENSIONS AUTOMATICALLY USING THE BASIC

WORKFLOW

1. Start the application or applet for which you want to enable extensions.

Jagan Mohan Julooru

 2. Start SilkTest and make sure the Basic Workflow bar is visible. If it is not, click
Workflows/Basic to enable it.

3. If you are using SilkTest projects, click the Project button and open your project,
or create a new project. If you are not using SilkTest projects, click Enable
Extensions.

4. Click Enable Extensions.

5. Select your test application from the list on the Enable Extensions dialog, and
then click Select. If your test application does not appear in the list, click Refresh.

6. Click OK on the Extension Settings dialog, and then close and restart your
application.

7. When the Test Extension Settings dialog appears, restart your application in the
same way in which you opened it; for example, if you started your application by
double-clicking the .exe, then restart it by double-clicking the .exe.

8. Make sure the application has finished loading, and then click the Test button.
When the test is finished, a dialog displays indicating that the extension has been
successfully enabled and tested. You are now ready to begin testing your
application or applet.

EXTENSIONS THAT SILKTEST CAN AUTOMATICALLY CONFIGURE

Through the Basic Workflow, SilkTest can automatically configure extensions for many
development environments, including:

1. browser applications and applets running in Internet Explorer 5.x, 6, Netscape 4.7,
7.0, 7.1, and AOL (waol.exe only) 7.0, 8.0, and 8.0 Plus

2. .NET standalone Windows Forms applications

3. standalone Java 1 (JDK 1.1.8), Java 2 (JDK 1.2 or greater) and Java AWT
applications

4. Java Web Start applications, and InstallAnywhere applications and applets

running in Java 2 environments (JDK/JRE 1.2+)

5. Visual Basic 5 and 6 applications

6. Client/Server applications

Jagan Mohan Julooru

DISABLING EXTENSIONS

1. In SilkTest, select Options/Extensions.

2. In the Primary Extension field, choose Disabled for the extension you want to
disable.

3. In the Other extensions field, uncheck any marked checkboxes.

4. Click OK.

Note If you are testing non-Web applications, you must disable browser extensions on
your host machine. This is because the recovery system works differently when testing
Web applications than when testing non-Web applications.

OVERVIEW OF THE RECOVERY SYSTEM

The built-in recovery system is one of SilkTest’s most powerful features because it
allows you to run tests unattended. When your application fails, the recovery system
restores the application to a stable state, known as the BaseState, so that the rest of your
tests can continue to run unattended.

The recovery system can restore your application to its BaseState at any point during
testcase execution:

• Before the first line of your testcase begins running, the recovery system restores
the application to the BaseState even if an unexpected event corrupted the
application between testcases.

• During a testcase, if an application error occurs, the recovery system terminates

the execution of the testcase, writes a message in the error log, and restores the
application to the BaseState before running the next testcase.

• After the testcase completes, if the testcase was not able to clean up after itself
(for example, it could not close a dialog it opened), the recovery system restores
the application to the BaseState.

SilkTest uses the recovery system for all testcases that are based on DefaultBaseState or
based on a chain of application states that ultimately are based on DefaultBaseState.

Jagan Mohan Julooru