Revision as of 11:09, 20 February 2010

>]]

>]]

Tool for Automated Testing of OpenOffice.org

About the TestTool

The TestTool is a program that is used for the automated testing of OpenOffice.org. The TestTool communicates with the TCP/IP-Interface of OpenOffice.org and can test each installation of OpenOffice.org on a PC. The current TestTool can be used on OpenOffice.org 3.0 and higher. However, as there can be some incompatible changes in future OpenOffice.org builds you may need to use a newer version of the TestTool.

The TestTool communicates with OpenOffice.org using SlotIDs, UniqueIDs, and HelpIDs that are associated with each menu item, window, dialog, and window or dialog control in OpenOffice.org. The IDs are automatically generated during the OpenOffice.org build-process or are assigned by developers.

You can create test scripts for the TestTool in the programing language StarBasic (like VisualBasic). Several commands are available for the TestTool, for example, to get or put information into OpenOffice.org controls. For a complete list of the available commands, see: Internal Commands, Methods and Functions for TestTool.You can simulate most mouse or keyboard actions with the TestTool as well as gather information from controls or change the default settings in OpenOffice.org. In other words, the TestTool lets you simulate an OpenOffice.org user.

Location of the TestTool

The TestTool Environment can be checked out via Mercurial on openoffice.org, and will be found in the directory: testautomation; Or it is available as a seperate package at: http://ooopackages.good-day.net/pub/OpenOffice.org/qa/testautomation/

The TestTool application is available at http://qa.openoffice.org/ooQAReloaded/AutomationTeamsite/ooQA-TeamAutomationBin.html ; On other platforms in the installation set (see setup). Just use the binary from the .../{officepath}/program-directory. Start the program testtool.bin respectively testtool.exe. Just for Mac OS X: Copy the script soffice to testtool and run it.

Installing the TestTool

To install the TestTool, extract the contents of the downloaded TestTool archive to your local disk. If more than one user will use the TestTool, copy the contents of the extracted archive to a network drive.

When you run the TestTool executable file, the testtool.ini and .testtoolrc control files are created on Win32 and UNIX, respectively.

If you place a TestTool control file in the directory that contains the TestTool executable file, the control file is automatically copied to the profile directory on Win32, and the user's home directory on UNIX.

Linux only: If you get a message similar to "Couldn't bootstrap uno servicemanager for reason : Couldn't create registry file ...services.rdb for writing", ensure that you are using 'nfslock'. For example, on Linux run /etc/init.d/nfslock status. If it is not running, switch to root and run '/etc/init.d/nfslock start' and 'chkconfig nfslock on'. This is necessary for the TurboLinux and the SuSe 8.1 Linux distributions.

Setting up the TestTool

Choose Extra - Settings - Profile.

Profile: Enter a name for your profile. Log base directory: Enter the path where you want to save the test results.For example: /opt/qa/qatesttool/errorlog/mymachine or d:\qa\qatesttool\errorlog\mymachine Base directory: Enter the root path for the TestTool Environment (without a slash at the end!)For example: /opt/qa/qatesttool or d:\qa\qatesttool Default HID directory: Mark the checkbox.

If you want, you can also edit these settings in the .testtoolrc / testtool.ini files.

CurrentProfile=_profile_Default

(...)

[_profile_Default]

LogBaseDir=/opt/qa/qatesttool/errorlog/mymachine

BaseDir=/opt/qa/qatesttool

HIDDir=/opt/qa/qatesttool/global/hid

Automated Crashreports

Choose Extra - Settings - Crashreport.

Use Proxy: Check if you need to use a proxy to access the internet. Host: Address of the proy.For example: proxy.somewhere.de Port: Enter the port number of the proxy.For example: 8080 Allow Contact: Mark the checkbox if you want to get an Email regarding your crashreport. Email: Your Email address.For example: you@somewhere.de

If you want, you can also edit these settings in the .testtoolrc / testtool.ini files.

[Crashreporter]

UseProxy=true

ProxyServer=proxy.somewhere.de

ProxyPort=8080

AllowContact=true

ReturnAddress=you@somewhere.de

Selecting the OpenOffice.org Installation

There are two choices:

Choose Extra - Settings - Misc.

OOo Program Dir: Select the OpenOffice.org installation to test.For example: /Volumes/OpenOffice.org 2.0.app/Contents/MacOS

If you want, you can also edit these settings in the .testtoolrc / testtool.ini files.

[OOoProgramDir]

Type=Path

Current=/Volumes/OpenOffice.org 2.0.app/Contents/MacOS

All=/Volumes/OpenOffice.org 2.0.app/Contents/MacOS

TestTool Editor

The TestTool uses syntax highlighting for all BASIC, StarBasic, and internal TestTool commands (For more information, see: Internal Commands, Methods and Functions for TestTool). Highlighting can increase the load time for large files.

Starting a TestTool Script

Start local OpenOffice.org installations using the TestTool command line parameter -enableautomation. In the TestTool Environment, executable scripts use the *.bas extension. To run a script, load a *.bas-file, and then run the script from the menu or with a shortcut.

