Silk

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