Using log files in your testing process
A log file is one of the most common tools in daily testing practice, but according to my experience, testers’ knowledge of correct using with log files is very limited. Usually, the average tester experience is confined to find errors and fatal in logs files, or alternatively 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 testers to configure correct log file and using a log as a main tool in a testing process.
A log file 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 log file you can configure the logging mechanism. There are some types of messages in log files, those messages called the “log level”. The 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 Warn, Error, Fatal messages.
– Error– Logs error messages. The Error message is printing in a log file when there is error in one of system capacity; in addition 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 reason for a system loading and sometimes for a performance degradation. The advantages of seeing all messages, is 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 in order to capture both warnings and error messages. If you prefer to ignore warning messages, set the level to Error in order to display only error messages. If you have a problem to find any message during you testing process, pay attention that you configured the log file to 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 summary, I think it’s very important to understand how to use a log during the 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 in order solve the problem.