SILK TEST

SilkTest Architecture
SilkTest QA Methodology
Plan Phase
•Use SilkTest projects to store information about
your testing process
•Define specific tests and determine testing
strategies
•Create a test plan
- Testplan Overview
- Testplan Detail
Capture Phase
•Learn about the application
•Visit each window
•Build a frame file
•Capture windows
•Create application states

Create Phase
•Create automated testcases
Run Phase
•Select and execute specific tests
•Generate results
Report Phase
•Summarize progress and defects
•Produce a Pass/Fail report
Track Phase
•Track defects
•Perform regression testing
SilkTest File Types
SilkTest Projects

•Can be created through File/New Project

•Organize all the resources associated with a test set, such as testplans,
scripts, data, options sets, .ini files, results and frame/include files
•Store relevant information about your project, including configuration
information, editor settings and data files for attributes and queries at the
project level
•Allow you to add appropriate files to your project
Project Explorer
•Is used to view and access all the resources in a SilkTest project
•Makes it easy to access files that have been added to the project
•Allows you to open a file by double-clicking it
•Presents the resources within each project visually, making them easier
to see, work with and manage
•Contains two tabs: Files and Global
Files Tab
•Lists all of the files included in the project
•Allows you to view, edit, add and remove files from the project
•Provides (via right-click) menu options for each of the file types, such
as Record Testcase and Run Testcase for a file contained in the Script
folder

Note: You cannot move files within the Project Explorer. For example, you
cannot drag a script file to another node
Global Tab
•Displays at a global level all the resources, for the open project, such as
testcases, functions and classes
•Allows you to double-click an object to open the file in which the object
is defined and position the cursor at the beginning of the first line of the
double-clicked object
The Basic Workflow Bar

•Allows you to create a new project or open an existing project

•Helps you to automatically enable and test extension settings
•Assists you in configuring the recovery system
•Leads you through the process of recording a testcase
•Allows you to run a testcase
Enable Extensions
Extensions enable SilkTest to recognize specific objects native to the
environment in which the Application Under Test resides. Extensions
must be set up prior to beginning the test development process

Recovery System
Base State returns the application to its starting point before running a
testcase, during a testcase, if an error occurs; and after testcase
completion

Record Testcase
•Displays the Record Testcase dialog which is used to create a testcase
•Allows you to record the actions that you perform against the
Application Under Test so that these can be played back at a later time
•Stores recorded instructions in the specified script file
Run Testcase
•Displays the Run Testcase dialog
•Is used to run any testcase in the active script file
Note: You may also run all testcases by pressing F9 or the button
located on the tool bar

Stopping a Testcase
To stop a script or testcase from running:

Select Run/Abort or press both shift keys simultaneously

• End of Day 1
The Frame File
•Is a central, global repository of information pertaining to your
application, including:
- data structures that support your test scripts, including window
declarations, constants, variables
- application states, as well as user-defined methods and functions
•Can be viewed by double-clicking the file listed under the
Include/Frame node in the Project Explorer window
•Provides the means to create logical descriptions (identifiers) for all
objects in an application
•Is written in the 4Test scripting language and can be edited through use
of the 4test Editor
•Uses indentation to indicate relationships between objects
•Assigns distinct colors to the various types of editor items
Note: Only one frame file is needed for an Application Under Test
A Testcase
•Is a sequence of commands that simulate a user interacting with an
application
•Resides in a 4Test script (.t) file
Testcase Results File
•Is automatically generated by SilkTest
•Has the same name as the executed script, frame or testplan, but with an
.res extension
•Provides information about the execution of the testcase, script or
testplan:
- Statistics at each level, including number of testcases run, number of
errors and pass/fail ratio
- Performance data, including start, stop and elapsed times
- Clear identification of passed versus failed testcases
- Information about any error(s)
•Is a generation data set containing results history for script, frame or
testplan
- Default history size is 5
- History size can be modified through the Runtime Options dialog
Capturing States in an Application
Base State
•Is the known, stable state that you expect the application to be in before
each testcase is executed
•Is typically the state that the application is in just after being started
•Has two components:
- Default Base State
- User-Defined Base State Method

Note: The Default Base State will look for and automatically execute a
User-Defined Base State Method.
Note: Each application will have only one base state.
Default Base State
•Is established when you create a new test fame to capture your
application
•Ensures that:

•Uses the value of the constant sLocation, as stored in the first (main)
window declaration in the frame file, to determine which application
window should be loaded
User-Defined Base State Method
•Allows you to enhance your application's default base state
•May be useful for:
- Adding specific data to a field on the Default Base State page
- Changing browser options such as memory and file cache to give you a
fresh start at the beginning of each new test
•Is an addition to the Default Base State; not a replacement for the
Default Base State
An Application State
•Is a state that you want your application to be in at the start of a given
testcase
•Is based on either Default Base State or another application state
•Reduces redundant code in your 4Test script and makes the code easier
to maintain
•Makes a testcase easier to record
•Ensures consistency in driving the application to the test state
•Is normally defined in the frame file

Note: It is a good practice to test each application state as it is created.

Allows you to reuse existing application states to:

