Configure log tracking of your application

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 OpenText Functional Testing-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.

Additionally:

  • 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.

Back to top

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.

Back to top

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 OpenText Functional Testing.)
  • OpenText Functional Testing 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 OpenText Functional Testing is installed) and the remote computer are synchronized.
  • Some applications may need to be restarted after modifying the log configuration file.

Back to top

Supported log tracking options

OpenText Functional Testing supports the following log tracking configuration options:

UI Elements

Description
Add log messages to run results

Enables OpenText Functional Testing 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
  • Network (0.0.0.0). Enables OpenText Functional Testing to receive log messages from the log framework wherever it is located—either on a remote computer on the network or on the local computer.
  • Local (127.0.0.1). Enables OpenText Functional Testing to receive log messages only from the log framework on the local computer.
Port

The port that OpenText Functional Testing 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:

  • TRACE (maps to micDone)
  • DEBUG (maps to micDone)
  • INFO (maps to micPass)
  • WARN (maps to micWarning)
  • ERROR (maps to micFail)
  • FATAL (maps to micFail)
Auto-configure log mechanism

Instructs OpenText Functional Testing to configure the log framework (using its log configuration file) at the beginning of every run session according to the settings in this pane. If you clear this checkbox, OpenText Functional Testing receives log messages only if you modify the log configuration file accordingly.

When using the Auto-configure log mechanism option, make sure that:

  • All logging prerequisites are met, for example, you may need to set registry values that are specific to your application.
  • The log framework's configuration file is writable and is in a location that OpenText Functional Testing can access.
  • Your application's log framework is configured to use the same file you specified in the Configuration file edit box.

  • Your application's log framework can monitor changes in the configuration file. If not, then you must always start your application after the run session begins so that OpenText Functional Testing can modify the configuration file.

    Note: If your application's log framework monitors your configuration file infrequently (for example, once per minute), start your application immediately after the run session begins. This enables OpenText Functional Testing to modify the configuration file in time to receive the log messages generated during the run session.
Configuration file

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:

  • *.XML (Java and .NET)
  • *.CONFIG (.NET)
  • *.LOG4NET (.NET)

Note: OpenText Functional Testing 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), OpenText Functional Testing modifies only the file specified in this text box. If you need to configure multiple files, do so manually. OpenText Functional Testing 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 OpenText Functional Testing receives from the log framework and sends to the run results.

Possible values in order of severity:

  • TRACE (maps to micDone)
  • DEBUG (maps to micDone)
  • INFO (maps to micPass)
  • WARN (maps to micWarning)
  • ERROR (maps to micFail)
  • FATAL (maps to micFail)
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).

Back to top

See also: