Software Testing Tools and Techniques

Testing Practices

2007-11-18T23:31:00.000-08:00

One should make testing a practice so that the deliverable quality is ensured after running succesful tests and removing the bugs.

According to Martin Fowler, "Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead." At first you will find that you have to create a new fixtures all the time, and testing will seem to slow you down a little. Soon, however, you will begin reusing your library of fixtures and new tests will usually be as simple as adding a method to an existing TestCase subclass.
You can always write more tests. However, you will quickly find that only a fraction of the tests you can imagine are actually useful. What you want is to write tests that fail even though you think they should work, or tests that succeed even though you think they should fail. Another way to think of it is in cost/benefit terms. You want to write tests that will pay you back with information.

Here are a couple of the times that you will receive a reasonable return on your testing investment:

During Development:
When you need to add new functionality to the system, write the tests first. Then, you will be done developing when the test runs.
During Debugging:
When someone discovers a defect in your code, first write a test that will succeed if the code is working. Then debug until the test succeeds.
One word of caution about your tests. Once you get them running, make sure they stay running. There is a huge difference between having your suite running and having it broken. Ideally, you would run every test in your suite every time you change a method. Practically, your suite will soon grow too large to run all the time. Try to optimize your setup code so you can run all the tests. Or, at the very least, create special suites that contain all the tests that might possibly be affected by your current development. Then, run the suite every time you compile. And make sure you run every test at least once a day: overnight, during lunch, during one of those long meetings.

Web Test tools

2007-09-30T23:26:00.000-07:00

Thousands of software testing tools and technologies are available in the todays market, thus helps organizations to make their software systems more reliable, enhanced and efficient.
Some important load and performance test tools with respect to the web applications are listed in this article. Their core features are also included to get familiar with their capabilities.

Load and performance test tools

Curl-Loader:
This tool is an open source tool written in ‘C’. It is useful to test the load and behavior of large number of Ftp/Ftps and Http/Https clients, each with its own source IP-address. Curl-Loader uses the real c-written client protocol stacks like HTTP and FTP stacks of libcurl and TSL/SSL of openssl. Activities for each virtual client is logged, all the logged data includes the following information: resolving, connection establishment, sending of requests, receiving responses, headers and data received/sent, errors from network, TLS/SSL and application (HTTP, FTP) level events and errors.

OpNet LoadScaler:
It is a load test tool presented by OpNet Technologies. It performed some useful functions like Create tests without programming; generate loads against web applications, and other services including Web Services, FTP, and Email. Record end-user browser activity in the OPNET TestCreatorTM authoring environment to automatically generate test scripts in industry-standard JavaScript. Modify, extend and debug tests with the included JavaScript editor. Alternatively, drag and drop icons onto the test script tree. No knowledge of a scripting language is required to customize test scripts.

Stress Tester:
It is a load and performance testing tool for web applications. Advanced user journey modeling, scalable load, system resources monitors and results analysis. No scripting required. Suitable for any Web, JMS, IP or SQL Application. OS independent.

Proxy Sniffer:
It is a stress and load testing tool having some nice features.
. HTTP/S Web Session Recorder that can be used with any web browser.
. Recordings can then be used to automatically create optimized Java-based load test programs.
. Automatic protection from "false positive" results by examining actual web page content.
. Detailed Error Analysis using saved error snapshots and real-time statistics.

Testing master:
Testing master is a strong load testing tool which has the following characteristics.
. IP spoofing
. Multiple simultaneous test cases
. Website testing features for sites with dynamic content and secure HTTPS pages

NeoLoad:
It is a web load testing tool with user friendly graphical interface and can design complex cases to handle real world applications. It has the following list of features:
. Data replacement
. Data extraction and SOAP support
. System monitoring (Windows, Linux, IIS, Apache, Web Logic, Web sphere...)
. SSL recording
. PDF/HTML/Word reporting
. IP spoofing
. It is multi platform and can run on Windows, Linux, and Solaris

QTest:
This tool is used for web load testing, it has the following characteristics
. Cookies are managed natively
. Shorten the script modeling stage
. HTML and XML parser
. Option of developing custom monitors using supplied APIs
. Allowing display and retrieval of any element from a HTML page or an XML flux in test scripts

LoadDriver:
A very strong testing tool equipped with some modern day technologies. It has the following capabilities:
. Rather than simulating the browsers tt directly drives multiple instances of MSIE
. It supports browser side scripts along with HTTP 1.0/1.1, HTTPS, cookies, cache, and Windows authentication
. Data can be taken from text files or custom ODBC data source and passed to the tests, for individual userID, password, page to start, think times, data to enter, links to click, cache, initial cache state

Site Tester1:
It is a load testing tool which require JDK1.2 or higher to run. Its functions includes HTTP1.0/1.1 compatible requests, POST/GET methods, cookies, running in multi-threaded or single-threaded mode, definition of requests, jobs, procedures and tests, keeps and reads XML formatted files for test definitions and test logs, generates various reports in HTML format

Microsoft WCAT load test tool:
A very efficient tool from Microsoft Corporation which is responsible for the load testing of Internet Information services (IIS) servers.

WebPerformance Load Tester:
It is a load tester having some attractive features listed below:
. It supports all browsers and web servers.
. Records and allows viewing of exact bytes flowing between browser and server
. No scripting required.
. Modem simulation allows each virtual user to be bandwidth limited.
. It can automatically handle variations in session-specific items such as cookies, usernames, passwords, IP addresses, and any other parameter to simulate multiple virtual users
. It can be used on Windows, Linux, UNIX and Solaris platforms.

Selecting an Object Order Preference

2007-07-25T03:35:00.000-07:00

Robot uses a variety of object recognition methods in order to uniquely identify objects in the application-under-test that are acted on during recording sessions. For example, Robot can identify a check box in the application-under-test by its object name, associated label or text string, index value, or ID value.

These recognition methods are saved as arguments in script commands so that Robot can correctly identify the same objects during playback.

Robot has two predefined preferences for the recognition method order for each standard object type. While recording an action on an object, Robot tries each method within the selected preference in sequence until it finds a method that uniquely identifies the object.

The following table describes the two predefined preferences.

Object Order Preference	Recognition Method Order	Comments
<Default>	Object Name Label and/or Text Index ID	Index comes before ID. In some environments, such as PowerBuilder and Visual Basic, the ID changes each time the developer creates an executable file and is therefore not a good recognition method.
C++ Recognition Order	Object Name Label and/or Text ID	Index ID comes before index. In some environments, suchas C++, the ID does not usually change and is therefore a good recognition method.

The object order preference is the initial setting. If you plan to test C++ applications, change the preference to C++ Recognition Order.

Note

Settings in the Object Recognition Order tab of the GUI Record Options dialog box do not affect HTML recording. When recording against HTML, Robot always uses HTMLID, if available, and then name, text, and index recognition and ignores any settings in the Object Recognition Order tab.

To change the object order preference:

Open the GUI Record Options dialog box.
Click the Object Recognition Order tab.
Select a preference in the Object order preference list.
Click OK or change other options.

Note

The object order preference is specific to each user. For example, you can record with C++ preferences while another user is recording with preferences at the same time.

Setting GUI Recording Options

2007-07-25T00:41:00.000-07:00

GUI recording options provide instructions to Robot about how to record and generate GUI scripts. You can set these options either before you begin recording or early in the recording process.

To set the GUI recording options:

Open the GUI Record Options dialog box by doing one of the following:

Before you start recording, click Tools > GUI Record Options.
Start recording by clicking the Record GUI Script button on the toolbar. In the Record GUI dialog box, click Options.

Set the options on each tab.
Click OK.

Naming Scripts Automatically

Robot can assist you in assigning names to scripts with its script autonaming feature. Autonaming inserts your specified characters into the Name box of a new script and appends a consecutive number to the prefix.

This is a useful feature if you are recording a series of related scripts and want to identify their relationship through the prefix in their names. For example, if you are testing the menus in a Visual Basic application, you might want to have every script name start with VBMenu.

To turn on script autonaming:

Open the GUI Record Options dialog box.
In the General tab, type a prefix in the Prefix box. Clear the box if you do not want a prefix. If the box is cleared, you need to type a name each time you record a new script.
Click OK or change other options.

The next time you record a new script, the prefix and a number appear in the Name box of the Record GUI dialog box.

For example the autonaming prefix is Test. When you record a new script, Test7 appears in the Name box because six other scripts begin with Test.

If you change the script autonaming prefix by clicking Options in the Record GUI dialog box, changing the prefix, and then clicking OK, the name in the Name box changes immediately.

Controlling How Robot Responds to Unknown Objects

During recording, Robot recognizes all standard Windows GUI objects that you click, such as check boxes and list boxes. Each of these objects is associated with one of a fixed list of object types. The association of an object with an object type is generally based on the class name of the window associated with the object.

Robot also recognizes many custom objects defined by IDEs that Robot supports, such as Visual Basic, Oracle Forms, Java, and HTML. For example, if you click a Visual Basic check box, Robot recognizes it as a standard Windows check box. This mapping is based on the object’s Visual Basic assigned class name of ThunderCheckBox.

These built-in object mappings are delivered with Robot and are available to all users no matter which project they are using. During recording, you might click an object that Robot does not recognize. In this case, Robot’s behavior is controlled by a recording option that you set. You can have Robot do either of the following:

Open the Define Object dialog box, so that you can map the object to a known object type.
Mapping an object to an object type permanently associates the class name of the object’s window with that object type, so that other objects of that type are recognized.
Automatically map unknown objects encountered while recording with the Generic object type. This permanently associates the class name of the unknown object’s window with the Generic object type.

This is a useful setting if you are testing an application that was written in an IDE for which Robot does not have special support and which therefore might contain many unknown objects. When an object is mapped to the Generic object type, Robot can test a basic set of its properties, but it cannot test the special properties associated with a specific object type. Robot also records the object’s x,y coordinates instead of using the more reliable object recognition methods to
identify the object.

These custom object mappings are stored in the project that was active when the mappings were created.

To control how Robot behaves when it encounters an unknown object during recording:

Open the GUI Record Options dialog box.
In the General tab, do one of the following:

Select Define unknown objects as type "Generic" to have Robot automatically associate unknown objects encountered while recording with the Generic object type.
Clear Define unknown objects as type "Generic" to have Robot suspend recording and open the Define Object dialog box if it encounters an unknown object during recording. Use this dialog box to associate the object with an object type.

Click OK or change other options.

Enabling IDE Applications for Testing

2007-07-12T00:05:00.000-07:00

Robot provides specialized support for testing the objects in applications that are created in many integrated development environments (IDEs).

To successfully test the objects in Oracle Forms, HTML, Java, C++, Delphi, and Visual Basic 4.0 applications, you need to enable the applications as follows before you start recording your scripts:

Oracle Forms – Install the Rational Test Enabler for Oracle Forms. Run the Enabler to have it add the Rational Test Object Testing Library and three triggers to the .fmb files of the application.
HTML – While recording or editing a script, use the Start Browser toolbar button to start Internet Explorer or Netscape Navigator from Robot. This loads the Rational ActiveX Test Control, which lets Robot recognize Web-based objects.
Java – Run the Java Enabler to have it scan your hard drive for Java environments such as Web browsers and Sun JDK installations that Robot supports. The Java Enabler only enables those environments that are currently installed.
C/C++ – To test the properties and data of ActiveX controls in your applications, install the Rational ActiveX Test Control. This is a small, nonintrusive custom control that acts as a gateway between Robot and your application. It has no impact on the behavior or performance of your application and is not visible at runtime. Manually add the ActiveX Test Control to each OLE container (Window) in your application.
Visual Basic 4.0 – Install the Rational Test Enabler for Visual Basic. Attach the Enabler to Visual Basic as an add-in. Have the Enabler add the Rational ActiveX Test Control to every form in the application. This is a small, nonintrusive custom control that acts as a gateway between Robot and your application.
Delphi – Install the Rational Object Testing Library for Delphi and the Rational Test Delphi Enabler. Run the Enabler, and then recompile your project to make it Delphi testable.

You can install the Enablers and the ActiveX Test Control from the Rational Software Setup wizard.

Recording GUI Scripts in Rational Robot

2007-06-28T23:51:00.000-07:00

The Recording Process

When you record a GUI script, Robot records:

Your actions as you use the application-under-test. These user actions include keystrokes and mouse clicks that help you navigate through the application.
Verification points that you insert to capture and save information about specific objects. A verification point is a point in a script that you create to confirm the state of an object across builds. During recording, the verification point captures object information and stores it as the baseline. During playback, the verification point recaptures the object information and compares it to the baseline.

The recorded GUI script establishes the baseline of expected behavior for the application-under-test. When new builds of the application become available, you can play back the script to test the builds against the established baseline in a fraction of the time that it would take to perform the testing manually.

The Recording Workflow

Typically, when you record a GUI script, your goal is to:

Record actions that an actual user might perform (for example, clicking a menu command or selecting a check box).
Create verification points to confirm the state of objects across builds of the application-under-test (for example, the properties of an object or the text in an entry field).

Before You Begin Recording

You should plan to use Robot at the earliest stages of the application development and testing process. If any Windows GUI objects such as menus and dialog boxes exist within the initial builds of your application, you can use Robot to record the corresponding verification points.

Consider the following guidelines before you begin recording:

Establish predictable start and end states for your scripts.
Set up your test environment.
Create modular scripts.
Create Shared Projects with UNC.

These guidelines are described in more detail in the following sections.

Establishing Predictable Start and End States for Scripts

By starting and ending the recording at a common point, scripts can be played back in any order, with no script being dependent on where another script ends. For example, you can start and end each script at the Windows desktop or at the main window of the application-under-test.

Setting Up Your Test Environment

Any windows that are open, active, or displayed when you begin recording should be open, active, or displayed when you stop recording. This applies to all applications, including Windows Explorer, e-mail, and so on.

Robot can record the sizes and positions of all open windows when you start recording, based on the recording options settings. During playback, Robot attempts to restore windows to their recorded states and inserts a warning in the log if it cannot find a recorded window.

In general, close any unnecessary applications before you start to record. For stress testing, however, you may want to deliberately increase the load on the test environment by having many applications open.

Creating Modular Scripts

Rather than defining a long sequence of actions in one GUI script, you should define scripts that are short and modular. Keep your scripts focused on a specific area of testing — for example, on one dialog box or on a related set of recurring actions.

When you need more comprehensive testing, modular scripts can easily be called from or copied into other scripts. They can also be grouped into shell scripts, which are top-level, ordered groups of scripts.

The benefits of modular scripts are:

They can be called, copied, or combined into shell scripts.
They can be easily modified or rerecorded if the developers make intentional changes to the application-under-test.
They are easier to debug.

Creating Modular Scripts with UNC

When projects containing GUI or Manual scripts are to be shared, create the project in a shared directory using the Uniform Naming Convention (UNC). UNC paths are required for GUI test scripts and Manual test scripts that are run on Agent computers.

Hosting Robot/Applications on a Terminal Server

2007-06-19T22:25:00.000-07:00

Robot supports the following Terminal Server environments:

Citrix MetaFrame (WIN2K)/Citrix MetaFrame client
Microsoft Terminal Server (WIN2K)/Microsoft Terminal Server client
Windows 2000 Server
Windows Terminal Server (Windows NT4)

The server hosts both the application under test and Robot. Robot runs on the client as a terminal server session. Rational Robot supports GUI script recording and playback on the server or from the client. The TestManager Log Viewer edition can be run from the server or from the client.

Starting Robot and Its Components

Before you start using Robot, you need to have:

Rational Robot installed.
A Rational project.

Logging On

When you log onto Robot or one of its components, you provide your user ID and password, which are assigned by your administrator. You also specify the project to log onto.

To log on:

From Start > Programs > Rational product name, start Rational Robot or one of its components to open the Rational Login dialog box.

Opening Other Rational Products and Components

Once you are logged onto a Robot component, you can start other products and components from either:

Some components also start automatically when you perform certain functions in another component.

Testing Applications with Rational TestFactory

2007-06-13T23:01:00.000-07:00

