Silktest Tutorial

silktest
for BMC Transaction Management Application Response Time by Segue Software Service Level Edition getting started: a tutorial
software quality optimization
version
7.6
Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada

Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031
Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000
Copyright 1992 - 2005 Segue Software, Inc. All rights reserved. BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc. IBM is a registered trademark of International Business Machines Corporation. DB2 is a registered trademark of International Business Machines Corporation. Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle Corporation. SilkTest is a registered trademark of Segue Software, Inc. All other trademarks belong to their respective companies. BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.
Customer support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, please see Before Contacting BMC Software.
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can read overviews about support services and programs that BMC Software offers find the most current information about BMC Software products search a database for problems similar to yours and possible solutions order or download product documentation report a problem or ask a question subscribe to receive e-mail notices when new product versions are released find worldwide BMC Software support center locations and contact information, including e-mail addresses, fax numbers, and telephone numbers
Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to support@bmc.com. Outside the United States and Canada, contact your local support center for assistance.
Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working on your problem immediately:
product information product name product version (release number) license number and password (trial or permanent) operating system and environment information machine type operating system type, version, and service pack or other maintenance level such as PUT or PTF system hardware configuration serial numbers related software (database, application, and communication) including type, version, and service pack or maintenance level sequence of events leading to the problem commands and options that you used messages received (and the time and date that you received them) product error messages
messages from the operating system, such as file system full messages from related software
Contents
Chapter 1 Introduction 7
The Benefits of Automated Testing 7 Understanding SilkTest Basics 9 SilkTest Features 15 Understanding the Segue Testing Methodology 17 SilkTest File Types 20 Exploring the SilkTest Window 22 Using SilkTest with Web Applications 23
Chapter 2
Preparing to Use this Tutorial
27
Setting up to Test Web Applications 28 Becoming Familiar with the Web Application Under Test 32 Setting Up to Test Client/Server Applications 39 Becoming Familiar with the Client/Server Application Under Test 44
Chapter 3
Planning a Testing Strategy
55
57
What is a SilkTest Testplan? 56 Understanding the SilkTest Testplan Editor Creating a Testplan 60 Defining and Associating Attributes 65
Chapter 4
Capturing Your Application
71
The Test Frame 72 Creating a Test Frame 78 The Window Declaration 80 Windows that Precede the Main Window Testing DefaultBaseState 87 Tags and Identifiers 88
83
Chapter 5
Creating Testcases
93
Guidelines for Creating Testcases 94 Recording a Testcase 94 Linking Scripts and Testcases to a Testplan 101 Recording from a Testplan 104 Exploring the Connections: Testplans, Scripts and Testcases Examining the Structure of a 4Test Statement 111
109
Getting Started: A Tutorial
Understanding How the Recovery System Works 112
Chapter 6
Running Testcases
115
Options for Running Testcases from a Testplan 115 Running a Single Testcase from a Testplan 116 Running All Testcases in a Testplan 118 Running Marked Tests in a Testplan 118
Chapter 7
Reviewing and Reporting Test Results

The Results File 124 Introducing an Error in a Testcase 125 Viewing an Error in a Testcase 127 Using the Difference Viewer 129 Generating Pass/Fail Reports 131
123
Chapter 8
Testing Databases
135
Overview of DBTester 135 Running the Sample Testcase 137 Switching from the Access database to the text database 142 Restoring the Sample Database 143
vi
1
1e rh C t p a
Introduction
This tutorial contains the following sections:
Section Page
In this chapter
The Benefits of Automated Testing Understanding SilkTest Basics SilkTest Features Understanding the Segue Testing Methodology SilkTest File Types Exploring the SilkTest Window Using SilkTest with Web Applications
7 9 15 17 20 22 23
The Benefits of Automated Testing

Manually testing software is a time-consuming and often tedious process, one which cannot guarantee consistency of testing across releases and across platforms. Additionally, time constraints often do not afford us the luxury of being able to manually test and retest our applications before they are released. Inevitably the question remains, Did any critical bugs go undetected?
1 INTRODUCTION The Benefits of Automated Testing
Automating your testing leads to a better use of your resources. Skilled testers are freed up to put more effort into designing better tests while machines that would otherwise lie idle overnight can be used to run unattended automated tests. The benefits of automating software testing with SilkTest for BMC Transaction Management Application Response Time by Segue Software are many:
The layered approach
Providing more coverage of regression testing. Reducing the elapsed time for testing, getting your product to market faster. Improving productivity of human testing. Improving the re-usability of tests. Providing a detailed test log.
The most common approach to any testing is the layered approach. The layered approach includes three types of tests: Operability Tests which examine each object, verifying specific properties of the object such as: state, size, caption and contents. Functionality Tests which examine the behavior of a group of objects that together provide a specific feature to the end user. This includes looking at a dialog as a collection of objects and verifying the functionality provided. It can also include verifying the interaction between objects. For example, verifying that a text box is enabled when a check box is checked. System Tests which examine how the application under test (AUT) interacts with other software or hardware products within the software environment.
Other types of tests
Other types of tests that may be performed using SilkTest include: Regression Tests which run existing tests on new versions of a program. Error Tests which verify the systems response to error conditions. Stress Tests which measure the systems response to repetitive or large amounts of data. White-Box vs. Black-Box Tests Where white-box testing places the focus on the internal structure of the software (the code) while black-box testing views the software from the end-user perspective and is unaware of the underlying code.
1 INTRODUCTION Understanding SilkTest Basics
Understanding SilkTest Basics

How SilkTest works
Applications are composed of graphical user interface (GUI) objects such as windows, menus and buttons that a user manipulates using a keyboard and a mouse to initiate application operations. SilkTest interprets these objects and recognizes them based on the class, properties and methods that uniquely identify them. During testing, SilkTest interacts with the objects to submit operations to the application automatically, simulating the actions of a user, and then verifies the results of each operation. The simulated user, SilkTest, is said to be driving the application. SilkTest consists of two distinct components that execute in separate processes: The SilkTest Host software The SilkTest Agent software
4Test Scripts GUI Commands
SilkTest Host
SilkTest Agent
Application Under Test
The SilkTest Host
The host software is the SilkTest component you use to develop, edit, compile, run and debug your test scripts and testplans. The machine that runs this component is often referred to as the host machine. The SilkTest Agent is the component of SilkTest that interacts with the GUI of your application. The Agent translates the commands in your 4Test scripts into GUI specific commands, driving and monitoring the application you are testing. The Agent can run locally on the same machine on which the Host is running or, in a networked environment, any number of Agents can run on remote machines. In a networked environment, the machine that runs the Agent is often referred to as the remote machine. Before you begin creating and running test scripts, you create a repository of information about your application to be used by SilkTest. This repository includes descriptions of the GUI objects that comprise your application. Based on the properties and methods SilkTest associates with these objects, SilkTest can recognize the actions performed on them and intelligently record those actions into your test script using the 4Test language.
The SilkTest Agent
How SilkTest records user actions
The table below provides a sample of what SilkTest records in the 4Test language when you complete a particular action.
What you do What SilkTest records Pick Check Uncheck SetText
You pick a menu item You check a check box You uncheck a check box You write text in a text field
You scroll a scrollbar to the maximum ScrollToMax position You select an item from a list box You close a dialog box You set the main window active
Select Close SetActive
You select a radio button from a group Select

The 4Test language
4Test is an object-oriented fourth-generation language (4GL) designed specifically with the needs of the QA professional in mind. 4Tests powerful features are organized into three basic kinds of functionality: A robust library of object-oriented classes and methods that specify how a testcase can interact with an applications GUI objects. A set of statements, operators and data types that you use to introduce structure and logic to a recorded testcase. A library of built-in functions for performing common support tasks.
Basic object-oriented concepts

To assist you in using this tutorial the following section presents some basic object-oriented programming terms and concepts. If you are already familiar with object-oriented concepts, proceed to The built-in recovery system on page 14.
Classes
Classes are the core of object-oriented languages and are common to basic GUI architecture. A class contains a collection of information about a type of object.
10
The following figure shows several classes in the main window of a sample client/server application. The classes are MainWin, Menu and Menu Item.
MainWin Menu Menu Item
The next figure shows several classes in the home page of a sample Web application. The classes are HtmlImage, HtmlHeading, HtmlText and HtmlLink.
Logo
HtmlHeading
HtmlText
HtmlLink
11
1 INTRODUCTION Understanding SilkTest Basics Objects
An object is a specific instance of a class. For example, in the 4Test language, the Exit button on a window is an object of the PushButton class. Note Objects can contain other objects. In the following figure, the About Green Mountain Outpost (GMO) window is a child window of the GMO main window.
Main Window
Child Window
Properties
A property is the physical characteristic of an object that you can access directly. Each class has an associated set of properties, although some properties are common among classes. The following figure shows SilkTests Library Browser, which contains information about methods, properties and functions. What you see below are the properties defined for the CheckBox class, bChecked and bValue.
12
The following table provides additional examples of properties:

Characteristic Property Name
State Enabled SelText
Whether a check box is checked Whether an object is enabled The text of the selected item in a radio list
The index of the selected item in a radio SelIndex list The caption of a window The text in the text field The highlighted text in a text field The size and position of a window
Methods Caption Text SelText Rect
Actions that you perform on objects are called methods. The methods available to an object are inherited from the class to which the object belongs. For example, the CheckBox class defines the actions that can be performed on all the check boxes in your application such as Check, Click and Toggle. Methods defined for one class cannot be used to perform actions on a different class. For example, you cannot use methods defined for the CheckBox class to perform actions on objects in the PushButton class. The following figure shows several methods defined for the CheckBox class:
13
The following table provides additional examples of methods:

User Action Method Name
Click () Pick () Check () UnCheck () SetText () GetText () Select () GetItemCount() Close () SetActive () Select ()
You click on a push button You pick a menu item You check a check box You clear a check box You type text into a text field You read the value of a text field You choose an item from a list box You count the number of items in a list box You close a dialog box You set the MainWin active You choose an item from a radio list
The built-in recovery system

The built-in recovery system is one of SilkTests most powerful features, because it allows you to run tests unattended with confidence. The failure of a single testcase shouldnt stop the rest of your tests from running. With SilkTest, when your application fails, the recovery system restores your application to a stable state, known as the BaseState. This allows the rest of your tests to continue even when a preceding test has failed. The recovery system will be discussed in more detail in Understanding How the Recovery System Works on page 112. You can also see the online Help for more information about the recovery system.
14
1 INTRODUCTION SilkTest Features
SilkTest Features
SilkTest offers a complete solution for the automated testing of Web and client/server applications. With SilkTest you can perform: Functional, operability and regression testing Test planning and management using the testplan editor Database validation using DBTester
For more information about the capabilities of SilkTest, see the online Help.
General application testing features
Organization of resources within a project Projects organize all the resources associated with a test set and present them visually in the Project Explorer, making it easy to see, manage, and work within your test environment. Guidance via workflow bars The Basic Workflow guides you through the process of creating a testcase, while the Data Driven Workflow assists you in creating a data driven testcase. Automatic completion within the Editor AutoComplete decreases the need to type text into your 4Test files by automatically completing functions, members, application states, and data types in the 4Test Editor. Easy recording of tests The SilkTest Recorder gives you the option to create window declarations on the fly, and helps you set up the recovery system. By default with the DOM extension, the recorder now displays a rectangle which highlights the controls as you go through your application, as a user would. SilkTest records the appropriate verification statement in your test in the 4Test language. True object recognition Your application is seen by SilkTest as comprised of discrete objects, with well-defined properties. Unattended testing with built-in recovery system SilkTest intelligently handles unexpected errors and automatically returns your application to the desired state before running your next test. Fully integrated testplan creation and maintenance You begin the automated testing process by creating testplans. Testplans allow you to plan and manage the testing of your application. Using criteria that you define, SilkTest allows you to run only the tests you want from within a testplan.
15
1 INTRODUCTION SilkTest Features
Database testing capabilities SilkTest enables you to manipulate your database directly using the Database Tester (DBTester). DBTester provides direct access, using SQL, from a test script to any database supported by ODBC drivers. Full distributed testing You can test client/server applications in a networked environment.
Additional features for Web applications
The following features are available when testing Web applications: Browser and platform independence SilkTest supports popular browsers on various platforms. You can create tests against one browser and use those tests on different browsers, enabling you to test whether your application works properly on multiple browsers. With minor modifications your tests can support different browsers and different versions of a particular browser. See the Release Notes for information on supported browsers. Technology independence SilkTest works seamlessly with the different Web technologies used to develop browser-based applications. Multiple testing options using browser extensions SilkTest allows you to view and test Web applications in two different ways, depending on the browser you are using and your testing requirements. Using the Document Object Model (DOM) extension, SilkTest is able to query the browser directly for information about the objects on the Web page. Alternately, SilkTests proprietary Virtual Object (VO) extension uses sophisticated pattern recognition techniques to identify Web page objects.
16
1 INTRODUCTION Understanding the Segue Testing Methodology
Understanding the Segue Testing Methodology

Testing is more than just creating random test scripts and running them. Testing is a skill that demands an organized, planned approach. A thoughtful approach to automated testing ensures that your testing not only uncovers a high proportion of defects but does so in a cost effective manner. Segue has developed the QA methodology to help ensure your testing is performed effectively.
The six phases of the testing process
SilkTest compliments the Segue Testing Methodology. This methodology consists of six phases: Plan Capture
Create
Run
Report
Track
Phase
Action
Description
I II III
Plan Capture Create
Determine the testing strategy and define specific test requirements. Classify the GUI objects in your application and build a framework for running your tests. Create automated, reusable tests. Use recording and/ or programming to build test scripts written in Segues 4Test language. Select specific tests and execute them against the AUT. Analyze test results and generate defect reports. Track defects in the AUT and perform regression testing.
IV V VI
Run Report Track
A summary of each phase of the Segue Testing Methodology is provided below.
17
1 INTRODUCTION Understanding the Segue Testing Methodology Phase I: Plan
You begin the automated testing process by creating a testplan. A testplan is a document that helps you plan and manage the testing of your application. You develop testplans in SilkTests testplan editor. Structured as a hierarchical outline, a basic testplan contains the following information: Descriptions of individual tests and groups of tests. You can use as many levels of descriptions as you want. Statements that link the test descriptions to one or more testcases that perform the actual testing of the application. Attributes, assigned to a specific testcase or group description. Attributes are useful for grouping tests so that you can run or report on specific parts of the testplan.
For large and complex software applications, testing every possible path is not cost or time effective; you must identify a subset of all possible tests to provide the highest coverage in the most crucial areas of the product. To get a thorough understanding of the crucial areas of your product we recommend that you review process documents such as: Customer Requirements Design Specifications Functional Specifications Marketing Requirements Product Documentation Tip Segue recommends, as good business practice, that you develop a testing strategy through the development of a testplan before you create your testcases. However, developing a testplan is optional.
Phase II: Capture
In the capture phase you introduce SilkTest to the AUT by building a framework for your testing. First you record a test frame, which is a central repository for information about your application. A test frame stores all the data structures required to support your test scripts: The URL for a Web application or the command line needed to invoke the client/server application used by the SilkTest recovery system Constants and variables Descriptions, called declarations, for all the GUI objects in your application
18
1 INTRODUCTION Understanding the Segue Testing Methodology Phase III: Create
After you have defined your test requirements and created a framework for testing your application, you can begin creating testcases. A testcase performs the following actions: 1 2 3 Drives the application to the state to be tested. Verifies that the applications actual state matches the expected state. Returns the application to its original state.
Phase IV: Run
The run phase consists of selecting one or more testcases and executing them against your application. You have the option of running individual test scripts, a collection of test scripts called a suite, or selecting specific testcases (using attributes) in a testplan, or the entire testplan. During this phase you review statistical information about the running of each testcase. SilkTest automatically records the statistics in a results file when the testcase is executing. From this results file you can generate pass/fail reports. The final phase is to identify defects in the application you are testing. You will want to implement a defect-tracking system, to monitor your application as it progresses through development and testing to ensure that the application is performing as expected. SilkRadar, Segues defect tracking system, offers all the features you need to track your QA process. This tutorial does not cover the Tracking phase of the Segue Testing Methodology. For more information about SilkRadar, go to http://www.bmc.com/support_home/.
Phase V: Report
Phase VI: Track
19
1 INTRODUCTION SilkTest File Types
SilkTest File Types

