background image
<< Test Cases - Test running the built-in recovery system | Test Cases - A testcase starts from a base state >>
Test Cases - Testcase design principles
<< Test Cases - Test running the built-in recovery system | Test Cases - A testcase starts from a base state >>
106
User's Guide
5 D
ESIGNING
AND
R
ECORDING
T
ESTCASES
Testcase design principles
The DefaultBaseState routine is executed, which should close the dialog
and any open windows, then display a results file.
For example, the following figure shows the results file produced when the
recovery system closes the Text Editor's Open dialog:
If the built-in recovery system cannot close one of the three representative
dialogs, you need to modify the recovery system so that it understands how to
close the dialog. For more information, see "Specifying new window closing
procedures" on page 293.
Testcase design principles
This section explains the methodology you use when you design and record a
testcase.
Two kinds of
testcases
There are two basic types of testcases, each with its own purpose.
Level 1 tests, often called smoke tests or object tests, verify that an
application's GUI objects function properly. For example, they verify
that text fields can accept keystrokes and check boxes can display a
check mark.
Level 2 tests verify an application feature. For example, they verify that
an application's searching capability can correctly find different types of
search patterns.
You typically run Level 1 tests when you receive a new build of your
application, and do not run Level 2 tests until your Level 1 tests achieve a
specific pass/fail ratio. The reason for this is that unless your application's
graphical user interface works, you cannot actually test the application itself.
A testcase has three
stages
Each testcase that you record should have the following three stages.
1
It drives the application from the initial state to the state you want to test.