Notice to A4-size paper users. This document is delivered in 8.5x11 US letter fo rmat.

It can be printed on A4 paper, but there will be wide bottom margins. Refo rmatting for A4 paper requires only a few simple steps. One, in Word open File | Layout and choose A4 from the Size tab. Two, go to the third page (anywhere in Contents) and press F9 to update. Three, go to the last page (anywhere in the In dex) and press F9 again to reindex. Four, save under a new name for convenience. The PDF version of this file is available at http://www.automatedqa.com/download s/tc.asp. Copyright Notice TestComplete, as described in this help system, is licensed under the software l icense agreement distributed with the product. The software may be used or copie d only in accordance with the terms of its license. TestComplete is Copyright 1999-2007 AutomatedQA Corp. ALL RIGHTS RESERVED. No part of this help can be reproduced, stored in any retrieval system, copied o r modified, transmitted in any form or by any means electronic or mechanical, in cluding photocopying and recording for purposes others than personal purchaser's use. All AutomatedQA product names are trademar s or registered trademar s of Automat edQA Corporation. All other trademar s, service mar s and trade names mentioned in this Help system or elsewhere in the TestComplete software pac age are the pr operty of their respective owners. TestComplete includes software developed by the OpenSSL Project for use in the O penSSL Tool it (http://www.openssl.org). This software is copyright 1998-2005 th e OpenSSL Project. It is provided by the OpenSSL Project as is and any expressed o r implied warranties including, but not limited to, the implied warranties of me rchantability and fitness for a particular purpose are disclaimed. In no event s hall the OpenSSL Project or its contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not li mited to, procurement of substitute goods or services, loss of use, data, or pro fits; or business interruption) however caused and on any theory of liability, w hether in contract, strict liability, or tort (including negligence or otherwise ) apprising in any way out of the use of this software, even if adviser or the p ossibility of such damage. TestComplete includes the UnzDll.dll library that is supplied by Info-Zip. This library is copyright 1990-2005 Info-ZIP. This software is provided as is, without warranty of any ind, expressed or implied. In no event shall Info-ZIP or its co ntributors be held liable for any direct, indirect, incidental, special or conse quential damages arising from the use of or inability to use this software. Table of Contents INTRODUCTION 5 Introducing TestComplete 5 What's New in TestComplete 5 5 Features Added to TestComplete 5.12 6 Features Added to TestComplete 5.11 6 Features Added to TestComplete 5.1 6 Features Added to TestComplete 5.0 6 Difference Between Standard and Enterprise Editions Supported Development Tools 16 System Requirements 17 Getting Support 19 GETTING STARTED 20 TestComplete Product Overview 20 User Interface Overview 21 About Projects and Project Items 23

14

TestComplete User Interface and Object Browser 25 TestCompletes Test Log 26 Stores of Images, Files and Object Properties 28 Loo ing Inside Applications 28 Testing Through Application Code 29 Creating a Project 30 Defining Applications to Test 33 Exploring the Application in the Object Browser 37 Creating Tests 43 Recording a Test Script 46 Analyzing the Recorded Script 51 Editing and Writing Scripts 60 Specifying Execution Order for Tests 62 Running Tests 65 Analyzing Test Results 68 Searching for the Reason of an Error 70 SCRIPTING 72 Writing Scripts Overview 72 Selecting the Scripting Language 74 Writing Scripts Quic Start 75 How TestComplete Recognizes Processes, Windows and Controls Calling Routines and Variables Declared in Another Unit 94 Supported Scripting Languages Peculiarities of Usage 96 INDEX 102

