After the test finishes, TestComplete shows the test log with the results of all test operations.
The results of our test look as follows:
The log contains messages of different types: actions, events, checkpoints, and so on. You can filter the messages using the toolbar above the message list. If you double-click a log message, TestComplete will navigate to the test operation that posted this message. This is useful when you need to know which operation caused an error.
The Picture panel contains images that show the expected and the actual application states before the selected test command is executed (“Expected” is the image that was captured for the command during test recording, and “Actual” is the image that was captured during the test run.) The Actual Image toolbar has a special button that lets you highlight the difference between the images (if any). The images help you understand what happened in the application during the run, view the differences, and find errors faster. For more information on capturing images, see the topics of the Test Visualizer section.
The Details panel contains details on the performed operation. For example, Details for property checkpoints includes the check type (equals, contains, matches a regular expression, and so on) and other details.
All logs are kept under Project Suite Logs > ProjectName Logs in the Project Explorer, so that you can review the previous logs.
Note: | By default, TestComplete stores all test results in log files. The number of the log files will grow with every test run, and this will result in the memory consumption increase. To reduce memory usage, you can delete files from the log manually or limit the number of log files to be kept. |
Resolving Errors
Your test may fail. There can be several possible reasons for this. For example, developers could change the application behavior, the recognition attributes of application controls could change and make the test engine fail to find the needed objects, and so on.
One of the most typical reasons that novice users face is the difference in the application state during the test creation and playback. To avoid this problem, make sure that the initial conditions of the test run correspond to those you had when creating the test. For instance:
If the tested application had been running before you recorded a test, it must also be running before you run the test.
If test actions were performed on a particular screen of the application, you should open the screen when running the test.
If you edited any data in the application, and then saved it, you need to revert the changes.
If the tested application has changed and the identification properties that your test uses to find tested objects are no longer valid, TestComplete will try to detect the changes to find the missing objects. If your test log reports the “Object <Object_Name> was replaced with a similar object” warning, this means that TestComplete was not able to find the needed tested object during the test run and used a similar object instead.
Do not ignore this warning. Examine it to learn about the missing and the replaced objects and update the object’s identification properties to resolve the issue.
Sometimes, the test engine fails to find an application object because it needs to wait for a specific application response. To solve this problem, insert a delay command and specify for how long the text execution should be paused:
In keyword tests, use the Delay operation with the Delay Time parameter specified.
In scripts, use the
aqUtils.Delay
method with the loop body.
For information on searching for the cause of errors and resolving typical problems, see Handling Playback Errors.
See Also
About Tested Application
Test Results
Handling Playback Errors