Once you have your trace log files, evaluate the information they contain to find the main reasons for unnecessarily long execution times. In this article, find a few example evaluations that help you turn trace data into concrete optimizations.
Open the newest timestamped All log for a quick overview. Then, switch to Repository or AllInput logs to investigate the bottlenecks you find.
Time-by-event evaluation
A time-by-event evaluation is a good way of finding out which event types take the most time.
In the above example, you can see that accessing repository items takes up half of the test execution time, and mouse clicks and keyboard sequences take up another 30 % combined. Here, it may be a good idea to do another test run with the repository tracer and the all-input tracer to see in more detail which repository items and actions take up the most time, so you can optimize those, e.g., by adjusting the RanoreXPaths of the repository items.
Delay actions also take up 12 %. It’s a good idea to check out where you can replace those with Wait for actions, which only stop the test for as long as necessary instead of for a fixed amount of time.
Time-by-repository-item evaluation
Using the repository log, you can evaluate which repository items take the longest to be found and identified. This tells you which items you should take a closer look at, for example, for adjusting the RanoreXPath to be quicker.
Time-by-test-container/module evaluation
The time it takes individual test containers or modules to execute is also a useful metric. Use it to find out where your test suite is slowest, so you can make structural improvements, for example, or remove clutter from test cases and modules.