Difference between revisions of "Framework/Article/VCLTestTool"
(first version (checkpoint save)) |
|||
| Line 42: | Line 42: | ||
The [[hid.lst]] contains matches of so called longnames to numbers. In the running testee only the numbers are available, so they can be converted to the corresponding longname using this list. these longnames are matched to so called shortnames which then define the new commands to be used in the testscripts. From time to time the numbers change for various reasons, but the longnames stay the same, so they don't have to get matched to the shortnames again. | The [[hid.lst]] contains matches of so called longnames to numbers. In the running testee only the numbers are available, so they can be converted to the corresponding longname using this list. these longnames are matched to so called shortnames which then define the new commands to be used in the testscripts. From time to time the numbers change for various reasons, but the longnames stay the same, so they don't have to get matched to the shortnames again. | ||
| − | The *.sid and *.win file format is fairly easy and described in the [http://qa.openoffice.org QA project] | + | The *.sid and *.win file format is fairly easy and described in the [http://qa.openoffice.org QA project] [http://qa.openoffice.org/qatesttool/OOo_testtool.pdf Introduction to Automated GUI Testing] chapter 4. |
Revision as of 11:39, 28 January 2009
VCLTestTool technical documentation
- NOTE: all pathes to sources are relative to SRC_ROOT
Contents
Overview
The VCLTestTool consists of two parts, one is the standalone Application which is used to run and edit the test scripts, the other part is a controller which is located in the Application under test (typically the OpenOffice.org).
Communication between the Scripting Application and the Controller is provided by TCP/IP.
The VCLTestTool sends, unless otherwise commanded, single commands to the Controller which executes them and returns the results. Results can be values which have been requested and a status whether the command succeeded or failed.
The standalone Application
The Controller
Commands
the CVLTestTool defines new commands to fulfill the special needs of a testing system. They become part of the language and can be called like any other command. There are several types of commands and it is important to understand the differences between them.
Local Commands
Local Commands are executed inside the VCTestTool anbd need no connection to a running Test Application. In the code they are declared using the MAKE_TT_KEYWORD macro. The code for definition and execution is located in automation/source/testtool/objtest.cxx.
Remote Commands
Remote Comands need a connected testee to work. They are transmitted to the testee via TCP and the VCLTestTool waits for an answer from the testee. They fall apart in two main categories:
Static Commands
Static Commands are those commands, that are compiled into the Application. They are defined in an include file which is dynamically generated during build time from the header file automation\source\inc\rcontrol.hxx. The commands are loaded in automation/source/testtool/objtest.cxx in TestToolObj::InitTestToolObj()
Dynamic Commands
Dynamic Commands are loaded at runtime using the 'use' command. There are two types of dynamic commands. One type allows to call slots (which often are UNO URLs nowadays) directly. E.g.: to toggle Underline for text or to open a file directly (not having to automate the file open dialog). These are loaded from *.sid files from the directory testautomation/global/sid.
The second type of Dynamic Commands are the definitions to access the GUI of the testee. They are organized hirarcically. Always grouped in one dialog, Toolbar or whatever unit suits the script developer. To access one group you first have to set a context using the command
context "MyDialog"
where MyDialog is the name of the desired group. Afterwards the subelements and the Dialog itself can be accessed in an object like notation. E.g.: MyDialog.Close or MyDialog.GetCaption() These Commands are defined in *.win files located in testautomation/global/win.
Defining Dynamic Commands / the hid.lst
to access the GUI of the testee you need to be able to identify each UI Element such as listboxes, buttons and editfileds. In OpenOffice.org most UI Elemts or Controls have a unique HelpID. The few that have none did get a UniqueID for automation purposes. These IDs are generated automatically for many types of Controls. For the remaining they are stated explicitly in the *.src files. When compiling the *.src files there are also hid files generated which are combined at the end of the build to the hid.lst. The hid.lst also contains some slot definitions because they are sometimes also used for the corresponding dialogs (fileOpen Dialog has the same HelpID as the slotID which does open it).
The hid.lst contains matches of so called longnames to numbers. In the running testee only the numbers are available, so they can be converted to the corresponding longname using this list. these longnames are matched to so called shortnames which then define the new commands to be used in the testscripts. From time to time the numbers change for various reasons, but the longnames stay the same, so they don't have to get matched to the shortnames again.
The *.sid and *.win file format is fairly easy and described in the QA project Introduction to Automated GUI Testing chapter 4.
--Gh 10:50, 28 January 2009 (UTC)
