General

MyITest4U supports the testing of different application types. The general working of MyITest4U is independent of the application type. Application specific help is found under the correspondent application type.

The following terms are used in this document:

• Test
• Test block
• GUI element
• Action
• Test step
• Test parameter
• String check point
• Test data

A brief description of these terms is given below. Some of the terms are difficult to describe but easy to understand. Examples are given for these terms instead of a description.

Test Block

A test block contains one or more test steps.

Test

A test contains one or more test blocks.
A test is the biggest unity in MyITest4U.
A test block can be used as a test.
In this document the word test can also stand for a Test Block.

GUI Element

A GUI element can be a button, text field, ….

Action

An action always belongs to a GUI element. An action can be a click, setting of text, …

Test Step

A test step contains a GUI element, an action, none, one or more parameters and an optional check point.

Test Parameter

A test parameter belongs to a test step. An example for a test parameter is the text which is entered into a text field.

String Check Point

A string check point is a string which needs to be present or absent on a certain page. The check is done after the action of the test step is completed. The actions after which a string check point will be done, can be defined in the configuration.

Test Data

The test data is all the data which belongs to a test. The test data is stored in the parameter file which belongs to a test. It contains the test step parameters and the string check points. Beside these data it might contain additional information. The additional information will be explained later on.

Where the information is stored

MyITest4U uses a data base to store all test relevant data.
The test data is also stored in files. Test data can be generated outside from MyITest4U. The test data can be imported into MyITest4U by opening the test data file which belongs to test using the build in CSV editor from the test generation editor and saving the test data file using the build in CSV editor (the test data file needs to contain a change for this to work).

Working of MyITest4U

MyITest4U has four main parts. They are:

• Collection of GUI elements
• Generation of Test Block / Test
• Test execution and analysis
• Test migration

Collection of GUI elements

The collection of GUI elements can be done automatically and / or manually. The automatic collection of GUI elements is done by the Spider. The Spider works in the following way. It treats an AUT (application under test) as a tree.

In the first round all GUI elements of the first tree level are collected. In the second round the GUI elements from the first round are used to get one level deeper in the AUT tree. The Spider goes on till no more new GUI elements are found.

Manual GUI element collection can be done after an action. It will collect all the GUI elements of the current page.

The following approach can be taken to collect the GUI elements.

Collect the GUI elements of the starting page.
Use the Spider configuration to exclude GUI elements which will lead to repeated collection of the same GUI elements e.g. GUI elements in the footer.
Let the Spider collect GUI elements for a reasonable amount of time.

Use the collected GUI elements to build tests which will show the missing pages. Collect the GUI elements of these pages as the last step in the test run.

Besides the GUI elements also the creator of the GUI elements is stored in the database. The creator name is the name of the test used to insert the GUI elements. GUI elements can be removed by creator (Maintenance / Remove GUI Elements by Creator). This is useful to remove GUI elements which where inserted by accident.

Generation of Test Block / Test

The test generation editor can be used for test block / test generation. A new parameter file is written after each save of the test. It is recommended to build a test block and test it thoroughly before writing big parameter files. It might also be worth to consider the generation of parameter files programmatically.

Further it should be considered to use programmatic algorithm to generate whole tests or test templates.

Test migration

The recommended steps for a test migration are as followed:

1. Run the Spider on the new release.
2. Migrate all GUI elements used in tests from the old to the new release and migrate the test steps.
3. Run the tests used to get missing GUI elements.
4. Migrate all GUI elements used in tests from the old to the new release.
5. Repeat till all GUI elements are migrated.
6. Fix all test step sequence changes.
7. Update the parameter files for the new tests.

MyITest4U supports the mapping of the old GUI elements to the new ones with the Migration Editor.

This editor allows you to migrate GUI elements one by one.

In case of many systematic changes in the GUI elements it might be worth to consider writing a program to speed up the migration of the GUI elements even more.

Directory structure

Everything belonging to MyITest4U is found under …/MyITest4U.

The main directories are:

Test Generation Editor

The test generation editor is used to build, run and analyze Test / Test Blocks.

In the following the main features of the editor are described.

Toolbar icons

	A refresh will get the data from the database again. It might be necessary after new GUI elements have been inserted into the database to make them visible in the editor.
	Will remove all data form the editor table.
	Saves the Test / Test Block under the given name. In case the Test / Test Block is already present an update will be done. An update will remove all test steps from the database and reinsert them. A save / update will also rewrite the parameter file. In most cases only the first line will be rewritten. The content of the previous two version of the parameter file is stored in the same file.
	Analyze will show the test results of the current Test / Test Block.
	Reorder Test Steps will number the test steps from one to n as they are shown in the editor table.
	Stops a running test.
	Adds the current test block to the current test. In the addition dialog you can chose the position of the test block in the test. The test needs to be saved to make the addition permanent.
	Opens the parameter file with the build in CSV Editor.
	Opens the parameter file with an Excel like program. The program to be used has to be set under File / Preferences.
	Opens the parameter file with an Editor like program. The program to be used has to be set under File / Preferences.
	Opens the Migration Editor.
	Open Editor
Loop	Shows the selected loop of a Test / Test Block.

AUT Line

Test Block Editor (Test Block Tab)

Search for a GUI element.

As for the Test / Test Block search "%" can be used as wild card.

Editor Table

Ctrl+Space has to be used to get possible entries for cells which can not be edited directly.

