Creating a testplan (if you are using the testplan editor)
Recording a test frame.
Creating testcases
Running testcases and interpreting their results.
Creating a testplan
If the testplan editor is used, the automated testing process is started by creating a testplan. A basic testplan is structured as a hierarchical outline and contains:
Descriptions of individual tests and groups of tests. As many levels of description can be used.
Statements that link the test descriptions in the plan to the 4Test routines, called testcases, that accomplish the actual work of testing.
Recording a test frame
Next, record a test frame, which contains descriptions, called window declarations, of each of the GUI objects in your application. A window declaration specifies a logical, cross-platform name for a GUI object, called the identifier, and maps the identifier to the object�s actual name, called the tag. In addition, the declaration indicates the type of the object, called its class.
Creating testcases
The 4Test commands in a testcase collectively perform three distinct actions :
Drive the application to the state to be tested.
Verify the state (this is the heart of the testcase).
Return the application to its original state.
The powerful object-oriented recorder can be used to automatically capture these 4Test commands to interact with the application, or to white the 4Test code manually if one is comfortable with programming languages. For maximum ease and power, these two approaches can be combined, recording the basic testcase and then extending it using 4Test�s flow of control features.
Running testcases and interpreting results
Next, run one or more testcases, either by running a collection of scripts, called a suite, or, if you are using the testplan editor, by running specific portions of the testplan. As each testcase runs, statistics are written to a results file. The results file and its associated comparison tools allow you to quickly pinpoint the problems in your application.
A Test Frame
The test frame is the backbone that supports the testcases and scripts. It is a file that contains all the information about the application�s GUI objects that Silk Test needs when you record testcases. This information minimally consists of a declaration for each GUI object, but can also include any data that you want to associate with each GUI object, as well as any new classes and methods that you want to define.
A window declaration specifies a cross-platform, logical name for a GUI object, called the identifier, and maps the identifier to the object�s actual name, called the tag. Because the testcases use logical names, if the object�s actual name changes on the current GUI, on another GUI, or in a localized version of the application, only the tag in the window declarations need to be changed; don�t need to change any of the scripts. Variables, functions, methods, properties can be added to the basic window declarations recorded by Silk Test.
To record declarations for the main window and menu hierarchy of your application.
1. Start up your application and Silktest.
2. Select File / New. The New dialog appears.
3. Select the Test Frame radio button and click OK. The New Test Frame dialog is displayed, allowing to create a test.
4. Frame file for an application displayed in the Application list box.
5. Select the application fro the Application list box. If a Web application is tested, different fields are seen.
6. Click OK. The new test frame file is created. The file 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.