- Save effort
- Modularize your routines
- Reduce maintenance
• End Of Day 2
Window Declarations
•Describe a window and all of its child objects; recorded window
declarations will capture all child objects
•Separate the physical page (which may change with each new build)
from its logical operation (which will generally remain unchanged)
•Specify logical names for all objects on a page – these names
(identifiers) will be used regardless of platform or browser
•Are added to the active frame file
Note: In general, all Web application pages and their respective objects
should be declared before creating test scripts
Creating and Running Testcases
Record Testcase
•Displays the Record Testcase dialog which is used to create a testcase
•Allows you to record the actions you perform against the application
under test so that these can be played back at a later time
•Stores recorded instructions in the specified script file
A Testcase
•Is an automated test that tests one objective of a testplan
•Drives an application to the state where the test will be performed
•Verifies whether the application works as expected
•Resides in a 4Test script file
•Performs two fundamental tasks:
- Drive the application to the state to be tested
- Verify that the actual state matches the expected state

Note: Each test description in a testplan will be implemented by one

testcase. Each testcase verifies one test objective
Note: No script or testcase should rely on the successful completion of a
previous script or testcase. Each testcase should be independent of
other testcases
Testcase Structure
Record Testcase
Note: Selecting Paste testcase and update window declaration(s)
assures that any objects your testcase interacts with will be defined in
the window declaration
When a Testcase Fails
Testcase Failures
Occur when:
- The object you are testing does not meet verification requirements
- The application has changed and the commands in the testcase are no
longer valid for the application
- A window or message box appeared that your testcase was not
expecting
SilkTest Recovery System
•Is designed to automatically restore the application to a known state
after an unexpected error
•Ensures that each testcase begins with the application in its base state
before executing any application states
•Supports automated, unattended tests so that tests can be run after hours
•Makes sure that a failed testcase does not prevent subsequent testcases
from running
•Manages unexpected events in the application and aids in ensuring
reliable results
•Logs warnings and errors
How SilkTest Handles Verification Failures
1. An error is raised by SilkTest
2. SilkTest stops running the testcase and passes control to the recovery
system
3. The recovery system logs the error to the results file
4. SilkTest executes the next testcase
The Results File
Extract Results

- Window displays the results in a SilkTest window - without Special

characters such as and so on
- File opens a Save dialog, allowing you to save the list to an ASCII
(.TXT) file
- Printer opens a Print dialog, allowing you to print the list to an installed
printer
Revisiting the Workflow Bar

Open Project
- Open an existing project
- Auto Generating a New Project

Enable Extensions
• End of Day 3
Data Driven Testcases
•Let you store data combinations in a list of items and invoke the
testcase once for each item passing the data to the testcase as a parameter
•Can be associated with an external data source such as a spreadsheet,
file or database
•Can be executed against a specified set of records in a data source
•Are executable either from the script file or from a testplan
•Are also referred to as generalized testcases
•Can be created in one of two ways:

- Standalone technique

- Data Driven Workflow technique

Standalone Technique
•Offers three methods for passing data to a data driven testcase

- Run/Testcase Dialog Method: select Run/Testcase and type the

record data into the Run Testcase dialog

- Testplan Method: in a SilkTest testplan, insert the record data as a

testcase statement

- External File Method: if the data exists in an external file, write a

data function to read the file and use a main function to run the data
function
External File Method
•Uses the same testcase format as any record driven testcase
•Uses data stored in an external file instead of from a testplan
•Needs a data function to parse the data from an external file
Note: Because the data is stored externally, a function may be created to
read the data and run the testcase
A Standard Testcase
•Is limited in its usage as the data is coded directly into 4Test statements
•Can be converted into a data driven testcase because it has data and data
types which can be stored in a record format

A Record

•May contain any number of fields, which may be of different data types
•Must be declared outside a function
Data Driven Testcase

•Is associated with an external data source such as a flat file, spreadsheet
or database
•Can be executed against a specified set of records in a data source
An External Data File

•Holds data that is stored in a record format

•Contains the data to be read during the testing scenario
A Data Function
•Is created to parse the data
from an external file
•Will be used within a five
step process to:
1) Declare a variable for the
external file
2) Declare a variable to hold
an instance of a record in the
file
3) Open the file
4) Read the file and run the
testcase for each set of data
5) Close the file
Note: FileReadValue returns a TRUE when it reads a record and returns a
FALSE when it encounters end of file
Data Driven Workflow Technique
• End of Day 4
Error Handling
•The recovery system scripts are located in defaults.inc, which is in the
directory where you installed SilkTest.
•You can write functions that override some of the default behavior of
the recovery system.
•You may want to handle errors locally and log errors and warnings in
the results file under script control.
•When a testcase uses its own error handling logic that does not call the
recovery system, it can pass, even though an error has occurred
4Test statements used to handle or raise exceptions
Options Set
•Is a file that contains settings to run SilkTest
•Must be opened in order to be used in your project
•Can be identified as the one that is currently loaded when its name
appears in the SilkTest title bar
•Can be passed along to other team members to ensure consistency in the
testing process
Set Recovery System
•Is used to identify the starting point (Base-State) of the application you
are testing
•Updates the Use Files field on the Runtime Options dialog with the path
to the executable for the application

Note: The Recovery System will return your application to its BaseState,
before running a testcase, during a testcase if an error occurs and after
a testcase completes.
The Frame File
•Contains the path to the application's executable file for the SilkTest
recovery system to use while running testcases
•Will initially hold a window declaration only for the starting
page/window
Help Topics
•Is used to get more information than the Library Browser provides
•Allows you to copy and paste examples into your testcase
Looping Statements
Branching Statements
How To Handle A Login Window
•Record a window declaration for the login window
•Record an Invoke method to handle the login window
•Modify the Invoke method to include a derived keyword
•Add the login widow's name to the wStartup constant in the Main
Window's window declaration