Relevant for: GUI tests and components
This pane enables you to configure and view your log tracking and collection preferences.
Log tracking usage
The settings in the top half are UFT One-specific, enabling it to receive log messages during a run session. The settings in the bottom half are specific to the log configuration file used by your application.
When configured, these settings are used during a run session if your Windows-based application uses a Java or .NET log framework that includes a UDP appender. The log messages generated by your application are displayed in the run results.
- Log tracking settings cannot be modified during a run session.
If external events affect your application while it is being tested, messages about these events may also be sent to the run results.
Caution: To ensure that log tracking settings are saved for application areas, make sure that you make at least one other modification after modifying the Minimum level to log settings. If necessary, select a checkbox and then clear it. Settings will not be saved if the Minimum level to log is the last setting defined.
- For business process tests, log tracking runs only if the application area associated with the first component in the business process test enables it. This means that if another component that runs later in the business process test is associated with a different application area, log tracking settings from that application area are ignored.
Access log tracking settings
Do one of the following:
With a test, action, or component in focus, select File > Settings > Log Tracking node.
Open the application area and select Additional Settings > Log Tracking in the sidebar.
Log tracking prerequisites
Ensure the following before configuring log tracking:
- Make sure that the firewall does not block the UDP port.
- The log framework must use an XML-based configuration file. (This enables you to configure it to send log messages to UFT One.)
- UFT One uses timestamps to associate log messages with the relevant test or component step. Therefore, if your logging application is located on a remote computer, make sure that the system clocks on your application's computer (where UFT One is installed) and the remote computer are synchronized.
- Some applications may need to be restarted after modifying the log configuration file.
Supported log tracking options
UFT One supports the following log tracking configuration options:
|Add log messages to run results||
Enables UFT One to receive log messages from the log framework used by your application and to include these messages in the run results in the Run Results Viewer.
|Log messages source||
The port that UFT One listens to on the computer on which the log framework runs. You can select any UDP port that is not in use.
|Minimum level to add node to results tree||
The minimum log message level for which a node is added to the run results.
Possible values in order of severity:
|Auto-configure log mechanism||
Instructs UFT One to configure the log framework (via its log configuration file) at the beginning of every run session according to the settings in this pane. If you clear this check box, UFT One receives log messages only if you modify the log configuration file accordingly.
When using the Auto-configure log mechanism option, make sure that:
The root path of the configuration file used by the log mechanism. The configuration file can be stored in any accessible location.
Possible configuration file types:
Note: UFT One can update only one file per run session, so if there are multiple configuration files (for example, if the test or component is validating more than one application - each with its own configuration file), UFT One modifies only the file specified in this text box. If you need to configure multiple files, do so manually. UFT One can receive log messages from multiple applications, but can auto-configure only one of them.
|Minimum level to log||
The minimum log message level that UFT One receives from the log framework and sends to the run results.
Possible values in order of severity:
|Recover original configuration file after run session||
Restores the configuration file that existed prior to the beginning of the run session (instead of keeping the configuration file modified at the beginning of the run session).