There are eight types of files used by SilkTest in the automated testing process, each with a specific function.
File Type Description File Extension
Project
SilkTest projects organize all the .vtp resources associated with a test set and present them visually in the Project Explorer, making it easy to see, manage, and work within your test environment. The project file has a .vtp (Verify Test Project) extension and is organized as an .ini file; it stores the names and locations of files used by the project. Each project file also has an associated project initialization file: projectname.ini. An automated testplan is an outline .pln that organizes and enhances the testing process; references testcases and allows execution of testcases according to the testplan detail; can be of type masterplan or of subplan that is referenced by a masterplan. A specific kind of include file that .inc upon creation automatically captures a declaration of the AUTs main window including the URL of the Web application or path and executable name for client/server applications; acts as a central repository of information about the AUT; can also include declarations for other windows, as well as application states, variables and constants.
Testplan
Test Frame
20
1 INTRODUCTION SilkTest File Types
File Type
Description
File Extension
4Test Script
Contains recorded and hand-written automated testcases, written in 4Test language, that verify the behavior of the AUT.
.t
Data Driven Script Contains data driven testcases that pull .g.t their data from databases. 4Test Include File A file that contains window declarations, constants, variables, classes and user-defined functions. .inc
Suite Text File
Allows sequential execution of several .s test scripts. An ASCII file; can be used to store .txt data that is used to drive a data-driven testcase; can be used to print a file in another document (Word) or presentation (PowerPoint); can be a readme file to accompany your automation; can be used to transform a tab-delimited plan into a SilkTest plan. Is automatically created to store a history of results for a testplan or script execution. .res
Results File
Initialization File
Stores attribute data and query .ini information; defaults to testplan.ini; can be modified in SilkTests General Options dialog.
21
1 INTRODUCTION Exploring the SilkTest Window
Exploring the SilkTest Window

Before you begin to create tests, you should familiarize yourself with the SilkTest main window.
Open SilkTest
From the Start menu click Programs/SilkTest/SilkTest. SilkTest opens, with the Basic Workflow bar enabled. The Basic Workflow bar guides you through the process of creating a testcase. Using this workflow bar, you create a project, automatically enable and test extension settings, configure the recovery system, and record and run a testcase. If you want to turn off the Basic Workflow bar, click Workflows/Basic.
The standard toolbar
The standard toolbar provides easy access to the most commonly performed tasks. The type of file that is active determines what buttons are displayed and available on the toolbar. The image below shows the standard toolbar available for testplans.
Copy Find Text Move Left GoTo Source Mark Line UnMark Testplan Compile Run Run Marked
New
Save
Open
Cut
Paste
Repeat Find
Move Right
Modify Detail
Unmark Line
Find Next Marked
Find next error
Run Single Testcase
Note You can also execute some commands using shortcut keys.
22
1 INTRODUCTION Using SilkTest with Web Applications
Using SilkTest with Web Applications

The challenges of Testing Web Applications
Testing Web applications poses more of a challenge to the QA engineer than testing client/server or stand-alone applications, since Web applications: Must run as expected on various Web browsers on different platforms. Can have dynamic content that may change on a weekly or even daily basis. Have dramatically inconsistent response times. Use a wide variety of technologies.
SilkTest is optimized to face these difficult challenges.

Multiple browsers
People use different browsers on different platforms to access content on the Web. Typically, you have no control over the browser or platform on which a user runs your Web application. And browsers are not the same. For example: Different browsers display the same pages differently: they might align and size buttons differently; they might render certain text, colors and special characters differently; they might use different heights for table rows. The differences can be dramatic. Different browsers have different message boxes and security dialogs. Different browsers support different technologies.
If you are providing your application on the Web, you might want to support multiple browsers, rather than limiting your users to those of a particular browser. If you have made the decision to support multiple browsers, youll want to make sure that your application works as intended and looks good on those browsers. To that end you will need a Web testing tool that is browserindependent, enabling you to see objects in a Web application, not just images, and you need a tool that allows you to create tests against one browser and run them against others. With SilkTest, you can do crossbrowser testing.
Multiple technologies
Web applications can be implemented using a variety of technologies. These technologies are constantly evolving and new technologies are being developed all the time. SilkTest enables you to test your Web applications, regardless of how they are implemented and regardless of the technologies that comprise your application.
23
1 INTRODUCTION Using SilkTest with Web Applications Dynamic content
The Web demands information to be current. To meet this demand, the content of many Web applications changes regularly, requiring your testing tool be flexible enough to keep up with the changes to your application. With SilkTests robust scripting language, 4Test, you can quickly modify your test scripts to meet the ever-changing face of your application. Response times in a Web application vary dramatically, depending on the speed of the server, the speed of the client, network traffic, the speed of your connection, what needs to be downloaded for a particular user, and so on. Thats not a problem for SilkTest. SilkTest waits until your test page is fully loaded before it continues.
Synchronization issues
The Browser Extensions

About browser extensions
An extension is a file that serves to extend the capabilities of, or data available to, a more basic program. SilkTest provides extensions for testing applications that use non-standard controls in specific development and browser environments. Using the Basic Workflow, you can automatically enable and test extension settings. Youll have a chance to do this for the GMO application in Chapter 2, Preparing to Use this Tutorial on page 27. Browser extensions enable you to test Web applications. Before testing your Web application, you must specify the appropriate browser extensions on your target and host machines. SilkTest includes the following browser extensions, each of which is described briefly in this chapter: Document Object Model (DOM) browser extension Virtual Object (VO) browser extension
You must tell SilkTest which extensions to load for each AUTregardless of whether the application will run locally or on remote machines. You do this by enabling an extension on your host machine and on each target machine before you record or run tests. Once extensions are enabled for applications under test, SilkTest sends each Agent the list of extensions to be loaded, and the Agent dynamically loads the appropriate extensions for testing each application. Before you can begin testing, you must determine which browser extensions to enable for the applications that you plan to test.
24
1 INTRODUCTION Using SilkTest with Web Applications Document Object Model (DOM) extension
SilkTests Document Object Model (DOM) extension makes use of the DOM standard developed by the World Wide Web Consortium (W3C). This standard, currently supported by Internet Explorer (IE) versions 5.0.x and higher and Netscape 6, allows external applications, such as SilkTest, to query the browser directly for information about the Web page it is currently displaying. SilkTests DOM extension communicates directly with the Web browser to recognize, categorize and manipulate objects on a Web page. It does this by working with the actual HTML code, rather than relying on the visual pattern recognition techniques currently employed by the Virtual Object (VO) extension. For more information about the DOM extension, refer to the online Help.
Virtual Object (VO) extension
SilkTests proprietary Virtual Object (VO) extension uses sophisticated pattern recognition techniques to identify browser-rendered objects. The VO extension sees Web pages as they appear visually; it does not read or recognize HTML tags in the Web application code. Instead, the VO extension sees the objects in a Web page; for example, links, tables, images and compound controls the way that you do, regardless of the technology behind them. For more information about the VO extension, refer to the online Help. When you enable an extension on the host machine, SilkTest: Adds the extensions include file to the Use Files text box in the Runtime Options dialog, so that the extensions classes are available to you. Makes sure that the classes defined in the extension appear in the Library Browser. SilkTest does this by adding the name of the extensions help file (browser.ht) to the Help Files For Library Browser field in SilkTest General Options dialog and recompiling the help file used by the Library Browser. Merges the property sets defined for the extension with the default property sets.The Web-based property sets are in a file named browser.ps in the Extend directory. The file defines the following property sets: Color, Font, Values and Location. (For more information about property sets, see the online Help).
What SilkTest does when you enable a browser extension
When you disable an extension, SilkTest reverses the preceding actions.
25
1 INTRODUCTION Using SilkTest with Web Applications
26
2
2e rh C t p a
Preparing to Use this Tutorial

This chapter will walk you through the configuration necessary to use SilkTest to test the sample applications. You may choose to read the entire chapter or only those sections specific to the version of GMO that you will be testing. If you will be testing the GMO Web application, please start at Setting up to Test Web Applications on page 28. If you will be testing the GMO client/ server application, please proceed to Setting Up to Test Client/Server Applications on page 39.
In this chapter
This chapter contains the following sections:

Section Page
Setting up to Test Web Applications Becoming Familiar with the Web Application Under Test Setting Up to Test Client/Server Applications
28 32 39
Becoming Familiar with the Client/Server Application Under Test 44
27
2 PREPARING TO USE THIS TUTORIAL Setting up to Test Web Applications
Setting up to Test Web Applications

This section describes the steps necessary to prepare SilkTest to test the GMO Web application.
In this section
This section includes the following:

Section Page
Creating a New Project
28
Enabling Extensions
Specifying the Use Files
30
31

SilkTest projects organize all the resources associated with a test set and present them visually in the Project Explorer, making it easy to see, manage, and work within your test environment. SilkTest projects store relevant information about your project, including references to all the resources associated with a test set, such as plans, scripts, data, options sets, .ini files, results, and frame/include files, as well as configuration information, Editor settings, and data files for attributes and queries. All of this information is stored at the project level, meaning that once you add the appropriate files to your project and configure it once, you may never need to do it again. Switching among projects is easy - since you need to configure the project only once, you can simply open the project and run your tests.
Creating a GMO Project
Lets create a project for use in this tutorial. 1 Open SilkTest and make sure the Basic Workflow is enabled. When the Basic Workflow is enabled, the following workflow bar appears. If you do not see the Basic Workflow bar, click Workflows/Basic and select Basic.
On the Basic Workflow bar, click Open Project/New Project.
28
On the New Project dialog, double click Create Project.
On the Create Project dialog, type GMO as the Project Name and type Test of the GMO Application as the Description.
Click OK to save your project in the default location, <SilkTest installation directory>/Project. If you already have a project open, click OK to close the open project and create the GMO project. SilkTest will create a projectname folder within this directory, save the projectname.vtp and projectname.ini to this location and copy the extension .ini files to a projectname/extend subdirectory. If you do not want to save your project in the default location, click Browse and specify the folder in which you want to save your project.
SilkTest creates your project and displays nodes on the Files and Global tabs for the files and resources associated with this project. You are now ready to enable the required extensions for testing the GMO application.
29
Enabling Extensions
Note The Web application tutorial requires Internet Explorer 5.x. If you do not have IE 5.x, please proceed toSetting Up to Test Client/ Server Applications on page 39 and complete the tutorial for the client/server version of GMO.
Enabling the required extension
1 2
Open the GMO Web application in your Internet Explorer browser: http://gmo.segue.com/. On the Basic Workflow bar, click Enable Extensions. The Enable Extensions dialog lists all open applications that are not minimized, including any Web applications, which are identified by the currently loaded pages title.
Click Welcome to Green Mountain Outpost and then click Select to enable the required extension for this application. If Welcome to Green Mountain Outpost does not appear in the application list, make sure it is not minimized, and then click Refresh. On the Extension Settings dialog, click OK to enable the DOM extension. Close Internet Explorer, restart it, and navigate to http://gmo.segue.com/. On the Test Extension Settings dialog, click Test.
4 5 6
30
Click OK on the Test Passed dialog. If you were testing your own application, you would probably then configure the recovery system, which creates a frame file automatically; see the online Help for details. However, for the purpose of this tutorial, well use a frame file that is delivered with SilkTest.

The Use Files specifies the names of one or more include files for SilkTest to automatically load at startup. This means that SilkTest is able to use the object descriptions, as declared in these .inc files, to recognize the GUI objects in your application When you record a test frame, the full path of the test frame is automatically added to the Use Files text box. However, for the purpose of this tutorial you will be using a test frame, gmow.inc, that can be found in <SilkTest installation directory>/Exercise. You will learn more about the test frame when you create your own in Chapter 4, Capturing Your Application. For now, you will need to manually tell SilkTest where to find the gmow.inc file when SilkTest starts. You do this through the Runtime Options dialog. 1 2 In SilkTest, click Options/Runtime. In the Runtime Options dialog, click the Add button next to the Use Files text box.
Add button
31
2 PREPARING TO USE THIS TUTORIAL Becoming Familiar with the Web Application Under Test
Navigate to <SilkTest installation directory>/Exercise, select the gmow.inc file, and then click Open. The path to gmow.inc is added to Use Files.
Click OK on the Runtime Options dialog. You are now ready to explore the GMO application.
Becoming Familiar with the Web Application Under Test

Before you begin testing your application you should become familiar with the components of the application under test (AUT). The following exercises will familiarize you with the sample Web application you will be using throughout this tutorial. They will also show you how to use SilkTest to identify the objects within the AUT.
32
The GMO Web Application

The GMO application is a basic OnLine Catalog application. The following illustration shows the applications structure. GMO Online All Browsers OnLine Catalog Products Place Order Billing Information OnLine Store Receipt With the GMO application you can view a list of the items available, view a picture of the items, and read a description of the items. Once an item has been selected and a quantity defined, you are able to place an order, enter billing and shipping information and get a receipt. This is a sample application; no merchandise will be shipped to you. About This Site
Performing an End to End Transaction

As you complete this exercise make a mental note of the objects on each of the pages. Consider what objects you might want to test and how you might test them. 1 Start the GMO application Start Internet Explorer 5.x and load the home page of the GMO application, http://gmo.segue.com. Maximize the browser if necessary. 2 3 Go to the Catalog Page Click Enter GMO OnLine. Go to the Products page Click any Item in the Item Name column. Read the description of the product.
33
Select a product and place the order Click Back on your browser toolbar. Select a product to purchase on the Catalog Page by entering a quantity in the Order Quantity field. Click Place An Order. You may need to scroll down. The Place Order page opens. Click Proceed with Order. The Billing Information page opens.
Fill out the billing information Enter the required billing information in the appropriate fields. Note the following requirements: Phone number must be 10 digits Credit Card Number must be 15 digits Expiration date must be a future date
Enter required Ship To information or select Same as Bill To. Click Place The Order. The OnLine Store Receipt page opens. 6 Return to GMO home page On the OnLine Store Receipt page click Return to Home Page. Repeat this exercise, as necessary, until you are comfortable with the transaction flow of the application.
Viewing Objects with SilkTest