Rational TestFactory is a component-based testing tool that automatically generates TestFactory scripts according to the application’s navigational structure.

TestFactory is integrated with Robot and its components to provide a full array of tools for team testing under Windows NT 4.0, Windows XP, Windows 2000, and Windows 98.

With TestFactory, you can:

Automatically create and maintain a detailed map of the application-under-test.
Automatically generate both scripts that provide extensive product coverage and scripts that encounter defects, without recording.
Track executed and unexecuted source code and report its detailed findings.
Shorten the product testing cycle by minimizing the time invested in writing navigation code.
Play back Robot scripts in TestFactory to see extended code coverage information and to create regression suites; play back TestFactory scripts in Robot to debug them.

Managing Defects with Rational ClearQuest

Rational ClearQuest is a change-request management tool that tracks and manages defects and change requests throughout the development process. With ClearQuest, you can manage every type of change activity associated with software development, including enhancement requests, defect reports, and documentation modifications.

With Robot and ClearQuest, you can:

Submit defects directly from the TestManager log or SiteCheck.
Modify and track defects and change requests.
Analyze project progress by running queries, charts, and reports.

Collecting Diagnostic Information During Playback

Use the Rational diagnostic tools to perform runtime error checking, profile application performance, and analyze code coverage during playback of a Robot script.

Rational Purify is a comprehensive C/C++ runtime error checking tool that automatically pinpoints runtime errors and memory leaks in all components of an application, including third-party libraries, ensuring that code is reliable.
Rational Quantify is an advanced performance profiler that provides application performance analysis, enabling developers to quickly find, prioritize, and eliminate performance bottlenecks within an application.
Rational PureCoverage is a customizable code coverage analysis tool that provides detailed application analysis and ensures that all code has been exercised, preventing untested code from reaching the end user.

Performance Testing with Rational TestManager

Rational TestManager is a sophisticated tool for automating performance tests on client/server systems. A client/server system includes client applications accessing a database or application server, and browsers accessing a Web server.

Performance testing uses Rational Robot and Rational TestManager. Use Robot to record client/server conversations and store them in scripts. Use TestManager to schedule and play back the scripts. During playback, TestManager can emulate hundreds, even thousands, of users placing heavy loads and stress on your database and Web servers.

Doing performance testing with TestManager, you can:

Find out if your system-under-test performs adequately.
Monitor and analyze the response times that users actually experience under different usage scenarios.
Test the capacity, performance, and stability of your server under real-world user loads.
Discover your server’s break point and how to move beyond it.

Managing Requirements with Rational RequisitePro

Rational RequisitePro is a requirements management tool that helps project teams control the development process. RequisitePro organizes your requirements by linking Microsoft Word to a requirements repository and providing traceability and change management throughout the project lifecycle.

Using RequisitePro, you can:

Customize the requirements database and manage multiple requirement types.
Prioritize, sort, and assign requirements.
Control feature creep and ensure software quality.
Track what changes have been made, by whom, when, and why.
Integrate with other tools, including Rose, ClearCase, Rational Unified Process., and SoDA.

Using Robot with Other Rational Products

2007-06-13T22:49:00.000-07:00

Rational Robot is integrated with many other Rational products and components, including TestManager, TestFactory, ClearQuest, Purify, Quantify, PureCoverage, and RequisitePro. The products and components are available based on what you have installed.

Planning and Managing Tests in TestManager

Rational TestManager is the one place to manage all testing activities – planning, design, implementation, execution, and analysis. TestManager ties testing with the rest of the development effort, joining your testing assets and tools to provide a single point from which to understand the exact state of your project.

Test Manager supports five testing activities:

Plan Test. The activity of test planning is primarily answering the question, "What do I have to test?" When you complete your test planning, the result is a test plan that defines what to test. In TestManager, a test plan can contain test cases. The test cases can be organized based on test case folders.
Design Test. The activity of test designing is primarily answering the question, "How am I going to do a test?" When you complete your test designing, you end up with a test design that helps you understand how you are going to perform the test case. In TestManager, you can design your test cases by indicating the actual steps that need to occur in that test. You also specify the preconditions, postconditions, and acceptance criteria.
Implement Test. The activity of implementing your tests is primarily creating reusable scripts. In TestManager, you can implement your tests by creating manual scripts. You can also implement automated tests by using Rational Robot. You can extend TestManager through APIs so that you can access your own implementation tools from TestManager. Because of this extensibility, you can implement your tests by building scripts in whatever tools are appropriate in your situation and organization.
Execute Tests. The activity of executing your tests is primarily running your scripts to make sure that the system functions correctly. In TestManager, you can run any of the following: (1) an individual script, which runs a single implementation; (2) one or more test cases, which run the implementations of the test cases; (3) a suite, which runs test cases and their implementations across multiple computers and users.
Evaluate Tests. The activity of evaluating tests is determining the quality of the system-under-test. In TestManager, you can evaluate tests by examining the results of test execution in the test log, and by running various reports.

Planning and managing tests is only one part of Rational TestManager. You also use TestManager to view the logs created by Robot.

Managing Intranet and Web Sites with SiteCheck and Robot

2007-06-13T22:19:00.000-07:00

You use Rational SiteCheck to test the structural integrity of your intranet or World Wide Web site. SiteCheck is designed to help you view, track, and maintain your rapidly changing site.

Use SiteCheck to:

Visualize the structure of your Web site and display the relationship between each page and the rest of the site.

Identify and analyze Web pages with active content, such as forms, Java, JavaScript, ActiveX, and Visual Basic Script (VBScript).

Filter information so that you can inspect specific file types and defects, including broken links.

Examine and edit the source code for any Web page, with color-coded text.

Update and repair files using the integrated editor, or configure your favorite HTML editor to perform modifications to HTML files.

Perform comprehensive testing of secure Web sites. SiteCheck provides Secure Socket Layer (SSL) support, proxy server configuration, and support for multiple password realms.

Robot has two verification points for use with Web sites:

Use the Web Site Scan verification point to check the content of your Web site with every revision and ensure that changes have not resulted in defects.

Use the Web Site Compare verification point to capture a baseline of your Web site and compare it to the Web site at another point in time.

The following figures show the types of defects you can scan for using a Web Site verification point and the list of defects displayed in SiteCheck.

Creating Datapools

2007-06-11T02:33:00.000-07:00

A datapool is a source of variable test data that scripts can draw from during playback.

If a script sends data to a server during playback, consider using a datapool as the source of the data. By accessing a datapool, a script transaction that is executed multiple times during playback can send realistic data and even unique data to the server each time. If you do not use a datapool, the same data (the exact data you recorded) is sent each time the transaction is executed.

TestManager is shipped with many commonly used data types, such as cities, states, names, and telephone area codes. In addition, TestManager lets you create your own data types.

When creating a datapool, you specify the kinds of data (called data types) that the script will send — for example, customer names, addresses, and unique order numbers or product names. When you finish defining the datapool, TestManager automatically generates the number of rows of data that you specify.

Analyzing Results in the Log and Comparators

You use TestManager to view the logs that are created when you run scripts and schedules.

Use the log to:

View the results of running a script, including verification point failures, procedural failures, aborts, and any additional playback information. Reviewing the results in the log reveals whether each script and verification point passed or failed.

Use the Comparators to:

Analyze the results of verification points to determine why a script may have failed. Robot includes four Comparators:

- Object Properties Comparator
– Text Comparator
– Grid Comparator
– Image Comparator

When you select the line that contains the failed Object Properties verification point and click View > Verification Point, the Object Properties Comparator opens, as shown in the following figure. In the Comparator, the Baseline column shows the original recording, and the Actual column shows the playback that failed. Compare the two files to determine whether the difference is an intentional change in the application or a defect.

Developing Tests in Robot

2007-06-06T00:50:00.000-07:00

You use Robot to develop two kinds of scripts: GUI scripts for functional testing and sessions for performance testing.

Use Robot to:

Perform full functional testing. Record and play back scripts that navigate through your application and test the state of objects through verification points.
Perform full performance testing. Use Rational Robot and Rational. TestManager together to record and play back sessions that help you determine whether a multiclient system is performing within user-defined standards under varying loads.
Create and edit scripts using the SQABasic and VU scripting environments. The Robot editor provides color-coded commands with keyword Help for powerful integrated programming during script development. (VU scripting is used with sessions in performance testing.)
Test applications developed with IDEs such as Java, HTML, Visual Basic, Oracle Forms, Delphi, and PowerBuilder. You can test objects even if they are not visible in the application’s interface.
Collect diagnostic information about an application during script playback. Robot is integrated with Rational Purify, Rational Quantify, and Rational PureCoverage. You can play back scripts under a diagnostic tool and see the results in the log.

The Object-Oriented Recording technology in Robot lets you generate scripts by simply running and using the application-under-test. Robot uses Object-Oriented Recording to identify objects by their internal object names, not by screen coordinates. If objects change locations or their text changes, Robot still finds them on playback.

The following figure shows the main Robot window after you have recorded a script.

The Object Testing technology in Robot lets you test any object in the application-under-test, including the object’s properties and data. You can test standard Windows objects and IDE-specific objects, whether they are visible in the interface or hidden.

In functional testing, Robot provides many types of verification points for testing the state of the objects in your application. For example, you use the Object Properties verification point to capture the properties of an object during recording, and to compare these properties during playback.

The following figure shows the Object Properties Verification Point dialog box.

Introduction to Rational Robot

2007-06-06T00:18:00.000-07:00

What Is Rational Robot?

Rational Robot is a complete set of components for automating the testing of Microsoft Windows client/server and Internet applications running under Windows NT 4.0, Windows XP, Windows 2000, and Windows 98.

The main component of Robot lets you start recording tests in as few as two mouse clicks. After recording, Robot plays back the tests in a fraction of the time it would take to repeat the actions manually.

Other components of Robot are:

Rational Administrator – Use to create and manage Rational projects, which store your testing information.
Rational TestManager Log – Use to review and analyze test results.
Object Properties, Text, Grid, and Image Comparators – Use to view and analyze the results of verification point playback.
Rational SiteCheck – Use to manage Internet and intranet Web sites.

Managing Rational Projects with the Administrator

You use the Rational. Administrator to create and manage projects.

Rational projects store application testing information, such as scripts, verification points, queries, and defects. Each project consists of a database and several directories of files. All Rational Test components on your computer update and retrieve data from the same active project.

Projects help you organize your testing information and resources for easy tracking. Projects are created in the Rational Administrator, usually by someone with administrator privileges.

Use the Administrator to:

Create a project under configuration management.
Create a project outside of configuration management.
Connect to a project.
See projects that are not on your machine (register a project).
Delete a project.
Create and manage users and groups for a Rational Test datastore.
Create and manage projects containing Rational RequisitePro. projects and Rational Rose. models.
Manage security privileges for the entire Rational project.
Create a test datastore using SQL Anywhere.
Convert an existing Microsoft Access test datastore to a SQL Anywhere test datastore.

The following figure shows the main Rational Administrator window after you have created some projects:

Summary

When you create a test datastore, the Rational Administrator uses Microsoft Access for the default database engine. However, if more than one user will access the test datastore simultaneously, use Sybase SQL Anywhere for the database engine. To create a test datastore using SQL Anywhere software, click Advanced Database Setup in the Create Test Datastore dialog box. See the Rational Administrator online Help for more information.

You must install Sybase SQL Anywhere software and create a SQL Anywhere database server before you create a new SQL Anywhere test datastore or convert an existing Microsoft Access test datastore to a SQL Anywhere test datastore.

SilkTest and WinRunner Feature Descriptions Continued...

2007-05-09T00:39:00.000-07:00

Scripting Language
Both tools provide proprietary, interpreted, scripting languages. Each language provide the usual flow control constructs, arithmetic and logical operators, and a variety of built-in libraryfunctions to perform such activities as string manipulation, [limited] regular expression support,standard input and output, etc. But that is where the similarity ends:
• SilkTest provides a strongly typed, object-oriented programming language called 4Test.Variables and constants may be one of 19 built-in data types, along with a user definedrecord data type. 4Test supports single- and multi-dimensional dynamic arrays and lists,which can be initialized statically or dynamically. Exception handling is built into thelanguage [via the do… except statement].
• WinRunner provides a non-typed, C-like procedural programming language called TSL.Variables and constants are either numbers or strings [conversion between these two typesoccurs dynamically, depending on usage]. There is no user defined data type such as a recordor a data structure. TSL supports sparsely populated associative single- and [pseudo] multidimensionarrays, which can be initialized statically or dynamically—element access isalways done using string references—foobar[“1”] and foobar[1] access the sameelement [as the second access is implicitly converted to an associative string indexreference]. Exception handling is not built into the language.The only way to truly understand and appreciate the differences between these two programmingenvironments is to use and experiment with both of them.

Exception Handling
Both tools provide the ability to handle unexpected events and errors, referred to as exceptions,but implement this feature differently:
• SilkTest’s exception handling is built into the 4Test language—using the do… exceptconstruct you can handle the exception locally, instead of [implicitly] using SilkTest’sdefault built-in exception handler [which terminates the currently running test and logs anerror]. If an exception is raised within the do block of the statement control is thenimmediately passed to the except block of code. A variety of built-in functions[LogError(), LogWarning, ExceptNum(), ExceptLog(), etc.] and 4Test statements[raise, reraise, etc.] aid in the processing of trapped exceptions within the except blockof code.
• WinRunner’s exception handling is built around
(1) defining an exception based on the typeof exception (Popup, TSL, or object) and relevant characteristics about the exeception (mostoften its error number);
(2) writing an exception hander, and
(3) enabling and disabling thatexception handler at appropriate point(s) in the code. These tasks can be achieved by handcoding or through the use of the Exception Handling visual recorder.

Test Results Analysis
• SilkTest’s test results file resolves around the test run. For example if you run 3 testcases[via a test suite or SilkOrganizer] all of the information for that test run will be stored in asingle results file. There is a viewer to analyze the results of the last test run or X previous tothe last run. Errors captured in the results file contain a full stack trace to the failing line ofcode, which can be brought up in the editor by double-clicking on any line in that stack trace.
• WinRunner’s test results file revolves around each testcase. For example if you run 3testcases [by hand or via a batch test or TestDirector] 3 test results files are created, each in asubdirectory under its associated testcase. There is a viewer to analyze the results of a test’slast run or if results have not been deleted, a previous run. Double clicking on events in thelog often expands that entry’s information, sometimes bringing up specialized viewers [forexample when that event is some type of checkpoint or some type of failure].

Managing the Testing Process
• SilkTest has a built-in facility, SilkOrganizer, for creating a testplan and then linking thetestplan to testcases. SilkOrganizer can also be used to track the automation process andcontrol the execution of selected groups of testcases. One or more user defined attributes[such as “Test Category”, “Author”, “Module”, etc.] are assigned to each testcase and thenlater used in testplan queries to select a group of tests for execution. There is also a modestcapability to add manual test placeholders in the testplan, and then manually add pass/failstatus to the results of a full test run. SilkTest also supports a test suite, which is a filecontaining calls to one or more test scripts or other test suites.
• WinRunner integrates with a separate program called TestDirector [at a substantialadditional cost], for visually creating a test project and then linking WinRunner testcases intothat project. TestDirector is a database repository based application that provides a variety oftools to analyze and manipulate the various database tables and test results stored in therepository for the project. A bug reporting and tracking tool is included with TestDirector aswell [and this bug tracking tool supports a browser based client].Using a visual recorder, testcases are added to one or more test sets [such as “TestCategory”, “Author”, “Module”, etc.] for execution as a group. There is a robust capabilityfor authoring manual test cases [i.e. describing of each test step and its expected results],interactively executing each manual test, and then saving the pass/fail status for each teststep in the repository. TestDirector also allows test sets to be scheduled for execution at atime and date in the future, as well as executing tests remotely on other machines [this lastcapability requires the Enterprise version of TestDirector].TestDirector is also capable of interfacing with and executing LoadRunner test scripts aswell as other 3rd party test scripts [but this later capability requires custom programming viaTestDirector APIs]. Additionally TestDirector provides API’s to allow WinRunner as well asother 3rd party test tools [and programming environments] to interface with a TestDirectordatabase.