Introduction Introducing TestComplete TestComplete is an automated testing environment for Win32, .NET and WPF applica tions. It provides extended support for testing Web pages, Web servers and proje cts created in Microsoft Visual C++, Visual Basic, Borland Delphi, C++Builder, J ava, .NET and WPF development tools. TestComplete manages scripts to test applications externally, self-testing by th e applications themselves, and many inside-outside forms of tests. It is oriente d equally to unit testing and to functional testing, provides superior support f or daily regression testing and supports many other ind of testing (data-driven testing, object-driven testing, etc.) If you are new to TestComplete, see Getting Started to learn how to use the prod uct. To get to now basic concepts, please read TestComplete - Product Overview (this topic is part of the Getting Started section). To learn more about new features, review Whats New. A note about plug-ins: TestCompletes entire architecture is COM-based. Most of th e features you see in the product are supported through plug-ins. When the plugin is meant to remain for the life of the current version, it is made an interna l part of TestComplete.exe. When it is possible that the plug-in could be update d, it is left external (such as the database-access plug-ins). Others will be ad ded to the AutomatedQA Web site (http://www.automatedqa.com), and users can writ e their own plug-ins using the supplied interface documentation and libraries se veral user-contributed plug-ins are in http://www.automatedqa.com/downloads/plug ins.asp. In fact, there are so many open features to TestComplete that we have put a chec l ist into a separate topic, Open Access. What's New in TestComplete 5 TestComplete 5 has been greatly enhanced compared to its previous version, TestC omplete 4. The new version includes a number of exciting features that provide n ew functionality and ma e the product more convenient to use. Below is a list of major changes. Note: TestComplete version 5 completely supports projects created in version 4 . However, you may need to recompile your Visual C++, Delphi or C++Builder Open

86

Applications. For more information, see Migrating Projects Created in TestComple te 4 to TestComplete 5 in TestComplete help. Features Added to TestComplete 5.12 A number of bugs have been fixed. Features Added to TestComplete 5.11 A number of bugs have been fixed. Features Added to TestComplete 5.1 The Object Name Mapping dialog now contains a new Highlight button. With this bu tton you can easily determine which window or control is being mapped. The WPFExpander object contains two new methods: Collapse and Expand. Now, you c an hide or display the controls contents by using these methods. TestComplete objects that correspond to .NET controls contaning the ContextMenuS trip property now have a new StripPopupMenu property. This property returns the Menu object that provides a scripting interface to the menu, specified by the co ntrols ContextMenuStrip property. The Insert Table dialog that is used to add tables to manual test instructions h as been modified. Now, it can display a preview section showing the table with t he applied settings. Using this section you can easily detect how changes made t o the table properties affect the table appearance. The Parameters dialog, where you specify properties of tested applications' RunA s mode, has been changed. Now, it contains the Confirm edit box and does not con tain the Show password chec box. A number of bugs have been fixed. Features Added to TestComplete 5.0 Overall Improvements Testing under a different user account. TestComplete 5 lets you launch and test applications under a different user account and test your application under diff erent user accounts without rebooting. See Wor ing With TestComplete Under a Use r Account and Testing Applications Running Under Another User Account in TestCom plete help for more information. Tested application improvements. The Tested Applications editor has been improve d. Now you can specify the run mode for applications: Simple, RunAs, Debug or Pr ofile (see Run Modes in TestComplete help). If Simple mode is selected, the appl ication is launched as it normally would be launched in earlier versions of Test Complete. RunAs mode lets you specify the user account under which the applicati on will be executed (see Testing Applications Running Under Another User Account in TestComplete help). If Debug mode is used, TestComplete traces events and exceptions that occur in t he application under test and posts them to the test log (see Tracing Events and Exceptions in Tested Applications in TestComplete help). Profile mode lets you select an AQtime profiler, which will trace the applicatio n execution. That is, your TestComplete project will simulate user actions or pe rform unit tests and AQtime will simultaneously chec for memory lea s, performa nce bottlenec s, or perform the coverage analysis. TestCompletes test log will co ntain references to files storing AQtime results. See Coverage Testing and Integ ration With AQtime in TestComplete help. Support for third-party menu controls. In earlier versions, TestComplete only pr ovided special scripting support for standard (Win32) menus. The simulation of u ser actions over third-party menus were limited by mouse clic s, or were not sup ported at all. In version 5, the third-party menu support has been improved. Now , window objects contain specific properties that let you simulate user actions and wor with items from most popular third-party menu componenets such as those from Microsoft, Borland, Developer Express, Component One, Janus, Infragistics, Syncfusion. To wor with these menus, TestComplete adds new properties to the w indow object (for more information on them, see TestComplete help): Window.ActionMainMenu Window.C1MainMenu Window.EssMainMenu Window.JMainMenu Window.StripMainMenu

Window.UICtrlsMainMenu Window.UltraMainMenu Window.XtraMainMenu All of these properties return the Menu object that provides a scripting interfa ce to the menus. The objects methods and properties coincide with the methods and properties of the Win32Menu object. The Win32Menu object was renamed to Menu an d the Win32MenuItem object was renamed to MenuItem. Test items parameters. In earlier versions a test item could refer to a project item or script routine to be executed. The script routine could not use paramete rs. Now you can run routines that have parameters. Using a special dialog you sp ecfiy the parameter values for the run. Improvements in Connected and Self-Testing Applications. In earlier versions of TestComplete, a Connected or Self-Testing Application had to be started from a T estComplete project, since TestComplete posts messages to the log and only provi des access to scripting objects when a script was running. In TestComplete 5, the files that are used to create these applications have bee n updated. Now these files include a special RunTest routine that lets you switc h TestComplete to the script-running mode from an external application. In other words, now there is no need to launch Connected and Self-Testing Applications f rom scripts even though the previous launching approach is also supported. For m ore information, see Running Connected and Self-Testing Applications in TestComp lete help. Windows Vista Technologies Support TestComplete version 5 provides an extensive support for Microsoft Windows Vista : Script recording and playbac . TestComplete can record and play bac scripts und er Windows Vista. Note that in order to run tests on Windows Vista, TestComplete and the application under test must have the same security priveleges. For comp lete information, see Testing Applications With TestComplete Under Windows Vista in TestComplete help. UI Automation support. TestComplete 5 supports the Microsoft UI Automation techn ology. Using UI Automation providers, TestComplete retrieves information on appl ication controls and their methods and properties, thus, giving you a possibilit y to use these methods and properties in your test proejcts. Also, TestComplete adds a new UIAObject method to the process and window objects. This method is us ed to address application object through the UI Automation technology. See UI Au tomation Technology Support in TestComplete help for more information. WPF (XAML) support. TestComplete 5 includes support for XAML (WPF) controls and applications. It adds special method (WPFObject) to process and window objects. Using this method you can wor with controls in your WPF application. TestComple te also includes special new objects for different types of XAML controls: combo boxes, list boxes, toolbar, and others. These objects contain specific methods and properties that let you easily obtain information on the controls state and s imulate user acitons over the control. For more information, see Testing WPF App lications in TestComplete help. Web Testing Improvements TestComplete 5 includes the following new features intended for functional testi ng of web pages: Firefox support. Earlier versions of TestComplete provided access to web page el ements only shown in Internet Explorer. Version 5 lets you wor with elements of web pages that are displayed in Firefox. Testing these pages is very similar to testing web pages shown in Internet Explorer. See Web Testing in TestComplete h elp for more information. Scripting interface to Internet Explorer settings. The Options object contains t wo new properties: IESettings and IEZoneSettings that provide program access to Internet Explorer options that are displayed on the Advanced and Security pages of Internet Explorers Internet Properties dialog. Name Mapping Improvements The Name Mapping engine has been greatly improved: Name Mapping templates. The Name Mapping engine provides predefined sets of prop

erty values that are commonly used for recognition of mapped objects. Instead of selecting the set of custom objects properties manually, you now can select the appropriate name mapping template. TestComplete contains predefined templates fo r standard Win32 controls, VCL controls, .NET controls and so on. See Name Mappi ng Templates in TestComplete help. Enhanced Name Mapping aliases. In TestComplete 5 the concept of aliases has been improved. Now you can create a custom tree of mapped object that differ from th e physical object tree. This gives you a possibility to call mapped objects only by alias, that is, s ipping the NameMapping.Sys.MyProcessName notation. Also, y ou can hide any intermediate levels of object hierarchy and ma e, for example, a control a child of a process (in normal hierarchy, a control is a child of a wi ndow, which in its turn is a child of a process). See Name Mapping Aliases in Te stComplete help. Using Project Variables to specify property values. In earlier versions of TestC omplete, you can specify property values only by using constants. Now you can li n a project variable with the property, so TestComplete will use this variables value to recognize objects. User Forms In TestComplete 5 you can create user-defined forms to be displayed during the t est execution. The forms can contain various controls - buttons, chec boxes, ed it boxes, combo boxes and many others - so you can easily create a form that wil l as you to select one of possible testing scenarios or to specify initial test conditions. The form creation is visual and it is very similar to the form creation in Micro soft Visual Studio or Borland Delphi. Using the powerful form editor, you are ab le not just set controlss properties, but also create event handlers to implement complex processing. To manage user-defined forms TestComplete includes special project item - User F orms. To wor with forms in script, TestComplete provides a new UserForms object . For more information on using the forms, see User Forms. Changes in Stores Three new improvements have been made to the Stores engine: The Regions, Objects and Files objects' Compare method's behavior has been chang ed. According to new options and settings made in the Regions, Files and Object editiors, the methods are not only able to compare the images (files, objects), but update the stored items with the image, file or object properties being comp ared. That is, you can use the same script code to update the images and to comp are them. For more information, see Regions.Compare, Files.Compare and Objects.C ompare. The methods of the Regions and Objects object that added images and object prope rties to the Stores project item now have an extra parameter that let you specif y the file and folder where the image and object properties will be saved. In ea rlier versions, the images and properties were saved to the folder where the Sto res project item file resided. See Regions.AddPicture and Objects.Save. The Objects editor has been modified. Now you are not only able to change the st ored property values, but you can also create new objects in the stored hierarch y. Load Testing Improvements The HTTP Load Testing project item now supports the Kerberos authentication syst em. Now you can specify the connection speed for your load tests. This feature lets you ma e testing conditions closer to real life. The Load Test Editor contains a new colunm, Connection Speed, where you can type the desired speed or select on e of the predefined speed values from the drop-down list. The HTTPTas object no w has a new BandWidth property that lets you specify the desired speed from scri pts. Now, if the load testing engine was unable to simulate connection requests, Test Complete logs a warning or an error message. To manage coo ies more efficiently, TestComplete 5 adds a new ClearCoo ies prope rty to VirtualUser and TestInstance objects that are used to perform load testin

g. See Managing Coo ies in TestComplete help for more information. The HTTPRequest object now contains two new URLVariables and BodyVariables prope rties that provide access to request variables passed via the URL string and req uest body. The load tests created visually now have a new property that lets you specify wh ether TestComplete will simulate virtual users simultaneously or in a series. Fo r more information, see Concurrent and Serial User Simulation in TestComplete he lp. The context menu of the Load Testing Tas editor contains a new Show Connections item. When this item is chec ed, the tree on the left of the editor contains bo th connection and request nodes. When the item is unchec ed, the tree only displ ays request nodes. Changes in .NET, Java and Other Open Applications New option. Java and .NET application objects can be addressed by their names de fined in application code or by class name, caption (or accessible name) and ind ex. In TestComplete 5, the project property's Open Applications group includes a new Use native object names for TestComplete object names option. It specifies whether TestComplete will use the names defined in the application code to name objects of .NET and Java applications. See Addressing Windows, Controls and Obje cts of .NET Applications and Addressing Windows, Controls and Objects of Java Ap plications in TestComplete help. The option also affects naming WPF application objects (see Addressing Windows, Controls and Objects of WPF Applications in Tes tComplete help). New properties of Java applications objects. TestComplete adds new properties to objects of Java applications: JavaClassName, JavaFullClassName, AWTComponentAcce ssibleName and AWTComponentIndex. The AWTObject and WaitAWTObject methods of the window object have a new WndIndex parameter that is used to identify controls in addition to the class name, acce ssible name and index. See the methods descriptions for more information. New properties to determine the Java virtual machines version. The process object s that correspond to Java applications now contain two new properties: JavaVMCou nt and JavaVMVersion. Using these properties you can detemine the number of Java virtual machines loaded into the process and the version of each machine. Support for arrays in Java applications. TestComplete recognizes objects that co ntain arrays and adds two properties to them: Items and Length. These properties provide access to array items. Multi-dimensional arrays are also supported. See Java Open Applications in TestComplete help. Delphi CLX Open Applications. In addition to Delphi VCL applications, TestComple te now supports Delphi Open Applications compiled with the CLX library. See Open Applications in Delphi and C++Builder in TestComplete help. New modules for creating Visual C++, Delphi and C++Builder Open Applications. Th e helper files that were used to create Visual C++, Delphi and C++Builder Open A pplications have been changed. To create an Open Application compatible with Tes tComplete 5, use the files shipped with TestComplete 5. For more information, se e Migrating Projects Created in TestComplete 4 to TestComplete 5. The Object Browser does not display WinForms objects' private and protected prop erty values, which are descendants of the System.Windows.Forms.Control class and whose IsHandleCreated property returns False. See Access to Properties in TestC omplete help. Manual Testing Improvements The Manual Test editor contains new toolbar items providing more editing capabil ities for HTML text in step instructions: Adding tables. Support for numbered and non-numbered lists. Special items for indenting and outdenting text bloc s. Also the editor of the root step now contains the Step notes and comments edit b ox. Using the new ManualTestBuilder object you can create manual tests directly from your scripts. For more information on this, see Creating Manual Tests From Scri pts in TestComplete help.

Low-Level Procedures Improvements Low-level procedures can now be recorded and executed in window coordinates. In earlier versions, low-level procedures only wor ed with screen coordinates. This new feature lets you create low-level procedures that will only operate over on e window. This is useful, if the window location on screen changes between diffe rent test runs and you cannot position the window before running the low-level p rocedure. To record a low-level procedure, use a new button on the Recording toolbar - . The Execute method of the LowLevelProcedure object has been changed. Now it uses a parameter that specifies a window where the procedure will simulate user acti ons. If you s ip this parameter, the procedure will wor for the whole screen. The low-level procedures, whose execution is started from the Project Explorer p anel, always wor in screen coordinates. The same concerns low-level procedures that are executed as test items. Networ Suite Enhancements The Networ Suite editor contains a new Run State page that lets you trace the s tatus of a tas , job or networ suite execution. The Tools menu contains a new Networ Suite submenu, whose items let you start a nd stop the Networ Suite Remote Agent executable (tcrea) and control its run mo de. See About Networ Suite Remote Agent in TestComplete help for more informati on. The Tas object contains a new PriorInstanceMode property that lets you specify whether TestComplete will close the remote TestComplete (or TestExecute) instanc e before executing the tas . Program Objects Enhancements Win32 controls support. Support for Win32 controls has been greatly improved. Te stComplete includes special program objects for wor ing with IP Address and SysL in controls. Existing Win32 objects now have new methods and properties that provide extended access to controls. Now it is possible to obtain images displayed by buttons, c hec boxes, tab pages, toolbars and controls, retrieve application-defined data o r get the bounds of the controls items, labels or icons. Control-specific propert ies and methods has also been extended, for instance, the TreeView control has a new wItems property that allows a user to access all tree view control items. The Runner.Stop method has a new CurrentTestOnly parameter. Using this parameter you can stop the current test or the whole test run. Picture object enhancements. The Picture object contains the following new membe rs: A new Pixels property - Use it to access individual pixels of the image. A new Stretch method - Use it to stretch or shrin the image at your desire. A new GetRect method - Use it to obtain a Picture object that corresponds to a r ectangular area within the given image. The Compare, Difference and Find methods have a new Mouse parameter that lets yo u include the mouse pointer in the comparison. The TestedApp object contains a new Params property. This property returns a new TestedAppParams object that provides a scripting interface to run parameters of various run modes through its properties (SimpleParams, RunAsParams, DebugParam s and ProfileParams). Now, to specify the command line for a tested application, you should use these properties. The Parameters and Wor Folder properties of th e TestedApp object became obsolete. They are supported for bac ward compatibilit y only. The object returned by the TestedApp.Run method depends on the run mode that is set for the tested application in the Tested Applications editor. If Profile mod e is selected, the method returns a new AQtime object. Else, it returns the proc ess object. The TestedApp.Run and TestedApp.RunAs methods contain two new parameters: Ignore Running and Timeout. Using the IgnoreRunning parameter you can control the numbe r of application instances to be launched and using the Timeout parameter you ca n specify the time period to wait until the application is started. TestComplete adds new properties to Java application objects: JavaClassName, Jav

aFullClassName, AWTComponentAccessibleName and AWTComponentIndex. The process objects that correspond to Java applications now contain two new pro perties: JavaVMCount and JavaVMVersion. The AWTObject and WaitAWTObject methods of the window object have a new WndIndex parameter that is used to identify controls in addition to the class name, acce ssible name and index. The functionality of the DbgServices.LaunchTestedApplication and DbgServices.Lau nchAllTestedApplications methods has been changed. Now, these methods launch the tested application according to the applications run mode. The Variables object contains a new method - AddVariable - that lets you create project, project suite or networ suite variables directly from your script code . Version 5 includes new ManualTestBuilder and ManualTestStep scripting objects th at let you create manual tests from scripts. See Creating Manual Tests From Scri pts in TestComplete help. The Variables object contains two new methods: AddVariable - Lets you create project, project suite or networ suite variables directly from your script code. GetVariableDefaultValue - Returns the default value of the specified variable. A new StopWatch object has been added. Using this object you can time the execut ion of your script code. A new RegExpr object lets you use regular expressions in scripts. A new action - HoverMouse - has been added to onscreen objects. It lets you hottrac the object with the mouse pointer by moving the pointer to the specified p osition within the object. The Tas object contains a new PriorInstanceMode property that lets you specify whether TestComplete will close the remote TestComplete (or TestExecute) instanc e before executing a networ suite tas . The ReturnValue property of the CallObjectMethodAsyncResult object does not supp ort object references. Now it can only return ordinary values (integer, string, boolean and so on). The built-in _Ord routine has been renamed to getOrd. AQtime Integration Improvements Integration has been made easier. Now you can select the Profile run mode for a tested application, and when TestComplete launches the application, it also laun ches AQtime to profile this application during the test run. AQtime now traces f or bottlenec s or chec s the application for memory and resource lea s while Tes tComplete is simulating user actions over the application. Version-independent scripting. The AQtimeIntegration object includes new Current Version and AQtime properties. Using the AQtime property you can create scripts that are not dependant on the AQtime version (the scripts will wor for both AQt ime 4 and AQtime 5). The only thing you have to change is your AQtime version wi th the CurrentVersion property at the beginning of the test run. TestComplete also includes a new AQtime object that contains the same methods an d properties as the object returned by the AQtimeIntegration.AQtime property and is used for version-independent wor with AQtime. A new WaitAndExportResult method. The AQtime4 and AQtime5 objects contain a new WaitAndExportResult method that pauses the script execution until profiling is o ver and then exports profiling results to a file. Other Improvements Now you can use Opera and Mozilla to view exported test log data. Using a new Character encoding project property, you can now select three format s for storing script files: ANSI, UTF-8 and UTF-16. TestComplete 3 and earlier u sed the ANSI format. TestComplete 4 uses the UTF-16 format to support Unicode. H owever, some version control systems do not support Unicode files or provide lim ited support for them. To resove the problem, TestComplete 5 includes a new opti on that lets you change the script file format to UTF-8 or ANSI. See also Charac ter Encoding in TestComplete help. Now you can rename log items displayed in the Project Explorer panel. See Renami ng Log Items and Adding Comments to Them in TestComplete help for more details.

 The Code Editor now copies script code to the clipboard eeping the color and fo nt attributes, for example, if you paste the copied text to WordPad, the formatt ing will be the same as it was in the Code Editor. Context menus in the ODT editors now include special items that allow you to cha nge the methods or propertys position in a class or object. See How to Create, Mod ify and Delete Methods and How to Create, Modify and Delete Properties in TestCo mplete help for more information. In earlier versions of TestComplete, the Code Templates Options dialog displayed templates defined for only one language. In TestComplete 5 the dialog lets you modify code templates for all supported scripting languages. Also, by default, T estComplete offers a number of pre-defined templates. The context menu that is displayed when you right-clic an editors caption in the Wor space panel now contains new items that let you chec the file in or out of source code control, get the latest version of the file or compare it with anot her file. TestCompletes COM interfaces have been improved and now they provide access to pr ojects and project suites test items. See Wor ing With TestComplete via COM for mo re information. Difference Between Standard and Enterprise Editions There are two editions of TestComplete: Standard and Enterprise. The following m atrices explain differences between them. Features Supported by Both Standard and Enterprise Editions Features Standard Edition Enterprise Edition Blac -box testing (functional testing of any Windows application) + + Extended support for .NET applications + + Extended support for Microsoft Visual C++ applications + + Extended support for Microsoft Visual Basic applications + + Extended support for Java applications + + Extended support for Borland Delphi applications + + Extended support for Borland C++Builder applications + + Extended support for applications using Microsoft Active Accessibility (Microsof t Visual FoxPro, Microsoft Access, etc.) + + UI Automation technology support + + Extended support for WPF (XAML) applications + + Extended AQtime integration and coverage testing + + Testing under different user accounts + + Scripting and script debugging + + Event handling + + Unit testing (including support for MSTest, JUnit, NUnit and DUnit unit tests) + + Functional testing (or user interface testing) + + ActiveX objects support + + Low-level recording and playbac + + Name mapping + + Object-driven testing + + Data-driven testing + + Source code control integration + + User forms + + Calling functions located in .NET assemblies + + Calling functions located in DLLs + + ADO and BDE support + + CORBA support + + Compression of test results + + Features Available in the Enterprise Edition Only Features Standard Edition Enterprise Edition HTTP load testing + Networ suite (distributed testing) + Functional testing of Web pages (web testing) +

Optical character recognition + Microsoft Visual Studio 2005 integration + Issue-trac ing support + TestExecute + TestRecorder + TestComplete Enterprise Edition includes special plug-ins that allows you to sim ulate virtual users and perform the load, stress and scalability testing of your Web servers (see Load, Stress and Scalability Testing in TestComplete help). Th e basic TestComplete Enterprise license supports only 5 virtual users. These use rs can be simulated on the wor station where TestComplete is installed. There ar e also versions available that support more virtual users: TestComplete Enterprise Edition with a 50 virtual user license. This license all ows you to simulate simultaneously from 1 to 50 virtual users on the computer wh ere TestComplete is installed. TestComplete Enterprise Edition with a 250 virtual user license. This version in cludes a special software pac age, TestComplete HTTP Load Testing Remote Agent, that lets you simulate virtual users on several networ computers. If you have t his license, you can install TestComplete on one wor station and install the HTT P Load Testing Remote Agent on any number of wor stations. The HTTP Load Testing Remote Agent includes all functionality needed to simulate virtual users. There is no need to install TestComplete on wor stations where the HTTP Load Testing Remote Agent is installed. You can share virtual users among wor stations as you wish, but the total number of virtual users wor ing simultaneously cannot excee d 250. TestComplete Enterprise Edition with unlimited number of virtual users. Li e the previous version, this one also includes the TestComplete HTTP Load Testing Rem ote Agent. If you have this license, you can simulate any number of virtual user s wor ing simultaneously on any number of wor stations. The number of virtual us ers per wor station cannot exceed 300 (this restriction is caused by certain ope rating system limitations). If you need to simulate, for example, 600 users, you would need to use two wor stations. Supported Development Tools Will TestComplete test my application? - This is probably one of the first questio ns our clients as about TestComplete. As a matter of fact, TestComplete does no t depend on any development tool. It can simulate user actions ( eypresses, mous e movements and clic s) under any application no matter whether this application was created in C#, Visual C++, Delphi or Java. However, in most cases, this in d of testing (testing via GUI) cannot provide reliable and thorough results. Qui te often, QA engineers need access to the application internal objects, methods and properties. This is required, for example, for unit testing. You can get thi s access using TestComplete. It opens the internal objects, methods and properties up to private object elements in applications that were created with the follow ing development tools: All existing .NET compilers. For instance: Microsoft: Visual C#, Visual Basic .NET and Visual C++ .NET v. 7.0 and later (ma naged code) (Visual Studio v. 8.0 only with Service Pac 1 installed), JScript . NET Non-Microsoft: Borland C#Builder, Borland Delphi for .NET (Delphi 8 and Delphi 2 005), Python .NET, Cobol .NET, Perl .NET, etc. Microsoft Visual C++ 6.0, Visual C++ 7.0 and later (unmanaged code) (Visual S tudio v. 8.0 only with Service Pac 1 installed) Microsoft Visual Basic 6.0 Borland Delphi 3.0 and later Borland C++Builder 3.0 and later Any Java development tool that supports one of the following Java virtual mac hines: MSVM, build 3309 or later Sun JDK (or JRE) v. 1.1.8 or later BEA JRoc it 5.0 For instance, you can use Microsoft Visual J++ 1.1 or later, Borland JBuilder 3.

0 or later, Sun Forte 1.0 or later, etc. The AWT and Swing library classes are a lso supported. Sybase PowerBuilder 10.0 and later Microsoft FoxPro 7.0 and later Microsoft Office Access 2003 and later Microsoft Office InfoPath 2003 and later Since TestComplete can test any Windows application via GUI, it can simulate ey presses and mouse clic s in any Internet browser. This allows you to test Web pa ges wor ing with any Internet browser. However, currently, you can only access p roperties and methods of HTML elements on a Web page shown in Internet Explorer, Firefox or in any instance of the Web Browser control. See Web Testing in TestC omplete help for complete information on this. As for the performance, load, stress and scalability testing of Web servers, the y do not depend on Internet browsers (Internet Explorer, Netscape Navigator, Moz illa, Opera, etc.), the server type (Microsoft IIS, Apache, etc.) or platform (W indows, Linux, etc.) That is, with TestComplete you can perform these inds of t esting for any Web server wor ing on any platform. Please see Load, Stress and S calability Testing of Web Servers With TestComplete in TestComplete help. System Requirements Minimal System Requirements Intel Pentium II 400 MHz or higher (Pentium III 800 MHz recommended) Microsoft Windows 98, Windows ME, Windows 2000, Windows XP (both 32-bit and 64-b it editions), Windows Vista (32-bit editions), Windows Server 2003 (both 32-bit and 64-bit editions) or Windows NT 4.0 with Service Pac 6 or later. For information on using TestComplete and the Windows Firewall, see TestComplete and Windows Firewall in TestComplete help. For more information on wor ing under Windows Vista, see Testing Applications Wi th TestComplete Under Windows Vista in TestComplete help. Microsoft Internet Explorer 5.0 or later. Memory: 64MB of RAM (128MB or more recommended) 250MB hard dis space VGA or higher resolution monitor Mouse or other pointing device Additional Requirements To test Java Open Applications, you must have one of the following Java virtual machines installed on your computer: MSVM, build 3309 or later. Sun JDK (or JRE) v. 1.1.8 or later. BEA JRoc it 5.0. To test .NET Open Applications, the Microsoft .NET Framewor v. 1.0.3705 or late r is required. To execute TestComplete tests from test projects created in Microsoft Visual Stu dio 2005, Microsoft Visual Studio 2005 ver. 8.0.50727.42 or later is required. To install TestCompletes Microsoft Visual Studio 2005 Team Foundation Integration pac age, Microsoft Visual Studio 2005 Team Foundation Server Release is require d. To perform load testing of Web servers, Microsoft Windows 2000, Window XP, Windo ws Server 2003 or Windows NT with Service Pac 6.0 or later is required. Also, i t is recommended that your computer meets the following requirements: Minimal Configuration Intel Pentium III 800 MHz 256 of RAM (for 300 virtual users) Recommended Configuration Intel Pentium 4 3 GHz with HyperThreading 1 Gb of RAM To run load testing samples under Windows Vista, you should modify some of the I IS settings. For more information on this, see Running Load Testing Samples Unde r Windows Vista in TestComplete help. Getting Support Questions about TestComplete? Problems? Quality answers and responsive help come

free from our e-mail support team at: support@automatedqa.com The support is free and unlimited. You can also subscribe to a priority support service: 12 months of the priority e-mail support (you will get answers within 2 4 hours and faster) plus free minor and major updates. The priority support is p rovided on an annual basis at cost of the product. For more information, please visit our Web site at www.automatedqa.com. Even more help is available on our newsgroup, along with a chance to exchange co mments and suggestions or even to post pointers for others: forums.automatedqa.com.public.testcomplete You can find answers to your question in the list of the frequently as ed questi ons which is available at: http://www.automatedqa.com/products/testcomplete/faqs/tc_faqs.asp Ta e part in TestComplete training seminars offered by AutomatedQA. To learn mor e about training services, please follow this lin : http://www.automatedqa.com/support/training.asp Learn more about using TestComplete from technical papers published at: http://www.automatedqa.com/techpapers/ Ma e sure you regularly visit the AutomatedQA Web site, http://www.automatedqa.c om, where you will find News Updated support options Downloads, such as plug-ins and free tools Hot Stuff contributed by experienced users and the AQA team (hands-on solutions, code, plug-ins, etc.) Getting Started Before you start reading the following topics, we recommend that you read the Te stComplete Product Overview to get the general concepts of the product. Creating a Project Defining Applications to Test Exploring the Application in Object Browser Creating Tests Creating Tests Recording a Test Script Analyzing the Recorded Script Editing and Writing Scripts Specifying Execution Order for Tests Running Tests Analyzing Test Results Searching For the Reason of an Error TestComplete Product Overview TestComplete is a powerful feature-rich automated testing tool. The following to pics provide an overview of the product: User Interface Overview About Projects and Project Items TestComplete User Interface and Object Browser TestCompletes Test Log Stores of Images, Files and Object Properties Loo ing Inside Applications Testing Through Application Code User Interface Overview The user interface of TestComplete consists of panels, the main menu and toolbar s. The general layout is as follows: Most of TestCompletes screen area is occupied by panels. Panels are where you do your actual wor and get your results. Each panel serves a separate purpose for your wor in TestComplete. There are four main panels: Panel Description Project Explorer Displays the contents of the project suite, its projects

and project items. Wor space This panel is your wor space in TestComplete. It holds a set of tabbed pages, in which you can modify properties of project items. When you dou ble-clic an item in the Project Explorer, TestComplete opens the appropriate ta b page in the Wor space panel. Log Filters and displays test results. Object Browser TestComplete "sees" a lot of the applications under test, as wel l as all applications running on the machine. The Browser shows all of this in a navigational tree format. Everything that can be found in the Browser can be us ed in a test - the Browser is your test-object map, using the universal TestComp lete object model. Names and values can be copied from the Browser and pasted to scripts. Values of all inds can be saved from the Browser to Stores for later comparison. There are more panels that are used for editing and debugging script code: Panel Description Boo mar s Shows a list of boo mar s set in the script code. Used for scrip t editing. Search/Replace Results Displays results of the search or replacement operations . Watch List Used for script debugging. Shows variable and property values du ring test runs. Call Stac Used for script debugging. During script execution, it shows the stac of function calls that led to the execution of the current routine. Brea points Displays information about brea points. Used for script debuggin g. Code Explorer Navigates through scripts that are ept within the project. Used for script editing and debugging. The size and layout of panels is not fixed. You can change panel sizes by draggi ng the separator between them. However, the most important point about handling panels is how they can be moved around - doc ing. Doc ing is our way of providin g you with the most flexible wor space for the particular tas you are intereste d in. It means that the entire wor area can be reconfigured as needed, even bey ond what is possible with toolbars (moving, hiding, etc.). Doc ing of panels in TestComplete is similar to doc ing windows in Microsoft Visual Studio .NET. For more information, see Doc ing in TestComplete help. There are common ways of arranging columns and lines in the grids, which most pa nels display. In addition, each panel has a number of options that you can modif y in the Panel Options dialog. The general organization of each panel has its ow n set of options, which you can modify in the User Interface dialog. To save the current panel layout to a file, select View | Des top | Save Doc ing to File from TestCompletes main menu (by default, these files have the .qtdoc e xtension). To load the panel layout from a file, select View | Des top | Load Do c ing from File. To restore the default panel layout, select View | Des top | Re store Default Doc ing. The Save Des top As and Load Des top items of the View | Des top submenu will save and load the panel layout along with the toolbar setti ngs. TestComplete's interface receives commands in four ways: Through menus. Through popup menus (right-clic , context-dependent). Through toolbars. Through eyboard shortcuts. Keyboard shortcuts are especially useful during recording, since they let you co mmand TestComplete without moving the focus off the tested application. These sh ortcuts can be customized with the Global Shortcut Options dialog. As in Microsoft Word or Excel, menus are a type of toolbar, and both can be cust omized as needed. You can also create your own toolbars. By default, toolbars ar e doc ed at the top of the TestComplete window. You can easily doc them to any other edge by dragging them to the left, right or bottom edge of the window. To remove or add buttons, you can either call the Toolbar Customization window or u se the Quic Customization feature. See Toolbars Customization in TestComplete h

elp for more information. To save or load the current layout of toolbars and toolbar items, use the View | Toolbars | Save Toolbars to File and View | Toolbars | Load Toolbars from File menu items. To restore the default toolbar layout, select View | Toolbars | Rest ore Default Toolbars. To save and load the layout of panels, menus and toolbars, use the View | Des top | Save Des top As and View | Des top | Load Des top menu items. About Projects and Project Items Projects and Project Suites Similar to program development tools, such as Microsoft Visual Studio or Borland Delphi, the primary unit of management in TestComplete is a project. A project contains data and files (project items) that are needed to perform tests as well as a cumulative log of all test runs since the start of the project. Related projects can be united into a project suite that contains one or more pr ojects. TestComplete automatically generates a project suite when you create a n ew project. You can also create empty project suites and then use TestCompletes d ialogs to fill the suite with the desired project files. Project Items Project items are elements that perform various testing operations or assist in performing these operations. Each project item is a collection of child items an d files. By default, the child items are stored in files located in subfolders o f the projects folder. The Project Explorer panel provides a graphical interface to view and manage the projects, project suites and project items: For complete information on project items available in TestComplete, see About P roject Items in TestComplete help. To view or modify properties of a project item or properties of its child elemen t, right-clic the desired item or element in the Project Explorer panel and cho ose Edit from the context menu, or simply double-clic the item (or element). Te stComplete will show the property editor in the Wor space panel: In addition to the editor displayed in the Wor space panel, TestComplete offers other helper panels and windows for some project items to ma e editing more conv enient. For instance, TestComplete includes the Code Explorer panel which ma es it easier to navigate through script units. About Test Items Most project items can be used to perform testing actions. For instance, Script and Low-Level Procedures can simulate user actions; HTTP Load Testing can simula te the user activity over a Web server, and so forth. In other words, a project item can be used as a source of the entire test or a part of the test (we call t hese parts test items). The sequence of test items to be run is specified in the Test Items page of the project editor. A project itself can be used as a test i tem when you create tests for project suites. For more information, read Creatin g Tests. TestComplete User Interface and Object Browser TestCompletes des top is organized into a number of panels (see User Interface Ov erview): The Project Explorer panel displays a tree of project items, their child element s and test log nodes. The Wor space displays editors for the selected project it em as well as test log pages. The Object Browser panel holds one major TestComplete function that does not bel ong to a specific project. The Object Browser maps all processes currently runni ng on the machine, whether they are an application for testing, a basic operatin g system service li e the Explorer process, or some other application li e Inter net Explorer or TestComplete itself. For each process it shows all objects acces sible externally through TestComplete facilities, and all of the accessible obje ct properties and methods. It also shows the simulated user actions possible on the object; these are simply called actions.

In other words, the Browser tells you everything that is available for external testing, and how to get to it. It also lets you ta e screen clips (by window obj ects or by rectangle) and store them as images with the current project. It does the same for any collection of object properties you may wish to store. Finally , there are several ways of copying information from the Browser to the clipboar d, or directly into scripts. The fastest way to understand how TestComplete supports external testing is to s pend some time in the Object Browser. See Exploring Application Properties in Te stComplete help. TestCompletes Test Log Each project holds a log of all project runs. In fact, the best definition of a project is what TestComplete maintains a log for. Everything else is secondary. Th e log is where you get the results of the entire testing exercise. The basic unit of the log is a test. The log itself is an object that can be cal led in scripts or code. Using TestComplete in the simplest way, you launch a tes t by right-clic ing a project or project item in the Project Explorer panel and selecting Run from the context menu. The log is smart enough to now that the cu rrent test starts when the project items execution begins, and ends when the exec ution stops. A project item (for example, script) can call other project items o r run applications that access the Log object - the current test goes on until the execution of the parent item is finished. The only thing you cannot do is run sev eral tests on the same computer in parallel. For each test, the log records start, stop, duration and completion (non-complet ion means the test could not continue to the end). The log has a tree-li e structure similar to the structure of the executed test items. Each node in this tree has a specific format of results (this format depe nds on the project item, where a test item is based). For instance, the log of a script execution is a tree-li e structure of messages. TestComplete supports a large variety of ways to differentiate these messages: It automatically logs the exact message time, so you can easily get the time spe nt between any two messages. Each message is posted according to one of the following message types - Error, Warning, Picture, File, Lin , Event and the ordinary Message (called information message in the Help to differentiate it). Each message can have an image associated with it. Each message also has a priority level. Messages contain text, additional comments (or remar s) and images. Related messages can be organized into folders within the log. Finally, filters can easily be defined to create reports of any type. If your script or other test code does not post messages to the log, the only me ssages you will find are possible error messages from TestComplete itself. There fore, unless you are simply trying out a test, the one thing it must do is post messages. This cannot be recorded, you have to write script code for it. Stores of Images, Files and Object Properties You may add the Stores project item to each TestComplete project. This project i tem contains a collection of images, files and object properties that allow for the comparison of test results. This is the very core of regression testing. One regression test can easily involve thousands of comparisons. However, other for ms of testing also need a validated reference during automation. Each Stores col lection has a corresponding program object which has methods meant to allow for this to be done automatically, and only report unexpected results. To understand this further, first see Testing With TestComplete in TestComplete help, and the n Regions Object, Objects Object and Files Object. You will probably use the Stores most often for storing the object's properties (that is, collections of object properties). Note that you can store a property collection directly from the Object Browser. This means that you can bring up th e application to be tested, run it to a point where you want to save the state o f something, then use the Browser to save this (using an option in its context m enu). You can do the same while recording, and the save-collection action will b

ecome part of the recording. See Comparing and Finding Images, Comparing Files a nd Saving and Comparing Object Properties in TestComplete help. Finally, a small note about image support. The Regions object, which is the obje ct for images, handles regions of images (sub-rectangles) just as well as entire image files. It will not only compare two images, but search for one within ano ther. Its viewer lets you define any rectangle within the current image, and sav e that to a second file. Loo ing Inside Applications TestCompletes Object Browser will show you a lot of detail about onscreen objects of random applications (li e Notepad or even TestComplete itself). For applicat ions compiled with the supported development tools and for Web pages, it shows m ore because it uses special object-recognition code for their standard UI librar ies. Some plug-ins provide deeper access to application internals. For example, the UI Automation Support plug-in retrieves window properties provided by Micros oft UI Automation Framewor ; the MSAA Open Applications plug-in exposes methods and properties of windows that implement the IAccessible interface (this lets yo u wor with windows of Sybase PowerBuilder, Microsoft Access or Visual FoxPro ap plications). Also, general access is gained to Win32 API, functions located in D LLs, .NET assemblies, Microsofts ADO and Borlands BDE database access engines. Applications can also test themselves using their own code, and access to applic ation objects is usually not a problem. However, even when applications are test ed externally, there is no reason to remain at a simple level. Where possible, t ested applications should be Open Applications. They should be compiled in a spe cial way in order to provide complete access to their objects, properties and me thods (.NET, Java, Visual Basic and WPF applications do not require special comp ilation). Compiling the application as an Open Application is fairly simple. To try it, pl ease view the Open Applications topic. Once your application is open loo at it th rough the Object Browser. You will see that one fairly easy step has multiplied the access to application objects for your test code. You can test much closer t o the design level, and much more conveniently. This one-step produces different degrees of openness depending on the developmen t tool. For Object Pascal code, which is used by Borland Delphi (exclusively) an d C++Builder (in part, especially for the VCL), there is a further step availabl e for opening up application classes -- PRegister. If an Open Application is also compiled with external debugger information, Test Complete has an exclusive technology called Debug Info Agent. Debug Info Agent wor s at test time to access practically all internal elements of the application u nder test, even private properties. See Debug Info Agent in TestComplete help for more information. Note: We would li e to note that .NET, Visual Basic, WPF and Java applications are opened by special plug-ins and there is no need to recompile these applicatio ns in order to get access to their internal objects, methods and properties. Testing Through Application Code TestCompletes services are provided through an OLE server. The entire user interf ace is simply a client of this server. By lin ing in just one file, an applicati on can put itself in the place of the TestComplete user interface and run the OL E server directly, for whatever purpose. We call this a Connected Application. The most common thing a Connected Application will do is run tests in its own so urce code (see Self-Testing Applications in TestComplete help). This is usually the easiest way to do unit tests (see Testing With TestComplete in TestComplete help). Connected Applications can also be used to run tests on other applications and p rovides more control over test conditions, since the TestComplete engine is comm anded from source code rather than the user interface, and because it is conveni ent to write test code in your normal programming language and use the preferred IDE for debugging. In addition to running tests, Connected Applications can be used to control the TestComplete engine for other various reasons. For instance, you might want to r un a specific series of tests at a given time, which tests are to be run would d

epend on the conditions at that time. All of these can be done from a rather sim ple Connected Application. Of course, application code in a Connected Application still has access to all o f the objects a script uses. These are all OLE objects, and the needed interface is in the file that you lin to. The following figure explains the relations between TestComplete and other appli cations (Open, Connected and General applications): Creating a Project Projects are at the core of TestComplete. A project contains all of the informat ion about one or more applications that you test. However, for a complex applica tion you may choose to devote a project to just one part of the application, and other projects to other parts (normally, modules). Note: We will illustrate each step of this Getting Started section with the Or ders sample application, which is installed in the <TestComplete>\Samples\Open A pps\OrdersDemo folder. Please compile this application before you proceed with Getting Started. If you have compilation problems, you can download the compiled executable from http://www.automatedqa.com/downloads/testcomplete/tc5_samples.asp. To create a new test project: Select File | New | New Project from TestCompletes main menu. This will call the Create New Project dialog where you can specify the project name, location, temp late, scripting language and the name and location of the project suite. Enter Orders as the project name and OrdersSuite as the project suite name. Test Complete will automatically generate the project path and display it in the Actu al location field. Note that if the path is too long, TestComplete will shorten it by replacing some part of it with ellipsis. To view the complete path, move t he mouse pointer over the Actual location field. The project folder will be used to store all information generated for or by the project -- scripts, results log, stores, and so on. Lets eep this path. If you have a project suite open in TestComplete, select the Create a new projec t suite chec box (we will add the Orders project to the new suite). Then specify the project language, say VBScript. Note: TestComplete is equally oriented to VBScript, JScript, DelphiScript, C++ Script and C#Script, therefore it allows you to select the language you now. Yo u will be able to use all of TestCompletes features regardless of the language yo u choose. However, due to the fact that languages have different syntax and thei r script instructions are executed by different scripting engines, there are som e exceptions. For more information, see Selecting the Scripting Language in Test Complete help. We would li e to also note that the scripting language does not depend on your t ested applications programming language. For instance, you can use JScript to tes t Visual C++ applications, or VBScript to test Delphi programs. There is one rec ommendation: if you plan to create a Connected or Self-Testing Application, you should select the language that matches the development tool that the applicatio n was created in. For example, if you use Visual C++ or C++Builder, you should s elect C++Script; if you use Visual Basic, select VBScript, and so forth. This wi ll ma e it easier to import recorded scripts to Connected and Self-Testing Appli cations. Now, after you specified the project name, location and scripting language, you can specify the project template. Project templates define which project items y our project will contain. The set of project items determines what testing actio ns a project can perform. The template specifies which of the project items will be included in your project by default. You can modify the set of enabled items using the Project wizard that is shown after you clic OK in the Create New Pro ject dialog. You can also add the desired project items any time later. For more information on this, see Adding and Removing Project Items and Their Child Elem ents in TestComplete help.

 Select any template in the Templates box. Clic OK in the Create New Project dialog. TestComplete will open the Project wi zard where you can modify the project items to be included in the project. Now lets select project items for our sample project. It will contain scripts, a list of tested applications and stores: Unchec all the items in the Project Items list except for the Script item (as f or tested applications, we will add them later to demonstrate how to add items t o existing projects. Stores will be added during the script recording). Note tha t the Events item can only be unchec ed if the Insert general events in new proj ects option in the Events Options dialog is disabled. Clic Next to switch to the next page of the dialog. Switch to the Script page. Here you can add one or more script units to your pro ject. By default, TestComplete creates one unit named Unit1. This is enough for our sample project and there is no need to create more units. Press Finish in the wizard. TestComplete will create a new project file, Orders. mds, with the Unit1 script unit and display the projects contents in the Project Explorer panel. Defining Applications to Test Each project may have a list of tested applications. This is a way for you to e ep trac of which applications the project deals with and how they are configure d for testing. It also allows TestComplete to launch all applications in the lis t or only those applications that are enabled to be launched manually via the co ntext menu, or from a script. Of course, since projects are independent from one another, any application may be in more than one projects list. To add a Win32 tested application to our project, we first need to add the Win32 Tested Applications project item. To do this: Right-clic the project node in the Project Explorer panel and select Add | New Item from the context menu. This will call the Create Project Item dialog. In the dialog: Select the Win32 Tested Applications item. Keep the value displayed in the Location box unchanged (this value specifies the folder where the .tcTAs file contains the tested application's settings). Press OK. TestComplete will add the Win32 Tested Application project item, TestedApps, to your project and show it in the Project Explorer panel. Now we can add our sample application to the tested applications list: Right-clic the TestedApps node in the Project Explorer panel. Choose Add | New Item from the context menu. The standard Open File dialog will appear. Locate Orders.exe using this dialog and then clic Open. The source code of this application resides in the <TestComplete>\Samples\Open A pps\OrdersDemo folder. As it was stated in the previous topic, Creating a Projec t, you should compile this application or download a compiled version from http: //www.automatedqa.com/downloads/testcomplete/tc5_samples.asp. In this tutorial, we use the Orders application compiled with Visual Basic 6.0. So, if you installed TestComplete to the default location, the path to Orders.ex e loo s li e this: C:\Program Files\Automated QA\TestComplete 5\Samples\Open App s\OrderDemo\VB\Orders.exe. Now, the sample application is in the list and we can specify command-line argum ents for it: Double-clic the TestedApps | Orders node in the Project Explorer panel. TestCom plete will show the available settings in the TestedApps editor. Now we should select the applications run mode. A tested application can be launc hed in several modes: Simple, RunAs, Debug or Profile. The Simple mode is simila r to launching the application from Windows Explorer or the command line window.

Using the RunAs mode you can launch the application under a different user acco unt than TestComplete is currently running under. Debug mode is similar to Simpl e, but TestComplete will act as a debugger for the application and will report i nformation about events and errors that occur during the application run. Finall y, Profile mode is used to debug and profile the application with AQtime. For mo re information on these modes, see Run Modes in TestComplete help. For our sample application we will use Simple run mode. This mode is used by def ault for tested applications. Loo at the Run Mode column and ma e sure the Simp le mode is selected: Now we will change the applications command line. To do this, press the ellipsis button within the Parameters column. This will call the Parameters dialog. Type -NOTOPENAPP or /NOTOPENAPP in the Command-line parameters edit box. We will explain this command-line argument later (see Exploring the Application in the Object Browser in TestComplete help). Press OK to close the dialog. Save your changes by selecting File | Save from TestCompletes main menu. As you can see, all application parameters (command line, wor folder and so on) can be set in one place. As stated above, one purpose of the tested applications list is to provide you w ith a way to launch all applications before you start recording a script. Of cou rse, you can record the launch of an application, but that is inefficient for a number of reasons: the manner of launching from a des top is cumbersome and/or f ragile (a shortcut icon can be hidden), providing special parameters is impossib le, and so forth. It is easier and more adaptable to have all the launch specifications you may ne ed in the list, and to unchec anything that is not needed for the current run ( in the Launch column). Then you choose Run Selected or Run All from the context menu and wait until the applications main window appears on screen: After the applications main window becomes visible, you can record your actions o ver it. We will see this in the next step. Exploring the Application in the Object Browser Before recording or running a script, you can explore what properties, fields, m ethods and events of your applications object TestComplete has access to. As the Introduction states, TestComplete can access almost all application objects, met hods and properties, even if they are not part of the application UI. The Object Browser panel shows you exactly what is available to your scripts: The tree view on the left contains a list of processes that are currently runnin g in the operating system and their windows. All processes are direct children o f System (the Sys object in scripts), and windows are children of the process th at opened them. In TestComplete terms, processes and windows are objects, and th is is how they are represented in scripts (see How TestComplete Recognizes Proce ss, Windows and Controls in TestComplete help). The right pane displays the selected objects methods and properties that are avai lable to scripts. If you use Windows Vista and you do not see an existing process in the Object Br owser, most li ely the process and TestComplete have different permissions. In o rder for TestComplete to be able to test applications under Windows Vista, it mu st have the same permissions as the application. See Testing Applications With T estComplete Under Windows Vista in TestComplete help. Now we can explore our sample application. To launch the application, right-clic the application node (Orders) in the Proj ect Explorer panel (the application node is a child node of the Orders | TestedA pps node) and select Run from the context menu. Find the application in the Object Browser tree view (to find the application qu ic er, you can right-clic the tree view, select Process Filter from the context

menu and then select the Orders process in the following Process Filter dialog) . Expand the application node and loo at its windows and their properties. The ri ght pane displays properties and methods that can be used in scripts (see the im age below). Note: The following image displays the properties, methods and objects of the Orders application created in Visual Basic 6.0. The properties, methods, window class names and the whole object structure that you see in the Object Browser on your computer may differ from what is displayed in the image. The information y ou see depends on the development tool, which you used to compile the tested app lication. For instance, the object and property names, and events for the object structure of Visual C++ 6 applications may differ from object names, properties and structure of .NET applications. Currently, the windows of the Orders application contain only TestComplete-defin ed properties, not those defined in the application source. This may be enough t o test important parts of some Windows applications, since TestComplete supports almost all standard Windows controls: list views, combo boxes, tree views, and so on. If you want to dig deeper into the application, you must compile it as an Open A pplication. In this case, objects, methods and properties defined in the source code become available to TestComplete scripts. Open Applications can be created in any supported compiler. For some compilers, there is more than one way to cre ate an Open Application. Each variant provides a different degree of openness. P lease read Open Applications for more information. The Orders application is already compiled as an Open Application. It provides m aximum openness, that is, it ma es all public, published and protected elements (with some restrictions) accessible to TestComplete and script routines. TestCom plete does not have access to internal properties and methods because we have sp ecified the -NotOpenApp command-line argument for it. Lets change the command lin e: Close the Orders application. Double-clic the application node in the Project Explorer panel. TestComplete wi ll show the list of the tested applications in the Wor space panel. Press the ellipsis button within the Parameters column. In the resulting Parameters dialog, remove -NotOpenApp from the Command-line par ameters edit box. Press OK to close the dialog. Save the changes by selecting File | Save from TestCompletes main menu (this menu item can be disabled, if you accidentally selected a project item other than Te stedApps in the Project Explorer). Right-clic the applications node in the Project Explorer panel and choose Run fr om the context menu. TestComplete will launch the Orders application and you wil l be able to explore the applications objects in the Object Browser: The Object Browser now displays a special icon ( ) for the Orders process. The i con indicates that TestComplete recognizes the Orders application as an Open App lication. The Object tree shows a list of internal applications objects. The image above sh ows the objects of the Orders application compiled with Visual Basic (these obje cts are addressed as VBObject("Object_Name")). If you compile the Orders applica tion with another compiler, TestComplete will address the objects using another method: WinFormsObject, VCLObject, SwingObject, and so on. If the TestComplete 3 Compatibility plug-in is installed, TestComplete will emulate the functionality of the previous versions of TestComplete and will address objects by their name s: MainForm, ImageList1, and so forth. Since version 4, TestComplete uses other principles for addressing objects where previous versions of the product did not . From this point forward, we will assume that the compatibility plug-in is not installed. The right portion of the Object Browser displays properties and methods of the o

bject selected in the object tree. The method and property lists include methods and properties defined in the applications source code as well as methods and pr operties introduced by TestComplete. Note that some methods and properties are u navailable to TestComplete (see Object Properties, Fields and Methods That Are U navailable to TestComplete). Also, protected and private properties are hidden f rom the panel by default. For more information on this, see Access to Properties . Lets try something. Change the main application forms caption by locating the form in the tree view, switching to the right pane, finding the Caption property and typing a new caption. The form caption will be changed. You have literally chan ged Orders internal data, and the next screen update reflects the new data. Note: For Visual C++ applications this procedure cannot be executed from the B rowser, since Visual C++ applications do not have properties. However, scripts c an call the appropriate Visual C++ method in order to achieve the same effect. Note that some methods and properties remain unavailable to TestComplete even if the application is compiled as an Open Application. There are a number of reaso ns for this. Typically, it occurs with non-OLE-compatible properties, with metho ds containing non-OLE-compatible parameters or return values. See Object Propert ies Fields and Methods That Are Unavailable to TestComplete in TestComplete help for more information. Some Read/Write properties are displayed as Read-Only ( ) or Write-Only ( ). T hese properties will be Read-Only or Write-Only in scripts. Usually, this means that the application does not call the other function, write or read, so it is not compiled. The following properties of Visual Basic applications are not accessible to interprocess calls: Icon Image MouseIcon Palette Picture As a result, if you try to view these properties via the Object Browser, an erro r will occur in the Visual Basic application you are exploring. One last feature of the Browser is that it lets you explore the internal structu re of the systems OLE objects if you now their ProgID, for instance WORD.APPLICA TION or SCRIPTING.FILESYSTEMOBJECT. Try the following: In the tree view select the root node (Sys). Find the OleObject property in the right pane. Clic the Params button. This will call a small dialog. Assuming Word is installed on your machine (open or not), enter its ProgID, WORD .APPLICATION, in the dialog and press OK. (Note that you can use CLSID as well a s ProgID). Wait until the OleObject property displays IDispatch for a value. This means you supplied a correct ProgID and TestComplete successfully obtained an IDispatch i nterface from the Sys object. In other words, OleObject acts as an array propert y, indexed on all of the systems valid ProgID strings. Supply a valid index, and a valid value will be created for it (the IDispatch interface that is now availa ble). This new value (IDispatch), in turn, displays its own ellipsis button. Press it to explore the desired OLE object. Creating Tests General Notes Before you create a new test, you should plan it: Define the test goal (decide which application functionality to be tested). The clearer the goal and the simpler the test, the better. Do not create tests t hat will test various aspects of the applications behavior at one run. It is bett er to create a simple test that is aimed at one objective only. Such tests are e asier to create and maintain. Once you create several simple tests, you can alwa ys organize them into a larger test.

 Plan testing steps (decide which actions the test will perform). The testing steps depend on the test purpose and the nature of the application u nder test. For instance, testing of a Web server may require simulating an exten sive load, which requires the recording and playbac of HTTP traffic to that ser ver, while testing of an image editor may need the recording and playbac of mou se movements and presses and releases of mouse buttons. TestComplete lets you si mulate these and other actions over the applications under test. Testing steps may include actions that prepare the application for the test (tha t is, they put the application to some initial state). Also, testing steps may feed corresponding input to the application. Chec test results (decide how to determine that the test passed successfully or failed). After the testing actions are finished, the test should chec the results agains t the expected output and decide whether the test was successful or not. Typical ly, after the application performed some actions, something changed in that appl ication: data in an application window can be rearranged, a new window may be cr eated, a file can be created on or deleted from your hard dis , and so on. You s hould determine what facts will be used as the fail (or success) criteria. Logging the result (determine how you will log the test result). The test results can be logged in different ways, for instance, your test script s can save the full test results to a file or show an on screen image notifying you that the test run is over. TestComplete trac s all simulated actions during the test run and saves the info rmation on these actions to the test log. Of course, you can post custom message s, image, files or file lin s to the log. The messages can be organized into fol ders and each message may use specific font and bac ground settings to display. The results can be exported to a file, compressed and sent via e-mail to your co -wor ers. You can even create a bug report in an issue-trac ing system directly from test results shown in the log. See Test Log for more information. After you have planned your test, you can create it. The basic test sequence inc ludes the following steps: 1. Define expected output. 2. Feed corresponding input. 3. Gather output. 4. Compare to expected output. 5. Call for attention if the comparison fails. These items can be divided into a sequence of smaller substeps, each of which wi ll perform a smaller tas . We call these substeps test items. A TestComplete project holds one or more project items. Some project items (for instance, Script) or their child elements (script routines) may be used as a sou rce of tests. That is, a project item or its child element may be used as a test item - it can be executed as a test or a subtest. Projects themselves can also be used as test items: this happens when you create tests for project suites. What actually happens when you execute a test item is determined by the properti es of that test item. For instance, if a test item executes a script routine, Te stComplete will run this routine; if a test item executes the Script project ite m, TestComplete will execute the script routine that is specified by the Main Ro utine property of that project item. If you command TestComplete to execute a pr oject, TestComplete will perform the test item defined by the projects properties . To create a test in TestComplete: Define the test purpose. Create source elements for test items (for instance, write or record a script, c reate a manual or unit test, record a low-level procedure, etc.). The test items created depend on your application and the test purpose. Specify the execution order of test items. Write a script that will chec and log the test result (if necessary). This item is optional, because some test items (for example, low-level procedures) automa tically post messages about their execution to the log. TestComplete provides va

rious ways that let you decide whether the test passed successfully. These inclu de special functions for comparing images, files and collections of object prope rties, script methods and properties that let you chec whether a window is visi ble or hidden, capture the window image, and so on. Creating a Test for the Orders Application The sample Orders application maintains a list of orders. Suppose we need to tes t whether the application generates the customer list correctly. In this case - Test purpose: The test should chec whether the Orders application generates the customer list properly. Testing steps: To generate the customer list, the user should select the Report | Generate customer list item from the main menu of the Orders application. One way to create a test that chec s the customer list is to write or record a scrip t or record a low-level procedure that will simulate the desired user actions. Y ou may even create several scripts (or low-level procedures): one of them may ca ll a form with a button on it, another - simulate user actions over the form, an d so forth. When the user presses the button to generate the customer list, the application calls the routine that generates the list. A possible alternative to simulating user actions is to call the applications routine that generates the list. This re quires TestComplete to have access to the internal applications objects, methods and properties, so that you can call this routine directly from your scripts. In order for TestComplete to have access to application internals, the application under test must be compiled as an Open Application. Though our sample application is compiled as an Open Application, we will follow the first approach: we will create a script that will simulate user actions. Chec ing and logging the test result: If the customer list has been generated su ccessfully, the Orders application creates a file that holds the customer names. To chec whether the list was generated successfully, our test can chec whethe r the file exists and then compare the generated file with the base-line copy st ored earlier. We will write script instructions that will perform the described chec ing and post an error message (if necessary) to the test log. Currently, our sample project does not include script routines, low-level proced ures or other project items that can be used as test items. Also, the test item sequence is not specified. In the next steps we will record a script routine and then use it as a test item. Recording a Test Script This topic provides general information about the recording capabilities offered by TestComplete and describes how to record a test script for the Orders applic ation. Recording in TestComplete With TestComplete you can record scripts, low-level procedures and HTTP traffic. To start the recording, select Script | Record from TestCompletes main menu or p ress Record on the Test Engine toolbar. This will switch TestComplete to the r ecording mode and display the Recording toolbar on the screen: The buttons on this toolbar support the recording process: for instance, one but ton ( ) captures images of windows and controls, another captures the whole scre en ( ) and a third saves object properties. The pictures and properties are save d to the Stores project item. Normally, these stored elements are used for compa rison. You can compare a saved snapshot with a later image of the same window to determine whether the window has changed. Besides saving images and properties, you can insert comments or additional code when recording scripts. Simply press Add Text To Script on the Recording tool bar. Do not hesitate to use this; we recommend that you comment your script as y ou record it, since this is the time when things are clearest in your mind. By default, once you initiate recording, TestComplete automatically starts recor ding a script. To record a low-level procedure, use the Record Low-Level Proce dure (screen coordinates) or Record Low-Level Procedure (window coordinates) b utton. To record HTTP traffic, use the Record an HTTP Tas button. For more in

formation on how to record low-level procedures or HTTP traffic, see Creating an d Recording Low-Level Procedures and Traffic Recording in TestComplete help. TestComplete records scripts as a series of instructions in one of the supported scripting languages: VBScript, JScript, DelphiScript, C++Script or C#Script. Yo u can use the Code Editor at any time to modify recorded scripts and to add spec ific non-recordable commands. By default, TestComplete always creates a new script routine before recording. Y ou can also record script code into the current position of the Code Editor. To do this, disable the Always start a new routine option. In this case, the way th e script is recorded depends on the insertion point position within the Code Edi tor window. If the insertion point is somewhere inside a script routine (procedu re or function), the script recorder will insert the recorder code into this pos ition. If the insertion point is outside an existing routine, the script recorde r will create a new routine before recording. TestComplete automatically creates a name for the new script. You can change thi s name in the Code Editor later. The name loo s li e TestN, where N is a number. TestComplete generates the routine name that does not coincide with the names o f other routines in the unit. However, this is possible only if the routines in the unit do not have syntax errors. Else, TestComplete will always name the new script routine Test1. If your project includes several script units, TestComplete will display a dialo g as ing you to select a unit where you would li e to include the recorded scrip t. When you start script recording, TestComplete automatically turns off the state of the CAPS LOCK ey. The same operation is performed when starting the test run . These actions ensure that TestComplete will correctly simulate eystro es. To avoid ma ing the script too dependent on the precise screen layout, and to e ep it readable and reasonably short, TestComplete, by default, only records eyb oard and mouse events that affect Windows controls. TestComplete does not, for i nstance, record the precise path of the mouse between clic s in different places , or the time elapsed between each eystro e. However, full-detail recording can be activated by simply using the low-level procedures. Also by default, TestComplete does not record the delay between user actions. Th is ma es the script faster and decreases its overall size. If time periods are c ritical, enable the Real-Time Mode option before recording. TestComplete records the delay between user actions when this option is enabled. As a result, you wi ll get a larger script, but it will be executed at the same speed as it was reco rded. You can of course remove the needless delay commands, and modify others to ma e the script run faster. For further information on options that affect reco rding, see Recording Options Dialog in TestComplete help. When we say TestComplete records user actions, we mean that it traces and record s eyboard and mouse events generated by these actions. Normally, the user actio n and recorded event does not differ from each other, for instance, when you cli c a button during recording, TestComplete records the mouse clic . However, dep ending on the functionality coded in the application under test the recorded act ion may differ from the action you performed. A typical example of this is an ap plication form that processes eystro es before they are passed to controls that lay on this form. For instance, if you press SPACE, the forms code may handle th e pressing and select or clear a chec box located on the form. In this case, Te stComplete will record the appropriate operation over the chec box rather than the SPACE eystro e. TestComplete lets you assign custom names to processes, windows and controls (se e Name Mapping in TestComplete help). If you assign a custom name to an object, the recorded script will use the mapped name to address the object. To stop the script recorder, press Stop on the Recording toolbar. You can use eyboard shortcuts to start or finish recording, and to control the recording process and playbac . Shortcuts free you from having to switch to the TestComplete window every time you want to start or stop recording. To customize the shortcuts, use the Shortcut Options dialog. TestComplete shortcuts override those used by other applications. For instance, an application may use SHIFT-F1

to display TestComplete help, but if TestComplete is running, pressing SHIFT-F1 will not call the Help window, it will start recording a script. Note: An application may implement menus using toolbar controls. For instance, the main menu of Windows Explorer is actually a Win32 toolbar control. When you r wor ing with these menus, eep in mind the following: The operating system opens a menu automatically when the mouse cursor is over th e item that provides access to the menu. When recording user actions with toolba r items, you should clic on each item you wish to open and do not use the autoopen feature. Otherwise, the recording may be incorrect. For instance, to record the selection of the File | New | Folder menu item in Windows Explorer, follow these steps: Move the mouse of the File item and clic this item. Clic New in the ensuing submenu. Finally, clic Folder in the subsequent sub-submenu. If your application implements menus using toolbar controls (li e Windows Explor er), you should use the described approach to record user actions over menu item s. If your application implements menus using standard Win32 menus, you can reco rd menu selections without clic ing on each menu item. To determine how your application implements menus, select the main window of yo ur application in the Object Browser, clic the ellipsis button of the MainMenu property and view the Count value. If it is 0, then your application implements menus using toolbar controls. Note: When recording user actions with standard Win32 menu items, do not selec t menu items using both mouse and eyboard shortcuts at the same time. Use only the mouse or eyboard to wor with the menu, otherwise, the recording may be inc orrect. Note: Currently, it is impossible to record eystro es when wor ing with conso le applications under Windows 98. This restriction does not exist in Windows XP. Note: To record scripts over web pages in Internet Explorer under Windows Vist a, both Internet Explorer and TestComplete must have administrator permissions. (See Testing Applications With TestComplete Under Windows Vista in TestComplete help) However, administrator permissions are not required to play bac a recorde d script. It is recommended that you add the Internet Explorer executable (<Program Files> \Internet Explorer\iexplore.exe) to the tested applications collection while hav ing administrator permissions for TestComplete. This way, the tested application launched from TestComplete will also have administrator privileges. Recording a Script for the Orders Application We are now ready to record a script for the Orders application. Lets record this script using a usual (non-open) application: Double-clic the Orders | TestedApps project item in the Project Explorer panel. TestComplete will show the list of tested applications in the Wor space. Press the ellipsis button in the Parameters cell and specify -NotOpenApp or /NotOpenAp p in the Command line parameters field of the resulting dialog. Close the dialog and return to the TestedApps editor. Right-clic somewhere within the Wor space panel and select Run All from the con text menu to run Orders. Select Script | Record from the main menu to start recording. Switch to the Orders application and select File | Open from its main menu. This will bring up the standard Open File dialog. In the dialog, choose MyTable.tbl. This file resides in the <TestComplete>\Sampl es\Open Apps\OrdersDemo folder. To open the file, you may need to clic the bu tton in the dialog (in order to move up in the folder hierarchy) and press Open. This will open a table with data in the application window. Select Samuel Clemens in the list of orders. Now we will capture an image - Press Capture Control on the Recording toolbar and do not release the mouse bu tton. Keep the mouse button pressed and move the cursor to the Orders toolbar. As you move the mouse, TestComplete highlights the window's control under the cursor us

ing a red frame. When the Orders toolbar is highlighted, release the mouse button. TestComplete w ill bring up the Image Viewer window and display the toolbar image in it. Let's add the image to the project. To do this: In the Image Viewer clic Add Image to Stores. TestComplete will add the Store s project item to your project and then it will show the standard Save File dial og. Save the image as Toolbar.bmp in 16 colors to the folder offered by the dialog. Upon saving, TestComplete will add the image to the Regions collection of the St ored project item. Note: It is recommended that you either capture and save screenshots using Tes tComplete, or create them using the Windows shortcuts (ALT-PRTSCN or PRTSCN) and save them using MSPaint. Other screenshot tools may save the images with slight errors which could generate incorrect results of image comparison and finding o perations. After you have added the image, TestComplete displays the Add Text To Script dia log with instructions for image comparison. The following image displays the comparison instructions in VBScript. The syntax of the instructions you see in the Add Text To Script dialog on your computer m ay differ from what is shown on the image. The actual code you see depends on th e scripting language you have selected for your TestComplete project on the Crea ting a Project step. Press Add to close this dialog. TestComplete will insert the comparison instruct ions into the script code. Close the Image Viewer window. After closing the Image Viewer window, we are bac to Orders. If you capture ima ges or save object properties during the recording, TestComplete pauses the reco rding. To continue, clic Record on the Recording toolbar. Move the mouse cursor to the Orders toolbar and press Edit order. This will ca ll the Edit Order dialog. In the dialog, select FamilyAlbum from the Product dropdown list. Select the value in the Card Nr edit field by dragging the mouse and then enter 123123123123 as a card number. Clic OK to close the dialog. Now you can export the customer list to a file. To do this: Select Report | Generate customer list from the main menu of the Orders applicat ion. Orders will display the Save File dialog. Enter C:\CustomerList.txt into the File name edit box of the Save File dialog. Clic OK to close the dialog. TestComplete will save the customer list into the specified file. Close the Orders window by clic ing the X button on the window's caption bar. Th is will display the dialog as ing if you want to save changes. Press No. Orders will close. Press Stop on the Recording toolbar to halt the recording. In the next step we will analyze the recorded instructions. Analyzing the Recorded Script The recorded script is added to and displayed in the Code Editor. Each script ap pears as a procedure coded in VBScript, JScript, DelphiScript, C++Script or C#Sc ript. More information about writing scripts is available in the next topic. Thi s topic only explains the recorded instructions. To open the Code Editor panel, right-clic the Script | Unit1 node in the Projec t Explorer panel and then choose Edit from the context menu, or simply double-cl ic the Script | Unit1 node. TestComplete will display the code of Unit1 in the Wor space panel. The recorded script code is similar to the code below. Your actual script may di ffer from this one. For example, it may have other class names or window indexes if you have recorded the script on a C# or Visual C++ application. [VBScript]

Sub Test1 Dim p1 Dim w1 Dim w2 Dim w3 Set p1 = Sys.Process("Orders") Set w1 = p1.Window("ThunderRT6FormDC", "*") Call w1.MainMenu.Clic ("File|Open...") Set w2 = p1.Window("#32770", "Open") Call w2.Window("ToolbarWindow32", "", 1).Clic Item(40961, False) Call w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic Item("MyTable.tbl", 0) Call w2.Window("Button", "&Open").Clic Button Call w1.Window("ListView20WndClass").Clic Item("Samuel Clemens", 0) If (Not Regions.Compare("Toolbar", Sys.Process("Orders").Window("ThunderRT6For mDC", "Orders - C:\Wor \TestComplete\Samples\Open Apps\OrdersDemo\MyTable.tbl", 1).Window("Toolbar20WndClass", "", 1).Window("msvb_lib_toolbar", "", 1))) Then Call Log.Error("The regions are not identical.") End If Call w1.Window("Toolbar20WndClass").Window("msvb_lib_toolbar").Clic Item(105, False) Set w2 = p1.Window("ThunderRT6FormDC", "Edit order") Call w2.Window("ThunderRT6ComboBox").Clic Item("FamilyAlbum") Set w3 = w2.Window("ThunderRT6TextBox", "", 2) Call w3.Drag(82, 12, -171, -5) Call w3.Keys("123123123123") Call w2.Window("ThunderRT6CommandButton", "OK").Clic Button Call w1.MainMenu.Clic ("Report|Generate customer list...") Set w2 = p1.Window("#32770", "Save") Call w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("c:\Cust omerList.txt") Call w2.Window("Button", "&Save").Clic Button Call w1.Close Call p1.Window("#32770", "Confirm").Window("Button", "&No").Clic Button End Sub [JScript] function Test1() { var p1; var w1; var w2; var w3; p1 = Sys.Process("Orders"); w1 = p1.Window("ThunderRT6FormDC", "*"); w1.MainMenu.Clic ("File|Open..."); w2 = p1.Window("#32770", "Open"); w2.Window("ToolbarWindow32", "", 1).Clic Item(40961, false); w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic Item("MyTable.tbl", 0); w2.Window("Button", "&Open").Clic Button(); w1.Window("ListView20WndClass").Clic Item("Samuel Clemens", 0); if(!Regions.Compare("Toolbar", Sys.Process("Orders").Window("ThunderRT6FormDC" , "*").Window("Toolbar20WndClass").Window("msvb_lib_toolbar"))) Log.Error("The regions are not identical."); w1.Window("Toolbar20WndClass").Window("msvb_lib_toolbar").Clic Item(105, false ); w2 = p1.Window("ThunderRT6FormDC", "Edit order"); w2.Window("ThunderRT6ComboBox").Clic Item("FamilyAlbum");

w3 = w2.Window("ThunderRT6TextBox", "", 2); w3.Drag(82, 12, -171, -5); w3.Keys("123123123123"); w2.Window("ThunderRT6CommandButton", "OK").Clic Button(); w1.MainMenu.Clic ("Report|Generate customer list..."); w2 = p1.Window("#32770", "Save"); w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("C:\\Customer List.txt"); w2.Window("Button", "&Save").Clic Button(); w1.Close(); p1.Window("#32770", "Confirm").Window("Button", "&No").Clic Button(); } [DelphiScript] procedure Test1; var p1 : OleVariant; var w1 : OleVariant; var w2 : OleVariant; var w3 : OleVariant; begin p1 := Sys.Process('Orders'); w1 := p1.Window('ThunderRT6FormDC', '*'); w1.MainMenu.Clic ('File|Open...'); w2 := p1.Window('#32770', 'Open'); w2.Window('ToolbarWindow32', '', 1).Clic Item(40961, false); w2.Window('SHELLDLL_DefView').Window('SysListView32', 'FolderView').Clic Item( 'MyTable.tbl', 0); w2.Window('Button', '&Open').Clic Button; w1.Window('ListView20WndClass').Clic Item('Samuel Clemens', 0); if not Regions.Compare('Toolbar', Sys.Process('Orders').Window('ThunderRT6Form DC', '*').Window('Toolbar20WndClass').Window('msvb_lib_toolbar')) then Log.Error('The regions are not identical.'); w1.Window('Toolbar20WndClass').Window('msvb_lib_toolbar').Clic Item(105, false ); w2 := p1.Window('ThunderRT6FormDC', 'Edit order'); w2.Window('ThunderRT6ComboBox').Clic Item('FamilyAlbum'); w3 := w2.Window('ThunderRT6TextBox', '', 2); w3.Drag(82, 12, -171, -5); w3.Keys('123123123123'); w2.Window('ThunderRT6CommandButton', 'OK').Clic Button; w1.MainMenu.Clic ('Report|Generate customer list...'); w2 := p1.Window('#32770', 'Save'); w2.Window('ComboBoxEx32').Window('ComboBox').Window('Edit').Keys('C:\CustomerL ist.txt'); w2.Window('Button', '&Save').Clic Button; w1.Close; p1.Window('#32770', 'Confirm').Window('Button', '&No').Clic Button; end; [C++Script, C#Script] function Test1() { var p1; var w1; var w2; var w3; p1 = Sys["Process"]("Orders"); w1 = p1["Window"]("ThunderRT6FormDC", "*"); w1["MainMenu"]["Clic "]("File|Open..."); w2 = p1["Window"]("#32770", "Open");

w2["Window"]("ToolbarWindow32", "", 1)["Clic Item"](40961, false); w2["Window"]("SHELLDLL_DefView")["Window"]("SysListView32", "FolderView")["Cli c Item"]("MyTable.tbl", 0); w2["Window"]("Button", "&Open")["Clic Button"](); w1["Window"]("ListView20WndClass")["Clic Item"]("Samuel Clemens", 0); if(!Regions["Compare"]("Toolbar", Sys["Process"]("Orders")["Window"]("ThunderR T6FormDC", "*")["Window"]("Toolbar20WndClass")["Window"]("msvb_lib_toolbar"))) Log["Error"]("The regions are not identical."); w1["Window"]("Toolbar20WndClass")["Window"]("msvb_lib_toolbar")["Clic Item"](1 05, false); w2 = p1["Window"]("ThunderRT6FormDC", "Edit order"); w2["Window"]("ThunderRT6ComboBox")["Clic Item"]("FamilyAlbum"); w3 = w2["Window"]("ThunderRT6TextBox", "", 2); w3["Drag"](82, 12, -171, -5); w3["Keys"]("123123123123"); w2["Window"]("ThunderRT6CommandButton", "OK")["Clic Button"](); w1["MainMenu"]["Clic "]("Report|Generate customer list..."); w2 = p1["Window"]("#32770", "Save"); w2["Window"]("ComboBoxEx32")["Window"]("ComboBox")["Window"]("Edit")["Keys"](" C:\\CustomerList.txt"); w2["Window"]("Button", "&Save")["Clic Button"](); w1["Close"](); p1["Window"]("#32770", "Confirm")["Window']("Button", "&No")["Clic Button"](); } The script starts with variable declarations. TestComplete automatically detects what objects (process, windows, controls, etc.) you recorded with user actions and defines the appropriate number of variables. [VBScript] Dim p1 Dim w1 Dim w2 Dim w3 [JScript] var p1; var w1; var w2; var w3; [DelphiScript] var p1 : OleVariant; var w1 : OleVariant; var w2 : OleVariant; var w3 : OleVariant; [C++Script, C#Script] var p1; var w1; var w2; var w3; After variable declarations the two following lines are -[VBScript] Set p1 = Sys.Process("Orders.exe") Set w1 = p1.Window("ThunderRT6FormDC", "*") [JScript] p1 = Sys.Process("Orders"); w1 = p1.Window("ThunderRT6FormDC", "*"); [DelphiScript]

p1 := Sys.Process('Orders'); w1 := p1.Window('ThunderRT6FormDC', '*'); [C++Script, C#Script] p1 = Sys["Process"]("Orders"); w1 = p1["Window"]("ThunderRT6FormDC", "*"); TestComplete provides special program objects to wor with processes and windows from scripts. The Sys.Process function returns the process object that represen ts the application in scripts. This method will be executed successfully only if the process (that is, the appl ication) exists in the system. Otherwise, TestComplete will generate an error an d post it to the test log. How then, would you run the application from the scri pt? Normally, by calling TestedApps.RunAll at the beginning of the script. It la unches any application chec ed in the Tested Applications list. The next method after Sys.Process is p1.Window(...). This is a method of the pro cess object. It returns the window object for a window created by the process (p 1). It uses the window class name, caption and window index (similar to z-order) as parameters. Only the first two parameters are used; the third one is omitted : TestComplete may not record the index if the class name and caption are enough for window recognition. Note that TestComplete recorded the * wildcard instead of the window caption. Th is was done to ma e the script more universal. The window caption is an unstable window attribute. It can be modified several times during the run. Replacing th e variable part of the window caption with wildcard characters (* and ?) guarant ees that the script will wor when the caption is changed. You can use wildcards in the window class name as well. This is necessary for so me MFC windows whose class name (li e Afx:400000:823:10011:0:0) changes from one application run to another. If the Auto-correct Afx window classes option is en abled, TestComplete automatically inserts wildcards in the class name during rec ording. To specify an asteris as part of the window caption or class name, use double a steris s (for example, MyWndCaption**). If the specified window does not exist, Window() posts an error message to the t est log. Objects that do not exist are always something to worry about with exte rnal scripts dealing with processes or windows. Than fully, every system object supports an Exists property that lets you chec first. For instance: [VBScript] Set p2 = Sys.Process("MyProcess") ' Do something here If Not p2.Exists Then ' Process was closed [JScript] p2 = Sys.Process("MyProcess"); // Do something here if (!p2.Exists) // Process was closed [DelphiScript] p2 := Sys.Process('MyProcess'); // Do something here if not p2.Exists then // Process was closed [C++Script, C#Script] p2 = Sys["Process"]("MyProcess"); // Do something here if (!p2["Exists"]) // Process was closed Bac to process.Window(). At this point, we do not want to find out if the windo

w exists or not. We just want to pause the script until it does exist. For this, we can use the WaitWindow function. It delays the execution for a specified num ber of milliseconds, or until a specified window appears on screen. There is a s imilar function for processes -- WaitProcess. Another way to pause the script un til the desired window appears on screen is to use process.Window() and increase the value of the Auto-wait timeout project property. For more information, see Waiting for a Process or Window Activation, Waiting for Object State Changes, De laying the Script Execution and WaitChild in TestComplete help. Note that if needed, you may map the long process and window names to a shorter an d more readable string. See Name Mapping in TestComplete help. The next line in the script is -[VBScript] Call w1.MainMenu.Clic ("File|Open...") [JScript] w1.MainMenu.Clic ("File|Open..."); [DelphiScript] w1.MainMenu.Clic ('File|Open...'); [C++Script, C#Script] w1["MainMenu"]["Clic "]("File|Open..."); It selects File | Open from Orders main menu. The name of the desired menu item i s passed to the Clic method of the MainMenu object. Item names in the item path a re separated by vertical lines. Note that you can address menu items by either their names, or by indexes. The m enu item names can be used if the menu item has no picture and the application d isplays the item in the standard way (that is, if the style of menu items is not MFT_BITMAP or MFT_OWNERDRAW). Indexes let you wor with menu items that cannot be addressed by their captions. Of course, item names ma e the script more reada ble, but indexes are more universal and wor for almost all item types. If you a re not sure how to address menu items, we recommend that you use indexes. See al so Simulating User Actions in TestComplete help. These lines come after a menu item is selected: [VBScript] Set w2 = p1.Window("#32770", "Open") Call w2.Window("ToolbarWindow32", "", 1).Clic Item(40961, False) Call w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic It em("MyTable.tbl", 0) Call w2.Window("Button", "&Open").Clic Button [JScript] w2 = p1.Window("#32770", "Open"); w2.Window("ToolbarWindow32", "", 1).Clic Item(40961, false); w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic Item("M yTable.tbl", 0); w2.Window("Button", "&Open").Clic Button(); [DelphiScript] w2 := p1.Window('#32770', 'Open'); w2.Window('ToolbarWindow32', '', 1).Clic Item(40961, false); w2.Window('SHELLDLL_DefView').Window('SysListView32', 'FolderView').Clic Item('M yTable.tbl', 0); w2.Window('Button', '&Open').Clic Button; [C++Script, C#Script] w2 = p1["Window"]("#32770", "Open"); w2["Window"]("ToolbarWindow32", "", 1)["Clic Item"](40961, false); w2["Window"]("SHELLDLL_DefView")["Window"]("SysListView32", "FolderView")["Clic Item"]("MyTable.tbl", 0);

w2["Window"]("Button", "&Open")["Clic Button"](); What do they do? The first line, w2 = p1.Window("#32770", "Open"), returns a win dow object that corresponds to the standard Open File dialog. The second line si mulates a clic on the button of the Open File dialogs toolbar. 40961 is this b uttons ID. The next two lines simulate user actions in the dialog. We will ta e them one at a time: [VBScript] Call w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic It em("MyTable.tbl", 0) [JScript] w2.Window("SHELLDLL_DefView").Window("SysListView32", "FolderView").Clic Item("M yTable.tbl", 0); [DelphiScript] w2.Window('SHELLDLL_DefView').Window('SysListView32', 'FolderView').Clic Item('M yTable.tbl', 0); [C++Script, C#Script] w2["Window"]("SHELLDLL_DefView")["Window"]("SysListView32", "FolderView")["Clic Item"]("MyTable.tbl", 0); Here, w2 is a window object that represents the Open File dialog. This dialog co ntains a list of files in a folder on your hard dis . The list is displayed in a ListView control, which is a child window for the dialog. Window("SysListView32 ", "FolderView") returns a window object for this ListView. The Clic Item method simulates a mouse clic on the MyTable.tbl item in the list . TestComplete automatically adds the Clic Item method to any window object that it recognizes as a list view control. To determine that a window is a list view window, TestComplete chec s the window class name with the name given by defaul t to windows of this type. If the names coincide, TestComplete treats the window as a list view control. Similarly, TestComplete determines the type of other wi ndows. If the window class name differs from the default name, TestComplete uses Object Mapping settings to determine the window type. Once TestComplete determi nes the window type it adds methods and properties specific to windows of that t ype to the window object. All of TestComplete's program objects for Windows cont rols have several methods to simulate mouse clic s within the controls. These me thods let you simulate the clic of an item displayed in the control, or simply simulate mouse clic s using specified coordinates. The next line in the script -[VBScript] Call w2.Window("Button", "&Open").Clic Button [JScript] w2.Window("Button", "&Open").Clic Button(); [DelphiScript] w2.Window('Button', '&Open').Clic Button; [C++Script, C#Script] w2["Window"]("Button", "&Open")["Clic Button"](); -- simulates pressing the Open button in the dialog. Pressing this button closes the Open File dialog. Note: When recording a script, TestComplete uses the same process, window and control names that are are displayed in the Object Browser panel. These names un iquely identify the object of the application under test, but can sometimes be t oo long and hard to understand. You can create a custom name for an object by us ing Name Mapping functionality and TestComplete will use this name during record ing. By using the Name Mapping feature you will have clearer and more readable c ode. For more information on name mapping, creating custom names and using them

when recording scripts, see Name Mapping, Adding Name Mapping Items and Name Map ping and Script Recording in TestComplete help. The next instruction in the script returns us to Orders main window and simulates a mouse clic on the Samuel Clemens node in the list: [VBScript] Call w1.Window("ListView20WndClass").Clic Item("Samuel Clemens", 0) [JScript] w1.Window("ListView20WndClass").Clic Item("Samuel Clemens", 0); [DelphiScript] w1.Window('ListView20WndClass').Clic Item('Samuel Clemens', 0); [C++Script, C#Script] w1["Window"]("ListView20WndClass")["Clic Item"]("Samuel Clemens", 0); Note that we do not use any special command to activate the window where the scr ipt will send the clic . TestComplete automatically activates the appropriate wind ow. Also note, that the window caption is not used to address the list view control on the main form of the Orders application ( w1.Window("ListView20WndClass"). Th e name is omitted because the form only contains one control with the class name ListView20WndClass. Now we have reached the instructions that were inserted into the script when we saved an image during recording: If Not... End If. Jumping ahead, the Clic meth od that follows these instructions, simulates the pressing of a button on the ap plication toolbar: [VBScript] If (Not Regions.Compare("Toolbar", Sys.Process("Orders").Window("ThunderRT6FormD C", "Orders - C:\Wor \TestComplete\Samples\Open Apps\OrdersDemo\MyTable.tbl", 1) .Window("Toolbar20WndClass", "", 1).Window("msvb_lib_toolbar", "", 1))) Then Call Log.Error("The regions are not identical.") End If Call w1.Window("Toolbar20WndClass").Window("msvb_lib_toolbar").Clic Item(105, Fa lse) [JScript] if(!Regions.Compare("Toolbar", Sys.Process("Orders").Window("ThunderRT6FormDC", "*").Window("Toolbar20WndClass").Window("msvb_lib_toolbar"))) Log.Error("The regions are not identical."); w1.Window("Toolbar20WndClass").Window("msvb_lib_toolbar").Clic Item(105, false); [DelphiScript] if not Regions.Compare('Toolbar', Sys.Process('Orders').Window('ThunderRT6FormDC ', '*').Window('Toolbar20WndClass').Window('msvb_lib_toolbar')) then Log.Error('The regions are not identical.'); w1.Window('Toolbar20WndClass').Window('msvb_lib_toolbar').Clic Item(105, false); [C++Script, C#Script] if(!Regions["Compare"]("Toolbar", Sys["Process"]("Orders")["Window"]("ThunderRT6 FormDC", "*")["Window"]("Toolbar20WndClass")["Window"]("msvb_lib_toolbar"))) Log["Error"]("The regions are not identical."); w1["Window"]("Toolbar20WndClass")["Window"]("msvb_lib_toolbar")["Clic Item"](105 , false); It is recommended that you create screenshots using the Windows shortcuts (ALT-P RTSCN or PRTSCN) and save them using MSPaint, or capture and save images using T estComplete. Other screenshot applications may save the images with errors, whic h may cause incorrect results of image comparisons and finding operations. To compare images, we call the Regions.Compare method. The full version of this method uses four parameters. In our case, only two are used: the first parameter is the picture which was saved to the Regions collection of the Stores project

item as Toolbar.bmp, and the second is the control on the screen. The omitted pa rameters allow you to exclude transparent pixels from comparison and ta e into a ccount the mouse cursor image. See Regions.Compare in TestComplete help. TestComplete provides similar comparisons of methods for files and object proper ties saved to the Stores project item. For more information, see Compare and Fin ding Images, Comparing Files and Saving and Comparing Object Properties in TestC omplete help. Why do we need a comparison here? Suppose that developers change the Edit order buttons ID from 105 to 220 (also, the button id can depend on the compiler that w as used to create the application). Doing a comparison lets you chec for this, before assuming your script is still pressing the right buttons. Due to the way the inserted code is written, you will get a log message if the comparison fails . A more advanced solution would be to modify the script so that it is not dependa nt on button location: you can find the button image on the toolbar using the Re gions.Find method and then simulate a mouse clic in the found area. The only re quirement is that you must first save the image of the button you are loo ing fo r to a file. For more information on this, see Comparing and Finding Images and Regions.Find in TestComplete help. The rest of the script code does not require any further explanation. It contain s - Instructions that simulate user actions in the Edit order dialog. Instructions that simulate user actions when generating the customer list. Code used to close the application window and simulate user actions for the Save Changes request. All methods and properties used here have been explained above. Editing and Writing Scripts General Notes In many cases it is convenient to first record a script and then modify it in th e Code Editor. However, sometimes it may ma e sense for you to create new script s manually without recording anything. The Code Editor wor s well for this. It o ffers all modern editing features: Syntax highlighting Outlining Code templates Code navigation Text search and replace Clipboard capacities Etc. The Code Editor has a Code Completion window with a list of objects and global f unctions which you can use in your scripts. See the Code Editor description in T estComplete help for a detailed overview of all Editor features. Of course, scri pt code is text and you can edit it in any text editor. For more information on writing script code in TestComplete, please see Scriptin g in TestComplete help. Writing Comparison Code The goal of our test was to compare if the Orders application generates the cust omer list correctly. We recorded a script simulating user actions that export a list to a file. Now we have to write script code that compares the baseline copy of this file with the copy that will be generated by the script. We will use the C:\CustomerList.txt file generated during the script recording a s the baseline copy. Now we should add this file to our TestComplete project: Launch Windows Explorer or any other file manager utility and move the C:\Custom erList.txt file to the <Your_project>\Stores folder. Switch bac to TestComplete. Activate the Project Explorer panel. Right-clic the Stores | Files node in the Project Explorer and select Add | New Item from the context menu. TestComplete will show the standard Open File dialo g, where you can select the file to be added to the project. In the dialog select the file <Your_project>\Stores\CustomerList.txt and clic O

K. TestComplete will add the file to the Files collection of the Stores project item. Now we can write script code that will compare the files. To perform the compari son, we will use the Files.Compare method. In our example, the comparison code i s as follows -[VBScript] Sub CompareFiles If Files.Compare("CustomerList", "C:\CustomerList.txt") Then Log.Message "Files are identical." Else Log.Error "Files differ." End If End Sub [JScript] function CompareFiles () { if (Files.Compare("CustomerList", "C:\CustomerList.txt")) Log.Message("Files are identical.") else Log.Error("Files differ.") } [DelphiScript] procedure CompareFiles; begin if Files.Compare('CustomerList', 'C:\CustomerList.txt') then Log.Message ('Files are identical.') else Log.Error ('Files differ.') end; [C++Script, C#Script] function CompareFiles () { if (Files["Compare"]("CustomerList", "C:\CustomerList.txt")) Log["Message"]("Files are identical.") else Log["Error"]("Files differ.") } For more information on comparing files, see the Comparing Files topic in TestCo mplete help. In the next step we will include the CompareFiles routine into testing tas s and execute the test. Specifying Execution Order for Tests Once you have created the desired test items, you can specify their execution fl ow. To do this, you can use the Test Items page of the project editor. This page shows a tree-li e structure of existing tests and lets you modify this structur e as needed. Note that the project suite editor also contains the Test Items page. It lets yo u specify the execution order of projects, which belong to this suite, by draggi ng the projects in the page. The project editors Test Items page lets you organiz e tests of one project. In other words, when you command TestComplete to execute a project suite, it will execute projects in the order specified on the Test It ems page of the project suite editor. When you command TestComplete to execute a project, TestComplete will run tests defined with the Test Items page of the pr oject editor. Below you can see sample images of the Test Items pages of the pro ject suite's and project's editors. Test Items Page (Project Suite Editor)

Test Items Page (Project Editor) By default, for each new project, TestComplete creates a new test item that laun ches the routine specified by the Main routine property of the Scripts project it em. To add a new test item: Right-clic the project node in the Project Explorer panel and choose Edit from the context menu. TestComplete will show the project editor in the Wor space pan el. Clic Test Items at the bottom of the editor. TestComplete will open the Test It ems edit page containing a tree-li e structure of test items. By default, the pa ge has only one test item that is associated with the main routine of the Script project item. Lets modify the properties of the existing test item so that it wi ll be associated with the recorded script routine (Test1), but not with the main routine. To specify the test items source, press the ellipsis button of the Element to be run column. This will call the Select Test Item dialog. In the Select Test Item dialog choose Script | Unit1 | Test1 (the recorded scrip t routine) and then clic OK to save. TestComplete will display the selected element in the Element to be run column. Now lets add a test item for the CompareFiles routine we created in the previous step: Right-clic somewhere within the Test Item's edit page and choose New Item fro m the context menu. TestComplete will create a new empty test item. To specify the test items source, press the ellipsis button of the Element to be run column. This will call the Select Test Item dialog. In the Select Test Item dialog choose Script | Unit1 | CompareFiles and clic OK . TestComplete will display the selected element in the Element to be run column . Once you have created a new test item, you can modify its properties in a column of the Wor space panel. For instance, you can change the Count property to spec ify the number of times the test item will be executed, or modify the Timeout pr operty to set the maximum time period for an item's execution. If the test item' s execution time exceeds the specified timeout, TestComplete terminates the test item run and considers that the item failed to execute successfully. For more i nformation on properties, see Test Items Edit Page in TestComplete help. To modify a property, simply clic twice (not double-clic ) on the desired prope rty in the panel or select the property and press F2. In our example, we will not modify the item's properties. Note: Ma e sure that the test item is enabled, that is, the chec box on the le ft of the test items icon is selected. TestComplete executes a test item only if it is enabled. We only created two test items. They will perform all of the steps described in the Creating Tests topic. This is enough for our sample project. In real-life pr ojects, you will typically need to create more than two test items. You can crea te as many test items as needed. To change the position of a test item, simply drag it to the desired node in the Wor space panel or use the items of the Project Editor toolbar. If the toolbar is hidden, you can show it by right-clic ing the main menu area and selecting Pr oject Editor from the ensuing context menu (see Toolbars Customization in TestCo mplete help). To remove a test item, select it in the Wor space and then choose Delete from th e context menu. Note: Test execution can be initiated from a script. That is, you can specify the Main Routine for the Script project item and create a test item referring to the Script project item or directly to the main routine. All other test routine s, low-level procedures, unit tests, manual tests, and so forth, can be called f rom this main routine. For information on how to do this, see Calling Project El

ements From Scripts in TestComplete help. Running Tests Before running tests, you should have completed the following preliminary steps: Define the tests purpose. Create test items. Specify the test item's execution order. TestComplete can use different inds of tests: scripts, low-level procedures, an d so forth. Some of these tests can be recorded. Therefore, before running tests , ma e sure they start with the same initial conditions as the recording did. Fo r instance, the script almost always requires the tested application to be runni ng. To guarantee that the application is loaded, do one of the following: Double-clic the TestedApps node in the Project Explorer panel. This will open t he tested applications editor in the Wor space panel. Right-clic in the Wor spac e and choose Run All from the context menu. -- or - Call TestedApps.RunAll at the beginning of the testing script. [VBScript] Sub Test1 Dim p1 Dim w1 Dim w2 Dim w3 TestedApps.RunAll ' <-- Added line Set p1 = Sys.Process("Orders") ... [JScript] function Test1() { var p1; var w1; var w2; var w3; TestedApps.RunAll(); // <-- Added line p1 = Sys.Process("Orders"); ... [DelphiScript] procedure Test1; var p1 : OleVariant; var w1 : OleVariant; var w2 : OleVariant; var w3 : OleVariant; begin TestedApps.RunAll; // <-- Added line p1 := Sys.Process('Orders'); ... [C++Script, C#Script] function Test1() { var p1; var w1; var w2; var w3; TestedApps["RunAll"](); // <-- Added line p1 = Sys["Process"]("Orders"); ... Note that in both cases, TestComplete will launch the application according to t he run mode specified in the TestedApps editor.

Note also that if you launch an application under Windows Vista with administrat or privileges, the operating system will display a dialog box as ing for your pe rmission for the run. Due to certain limitations, the closing of this dialog box cannot be automated (when this dialog box is visible, the script run is paused) . You should either close the dialog manually, or modify User Account Control se tttings so that Windows does not display the dialog. See Testing Applications Wi th TestComplete Under Windows Vista in TestComplete help. The created tests are not compiled into an .exe for test runs. You run the tests directly from TestComplete. To run tests on computers that do not have TestComp lete installed, you can use a resource-friendly utility called TestExecute. You can also export script code to an external application and run it there. For mor e information on this, see Connected and Self-Testing Applications in TestComple te help. To run your test: Go to the Project Explorer panel (if this panel is hidden, select View | Project Explorer from TestCompletes main menu). Clic Run Project on the panel toolbar. You can also start the project executi on by pressing SHIFT-F3 (this shortcut can be changed in the Global Shortcut Opt ions dialog). TestComplete will start executing the tests. Not only can you execute projects, but any element that provides one or more tes ts: for example, a project suite, the Script project item, a low-level procedure , and so forth. To run the element, right-clic it in the Project Explorer panel and select Run from the context menu. For instance: To execute the Script project item, right-clic this project item and choose Run f rom the context menu. TestComplete will run the routine that is specified by the Main Routine property of the Script project item. To run an individual script routine, right-clic the unit holding that routine a nd choose the desired script routine from the Run submenu of the context menu. To execute the project suite, right-clic the project suite node and choose Run, o r select Run Project Suite from the Project Explorer toolbar. If the Save log every minutes option is enabled, TestComplete saves test results automatically at the specified interval. This is an insurance against computer crashes and power outages. The test execution will last until the execution of all test items is over. You can stop the execution at any time by pressing Stop on the Test Engine toolbar or select Script | Stop from TestCompletes main menu. You can pause the test execution by clic ing Pause on the Debug toolbar (if th e toolbar is hidden, right-clic somewhere within the toolbar area and choose De bug from the ensuing context menu). During the pause you can perform any actions needed, for instance, you can close certain applications or explore the script variables and objects using TestCompletes Watch List panel or the Evaluate dialog (see Debugging Scripts). After the test execution is over, you can view test results using TestCompletes t est log. The next topic provides a brief overview of the log capabilities. You can use eyboard shortcuts to start, stop, pause and resume script runs. Sho rtcuts free you from having to switch to the TestComplete window every time you want to start or stop a script. To reset the shortcuts, use the Shortcut Options dialog. TestComplete's eyboard shortcuts override the shortcuts used by other applications. For instance, an application can use SHIFT-F1 to display TestCompl ete help, but if TestComplete is running, pressing SHIFT-F1 will not call the He lp window, it will start the script recording. TestComplete projects have a number of properties that let you customize the tes t run (see Project Properties in TestComplete help). For instance, you can confi gure the properties, so that the test will stop if an error or warning message i s posted to the test log. Some other options specify the speed of eystro es and mouse movements during the playbac as well as the delay between simulated user actions. Another group of project settings allows you to tune TestCompletes behavior when running a script encounters unexpected or overlapping windows. See Handling Unex pected Windows and Playbac project properties in TestComplete help. You can als

o create a routine that will be called when an unexpected window appears. See Cr eating a Script Routine That Handles the OnUnexpectedWindow Event in TestComplet e help. Note that when you start the test run, TestComplete automatically turns off the state of the CAPS LOCK ey. The same operation is performed when recording a scr ipt. All of these actions ensure that TestComplete will correctly simulate eyst ro es. Note: TestComplete cannot run tests on loc ed computers. For information on ho w to wor around this problem, see Running Tests on Loc ed Computers in TestComp lete help. Analyzing Test Results TestComplete eeps a complete log of all operations performed during testing. Yo u can add your own notes, references or images to the log as well. By default, TestComplete stores the results of each test run in subfolders of th e <Project>\Log folder (you can specify another folder for the log files using t he Log location project property). Each subfolder name includes the name of the executed test including the date and time of the run. The titles of test results are shown in the Project Explorer panel under the Pro ject_Suite_Name Log | Project_Name Log node. It is the primary wor space for loo ing up the test history of the project and project suite. Each node corresponds to a test run. An image to the left of the node specifies whether the correspon ding test run passed successfully. By default, projects store references to all log files. That is, the number of r eferences ept by the project equals to the number of test runs. This number inc reases as the testing progresses, and, if the number of references is too large, you can remove the unnecessary logs by right-clic ing them in the Project Explo rer panel and selecting Delete from the context menu. To add existing log file s to your project, right-clic the Project Log node and selecting Add Log File from the context menu. You can also limit the number of references ept by using the Number of recent l ogs to eep option (see Log Options in TestComplete help). In this case newer lo g files will push out older log files from the list of stored results when the n umber of references exceeds the option value. TestComplete will delete both refe rences to files and the files themselves, so if you want to store test results y ou should copy them. You can add the saved copy of the results to your project a ny time later as it is described above. Note: TestComplete automatically adds nodes for the last results after the tes t execution is over. That is, the results are not displayed when the test is run ning. You have to wait until the test run is over. However, you can view intermediate results if you pause the test execution. Test Complete includes a special Show Log on pause option. If this option is enabled, then during the pause, TestComplete displays the Pause Log window in the Wor sp ace panel. The window is closed once you resume the test execution. The pause lo g is not added to the test log tree displayed in the Project Explorer. To view the detailed test results, right-clic the desired node and choose Open from the context menu. TestComplete will display the test results in the Wor spa ce panel. In our example, the log is as follows --

The test results window shows results of one test run. On the left of the window there is a tree-li e structure of the test that was executed during the test run . The tree includes results of all executed test items: scripts, low-level proce dures, unit tests, etc. and reflects the hierarchy and flow of the executed test s. For instance, if you initiated load testing from a script, the Script log tre e node will have a child node named Load testing log. If an event handling routi ne was executed during the load testing run, the Load testing log node will hold another Script log node as a child. We executed the project that has two test items with each one running a script r outine. Lets explore the test log nodes. The root node of the tree corresponds to the start item of the test. In our case the root element corresponds to a project, since we ran the project. But if we

ran a project suite, the root element would correspond to the project suite; if we ran the Script project item, the root element will be the Script log, and so on. The root node has two child nodes. They correspond to test items that were execu ted by the project. Each of these test items execute one element - the script ro utine that is specified by the Element to be run column of the project editors Te st Items page. The script logs are shown as child nodes of the test item nodes. To view detailed results for a node, simply select it from the log tree. TestCom plete will display detailed results on the right. Note that every project item h as its own results presentation, so what the log window displays is determined b y what project item was used as a source of the test. For instance, the Script p roject item forms a log of records with informative, error, warning and picture messages (see the image above). The Remar s pane of the script test log contains additional information about the currently selected message. The Picture pane s hows an image posted to the log. You can rearrange the Log panel as described in Arranging Columns, Lines and Panels in TestComplete help. For instance, you can sort items on the Time column, filter results by their type, and do a lot more. A double-clic on a message switches you to the script line holding the function that posted this message to the test log. An image to the left of the node shows whether the test was successful and if er rors or warnings occurred during its execution. TestComplete can generate error or warning messages to pinpoint application errors, as well as generate notifica tions for actions such as eypresses. Scripts can post any ind of message (see Posting Messages to the Log in TestComplete help). By expanding the nodes with error (or warning) icons, you can easily find which test operation failed to execute successfully. The next topic of the Getting Sta rted section, Searching for the Reason of an Error, describes how you can determ ine why your script failed to run successfully. Searching for the Reason of an Error It is possible that the first versions of your test scripts will fail to execute successfully. There can be a lot of reasons for this. For instance, the script code may contain a mista en instruction, the application behavior can differ fro m what you expected or an unexpected window may appear during the script run. Yo u can search for the cause of an error in the following way: Loo at the first error in the test log (to view the script function that posted this error to the log, double-clic the message in the log window). Run your script once again to analyze the application state when an error occurs . To perform this analysis you can - Set brea points or pause the test execution, use the Watch List panel and the Ev aluate dialog. See Debugging Scripts in TestComplete help. Add script statements that will post different diagnostic messages to the log, f or example: The list of child objects (windows). Images of one or several application windows. The state of objects (windows): existence, visibility, and so on. For instance, to see if an object or window exists, use the Exists property; to see if a windo w or an onscreen object is visible, you can use the Visible and VisibleOnScreen properties; to see if an object (window) is enabled or focused, use the Enabled and Focused properties. The goal of the analysis is to answer the following questions: What is the difference between the current application state and the state you e xpect? What is the cause of the error: an error or typo in the script, an application b ug or something else? If you cannot determine the cause of an error, send a message to AutomatedQAs sup port team at support@automatedqa.com (see Getting Support). In order for the sup port team to answer the message in a timely manner, please attach your script an d archived results folder of your TestComplete project to the message (the proje ct results folder is normally <Your_Project_Folder>\Log directory). Please modif y the script so that it gives detailed information on your application state at

the moment of an error: images of application windows, the list of child objects of the tested process, and so on. A small sample application that illustrates t he problem will be greatly appreciated. You can also as about the problem in our newsgroup or search for a solution in the list of frequently as ed questions. For more information on this, see Gettin g Support. Scripting Writing Scripts Overview About Scripts There are two basic ways to create a script: Record a script using TestCompletes script recorder (see Recording a Test Script in TestComplete help). -- or - Write a script in TestCompletes Code Editor. The easiest way to begin scripting is to use the recorder. The script can be edi ted further through the Code Editor. A script is a procedure or function in one of the supported scripting languages (see the Scripting Languages section below). Scripts are grouped into unit files , and each project may use as many units as needed. In the hierarchy of project elements, all the units belong to the Script project item. When you create a new project, TestComplete automatically creates the Script project item with one un it in it. A typical script that simulates user actions contains the following statements: Sys.Process() - This method returns an object that provides a scripting interface to the process of the tested application. processObj.Window(), windowObj.Window() - These methods return windows of objects or child windows of a parent window (controls on an application form). windowObj.Clic , windowObj.DblClic , etc., - These statements simulate user acti ons over a window. For more information on these instructions, see How TestComplete Recognizes Proc esses, Windows and Controls and Simulating User Actions in TestComplete help. Scripts may be called from other scripts, by name if in the same unit, else usin g the <unit name>.<script> format (see Calling Routines and Variables Declared i n Another Unit). You can also import units of other projects (see Calling Routin es and Variables Declared in Another Project in TestComplete help). Note: Since the unit name can be used in script code, the unit name should be a valid script identifier and it should not coincide with the name of an existin g programming object. If the unit name is invalid, you have to rename the unit. You can do this in the same way you rename any other project items. See Renaming Projects, Project Suites and Project Items in TestComplete help. Whenever you run a command execution of any script, TestComplete chec s all scri pt units for syntax errors. The script will not be run if syntax errors are foun d. You can chec syntax by right-clic ing the desired unit in the Project Explor er and selecting Chec Syntax from the context menu. Scripting Languages The scripting language for the project is defined once during its creation. You can choose from one of the five scripting languages: VBScript, JScript, DelphiSc ript (a subset of Object Pascal), C++Script or C#Script (both based on the JScri pt engine). All languages are restricted to variables of the OleVariant compatib le type, and cannot use pointers. Types specified in variable or function declar ations are ignored. DelphiScript support is built into TestComplete. VBScript and JScript are suppor ted by DLLs (of the same name) shipped with Windows and Internet Explorer. Since C++Script and C#Script are based on JScript, they also depend on these DLLs. To run VBScript, JScript, C++Script or C#Script in TestComplete, Internet Explorer 5.0 or higher must be installed on the machine. If you do not have Internet Exp lorer 5.0 or higher installed, you can install the Microsoft scripting component s directly. The latest version of these DLLs (as a part of Windows Script Compon ents) is available at http://www.microsoft.com/downloads. For debugging VBScript, JScript, C++Script and C#Script routines, you must have

either Microsoft Visual InterDev or Microsoft Script Debugger installed. Microso ft Script Debugger is free and can be downloaded from http://www.microsoft.com/d ownloads. Debugging of DelphiScript routines does not require any additional sof tware. TestComplete is equally oriented on each of the supported scripting languages. H owever, each of the languages has its pros and cons that may or may not match yo ur specific requirements. Read the Selecting a Scripting Language topic to decid e what language you should choose. For complete information on the supported scripting languages, use the lin s bel ow: VBScript http://www.msdn.microsoft.com/scripting JScript http://www.msdn.microsoft.com/scripting DelphiScript DelphiScript Description in TestComplete help C++Script Writing C++ Scripts in TestComplete help C#Script Writing C# Scripts in TestComplete help Scripts and Connected and Self-Testing Applications Everything that can be done in a script can also be done in application code, us ing TestCompletes Connected Application facility. Such connected code is free fro m the limitations of scripting languages, and has the same access to application internals as ordinary application code. It can also be debugged by the developm ent tools debugger, just li e the rest of the applications source. Connected code can be written directly in the applications source editor. However , it can also be read from TestCompletes project source and copied to the applica tion source. VBScript can be read by the Visual Basic compiler or interpreter; D elphiScript code - by Delphi; C++ code can be read by any C++ compiler, but the necessary library to ma e a Connected Application is compiler-specific, and only Microsoft Visual C++ and Borland C++Builder are supported. C#Script code can be read by any C# compiler, but to ma e a C# Connected or a Self-Testing Applicati on, you will have to add certain assemblies to the application. Script File Format and Source Control Systems TestCompletes script files can have either ANSI, UTF-8 or Unicode (UTF-16) format . Some source control systems treat Unicode files as binary and thus do not let you perform some operations over such files, for example, compare or merge. Plea se refer to the documentation on your source control system to learn how you can wor with Unicode files. To solve the problem, you can also change the character encoding format used in your project for script files. For more information on this, see Character Encod ing in TestComplete help. Selecting the Scripting Language The scripting language for the project is specified at the project creation time and cannot be changed later. TestComplete supports the five languages: VBScript , JScript, Delphi, C++Script and C#Script. The languages are quite different, so you may as Which one should I choose for my project? First of all, we would li e to note that the scripting language does not depend on your tested applications programming language. For instance, you can use JScri pt to test Visual C++ applications, or VBScript to test Delphi programs. There i s only one recommendation: if you plan to create a Connected or a Self-Testing A pplication, you should select the scripting language that matches the developmen t tool where you will create that application. That is, if you use Visual C++ or C++Builder, you should select C++Script; if you use Visual Basic, select VBScri pt; if you use C#, use C#Script, and if your using Delphi, select DelphiScript. This will ma e it easier to import recorded scripts to Connected and Self-Testin g Applications. The vast majority of TestComplete features is equally oriented on each of the fi ve supported languages. So, you can select the language that is closer to your d evelopment s ills. This will decrease the test creation time, since you will not have to learn a new language. You will not be limited in functionality if you prefer one language to another you will be able to use all of TestCompletes features regardless of which langua ge you choose. However, due to the fact that languages have different syntax and

wor via different engines, there are few exceptions: The size of a DelphiScript unit in a TestComplete cannot exceed 1 MB. There is n o such a limitation for projects created in other scripting languages (VBScript, JScript, C++Script and C#Script). JScript does not support functions that obtain parameters by reference. The same applies to C++Script and C#Script since these languages wor via the JScript en gine. Any of the supported scripting languages let you call routines and variables def ined in another unit. However, circular references between units are supported i n VBScript and DelphiScript only and are not supported in JScript, C++Script and C#Script. JScript, C++Script and C#Script may handle exceptions incorrectly when the try{} bloc holds calls to routines defined in other units. That is, the try... catch ... finally bloc wor s correctly only when it does not hold calls to routines f rom other units. Some users consider that exception handling in JScript, C++Script, C#Script or D elphiScript may be more convenient than exception handling in VBScript. The format of arrays in JScript, C++Script and C#Script differs from the DelphiS cript and VBScript (see Supported Scripting Languages - Peculiarities of Usage). This affects the usage of some routines (for example, the Find and FindAll meth ods) in JScript, C++Script and C#Script code. For more information, see document ation for the specific method. For information on usage peculiarities of supported scripting languages, see Sup ported Scripting Languages - Peculiarities of Usage. One more criterion that may affect the selections of the scripting language is t he set of predefined language functions. Each scripting language provides a numb er of built-in functions that help you perform some routine actions, such as con verting numerical values to strings and vice versa (C++Script and C#Script have the same functions as JScript, since these languages are based on JScript). Norm ally, the sets of predefined functions of different scripting languages are simi lar to each other, with few exceptions (for instance, DelphiScript does not have an analogue of VBScripts split function). However, the difference in predefined functions is negligible, since most of predefined functions are simple and you c an easily create their analogues in another language. Writing Scripts Quic Start This topic is a starting point in understanding of how to write scripts. It prov ides brief information on how to perform common actions in scripts and gives you lin s to more detailed descriptions. Note: We recommend that you read Writing Scripts Overview before you proceed. General Notes To write scripts, you must add the Script project item to your project. You can do this at the time of the project creation or any time later using TestCompletes dialogs. For more information, see Adding and Removing Project Items and Their Child Elements in TestComplete help. A script is a routine written in one of the supported scripting languages. Scrip t routines are organized in units that are shown as child nodes of the Script pr oject item in the Project Explorer panel. The unit name can be used in script code, so the unit name should be a valid scr ipt identifier and it should not coincide with the name of an existing programmi ng object. If the unit name does not match these rules, you have to rename the u nit. You can do this the same way you rename any other project items. See Renami ng Projects, Project Suites and Project Items. You can call script routines defined in one unit from another unit. You can also import units created in other projects into your project. To modify the code of a unit, right-clic this unit in the Project Explorer and choose Edit from the context menu. TestComplete will open the Code Editor with t he units code in the Wor space panel. The Code Editor offers an abundance of features for editing script code: syntax highlighting, code completion, code templates, outlining, boo mar s, etc. To deb ug the script code, you can use conditional brea points, evaluate and watch dial

ogs and some other means provided by TestComplete. For more information on editi ng and debugging capabilities, see About Code Editor and Debugging Scripts in Te stComplete help. Running Tested Applications Each TestComplete project has a list of tested applications. This is a way for y ou to eep trac of which applications the project deals with, and for TestCompl ete to launch the applications on the list automatically (you can unchec any ap plication you do not want to be launched automatically). To ensure that the test ed applications are running before you perform any action on them, add the follo wing code at the beginning of your script: [VBScript] TestedApps.RunAll [JScript] TestedApps.RunAll(); [DelphiScript] TestedApps.RunAll(); [C++Script, C#Script] TestedApps.RunAll To run a single tested application, use the TestedApps.Items(Index).Run statemen t (the Index parameter specifies the index of the desired application in the tes ted applications list of your project). The following code demonstrates how to r un one instance of the first tested application in the list: [VBScript] TestedApps.Items(0).Run(1) [JScript] TestedApps.Items(0).Run(1); [DelphiScript] TestedApps.Items[0].Run(1); [C++Script, C#Script] TestedApps["Items"](0)["Run"](1); Using the Run method you can launch one or more application instances. Also, usi ng the methods Timeout parameter you can specify the number of milliseconds to wa it until all application instances have been launched. For more information, see the method description in TestComplete help. You can also run tested applications by creating the appropriate test item. For more information on tested applications, see Tested Applications and Wor ing With Tested Applications From Scripts in TestComplete help. Addressing Processes, Windows and Controls Before you simulate a user action over a window or control, you should obtain a program object that provides scripting interface to that window (control). To do this, you should first obtain a process, to which the desired window belongs (i n TestComplete object model, processes are children of the System (Sys object), windows are children of processes). If you started a tested application by calling the Run method of the TestedApp o bject in your script code, then the method will return the process object corres ponding to the launched application: [VBScript] Set p = TestedApps.Items(0).Run(1) [JScript] var p; p = TestedApps.Items(0).Run(1); [DelphiScript]

var p : OleVariant; begin p := TestedApps.Items[0].Run(1); end; [C++Script, C#Script] var p; p = TestedApps["Items"](0)["Run"](1); To obtain a scripting interface to any process running in the system (including those processes that were started from TestComplete), use the Sys.Process or Sys .WaitProcess methods. They return a process object that provides scripting inter face to the process specified by its name and index. The index is used to distin guish several instances of the same application. If there is only one instance o f the application running, the index can be omitted. Below is typical code for o btaining the process object for running the Notepad application: [VBScript] Set p = Sys.Process("Notepad") [JScript] p = Sys.Process("Notepad") [DelphiScript] var p : OleVariant; begin p := Sys.Process('Notepad'); end; [C++Script, C#Script] var p; p = Sys["Process"]("Notepad") If the specified process does not exist, the Process method will post an error m essage to the test log and return an empty stub object containing only one prope rty named Exists. If you then attempt to call any other methods or properties us ing this stub object, TestComplete will either post an error message to the test log or display an error message on screen. The action to be performed is specif ied by the When referring to a non-existent object that can be changed in the En gines General Options dialog. To wait until the desired process starts up, you can use the WaitProcess method. This method pauses the script execution until the specified process is created or the specified timeout is over. If the process is not created, the method does not post an error message to the log, it just returns an empty object: [VBScript] Set p = Sys.WaitProcess("Notepad", 2000) If Not p.Exists Then ' Process does not exist End If [JScript] p = Sys.WaitProcess("Notepad", 2000) if (! p.Exists) // Process does not exist [DelphiScript] var p : OleVariant; begin p := Sys.WaitProcess('Notepad', 2000); if not p.Exists then

// Process does not exist end; [C++Script, C#Script] var p; p = Sys["Process"]("Notepad", 2000) if (! p["Exists"]) // Process does not exist A possible alternative to the WaitProcess method is to specify the wait time usi ng the Timeout parameter of the TestedApp.Run method. After you have the process, you can obtain windows belonging to this process. Th e way you do this depends on whether your application is compiled as an Open App lication or not. Open Applications provide TestComplete with access to their int ernal objects, methods and properties. .NET, Java, WPF and Visual Basic 6.0 appl ications are always open to TestComplete. Visual C++, Delphi and C++Builder applic ations need to be recompiled in a special manner. For complete information on th is, see Open Applications in TestComplete help. If your application is an Open Application, you can address windows using one of the following special methods: Method Description WinFormsObject Provides access to windows in Microsoft .NET applications by obj ect name or by control class name, window text (caption) and index. VCLNETObject Provides access to windows in Borland VCL.NET applications by ob ject name or by control class name, window text (caption) and index. VBObject Provides access to windows in Visual Basic 6.0 applications by o bject name. VCLObject Provides access to windows in Delphi and C++Builder VCL Open App lications by object name. CLXObject Provides access to windows in Delphi and C++Builder CLX Open App lications by object name. SwingObject Provides access to windows in Java Swing applications by object name or by class name, caption and index. AWTObject Provides access to windows in Java AWT applications by object na me or by class name, caption and index. SWTObject Provides access to windows in Java SWT applications by object na me or by class name, caption and index. WFCObject Provides access to windows in Java WFC applications by object na me or by class name, caption and index. WPFObject Provides access to windows in WPF (XAML) applications by object name. Windows and objects of Visual C++ applications as well as windows and objects of Java applications that were built using other libraries than Swing and AWT, are addressed as windows of blac -box applications (see below). The following example demonstrates how you can obtain a form of a .NET applicati on created with Microsoft Windows Forms library. If your Open Application was cr eated with another development tool, then to obtain a form of your application r eplace calls to the WinFormsObject method with calls to the appropriate method f rom the table above. [VBScript] Set p1 = Sys.Process("MyApp") Set w1 = p1.WinFormsObject("MainForm") [JScript] p1 = Sys.Process("MyApp"); w1 = p1.WinFormsObject("MainForm"); [DelphiScript] var p1, w1 : OleVariant; begin

p1 := Sys.Process('MyApp'); w1 := p1.WinFormsObject('MainForm'); end; [C++Script, C#Script] var p1, w1; p1 = Sys["Process"]("MyApp"); w1 = p1["WinFormsObject"]("MainForm") Note: Each of the changed methods return the wrapper object for a window of a tested application. This wrapper object provides access to the methods and prope rties defined by the application code (for example, methods and properties of .N ET, Java or MFC classes) as well as methods, properties and actions provided by TestComplete. It is possible that a process contains several windows having the same name (for instance, your Open Application may create several instances of the EditOrder f orm). To distinguish such windows in your scripts, you can use any of the follow ing alternatives: Use the Name Mapping feature. Find for the window using the Find or FindId method of the process (Find returns a child object by values of its properties, FindId returns a child object by it s id). Enumerate all of the windows belonging to the same process, examine the window p roperties (or properties of their child windows) and obtain the desired window. To enumerate windows, you can use the Child and ChildCount properties of the pro cess object. If a window has no Name property (for example, windows of Visual C++ application s have no names), or if your application is not an Open Application, you can use the Window and WaitWindow methods of the process object to get the desired wind ow. These methods return a top-level window of a process using window class name , caption and index as parameters: [VBScript] Set p1 = Sys.Process("MyApp") Set w1 = p1.Window("WindowClassName", "WindowCaption", 1) ' or Set w1 = p1.WaitWindow("WindowClassName", "WindowCaption", 1, 2000) [JScript] p1 = Sys.Process("MyApp"); w1 = p1.Window("WindowClassName", "WindowCaption", 1); // or w1 = p1.WaitWindow("WindowClassName", "WindowCaption", 1, 2000); [DelphiScript] var p1, w1 : OleVariant; begin p1 := Sys.Process('MyApp'); w1 := p1.Window('WindowClassName', 'WindowCaption', 1); // or w1 := p1.WaitWindow('WindowClassName', 'WindowCaption', 2000); end; [C++Script, C#Script] var p1, w1; p1 = Sys["Process"]("MyApp"); w1 = p1["Window"]("WindowClassName", "WindowCaption", 1); // or w1 = p1["WaitWindow"]("WindowClassName", "WindowCaption", 1); The differences between the Window and WaitWindow methods are similar to the dif ferences between the Sys.Process and Sys.WaitProcess methods. Window chec s whet her the specified window exists and if it does not, the method posts an error me ssage to the test log. WaitWindow delays the script execution until the specifie

d window is created or until the specified timeout is over. It does not post an error message to the log if the desired window does not exist. If the window with the specified attributes does not exist, both Window and Wait Window methods will return an empty stub object containing only one Exists prope rty. If you attempt them to call any other method or property for the stub objec t, TestComplete will either post an error message to the test log or show an err or message on screen. Which of these actions that will be performed is specified by the When referring to a non-existent object option that can be changed in th e Engines General Options dialog. To determine which class name, caption or index to use to address a window, expl ore your application in the Object Browser. You can copy the whole window recogn ition string from the Object Browser: Note: You can use wildcards (? and *) when specifying the window caption and c lass name. The Window and WaitWindow methods of the process object return the window progra m object that corresponds to a top-level window of a process. To get a child win dow or control, call Window or WaitWindow methods of that window object. If your application is an Open Application, you can obtain child windows by thei r names or by using the methods (WinFormsObject, VBObject, etc.) described above . [VBScript] Set p1 = Sys.Process("MyApp") Set w1 = p1.WinFormsObject("MainForm") Set w2 = w1.WinFormsObject("Button1") ' or Set w2 = w1.Button1 [JScript] p1 = Sys.Process("MyApp"); w1 = p1.WinFormsObject("MainForm"); w2 = w1.WinFormsObject("Button1"); // w2 = w2.Button1; [DelphiScript] var p1, w1, w2 : OleVariant; begin p1 := Sys.Process('MyApp'); w1 := p1.WinFormsObject('MainForm'); w2 := w1.WinFormsObject('Button1'); // w2 := w1.Button1; end; [C++Script, C#Script] var p1, w1, w2; p1 = Sys["Process"]("MyApp"); w1 = p1["WinFormsObject"]("MainForm"); w1 = w1["WinFormsObject"]("Button1"); // or w2 = w1["Button1"]; If you do not call the xxxxObject method, TestComplete will return the wrapper o bject for the request window or control that will hold only application-defined properties (for instance, if you are testing a .NET application, the wrapper obj ect will hold only methods and properties of .NET classes). To obtain an object containing both application-defined and TestComplete methods and properties, use the the xxxxObject method. The hierarchy of windows depends on the Object tree model option of your TestComplete project. This option specifies which of the object tree models, Fl at or Tree, is active. For complete information on them, see Object Tree Models in TestComplete help. Note that scripts created for the Flat model are not suppo rted by the Tree model and vice versa. That is, if you run a script routine crea ted for the Flat model when the Tree model is active, TestComplete will not find windows and will post errors to the test log. Note: The child objects list of some objects can change dynamically (for insta nce, windows can be created or deleted within the process). TestComplete automat ically updates the child list when you obtain a child of some object. You can fo

rce TestComplete to update the child list of an object by calling the Refresh me thod of that object. If the same parent window contains two or more objects having the same name, the n to obtain the desired window, you can use approaches similar to those that wer e described for top-level windows (name mapping, searching with Find and FindId method, enumeration of child windows). Once you obtain the desired window or control, you can wor with it as your need s dictate. For instance, you can simulate user actions (mouse clic s or eystro es), maximize or minimize a window (if it is a top-level or MDI window), change window properties (e.g. text), etc. To determine what properties are available t o your TestComplete scripts, we would recommend to loo up the window properties in the Object Browser. If your application in an Open Application (for example, a .NET application), th e Object Browser will show methods and properties or .NET classes as well as met hods and properties provided by TestComplete. Note that TestComplete automatically determines the type (button, list box, tree view, etc.) of a window. It adds specific methods and properties to the window object, so you can use these methods and properties to perform actions specific to the control. For instance, you can enumerate nodes of a tree view, clic elem ents of a list view control, get item of a list box, etc. To determine the control type TestComplete chec s the window class name. For ins tance, if the class name of a window coincides with the default class name given by Windows to button windows, TestComplete considers a window as a button. Simi larly TestComplete determines the types of other controls (list boxes, tree view s, etc.) Of course, the class name of a window may differ from the default class name. In this case TestComplete uses Object Mapping settings to determine the control ty pe. For complete information on how to address processes, windows and controls in sc ripts, see How TestComplete Recognizes Processes, Windows and Controls in TestCo mplete help. Simulating User Actions TestComplete includes all the means for simulating user actions. You can - Maximize, minimize, bring to font and change position of applications top-level w indows on the screen. Simulate mouse clic s, double-clic s, drag-and-drop events, eystro es, etc. in controls on application forms. Simulate selection of menu and toolbar items. Simulate selection of items in list view, tree view, list box and many other con trols. For instance, to simulate a clic of a button, obtain the window object for that button and then call the Clic Button method of this object (TestComplete automa tically adds this method to all window objects that correspond to buttons): [VBScript] Set p1 = Sys.Process("notepad") Set w1 = p1.Window("#32770", "Open", 0) Set w2 = w1.Window("Button", "&Open", 1) w2.Clic Button [JScript] p1 = Sys.Process("notepad"); w1 = p1.Window("#32770", "Open", 0); w2 = w1.Window("Button", "&Open", 1); w2.Clic Button(); [DelphiScript] var p1, w1, w2 : OleVariant; begin p1 := Sys.Process('notepad');

w1 := p1.Window("#32770", "Open", 0); w2 := w1.Window("Button", "&Open", 1); w2.Clic Button(); end; [C++Script, C#Script] var p1, w1, w2; p1 = Sys["Process"]("notepad"); w1 = p1["Window"]("#32770", "Open", 0); w2 = w1["Window"]("Button", "&Open", 1); w2["Clic Button"](); TestComplete automatically determines the class name of a window (see the previo us section) and adds methods and properties specific to this control type to the window object that corresponds to that window. You can call these methods and p roperties to perform operations specific to the control. For instance, you can s imulate clic s and double-clic s of tree view nodes, retrieve date held in a cal endar controls, drag sliders thumb, etc. TestComplete provides extended support f or almost all types of standard controls. See Wor ing With Win32 Controls in Tes tComplete help. Besides, TestComplete supports recent Windows Presentation Found ation controls and .NET controls, as well as several popular third-party compone nts. Furthermore, using object mapping, you can set up TestComplete so it handle s a custom control as if it is a standard one. See Wor ing With Custom Controls in TestComplete help. It is possible that an object will contain several methods or properties with th e same name. For instance, an object of an Open Application may contain the meth od Clic and TestComplete may add a method of the same name to this object. If y ou then call the Clic method of this object in your scripts, TestComplete will use its method, not the method defined in your application. To call the latter, use namespaces. For complete information on simulating user actions, see Simulating User Actions in TestComplete help. Retrieving Data From Application Objects, Windows and Controls TestComplete automatically determines the type of a control (buttons, tree view, list box, etc.) and adds specific methods and properties to the window object c orresponding to this control (see the Addressing Processes, Windows and Controls section above). Using these methods and properties you can obtain data held in the desired controls. If TestComplete cannot associate the control used with any standard Win32 contro l, then you can try compiling your application as an Open Application. Open Appl ications provide access to their internal objects, methods and properties, so yo u should be able to obtain data stored in the desired control. For complete information, please see Retrieving Data From Application Objects, W indows and Controls in TestComplete help. See also Wor ing With Grids in TestCom plete help. Posting Messages to the Test Log To post messages to the test log, use methods of the Log object. Using these met hods you can post messages of different types (error, warning, informative, etc. ): [VBScript] Log.Error "Message Text 1", "Extended Message Text 1" Log.Warning "Message Text 2", "Extended Message Text 2 " Log.Message "Message Text 3", "Extended Message Text 3 " [JScript] Log.Error("Message Text 1", "Extended Message Text 1"); Log.Warning("Message Text 2", "Extended Message Text 2"); Log.Message("Message Text 3", "Extended Message Text 3 "); [DelphiScript] Log.Error('Message Text 1', 'Extended Message Text 1');

Log.Warning('Message Text 2', 'Extended Message Text 2'); Log.Message('Message Text 3', 'Extended Message Text 3'); [C++Script, C#Script] Log["Error"]("Message Text 1", "Extended Message Text 1"); Log["Warning"]("Message Text 2", "Extended Message Text 2"); Log["Message"]("Message Text 3", "Extended Message Text 3"); Each message can have an image associated with it. The message parameter lets yo u specify color and font style of a message. Besides messages, you can also post images and file lin s (see methods of the Log object). The Log object also incl udes special methods that let you organize log messages into folders. For complete information on posting messages and images to the log, see Posting Messages to the Log in TestComplete help. Note: An object may contain several properties having the same name (for insta nce, an object of an Open Application may contain the property Left and TestComp lete may add a property of the same name to the object). If you address the Left property of this object in your scripts, TestComplete will use its property, no t the property defined in your application. To call the latter, use namespaces. Database Access To wor with databases directly from your scripts, use TestCompletes ADO and BDE program objects. Using the ADO object you can wor with databases via Microsoft ADO objects, meth ods, and properties. The ADO object also provides methods for wor ing with datab ase using wrappers of Borland VCL data-aware objects. The BDE object lets you wor with databases via wrappers of VCL data-aware objec ts for BDE access. An alternative to use of the ADO and BDE is the creation of ADO objects from scr ipts: [VBScript] Set AConnection = CreateObject("ADODB.Connection") ' Specify the connection string AConnection.ConnectionString = "Provider=Microsoft.Jet.OLEDB.3.51;" + _ "Data Source=C:\Microsoft Visual Studio\VB98\biblio.mdb" ' Activate the connection AConnection.Open [JScript] AConnection = new ActiveXObject("ADODB.Connection"); // Specify the connection string AConnection.ConnectionString = "Provider=Microsoft.Jet.OLEDB.3.51;" + "Data Source=C:\\Microsoft Visual Studio\\VB98\\Biblio.mdb"; // Activate the connection AConnection.Open(); [DelphiScript] var AConnection : OleVariant; begin AConnection := Sys.OleObject('ADODB.Connection'); // Specify the connection string AConnection.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.3.51;' + 'Data Source=C:\Microsoft Visual Studio\VB98\biblio.mdb'; // Activate the connection AConnection.Open; end; [C++Script, C#Script]

var AConnection; AConnection = Sys["OleObject"]("ADODB.Connection"); // Specify the connection string AConnection["ConnectionString"] = "Provider=Microsoft.Jet.OLEDB.3.51;" + "Data Source=C:\\Microsoft Visual Studio\\VB98\\Biblio.mdb"; // Activate the connection AConnection["Open"](); For more information on database access from scripts and for code examples, see Wor ing With Databases in TestComplete help. Calling Project Elements From Scripts For each project item TestComplete provides special program objects that let you wor with project items from scripts. For instance, these objects let you execu te tests provided by project items, or get project items' property values. You can address project elements from scripts using the element name as it is sh own in the Project Explorer panel. For instance, to execute a low-level procedur e from a script, you can use the following code: LLPCollection1.LLP1.Execute() Here LLPCollection1 is the name of the Low-Level Procedures Collection project i tem as it is shown in the Project Explorer. LLP1 is the name of the desired lowlevel procedure. Similarly, you can initiate execution of tests provided by other project items ( HTTP Load Testing, Manual Testing, Unit Testing, etc.) For more information on h ow to do this, see the description of the appropriate project item in TestComple te help. How TestComplete Recognizes Processes, Windows and Controls This topic explains how object names are formed. This is important information, since these names are returned by the Name property and are used to address obje cts in your scripts. The topic includes the following sections: Naming Concepts Processes Window Objects Controls and Objects Within Applications Web Objects Naming Concepts To address objects of tested applications in scripts, TestComplete uses properti es of these objects. Each object has a number of properties such as class name, tex t, enabled and so on. You can view available object properties in the Object Browse r or using the Object Properties window. Some object properties are often changed during the application's execution (for instance, text in an edit box), while others (for instance, window handle) rema in constant but may change between two application runs. Other properties (for i nstance, window class name in some applications) do not change between applicati on runs. In order for a property to be used in addressing an object from a script, it mus t uniquely distinguish the desired object from other similar objects and remain unchanged during the application's execution and between application runs. Also, it is desirable for the property to be readable. In a general case, no property meets all of these requirements, so TestComplete uses a combination of properties to identify objects. For instance, to address p rocesses it uses the name of the executable file that started the process and th e process index by default; to address windows it uses the window's class name, window's caption and index. In other words, the object names typically include s everal components: For complete information on the naming process, windows and other objects of tes ted application, see the next sections of this topic. Some components of an objects name (for instance, window caption or proce ss index) can change during the application run, so it is possible that you will have to use different names to address the same process or window during the sc

ript run. Using the Name Mapping feature you can redefine the combination of properties Te stComplete uses to address objects. For more information on this, see Name Mappi ng in TestComplete help. The addressing is hierarchical. For instance, to obtain a program object corresp onding to a window, you should first obtain a process object; to get program acc ess to a control, you should first obtain a window object that corresponds to th e window containing the desired control, and so on. To explore the hierarchy of objects, use the Object Browser. The object name used by TestComplete to address an object is specified by the ob jects Name property. This property has every program object that provides a scrip ting interface to a process, window or control of a tested application. Besides Name, these objects also contain the FullName property, which in addition to the object name also includes the names of parent objects. In fact, FullName return s a string that identifies the object in the system. When recording a script, TestComplete addresses the objects using the name shown in the Object Browser. However, if you create a custom name for the object usin g the Name Mapping feature, TestComplete will use the mapped name or alias. The following sections of this topic provide detailed information on addressing processes, windows and controls of the tested applications. Processes To wor with processes from scripts, use the process objects. To obtain a proces s object, call the Sys.Process or Sys.WaitProcess methods. These method use para meters that uniquely identify the process in the operating system: The name of an executable file that starts the process. The file name is used wi thout an extension. The index of a process instance. There can be several running applications with the same name in the system. In this case, the process index is used to distingu ish one process instance from another. The first started process has index 1, th e second - 2, etc. [VBScript, Visual Basic] ' Obtains the object that provides scripting interface ' to the second instance of Notepad Set p = Sys.Process("Notepad", 2) [JScript] // Obtains the object that provides scripting interface // to the second instance of Notepad var p = Sys.Process("Notepad", 2); [DelphiScript, Delphi] var p : OleVariant; begin // Obtains the object that provides scripting interface // to the second instance of Notepad p := Sys.Process('Notepad', 2); end; [C++Script, C#Script, C++, C#] var p; // Obtains the object that provides scripting interface // to the second instance of Notepad p = Sys["Process"]("Notepad", 2); Note that the process index can change during the script run: if a process with a lower index is terminated, the higher indexes will be decreased, so the names of other processes are changed. If you omit the process index when referring to the process, the default value 1 will be used, for example, the names Process("Notepad") and Process("Notepad", 1) are equivalent.

Window Objects The principles which TestComplete uses to recognize windows depend on whether th e application under test is an Open Application (white-box) or non-Open Applicat ion (ordinary, blac -box). Open Applications If the tested application was compiled as an Open Application, you can address i ts windows and objects using special methods provided by TestComplete: WinFormsO bject, VBObject, VCLObject, SwingObject, and so on. There methods let you addres s the desired window by using the value specified by the applications Name proper ty, or by using the class name, caption and index. The method used depends on th e programming language and the development tools used to create your application . For complete information on using these methods, see the following topic in Te stComplete help: Addressing Windows, Controls and Objects of Open Applications Blac -Box Applications To address windows in blac -box applications, TestComplete by default uses the f ollowing window attributes: Window class name Window caption Window index The Windows API offers several attributes meant to distinguish one window from t he other, among those currently open in the system. The one it uses internally, the handle, is meaningless from one run to the next. The attributes used by Test Complete - class name, caption and index - are more stable. The use of other pro perties (for example, control id) is also possible. See below for more informati on. Now we will describe attributes used by default. Window class name. This attribute specifies the name of the windows class as it i s registered in the operating system, for instance, msctrl_statusbar32, #32770, TForm1 or Afx:400000:b:10008:6:1027b. Window class name is the most stable component of a window name. It does not cha nge during the script run. However, it is not unique for a window (it is quite p ossible that two or more windows have the same name) and it can change from one application run to another (these changes are typical for MFC applications). To negate the change of the class name, you can use the wildcard symbols (* and ?) to s pecify a window class name. For instance, you can use Afx:400000:b:* instead of Afx :400000:b:10008:6:1027b. Without the wildcards, you would have to modify window c lass names in script code before each run. To specify an asteris as part of the window class name, use two consequent asteris s. Window caption. The window caption identifies the window for users. It is not un ique and there can be two windows with the same caption in the system. Generally , the caption can also be changed during the execution of the application. The d eveloper may use it to display any helpful information, for instance, the captio n of a text editor usually display the name of the edited document: MyEditor - Do cument1.rtf. You can use wildcard symbols (* and ?) to specify caption patterns. This technique m a es application testing more flexible. For example, you can specify only the co nstant part of the caption (MyEditor - ), and replace the name of the edited docum ent with *. To specify an asteris in the caption, use duplicated asteris s (for e xample, MyEditor - DocName.txt** in scripts corresponds to the caption MyEditor - D ocName.txt*). Since applications often use their main caption as the applications name followed by a hyphen and the name of the active window (or document, or project, etc.), TestCompletes recorder will automatically record the string * for any caption that includes a hyphen. Thus, GraphEditor - MyPicture1.bmp is recorded as *. Note that many windows, especially smaller ones, have no caption, that is, they all have the same caption, empty. Menus for instance, are captionless windows, a nd they are rather typical. Entire window classes are used without captions, ma ing the caption useless to distinguish among siblings. In this case, to obtain a window, you should use other attributes: class name and index.

 Index. The windows index is more unstable than the windows caption, but it is need ed when a process or parent window has several child windows with the same capti on and the same class name. The index is the current front-to-bac onscreen posi tion (similar to Z-order) of the window among windows of the same class with the same parent, 1 meaning the currently topmost window in the class. The window in dex is determined by certain Windows API functions, so even if two or more windo ws visually have the same Z-order, they have different window indexes. To determ ine the index of the desired window, explore the application windows and control s in TestCompletes Object Browser. The index of an application window changes when other windows from the class are called onscreen or when the front-bac position of this window changes. TestComplete may not record a windows index when you are recording a script, if t he class name and caption provide enough information for the recognition of this window. To obtain a window in a script, you can use one of the following methods: Proces s.Window, Process.WaitWindow, Window.Window and Window.WaitWindow. These methods use parameters that specify the class name, caption and index of the desired wi ndow: [VBScript, Visual Basic] Set p = Sys.Process("winword") Set w = p.Window("OpusApp", "Microsoft Word - *", 1) [JScript] p = Sys.Process("winword"); w = p.Window("OpusApp", "Microsoft Word - *", 1) [DelphiScript, Delphi] var p, w : OleVariant; begin p := Sys.Process('winword'); w := p.Window('OpusApp', 'Microsoft Word - *', 1) end; [C++Script, C#Script, C++, C#] var p, w; p = Sys["Process"]("winword"); w = p.["Window"]("OpusApp", "Microsoft Word - *, 1") The hierarchy of windows depends on the Object tree model option of your TestComplete project. This option specifies the active object model: Flat or Tr ee. For complete information, see Object Tree Models in TestComplete help. We re commend to read this topic since nowing the tree model is essential for running the scripts. Scripts created for the Flat model will run incorrectly if the Tre e model is active and vice versa. To chec the state of the Object tree model option in scripts, use the Options.P roject.General.TreeModel property. In order to identify windows you can use not only the mentioned attributes (clas s name, caption and index), but also other window attributes. For example, you c an use the control identifier of a window. This identifier is an application-def ined integer value associated with a window. The identifier value is returned by Win32 API GetWindowLong(hwndCtrl, GWL_ID) or GetDlgCtrlID(hwndCtrl) functions. We use the term control identifier since this identifier is typically used to addr ess child windows, for instance, controls on a form (controls are also windows). However, top-level windows also have identifiers. The control identifier can be specified by a developer (for example, when they d esigned the dialog template in Visual Studio) or by the development tool itself (for instance, if the development tool does not support manual setting of the id entifier). Though the identifier seems to be a persistent window attribute, it m ay be unspecified (0), its value may change from one application run to another or the program may return the same identifier for two different windows. If you

do not find the identifier helpful, you can use the window caption, class name a nd index to find the desired window. The following code uses the FindChild method that returns a window by its contro l identifier: [VBScript] Set p = Sys.Process("Notepad") Set w = p.FindChild("ControlId", 133099, 1) [JScript] var p, w; p = Sys.Process("Notepad"); w = p.FindChild("ControlId", 133099, 1); [DelphiScript] var p, w; begin p := Sys.Process('Notepad'); w := p.FindChild('ControlId', 133099, 1); end; [C++Script, C#Script] var p, w; p = Sys["Process"]("Notepad"); w = p["FindChild"]("ControlId", 133099, 1); The FindChild method returns a child object by any combination of its property v alues. For instance, the method can find a window using a combination of the Chi ldCount, Visible, WndClass and WndStyle properties (or any other set of properti es that let you uniquely distinguish the window). The combination of properties that let you uniquely identify the window depend on the application under test. For instance, two forms may have different window styles (WndStyle property) and different number of child windows (ChildCount property). Using the FindChild me thod you can obtain the desired object using any combination of its properties. For more information on using the method, see the method description in TestComp lete help. To obtain a window by custom property values, you can also use the Name Mapping feature. Name mapping lets you visually specify the combination and values of th e properties that will be used for recognition and to assign custom names to obj ects that will match the specified recognition criteria. Once you map an object, you can address this object in scripts using the mapped name, rather than the o bjects default name. For more information, see Name Mapping in TestComplete help. Controls and Objects Within Applications Addressing controls is similar to addressing windows, since for the operating sy stem each control is a window. Li e addressing windows, addressing controls and objects depend on whether the tested application is compiled as an Open Applicat ion or not. Open Applications For information on how to address controls and objects in Open Applications, see following topic in TestComplete help: Addressing Windows, Controls and Objects of Open Applications Blac -Box Applications TestComplete recognizes controls on forms of blac -box applications using attrib utes of window objects (class name, caption and index). To obtain controls, you use the window objects, which are returned by Window or WaitWindow methods of th e parent window object. These methods use the recognition attributes that were e xplained in the previous section: window class name, window caption and index (s ee the sample code below). A note on using index: The window index is similar to Z-order. It is determined

by certain Windows API functions, so even if controls lay on the same form and visually have the same Z-order, they have different indexes. To determine the in dex of the desired control, explore the application form in TestCompletes Object Browser. For controls, the window index is typically persistent. It is not changed when o ther controls of the class become hidden or visible. However, it changes when ot her controls of the same class and caption are deleted or new controls are creat ed. The index does not change when the application is recompiled (if developers do not change the form). [VBScript, Visual Basic] Set p = Sys.Process("MyApp") Set w = p.Window("WndClass", "WndCaption", 1) ' Obtains a top-level window Set w2 = w.Window("ControlWndClass", "ControlText", 1) ' Obtains a control on th e top-level window [JScript] var p, w, w2; p = Sys.Process("MyApp"); w = p.Window("WndClass", "WndCaption", 1); // Obtains a top-level window w2 = w.Window("ControlWndClass", "ControlText", 1); // Obtains a control on the top-level window [DelphiScript, Delphi] var p, w, w2 : OleVariant; begin p := Sys.Process('MyApp'); w := p.Window('WndClass', 'WndCaption', 1); // Obtains a top-level window w2 := w.Window('ControlWndClass'. 'ControlText', 1); // Obtains a control on t he top-level window end; [C++Script, C#Script, C++, C#] var p, w, w2; p = Sys["Process"]("MyApp"); w = p["Window"]("WndClass", "WndCaption", 1); // Obtains a top-level window w2 = w["Window"]("ControlWndClass", "ControlText", 1); // Obtains a control on t he top-level window The methods we use in the above example address the controls using the standard recognition attributes: class name, caption and index. Since controls are window , you can also address the controls using any other property (for instance, Cont rolId) or combination of properties. For example, the following code shows how y ou can obtain a window by using the ControlId property. For code sample that sea rches using a combination of properties, see the FindChild method description in TestComplete help: [VBScript] Set p = Sys.Process("Notepad") Set w1 = p.Window("Notepad", "Untitled - Notepad", 1) Set w2 = w1.FindChild("ControlId", 15, 1) ' Obtains a child window by ControlId [JScript] var p, w1, w2; p = Sys.Process("Notepad"); w1 = p.Window("Notepad", "Untitled - Notepad", 1); w2 = w1.FindChild("ControlId", 15, 1); // Obtains a child window by ControlId [DelphiScript] var p, w1, w2;

begin p := Sys.Process('Notepad'); w1 := p.Window('Notepad', 'Untitled - Notepad', 1); w2 := w1.FindChild('ControlId', 15, 1); // Obtains a child window by ControlId end; [C++Script, C#Script] var p, w1, w2; p = Sys["Process"]("Notepad"); w1 = p["Window"]("Notepad", "Untitled - Notepad", 1); w2 = w1["FindChild"]("ControlId", 15, 1); // Obtains a child window by ControlId You can also assign a custom name to a control by using the Name Mapping feature . The child objects list of process or window objects can change dynamically (for instance, windows can be created or deleted within a process). TestComplete auto matically updates the child list when you attempt to obtain a child of an object . You can force TestComplete to update the child list of an object by calling th e Refresh method of that object. The hierarchy of windows depends on the Object tree model option of your TestComplete project. For complete information about the supported tree models, see Object Tree Models in TestComplete help. We recommend to read this topic si nce nowing the tree model is essential for running the scripts. Scripts created for Flat model will run incorrectly if the Tree model is active and vice versa. Web Objects When testing Web pages, TestComplete wor s with the elements of Web pages as is would with application objects. The names used for these objects depend on the T ree model project setting. It specifies the object model (DOM or Tag) of objects on the page. The names of objects in these models are different. For detailed i nformation on how they are formed, see DOM Model or Tag Model in TestComplete he lp. The currently used names are displayed in the Object Browser. Calling Routines and Variables Declared in Another Unit By default, a unit can only call routines (procedures or functions), variables a nd constants within the same unit. To call routines, variables or constants in a nother unit, the current unit must be "lin ed" to it. In VBScript projects, place the cursor at the beginning of the unit and add the following string: [VBScript] 'USEUNIT Unit_Name Be sure to specify the apostrophe ( ' ) before USEUNIT. To lin several units, use the following syntax: [VBScript] 'USEUNIT Unit1_Name 'USEUNIT Unit2_Name If you have a VBScript class defined in one unit and you want to create a class instance from another unit, then using the USEUNIT statement is not enough. You also have to create a special routine that will return the desired class instanc e. For more information, see Supported Scripting Languages - Peculiarities of Us age. In DelphiScript projects, place the cursor at the beginning of the unit and add the following string: [DelphiScript] uses Unit_Name; If you need to lin several units, separate their names with commas: [DelphiScript] uses Unit1_Name, Unit2_Name; In JScript, C++Script and C#Script projects place the cursor at the beginning of the unit and add the following string: [JScript, C++Script, C#Script] //USEUNIT Unit_Name

Be sure to specify the double slash ( // ) before USEUNIT. You can lin to several units in the following manner: [JScript, C++Script, C#Script] //USEUNIT Unit1_Name //USEUNIT Unit2_Name The USEUNIT statement does not allow tab or space characters at the begi nning of the line and between the USEUNIT and the comment operator (' in VBScrip t and // in JScript). So, the following use of USEUNIT will cause an error: [VBScript] ' USEUNIT Unit_Name 'USEUNIT Unit_Name ... [JScript, C++Script, C#Script] // USEUNIT Unit_Name //USEUNIT Unit_Name ... Note: If you want to ma e a variable (constant) visible in other units, you ne ed to declare this variable (constant) outside of any routine, that is, you need to declare a global variable or constant. Otherwise, the variable (constant) wi ll be visible only within the routine where it is declared. Once an external unit is lin ed to the current one, all routines as well as glob al variables and constants of the external unit can be called in the current uni t. There is an exception, if the current unit already holds a routine, a global variable or a global constant of the same name. You can wor around this problem by prefixing external calls by their unit names. That is, you can use the follo wing syntax: MyUnit.MyRoutine(Param1, Param2) MyUnit.MyVariable MyUnit.MyConstant To call script routines located in another script unit, you can also use the Run ner.CallMethod method. It calls any routine specified by its full name (that is, unit_name.routine_name). If you call a script routine using this function, ther e is no need to include the unit specified by unit_name in the uses (USEUNIT) cl ause of the current unit. Note that DelphiScript and VBScript units in TestComplete can refer to each othe r. In other words, circular references are allowed. For instance, if you need to call scripts declared in UnitA from UnitB, and to call scripts declared in Unit B from UnitA, you must add references to both units -[VBScript] UnitA 'USEUNIT UnitB ... UnitB 'USEUNIT UnitA ... [DelphiScript] UnitA uses UnitB; ... UnitB uses UnitA; ... Note: The circular reference is not allowed . Circular lin s in these languages may cause pt and C#Script are based on JScript and also cause other errors in TestComplete. Supported Scripting Languages Peculiarities TestComplete supports the following scripting

in JScript, C++Script and C#Script errors in the jscript.dll (C++Scri use this DLL) and these errors can of Usage languages:

 VBScript JScript DelphiScript C++Script C#Script These languages have different syntax and wor via different scripting engines. Their usage has some peculiarities described below. These are features concernin g the language support in TestComplete as well as some peculiarities, which are not well- nown and can be overloo ed by beginners. VBScript The usage of VBScript has the following peculiarities: If you assign an object to a variable or property, use the Set statement, for ex ample: [VBScript] Set p = Sys.Process("MyProcess") ' Correct p = Sys.Process("MyProcess") ' Incorrect !!! In TestComplete, script units can refer to each other, so you can call routines and variables defined in one unit from another unit. VBScript supports circular references between units. To debug VBScript code, you may need to modify Internet Explorer's options. Also , if you wor under a user account (not an administrator account), you may need permissions for the Machine Debug Manager's system component. For more informati on, see Debugging Scripts in TestComplete in TestComplete help. The OnStopTest event is not generated if the script written in VBScript stops up on an unhandled exception. If you have VBScript engine ver. 5 or later, you can create and use classes in y our scripts. For more information on VBScript classes, see Microsoft Development Networ (http://www.msdn.microsoft.com/scripting). Note that you can create class instances only in the unit, in which the class is defined. Creating a class from another unit will cause an error. The following code demonstrates this: [VBScript] [UnitA] Class MyClass ... End Class Sub TestRotuine ... ' Creating class in the same unit Set cls = New MyClass ' OK! ... End Sub

[UnitB] 'USEUNIT UnitA Sub AnotherRoutine ... ' Creating class in another unit Set cls = New MyClass ' Error! ... End Sub To solve the problem, you can create a helper routine in the unit, in which the class is defined. This routine will create a class instance and return it. You c an then call this routine from another unit and wor with the created class inst

ance in a usual manner: [VBScript] [UnitA] Class MyClass ... End Class ' This routine creates and returns a new class instance Function GetClassInstance Set GetClassInstance = New MyClass End Function [UnitB] 'USEUNIT UnitA Sub AnotherRoutine ... ' Calling a routine defined in UnitA. ' Do not forget to include this unit with the USEUNIT statement Set cls = GetClassInstance ' OK ! ... End Sub DelphiScript DelphiScript support is built into TestComplete. The usage of DelphiScript has t he following peculiarities: The size of a DelphiScript unit in TestComplete cannot exceed 1 MB. This limitat ion does not exist for projects created in other scripting languages (VBScript, JScript, C++Script and C#Script). In TestComplete script units can refer to each other, so you can call routines a nd variables defined in one unit from another unit. DelphiScript supports circul ar references between units. In Object Pascal, the body of a function or a procedure can contain declarations of other functions and procedures, for example: [Delphi] procedure FuncA; procedure FuncB; begin end; begin end; In DelphiScript scripts ran from TestComplete, nested routine declarations are n ot allowed. This restriction does not exist in Delphi Connected Applications. DelphiScripts ExceptionMessage function cannot be evaluated in TestCompletes Watch List panel and Evaluate dialog. JScript, C++Script and C#Script C++Script and C#Script are based on JScript, so all of these languages have the same peculiarities of usage: JScript, C++Script and C#Script do not support functions that obtain parameters by reference. In TestComplete script units can refer to each other, so you can call routines a nd variables defined in one unit from another unit. JScript, C++Script and C#Scr ipt do not support circular references between units.

JScript, C++Script and C#Script may handle exceptions incorrectly when the try{} bloc contains calls to routines defined in other units. That is, the try... ca tch... finally bloc wor s correctly only when it does not contain calls to rout ines from other units. To debug JScript, C++Script and C#Script code, you may need to modify Internet E xplorer's options. Also, if you wor under a user account (not an administrator account), you may need permissions for the Machine Debug Manager's system compon ent. For more information, see Debugging Scripts in TestComplete in TestComplete help. The format of arrays created by the JScript engine differs from arrays created i n VBScript or DelphiScript. The arrays in JScript, C++Script and C#Script are ob jects, while arrays created in VBScript and DelphiScript are Variant values. Thi s difference limits the use of some routines (for instance, the Find and FindAll methods) in JScript, C++Script and C#Script code. In order to use a JScript arr ay with these routines, you need to convert the array to the format adopted in V BScript and DelphiScript. Below is a typical conversion routine: [JScript] function ConvertJScriptArray(JScriptArray) { // Uses the Dictionary object to convert JScript array var objDict = Sys.OleObject("Scripting.Dictionary"); objDict.RemoveAll(); for (var i in JScriptArray) objDict.Add(i, JScriptArray[i]); return objDict.Items(); } [C++Script, C#Script] function ConvertJScriptArray(JScriptArray) { // Uses the Dictionary object to convert JScript array var objDict = Sys["OleObject"]("Scripting.Dictionary"); objDict["RemoveAll"](); for (var i in JScriptArray) objDict["Add"](i, JScriptArray[i]); return objDict["Items"](); } Variables that are declared with the var statement within a function are only vi sible within this function. Variables that are used without declaring them with var, become global variables. This behavior may cause hidden influence of functi ons onto other functions. For instance, the execution of the following code neve r ends: [JScript, C++Script, C#Script] function ChildFunc() { for(i = 0; i < 5; i++) } function ParentFunc() { for(i = 0; i < 10; i++) ChildFunc(); } This happens because after a call to ChildFunc, the i variable is always 5 and n ever 10, so the loop within the ParentFunc function becomes an infinite loop. When a variable goes out of scope, it is released. However, if the variable held a reference to an object, the JScript engine does not release this object until the entire script run is over. This happens because the JScript engine cleans u p memory and references at a certain point and not when a variable is destroyed

or you set it to null. This restriction may cause problems when wor ing with certain program objects an d COM servers. Suppose you have the following code: [JScript, C++Script, C#Script] function Foo() { Obj = new ActiveXObject("MyCOMObject.MyCOMObject"); Obj = null; } function MainFoo() { Foo(); // MyCOMObject still exists } In this example, MyCOMObject exists after a call to Foo. Assigning null to the O bj variable mar s it as a candidate for releasing, but the object still exists i n memory. To force the releasing of all such objects and variables, call JScripts CollectGarbage method: [JScript, C++Script, C#Script] function Foo() { Obj = new ActiveXObject("MyCOMObject.Application"); Obj = null; CollectGarbage(); } The described JScript peculiarity may cause a problem with creating virtual user s when performing load tests. For more information on this, see Creating Load Te sts in Scripts in TestComplete help. Due to certain peculiarities of the JScript engine, the instanceof operator retu rns an incorrect value if the chec ed objects are passed between script units. S uppose you have the following code: [JScript, C++Script, C#Script] function fooA(){ try { throw new Error(10,"This is an error."); // Simulates exception } catch(err) { var res = err instanceof Error; Log.Message("fooA: err instanceof Error = " + r); fooB(err); } } function fooB(err) { var res = err instanceof Error; Log.Message("fooB: err instanceof Error = " + res); } If both fooA and fooB reside in the same script unit, in both functions the res variable will be true. If you place fooB to another unit, then the res variable in fooA will be true, and the res variable in fooB will be false. The OnStopTest event is not generated if the script written in JScript, C++Scrip t or C#Script stops upon an unhandled exception.

Index A Analyzing 51, 68 Recorded script 51 Test results 68 Application controls and objects 86 Addressing in scripts 86 Arrays 96 in JScript, C++Script and C#Script 96 C C#Script 74, 96 Peculiarities of usage 96 Selecting the scripting language 74 C++Script 74, 96 Peculiarities of usage 96 Selecting the scripting language 74 Calling 94 Project items in scripts 75 Routines declared in another unit 94 Variables and constants declared in another unit 94 Controls Addressing in scripts 86 Recognizing windows and controls 86 Creating a project 30 D DelphiScript 74, 96 Peculiarities of usage 96 Selecting the scripting language 74 Difference between various TestComplete editions 14 E Enterprise edition of TestComplete 14 Errors 70 Searching for the reason of errors 70 G Getting started with TestComplete 20 Getting Support 19 H How to 94 Calling routines declared in another unit 94 Calling variables and constants declared in another unit J JScript 74, 96 Peculiarities of usage 96 Selecting the scripting language 74 L Languages 74, 96 Comparing features of scripting languages 74 Peculiarities of usage 96 Selecting the scripting language 74 N Naming processes and windows 86 O Overview 5 P Processes Recognition of 86 Project items 23 Projects Creating 30

94

R Recognizing Processes, windows and controls 86 Recording Scripts 46 Results 68 Analyzing 68 Running tests 65 S Scripting 72 Comparing features of scripting languages 74 Overview 72 Quic start 75 Scripting languages 74 Supported languages Peculiarities of usage 96 Scripting languages 74, 96 Comparing features of scripting languages 74 Peculiarities of usage 96 Selecting the scripting language 74 Scripts 46 About writing scripts 72 Analyzing recorded script 51 Quic start 75 Recognition of processes and windows 86 Recording 46 Writing scripts 72 Writing scripts Quic start 75 Specifying the execution flow for tests and test items 62 Standard edition of TestComplete 14 Supported development tools 16 System Requirements 17 T Test items 62 Specifying the execution flow 62 Test results 68 Analyzing 68 TestComplete Difference between Standard and Enterprise editions 14 Getting started 20 Overview 5, 20 Projects and project items 23 Supported development tools 16 What's new 5 Tested applications 33 Defining applications to test 33 Tests 43 About 43 Creating 43 Running tests 65 Specifying the execution flow 62 U uses statement About 94 V VBScript 74, 96 Peculiarities of usage 96 Selecting the scripting language 74 W What's new in TestComplete 5 5 Win32Menu object 7 Win32MenuItem object 7 Windows

Recognition of 86