F5 Start Starts the script, opens a new or old result file, and inserts the result of the test in the file. F8 Single stepping Runs the script by single steps. F10 Single step over procedures Runs the script one sub routine at a time. F9 Set / Select a break point Creates a breakpoint (red circle) in the script on the blue border on the left side.	Shift+F5 Cancel Cancels a running script. Ctrl+F5 Interrupt Interrupts a running script. Shift+F8 Next Error Jumps to the next error after a syntax error in a script. Shift+F7 Previous Error Jumps to the previous error in a script.

Result File

The TestTool automatically saves a result file during a test script is run. The name of the result file is the name of the script *.bas-file that generated the result, but with the *.res extension (For example: first.bas - first.res). To set the path for saving the result file, choose Extra - Settings - Profile and enter the path in the Log Base directory box.

If a result file already exists, the file is opened and the new result is added at the beginning of the file.

The results are presented as a hierarchical tree list where you can click plus sign (+) or minus sign (-) to expand or collapse the outputs.

• The first output is Reading the files. Expand this entry to see the declaration files. If the entry is orange, the declaration files (*.win / *.sid) contain errors. The sum of the errors is displayed at the end of a test as Warnings occurred during initialization.
• The next output is a short entry that is generated automatically by the start up routines. The entry displays information about the TestTool version, the paths where OpenOffice.org is installed, and where the application was started. The office- and the system language is also displayed.
• Each entry that has a [+] in front of it is a testcase. If the testcase entry is a color other than black, the test contains errors.
• An orange testcase indicates that one or more warnings are present. To see where the error occurred, expand the entry and examine the warnlogs, which are the outputs from the developer of the test script. To jump directly to the place in the test script where a warning occurred, double-click the warning.
• A light green testcase indicates a QAErrorLog entry that was inserted by the developer of the testcase to give the tester some information (for example, about an existing bug or workaround)
• A light blue testcase indicates an Assertion that gives selectable informatoins when testing a debug build of OpenOffice.org.
• A red testcase indicates that one or more errors are present. The tree is expanded to display the error(s). In the example result file, the error occurred when the TestTool did not find the slot. That is because there is a typo in it ‚Äì it should be ToolsOptions.
• When you expand a red entry by clicking the plus sign (+) in front of the entry, a level by level (sub main - testcase ... - subroutine ... - .....) view of the error is displayed. You can also see what the TestTool did to return OpenOffice.org to a defined base state so that the TestTool can run the next testcase without any open windows or dialogs.For example:
  • the WORKINGWINDOW "Untitled2 - OpenOffice.org Writer" is closed (geschlossen = closed)
  • Explanation:
  • the working document is closed
  • The TestTool then started the next testcase at the base state of OpenOffice.org (that is, with one open document and no open dialog).
• At the end of a test, the number of errors and warnings is displayed

Starting a Test Script From the Command Line

To start a test-script from the command line, use the following syntax:

Run a Batch with Testcases

There are examples for Win32 and Unix at http://hg.services.openoffice.org/DEV300/file/1467f46f8817/testautomation/tools/run_tests.

Testing a Non-Product Version

• Define the files where you want to store the debug-settings for OpenOffice.org by inserting the following section into the win.ini file (If you don't have access to the file, you may use environment variables.):

 [SV]
 dbgsv=c:\dbgsv.ini
 dbgsvlog=c:\dbgsv.log 

• On Linux/Unix/Win32 Platforms you have to set an environment variable to control where the debug-settings are stored:

 DBGSV_INIT=/some/path/dbgsv.ini
 DBGSV_LOG=/some/path/dbgsv.log

• In OpenOffice.org, press Shift+Ctrl+Alt+D, and then select TestTool in the Error list box.
• In the TestTool, assertions are indicated by light blue. To manually reproduce an assertion, select MessageBox in the Error list box.

The TestTool Environment

The structure of the TestTool Environment was changed after the release of source SRC641 (OpenOffice.org 1.0, StarOffice 6.0 / StarSuite 6.0). The following description of paths is only valid for source versions SRX641 and higher.

The TestTool Environment contains the start scripts, the test scripts, and the libraries (include files) that are required to automatically test OpenOffice.org. The TestTool Environment is modular, so that a module exits for each application or area that you want to test in OpenOffice.org. To test a single OpenOffice.org application, such as Writer, you only need the “application module” and the “global” module.

The following subcategories are defined for the TestTool Environment modules:

These are only the defined name, you can also find other subcategories in the paths. Mostly the named of the directory mirror the tested area.

If you find a *.bas-file in one of these directories you are in a test-module. Those module should include the following directories/files:

global-Module

The global-directory is required for each test. The directory contains the main routines for running a test script, including the hid.lst, the declaration files that identify menu items, dialogs and controls in OpenOffice.org, and general tooling routines.

CVS information

The complete TestTool Environment is checked into a CVS-tree under the module name qa/qatesttool. You can then check out the module or the global-module along with the application or module that you want to test. Since the content (such as global routines and the hid.lst) of the global-module can change, update the global-module regularly.

The commandline looks like:
cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs -z3 co -P qa/qatesttool

Configuration file entries

The configuration file (UNIX: .testtoolrc, Win32: testtool.ini) contains several sections.The section name is surounded by '[', ']' and contains several entries like: EntryName=Value.

GUI Platform

Current= depends on the Platform.