Addins and Extensions

Out of the box, under Windows, both tools can interrogate and work with objects and windows created 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 as custom objects. Dealing with truly custom objects is discussed further in section 2.8 on page 6. 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 a special manner:

• SilkTest enables support for these technologies using optional extensions. Selected extensions are enabled/disabled in the current Option Set [or the configuration established by the 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 mutually exclusive, (2) some of these addins/extensions may no longer be supported in the newest releases of the tool, (3) some of these addins/extensions may only support the last one or two releases of the technology [for example version 5 and 6 of Visual Basic] and (4) some of these addins and extensions 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 and windows in an existing GUI Map. It is also possible to implicitly create GUI Map entries by capturing 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 to the 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 all applications, 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 utilities are important to your automated testing efforts.

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 as a 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 object hierarchy where child objects exist in parent windows. Note that web page frames are treated as windows, and not child objects of the enclosing window on web pages that are constructed using frames.

Object Recognition

Both of these tools use a lookup table mechanism to isolate the variable name used to reference an object in a test script from the description used by the operating system to access that object at runtime:

• SilkTest normally places an application’s GUI declarations in a test frame file. There is generally 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 can include wildcards; (2) an array reference which resolves to a string which can include wildcards; (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] each optionally 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 each window and each object in a window. The logical name is used to reference the object in a test script, while the physical descriptor is used by the operating system to access that object at runtime. WinRunner provides the following capabilities to define a physical descriptor: (1) a variable number of comma delimited strings which can include wildcards, where each string identifies 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 of obligatory, 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 associated identifier [SilkTest] or logical name [WinRunner] used in the testcase. In general the object tag [SilkTest] or physical descriptor [WinRunner] resolve to one or more property definitions which uniquely identify the object in the context of its enclosing parent window at runtime. It is also possible with both tools to dynamically construct and use object tags [SilkTest] or physical 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 in the test code while the multiple property recorders create unique checklist [*.ckl] files in the /chklists subdirectory [which describe the objects and properties to capture], as well as an associated expected results [*.chk] file in the /exp subdirectory [which contains the expected 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 how existing properties are captured for standard objects.