Setting-up to view object identifiers
In the next exercise you will observe the AUT through SilkTest, and see how SilkTest identifies objects. 1 Return to the GMO homepage If GMO is not already open, start Internet Explorer 5.x and load the home page of the GMO application, http://gmo.segue.com. Maximize the browser if necessary. 2 In SilkTest, open the Record Window Identifiers dialog. Click Record/Window Identifiers.
34
The Record Window Identifier displays the 4Test identifiers for the GUI objects. The actual name displayed by this tool depends on whether or not you have previously recorded declarations for the objects and if those files are specified in the Runtime Options Use Files. 3 Minimize the SilkTest main window In order to view the objects in the AUT, the AUT must be visible.
Viewing the browser identifiers
First you will take a look at the browsers objects. 1 View browser objects Point to the title bar of the browser. Notice that Record Window Identifiers identifies the window as Browser. Browser is a built-in window declaration for a Web browser.
Point to the Home button in the browser toolbar. SilkTest sees the button as Browser.Home, that is, as the object Home in the window Browser. Point to any of the other buttons in the browser toolbar. Notice that SilkTest reports some of the buttons as Explorer.X, where X is the buttons name.
Viewing the AUTs identifiers
Now take a look at some of the AUT objects as declared in the gmow.inc test frame, that you specified in the Runtime Options Use Files. Notice that the DOM extension sees the objects exactly as they are defined in the gmow.inc test frame. 1 View objects on the GMO Homepage Point to the Green Mountain Outpost image in top right corner. Notice that SilkTest identifies the object as GMO.Logo.
35
Point to the text Welcome to Green Mountain.... Notice that SilkTest identifies the object as GMO.WelcomeText.
View objects on the OnLine Catalog page Click Enter GMO OnLine to look at a table on the Online Catalog page. Point to the heading of the first column, Item Number. Notice that SilkTest identifies the object as:
That is, as the object Item Number within the object Catalog Table in the Window Catalog Page. For a review of objects. see Basic object-oriented concepts on page 10. 3 Close the Record Window Identfiers dialog When you have finished exploring, on the Record Window Identifiers click Close.
36
2 PREPARING TO USE THIS TUTORIAL Becoming Familiar with the Web Application Under Test Dynamic instantiation
Typically, before you begin recording your scripts you record a test frame that contains declarations of each of the Web pages within the application that you want to test. But if you have not declared the pages in the Web application, SilkTest dynamically instantiates the objects when you record them. This means that SilkTest automatically creates a unique name based on the objects class and tag. For more information about classes and tag see Basic object-oriented concepts on page 10. If we were not using the gmow.inc test frame to view the GMO application. the DOM extension would have dynamically instantiated the objects as displayed in the following image.
Browser.BrowserChild(Welcome to Green Mountain Outpost).HtmlImage(Logo|#1|$htt p:??gmo.segue.com?images?gmoanimate.gif) Browser.BrowserChild.(Welcome to Green Mountain Outpost).HtmlHeading(GMO OnLine) Browser.BrowserChild.(Welcome to Green Mountain Outpost).HtmlText(Welcome to Green Mountain Outposts OnLine Catalog!)
Browser.BrowserChild.Welcome to Green Mountain Outpost).HtmlLink(Please let us know how you like our site|#1|$mailto:gmomaster@segue.com)
Note If you would like to try this yourself, you must remove the gmow.inc file from the SilkTest Options/Runtime Use Files.
37
The DOM extension uses the following syntax when tagging dynamically instantiated objects: Syntax: Browser.BrowserChild.class("tag") Example: Browser.BrowserChild.HtmlHeading("GMO OnLine") In this declaration:
Browser refers to your Web browser Browser Child refers to any Web page that you have not declared HtmlHeading is the class of the object GMO OnLine is the caption
For more information about dynamic instantiation or syntax and structure, see the online Help.
Multi-tagging
The DOM extension also provides additional information for dynamically instantiated tags, when available, through multi-tagging. For example: Syntax: Browser.BrowserChild.class("caption|index|window identifier") Example: Browser.BrowserChild.HtmlLink(Please let us know how you like our site.|#1|$mailto:gmo-master@segue.com) In this declaration:
Browser refers to your Web browser Browser Child refers to any Web page that you have not declared. HtmlLink is the class of the object Please let us know how you like our site. is the caption. #1 is the index, signifying that this is the first HtmlLink on the page. $mailto:gmo-master@segue.com is the window identifier.
By multi-tagging, or generating any of the five types of tags: caption, prior text, index, window identifier and location for each object, the DOM extension provides a higher rate of object recognition. Since the DOM extension identifies an object by the tags, if one of the tags does not match, but the others do, your testcase will still succeed. For example, if you are testing a Web application with dynamically changing content the caption may change but the index would remain the same, enabling your test to succeed. For more information about multi-tagging, see the online Help. You have completed the preparation required to test the GMO Web application. Proceed to Chapter 3, Planning a Testing Strategy on page 55.
38
2 PREPARING TO USE THIS TUTORIAL Setting Up to Test Client/Server Applications
Setting Up to Test Client/Server Applications

This section describes the steps necessary to prepare SilkTest to test the GMO client/server application.
In this section
This section includes the following:

Section Page
Installing the GMO application
39
Creating a New Project Setting Up the Runtime Environment

40 42
49
Installing the GMO application

With this tutorial you will use SilkTest to test a sample application called Green Mountain Outpost (GMO). After you install SilkTest, you will need to install the GMO client/server application. You can obtain the GMO client/ server application for this tutorial from the SilkTest installation CD, or the download it from a web site.
Installing from CD
To install the GMO application from the CD: 1 Navigate to the GMO folder on the SilkTest CD Place the CD in the CD-ROM drive. If the SilkTest installation program starts, click Exit. Use the Windows Explorer to open the GMO folder. Note GMO must be installed on the same machine on which you have installed SilkTest. 2 Run the GMO installation program Double-click Setup.exe. The GMO installation program displays the GMO Setup screen. 3 Follow the instructions in the GMO Setup Note You do not need to restart your computer after the GMO installation.
39
2 PREPARING TO USE THIS TUTORIAL Setting Up to Test Client/Server Applications Installing from Download area
To install the GMO application from the download area 1 Navigate to the download area by going to the SilkTest area of the Segue - Support - Technical Support - Utilities web page (www.segue.com). Locate the SilkTest GMO application and double click to start the installation program. You do not need a license to run the GMO application. Note You do not need to restart your computer after the GMO installation.
GMO Database files
The GMO installation program installs the following database files and uses them to provide customer information: A text file database, green2.txt, and a back-up copy called green2base.txt A Microsoft Access database, green2.mdb, and a back-up copy called green2-base.mdb
The back-up copies allow you to restore the original information to the databases. For information see Restoring the Sample Database on page 143.

SilkTest projects organize all the resources associated with a test set and present them visually in the Project Explorer, making it easy to see, manage, and work within your test environment. SilkTest projects store relevant information about your project, including references to all the resources associated with a test set, such as plans, scripts, data, options sets, .ini files, results, and frame/include files, as well as configuration information, Editor settings, and data files for attributes and queries. All of this information is stored at the project level, meaning that once you add the appropriate files to your project and configure it once, you may never need to do it again. Switching among projects is easy - since you need to configure the project only once, you can simply open the project and run your tests.
Creating a GMO Project
Lets create a project for use in this tutorial.
40
Open SilkTest and make sure the Basic Workflow is enabled. When the Basic Workflow is enabled, the following workflow bar appears. If you do not see the Basic Workflow bar, click Workflows/Basic and select Basic.
2 3
On the Basic Workflow bar, click Open Project/New Project. On the New Project dialog, double click Create Project.
On the Create Project dialog, type GMO as the Project Name and type Test of the GMO Application as the Description.
Click OK to save your project in the default location, <SilkTest installation directory>/Project. If you already have a project open, click OK to close the open project and create the GMO project. SilkTest will create a projectname folder within this directory, save the projectname.vtp and projectname.ini to this location and copy the extension .ini files to a projectname/extend subdirectory. If you do not want to save your project in the default location, click Browse and specify the folder in which you want to save your project.
SilkTest creates your project and displays nodes on the Files and Global tabs for the files and resources associated with this project.
41
You are now ready to set up the Runtime environment for the GMO Client/ Server application.
Setting Up the Runtime Environment

In this tutorial you will use SilkTest to test the Green Mountain Outpost client/server application. As you go through the following chapters you will create files that provide the structure to your testing effort. These files include the testplan, test frame and the test script (also simply called script). You will also be asked to use files, completed versions of those that you created, that have been provided for use with this tutorial. The Runtime Options dialog allows you to specify settings that SilkTest uses when running a script. For the purpose of this tutorial our only concern will be with the Use Files and the Default Browser. For more information about the Runtime Options dialog, see the online Help.
The Use Files specifies the names of one or more include files for SilkTest to automatically load at startup. This means that SilkTest is able to use the object descriptions, as declared in these .inc files, to recognize the GUI objects in your application. When you record a test frame, the full path of the test frame is automatically added to the Use Files text box. However, for the purpose of this tutorial you will be using a test frame, gmoc.inc that can be found in <GMO installation directory>/Exercise. You will learn more about the test frame when you create one in Chapter 4, Capturing Your Application. For now, you will need to manually tell SilkTest where to find the gmoc.inc file when SilkTest starts. You do this through the Runtime Options dialog.
42
In SilkTest, click Options/Runtime.
Add Use File Set Default browser
2 3
In the Runtime Options dialog, click Add. In the Add Use Files dialog, navigate to <GMO installation directory>\Exercise, select gmoc.inc, and then click Open.
Remove the Default browser
For testing client/server applications, it is required that the Default browser be set to none. The Default browser field is used for testing Web applications only. 1 In the Runtime Options dialog, confirm Default browser set to none Make sure the Default browser field displays:
43
2 PREPARING TO USE THIS TUTORIAL Becoming Familiar with the Client/Server Application Under Test
If it does not, from the Default browser drop-down list box click [none]. 2 Confirm no browser extension in Use Files Make sure there are no browser include files, such as extend\explorer.inc, listed in the Use Files field. If there is, simply select the file and delete. 3 Close the Runtime Options dialog Click OK. You are now ready to become familiar with the GMO client/server application. Please see "Becoming Familiar with the Client/Server Application Under Test" below.
Becoming Familiar with the Client/Server Application Under Test

Before you begin testing your application you should become familiar with the applications components. The following exercises will familiarize you with GMO, the sample client/server application you will be using throughout this tutorial, and how to use SilkTest to identify the objects within that application.
The GMO application

The GMO client/server application is a basic Catalog application. The following illustration shows the applications structure.
Green Mountain Outpost Handling Customers Customer Information Customer Search Handling Orders Item Search Place Order Complete Order Order Status Administrative DB Admin About GMO
With the GMO application you are able to add a new customer to the database, search for an existing customer, search for a product and view the product information, enter payment information, complete the order and get a confirmation number.
44
Performing an End to End Transaction

Starting the GMO application
As you complete this exercise note the objects on each of the pages. Consider what objects you might want to test and how you might test them. 1 Start the GMO application From the Start menu choose Programs/Green Mountain Outpost/ GMO. The GMO application displays the following message:
For this part of the tutorial you will use the text file database. If you want to learn about testing a database, see Chapter 2, Preparing to Use this Tutorial on page 27. 2 Use the text database Click OK. The application displays the Green Mountain Outpost Main Window and the Customer Information Window, as shown below.
Selecting a customer
Display the Customer Search dialog In the Customer Information dialog, click Search.
45
Select a customer Select any Customer. Click Select. The GMO application re-displays the Customer Information dialog with information about the customer you selected, as show below for customer Patricia Durnfeld.
Placing an order
Display the Place Order dialog Click Place Order. A blank order screen appears.
46
Display the Item Search dialog Click Search. The Item Search dialog lists the items that you can order.
Select an item Select any item. Click Select. The item detail area of the Place Order dialog now displays information about the item you just selected. Note The Order Item button is not available until a quantity has been entered.
Enter a quantity and order the item Enter a quantity in the quantity text box. Click Order Item.
47
Note The Complete Order button is not available until an item has been ordered. 5 Display the Complete Order dialog Click Complete Order.
Enter the required order information Type the following information into the appropriate fields. Card Number Expiration Date - must be future date
48
Process the order Click Process Order. The GMO application displays a flashing confirmation box indicating that your order is being confirmed.
When your order has been confirmed, the GMO application displays a confirmation number in the Complete Order form.
Confirmation Number
Close the Complete Order dialog Click Close.

Setting-up to view object identifiers
In the next exercise you will observe the client/server AUT through SilkTest to see how SilkTest identifies objects. 1 Start the GMO Application If the GMO client server application is not already open, from the Start menu choose Programs/Green Mountain Outpost/GMO. Click OK to use the text file database. 2 In SilkTest, open the Record Window Identifiers dialog
49
Click Record/Window Identifiers.
The Record Window Identifier displays the 4Test identifiers for the GUI objects. The actual identifier displayed by this tool depends on whether or not you have previously recorded declarations for the objects and if those include files are specified in the Runtime Options Use Files. For more information about Runtime Options see Setting Up the Runtime Environment on page 42. 3 4 Minimize the SilkTest main window Set the AUT active In order to view the object in the AUT you will need to make the AUT the active window. Click the title bar of GMO.
Viewing the AUTs identifiers
Now take a look at some of the AUT objects as declared in the gmoc.inc test frame that you specified in the Runtime Options Use Files. 1 Look at objects on the Customer Information Window Point to the GMO Title Bar. Notice that SilkTest identifies the window as GMO in the Record Window Identifiers dialog.
Point to the Green Mountain Outpost image in top right corner. Notice that SilkTest identifies the object as: CustomerInformation.DialogBox1.GMOlogo. That is, as the object GMOlogo, in the object DialogBox1, in the object CustomerInformation.
Point to the Customer Number text field. Notice that SilkTest identifies the object as:
CustomerInformation.DialogBox1.CustomerNumber
Look at objects on the Customer Search dialog
50
On the Customer Information window, click Search. 3 Point to the text Customer Number. Notice that SilkTest identifies it as: CustomerSearch.CustomerNumberText. Point to the Customer Number text field. Notice that SilkTest identifies it as: CustomerSearch.CustomerNumber. Point to the Cancel button. Notice that SilkTest identifies it as: CustomerSearch.Cancel.
Close the Record Window Identfiers dialog. When you have finished exploring, click Close on the Record Window Identifiers dialog.
In GMO, close the Customer Search Dialog Click Close.
Dynamic instantiation
Typically before you begin recording your scripts you record a test frame for your application that contains declarations of each of the windows that you want to test. But if you have not declared the windows in your application, SilkTest dynamically instantiates the objects when you record them. This means that SilkTest automatically creates the unique name based on the objects class and tag. For more information about classes and tags see Basic object-oriented concepts on page 10. If we were not using the gmoc.inc test frame to view the GMO application. the SilkTest would have dynamically instantiated the objects as displayed in the following image.
MainWin("Green Mountain Outpost|$C:\Program Files\Segue\Gmo\green.exe"). ChildWin("Customer Information").DialogBox("#1| $59648").CustomWin("[BitMap] #2|$65535[2]") MainWin("Green Mountain Outpost|$C:\Program Files\Segue\Gmo\green.exe"). ChildWin("Customer Information").DialogBox("#1| $59648").TextField("Customer Number:|$1000")
51
Note If you would like to try this yourself, you must remove the gmoc.inc file from the SilkTest Options/Runtime Use Files. SilkTest uses the following syntax when tagging dynamically instantiated objects in client/server application: Syntax: class("tag ") Example: MainWin("Green Mountain
Outpost").ChildWin("Customer Information")
In this declaration:
MainWin refers to the class of the applications main window. Green Mountain Outpost is the identifier, Caption in this example, of
the object, MainWin.

ChildWin is the class of the Customer Information Window. Customer Information is the identifier of the ChildWin.
For more information about dynamic instantiation or syntax and structure, see the online Help.
Multi-tagging
SilkTest also provides additional information for dynamically instantiated tags, when available. For example: Syntax: class("caption|index|window ID ") Example: PushButton("Add|$1010") In this declaration:
PushButton is the class of the object Add is the caption. $1010 is the window identifier.
By multi-tagging, or generating any of the five types of tags: caption, prior text, index, window identifier and location for each object, a higher rate of object recognition is obtained. Since SilkTest identifies an object by the tags, if one of the tags does not match, but the others do, your testcase will still succeed. For example, if you record a caption and window ID for an object and the caption changes (such as from Open to OK) but the index remains the same, SilkTest is still able to find the object based on its window ID. For more information about multi-tagging, see the online Help.
52
What You Have Learned

In this chapter you learned: How to configure SilkTest to test the GMO application. How to use the Record Window Identifiers tool to explore the GUI objects within the application under test.
You also became familiar with the application under test, GMO.
53
54
3
3e rh C t p a
Planning a Testing Strategy

This chapter introduces Phase I of the Segue Testing Methodology, Planning. Plan Capture
Create
Run
Report
Track
This chapter provides information to help you formulate a testing strategy, and offers guidelines for determining which tests to automate. This section also examines the basic structure of a testplan and describes how to create a testplan using SilkTests testplan editor. Segue highly recommends that in order to gain more leverage in your testing effort, you utilize SilkTests planning tool, the testplan editor. Creating a testplan, however, is not required. If you chose not to create a testplan for your own testing you may begin with capturing a test frame, described in Chapter 4, Capturing Your Application. For this tutorial you will be creating a testplan.
In this chapter

Section Page
What is a SilkTest Testplan? Understanding the SilkTest Testplan Editor Creating a Testplan Defining and Associating Attributes
56 57 60 65
55
3 PLANNING A TESTING STRATEGY What is a SilkTest Testplan?
What is a SilkTest Testplan?

The SilkTest testplan is an outline that provides a framework for the software testing process and serves as the point of control for organizing and managing your test requirements. By using testplans to plan and manage your automated testing, you reap the following benefits: The outline model allows you to use a top-down approach when defining test requirements. This approach helps you to develop your thoughts about the testing problem and to refine requirements. Individual tests in the plan can be assigned characteristics, called attributes. Attributes can apply either to individual tests or groups of tests, depending on where you place them in the plan. Tests with a given attribute or set of attributes can then be run and reported on as a group. A hierarchical outline reduces redundancy by allowing the statements that actually implement the tests to be used by just a single test description or shared by a group of test descriptions. A testplan yields a comprehensive inventory of test requirements, from the most general to the most specific. You can decide what tests you want to run by marking the high-level description of the test. Theres no need to interact with individual script files or even to know where a testcase is located. You can selectively run or report on individual tests, groups of tests, or the entire testplan. A testplan communicates to reviewers how you plan to test the application and provides them with a framework for evaluating the testplans thoroughness and logic. Omissions and redundancies are easy to spot.
A successful testing effort begins with a well structured testplan. A testplan consists of two distinct parts: an outline, which is a formatted description of the test requirements, and statements, which are used to connect the testplan to SilkTest scripts and testcases that implement the test requirements.
56
3 PLANNING A TESTING STRATEGY Understanding the SilkTest Testplan Editor What goes into a testplan?
You can use the testplan to capture a variety of information, such as: An architectural overview of the application and testing approach Assumptions or risks associated with testing the application Individuals responsible for testing the application Prerequisites for testing the application Software dependencies Testplan review and revision history
Deciding what to test
One of the most challenging aspects of the test planning process is deciding which features of the application you want to test and which features do not require testing at all. Information that can help you clearly define the test requirements for your application can come from a different sources. Two primary sources of information are the product requirements document and the product functional specification. In addition to these documents, feedback from customers and support staff can also help you determine what to test. When defining test requirements, the goal is to determine how each feature of the application is supposed to work and then create tests that exercise those features thoroughly. It may not be practical to automate all your tests, so you should try to prioritize your automation strategy. You might consider automating a test if: It will be repeated frequently It is relatively easy to automate It is difficult to reproduce manually There is high risk associated with not performing the test before the application is released
Defining test requirements
Understanding the SilkTest Testplan Editor

The outline created in the testplan editor, the .pln file, like any other outline, uses indentation to indicate the hierarchical structure of the testplan. The following example shows a written outline of tests:
I. Billing Information page A. Verify caption is correct B. Verify all text fields are empty C. Verify Place Order push button is enabled D. Verify number of Credit Cards E. Verify format of Credit Card E. Verify Ship To check box is enabled
57
3 PLANNING A TESTING STRATEGY Understanding the SilkTest Testplan Editor
The following figure shows the same outline created with the testplan editor. The name of this testplan is sample.pln:
Comments Group descriptions Test descriptions
Using color to indicate structure
There are five types of text lines used by the editor, each with an identifying color. The default colors in the testplan editor are described below:
Color Component Description
Green
Comment
Additional user information that is incidental to the outline; preceded by double slashes (//); provides documentation throughout the testplan. Higher level lines of the hierarchical testplan outline that describe a group of tests; may be several levels in depth. Lowest level of the hierarchical testplan outline that describes a single testcase. Link scripts, testcases, test data, closed subplans or an include file (such as a test frame) to the testplan. Subplans to be included in a master plan. For more information about master plans and subplans, see the Users Guide and online Help.
Black
Group description
Blue
Test description
Dark Red
Testplan statement
Magenta
Open subplan file marker
58
3 PLANNING A TESTING STRATEGY Understanding the SilkTest Testplan Editor Indenting and changing levels
The testplan is divided into blocks of statements with different levels of indentation. Each successive level is indented one level to the right. A minus icon [-] indicates that the block is fully expanded. Clicking on the minus icon collapses the statements within that block. A plus icon [+] indicates that the block can be expanded further. Note Each line begins with a diamond icon character. , not the first
As you work in the testplan editor, you can use menu commands, shortcut keys or tool bar commands to move blocks in the hierarchy both horizontally and vertically. The following table summarizes the commands:
To Menu Item Key Toolbar
Increase the level of indentation (move the item lower in the hierarchy) Decrease the level of indentation (move the item higher in the hierarchy) Move the selected line(s) up Move the selected line(s) down
Outline/Move Right
Alt +
Outline/Move Left
Alt +
Outline/Transpose Up Outline/Transpose Down
Alt + Alt +
None None
Note Correct indentation is important in the testplan editor. Make sure that you move lines using the commands or icons listed in the table above. Do not use tabs or spaces to align lines; this will not work correctly.
59
3 PLANNING A TESTING STRATEGY Creating a Testplan
Creating a Testplan
1 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28. Click the Files tab in the Project Explorer, right-click the Plan folder, and then click New File. An untitled testplan file opens in the SilkTest editor.
3 4
Click File/Save. On the Save As dialog, name the Testplan: (Web): Name the testplan webtut.pln and save it in the SilkTest/ Projects/GMO folder. (client/server): Name the testplan cstut.pln and save it in the SilkTest/ Projects/GMO folder.
Click Save, and then click Yes when prompted to add the file to your project. The plan file appears in the Plan folder in the Project Explorer.
60
In the first line of the testplan insert double forward slashes, //. Note that they turn green, indicating a comment. Type a name for your testplan. For example, Sample Testplan for GMO. Enter another comment line and type the following Author: Your Name. Finally, create another comment line and type Date: Todays Date. The following shows what your testplan should look like.
Note It is good practice to add comments to your work. They help to provide others with an understanding of your intent, as well as, serving as reminders to yourself. 6 Click File/Save.
You will develop this testplan further in the next section.

Importing a testplan
You can import an existing testplan into the testplan editor if it was written in tab-indented format and saved in ASCII text file format. Simply select the contents of the outline in the .txt file, copy to the clipboard and paste into your testplan. SilkTest automatically formats the indentation of your testplan. A testplan can also be developed as an outline in Word and then converted into a testplan. For more information about importing testplans see the online Help.
61
Structuring Your Testplan

The structure and content of the testplan outline will vary according to the hierarchy necessary to meet your specific testing requirements. For this tutorial we will take the simple approach of creating a few operability tests for the GMO application.
Creating the group descriptions for the testplan
This exercise will show you how to create the top-level group descriptions for operability tests for the GMO application testplan. 1 In your testplan, create the top level group descriptions To add some blank lines, click at the end of the last comment and press Enter several times. (Web): Type GUI Tests. Press Enter to add a new line.
(client/server): Type the name of the first window, Customer Information Window. Press Enter to add a new line.
62
Indent the new line With the cursor on the line you created in the last step, click Outline/ Move Right. Notice that the [-] icon appears in the group description above, indicating that the group description is expanded.
Create the second level group descriptions (Web): On the newly indented line type GMO OnLine. Press Enter. Type Billing Information Page.
You have just added a second level and created two group descriptions for GUI Tests indicating that there will be GUI tests for the GMO OnLine homepage and the Billing Information page. (client/server): On the newly indented line, type GUI Tests.
You have just created a group description that indicates that for the Customer Information window there will be GUI tests. 4 Save the Changes Click File/Save.
63
3 PLANNING A TESTING STRATEGY Creating a Testplan Creating the test descriptions
This exercise will show you how to add test descriptions within each of the group descriptions. 1 Add a line below the group description (Web): Click the end of the GMO OnLine group description. Press Enter. (client/server): Click the end of the GUI Tests group description. Press Enter. 2 Indent the new line Click the line you just created, click Outline/Move Right. Notice that the [-] icon appears in the group description above, indicating that the group description is expanded. 3 Add some test descriptions In the line you just created, (Web): Type Verify caption is correct. Press Enter. Type Verify Enter GMO OnLine pushbutton is enabled.
(client/server): Type Verify caption is correct. Press Enter. Type Verify Search pushbutton is enabled.
64
3 PLANNING A TESTING STRATEGY Defining and Associating Attributes
Note Remember to indent properly. Do not use the space bar or tab key. 4 Save the changes Click File/Save.
Defining and Associating Attributes

Attributes are site-specific or project-specific characteristics that you define for your testplan and assign to test descriptions or group descriptions. They are used to categorize tests, so that you can then reference them as a group. The benefit of using attributes is that they can be incorporated into queries, allowing you to mark and run testcases in a testplan based on criteria that you set. Attributes can also be used as a means to categorize report data.
Default attributes
SilkTest provides three default testplan attributes with predefined names:

Attribute Specifies
Category
The type of testcase or group of testcases. For example, the testcase might belong to a category called Negative Tests or Smoke Tests. The name of the application modules to be tested. The name of the QA engineer assigned to develop the testcase or group of testcases or the name of the software engineer responsible for the feature being tested.
Component Developer
Attribute Names are limited to 11 characters and cannot have spaces. They are not case sensitive. Note You may rename any attributes, including the default attributes. However, renaming attributes does not update those attributes that are already in use in existing testplans. If you have existing testplans renaming attributes may result in orphaned attributes in those testplans. Attribute Values are the values that have been assigned to a specific attribute. For example, the Component attribute may have the values Place Order, Billing Information and OnLine Receipt. The developer attribute may have the values Joe, Peter and Sally.
65
3 PLANNING A TESTING STRATEGY Defining and Associating Attributes Where are the attributes stored?
Attribute data, as well as queries, are stored by default in the testplan initialization file, testplan.ini, located in the SilkTest installation directory. The default file can be changed. For information about initialization files, see the online Help. In the following exercise, you will define values for the default attributes. 1 Open the testplan (Web): If webtut.pln is not already open, double-click the file under the Plan folder in the GMO Project. If your project is not open, click File/ Open Project. (client/server): If cstut.pln is not already open, double-click the file under the Plan folder in the GMO Project. If your project is not open, click File/Open Project. 2 Open the Define Attributes dialog Click Testplan/Define Attributes.
Defining values for default attributes
3 4
Select an attribute In the Attributes list box select Developer. Add a name to values list In the Add text box, located in the bottom right corner of the Define Attribute dialog, type Andy. Click Add. Note The Add button is not available until you type something in the Add text box.
Repeat the previous step to define values for these developers Bob Tom Patricia
66
The Define Attributes dialog should look like this:
Note Attributes are displayed in alphabetical order.

Defining new attributes and their values
In the following exercise, you will define a new attribute and its values. 1 Open the New Attribute dialog On the Define Attributes dialog, click New.
2 3
Name the Attribute In the Name text field type Priority. Select attribute type Select the default Normal. The following table explains the different attribute types.
Type Description
Normal
You specify values when you define the attribute. Only one value can be assigned per testplan statement. You specify values when you associate the attribute with the testplan. Only one value can be assigned per testplan statement. You specify values when you define the attribute. Multiple values can be assigned per testplan statement.
Edit
Set
67
4 5
Close New Attribute dialog Click OK. Assign values for the attribute In the Add text field type the value High. Click Add. Repeat for the values Medium and Low. Note Values are displayed in alphabetical order.
Close the Define Attributes dialog Click OK.
Associating attributes
The next exercise shows you how to associate attributes with statements in a testplan. 1 In SilkTest, open the testplan (Web): If webtut.pln is not already open, double-click the file under the Plan folder in the GMO Project. If your project is not open, click File/ Open Project. (client/server): If cstut.pln is not already open, double-click the file under the Plan folder in the GMO Project. If your project is not open, click File/Open Project. 2 3 Select a testcase Click on the test description Verify caption is correct. Open the Testplan Detail dialog Click Testplan/Detail.
Web application
Client/server application
In the top portion of the Testplan Detail dialog, the right arrow icon points to the line of the testplan in which the insertion point was placed when you invoked the dialog.
68
Assign a Developer to the selected testcase Click the Test Attribute tab. Click in the Developer field. Using the scroll bar to the right of the drop-down list, select Tom.
Close the Testplan Detail dialog Click OK. The attribute Developer, value Tom is assigned to the testcase. The attribute, in red, is added below the Verify caption is correct test description in the testplan.
6 7 8
Save the changes Click File/Save. Close the testplan Click File/Close. Close the GMO application

In this chapter you learned: What a testplan is and the benefits of using one. How to use the SilkTest testplan editor. How to create a testplan. How to define and associate attributes with a testplan. Plan Capture
Create
Run
Report
Track
69
70
4
4e rh C t p a
Capturing Your Application

This chapter introduces Phase II of the Segue Testing Methodology, Capturing. Plan Capture
Create
Run
Report
Track
Capturing refers to the capture of information about the application under test. The information captured is stored in a test frame. Though you dont have to create a test frame, by doing so you will find it much easier to understand, modify and interpret the results of your tests.
In this chapter

Section Page
The Test Frame Creating a Test Frame The Window Declaration Windows that Precede the Main Window Testing DefaultBaseState Tags and Identifiers
72 78 80 83 87 88
71
4 CAPTURING YOUR APPLICATION The Test Frame
The Test Frame

Before you begin recording testcases, SilkTest needs to learn some things about your application. This is done by capturing, in a test frame, the data structures that will support your testcases. The test frame is an include file (.inc) that acts as a repository of information about the AUT, storing window declarations, constants and variables. SilkTest references this test frame when recording and running testcases. For more information about how SilkTest references test frames see the tutorial named Preparing to Use this Tutorial.
Building a test frame
You build a test frame in two stages, by First, recording the window declaration for the main window. Next, bringing up each of the application windows/dialogs one at a time and recording its declarations.
The first stage automatically takes place when you create the <test frame>.inc itself. Once the test frame has been created, you then add the window declarations for the other windows/dialogs in your application.
What is Captured in the Test Frame?

The information captured for a Web application is different from that captured for a client/server application. If you are testing the Web application read "Test frames for Web applications" below. If you are testing the client/ server application proceed to Test frames for client/server applications on page 76.
72
Test frames for Web applications

When you create a test frame for a Web application the following information about the application is captured and stored in the declaration for the main window:
A constant named wMainWindow
This constant holds the identifier value of your applications home page, that is, the page that was displayed in the browser when you created the test frame. The recovery system uses wMainWindow to restore the browser to that page when a test fails.This is known as BaseState. Typically the BaseState navigates to the first page of the application. This window has the same identifier as the value of wMainWindow; this is the window that SilkTest loads in order to restore the application to BaseState. The URL for the homepage; used by the recovery system to load the page. Two commented constants that specify the user name and password to access the application (if required). Two commented constants that specify the size of the browser window and the default font to use for displaying text. Declarations of all objects on the page, such as HtmlHeadings, HtmlText, HtmlLinks, HtmlText, HtmlPushButtons and so on.
A window of class BrowserChild
sLocation sUserName and dPassword BrowserSize and bDefaultFont Objects Declarations
73
The following image shows a test frame for the GMO homepage:
wMainWindow comments
window BrowserChild sLocation sUserName dPassword constant BrowserSize constant bDefaultFont
Object declarations
Specifying username and password The two built-in constants sUserName and sPassword, are commented out (//) in the generated test frame, as shown above. You can uncomment those constants and supply values to specify your user name and password if your application requires you to enter such information. Once you have done this, whenever you are loading a page and you are prompted for user name and password, SilkTest will automatically supply the values and click OK in the message box, enabling the testcase to run unattended. For more information about Login, see the online Help. Specifying browser size and fonts By default, two other built-in constants are also enclosed in comment tags in a generated test frame: BrowserSize and bDefaultFont. The recovery system uses these two constants to set the browsers state before and after each test is run. They are useful in establishing a consistent environment for your testing. BrowserSize Specifies the width and height of the browser window, in pixels. The data type is POINT, which is a record of two integers. The first integer is the width in pixels; the second integer is the height in pixels. The default value ( {600, 400} ) is an appropriate size for a screen with VGA resolution (640 by 480).
74
If you are using a higher resolution, you would want a larger size for the browser window (the larger the better, in order to minimize scrolling in the testcases). For example, if you are using a resolution of 1280 by 1024, a good BrowserSize might be {650, 900}, which would take up about half the width and most of the height of the desktop. bDefaultFont If this constant is set to TRUE, the recovery system restores the fonts to the shipped defaults for the browser, as follows:
Browser Action by recovery system if bDefaultFont is TRUE
Internet Explorer Netscape Navigator
Sets the font size to Medium. Sets the variable-width font to be 12-point Times New Roman. Sets the fixed-width font to be 10-point Courier New.
Using these constants To have the recovery system set the size and fonts, uncomment the constants in the test frame and specify appropriate values. Important Having the recovery system set the browser size and fonts ensures maximum portability of your window declarations in different testing sessions and between browsers. We strongly recommend that you use these constants. Please proceed to How is the test frame used? on page 77.
75
Test frames for client/server applications

When you create a test frame for a client/server application the following information about the application is captured and stored in the declaration for the main window:
wMainWindow
This constant holds the identifier of your applications main window, that is, the window that is displayed when you created the test frame. The recovery system uses wMainWindow to restore the application to that window when a test fails. This is known as Basestate. This constant holds the path of the working directory of the application under test. This constant holds the full path and file name of the executable to start the application under test. This constant holds the identifier of the first window to open when the application is started; this window may be a login or security window. By default this constant is commented out. This constant pertains to the configuration of the recovery system. This constant holds the identifier of one or more windows, other than the main window, to leave open after a testcase has completed execution. By default this constant is commented out. This constant pertains to the configuration of the recovery system. This declaration is automatically included when creating a new test frame for a client/server application. It provides declarations for controls that are commonly associated with a message box, such as static text for the message and the OK, Cancel, Yes and No push buttons. This declaration is valid for all the message boxes in your application.
sDir sCmdLine wStartup
lwLeaveOpen
MessageBoxClass
Note SilkTest allows you to define additional or alternative controls for MessageBoxClass. For example, you may want to add alternative static text objects or additional push buttons. For more information, see the online Help.
76
The following is an example of a test frame for the client/server application.

wMainWindow
comments sDir sCmdLine wStartup lwLeaveOpen
MessageBoxClass
How is the test frame used?
When you create a test frame, SilkTest automatically adds the test frame to the Use Files field of the Runtime Options dialog. This allows SilkTest to reference the information in the test frame for use by the Recovery System, the recorder (when generating code) and the agent (during playback).
Use Files
77
4 CAPTURING YOUR APPLICATION Creating a Test Frame
Creating a Test Frame

The following exercise will show you the first stage of creating the test frame, recording the window declaration for the main window. 1 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project). If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28. Start the GMO application (Web): Start Internet Explorer 5 and navigate to the home page of the GMO application, http:\\gmo.segue.com. Maximize the browser if necessary. (client/server): From the Start menu choose Programs/Green Mountain Outpost/GMO. Click OK to use the text field database. 3 4 In SilkTest, open the New dialog Click File/New. Open New Test Frame dialog Select the Test Frame button.
Click OK. This New Test Frame dialog appears and lists all open applications that are running and not minimized.
78
4 CAPTURING YOUR APPLICATION Creating a Test Frame
Web application
Note If Green Mountain Outpost is not listed and you know that it is running, click Cancel, open the GMO application, and then click File/New to start over. 5 Select the Application (Web): Select Welcome to Green Mountain Outpost from the list of applications. Note that information displayed in the text fields of the New Test Frame dialog changes. (client/server): Select Green Mountain Outpost from the list of applications. Note that information displayed in the text fields of the New Test Frame dialog changes. 6 Specify a new File name The File name identifies the path and file name for the new test frame. The default name of the test frame is frame.inc. By default, subsequent test frames in the same directory are named frame1.inc, frame2.inc and so on. You can click Browse to specify a different path and file name for the test frame, or you can edit the contents of the File Name field directly. (Web): Click Browse; the New Test Frame - File Name dialog opens. Navigate to the <SilkTest installation directory>\Exercise and name the file webtut.inc. Click Open. (client/server): Click Browse; the New Test Frame - File Name dialog opens. Navigate to the <GMO installation directory>\Exercise and name the file cstut.inc. Click Open.
79
4 CAPTURING YOUR APPLICATION The Window Declaration
Change the default Window Name In the 4Test Identifier text box at the bottom of the New Test Frame dialog, type GMO to provide a shorter identifier that is easy to use.
8 9
Close the dialog Click OK. The new test frame appears. Open the declaration (Web): Click the plus icon [+] next to the line window BrowserChild GMO. (client/server): Click the plus icon [+] next to the line window MainWin GMO.
10 Save the declaration Click File/Save. The new test frame is added to your project.
The Window Declaration

The second stage of creating a test frame is recording window declarations for the other windows/pages/dialogs in your application and adding those declarations to the test frame. Note You dont need to have all the declarations in one file. You can put them into different files, and make them available to scripts using the 4Test use statement. For more information about use statements, see the online Help.
Recording window declarations
In SilkTest, open the test frame (Web): If webtut.inc is not already open, click File/Open and select the test frame webtut.inc. (client/server): If cstut.inc is not already open, click File/Open and select the test frame cstut.inc.
Open another window of the AUT (Web): If GMO is not open, start Internet Explorer and navigate to the homepage of the GMO application, http:\\gmo.segue.com. Maximize the browser if necessary. On the GMO OnLine home page, click Enter GMO OnLine. The OnLine Catalog page opens.
80
(client/server): If GMO is not open, from the Start menu choose Programs/Green Mountain Outpost/GMO. Click OK to use the text file database. Click the title bar of the Customer Information window to make it active. 3 In SilkTest, open the Record Window Declarations dialog Click Record/Window Declarations. Move your pointer around the GMO window. Notice that the values in the Record Window Declarations dialog change to reflect the object the pointer is currently over. Note From this dialog you can modify the identifiers and tags that SilkTest generates for a window declarations. 4 Select the window to declare (Web): Click the background of the OnLine Catalog page. (client/server): Click title bar of the Customer Information window.
81
Pause tracking Press Ctrl+Alt to pause tracking. The declaration is captured in the Record Windows Dialog, as shown in the following figures:
Web application
Note The object selected in the Window Declaration area, at the bottom of the Record Window Declaration, may vary depending on where your pointer was at the time you paused tracking. 6 Paste the new declaration to your test frame Click Paste to Editor. The declaration is pasted to the open test frame. If you wanted to declare more pages of the application you would click Resume Tracking on the Record Window Declarations dialog, and repeat Steps 3 through 6 for the other pages in the application. 7 8 Close the Record Window Declarations dialog Click Close. In SilkTest, save the changes to the test frame Click File/Save. For more information about recording window declarations, see the online Help. Completed test frames are provided for both the GMO Web and client/server applications to be used later in this tutorial. The files are located in: (Web): <SilkTest installation directory>\Exercise (client/server): <GMO installation directory>\Exercise
82
4 CAPTURING YOUR APPLICATION Windows that Precede the Main Window
Windows that Precede the Main Window

Although an applications main window is usually displayed first, it is also common for a login or security window to be displayed before the main window. If you do not tell SilkTest how to handle this first window it will not be able to meet DefaultBaseState, and therefore it will not be able to run any testcases. You can handle such a window by deriving, from the Invoke method used by DefaultBaseState, a new Invoke method. There are three steps to defining a derived Invoke method: Step 1: Record a declaration for the first window and include it in your test frame. Step 2: Complete the declaration for the wStartup constant. Step 3: Define an Invoke method in the main window declaration that calls the built-in Invoke method and performs any actions required by the first window. Important The following exercise is for the client/server sample application only. If you are completing the tutorial for the GMO Web application, please proceed to Testing DefaultBaseState on page 87. If you are completing the tutorial for the GMO client/server application, please continue on to "Handling windows that precede the main window".
Handling windows that precede the main window
The following exercise shows you how to create a derived Invoke method for the GMO client/server application. This derived Invoke method tells SilkTest how to handle the dialog box that appears before the main window.
Step 1: Create the declaration

1 2 Close the GMO client/server application if it is running Activate the dialog that precedes the applications main window Open the GMO application. From the Start menu choose Programs/ Green Mountain Outpost/GMO.
The Green Mountain Outpost dialog appears. Do not close it.
83
3 4
In SilkTest, open the test frame Open cstut.inc. Record a declaration for the dialog Click Record/Window Declarations. Point to the title bar of the Green Mountain Outpost dialog that you left open in Step 2. Press Ctrl+Alt. The declaration is captured in the Record Windows Dialog, as shown in the following figure:
5 6
Paste the declaration to the test frame Click Paste to Editor. Close the Record Window Declarations dialog Click Close. A declaration for window DialogBox GreenMountainOutpost is added to the test frame.
Step 2: Complete the declaration for the wStartup constant

1 In SilkTest, remove the comment characters (//) at the beginning of the declaration. If it is not already expanded, expand the declaration for window MainWin GMO by clicking on the plus icon [+]. In the MainWin declaration, select the constant wStartup, which appears several lines down, by clicking to the left of the diamond icon . Click Outline/Uncomment Block. Note A red X appears to the left of the constant.
84
Define the identifier for the wStartup constant. Replace the question mark with the identifier of the Green Mountain Outpost dialog, GreenMountainOutpost, as recorded in the window declaration. You may want to copy and paste the identifier from the window declaration. Note When you click anywhere else on the test frame the red X disappears.
Step 3: Record the new Invoke method

1 2 In the cstut.inc test frame, click the constant wStartup. Open the Record Method dialog Click Record/Method.
Select the Method name From the Method Name list box, select Invoke.
Open the GMO application. From the Start menu choose Programs/Green Mountain Outpost/ GMO. The Green Mountain Outpost dialog appears. Do not close it.
In SilkTest, start recording On the Record Method dialog, click Start Recording. SilkTest is minimized, the Green Mountain Outpost dialog appears and the SilkTest Record Status dialog appears.
Perform and record the actions to dismiss the dialog On the Green Mountain Outpost dialog, first click the title bar to set the dialog active. Second click OK, to dismiss the dialog.
Getting Started: A Tutorial 85
Finish recording On the SilkTest Record Status dialog, click Done. The Record Method dialog appears with the actions you just recorded on the Green Mountain Outpost dialog translated into 4Test statements.
8 9
Paste the Method into the test frame On the Record Method dialog, click Paste to Editor. Open the new method In the test frame, cstut.inc, expand the new Invoke method by clicking the plus icon [+].
10 Add a new line in the test frame Click at the end of the word Recording, the second line of the Invoke method. Press Enter. 11 Add a statement On this new line type derived::Invoke (). Keywords are case sensitive and there must be a space between Invoke and (). 12 Save the changes Click File/Save. You have finished telling SilkTest how to handle a dialog box that appears before the main window.
86
4 CAPTURING YOUR APPLICATION Testing DefaultBaseState
Testing DefaultBaseState
In the next exercise you will run DefaultBaseState to make sure that you have correctly captured the test frame. You do this to ensure that the Recovery System can work properly. 1 2 Close the GMO application if it is running In SilkTest, open the test frame (Web): Open webtut.inc. (client/server): Open cstut.inc. 3 Open the Run Application State dialog Click Run/Application State.
Run DefaultBaseState If it is not already selected, select DefaultBaseState. Click Run. The Runtime Status Dialog opens momentarily.
87
4 CAPTURING YOUR APPLICATION Tags and Identifiers
Then a results file opens indicating whether or not DefaultBaseState has been achieved. Results files are discussed further in the Reviewing and Reporting Test Results tutorial.
Web application Client/server application
Close the results file Click File/Close. Note If an error message appears saying that GreenMountainOutpost is not unique, make sure there are no stray dialogs open.
Tags and Identifiers

Each object declaration has a class, a tag and an identifier. The home page of the GMO Web application has the class BrowserChild while the Main Window of the GMO client/server application has the class MainWin. Its default identifier is the name you specified in the 4Test identifier field when you created the test frame, in this case GMO. The tag, which is not modifiable, is generated by SilkTest and it is the way that SilkTest identifies the object at runtime.
Class Identifier
Tag
Note Tags, identifiers and all other aspects of window declarations are described in detail in the online Help.
88
4 CAPTURING YOUR APPLICATION Tags and Identifiers Why do I want to modify the identifiers?
You may want to modify the identifiers in your declaration files to make them more meaningful to you. For example, the table below shows some identifiers as captured by SilkTest for the Web applications homepage versus identifiers for the same objects that have been modified to be more meaningful to the user.
Identifier WelcomeToGreenMountainOutp ThisIsASampleWebSiteFor InformationInThisDocumentI Modified Identifier WelcomeText DemoText CopyrightText
To make your tests easier to maintain, you can change the objects identifiers to correspond to their meaning in the application.
Modifying identifiers
You can modify the objects identifiers in one of two ways: After you have recorded the window declaration, by modifying them directly in the test frame (.inc) or other declaration files, or As you record the window declarations, by modifying the identifier in the Window Detail area of the Record Window Declarations dialog.
To modify identifiers in the Record Window Declarations dialog: 1 Open GMO (Web): If GMO is not open, start Internet Explorer and load the homepage of the GMO application, http:\\gmo.segue.com. Maximize the browser if necessary. (client/server): If GMO is not open, from the Start menu choose Programs/Green Mountain Outpost/GMO. Click OK to use the text file database. 2 Navigate to a new window (Web): Click Enter GMO OnLine. The OnLine Catalog page opens. (client/server): Click the Customer Information window. If the Customer Information window is not open, click Order/Customer Information. The Customer Information window opens.
89
In SilkTest, open the test frame (Web): If webtut.inc is not already open, click File/Open and select the test frame webtut.inc. (client/server): If cstut.inc is not already open, click File/Open and select the test frame cstut.inc.
4 5
Open the Record Window Declarations dialog Click Record/Window Declarations. In GMO, Select the window (Web): Click the background of the OnLine Catalog page. (client/server): Click the title bar of the Customer Information window.
6 7
Pause tracking Press Ctrl+Alt. Select the object From the Window Declaration list on the Record Window Declaration dialog, select the object that you want to modify. (Web): Select the HtmlText TheseAreTheItemsCurrently1. (client/server): Select the CustomWin Bitmap2.
Modify the identifier In the Window Detail area, select the old identifier and type the new identifier in the Identifier field. (Web): Type CatalogInstructions. (client/server): Type GMOLogo. To modify more identifiers on this window repeat steps 7 and 8 for each of the objects that you want to modify.
Create the declaration When you have finished making changes, click Paste to Editor. SilkTest pastes the window declaration to the active test frame or to the include file. If an include file is not active, SilkTest creates a new one. This creates two window declarations with the same name; we recommend commenting out the first window declaration.
10 Close the Record Window Declarations dialog Click Close. SilkTest returns to view and the .inc file is displayed. The window declaration has been added to the file. You can expand this declaration and compare it to the one you created in Recording window declarations on page 80.
90
11 Save the test frame Click File/Save. 12 Close the test frame Click File/Close. For more information about working with identifiers and window declarations, see the online Help.

In this chapter you learned: What a test frame is and the benefits of using one. How to capture a test frame. How to add window declarations for other windows to the test frame. How to handle a window that appears before the main window. How to test DefaultBaseState. How to read a test frame and modify identifiers. Plan Capture
Create
Run
Report
Track
91
92
5
5e rh C t p a
Creating Testcases
This chapter introduces Phase III of the Segue Testing Methodology, Creating. Plan Capture
Create
Run
Report
Track
Recording and running tests is the core of what you will do with SilkTest.
In this chapter

Section Page
Guidelines for Creating Testcases Recording a Testcase Linking Scripts and Testcases to a Testplan Recording from a Testplan Exploring the Connections: Testplans, Scripts and Testcases Examining the Structure of a 4Test Statement Understanding How the Recovery System Works
94 94 101 104 109 111 112
93
5 CREATING TESTCASES Guidelines for Creating Testcases
Guidelines for Creating Testcases

When creating a testcase, you should keep the following in mind: A testcase has three fundamental tasks: Drive the application to the state to be tested Verify that the actual state matches the expected state Return the application to its initial state (also called the base state)
Each testcase is independent of other testcases; that is, no script or testcase should rely on the successful completion of a previous script or testcase. Each testcase should have a single purpose. This makes it easy to determine specifically what aspect of the application is either working or not working. A testcase starts from base state. In order for a testcase to be able to function properly, the application must be in a stable state when the testcase begins to execute. Tip After learning the basics of recording a testcase in the next section, be sure to read about Recording from a Testplan on page 104. That section describes how to make recording easier by automatically generating the links that connect the testplan to the testcase for you.
Recording a Testcase
There are three steps to recording a testcase: Step 1: Setting up to Record Step 2: Recording the Setup Stage Step 3: Recording the Verification Stage
You must complete the exercises in this section consecutively.
94
5 CREATING TESTCASES Recording a Testcase
Step 1: Setting up to Record

Before you begin recording testcases you need to:
Configuring SilkTest
Make sure that SilkTest is configured properly Name your testcase
1 2
In SilkTest, open Runtime Options dialog Click Options/Runtime. Confirm the test frame After capturing the test frame in the last chapter you will need to replace the test frame in the Use Files. (Web): Remove the path to webtut.inc. Click Add. Select gmow.inc. Click Open.The path to the gmow.inc test frame must be listed before the extend\explorer.inc. If it is not, cut and paste the files to adjust the order. A comma should separate the files. Your Use Files field should look something like this:
C:\Program Files\Segue\SilkTest\Exercise\gmow.inc,extend\explorer.inc
(client/server): Remove the path to cstut.inc. Click Add. Select gmoc.inc. Click Open. Leave gmow.inc open while you complete the following steps. 3 Confirm the default browser (Web): Make sure that IE 5.x DOM is selected. (client/server): Make sure the (none) is selected. 4 Close Runtime Options Click OK.
Naming the testcase
Make sure there are no files open in SilkTest. 1 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 27. Open the Record Testcase - Open 4Test script dialog Click Record/Testcase.
95
SilkTest displays the Record Testcase dialog.
Name the testcase By default the testcase is named Test1 (unless that name is used in the current script file, in which case the default name is Test2, and so on). It is good practice to choose a name that indicates the purpose of the testcase. (Web): The testcase you create will verify the caption of the GMO home page. Type the name Verify_Window_Caption in the Testcase name text box of the Record Testcase dialog. (client/server): The testcase you create will verify the caption of the Customer Information window. Type the name Verify_Window_ Caption in the Testcase name text box of the Record Testcase dialog. Note Testcase names are not case sensitive; they can be any length and consist of any combination of alphanumeric and underscore characters, but they must begin with a letter.
Select the application state Select DefaultBaseState to have the built-in recovery system restore the default base state before the testcase begins executing.
Start recording Click Start Recording. The following sequence of events occurs. The Record Testcase dialog closes. Your application is started, if it was not already running. The SilkTest editor window disappears from the display. The Record Status dialog appears.
96
The status field flashes Recording to indicate that from here on, SilkTest is recording all mouse actions and keystrokes, intentional or unintentional, as you interact with the GMO application. Leave the Record Status dialog open. Note Unintentional actions can be removed from the script later. Tip Record your actions slowly. Observe the Record Status dialog to make sure the name of the object you are interested in is displayed. If the name of the object is not displayed, wait for the recorder to catch up.
Using the Record Status dialog
Move your pointer over the window, it does not matter which window. Notice that as you move over the application while recording, the Record Status dialog dynamically updates to show the object that you are currently pointing to or the control that has focus. Use this information to make sure that the recorder has kept up with your actions (sometimes the recorder can fall behind if your systems resources are low). Remember to check the Record Status dialog before pressing Ctrl+Alt to do your verification.
Step 2: Recording the Setup Stage

For our testcase it is not necessary to record the setup stage. However, if you wanted to verify an object that was on a page other than the main window or Homepage, you would need to drive the application to that page; pressing links or entering information as required. You could also use an application state that is built on BaseState. For more information about application states, see the online Help.
97
Step 3: Recording the Verification Stage

Testing applications involves verifying that the state of the GUI object is the same as the baseline state expected. To achieve this you can: Test the properties to verify an object Capture all or part of a bitmap to verify the appearance of an object Use a method to verify an object
You will perform most of your verifications using properties. The next exercise will show you how to test the properties of an object. By recording verification statements for the values of one or more of an objects properties, you can determine whether the state of the application is correct or in error when you run your testcases. For more information about verifying objects see the online Help. 1 Open the Verify Window (Web): Point to the background of the GMO OnLine homepage. Look at the Record Status dialog and make sure it is lists GMO. If so, press Ctrl+Alt. (client/server): Open the Customer Information window, click Order/ Customer Information. Point to the title bar of the Customer Information window. Look at the Record Status dialog and make sure it is listing CustomerInformation. If so, press Ctrl+Alt. Two things happen: The Capturing Properties dialog appears momentarily
Then the Verify Window appears over your application
98
Web application
The Window field in the top-left corner of the Verify Window displays the name of the object to which you were pointing. If the name in the Window field is incorrect, press Cancel to close the dialog and return to the application and try again. For information about the Verify Window, see the online Help. 2 Select the object to verify (Web): Click Uncheck All. This clears all check boxes in the Windows to Verify area. Click HtmlText WelcomeText.
99
(client/server): Click Uncheck All. This clears all check boxes in the Windows to Verify area. Click ChildWin CustomerInformation. 3 Select the property to verify (Web): In the Properties to Verify area click Text. Unselect any other properties selected. (client/server): In the Properties to Verify area click Caption. Unselect any other properties selected. 4 5 Close the Verify Window Click OK. SilkTest re-displays the Record Status dialog. Close the Record Status dialog Click Done. SilkTest re-displays the Record Testcase dialog, with your actions translated into 4Test statements.
Web application
100
5 CREATING TESTCASES Linking Scripts and Testcases to a Testplan
Paste testcase into script Click Paste to Editor. The 4Test statements are pasted into the script file and the Record Testcase dialog closes.
Save changes to the script file Click the script file to make it active. Click File/Save. (Web): Save the file as webtut.t. Save it in the <SilkTest installation directory>\Exercise. Click Save. (client/server): Save the file as cstut.t. Save it in the <GMO installation directory>\Exercise. Click Save.
Close the script file Click File/Close. Click Yes to add this file in your project.
Linking Scripts and Testcases to a Testplan

The following exercise will show you how to link the testcase, Verify_ Window_Caption, that you created in the previous section to the testplan you created in Chapter 3, Planning a Testing Strategy.
Linking a testcase to a testplan
If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 27. In SilkTest, open the testplan Click File/Open. Tip In the File/Open dialog, you can display all of the SilkTest files in the directory. From the List files of type pull-down menu, choose Silk Files (*.t;*.inc; *.pln). You can also double click the name of the testplan in the Project treeview. (Web): Navigate to webtut.pln. Click Open. (client/server): Navigate to cstut.pln. Click Open.
Select the test description (Web): Click the test description Verify Caption is Correct. This can be found in the group descriptions GUI Test/GMO OnLine. (client/server): Click the test description Verify Caption is Correct. This can be found in the group descriptions Customer Information Window/GUI Tests.
Open the Testplan Detail dialog
101
Still pointing to the test description, click Testplan/Detail. The Testplan Detail dialog opens.
Note Generally scripts are linked to a group description and testcases are linked to a test description. 5 6 Select the Test Execution tab Select the script file Click Scripts to browse for the script that contains the testcase you want to link to your testplan. (Web): Select webtut.t. Click Open. (client/server): Select cstut.t. Click Open. Tip If a script is linked to a group description, the script name is inherited by all test descriptions in that group. 7 Select the testcase Click Testcases, to see a list of testcases in the selected script file. Select the testcase Verify_Window_Caption. Click OK.
Web application
102
Close the Testplan Detail dialog Click OK. Notice that two testplan statements have been added below the test description within the testplan, a script statement and a test statement.
Save the testplan Click the testplan file to make it active. Click File/Save.
103
5 CREATING TESTCASES Recording from a Testplan
Recording from a Testplan

You can record a testcase from a testplan in two ways; While the testplan is being developed or After the testplan has been completed.
There is an advantage to recording from a testplan rather than recording the testcase on its own and then linking it to the testplan. The advantage is, in recording from the testplan editor SilkTest automatically inserts the script and testcase statements into the plan when you have finished recording. In the following exercise you will create a testcase from the test descriptions you created in Chapter 3, Planning a Testing Strategy. 1 In SilkTest, confirm your Runtime Options Click Options/Runtime. (Web): Make sure you are using gmow.inc as your test frame: In the Use Files field, confirm gmow.inc. Click OK. (client/server): Make sure you are using gmoc.inc as your test frame: In the Use Files field, confirm gmoc.inc. Click OK. 2 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 27. Open the testplan If it is not already open, click File/Open. (Web): From the list of files, select webtut.pln and click OK. (client/server): From the list of files, select cstut.pln and click OK. 4 Select a test description (Web): In the testplan, click on the test description Verify Enter GMO OnLine pushbutton is enabled. (client/server): In the testplan, click on the test description Verify Search pushbutton is enabled. 5 6 Open the Record Testcase Script dialog Click Record/Testcase. Select the script file (Web): Select webtut.t. Click Open. (client/server): Select cstut.t. Click Open.
104
SilkTest displays the Record Testcase dialog. 7 Name the testcase (Web): Type the name Verify_Enter_Enabled in the Testcase name text box. (client/server): Type the name Verify_Search_Enabled in the Testcase name text box. 8 Confirm the Application State In the Application state field, confirm the DefaultBaseState is selected from the drop-down list. (Web): The settings in the Record Testcase dialog should now appear as shown in the following figure:
(client/server): The settings in the Record Testcase dialog should now appear as shown in the following figure.
Start recording
105
In the Record Testcase dialog, click Start Recording. SilkTest closes the Record Testcase dialog and displays the Record Status window. 10 (client/server Only) Navigate to the window to be tested Open the Customer Information window, click Order/Customer Information. 11 Open the Verify Window (Web): Point to the background of the GMO OnLine homepage. Look at the Record Status dialog and make sure it is listing GMO. When GMO is listed, press Ctrl+Alt. The Verify Window appears over your application.
(client/server): Point to the title bar of the Customer Information window. Look at the Record Status dialog and make sure it is listing CustomerInformation. When CustomerInformation is listed, press Ctrl+Alt. The Verify Window appears over your application.
106
Because we did not identify a specific object, all the objects on the page are listed in the Windows to Verify area. 12 Uncheck all objects In the Windows to Verify area, click Uncheck All. 13 Select the object to verify In the Windows to Verify list, (Web): Scroll down and select HtmlPushButton EnterGMOOnLine. (client/server): Scroll down and select Pushbutton Search. 14 Select the property to verify In the Properties to Verify list, click Enabled True. Uncheck any other properties. 15 Close the Verify Window Click OK. 16 Close the Record Status dialog Click Done. SilkTest re-displays the Record Testcase dialog, with your actions translated into 4Test statements.
107
Web application
17 Paste recorded actions into the script Click Paste to Editor. The 4Test statements are pasted into the script file and the Record Testcase dialog closes. 18 Save the changes to the script file Click the script file to make it active. Click File/Save. 19 Close the script file Click File/Close. 20 Close the testplan Click File/Close.
108
5 CREATING TESTCASES Exploring the Connections: Testplans, Scripts and Testcases
Exploring the Connections: Testplans, Scripts and Testcases

This section explains the connections between the testplan, the script and the testcases you have created. If you are testing the client/server application, proceed to The Client/Server Application on page 110.
The Web Application

Take a look at the image below.
Testplan file
Test description Testcase statement Script statement
Script file
Note the following in the testplan (webtut.pln): The test description, Verify caption is correct (in blue) begins with a minus sign instead of a bullet, indicating that the test description can be expanded. The testplan contains script and testcase statements (in red) that connect to the testcase you created: The script statement specifies the script file that contains the testcase for verifying the caption. The testcase statement invokes the testcase that performs the test.
Getting Started: A Tutorial 109
5 CREATING TESTCASES Exploring the Connections: Testplans, Scripts and Testcases
Also note that the 4Test script (webtut.t) contains the 4Test statements for all of your interactions with the application when you created the testcase. The next section describes the connections between the testplan, script and testcases that were developed for the client/server application. If you are not testing client/server application please proceed to Examining the Structure of a 4Test Statement on page 111.
The Client/Server Application

Take a look at the image below.
Testplan file
Script statement Test description Testcase statement
Script file
Note the following in the testplan (cstut.pln): The test description (in blue) begins with a minus sign instead of a bullet, indicating that the test description is fully expanded. The testplan contains script and testcase statements (in red) that connect to the testcase you created: The script statement specifies the script that contains the testcase for verifying the caption. The testcase statement invokes the testcase that performs the test.
110
5 CREATING TESTCASES Examining the Structure of a 4Test Statement
Also note that the 4Test script (cstut.t) contains the 4Test statements for all interactions with the application that took place when you created the testcase.
Examining the Structure of a 4Test Statement

The testcases you record contain all of your interactions with the application in 4Test syntax. Each interaction is a complete 4Test statement. In SilkTest, a statement is a method, function call, or 4Test flow-of-control command that is used within a 4Test testcase. To better understand how your actions are translated, take a look at the syntax for a sample testcase.
This Line of 4Test script language testcase Verify_Window_Caption () Tells SilkTest
That the testcase is named

Verify_Window_Caption
GMO.SetActive ()
To make the GMO application active To select the Customer Information menu item under the Order menu in the main window To verify selected properties of the Customer Information window To verify the caption in the Customer Information window
"Customer Information"}
GMO.Order.CustomerInformation.Pick ()
CustomerInformation.VerifyProperties ({...})
" " {...} {"Caption",
CustomerInformation.SetActive ()
To make the Customer Information window active Information window
CustomerInformation.DialogBox1.Close.Click () To close the Customer
111
5 CREATING TESTCASES Understanding How the Recovery System Works
Understanding How the Recovery System Works

The recovery system is a unique, powerful and fully integrated feature of SilkTest. The recovery system ensures that each testcase begins and ends with the application in its intended state. SilkTest refers to this intended application state as the base state.
Base state
An applications base state is the known, stable state that you expect the application to be in before each testcase begins execution, and the state the application can be returned to after each testcase has ended execution. This state may be the state of an application when it is first started. Base states are important because they ensure the integrity of your tests. By guaranteeing that each testcase can start from a stable base state, you can be assured that an error in one testcase does not cause subsequent testcases to fail. When you activate the recovery system for one or more testcases, SilkTest automatically ensures that your application is at its base state during the following three stages: Before a testcase is run During the execution of a testcase If an error occurs, SilkTest does the following: Stops execution of the testcase Transfers control to the recovery system, which restores the application to its base state and logs the error in a results file Resumes script execution by running the next testcase after the failed testcase
After a testcase completes successfully
The recovery system makes sure that the testcase was able to clean up after itself, so that the next testcase is run under valid conditions.
Default base state
SilkTest provides a default base state for applications, which ensures the following conditions are met before recording and executing a testcase: The application is running The application is not minimized The application is the active application No windows other than the applications main window are open
112
Default base state ensures the following for browsers in addition to the items listed above: The browser is ready Constants are set The browser has toolbars, location and status bar displayed
For more information about the recovery system, see the online Help.

In this chapter you learned: How to structure a testcase. How to record a testcase. How to link testcases to a testplan. How to record a testcase from a testplan. How to read a 4Test statement. About the recovery system. Plan Capture
Create
Run
Report
Track
113
114
6
6e rh C t p a
Running Testcases
This chapter introduces Phase IV of the Segue Testing Methodology, Running. Plan Capture
Create
Run
Report
Track
So far you have successfully created a testplan and recorded a testcase. Now you are ready to run (also called execute) testcases that test the GMO application.
In this chapter

Section Page
Options for Running Testcases from a Testplan Running a Single Testcase from a Testplan Running All Testcases in a Testplan Running Marked Tests in a Testplan
115 116 118 118
Options for Running Testcases from a Testplan

When you run a testcase, SilkTest interacts with the application by executing all the actions you specified in the testcase and testing whether all the features of the application performed as expected. The most basic approach to running a testcase is to run it from the script file itself. However, running testcases from the script file only allows you to run a single testcase or all testcases within the script. On the other hand, a SilkTest testplan, allows you to do that plus it allows you to run only those testcases that you have marked for execution.
115
6 RUNNING TESTCASES Running a Single Testcase from a Testplan
The SilkTest testplan lets you mark testcases for execution in two ways: Selecting a testcase in the testplan editor and choosing a marking command, or Performing a mark by query, which marks only testcases that have been assigned certain characteristics called attributes
We have provided completed versions of the testplan that you created in Chapter 3, Planning a Testing Strategy as well as the script file you created in Chapter 5, Creating Testcases. These files are used in the exercises in both this chapter and the following chapter, "Reviewing and Reporting Test Results". (Web): If you are testing the GMO Web application the testplan gmow.pln and the script it uses, gmow.t, can be found in <SilkTest installation directory>\Exercise. (client/server); If you are testing the GMO client/server application the testplan gmoc.pln and the script it uses, gmoc.t, can be found in <GMO installation directory>\Exercise. The gmoc.pln testplan also contains several functionality tests that you can run against the GMO application. Note that these tests are commented out; you can run and review them at your convenience.
Running a Single Testcase from a Testplan

The following exercise shows you how to run a single testcase from within a testplan that contains multiple testcases. 1 In SilkTest, confirm your Runtime Options Click Options/Runtime. (Web): Make sure you are using gmow.inc as your test frame; In the Use Files field, confirm gmow.inc. Click OK. (client/server): Make sure you are using gmoc.inc as your test frame; In the Use Files field, confirm gmoc.inc. Click OK. 2 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28.
116
6 RUNNING TESTCASES Running a Single Testcase from a Testplan
Open the plan file (Web): On the Files tab, expand the Plan folder and double click gmow.pln. (client/server): On the Files tab, expand the Plan folder and double click gmoc.pln.
Select testcase description Note You may need to expand the group and test descriptions. In the testplan, select the testcase description by clicking to the left of Verify caption is correct so that the entire line is highlighted.
Execute the testcase Click Run/Testcase or click the Run Testcase button on the Basic Workflow bar. SilkTest displays the Run Testcase dialog with Verify_Window_Caption selected. Click Run.
Warning Do not click mouse buttons or press keys while the testplan runs. These actions, however unintentional, will conflict with the mouse clicks and button presses being executed by the running testcase. When SilkTest finishes executing the testcase, it displays the results of the execution in a results (.res) file in the Results window. 6 Close the results file Click File/Close.
117
6 RUNNING TESTCASES Running All Testcases in a Testplan
Running All Testcases in a Testplan

When you run a testplan, SilkTest executes all of the testcases in the testplan. The following explains how to run all testcases contained in a testplan. 1 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project). If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28. In SilkTest, open the testplan (Web): If gmow.pln is not already open, expand the Plan folder on the Files tab and double click gmow.pln. (client/server): If gmoc.pln is not already open, expand the Plan folder on the Files tab and double click gmoc.pln. 3 Run all testcases Click Run/Run All Tests. When SilkTest finishes running the testcases in the testplan, it displays the results of the execution in a results (.res) file in the Results window.
Running Marked Tests in a Testplan

There may be times when you do not want to run all the testcases in the testplan but you do want to run more than one. SilkTest makes this possible by letting you mark multiple testcases for execution from within a testplan. Marks are temporary denotations that allow you to run selected testcases in a testplan. Marks last only for the duration of the current work session and you can remove them at any time during that work session. You mark testcases in a testplan by using one of the marking commands on the Testplan menu: Mark Mark All Mark by Query Mark by Named Query
The following exercises show you how to select specific testcases to run using the Mark command or the Mark by Query command.
118
6 RUNNING TESTCASES Running Marked Tests in a Testplan Using the Mark command
If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28. In SilkTest, open the testplan (Web): If gmow.pln is not already open, expand the Plan folder on the Files tab and double click gmow.pln. (client/server): If gmoc.pln is not already open, expand the Plan folder on the Files tab and double click gmoc.pln.
Select a testcase (Web): Click anywhere in the test description Verify all text fields are empty. (client/server): Click anywhere in the test description Verify Update pushbutton is disabled.
Mark the test Click Testplan/Mark. The black stripe in the left margin indicates the test is marked.
Run the marked test Click Run/Run Marked Tests. SilkTest runs the marked test and generates a results file.
6
Using the Mark by Query command
Leave the results and testplan files open
If you have defined and associated attributes with your testplan, you can run testcases based on those attributes. This exercise shows you how to run testcases based on these attributes. 1 In SilkTest, open the Mark by Query dialog Make the testplan the active window. Click Testplan/Mark by Query. SilkTest displays the Mark by Query dialog, as shown in the following figure:
119
6 RUNNING TESTCASES Running Marked Tests in a Testplan
Select the test attribute Click the Test Attributes tab, click in the Developer field, and using the scroll bar, select Tom from the Developer list:
Unmark all
Keep existing marked tests We want to keep the test we marked in the previous exercise therefore clear the Unmark All Before Query check box.
Mark the tests by query Click Mark. SilkTest marks the testcase that has been associated with the Developer Tom.
Marked by query Marked
Note that there are now two marked testcases in the testplan. 5 Run marked tests Click Run/Run Marked Tests. SilkTest runs the marked tests and generates a results file.
120
6 7
Close the results file Click File/Close. Close the testplan Click File/Close.

In this chapter you learned: About the different options available for running testcases from testplans. How to run a single testcase. How to run all testcases. How to mark and run marked testcases, including testcases marked by query. Plan Capture
Create
Run
Report
Track
121
122
7
7e rh C t p a
Reviewing and Reporting Test Results

This chapter introduces Phase V of the Segue Testing Methodology, Reporting. Plan Capture
Create
Run
Report
Track
After you run a testcase, script, suite or testplan, SilkTest automatically creates a results file. From examining the statistics in the results file, you can determine how many tests passed and how many failed. This chapter will show you:
In this chapter
How to interpret the information contained in the results file What you can do with the information in the results file The reports that SilkTest can produce from the information in the results file

Section Page
The Results File Introducing an Error in a Testcase Viewing an Error in a Testcase Using the Difference Viewer Generating Pass/Fail Reports
124 125 127 129 131
123
7 REVIEWING AND REPORTING TEST RESULTS The Results File
The Results File

A results file provides information about the execution of the testcase, script, suite or testplan. By default, the results file has the same name as the executed script, suite, or testplan, from which the testcase(s) was executed, but with a .res extension. To change the default name and directory of the results file, edit the Runtime Options dialog. For more information, see the online Help. The following is an example of a results file. This file was generated for the testplan gmoc.t:
Script Results summary
Summary of results
By default, the results file displays an overall summary at the top of the file indicating the following: The name of the script, suite or testplan and the overall success or failure of the script or testplan The machine on which the tests ran The starting time and the total elapsed time The number and percentage of testcases that passed and failed The total number of errors and warnings Tip To hide the overall summary, click on the summary and click Result/Hide Summary. (You can change the default behavior in the Runtime Options. For more information, see the online Help.)
What color indicates
In Chapter 3, Planning a Testing Strategy, you learned that color plays an important role in identifying the parts of a testplan. Color is also used in results files to identify various components.
Color Description
Blue Red Gray

124 Getting Started: A Tutorial
Test description; also test output and informational messages from the recovery system Test error Testcase was not executed
7 REVIEWING AND REPORTING TEST RESULTS Introducing an Error in a Testcase
Color
Description
Green Black
Test summary Other
Introducing an Error in a Testcase

When you ran the testplan, gmow.pln for the Web application and gmoc.pln for the client/server application in the last chapter they did not encounter any errors. In this next exercise, you will introduce an error into a testcase that causes the property verification statement to fail. This will allow you to see how the results file handles errors in an application. 1 If the GMO project that you created in Chapter 2 is not open, please open it (File/Open Project.) If you have not created this project yet, please see Chapter 2, Preparing to Use this Tutorial on page 28. In SilkTest, open the script file (Web): On the Files tab, expand the Script folder and double click gmow.t. (client/server): On the Files tab, expand the Script folder and double click gmoc.t. 3 If necessary, expand the testcase In the testplan editor, click the plus icon [+] to expand the testcase Verify_Window_Caption.
125
7 REVIEWING AND REPORTING TEST RESULTS Introducing an Error in a Testcase
If necessary, expand the section (Web): Expand the section named GMO.VerifyProperties.
(client/server): Expand the section named CustomerInformation.VerifyProperties.
Modify the identifier (Web): Find the line that begins {$Caption, and change the text from Welcome to Green Mountain Outpost to Welcome to GMO. This change will cause the testcase to fail when you run it because the verification statement attempts to verify that the caption for the window is Welcome to GMO when in fact it is Welcome to Green Mountain Outpost. (client/server): In the Verify_Window_Caption testcase find the line that begins {Caption, and change the text from Customer Information to Customer Service. This change will cause the testcase to fail when you run it because the verification statement attempts to verify that the caption for the window is Customer Service when in fact it is Customer Information.
Save the changes to the script Click File/Save. You are now going to run the modified testcase from the testplan.
126
7 REVIEWING AND REPORTING TEST RESULTS Viewing an Error in a Testcase
Open the testplan (Web): On the Files tab, expand the Plan folder and double click gmow.pln. (client/server): On the Files tab, expand the Plan folder and double click gmoc.pln.
Unmark the testplan Click Testplan/Unmark All, if necessary. This time you will run all the tests in the testplan.
Run all tests Click Run/Run All Tests.
SilkTest briefly displays the Program Status window, indicating that all the tests in the testplan are running. When the testplan completes, the .res file becomes the active window. 10 Leave the results file open
Viewing an Error in a Testcase

When an error occurs in a testcase, SilkTest indicates that a testcase failed by placing a red plus sign next to it in the results file. In addition to flagging an error in the testcase, the red plus sign also indicates that more information is available if you expand the block. This is what your results file should look like:
127
7 REVIEWING AND REPORTING TEST RESULTS Viewing an Error in a Testcase
To obtain more information about the failed testcase: 1 Expand the error line Click the red plus sign [+] indicating an error. SilkTest expands the error line and changes the plus sign to a minus sign [-], indicating that the block is expanded.
Web application What failed Detected by Where Client/server application What failed Detected by Where
The error line discloses the following information: The property verification failed. The method that detected the error 2 (Web): GMO.VerifyProperties (client/server): CustomerInformation.VerifyProperties (Web): Line 18 in gmow.t script file. (client/server): Line 16 in gmoc.t script file.
Where in the script file the error occurred
Connect to the line in the script file that detected the error All of the following actions will bring you to the point in the script file that contains the error: Double-click in the margin to the left of the error message. Note the pointer changes from an I-beam to an arrow. Click the error message and press the Enter key. Click the error message and click Results/Goto Source.
The associated script file becomes the active window and the insertion point is placed at the beginning of the verification that contains the error.
128
7 REVIEWING AND REPORTING TEST RESULTS Using the Difference Viewer
Using the Difference Viewer

The Difference Viewer is a dual-paned, display-only window that lists the expected values in the left pane and the actual values in the right pane. The Difference Viewer provides more detailed information about the error that caused the testcase to fail. To invoke the Difference Viewer, click the box icon next to the error in the results file. Note If you were testing a bitmap image, clicking the box icon would invoke the Bitmap Tool, which you use to compare two (or more) bitmaps and identify the differences between them. For more information about the Bitmap Tool, see the Users Guide or online Help. 1 2 Make the results file active Click the Results window. Open the Difference Viewer Click the box icon preceding the error message. SilkTest opens the Difference Viewer, as shown in the following:
Web application
(Web): As you can see, the Difference Viewer shows that the Verify_Window_Caption testcase expected a value of Welcome to GMO, but the actual value verified at runtime was Welcome to Green Mountain Outpost.
(client/server): As you can see, the Difference Viewer shows that the Verify_Window_Caption testcase expected a value of Customer Service, but the actual value verified at runtime was Customer Information.
129
7 REVIEWING AND REPORTING TEST RESULTS Using the Difference Viewer
The preceding exercise is a simple example to show you how the Difference Viewer works. Because of the simplicity of the error, the Difference Viewer does not provide much more information about the error than you previously knew by looking at the error message in the results file. However, for complicated or long comparisons, you will often need to use the Difference Viewer to pinpoint each of the pieces of data in the verification that failed. 3 Leave the Difference Viewer open In the next exercise you will use the Difference Viewer to update the expected values in your test script.
Updating expected values
In the previous section, you used the Difference Viewer to obtain detailed information about an error that caused a testcase to fail. The testcase failed because the actual value did not match with the expected value. To have your testcase run cleanly the next time, use the Update Expected Value command to modify the expected value in your script. To update the expected value in your script: 1 2 In SilkTest, click the Difference Viewer window to make it the active window Update the expected value Click Results/Update Expected Value. The script file becomes the active window. Note that the caption has been replaced with the actual value. Tip You can also update an expected value from the results file. Select the line containing the error and click Results/Update Expected Value. 3 Close the Difference Viewer Make the Difference Viewer active, click File/Close. Do not close the results file. For more information about results files, see the online Help.
130
7 REVIEWING AND REPORTING TEST RESULTS Generating Pass/Fail Reports
Generating Pass/Fail Reports

A Pass/Fail report lists the number and percentage of tests that have passed during a given execution of the testplan. The report can be subtotaled by an attribute, for example, the Developer. This section describes how to generate a Pass/Fail report for a sample testplan. To generate a Pass/Fail report: 1 In SilkTest, make the results file the active window (Web): Confirm that gmow.res is active. (client/server): Confirm that gmoc.res is active. 2 Open the Pass/Fail Report dialog Click Results/Pass/Fail Report.
Select the attribute on which you want to report From the Subtotal by Attribute drop-down list, select Developer, the default.
Generate the report Click Generate. SilkTest generates the report based on the Developer attribute and displays the results, as shown in the figures below.
131
Web application
After you have generated a Pass/Fail report, you can choose to: Print the report Chart the report Export the report to a comma-delimited ASCII file
For more information about these options, see the Users Guide. 5 6 7 8 Close Pass/Fail Report dialog Click Close. Close the results file Click Close. Close the script, .t file Click File/Close. Click Yes to save the changes. Close the testplan Click File/Close.
132

In this chapter you learned: How to read the results file. How to introduce an error into a testcase. How to jump from the results file to the testcase in the script file in the event of an error. How to use the Difference Viewer. How to generate Pass/Fail reports. Plan Capture
Create
Run
Report
Track
For information about the last phase of the Segue Testing Methodology, Tracking, contact support@bmc.com.
133
134
8
8e rh C t p a
Testing Databases
Do you test distributed applications that access a database, or do you test database software directly? Are you familiar with SQL? If so, you might want to learn about DBTester. Note If you would like to complete the following exercises and you have not already done so, you will need to install the GMO client/ server application. For installation instructions, please see Installing the GMO application on page 39 in Chapter 2, Preparing to Use this Tutorial.
In this chapter

Section Page
Overview of DBTester Running the Sample Testcase Restoring the Sample Database
135 137 143
Overview of DBTester
What is DBTester?
DBTester provides direct access, using SQL, from a SilkTest script to a database supported by ODBC drivers. DBTester comprises six functions that allow you to read and write database records without using the applications user interface. Thus, you can test an applications database or database software without using the application itself.
135
8 TESTING DATABASES Overview of DBTester DBTester functions
The set of DBTester functions is summarized here. More detailed descriptions and examples are included in the online Help.
Function DB_Connect Description
Opens a database connection and returns a handle to that system. SQL statements can be submitted to the database. Closes the connection between SilkTest and the database and releases all resources. Sends an SQL statement to the database for execution. Retrieves the next row from the database. Retrieves the previous row from the database. Removes the result of the SQL statement and releases the associated system resource (statement handle).
DB_Disconnect
DB_ExecuteSql DB_FetchNext DB_ FetchPrevious DB_FinishSql
Using the functions in a testcase
The sample file dbtester.t shows how to use the DBTester functions together in a simple testcase that prints a customer list from the client/server version of GMO. (You can find this file in <GMO installation directory>/Exercise. Do not use the dbtester.t file in the <SilkTest installation directory>/ Exercise.)
testcase DBTester () appstate none //Use the DBTester functions to access the GMO database //Print GMOs customer list STRING custnum, lname, fname HDATABASE hdbc HSQL hstmnt // Connect to the GMO database, green2.mdb hdbc = DB_Connect ("dsn=gmovb") // Retrieve everything from the customer table sorted by // last name hstmnt = DB_ExecuteSql (hdbc, "SELECT * FROM cidb ORDER BY last_name") // Process the retrieved data and print customer names
136
8 TESTING DATABASES Running the Sample Testcase print ("GMO Customer List:") print () while (DB_FetchNext (hstmnt, custnum, fname, lname)) print ("{lname}, {fname}") // Release resources DB_FinishSql (hstmnt) // Disconnect from the GMO database DB_Disconnect (hdbc)
Running the Sample Testcase

Prerequisite for running the script
This part of the tutorial has you test the client/server GMO applications Microsoft Access database. For GMO to use the Access database you need to: Install the ODBC driver for Microsoft Access, if it is not already installed. This driver provides ODBC access to Microsoft Access data. Set up the ODBC driver for Microsoft Access to use the GMO Access database as its data source.
If you have questions about the installation and set up of the ODBC driver, see your companys database administrator.
Installing the ODBC driver
The ODBC driver for Microsoft Access is part of the Microsoft Data Access Components (MDAC). You can download MDAC free from Microsofts Web site. 1 Go to Microsofts Web site From your browser, enter the following URL: http://www.microsoft.com/ 2 Find the download and install instructions From the Microsoft home page perform a search for MDAC. If you are unsure of what version to download, see your companys database administrator. 3 Download MDAC to your computer Follow the downloading instructions to copy the MDAC executable to your computer. 4 Install the driver Follow the setup instructions to install and set up the ODBC driver for Microsoft Access.
137
8 TESTING DATABASES Running the Sample Testcase Setting up the ODBC driver
After you install the ODBC driver, you will need to set up the Microsoft Access database as the data source for the GMO application: 1 2 Exit the GMO application, if it is running Click File/Exit. Open the Database Administrator dialog From the Windows Start menu, click Settings/Control Panel/Data Sources (ODBC). From the Windows2000 Start menu, click Settings/Control Panel/ Administrative Tools/Data Sources (ODBC). 3 4 5 6 Add a User DSN Click the User DSN tab. Click Add. Select a driver Select Microsoft Access Driver (*.mdb). Click Finish. Name the data source Enter Green2 as the Data Source Name. Click Select. Select the database Browse to the GMO installation directory. (The default directory location is C:\Program Files\Segue\Gmo.) Select green2.mdb. Click OK. 7 8 9 Close the ODBC Microsoft Access Setup dialog Click OK. Close the ODBC Data Source Administrator Click OK. Start the GMO application. From the start menu choose Programs/Green Mountain Outpost/ GMO. Note The GMO installation provides not only the Access database file, green2.mdb, but also a back-up copy of that file, called green2base.mdb. The copy allows you to experiment with the database and still have a copy of the original information to which you can restore the database.
138
8 TESTING DATABASES Running the Sample Testcase Running the testcase
If you have installed the Microsoft Access driver, you can run the testcase. 1 In SilkTest, open the script file Click File/Open. Navigate to the <GMO installation directory>/ Exercise. (The default directory location is c:\Program Files\Segue\Gmo. Do not use the dbtester.t file in the <SilkTest installation directory>/ Exercise.) Select the dbtester.t. Click Open. 2 Run the tests Click Run/Run. Upon completion of the execution the results file, dbtester.res, appears. 3 Review the results Click the plus icon preceding Testcase DBTester - Passed. You should see the following alphabetical listing of GMO customers:
GMO Customer List:
ARUNDEL, CLAUDE BUCCIGRAS, CATHERINE COHEN, ROBIN CORELLI, ARCANGELO DURNFELD, PATRICIA GOLDSTEIN, MARTHA HARTMANN, JUDY JOHNSON, JAMES JONES, RONALD LEYDON, THOMAS MURPHY, SONIA PERKINS, BOB ROBERTS, RANDY ROBERTSON, GUNNAR
139
8 TESTING DATABASES Running the Sample Testcase
The GMO database customer table The GMO database, green2.mdb, stores customer information in the cidb table. The tables columns, which take string values, are as follows:
A look at the testcase
customer_number first_name last_name address_1 address_2 city state zip_code phone_number
This simple testcase prints the first and last name of each GMO customer.
140
8 TESTING DATABASES Running the Sample Testcase
The following table lists and describes the functions that were performed.
Function DB_Connect Description
Opens a connection to the GMO database and returns a database handle, stored in the 4Test variable hdbc. Note that you must pass in a connection string that specifies the data source name you named on the User DSN tab of the ODBC Data Source Administrator, in this case, gmovb. Submits the database handle, as returned by the DB_ Connect function, and a string specifying a SQL statement. Here a SELECT statement retrieves all customer records from the cidb table and places them in alphabetical order by last name (last_name). The function returns a handle to the executed SELECT statement. Must be used after DB_ExecuteSQL to retrieve the next (or previous) row of results of the SQL statement. The first argument is the handle to the executed SQL statement. Following the handle is a list of 4Test output variables representing the table columns in order. DB_FetchNext fills the output variables starting with the first column and continuing in order through the row until the function runs out of variables. For example, custnum, the first output variable, holds the row value of the first column (customer_number); the second variable, fname, holds the row value of the second column (first_name), and so on. The point is that values cannot be skipped; even though were interested in only the second and third values (last and first names), the testcase must retrieve the first value too. Note that the output variables custnum, lname and fname must be declared as strings, the same type as the table columns. (Alternately, output can be specified as a single list variable or even a record variable, which may or may not have fields for all the columns.) The DB_FetchNext function terminates (returns FALSE) when there are no more rows to retrieve.
DB_ExecuteSql
DB_FetchNext (or DB_ FetchPrevious)
141
8 TESTING DATABASES Switching from the Access database to the text database
Function DB_FinishSql and DB_ Disconnect
Description
The DB_FinishSQL function removes the results of the SELECT statement and releases the system resource, that is, the specified statement handle, hstmnt. Note that DB_FinishSql is not strictly necessary in this example, because the DB_ Disconnect function, which releases all statements for the connection, follows immediately.
Switching from the Access database to the text database

Even though you have installed the ODBC driver and used the Access database with the GMO application, you can switch back to using the text database. 1 2 Exit the GMO application, if it is running Click File/Exit. Open the Database Administrator dialog From the Windows Start menu, click Settings/Control Panel/Data Sources (ODBC). 3 4 5 6 Remove a DSN Click the User DSN tab. Select Green2. Click Remove. Confirm the removal On the Confirmation dialog, click Yes. Close the ODBC Data Source Administrator dialog Click OK. Start the GMO application The GMO application now uses the text database.
142
8 TESTING DATABASES Restoring the Sample Database
Restoring the Sample Database

The GMO installation provides not only a Microsoft Access database file, green2.mdb, but also a back-up copy of that file, called green2-base.mdb. The text database file, green2.txt, also has a back-up copy, called green2.base.txt. These copies allow you to experiment with the database and still have a copy of the original information to restore. 1 Navigate to the GMO installation directory Using the Windows Explorer navigate to the <GMO installation directory> (The default directory location is C:\Program Files\Segue\Gmo). 2 Delete the file for the database that you want to restore 3 If you were using the text database (the default) delete green2.txt. If you specified that GMO should use the Access database, delete green2.mdb. If you were using the text database, right-click green2-base.txt. Select Copy. With the <GMO installation directory> still open in the Explorer, right-click and select Paste. A copy of the file is placed in the GMO directory. If you were using the Access database, right-click green2base.mdb. Select Copy. With the <GMO installation directory> still open in the Explorer, right-click and select Paste. A copy of the file is placed in the GMO directory. If you were using the text database (the default), right-click copy of green2-base.txt, select Rename. Rename the file green2.txt. If you were using the Access database, right-click copy of green2base.mdb, select Rename. Rename the file green2.mdb.
Create a copy of the back-up copy of the database
Rename the copy of the back-up database
143
8 TESTING DATABASES Restoring the Sample Database
144
Notes
*59925* *59925* *59925* *59925*

*59925*

Silktest Tutorial

Uploaded by

Copyright:

Available Formats

Silktest Tutorial

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Silktest Tutorial

Uploaded by

Copyright:

Available Formats

silktest

software quality optimization

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC Software

Preparing to Use this Tutorial

Planning a Testing Strategy

Capturing Your Application

Getting Started: A Tutorial

Understanding How the Recovery System Works 112

Reviewing and Reporting Test Results

Getting Started: A Tutorial

The Benefits of Automated Testing

Getting Started: A Tutorial

1 INTRODUCTION The Benefits of Automated Testing

Other types of tests

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics

Understanding SilkTest Basics

Application Under Test

The SilkTest Host

The SilkTest Agent

How SilkTest records user actions

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics

You select a radio button from a group Select

Basic object-oriented concepts

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics Objects

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics

The following table provides additional examples of properties:

Getting Started: A Tutorial

1 INTRODUCTION Understanding SilkTest Basics

The following table provides additional examples of methods:

The built-in recovery system

Getting Started: A Tutorial

1 INTRODUCTION SilkTest Features

Getting Started: A Tutorial

1 INTRODUCTION SilkTest Features

Getting Started: A Tutorial

1 INTRODUCTION Understanding the Segue Testing Methodology

Understanding the Segue Testing Methodology

Plan Capture Create

Run Report Track

A summary of each phase of the Segue Testing Methodology is provided below.

Getting Started: A Tutorial

1 INTRODUCTION Understanding the Segue Testing Methodology Phase I: Plan

Getting Started: A Tutorial

1 INTRODUCTION Understanding the Segue Testing Methodology Phase III: Create

Phase IV: Run

Phase VI: Track

Getting Started: A Tutorial

1 INTRODUCTION SilkTest File Types

SilkTest File Types