External Files
When the tool’s source code files are managed with a code control tool such as PVCS or VisualSourceSafe, it is useful to understand what external side files are created:
• SilkTest implicitly creates *.*o bytecode-like executables after interpreting the source codecontained in testcases and include files [but it unlikely that most people will want to sourcecode control these files]. No side files are created in the course of using its recorders.SilkTest does though create an explicit *.bmp files for storing the expected and actualcaptured bitmap images when performing a bitmap verification.• WinRunner implicitly creates many side files using a variety of extensions [*.eve, *.hdr,*.asc, *.ckl, *.chk, and a few others] in a variety of implicitly created subdirectories[/db, /exp, /chklist, /resX] under the testcase in the course of using its visual recordersas well as storing pass/fail results at runtime.

Debugging
Both tools support a visual debugger with the typical capabilities of breakpoints, single step, runto, step into, set out of, etc.

SilkTest And WinRunner Feature Description Continued....

2007-05-09T00:24:00.000-07:00

Object Hierarchy
• SilkTest supports a true object-oriented hierarchy of parent-child-grandchild-etc.relationships between windows and objects within windows. In this model an object such asa menu is the child of its enclosing window and a parent to its menu item objects.
• WinRunner, with some rare exceptions [often nested tables on web pages], has a flat objecthierarchy where child objects exist in parent windows. Note that web page frames are treatedas windows, and not child objects of the enclosing window on web pages that are constructedusing frames.

Object Recognition
Both of these tools use a lookup table mechanism to isolate the variable name used to referencean object in a test script from the description used by the operating system to access that object atruntime:
• SilkTest normally places an application’s GUI declarations in a test frame file. There isgenerally one GUI declaration for each window and each object in a window. A GUI declaration consists of an object identifier—the variable used in a test script—and its class and object tag definition used by the operating system to access that object at runtime.SilkTest provides the following capabilities to define an object tag:
(1) a string, which caninclude wildcards;
(2) an array reference which resolves to a string which can includewildcards;
(3) a function or method call that returns a string, which can include wildcards,
(4) an object class and class relative index number; and
(5) multiple tags [multi-tags] eachoptionally conditioned with
(6) an OS/GUI/browser specifier [a qualification label].
• WinRunner normally places an application’s logical name/physical descriptor definitions in a GUI Map file. There is generally one logical name/physical descriptor definition for eachwindow and each object in a window. The logical name is used to reference the object in atest script, while the physical descriptor is used by the operating system to access that objectat runtime.WinRunner provides the following capabilities to define a physical descriptor:
(1) a variablenumber of comma delimited strings which can include wildcards, where each stringidentifies one property of the object. [While there is only a single method of defining a physical descriptor, this definition can include a wide range and variable number ofobligatory, optional, and selector properties on an object by object basis].The notion behind this lookup table mechanism is to permit changes to an object tag [SilkTest]or a physical descriptor [WinRunner] definition without the need to change the associatedidentifier [SilkTest] or logical name [WinRunner] used in the testcase.In general the object tag [SilkTest] or physical descriptor [WinRunner] resolve to one or moreproperty definitions which uniquely identify the object in the context of its enclosing parentwindow at runtime.It is also possible with both tools to dynamically construct and use object tags [SilkTest] orphysical descriptors [WinRunner] at runtime to reference objects in test scripts.

Object Verification
Both tools provide a variety of built-in library functions permitting a user to hand code simple verification of a single object property [i.e. is/is not focused, is/is not enabled, has/does not have an expected text value, etc.]. Complex multiple properties in a single object and multiple object verifications are supported using visual recorders:
• SilkTest provides a Verify Window recorder which allows any combination of objects and object properties in the currently displayed window to be selected and captured. Using this tool results in the creation, within the testcase, of a VerifyProperties() method call against the captured window.
• WinRunner provides several GUI Checkpoint recorders to validate
(1) a single object property,
(2) multiple properties in a single object, and
(3) multiple properties of multiple objects in a window. The single property recorder places a verification statement directly inthe test code while the multiple property recorders create unique checklist [*.ckl] files inthe /chklists subdirectory [which describe the objects and properties to capture], as wellas an associated expected results [*.chk] file in the /exp subdirectory [which contains theexpected value of each object and property defined in the checklist file].Both tools offer advanced features to define new verification properties [using mapping techniques and/or built-in functions and/or external DLL functions] and/or to customize howexisting properties are captured for standard objects.

Custom Objects
Note: The description of this feature, more than any other in this report, is limited in its scope and coverage. An entire white paper could be dedicated to exploring and describing how each ofthese tools deal with custom objects. Therefore dedicate several days to evaluating how eachof these tools accommodate custom objects in your specific applications.To deal with a custom object [i.e. an object that does not map to standard class] both toolssupport the use of class mapping [i.e. mapping a custom class to a standard class with like functionality], along with a variety of X:Y pixel coordinate clicking techniques [some screen absolute, some object relative] to deal with bitmap objects, as well as the ability to use external DLL functions to assist in object identification and verification. Beyond these shared capabilitieseach tool has the following unique custom object capabilities:
• SilkTest has a feature to overlay a logical grid of X rows by Y columns on a graphic that has evenly spaced “hot spots”[this grid definition is then used to define logical GUI declarationsfor each hot spot]. These X:Y row/column coordinates are resolution independent [i.e. thelogical reference says “give me 4th column thing in the 2nd row”, where that grid expands orcontracts depending on screen resolution].
• WinRunner has a built-in text recognition engine which works with most standard fonts.This capability can often be used to extract visible text from custom objects, position thecursor over a custom object, etc. This engine can also be taught non-standard font typeswhich is does understand out of the box.Both tools offer support for testing non-graphical controls through the advanced use of customDLLs [developed by the user], or the Extension Kit [SilkTest, which may have to be purchased atan addition cost] and the Mercury API Function Library [WinRunner].

Internationalization (Language Localization)
• SilkTest supports the single-byte IBM extended ASCII character set, and its TechnicalSupport has also indicated “that Segue has no commitment for unicode”. The user guidechapter titled “Supporting Internationalized Applications” shows a straightforward techniquefor supporting X number of [single-byte IBM extended ASCII character set] languages in asingle test frame of GUI declarations.
• WinRunner provides no documentation on how to use the product to test language localizedapplications. Technical Support has indicated that
(1) “WinRunner supports multi-bytecharacter sets for language localized testing…”,
(2) “there is currently no commitment forthe unicode character set…”, and
(3) “it is possible to convert a US English GUI Map toanother language using a [user developed] phrase dictionary and various gui_* built-infunctions”.Check into the aspects of this feature very carefully if it is important to your testing effort.

Database Interfaces
Both tools provide a variety of built-in functions to perform Structure Query Language (SQL)queries to control, alter, and extract information from any database which supports the OpenDatabase Connectivity (ODBC) interface.

Database Verification
Both tools provide a variety of built-in functions to make SQL queries to extract informationfrom an ODBC compliant database and save it to a variable [or if you wish, an external file].Verification at this level is done with hand coding.WinRunner also provides a visual recorder to create a Database Checkpoint used to validate theselected contents of an ODBC compliant database within a testcase. This recorder creates sidefiles similar to GUI Checkpoints and has a built-in interface to
(1) the Microsoft Query application [which can be installed as part of Microsoft Office], and
(2) to the Data Junctionapplication [which may have to be purchased at an addition cost], to assist in constructing andsaving complex database queries.

Data Driven Testing
Both tools support the notion of data-driven tests, but implement this feature differently:
• SilkTest’s implementation is built around an array of user defined records. A record is adata structure defining an arbitrary number of data items which are populated with valueswhen the array is initialized [statically or at runtime]. Non-programmers can think of anarray of records as a memory resident spreadsheet of X number of rows which contain Ynumber columns where each row/column intersection contains a data item.The test code, as well as the array itself, must be hand coded. It is also possible to populatethe array each time the test is run by extracting the array’s data values from an ODBC compliant database, using a series of built-in SQL function calls. The test then iteratesthrough the array such that each iteration of the test uses the data items from the next recordin the array to drive the test or provide expected data values.
• WinRunner’s implementation is built around an Excel compatible spreadsheet file of Xnumber of rows which contain Y number of columns where each row/column intersectioncontains a data item. This spreadsheet is referred to as a Data Table.The test code, as well as the Data Table itself, can be created with hand coding or the use ofthe DataDriver visual recorder. It is also possible to populate a Data Table file each time thetest is run by extracting the table’s data values from an ODBC compliant database using aWinRunner wizard interfaced to the Microsoft Query application.. The test then iteratesthrough the Data Table such that each iteration of the test uses the data items from the nextrow in the table to drive the test or provide expected data values.Both tools also support the capability to pass data values into a testcase for a more modestapproach to data driving a test.

Restoring an Application’s Initial State
• SilkTest provides a built-in recovery system which restores the application to a stable state,referred to as the basestate, when the test or application under test fails ungracefully. Thedefault basestate is defined to be: (1) the application under test is running;
(2) the applicationis not minimized; and
(3) only the application’s main window is open and active. There aremany built-in functions and features which allow the test engineer to modify, extend, andcustomize the recovery system to meet the needs of each application under test.
• WinRunner does not provide a built-in recovery system. You need to code routines to returnthe application under test to its basestate—and dismiss all orphaned dialogs—when a testfails ungracefully.

Silktest And WinRunner Feature Descriptions

2007-05-08T23:35:00.000-07:00

FEATURE DESCRIPTIONS
For the sake of consistency alphabetical ordering was selected to describe SilkTest features first,followed by WinRunner features in each of the following sections.

Startup Initialization and Configuration
• SilkTest derives its initial startup configuration settings from its partner.ini file. Thisthough is not important because SilkTest can be reconfigured at any point in the session byeither changing any setting in the Options menu or loading an Option Set.An Option Set file (*.opt) permits customized configuration settings to be established foreach test project. The project specific Option Set is then be loaded [either interactively, orunder program control] prior to the execution of the project’s testcases.The Options menu or an Option Set can also be used to load an include file (*.inc)containing the project’s GUI Declarations along with any number of other include files containing library functions, methods, and variables sharedby all testcases.
• WinRunner derives its initial startup configuration from a wrun.ini file of settings.During startup the user is normally polled [this can be disabled] for the type of addins theywant to use during the session .The default wrun.ini file is used when starting WinRunner directly, while project specificinitializations can be established by creating desktop shortcuts which reference a projectspecific wrun.ini file. The use of customized wrun.ini files is important because once WinRunner is started with a selected set of addins you must terminate WinRunner and restart it to use a different set of addins.The startup implementation supports the notion of a startup test which can be executedduring WinRunner initialization. This allows project-specific compiled modules [memoryresident libraries] and GUI Maps to be loaded. The functions and variables contained in these modules can then be used by all tests that are run during that WinRunner session.Both tools allow most of the configuration setup established in these files to be over-ridden withruntime code in library functions or the test scripts.

Test Termination
• SilkTest tests terminate on exceptions which are not explicitly trapped in the testcase.
For example if a window fails to appear during the setup phase of testing [i.e. the phase drivingthe application to a verification point], a test would terminate on the first object or windowtimeout exception that is thrown after the errant window fails to appear.
• WinRunner tests run to termination [in unattended Batch mode] unless an explicit action is taken to terminate the test early. Therefore tests which ignore this termination model will continue running for long periods of time after a fatal error is encountered. For example if awindow fails to appear during the setup phase of testing, subsequent context sensitive statements [i.e. clicking on a button, performing a menu pick, etc.] will fail—but this failure occurs after a multi-second object/window “is not present” timeout expires for each missingwindow and object. [When executing tests in non-Batch mode, that is in Debug, Verify, orUpdate modes, WinRunner normally presents an interactive dialog box when implicit errorssuch as missing objects and windows are encountered].
Addins and ExtensionsOut of the box, under Windows, both tools can interrogate and work with objects and windowscreated with the standard Microsoft Foundation Class (MFC) library. Objects and windows created using a non-MFC technology [or non-standard class naming conventions] are treated ascustom objects. But objects and windows created for web applications [i.e. applications which run in a browser],Java applications, Visual Basic applications, and PowerBuilder applications are dealt with in aspecial manner:
• SilkTest enables support for these technologies using optional extensions. Selectedextensions are enabled/disabled in the current Option Set [or the configuration established bythe default partner.ini option settings].
• WinRunner enables support for these technologies using optional addins. Selected addins are enabled/disabled using either the Addin Manager at WinRunner startup, or by editing the appropriate wrun.ini file prior to startup.
Note that (1) some combinations of addins [WinRunner] and extensions [SilkTest] are mutuallyexclusive, (2) some of these addins/extensions may no longer be supported in the newest releasesof the tool, (3) some of these addins/extensions may only support the last one or two releases ofthe technology [for example version 5 and 6 of Visual Basic] and (4) some of these addins andextensions may have to be purchased at an addition cost.

Visual Recorders
SilkTest provides visual recorders and wizards for the following activities:
• Creating a test frame with GUI declarations for a full application and adding/deleting selective objects and windows in and existing GUI declarations frame file.
• Capturing user actions with the application into a test case, using either context sensitive[object relative] or analog [X:Y screen coordinate relative] recording techniques.
• Inspecting identifiers, locations and physical tags of windows and objects.
• Checking window and object bitmaps [or parts thereof].
• Creating a verification statement [validating one or more object properties].WinRunner provides visual recorders and wizards for the following activities:
• Creating an entire GUI Map for a full application and adding/deleting selective objects andwindows in an existing GUI Map. It is also possible to implicitly create GUI Map entries bycapturing user actions [using the recorder described next].
• Capturing user actions with the application into a test case, using either context sensitive[object relative] or analog [X:Y screen coordinate relative] recording techniques.
• Inspecting logical names, locations and physical descriptions of windows and objects.• Checking window and object bitmaps [or parts thereof].
• Creating a GUI checkpoint [validating one or more object properties].
• Creating a database checkpoint [validating information in a database].
• Creating a database query [extracting information from a database].
• Locating at runtime a missing object referenced in a testcase [and then adding that object tothe GUI Map].
• Teaching WinRunner to recognize a virtual object [a bitmap graphic with functionality].
• Creating Data Tables [used to drive a test from data stored in an Excel-like spreadsheet].• Checking text on a non-text object [using a built-in character recognition capability].
• Creating a synchronization point in a testcase.
• Defining an exception handler.Some of these recorders and wizards do not work completely for either tool against allapplications, under all conditions. For example neither tool’s recorder to create a full GUI Map[WinRunner] or test frame [SilkTest] works against large applications, or any web application.Evaluate the recorders and wizards of interest carefully against your applications if these utilitiesare important to your automated testing efforts.

Selecting the best defect tracking system

2007-05-04T02:12:00.000-07:00

The following is a general comparison overview of Bug tracking tools. It is focused particularly on the technical aspect. The aim is to help you to select the best tracking system that meets your requirement. Click on the link for a more detailed comparison between Bugzero, Bugzilla, and Gnats.

System Architecture:
Many old bug or defect tracking systems are client server based. You need install the server, and each user need install the client software. If external users were involved, it could be problematic because of issues like firewall etc. Also, it is not always feasible to install client software.
Newer systems are more likely web browser based and no client software need to be installed (except a browser). A web-based bug tracking system is especially attractive if your users are located in different locations and are connected through the internet.
For a web-based bug or defect tracking system, make sure it supports the browsers your users are using. Be aware that many systems support only IE.

Server Operating System:
Most commercial bug tracking systems are Windows based. In such a case, it is likely that it requires an NT/2000/XP server and a SQL Server database. Note that, a Windows XP Professional may not be sufficient, instead, a server may be required.
Most free bug or defect tracking systems are Linux/Unix based, and may not work as well on Windows. It may also require more technical skills to install and setup the system.
When people say their system is cross-platform, you need make sure they meant the server. Only a very few bug tracking systems are really cross-platform (with the same code base). Some vendors claim to support multiple OS, but they have completely independent versions for each OS and that results in higher costs for the vendor and therefore higher price for the end users.

Backend Database:
Most bug or defect tracking systems require a backend database, but a few are file based. In the latter case, make sure it scales well. If someone tells you that a file based system is better than a database, think twice.
For Windows based systems, database selection may be limited to only Access and SQL Server. On the other hand, some free systems may lock you into just one database, notably MySQL. Only a very few bug tracking systems are really cross database systems.
Be aware of any bug tracking software that uses non-standard proprietary databases. They cannot be better than the public, commonly used database systems.

Language Support:
Many bug tracking systems do not support localization, particually, Asian langauges. Note that, it involves the web interface, the data, and the email notification.
If you do need localization, you should find a system that can do that easily.

Web Server:
For Windows based bug tracking systems, most likely it requires IIS as the web server.
For Java-based bug tracking systems, a Servlet or J2EE server is most likely required. There are many high quality servers you can download for free.

Programming Language:
Most of the bug tracking systems are written in either c/c++, or perl/php, or Java.
Depending on your IT environment and skill set, the programming language may be relevant in selecting your system. For example, if you are developing Java software, it may make sense to use a Java based bug tracking system.

Version Control Integration:
Some bug tracking systems have the capability of integrating with source control systems such as CVS, Source Safe, etc.
Be aware of the limitations, and make sure it does the things you want.

Installation and Configuration:
A bug tracking system is not a desktop application and it rarely works out-of-the-box. It is not uncommon to spend a few hours to setup such a system, and then more time to customize it.
However, if you need only a lightweight bug tracking system, a heavy, complex, can-do-everything system is certainly a over kill and it may do more harm than good.

Maintenance and Support:
A bug tracking tool is not a super complex software system, but from time to time you may need technical support. As you certainly know, in most cases, the error messages from these systems are always cryptic, and you won't be able to solve the problem on your own.
How is the error handled in a tool is far more important than you might think. You as the administrator may want select a tool that you feel comfortable to work with.
When support is needed, it is always urgent to you, but not necessary to the vendor. Before you purchase the software, you should ask what is the response time for support.

Features:
Simple is the key here. The system must be simple that people like to use it, but not so complex that people avoid to use it. You might not want to deploy a tool that requires serious end user training. It is really not the initial training, rather the on-going support needed from your end users that you should be concerned with.
Yet it should be flexible and configurable enough to satisfy your business needs. If you select a tool that cannot do whatever you intend it to do, then what is the use of it?

Cost of Ownship:
The initial cost of a bug tracking system varies from free to tens of thousands of dollars. But be aware that this is not the same as the total cost of the ownership. Some free systems charge a hefty consulting fee for support and you may end up paying much more than you planned.
You should select a bug tracking system based on your needs, not just the price. If you know what you are doing and do not need commercial support, go for a free one if it meets your requirement.
However, if you unfortunately selected a bad one, you better get out of it as soon as possible, because the longer you keep it, the more moeny and time you will have to spend on it.
In any case, spending many days to setup a free system or even weeks or months to create an in-house system makes no business and economic sense, because if you consider the time spent, you are actually paying much more than just buying one.

WinRunner Tips

2007-05-04T02:02:00.000-07:00

