How to use log files in your software testing
A log file is one of the most common tools in daily testing practice, but according to my experience, the software engineer’s knowledge of correct use with log files is very limited.
Usually, the average tester experience is confined to find errors and fatal in logs files, or to find a keyword of some message.
In this post, I’ll try to describe and give some examples of server logging that can help software engineers to configure correct log file and use a log as the main tool in a software testing process.
What is a log file meaning?
A log file definition is a file that contains a list of events, which have been “logged” by a computer.
A log file is a recording of everything that goes in and out of a particular server.
The information is frequently recorded chronologically, and is located in the root directory, or occasionally in a secondary folder, depending on how it is set up with the server.
The point of a log file is to keep track of what is happening with the server.
If something should malfunction within a complex system, there may be no other way of identifying the problem.
Log files are also important to keeping track of applications that have little to no human interaction, such as server applications.
Most log files are saved in a plain text format, which minimizes their file size and allows them to be viewed in a basic text editor.
Most log files have a “.log” file extension, but many use the standard “.txt” extension or another proprietary extension instead.
Before you start to work with the log file you can configure the logging mechanism.
There are some types of messages in log files, those messages called the “log level“.
The log levels are All, Info, Debug, Error, Warn, and None.
In server logging. XML file, you can configure the level for each part of the system that you are testing.
The setting log levels described below:
– ALL –Logs all message in a system
– Info– Logs info message. Info messages indicate general information to the developer or tester. If you select Info logging level it will include both Info and Error messages in your logging file
– Debug-Logs debug message. Select the Debug logging level to include Debug, Info, and Warning, Error, Fatal messages.
– Error– Logs error messages. The Error message is printing in a log file when there is an error in one of the system capacity; also, Error messages indicate when a critical service doesn’t go up or available. Select the Error level to include Error and Fatal messages.
– Warn-Logs warning messages. Warning messages indicate that Flex encountered a problem with the application, but the application does not stop running. Select the Warn logging level to include Warn, Error, and Fatal messages.
– None-No messages are logged.
As a default, you can configure a log file to ALL or Debug level, but sometimes this configuration could be problematic because in those levels the system is printing all messages are transferring in system process and this could be the reason for a system loading and sometimes for performance degradation.
The advantages of seeing all messages are a better understanding of the system process and the ability to build test cases in your software test description.
In some cases, you typically can set the logging level to Warn to capture both warnings and error messages.
If you prefer to ignore warning messages, set the level to Error to display only error messages.
If you have a problem finding any message during your testing process, pay attention that you configured the log file to the correct level for your testing.
Each time the server application starts, a new log file is created, and the server will continue to write messages to that log until it reaches the maximum log size.
Once the log file exceeds the maximum size, it is retired and a new log file is created.
In conclusion, I think it’s very important to understand how to use a log file during the software testing process.
The log files provide the information to identify what the errors are, and through the information in the log, infer what to investigate to solve the problem.
Is this post helpful for you? Share your thoughts in comments on how it helped you.
Join to Productive Hut Family and be part of a testing community!