An entered value can be deleted by marking the whole value followed by pressing delete or back.

Tab can be used to navigate from one cell to the next one. A new test step is inserted when Tab is clicked at the end of the row.

Index is the index of the GUI element. Counting of GUI elements starts at 0.

The values set in the values column belong to the selected loop. Initially a parameter file is created with only one loop. Further loops have to be added by editing the parameter file.

The values in the parameter file take always precedence over the values set in the editor.

Saving or updating a test block results in a recreation of the parameter file. The values given in the editor are always used for the first loop.

A right click on a table field will show the context menu.

A test step can be copied, pasted, deleted … using the context menu.

Drag and drop of a test step is also possible.

Both of the above actions can also be done by selecting more than one test step.

The step column can be sorted. Test execution will always use sorted test steps.

Click on the title of a column containing check boxes will set or unset them all. The current settings are not stored.

Test Log Area

Here the test log will appear.

A right click will show the context menu.

Test Block Changes

A change in the test steps of a test block will be reflected in all tests using the changed test block. MyITest4U will try to update the parameter files as well. This update might not work in all cases. In these cases you have to set the parameters manually.

Run Spider / Test

The Spider can be started from the test generation editor using the menu Run / Run Spider. No test or test block can present for the Spider to run. The Run Spider dialog allows you to configure certain specific parameters. You can save the current settings by clicking Save. This will generate a batch file (RunSPIDER.bat) which can be used to run the Spider. The saved settings can be loaded by clicking on Load.
A test can be run from the test generation editor by clicking on the Run icon in the tool bar or by using the menu (Run / Run or Run / Run Configuration). The Run Configuration can be saved. Thereby a batch file, which can be used to run the test is generated. The file has the name Run<Test Name>.bat. The saved Run Configuration can be loaded using the Run Configuration dialog.

Test Analysis

A log file with the name of the test is written when a test is run. The same information is also written to the general log file. Only the general log file is used to obtain test results from the log file.

Test results can be written to the database. Any change in a test will remove the test step results from the database. Only the test result summary will remain.

There is no way to map old test results to a new test. If old test results are obtained from the log file. Only the test result summary will be written to the database. Test step results can not be written to the database.

Parse Test Log

The test log can be parsed using the following menu: Analysis / Parse Test Log and Write to DB.

The log of the parsing is written to the test log area in the editor. The last 100 test results are linked to the tests. Test results obtained from log files containing more the 100 tests have to be written to the database to be able to link the test result to the test.

The test results stored in the database can be viewed using the menu Analysis / Show Test Results.

The test results can be filtered by the following properties:

• Current
• Failed
• Missed
• Reason for Failure

Current results will only show test results of the last test run. Tests results of tests which were changed since the last run are not shown.

The error messages can be shown by clicking Show Error Messages.

The tests can be filtered by error message. Therefore NS needs to be checked in the Error Message Table. All tests having only the selected error messages will be removed from the test results overview after a refresh is done.

Universal Check Points

Two kind of universal check points exist in MyITest4U.

The first kind are strings which need to be found or not found after certain action. These check points can be set in the AUT configuration (AUT / New AUT or AUT / Update AUT). They can be useful to find some general errors like missed language strings.

The second kind of universal check points use a reference. Each test run is compared against this reference. The reference can be for example the source of the HTML page (details see under each test engine section). These universal check points work in the following way. In a first test run the reference is recorded. In a second run filters are constructed which will filter away any changes which always occur between two test runs like changes in time stamps or dates. All the following test runs will compare their results against the reference. These kind of check points are useful to detect any changes between two test runs.
Select DoAnalysis in the run configuration to make use of the analysis check points. MyITest4U will then do the following:
First test run will create a reference. Kind of run will be Reference.
Second test run will create the filters. Kind of run will be Run.
Third and all following test runs will do the comparison between Reference and Run.
As soon as a reference folder exists a test run will be labeled Run and all test results will be written to the Run folder.
More details to this kind of check point is given in the module documentation.

Username

As till now the username is used to store:

• profiles.
• test result.

Each user can define his own profiles. Profiles can be shared between users.

Test results are stored user dependent. A user can view test results depending on the user who performed the tests.

The test blocks or tests are not linked to a user name.

Backup and Restore

Backup and Restore are using "pg_dump.exe" and "psql.exe". Both exe files belong to PostgreSQL. They are found in the bin folder of the PostgresSQL installation. The PostgreSQL home folder is set in the MyITest4UDb.properties file. The MyITest4UDb.properties file is found in the folder ..\MyITest4U\TestEngine\Java\Api\resources. After changing anything in the MyITest4UDb.properties file MyITest4U needs to be restarted.

A backup of MyITest4U can be obtained under File / Backup. The following folders are copied to MyITest4U_Backup:

• Analysis
• AutReleases
• TestLog
• TestApplications

The database is stored in the folder MyITest4U_Backup/Database.

The backup is done in the following way. All files are written to MyITest4U_Backup_Temp. After all files are written the original backup is deleted and the temp folder is renamed to the backup folder.

MyITest4U can be restored from the backup using File / Restore. The restore process will first write the current MyITest4U folder to MyITest4U_Backup_Temp. After that the database will be removed and recreated from the backup. The following folders will be deleted and restored from the backup:

• Analysis
• AutReleases
• TestLog
• TestApplications

MyITest4U needs to be restarted after restoration has finished.