WinRunner Fundamentals
The 5 major areas to know for WinRunner are listed below with SOME of the subtopics called out for each of the major topics:
1) GUI Map
- Learning objects
- Mapping custom objects to standard objects
2) Record/Playback
- Record modes: Context Sensitive and Analog
- Playback modes: (Batch), Verify, Update, Debug
3) Synchronization
- Using wait parameter of functions
- Wait window/object info
- Wait Bitmap
- Hard wait()
4) Verification/Checkpoints
- window/object GUI checkpoints
- Bitmap checkpoints
- Text checkpoints (requires TLS)
5) TLS (Test Script Language)
- To enhance scripts (flow control, parameterization, data driven test, user defined functions,...

Calling Scripts and Expected Results
When running in non-batch mode, WinRunner will always look in the calling scripts \exp directory for the checks. When running in batch mode, WinRunner will look in the called script's \exp directory.
There is a limitation, though. WinRunner will only look in the called script's \exp directory one call level deep. For example, in bacth mode: script1:
gui_check(...); #will look in script1\exp
call "script2" ();
script2:
gui_check(...); #will look in script2\exp
call "script3" ();
script3:
gui_check(...); #will look in script2\exp (and cause an error)
In non bacth mode:
script1:
gui_check(...); #will look in script1\exp
call "script2" ();
script2:
gui_check(...); #will look in script1\exp (and cause an error)
call "script3" ();
script3:
gui_check(...); #will look in script1\exp (and cause an error)

Run Modes
Batch mode will write results to the individual called test.
Interactive (non-batch) mode writes to the main test.
Data Types
TSL supports two data types: numbers and strings, and you do not have to declare them. Look at the on-line help topic for some things to be aware of:
"TSL Language", "Variables and Constants", "Type (of variable or constant)"
Generally, you shouldn't see any problems with comparisons.
However, if you perform arithmetic operations you might see some unexpected behavior (again check out the on-line help mentioned above). var="3abc4";rc=var + 2; # rc will be 5 :-)

Debugging
When using pause(x); for debugging, wrap the variable with brackets to easily see if "invisible" characters are stored in the variable (i.e., \n, \t, space, or Null) pause("[" & x & "]");
Use the debugging features of WinRunner to watch variables. "invisible" characters will show themselves (i.e., \n, \t, space) Examples:
Variable
pause(x);
pause("[" & x & "]");
x="a1";
a1
[a1]
x="a1 ";
a1
[a1 ]
x="a1\t";
a1
[a1 ]
x="a1\n";
a1
[a1]
x="";

[]

Block Comments
To temporarily comment out a block of code use: if (TRUE) { ... block of code to be commented out!! }

Data Driven Test ddt_* functions vs getline/split
These bothfunctions do almost the same thing. There are some agruably good benefits to using ddt_* , but most of them are focused on the data management. In general you can always keep the data in Excel and perform a Save As to convert the file to a delimited text file.
One major difference is in the performance of playing back a script that has a huge data file. The ddt_* functions currently can not compare to the much faster getline/split method.
But here is an area to consider: READABILITY I personally do not like scripts with too many nested function calls (which the parameterize value method does) because it may reduce the readability for people with out a programming background. Example:
edit_set("FirstName", ddt_val(table, "FirstName"));
edit_set("LastName", ddt_val(table, "LastName"));
So what I typically do is, declare my own variables at the beginning of the script, assign the values to them, and use the variable names in the rest of the script. It doesn't matter if I'm using the getline/split or ddt_val functions. This also is very useful when I may need to change the value of a variable, because they are all initialized at the top of the script (whenever possible). Example with ddt_* functions in a script:
FIRSTNAME=ddt_val(table, "FirstName");
LASTNAME=ddt_val(table, "LastName");
...
edit_set("FirstName", FIRSTNAME);
edit_set("LastName", LASTNAME);
And most of the time I have a driving test which calls another test and passes an array of data to be used to update a form. Example with ddt_* functions before calling another
script:
# Driver script will have
...
MyPersonArray [ ] =
{
"FIRSTNAME" = ddt_val(table, "FirstName");
"LASTNAME" = ddt_val(table, "LastName");
}
call AddPerson(MyPersonArray)
...
# Called script will have
edit_set("FirstName", Person["FIRSTNAME"]);
edit_set("LastName", Person["LASTNAME"]);
So as you can see, there are many ways to do the same thing. What people must keep in mind is the skill level of the people that may inherit the scripts after they are created. And a consistent method should be used throughout the project.

String Vs Number Comparison
String Vs Number comparisons are not a good thing to do.
Try this sample to see why:
c1=47.88 * 6;
c2="287.28";
#Prints a decimal value while suppressing non-significant zeros
#and converts the float to a string.
c3 = sprintf ("%g", c1);

pause ("c1 = [" & c1 & "]\nc2 = [" & c2 & "]\nc3 = [" & c3 & "]\n" & "c1 - c2 =
[" & c1 - c2 & "]\nc1 - c3 = [" & c1 - c3 & "]\nc2 - c3 = [" & c2 - c3 & "]");

Text Checkpoint Tips

2007-03-15T02:46:00.000-07:00

• Before you create a script that reads text, determine where the text is located. If
the text is part of a standard GUI object, use a GUI checkpoint or TSL function
such as edit_get_text or button_get_info. If the text is part of a non-standard
GUI object, use the Create > Get Text > From Object/Window command. If the
text is part of a bitmap, use the Create > Get Text > From Screen Area
command.
• When WinRunner reads text from the application, the text appears in the script
as a comment (a comment is preceded by #). If the comment #no text was
found appears in the script, WinRunner does not recognize your application font.
Use the Font Expert to teach WinRunner this font.
• TSL includes additional functions that enable you to work with text such as
win_find_text, obj_find_text, and compare_text. For more information, refer
to the "Checking Text" chapter in your WinRunner User’s Guide.

Running the Test on a New Version

2007-03-15T02:36:00.000-07:00

Once the test script is debugged, you can run it on a new version of the Flight
Reservation application.
1 Open version 1B of the Flight Reservation application.
Choose Programs > WinRunner > Sample Applications > Flight 1B on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Reposition the Flight Reservation application and WinRunner so
that they are both clearly visible on your desktop.
2 In WinRunner, select Verify mode from the Run Mode list on the Standard
toolbar.
Verify mode will stay in effect until you select a different mode.
3 Choose Run from Top.
Choose Run > Run from Top, or click the Run from Top button. The Run Test
dialog box opens. Accept the default test run name "res1." Make sure that the
Display Test Results at End of Run check box is selected.
4 Run the test.
Click OK in the Run Test dialog box. The test run begins.
5 Review the test results.
The test fails because the graph was not updated after WinRunner placed an
order for one ticket. WinRunner read the total number of orders from the graph
and concluded that the text is incorrect.
6 Close the Test Results window.
Choose File > Exit.
7 Close the lesson9 test.
Choose File > Close.
8 Close version 1B of the Flight Reservation application.
Choose File > Exit.

Verifying Text

2007-03-15T02:33:00.000-07:00

In this exercise you add an if/else statement to the test script in order to determine
whether the total was updated in the graph after you placed an order.
1 In the first obj_get_text statement in the lesson9 test script, change the
text variable to first_total.
2 In the second obj_get_text statement in the test script, change the text
variable to new_total.
3 Place the cursor below the last line of the script.
4 Add the following statements to the test script exactly as they appear
below.
if (new_total == first_total + 1)
tl_step ("graph total", 0, "Total is correct.");
else
tl_step ("graph total", 1, "Total is incorrect.");
In plain English, these statements mean "If new_total equals first_total plus 1,
report that the total is correct, otherwise (else) report that the total is incorrect."
5 Add a comment to describe what this section of the script will do.
Place the cursor above the if statement you added in the previous step. Choose
Edit > Comment. After the # sign, type: check that graph total increments by
one.
6 Save the test.
Choose File > Save or click the Save button.

Debugging the Test Script
You should now run the test in Debug mode in order to check for errors in syntax
and logic. If any error messages appear, look over the test script and try to fix the
problem.
1 Select Debug mode from the Run Mode list on the Standard toolbar.
Debug mode will stay in effect until you select a different mode.
2 Run the test.
Choose Run > Run from Top or click the Run from Top button. If you prefer to
run the test line by line, use the Step button.
3 Review the test results in the WinRunner Test Results window.
Choose Tools > Test Results or click the Test Results button. The WinRunner
Test Results window displays the results of the Debug test run.
If the tl_step event failed, a problem exists in the test script. Examine the script
and try to fix the problem.
4 Close the Test Results window.
Choose File > Exit in the WinRunner Test Results window.
5 Exit the Flight Reservation application.
Choose File > Exit.

Teaching Fonts to WinRunner

2007-03-15T02:29:00.000-07:00

In the following exercise you will teach WinRunner the font used by the Flights
Reservation application.
Note that you only need to perform this exercise now if WinRunner did not
recognize text in the previous exercise. In general, you only need to teach fonts
to WinRunner if it does not automatically recognize the fonts in the application you
are testing.
To teach a font to WinRunner you:
• learn the set of characters (font) used by your application
• create a font group, a collection of fonts grouped together for specific testing
purposes
• activate the font group by adding the setvar TSL function to a test script

Learning Fonts
You use the WinRunner Fonts Expert to learn the fonts used by your application.
1 Start WinRunner and open a new test.
If WinRunner is not already open, choose Programs > WinRunner >
WinRunner on the Start menu. If the Welcome window is open, click the New
Test button. Otherwise, choose File > New. A new test window opens.
2 Open the Fonts Expert.
In WinRunner, choose Tools > Fonts Expert. The Font Expert window opens.
3 Open the Learn Font window.
In the Fonts Expert, choose Font > Learn. The Learn Fonts window opens.
4 Name the font in the Flight Reservation flights.
In the Font Name box, type flights.
5 Describe the properties of the flights font.
Click the Select Font button to open the Font dialog box. The Flight Reservation
font is MS Sans Serif, Bold, 8 points. Select these properties in the window and
click OK.
6 Learn the flights font.
In the Learn Font window, click the Learn Font button. When the learn process
is completed, the Existing Characters box displays the characters learned and
the Properties box displays the font’s properties.
7 Close the Learn Fonts window.
Click Close.

Creating a Font Group
After WinRunner learns a font, you must assign it to a font group. A font group can
contain one or more fonts. In this exercise you will create a font group which
contains only the flights font.
1 Open the Font Groups window.
In the Fonts Expert, choose Font > Groups.
2 Create a Font Group called flt_res and assign the flights font to it.
Type the name flt_res into the Group Name field. Select "flights" in the Fonts in
Library box. Click the New button.
3 Close the Font Groups window and the Fonts Expert.
Click Close.
4 Close the Fonts Expert.
Choose Font > Exit.

Activating a Font Group
The final step before you can read text is to activate the font group. You do this in
the General Options dialog box.
1 Open a blank test window in WinRunner.
If a blank test window is not currently open, choose File > New.
2 Activate the flt_res font group and the Image Text Recognition mechanism.
Choose Settings > General Options. In the General Options dialog box, click
the Text Recognition tab. Select the Use Image Text Recognition Mechanism
check box. In the Font Group box, type flt_res, and click OK.

Reading Text from an Application

2007-03-13T00:16:00.000-07:00

In this exercise you will record the process of opening the graph in the Flight Reservation application to read the total number of tickets sold, creating a new order, and opening the graph again. In the next exercise you will add programming elements to the test script that verify the text in the graph.
Note that in order for WinRunner to read text on computers with certain display drivers, including ATI, you must learn the fonts in the Flight Reservation application before you can perform this exercise. If WinRunner fails to read text in the exercise below, stop the exercise, follow the instructions in "Teaching Fonts to WinRunner" in the next section, and then repeat this exercise from the beginning.
1 Start WinRunner and open a new test.
If WinRunner is not already open, choose Programs > WinRunner > WinRunner on the Start menu. If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A new test window opens.
2 Open the Flight Reservation application and log in.
Choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu. In the Login window, type your name and the password mercury, and click OK. Reposition the Flight Reservation application and WinRunner so that they are both clearly visible on your desktop.

3 Start recording in Context Sensitive mode.
Choose Create > Record—Context Sensitive or click the Record button.
4 Open the graph.
In the Flight Reservation application, choose Analysis > Graphs.
5 Read the total from the graph.
In WinRunner, choose Create > Get Text > From Screen Area, or click the Get Text From Screen Area button on the User toolbar.
Use the crosshairs pointer and the left mouse button to drag a rectangle around the total. Click the right mouse button to finish the operation.

WinRunner inserts an obj_get_text statement into the test script. The text appears in the script as a comment.

6 Close the graph.
7 Create a new order.
Choose File > New Order in the Flight Reservation application.

8 Enter flight and passenger information.

9 Insert the order into the database.
Click the Insert Order button. When the insertion is complete, the message "Insert Done" appears in the status bar:

10 Synchronize the test so that it waits for the "Insert Done" message to appear in the status bar.
In WinRunner, choose the Create > Synchronization Point > For Object/Window Bitmap command or click the Synchronization Point For Object/Window Bitmap button on the User toolbar.
Use the pointer to click the "Insert Done" message.
11 Open the graph again.
Choose Analysis > Graphs.
12 Read the total from the graph.
Choose Create > Get Text > From Screen Area, or click the Get Text From Screen Area button on the User toolbar.

Use the crosshairs pointer and the left mouse button to drag a rectangle around the total.

Click the right mouse button to finish the operation. WinRunner inserts an obj_get_text statement into the test script.
13 Close the graph.
14 Stop recording.
Choose Create > Stop Recording or click the Stop button.

15 Save the test.
Choose File > Save or click the Save button. Name the test lesson9 and click Save.
16 If you are working in the Global GUI Map File mode, save the new objects to the GUI map.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Choose File > Save. Click Yes or OK to add the new object or new window to your GUI map.
Choose File > Exit to close the GUI Map Editor.

How Do You Read Text from an Application?

2007-03-13T00:12:00.000-07:00

You can read text from any bitmap image or GUI object by adding text checkpoints to a test script. A text checkpoint reads the text from the application. You then add programming elements to the test script, which verify that the text is correct.
For example, you can use a text checkpoint to:
• verify a range of values
• calculate values
• perform certain operations only if specified text is read from the screen
To create a text checkpoint, you indicate the area, object, or window that contains the text you want to read.
WinRunner inserts a win_get_text or obj_get_text statement into the test script and assigns the text to a variable. To verify the text you add programming elements to the script.
Note that when you want to read text from a standard GUI object (such as an edit field, a list, or a menu), you should use a GUI checkpoint, which does not require programming. Use a text checkpoint only when you want to read text from a bitmap image or a non-standard GUI object.
In the following exercises you create a test that:
. opens a graph and reads the total number of tickets sold
. creates a new order for the purchase of one ticket
. opens the graph again and checks that the total number of tickets sold was updated
. reports whether the number is correct or incorrect

Reading Text

2007-03-13T00:10:00.000-07:00

Reading Text

This lesson:
• describes how you can read text from bitmaps and non-standard GUI objects
• shows you how to teach WinRunner the fonts used by an application
• lets you create a test which reads and verifies text
• lets you run the test and analyze the results

Data-Driven Testing Tips

2007-03-12T04:39:00.000-07:00

• You can parameterize only part of your test script or a loop within it, and a single data-driven test can contain more than one parameterized loop.
• You can open and save data tables other than the default.xls data table. This enables you to use several different data tables in one test script.
• You can parameterize statements containing GUI checkpoints, bitmap checkpoints, and bitmap synchronization points, and constants.
• You can use the data table in the same way as an Excel spreadsheet, including inserting formulas into cells.
• Before you run a data-driven test, you should look through it to see if there are any elements that may cause a conflict in a data-driven test. There are two ways to solve most of these conflicts:
• Use a regular expression to enable WinRunner to recognize objects based on a portion of its physical description. For more information on regular expressions, refer to the "Using Regular Expressions" chapter in the WinRunner User’s Guide.
• Use the GUI Map Configuration dialog box to change the physical properties that WinRunner uses to recognize the problematic object.
• You can change the active row, or read from a non-active row during the test run by using TSL statements. For more information, refer to the "Using TSL Functions with Data-Driven Tests" chapter in the WinRunner User’s Guide.
• It is not necessary for the data table viewer to be open when you run a test.

Running the Test and Analyzing Results

2007-03-12T04:33:00.000-07:00

You run the data-driven test just like any other test in WinRunner. When the test run is completed, the results for all iterations are included in a single Test Results window.
1 Make sure that the Flight 1A Flight Reservation application is open on your desktop.
2 In WinRunner, check that Verify mode is selected in the Standard toolbar.
3 Choose Run from Top.
Choose Run > Run from Top, or click the Run from Top button. The Run Test dialog box opens. Accept the default test run name, "res1". Make sure that the Display Test Results at End of Run check box is selected.
4 Run the test.
Click OK in the Run Test dialog box. The test will run through the parameterized section of the script five times, once for each row in the data table.

5 Review the results.
When the test run is completed, the test results appear in the WinRunner Test Results window.

Note that the tl_step event is listed five times and that the details for each iteration include the actual number of tickets, price and total cost that was checked.

6 Close the test results.
Choose File > Exit to close the Test Results window.
7 Close the Flight Reservation application.
Choose File > Exit.
8 Close the lesson8 test.
Choose File > Close.

Customizing the Results Information

2007-03-12T04:32:00.000-07:00

You could run the test now, but it may be difficult for you to interpret the results for each iteration. You can add iteration-specific information to the reporting statements in your script so that you can see which data is the basis for each result.
1 Modify the tl_step statements.
Locate the first tl_step statement in your script. Delete the words "total is correct." and replace them with, "Correct. "tickets" tickets at $"price" cost $"total"."
tl_step("total",0, "Correct. "tickets" tickets at $"price" cost $"total".");
Use the same logic to modify the next tl_step statement to report an incorrect result. For example:
tl_step("total", 1, "Error! "tickets" tickets at $"price" does not equal $"total". ");
Now you will be able to see which data is used in each iteration when you view the results.
2 Save the test.
Choose File > Save or click the Save button.

Adjusting the Script with Regular Expressions

2007-03-12T04:19:00.000-07:00

Your test is almost finished. Before running the test you should look through it to see if there are any elements that may cause a conflict in a data-driven test. The DataDriver wizard finds all fixed values in selected checkpoints and recorded statements, but it does not check for things such as object labels that also may vary based on external input.
In the flight application, the name of the Fax Order window changes to reflect the fax order number. If you run the test as it is, the test will fail on the second iteration, because the Flight Application will open a window labeled, "Fax Order No. 1", but the script tells it to make the window labeled, "Fax Order No. 4" active. WinRunner will be unable to find this window.
To solve this problem, you can use a regular expression. A regular expression is a string that specifies a complex search phrase in order to enable WinRunner to identify objects with varying names or titles.
In this exercise you will use a regular expression in the physical description of the Fax Order window so that WinRunner can ignore variations in the window’s label.

1 Locate the Fax Order window in the flight1a.gui GUI map file.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Select the Fax Order No. 4 window icon.
2 Modify the window label with a regular expression.
Select Modify. The Modify window opens. In the Physical Description label line, add an "!" immediately following the opening quotes to indicate that this is a regular expression. Delete the period, space and the number "4" at the end of the line and replace this text with ".*" to indicate that the text following this phrase can vary.

3 Close the Modify dialog box.
Click OK to close the Modify window
4 Save the GUI map (only if you are working in the Global GUI Map File mode) and close the GUI Map Editor.
If you are working in the Global GUI Map File mode, Choose File > Save to save your changes and choose File > Exit to close the GUI Map Editor.
If you are working in the GUI Map File per Test mode, choose File > Exit to exit the GUI Map Editor.

Adding Data to the Data Table

2007-03-12T04:01:00.000-07:00

Now that you have parameterized your test, you are ready to add the data that the
parameterized test will use.
1 Open the data table.
Choose Tools > Data Table. The lesson8.xls table opens. Note that there is one
column named "Order_Num", and that the first row in the column contains the
value "4".
2 Add data to the table.
In rows 2, 3, 4, and 5 of the Order_Num column, enter the values, "1", "6", "8",
and "10" respectively.

3 Save and close the table.
Click an empty cell and choose File > Save from the data table menu. Then
choose File > Close to close the table.
4 Save the test.
Choose File > Save or click the Save button. Click Save to close the Save Test
dialog box.

Converting Your Test to a Data-Driven Test

2007-03-12T03:20:00.000-07:00

Start by opening the test you created in Lesson 7 and using the DataDriver Wizard
to parameterize the test.
1 Create a new test from the lesson7 test.
If WinRunner is not already open, choose Programs > WinRunner >
WinRunner on the Start menu. If the Welcome window is open, click the Open
Test button. Otherwise, choose File > Open and select the test you created in
Lesson 7. The lesson7 test opens.
Choose File > Save As and save the test as lesson8 in a convenient location on
your hard drive.
2 Run the DataDriver Wizard.
Choose Tools > DataDriver Wizard. The DataDriver Wizard welcome window
opens. Click Next to begin the parameterization process.

3 Create a data table for the test.
In the Use a new or existing Excel table box, type "lesson8". The DataDriver
Wizard creates an Excel table with this name and saves it the test folder.

4 Assign a table variable name.
Accept the default table variable name, "table".

At the beginning of a data-driven test, the Excel data table you wish to use is
assigned as the value of the table variable. Throughout the script, only the table
variable name is used. This makes it easy for you to assign a different data table
to the script at a later time without making changes throughout the script.
5 Select global parameterization options.
Select Add statements to create a data-driven test. This adds TSL statements
to the test that define the table variable name, open and close the data table,
and run the appropriate script selection in a loop for each row in the data table.
Select Parameterize the test and choose the Line by line option. When you
select Parameterize the test, you instruct WinRunner to find fixed values in
recorded statements and selected checkpoints and to replace them with
parameters. The Line by line option instructs the wizard to open a screen for
each line of the selected test that can be parameterized so that you can choose
whether or not to parameterize that line.
Click Next.
6 Select the data to parameterize.
The first line-by-line screen opens. It refers to the Order Number radio button.

In this test you are going to open a different fax order in each iteration and the
Order Number radio button must be selected each time. Thus, for this script line,
keep the selection, Do not replace this data, and click Next.
The next line by line screen refers to the Order Number edit field. This is the field
you want to change for each iteration. Note that the value, "4" is highlighted and
listed in the Argument to be replaced box to indicate that this is the value
selected for parameterization.

Select A new column under "Replace the selected value with data from:" and
type: Order_Num in the adjacent edit field. The New Column option creates a
column titled "Order_Num" in the lesson8.xls table, and enters the value "4" in
the first row of the column.

Click Next and then click Finish. Your test is parameterized.

How Do You Create Data-Driven Tests?

2007-03-12T03:12:00.000-07:00

Once you have successfully debugged and run your test, you may want to see
how the same test performs with multiple sets of data. To do this, you convert
your test to a data-driven test and create a corresponding data table with the sets
of data you want to test.
Converting your test to a data-driven test involves the following steps:
• Adding statements to your script that open and close the data table.
• Adding statements and functions to your test so that it will read from the data
table and run in a loop while it applies each set of data.
• Replacing fixed values in recorded statements and checkpoint statements with
parameters, known as parameterizing the test.
You can convert your test to a data-driven test using the DataDriver Wizard or
you can modify your script manually.

When you run your data-driven test, WinRunner runs the parameterized part(s) of
the test one time (called an iteration) for each set of data in the data table, and
then displays the results for all of the iterations in a single Test Results window.
In Lesson 7 you created a test that opened a specific flight order and read the
number of tickets, price per ticket, and total price from a fax order dialog box in
order to check that the total price was correct. In this lesson you will create a test
that performs the same check on several flight orders in order to check that your
application computes the correct price for various quantities and prices of tickets.

Creating Data-Driven Tests

2007-03-12T03:09:00.000-07:00

Creating Data-Driven Tests

This lesson:
• shows you how to use the DataDriver Wizard to create a data-driven test
• explains how to use regular expressions for GUI object names that vary with
each iteration of a test
• lets you run a test with several iterations and analyze the results

Running the Test on a New Version

2007-03-12T02:57:00.000-07:00

5 Review the test results.
When the test run is completed, the test results appear in the WinRunner Test Results window.

You can double-click the tl_step statement in the test log to view the full details:

Notice that the message, "Total is correct", is the same message you wrote in the test script. Click OK to close the message.
6 Close the test results.
Choose File > Exit to close the Test Results window.
7 Close the lesson7 test.
Choose File > Close.
8 Close version 1B of the Flight Reservation application.
Choose File > Exit.

Debugging the Test Script

2007-03-12T02:54:00.000-07:00

After enhancing a test with programming elements, you should check that the test
runs smoothly, without errors in syntax and logic. WinRunner provides debugging
tools which make this process quick and easy.
You can:
• run the test line by line using the Step commands
• define breakpoints that enable you to stop running the test at a specified line or
function in the test script
• monitor the values of variables and expressions using the Watch List
When you debug a test script, you should run your test in Debug mode. (To run a
test in Debug mode, select Debug from the Run Mode list on the Standard
toolbar.) The test results are saved in a debug directory. Each time you run the
test in Debug mode, WinRunner overwrites the previous debug results.
In this exercise you will control the test run using the Step command. If any error
messages appear, examine the test script and try to fix the problem.
1 Select Debug mode from the Run Mode list on the Standard toolbar.
Debug mode will remain in effect until you select a different mode.
2 Place the execution marker –> next to the first line in the test script.
Click in the left margin, next to the first line in the test script.
3 Choose Run > Step or click the Step button to run the first line in the test script.
WinRunner runs the first line of the test.
4 Use the Step button to run the entire test, line by line.
Click the Step button to run each line of the test script. Note that your mouse pointer may sometimes move to the flight application as it clicks on objects during the test run.
5 Click Stop.
Click the Stop button to tell WinRunner that you have completed the Debug test run.
6 Review the test results in the WinRunner Test Results window.
When you run the test in Debug mode, the test results do not open automatically.
Choose Tools > Test Results or click the Test Results button. The WinRunner
Test Results window displays the results of the Debug test run.
7 Close the Test Results window.
Choose File > Exit.
8 Exit the Flight Reservation application.
Choose File > Exit.

Understanding tl_step

2007-03-12T02:52:00.001-07:00

Understanding tl_step
In most cases when you run a test, WinRunner reports an overall test result of
pass or fail. By adding tl_step statements to your test script, you can determine
whether a particular operation within the test passed or failed, and send a
message to the report.
For example:
tl_step ("total", 1, "Total is incorrect.");
total is the name you assign to this operation.
1 causes WinRunner to report that the operation failed. If you use 0, WinRunner
reports that the operation passed.
Total is incorrect is the message sent to the report. You can write any message
that will make the test results meaningful.

Adding Logic to the Test Script

2007-03-12T02:47:00.000-07:00

Adding Logic to the Test Script

In this exercise you will program decision-making logic into the test script using
an if/else statement. This enables the test to:
• check that the total is equal to the number of tickets ordered multiplied by the
price per ticket
• report whether the total is correct or incorrect
1 Place the cursor below the last edit_get_text statement in the lesson7
script.
2 Add the following statements to the test script exactly as they appear
below. Note that the tabs or spaces at the beginning of the second and
fourth lines are optional.
if (tickets*price == total)
tl_step ("total", 0, "Total is correct.");
else
tl_step ("total", 1, "Total is incorrect.");
In plain English these statements mean: "If tickets multiplied by price equals
total, report that the total is correct, otherwise (else) report that the total is
incorrect."

3 Add a comment to describe what this section of the script will do.
Place the cursor above the if statement you added in the previous step. Choose
Edit > Comment. After the # sign, type: check that the total ticket price is
calculated correctly.
4 Save the test.
Choose File > Save or click the Save button.

Using the Function Generator to Insert Functions

2007-03-12T02:42:00.000-07:00

Using the Function Generator to Insert Functions

You are now ready to add functions to the test script which query the # Tickets,
Ticket Price, and Total fields in the Fax Order dialog box.
1 Insert a blank line above the button_press ("Cancel"); statement and place
the cursor at the beginning of this line.
2 Open the Fax Order dialog box.
Choose File > Fax Order in the Flight Reservation application.
3 Query the # Tickets field.
Choose Create > Insert Function > For Object/Window or click the
Insert Function for Object/Window button on the User toolbar. Use the
pointer to click the # Tickets field.
The Function Generator opens and suggests the edit_get_text function.

This function reads the text in the # Tickets field and assigns it to a variable. The
default variable name is text. Change the variable name, text, to tickets by typing
in the field:

edit_get_text("# Tickets:",tickets);

Click Paste to add the function to the test script.
4 Query the Ticket Price field.
Choose Create > Insert Function > For Object/Window or click the
Insert Function for Object/Window button on the User toolbar. Use the
pointer to click the Ticket Price field.
The Function Generator opens and suggests the edit_get_text function.
Change the name of the text variable to price:
edit_get_text("Ticket Price:",price);
Click Paste to add the function to the test script.
5 Query the Total field.
Choose Create > Insert Function > For Object/Window or click the
Insert Function For Object/Window button on the User toolbar. Use the
pointer to click the Total field.
The Function Generator opens and suggests the edit_get_text function.
Change the name of the text variable to total:

edit_get_text("Total:",total);

Click Paste to add the function to the test script.

6 Close the Fax Order dialog box.
Click Cancel to close the dialog box in the Flight Reservation application.
7 Save the test.
Choose File > Save or click the Save button.
8 If you are working in the Global GUI Map File mode, save the new objects
to the GUI map.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Choose File >
Save. Click Yes to add the new object or new window to your GUI map. A
WinRunner message box opens. Click OK. Choose File > Exit to close the GUI
Map Editor.

Recording a Basic Test Script

2007-03-12T02:40:00.000-07:00

Recording a Basic Test Script
Start by recording the process of opening an order in the Flight Reservation
application and opening the Fax Order dialog box.
1 Start WinRunner and open a new test.
If WinRunner is not already open, choose Programs > WinRunner >
WinRunner on the Start menu. If the Welcome window is open, click the New
Test button. Otherwise, choose File > New. A new test window opens.
2 Start the Flight Reservation application and log in.
Choose Programs > WinRunner > Sample Applications > Flight 1A on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Reposition the Flight Reservation application and WinRunner so
that they are both clearly visible on your desktop.
3 Start recording in Context Sensitive mode.
Choose Create > Record—Context Sensitive or click the Record button on the
toolbar.
4 Open order #4.
In the Flight Reservation application, choose File > Open Order. In the
Open Order dialog box, select the Order No. check box and type "4" in the
adjacent box. Click OK to open the order.
5 Open the Fax Order dialog box.
Choose File > Fax Order.
6 Click Cancel to close the dialog box.
7 Stop recording.
Choose Create > Stop Recording or click the Stop button.
8 Save the test.
Choose File > Save or click the Save button. Save the test as lesson7 in a
convenient location on your hard drive. Click Save to close the Save Test dialog
box.
9 If you are working in the Global GUI Map File mode, save the new objects
to the GUI map.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Choose File >
Save. Click Yes or OK to add the new object or new window to your GUI map.
Choose File > Exit to close the GUI Map Editor.

How Do You Program Tests with TSL?

2007-03-12T02:39:00.000-07:00

How Do You Program Tests with TSL?
When you record a test, WinRunner generates TSL statements in a test script
each time you click a GUI object or type on the keyboard. In addition to the
recorded TSL functions, TSL includes many other built-in functions which can
increase the power and flexibility of your tests. You can quickly add these
functions to a test script using WinRunner’s visual programming tool, the Function
Generator. All functions located in the Function Generator are explained in the
TSL Online Reference and the TSL Reference Guide.
The Function Generator enables you to add TSL functions in two ways:
• You can point to a GUI object and let WinRunner "suggest" an appropriate
function. You can then insert this function into the test script.
• You can select a function from a list. Functions appear by category and
alphabetically.
You can further enhance your test scripts by adding logic. Simply type
programming elements such as conditional statements, loops, and arithmetic
operators directly into the test window.

Programming Tests with TSL

2007-03-12T02:38:00.000-07:00

Programming Tests with TSL

This lesson:
• shows you how to use visual programming to add functions to your recorded test
scripts
• shows you how to add decision-making logic to a test script
• helps you debug a test script
• lets you run a test on a new version of an application and analyze the results

Bitmap Checkpoint Tips

2007-03-12T02:34:00.000-07:00

Bitmap Checkpoint Tips

• To capture an area, choose Create > Bitmap Checkpoint > For Screen Area or
click the Bitmap Checkpoint for Screen Area button on the User toolbar. (To
see this menu command, a test must be open. Otherwise it is inactive.) Use the
crosshairs pointer to mark the area that you want WinRunner to capture.
WinRunner inserts a win_check_bitmap statement into your test script. This
statement includes additional parameters that define the position (x- and ycoordinates)
and size (width and height) of the area.

• For overnight test runs, you can instruct WinRunner not to display a message
when a bitmap mismatch is detected. Choose Settings > General Options. In
the General Options dialog box, click the Run tab and clear the Break when
verification fails check box. This enables the test to run unattended.

• When running a test that includes bitmap checkpoints, make sure that the screen
display settings are the same as when the test script was created. If the screen
settings are different, WinRunner will report a bitmap mismatch.

• If you want to create new expected results for a bitmap checkpoint, run the test
in Update mode. WinRunner overwrites the existing expected bitmaps with new
expected bitmaps captured during the Update run.

Running the Test on a New Version

2007-03-12T02:31:00.000-07:00

Running the Test on a New Version

You can now run the test on a new version of the Flight Reservation application.
1 Close Flight Reservation 1A.
Choose File > Exit.
2 Start Flight Reservation 1B.
Choose Programs > WinRunner > Sample Applications > Flight 1B on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Reposition the Flight Reservation application and WinRunner so
that they are both clearly visible on your desktop.
3 Make sure that lesson6 is the active test.
Click in the lesson6 test window.
4 Check that Verify mode is selected in the Standard toolbar.
5 Choose Run from Top.
Choose Run > Run from Top, or click the Run from Top button. The Run Test
dialog box opens. Accept the default test run name "res1." Make sure that the
Display test results at end of run check box is selected.
6 Run the test.
Click OK. The test run begins.

If a mismatch is detected at a bitmap checkpoint, click Continue in the message
window.
7 Review the results.
When the test run is completed, the test results appear in the WinRunner Test Results window.

8 Close the Test Results window.
Choose File > Exit to close the Test Results window.
9 Close the lesson6 test.
Choose File > Close.
10 Close version 1B of the Flight Reservation application.
Choose File > Exit.

Viewing Expected Results

2007-03-12T02:26:00.000-07:00

Viewing Expected Results

You can now view the expected results of the lesson6 test.
1 Open the WinRunner Test Results window.
Choose Tools > Test Results or click the Test Results button. The Test Results
window opens.
2 View the captured bitmaps.
In the test log section, double-click the first "capture bitmap" event, or select it
and click the Display button.

Next, double-click the second "capture bitmap" event, or select it and click the
Display button.

3 Close the Test Results window.
Close the bitmaps and choose File > Exit to close the Test Results window.

Adding Bitmap Checkpoints to a Test Script

2007-03-12T02:20:00.000-07:00

Adding Bitmap Checkpoints to a Test Script
In this exercise you will test the Agent Signature box in the Fax Order dialog box.
You will use a bitmap checkpoint to check that you can sign your name in the box.
Then you will use another bitmap checkpoint to check that the box clears when
you click the Clear Signature button.
1 Start WinRunner and open a new test.
If WinRunner is not already open, choose Programs > WinRunner >
WinRunner on the Start menu. If the Welcome window is open, click the New
Test button. Otherwise, choose File > New. A new test window opens.
2 Start the Flight Reservation application and log in.
Choose Programs > WinRunner > Sample Applications > Flight 1A on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Reposition the Flight Reservation application and WinRunner so
that they are both clearly visible on your desktop.
3 Start recording in Context Sensitive mode.
Choose Create > Record—Context Sensitive or click the Record button on the
toolbar.
4 Open order #6.
In the Flight Reservation application, choose File > Open Order. In the Open
Order dialog box, select the Order No. check box and type "6" in the adjacent
box. Click OK to open the order.
5 Open the Fax Order dialog box.
Choose File > Fax Order.
6 Enter a 10-digit fax number in the Fax Number box.
You do not need to type in parentheses or dashes.
7 Move the Fax Order dialog box.
Position the dialog box so that it least obscures the Flight Reservation window.
8 Switch to Analog mode.
Press F2 on your keyboard or click the Record button to switch to Analog mode.
9 Sign your name in the Agent Signature box.
10 Switch back to Context Sensitive mode.
Press F2 on your keyboard or click the Record button to switch back to Context
Sensitive mode.
11 Insert a bitmap checkpoint that checks your signature.
Choose Create > Bitmap Checkpoint > For Object/Window or click the
Bitmap Checkpoint for Object/Window button on the User toolbar.
Use the pointer to click the Agent Signature box. WinRunner captures the
bitmap and inserts an obj_check_bitmap statement into the test script.
12 Click the Clear Signature button.
The signature is cleared from the Agent Signature box.
13 Insert another bitmap checkpoint that checks the Agent Signature box.
Choose Create > Bitmap Checkpoint > For Object/Window or click the
Bitmap Checkpoint for Object/Window button on the User toolbar.
Use the pointer to click the Agent Signature box. WinRunner captures a
bitmap and inserts an obj_check_bitmap statement into the test script.
14 Click the Cancel button on the Fax Order dialog box.
15 Stop recording.
Choose Create > Stop Recording or click the Stop button.
16 Save the test.
Choose File > Save or click the Save button. Save the test as lesson6 in a
convenient location on your hard drive. Click Save to close the Save Test dialog
box.
17 If you are working in the Global GUI Map File mode, save the new objects
to the GUI map.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Choose File >
Save. Click Yes or OK to add the new object or new window to your GUI map.
Choose File > Exit to close the GUI Map Editor.

How Do You Check a Bitmap?

2007-03-12T02:16:00.000-07:00

How Do You Check a Bitmap?
If your application contains bitmap areas, such as drawings or graphs, you can
check these areas using a bitmap checkpoint. A bitmap checkpoint compares
captured bitmap images pixel by pixel.
To create a bitmap checkpoint, you indicate an area, window, or object that you
want to check. For example:

WinRunner captures a bitmap image and saves it as expected results. It then
inserts an obj_check_bitmap statement into the test script if it captures an
object, or a win_check_bitmap statement if it captures an area or window.
When you run the test on a new version of the application, WinRunner compares
the expected bitmap with the actual bitmap in the application. If any differences
are detected, you can view a picture of the differences from the Test Results
window.

Checking Bitmaps

2007-03-12T02:15:00.000-07:00

Checking Bitmaps

This lesson:
• explains how to check bitmap images in your application
• shows you how to create a test that checks bitmaps
• shows you how to run the test in order to compare bitmaps in different versions
of an application
• helps you analyze the results

GUI Checkpoint Tips

2007-03-12T01:23:00.000-07:00

GUI Checkpoint Tips

• You can create a single GUI checkpoint in your test that checks several or all
objects in a window. Choose Create > GUI Checkpoint > For Multiple Objects.
The Create GUI Checkpoint dialog box opens, which enables you to add objects
to the GUI checkpoint and to specify the checks you want to perform on those
objects. When you finish creating the checkpoint, WinRunner inserts a
win_check_gui statement into the test script, which includes a checklist for the
selected objects.
• For overnight test runs, you can instruct WinRunner not to display a message
when a GUI mismatch is detected. Choose Settings > General Options. In the
General Options dialog box, click the Run tab, and clear the Break when
verification fails check box. This enables the test to run without interruption.

For more information on setting test run options, refer to the "Setting Global
Testing Options" and "Setting Testing Options from a Test Script" chapters in the
WinRunner User’s Guide.

• If you want to create new expected results for a GUI checkpoint, run the test in
Update mode. WinRunner overwrites the existing expected GUI data with new
data captured during the Update run.

Running the Test on a New Version

2007-03-12T01:05:00.000-07:00

Running the Test on a New Version

In this exercise you will run the lesson5 test on a new version of the Flight
Reservation application in order to check the behavior of its GUI objects.
1 Open version 1B of the Flight Reservation application.
Choose Programs > WinRunner > Sample Applications > Flight 1B on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Position the Flight Reservation application and WinRunner so that
they are both clearly visible on your desktop.
2 Make sure that lesson5 is the active test.
Click in the lesson5 test window in WinRunner.
3 Check that Verify mode is selected in the toolbar.
4 Choose Run from Top.
Choose Run > Run from Top, or click the Run from Top button. The Run Test
dialog box opens. Accept the default test run name "res2." Make sure that the
Display Test Results at End of Run check box is selected.
5 Run the test.
Click OK. The test run begins. This process might take a while.
If a mismatch is detected at a GUI checkpoint, click Continue in the message
window.

6 Review the results.
When the test run is completed, the test results appear in the WinRunner Test
Results window. In the test log section, one "end GUI checkpoint" statement
appears in red and its Result field lists "mismatch." This indicates that one or
more of the checks performed on the object failed.
Double-click the red "end GUI checkpoint" event to view detailed results of the
failed check. The GUI Checkpoint Results dialog box opens. Select Customer
Name to display the dialog box as follows:

7 Close the Test Results window.
Click OK in the GUI Checkpoint Results dialog box and then choose File > Exit
to close the Test Results window.
8 Close the lesson5 test.
Choose File > Close.
9 Close version 1B of the Flight Reservation application.
Choose File > Exit.

Running the Test

2007-03-12T01:00:00.000-07:00

Running the Test

You will now run the lesson5 test in order to verify that the test runs smoothly.
1 Make sure that the Flight Reservation application is open on your desktop.
2 In WinRunner, check that Verify mode is selected in the Standard toolbar.
3 Choose Run from Top.
Choose Run > Run from Top, or click the Run from Top button. The Run Test
dialog box opens. Accept the default test run name "res1." Make sure that the
Display test results at end of run check box is selected.
4 Run the test.
Click OK in the Run Test dialog box.
5 Review the results.
When the test run is completed, the test results appear in the WinRunner Test
Results window. In the test log section all "end GUI checkpoint" events should
appear in green (indicating success).

Double-click an end GUI checkpoint event to view detailed results of that GUI
checkpoint. The GUI Checkpoint Results dialog box opens. Select Customer
Name to display the dialog box as follows:

6 Close the test results.
Click OK to close the GUI Checkpoint Results dialog box. Then choose File >
Exit to close the Test Results window.
7 Close the Flight Reservation application.
Choose File > Exit.

Adding GUI Checkpoints to a Test Script

2007-03-12T00:52:00.001-07:00

Adding GUI Checkpoints to a Test Script

In this exercise you will check that objects in the Flight Reservation Open Order
dialog box function properly when you open an existing order.
1 Start WinRunner and open a new test.
If WinRunner is not already open, choose Programs > WinRunner >
WinRunner on the Start menu. If the Welcome window is open, click the New
Test button. Otherwise, choose File > New. A new test window opens.
2 Start the Flight Reservation application and log in.
Choose Programs > WinRunner > Sample Applications > Flight 1A on the
Start menu. In the Login window, type your name and the password mercury,
and click OK. Reposition the Flight Reservation application and WinRunner so
that they are both clearly visible on your desktop.
3 Start recording in Context Sensitive mode.
Choose Create > Record—Context Sensitive or click the Record button on the
toolbar.

4 Open the Open Order dialog box.
Choose File > Open Order in the Flight Reservation application.

5 Create a GUI checkpoint for the Order No. check box.
Choose Create > GUI Checkpoint > For Object/Window, or click the GUI
Checkpoint for Object/Window button on the User toolbar.

Use the pointer to double-click the Order No. check box. The Check GUI
dialog box opens and displays the available checks. Note that this dialog box
does not open if you only single-clicked the Order No. check box. Accept the
default check, "State." This check captures the current state (off) of the check
box and stores it as expected results.
Click OK in the Check GUI dialog box to insert the checkpoint into the test script.
The checkpoint appears as an obj_check_gui statement.
6 Enter "4" as the Order No.
Select the Order No. check box and type in 4 in the Order No. text box.
7 Create another GUI checkpoint for the Order No. check box.
Choose Create > GUI Checkpoint > For Object/Window or click the
GUI Checkpoint for Object/Window button on the User toolbar.
Use the pointer to single-click the Order No. check box. WinRunner
immediately inserts a checkpoint into the test script (an obj_check_gui
statement) that checks the default check "State." (Use this shortcut when you
want to use only the default check for an object.) This check captures the current
state (on) of the check box and stores it as expected results.

8 Create a GUI checkpoint for the Customer Name check box.
Choose Create > GUI Checkpoint > For Object/Window or click the
GUI Checkpoint for Object/Window button on the User toolbar.
Use the pointer to double-click the Customer Name check box. The Check
GUI dialog box opens and displays the available checks. Accept the default
check "State" and select "Enabled" as an additional check. The State check
captures the current state (off) of the check box; the Enabled check captures the
current condition (off) of the check box.
Click OK in the Check GUI dialog box to insert the checkpoint into the test script.
The checkpoint appears as an obj_check_gui statement.
9 Click OK in the Open Order dialog box to open the order.
10 Stop recording.
Choose Create > Stop Recording or click the Stop button.

11 Save the test.
Choose File > Save or click the Save button. Save the test as lesson5 in a
convenient location on your hard drive. Click Save to close the Save Test dialog
box.
12 If you are working in the Global GUI Map File mode, save the new objects
to the GUI map.
Choose Tools > GUI Map Editor. Choose View > GUI Files. Choose File >
Save. Click Yes or OK to add the new object or new window to your GUI map.
Choose File > Exit to close the GUI Map Editor.

Adding GUI Checkpoints to a Test Script

2007-03-12T00:52:00.000-07:00

Adding GUI Checkpoints to a Test Script

4 Open the Open Order dialog box.
Choose File > Open Order in the Flight Reservation application.

5 Create a GUI checkpoint for the Order No. check box.
Choose Create > GUI Checkpoint > For Object/Window, or click the GUI
Checkpoint for Object/Window button on the User toolbar.

How Do You Check GUI Objects?

2007-03-12T00:47:00.000-07:00

How Do You Check GUI Objects?
When working with an application, you can determine whether it is functioning
properly according to the behavior of its GUI objects. If a GUI object does not
respond to input as expected, a defect probably exists somewhere in the
application’s code.
You check GUI objects by creating GUI checkpoints. A GUI checkpoint examines
the behavior of an object’s properties. For example, you can check:

To create a GUI checkpoint for a single object, you first point to it in your
application. If you single-click the object, a checklist with the default checks for
the object you selected is inserted into your test script. A checklist contains
information about the GUI object and the selected properties to check. If you
double-click the object, the Check GUI dialog box opens and displays the object
you selected. Select the properties you want to check, and click OK to insert a
checklist for the object into your test script.

Whether you choose to check an object’s default properties or you specify the
properties of an object you want to check, WinRunner captures the current
values of those properties and saves this information as expected results. It then
inserts an obj_check_gui statement into the test script if you are checking an
object, or a win_check_gui statement if you are checking a window.
When you run this test on a new version of the application, WinRunner compares
the object’s expected behavior with its actual behavior in the application.

Checking GUI Objects

2007-03-12T00:46:00.000-07:00

Checking GUI Objects

This lesson:
• explains how to check the behavior of GUI objects
• shows you how to create a test that checks GUI objects
• shows you how to run the test on different versions of an application and
examine the results

Running the Synchronized Test

2007-03-12T00:33:00.000-07:00

Running the Synchronized Test

In this exercise you will run the synchronized test script and examine the test
results.
1 Confirm that the lesson4 test window is active in WinRunner.
Click the title bar of the lesson4 test window.
2 Confirm that Verify mode is selected in the Standard toolbar.
Verify mode will stay in effect until you choose a different mode.
3 Choose Run from Top.
Choose Run > Run from Top or click the Run from Top button. The Run Test
dialog box opens. Accept the default name "res2." Make sure that the Display
test results at end of run check box is selected.
4 Run the test.
Click OK in the Run Test dialog box. WinRunner starts running the test from the
first line in the script.
Watch how WinRunner waits for the "Insert Done" message to appear in the
status bar.

5 Review the results.
When the test run is completed, the test results appear in the WinRunner Test
Results window. Note that a "wait for bitmap" event appears in green in the test
log section. This indicates that synchronization was performed successfully. You
can double-click this event to see a bitmap image of the status bar displaying the
"Insert Done" message.

6 Close the Test Results window.
Choose File > Exit.
7 Close the lesson4 test.
Choose File > Close in WinRunner.
8 Close the Flight Reservation application.
Choose File > Exit.
9 Change the timeout value back to 10000 milliseconds (10 seconds).
Choose Settings > General Options to open the General Options dialog box.
Click the Run tab. In the Timeout for Checkpoints and CS statements box,
change the current value to "10000". Click OK to close the dialog box.
To learn about additional synchronization methods, read the "Synchronizing the
Test Run" chapter in your WinRunner User’s Guide.

Synchronizing the Test

2007-03-08T23:07:00.000-08:00

Synchronizing the Test
In this exercise you will insert a synchronization point into the lesson4 test script. The synchronization point will capture a bitmap image of the "Insert Done" message in the status bar. Later on when you run the test, WinRunner will wait for the "Insert Done" message to appear before it attempts to click the Delete Order button.
1 Make sure that the lesson4 test window is active in WinRunner. Click the title bar of the lesson4 test window.
2 Place the cursor at the point where you want to synchronize the test. Add a blank line below the button_press ("Insert Order"); statement. Place the cursor at the beginning of the blank line.
3 Synchronize the test so that it waits for the "Insert Done" message to appear in the status bar. Choose Create > Synchronization Point > For Object/Window Bitmap or click the Synchronization Point for Object/Window Bitmap button on the User toolbar.
Use the pointer to click the message "Insert Done" in the Flight Reservation window. WinRunner automatically inserts an obj_wait_bitmap synchronization point into the test script. This statement instructs WinRunner to wait 1 second for the "Insert Done" message to appear in the status bar.
4 Manually change the 1 second wait in the script to a 10 second wait. The one-second wait that was inserted in the previous step isn’t long enough, so find the statement:
obj_wait_bitmap("Insert Done...", "Img1", 1);
and change the 1 at the end of the statement to a 10, to indicate a 10 second wait.
5 Save the test. Choose File > Save or click the Save button.
6 If you are working in the Global GUI Map File mode, save the new objects to the GUI map.
During this test you recorded an object in the Flight Reservation window (the Insert Done bitmap). You should save this object in your GUI map.
To save a new object from a window that already exists in your GUI map, choose
Tools > GUI Map Editor.
Choose View > GUI Files.
Note that the new object is displayed in the L0 GUI map file. Choose File > Save. The New Windows dialog prompts you to save the new window to the existing map file or to a new one. Click OK to add the new window to your GUI map.
Choose File > Exit to close the GUI Map Editor.

Identifying a Synchronization Problem

2007-03-08T23:05:00.000-08:00

Identifying a Synchronization Problem

You are now ready to run the lesson4 test. As the test runs, look for a synchronization problem.

1 Make sure that the lesson4 test window is active in WinRunner. Click the title bar of the lesson4 test window.

2 Choose Run from Top. Choose Run > Run from Top or click the Run from Top button. The Run Test dialog box opens. Accept the default test run name "res1." Make sure that the Display test results at end of run check box is selected.

3 Run the test. Click OK in the Run Test dialog box. WinRunner starts running the test. Watch what happens when WinRunner attempts to click the Delete button.

4 Click Pause in the WinRunner message window. WinRunner fails to click the Delete Order button because the button is still disabled. This error occurred because WinRunner did not wait until the Insert Order operation was completed. Note that the execution arrow has paused opposite the command to click the Delete Order button.

Changing the Synchronization Setting

2007-03-08T23:03:00.000-08:00

Changing the Synchronization Setting

The default interval that WinRunner waits for an application to respond to input is 10 seconds. In the next exercise you will identify a synchronization problem and add a synchronization point to solve it. To run the test you have just recorded with a synchronization problem, you need to change the default synchronization setting.

1 Open the General Options dialog box. Choose Settings > General Options.

2 Click the Run tab.

3 Change the value to 1000 milliseconds (1 second). In the Timeout for Checkpoints and CS statements box, change the value to "1000".

4 Click OK to close the dialog box.

Creating a Test

2007-03-08T23:01:00.000-08:00

Creating a Test

In this first exercise you will create a test that opens a new order in the Flight Reservation application and inserts the order into a database.

1 Start WinRunner and open a new test. If WinRunner is not already open, choose Programs > WinRunner > WinRunner on the Start menu. If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A new test window opens.

2 Start the Flight Reservation application and log in. Choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu. In the Login window, type your name and the password mercury, and click OK. Reposition the Flight Reservation application and WinRunner so that they are both clearly visible on your desktop.

3 Start recording in Context Sensitive mode. Choose Create > Record—Context Sensitive or click the Record button on the toolbar. WinRunner will start recording the test.

4 Create a new order. Choose File > New Order in the Flight Reservation application.

6 Insert the order into the database. Click the Insert Order button. When the insertion is complete, the "Insert Done" message appears in the status bar.

7 Delete the order. Click the Delete Order button and click Yes in the message window to confirm the deletion.

8 Stop recording. Choose Create > Stop Recording or click the Stop button.

9 Save the test. Choose File > Save. Save the test as lesson4 in a convenient location on your hard drive. Click Save to close the Save Test dialog box.

When Should You Synchronize?

2007-03-08T22:59:00.000-08:00

When Should You Synchronize?
When you run tests, your application may not always respond to input with the same speed. For example, it might take a few seconds:

• to retrieve information from a database

• for a window to pop up

• for a progress bar to reach 100%

• for a status message to appear

WinRunner waits a set time interval for an application to respond to input. The default wait interval is up to 10 seconds. If the application responds slowly during a test run, WinRunner’s default wait time may not be sufficient, and the test run may unexpectedly fail.
If you discover a synchronization problem between the test and your application, you can either:

• Increase the default time that WinRunner waits. To do so, you change the value of the Timeout for Checkpoints and CS Statements option in the Run tab of the General Options dialog box (Settings > General Options). This method affects all your tests and slows down many other Context Sensitive operations.

• Insert a synchronization point into the test script at the exact point where the problem occurs. A synchronization point tells WinRunner to pause the test run in order to wait for a specified response in the application. This is the recommended method for synchronizing a test with your application.

In the following exercises you will:
. create a test that opens a new order in the Flight Reservation application and inserts the order into the database
. change the synchronization settings
. identify a synchronization problem
. synchronize the test
. run the synchronized test

Synchronizing Tests

2007-03-08T22:58:00.000-08:00

Synchronizing Tests

This lesson:
• describes when you should synchronize a test
• shows you how to synchronize a test
• shows you how to run the test and analyze the results

Recording Tips

2007-03-08T22:56:00.000-08:00

Recording Tips
• Before starting to record, you should close applications that are not required for the test.

• Create the test so that it ends where it started. For example, if the test opens an application, make sure that it also closes the application at the end of the test run. This ensures that WinRunner is prepared to run repeated executions of the same test.

• When recording in Analog mode, avoid holding down the mouse button if this results in a repeated action. For example, do not hold down the mouse button to scroll a window. Instead, scroll by clicking the scrollbar arrow repeatedly. This enables WinRunner to accurately run the test.

• Before switching from Context Sensitive mode to Analog mode during a recording session, always move the current window to a new position on the desktop. This ensures that when you run the test, the mouse pointer will reach the correct areas of the window during the Analog portion of the test.

• When recording, if you click a non-standard GUI object, WinRunner generates a generic obj_mouse_click statement in the test script. For example, if you click a graph object, it records: obj_mouse_click (GS_Drawing, 8, 53, LEFT); If your application contains a non-standard GUI object that behaves like a standard GUI object, you can map this object to a standard object class so that WinRunner will record more intuitive statements in the test script. For more information refer to the "Configuring the GUI Map" chapter in your WinRunner User’s Guide.

• If you are working in the Global GUI Map File mode, then if you click an object whose description was not previously learned, WinRunner learns a description of the object and adds it to a temporary GUI map file. For more information, refer to the "Working in the Global GUI Map File Mode" chapter in your WinRunner User’s Guide.

• To easily switch between Context Sensitive and Analog modes, press F2.

• If you are working in Global GUI Map File mode, always check whether new windows or objects have been added to the temporary GUI map before you close WinRunner. If new objects have been added, save them to the appropriate GUI map file for your test.

Analyzing Test Results

2007-03-08T22:51:00.000-08:00

Analyzing Test Results

Once a test run is completed, you can immediately review the test results in the WinRunner Test Results window. WinRunner color-codes results (green indicates passed and red indicates failed) so that you can quickly draw conclusions about the success or failure of the test.

1 Make sure that the WinRunner Test Results window is open and displays the test results.

If the WinRunner Test Results window is not currently open, first click the test window to activate it, and then choose Tools > Test Results or click the Test Results button.

1 Displays the name of the current test.

2 Shows the current results directory name.

3 Shows whether a test run passed or failed.

4 Includes general information about the test run such as date, operator name, and total run time. To view these details, double click the Information icon.

5 The test log section lists the major events that occurred during the test run. It also lists the test script line at which each event occurred.

2 Review the results.
3 Close the Test Results window. Choose File > Exit in the WinRunner Test Results window.
4 Close the test. Choose File > Close.
5 Close the Flight Reservation application. Choose File > Exit.

Running the Test

2007-03-08T22:48:00.000-08:00

Running the Test

You are now ready to run your recorded test script and to analyze the test results. WinRunner provides three modes for running tests. You select a mode from the toolbar.

• Use Verify mode when running a test to check the behavior of your application, and when you want to save the test results.

• Use Debug mode when you want to check that the test script runs smoothly without errors in syntax. See Lesson 7 for more information.

• Use Update mode when you want to create new expected results for a GUI checkpoint or bitmap checkpoint. See Lessons 5 and 6 for more information.

To run the test:

1 Check that WinRunner and the main window of the Flight Reservation application are open on your desktop.

2 Make sure that the lesson3 test window is active in WinRunner. Click the title bar of the lesson3 test window. If the test is not already open, choose File > Open and select the test.

3 Make sure the main window of the Flight Reservation application is active. If any dialog boxes are open, close them.

4 Make sure that Verify mode is selected in the toolbar.

5 Choose Run from Top. Choose Run > Run from Top or click the Run from Top button. The Run Test dialog box opens.

6 Choose a Test Run name. Define the name of the folder in which WinRunner will store the results of the test. Accept the default folder name "res1." The results folder will be stored within the test’s folder. Note the Display Test Results at end of run check box at the bottom of the dialog box. When this check box is selected, WinRunner automatically displays the test results when the test run is completed. Make sure that this check box is selected.

7 Run the test. Click OK in the Run Test dialog box. WinRunner immediately begins running the test. Watch how WinRunner opens each window in the Flight Reservation application.

8 Review the test results. When the test run is completed, the test results automatically appear in the WinRunner Test Results window. See the next section to learn how to analyze the test results.

Recording in Analog Mode

2007-03-08T22:42:00.000-08:00

Recording in Analog Mode
In this exercise you will test the process of sending a fax. You will start recording in Context Sensitive mode, switch to Analog mode in order to add a signature to the fax, and then switch back to Context Sensitive mode.

1 In the lesson3 test, place the cursor below the last line of the script. You will add the new test segment to the lesson3 test. If the test is not already open, choose File > Open and select the test. In the lesson3 test window, place the cursor below the last line of the test.

2 Start Recording in Context Sensitive mode. Choose Create > Record—Context Sensitive or click the Record button on the toolbar.

edit_set ("Edit", "3");

For more information about the different ways in which WinRunner records keyboard input, choose Help > TSL Online Reference.

3 Open the Fax Order form and fill in a fax number. In the Flight Reservation application, choose File > Fax Order. In the Fax Number box, type "4155551234".

4 Select the Send Signature with Order check box.

5 Sign the fax in Context Sensitive mode. Use the mouse to sign your name in the Agent Signature box.
Watch how WinRunner records your signature.

6 Clear the signature. Click the Clear Signature button.

7 Move the Fax Order window to a different position on your desktop. Before switching to Analog mode, reposition the window in which you are working.

8 Sign the fax again in Analog mode. Press F2 on your keyboard or click the Record button again to switch to Analog mode. Sign your name in the Agent Signature box. Watch how WinRunner records your signature.

9 Switch back to Context Sensitive mode and send the fax. Press F2 or click the Record button to switch back to Context Sensitive mode. Click Send. The application will simulate the process of sending the fax.

10 Stop Recording. Choose Create > Stop Recording or click the Stop button.

11 Save the test. Choose File > Save or click the Save button.

12 If you are working in the Global GUI Map File mode, save the new objects to the GUI map. When you ran the RapidTest Script wizard in the previous lesson, it learned all the windows and objects it was able to access. The fax order dialog box, however, can be open only when an order has already been opened, as you did in step 5 of Recording a Context Sensitive Test on page 38. Therefore, when you opened the fax order dialog box in step 3 above, WinRunner added the new window, and the objects you recorded within that window, to the temporary GUI map. The temporary GUI map is discarded whenever you close WinRunner, so it is important to save new windows and objects to the GUI map file that your test uses.

Choose Tools > GUI Map Editor. Choose View > GUI Files. Note that the Fax Order No. 3 window is displayed in the L0 GUI map file. Choose File > Save. The New Windows dialog box opens. Confirm that the flight1a.GUI file is displayed in the Loaded GUI Files box. Click OK. The Fax Order No. 3 window and all objects under that window are moved from the temporary GUI map to the flight1a.GUI map file. Choose File > Exit to close the GUI Map Editor.

Understanding the Test Script

2007-03-08T22:40:00.000-08:00

Understanding the Test Script
In the previous exercise, you recorded the process of opening a flight order in the Flight Reservation application. As you worked, WinRunner generated a test script similiar to the following:
# Flight Reservation set_window ("Flight Reservation", 3);
menu_select_item ("File;Open Order...");
# Open Order set_window ("Open Order", 1);
button_set ("Order No.", ON);
edit_set ("Edit_1", "3");
button_press ("OK");
As you can see, the recorded TSL statements describe the objects you selected and the actions you performed.
For example, when you selected a menu item, WinRunner generated a menu_select_item statement.
The following points will help you understand your test script:
• When you click an object, WinRunner assigns the object a logical name, which is usually the object’s text label. The logical name makes it easy for you to read the test script. For example, when you selected the Order No. check box, WinRunner recorded the following statement: button_set ("Order No.", ON); "Order No." is the object’s logical name.
• By default, WinRunner automatically adds a comment line each time you begin working in a new window so that your script is easier to read. For example, when you clicked on the Flight Reservation window, WinRunner generated the following comment line: # Flight Reservation
• WinRunner generates a set_window statement each time you begin working in a new window. The statements following a set_window statement perform operations on objects within that window. For example, when you opened the Open Order dialog box, WinRunner generated the following statement: set_window ("Open Order", 10);
• When you enter keyboard input, WinRunner generates a type, an obj_type, or an edit_set statement in the test script. For example, when you typed 3 in the Order Number box, WinRunner generated the following statement:

Recording a Context Sensitive Test

2007-03-08T22:31:00.000-08:00

Recording a Context Sensitive Test
In this exercise you will create a script that tests the process of opening an order in the Flight Reservation application. You will create the script by recording in Context Sensitive mode.

1 Start WinRunner.
If WinRunner is not already open, choose Programs > WinRunner > WinRunner on the Start menu.

2 Open a new test.
If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A new test window opens in WinRunner.

3 Start the Flight Reservation application and log in.
Choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu. In the Login window, type your name and the password mercury, and click OK. The name you type must be at least four characters long.

Position the Flight Reservation application and WinRunner so that they are both clearly visible on your desktop.

4 Start recording in Context Sensitive mode.
In WinRunner, choose Create > Record—Context Sensitive or click the Record button on the toolbar. From this point on, WinRunner records all mouse clicks and keyboard input. Note that the text, "Rec" appears in blue above the recording button. This indicates that you are recording in Context Sensitive mode. The status bar also informs you of your current recording mode.

5 Open order #3.
In the Flight Reservation application, choose File > Open Order. In the Open Order dialog box, select the Order No. check box. Type 3 in the adjacent box, and click OK. Watch how WinRunner generates a test script in the test window as you work.

6 Stop recording.
In WinRunner, choose Create > Stop Recording or click the Stop button on the toolbar.

7 Save the test.
Choose File > Save or click the Save button on the toolbar. Save the test as lesson3 in a convenient location on your hard drive. Click Save to close the Save Test dialog box.

Analog

2007-03-08T04:53:00.000-08:00

Analog

In Analog mode, WinRunner records the exact coordinates traveled by the mouse, as well as mouse clicks and keyboard input. For example, if you click the OK button in the Login window, WinRunner records statements that look like this:
When this statement is recorded... .......... it really means:
move_locator_track (1);
mouse track mtype ("-");
left mouse button press mtype ("+");
left mouse button release
When you run the test, WinRunner retraces the recorded movements using absolute screen coordinates. If your application is located in a different position on the desktop, or the user interface has changed, WinRunner is not able to execute the test correctly.
When choosing a record mode, consider the following points:

If you are testing an application that contains both GUI objects and bitmap areas, you can switch between modes as you record. This will be discussed later in the lesson.

Choosing a Record Mode

2007-03-08T04:50:00.000-08:00

Choosing a Record Mode
By recording, you can quickly create automated test scripts. You work with your application as usual, clicking objects with the mouse and entering keyboard input. WinRunner records your operations and generates statements in TSL, Mercury Interactive’s Test Script Language. These statements appear as a script in a WinRunner test window.
Before you begin recording a test, you should plan the main stages of the test and select the appropriate record mode. Two record modes are available: Context Sensitive and Analog.
Context Sensitive
Context Sensitive mode records your operations in terms of the GUI objects in your application. WinRunner identifies each object you click (such as a window, menu, list, or button), and the type of operation you perform (such as press, enable, move, or select).
For example, if you record a mouse click on the OK button in the Flight Reservation Login window, WinRunner records the following TSL statement in your test script:
button_press ("OK");
When you run the script, WinRunner reads the command, looks for the OK button, and presses it.

Recording Tests

2007-03-08T04:49:00.000-08:00

Recording Tests

This lesson:
• describes Context Sensitive and Analog record modes
• shows you how to record a test script
• helps you read the test script
• shows you how to run the recorded test and analyze the results

Using the RapidTest Script Wizard

2007-03-08T04:34:00.000-08:00

Using the RapidTest Script Wizard

If you choose the Global GUI Map File mode, the RapidTest Script wizard is usually the easiest and quickest way to start the testing process. The RapidTest Script wizard systematically opens the windows in your application and learns the description of every GUI object. The wizard stores this information in a GUI map file. To observe WinRunner’s learning process, use the RapidTest Script wizard on the Flight Reservation application.
1 Log in to the Flight Reservation application.
If the Login window is open, type your name in the Agent Name field, and mercury in the Password field and click OK. The name you type must be at least four characters long.
If the Login window is not already open on your desktop, choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu and then log in, as described in the previous paragraph.
2 Start WinRunner.
If WinRunner is not already open, choose Programs > WinRunner > WinRunner on the Start menu.
3 Open a new test.
If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A new test window opens in WinRunner.
4 Start the RapidTest Script wizard.
Choose Create > RapidTest Script Wizard. Click Next in the wizard’s Welcome screen to advance to the next screen.

5 Point to the application you want to test.
Click the button and then click anywhere in the Flight Reservation application. The application’s window name appears in the wizard’s Window Name box. Click Next.
6 Make sure that all the check boxes are cleared.
For the purposes of this exercise, confirm that all the check boxes are cleared. You will use the wizard only to learn the GUI of the Flight Reservation application. Click Next.
7 Accept the default navigation controls.
Navigation controls tell WinRunner which GUI objects are used to open windows. The Flight Reservation application uses the default navigation controls (... and > >) so you do not need to define additional controls. Click Next.
8 Set the learning flow to "Express."
The learning flow determines how WinRunner walks through your application. Two modes are available: Express and Comprehensive. Comprehensive mode lets you customize how the wizard learns GUI object descriptions. First-time WinRunner users should use Express mode. Click the Learn button. The wizard begins walking through the application, pulling down menus, opening windows, and learning object descriptions. This process takes a few minutes. If a pop-up message notifies you that an interface element is disabled, click the Continue button in the message box. If the wizard cannot close a window, it will ask you to show it how to close the window. Follow the directions on the screen.
9 Accept "No" in the Start Application screen.
You can choose to have WinRunner automatically open the Flight Reservation application each time you start WinRunner. Accept the default "No." Click Next.
10 Save the GUI information and a startup script.
The wizard saves the GUI information in a GUI map file. The wizard also creates a startup script. This script runs automatically each time you start WinRunner. It contains a command which loads the GUI map file so that WinRunner will be ready to test your application. Accept the default paths and file names or define different ones. Make sure that you have write permission for the selected folders. Click Next.
11 Click OK in the Congratulations screen.
The information WinRunner learned about the application is stored in a GUI map file.

Getting Started

2007-03-08T04:31:00.000-08:00

Getting Started
The remaining sections in this lesson can be performed only in the Global GUI Map File mode. If you choose to work in the GUI Map File per Test mode, change the mode setting as described above and proceed to lesson 3. If you choose to work in the Global GUI Map File mode, proceed to the section below on Using the RapidTest Script Wizard.

Setting Your Preferred GUI Map File Mode

2007-03-08T04:30:00.001-08:00

Setting Your Preferred GUI Map File Mode
By default, WinRunner is set to the Global GUI Map File mode. To change the mode to the GUI Map File per Test mode choose Settings > General Options, click the Environment tab, and select GUI Map File per Test. Click OK to close the dialog box.

The Global GUI Map File Mode

2007-03-08T04:29:00.000-08:00

The Global GUI Map File Mode
In the Global GUI Map File mode, you can use a single GUI map for a group of tests. When you work in the Global GUI Map File mode, you need to save the information that WinRunner learns about the properties into a GUI map file. When you run a test, you must load the appropriate GUI map file. If you are familiar with WinRunner or with testing, it is probably most efficient to work in the Global GUI Map File mode.

The GUI Map File per Test Mode

2007-03-08T04:28:00.000-08:00

The GUI Map File per Test Mode
In the GUI Map File per Test mode, WinRunner automatically creates a new GUI map file for every new test you create. WinRunner automatically saves and opens the GUI map file that corresponds to your test. If you are new to WinRunner or to testing, you may want to consider working in the GUI Map File per Test mode. In this mode, a GUI map file is created automatically every time you create a new test. The GUI map file that corresponds to your test is automatically saved whenever you save your test and automatically loaded whenever you open your test. This is the simplest mode for inexperienced testers and for ensuring that updated GUI Map files are saved and loaded.

Choosing a GUI Map Mode

2007-03-08T04:26:00.000-08:00

Choosing a GUI Map Mode
Before you start teaching WinRunner the GUI of an application, you should consider whether you want to organize your GUI map files in the GUI Map File per Test mode or the Global GUI Map File mode.

Spying on GUI Objects

2007-03-08T04:05:00.000-08:00

Spying on GUI Objects

To help you understand how WinRunner identifies GUI objects, examine the objects in the sample Flight Reservation application.
1 Start the Flight Reservation application.

Choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu. The Login window opens.

2 Start WinRunner.
Choose Programs > WinRunner > WinRunner on the Start menu. In the Welcome window, click the New Test button. If the Welcome window does not open, choose File > New.
3 Open the GUI Spy. This tool lets you "spy" on the properties of GUI objects.
Choose Tools > GUI Spy. The GUI Spy opens. Position the GUI Spy on the desktop so that both the Login window and the GUI Spy are clearly visible.

4 View the properties that provide a unique description of the OK button.
In the GUI Spy, click the Spy button. Move the pointer over objects in the Login window. Notice that each object flashes as you move the pointer over it, and the GUI Spy displays its properties. Place the pointer over the OK button and press Left Ctrl + F3. This freezes the OK button’s description in the GUI Spy.

5 Examine the properties of the OK button.
At the top of the dialog box, the GUI Spy displays the name of the window in which the object is located and the object’s logical name. In the Recorded tab, the property names and values that would be recorded are listed. For example, "label OK" indicates that the button has the text label "OK", and "class push_button" indicates that the button belongs to the push button object class. As you can see, WinRunner needs only a few properties to uniquely identify the object.
6 Take a few minutes to view the properties of other GUI objects in the Login window.
Click the Spy button and move the pointer over other GUI objects in the Login window. If you would like to view an expanded list of properties for each object, press Left Ctrl + F3 to stop the current Spy, and then click the All Standard tab.
7 Exit the GUI Spy.
Click Close.

How Does WinRunner Identify GUI Objects?

2007-03-08T04:00:00.000-08:00

How Does WinRunner Identify GUI Objects?
GUI applications are made up of GUI objects such as windows, buttons, lists, and menus. When WinRunner learns the description of a GUI object, it looks at the object’s physical properties. Each GUI object has many physical properties such as "class," "label," "width," "height", "handle," and "enabled" to name a few. WinRunner, however, only learns the properties that uniquely distinguish an object from all other objects in the application. For more information regarding properties, refer to the "Configuring the GUI Map" chapter in the WinRunner User’s Guide. For example, when WinRunner looks at an OK button, it might recognize that the button is located in an Open window, belongs to the pushbutton object class, and has the text label "OK."

Setting Up the GUI Map

2007-03-08T03:58:00.000-08:00

Setting Up the GUI Map

This lesson:
• describes how WinRunner identifies GUI objects in an application
• shows how to use the GUI Spy to view object properties
• describes the two GUI map modes
• explains how to use the RapidTest Script wizard to learn descriptions of GUI objects and to generate tests
• shows you how to run a test
• helps you analyze the test results

Exploring the WinRunner Window

2007-03-08T03:28:00.000-08:00

Exploring the WinRunner Window
Before you begin creating tests, you should familiarize yourself with the
WinRunner main window.
To start WinRunner:
Choose Programs > WinRunner > WinRunner on the Start menu.

The first time you start WinRunner, the Welcome to WinRunner window opens.
From the welcome window you can create a new test, open an existing test, or
view an overview of WinRunner in your default browser.

The first time you select one of these options, the WinRunner main screen opens
with the "What’s New in WinRunner" section of the help file on top. If you do not
want the welcome window to appear the next time you start WinRunner, clear
the Show on startup check box.
Each test you create or run is displayed by WinRunner in a test window. You can
open many tests at one time.

1 The WinRunner window displays all open tests.
2 Each test appears in its own test window. You use this window to record, program, and edit test scripts.
3 Buttons on the Standard toolbar help you quickly open, run, and save tests.
4 The User toolbar provides easy access to test creation tools.
5 The status bar displays information about selected commands and the current test run.

The Standard toolbar provides easy access to frequently performed tasks, such as opening, executing, and saving tests, and viewing test results. The User toolbar displays the tools you frequently use to create test scripts. By
default, the User toolbar is hidden.
To display the User toolbar choose Window > User Toolbar. When you create tests, you can minimize the WinRunner window and work exclusively from the toolbar.

The User toolbar is customizable. You choose to add or remove buttons using the Settings > Customize User Toolbar menu option. When you re-open WinRunner, the User toolbar appears as it was when you last closed it. The commands on the Standard toolbar and the User toolbar are described in detail in subsequent lessons. Note that you can also execute many commands using softkeys. Softkeys are keyboard shortcuts for carrying out menu commands. You can configure the softkey combinations for your keyboard using the Softkey Configuration utility in your WinRunner program group. For more information, see the "WinRunner at a Glance" chapter in your WinRunner User’s Guide. Now that you are familiar with the main WinRunner window, take a few minutes to explore these window components before proceeding to the next lesson.

Understanding the Testing Process

2007-03-07T23:23:00.000-08:00

Understanding the Testing Process
The WinRunner testing process consists of 6 main phases:
1 Teaching WinRunner the objects in your application WinRunner must learn to recognize the objects in your application in order to run tests. The preferred way to teach WinRunner your objects depends on the GUI map mode you select. The two GUI map modes are described in detail in subsequent lessons.
2 Creating additional test scripts that test your application’s functionality WinRunner writes scripts automatically when you record actions on your application, or you can program directly in Mercury Interactive’s Test Script Language (TSL).
3 Debugging the tests You debug the tests to check that they operate smoothly and without interruption.