Changes between Initial Version and Version 1 of Documentation/T3Q/Quality-Checks/Log-Statements

Timestamp:

06/03/10 15:59:46 (14 years ago)

Author:

zeiss

Comment:

Importing pages from "/var/lib/svn/trac/etsicheck2" using ​WikiImport plugin.

Documentation/T3Q/Quality-Checks/Log-Statements

@@ +1 @@
+
+=== Log Statements ===
+
+==== Log Format Must Match the Format of a Regular Expression ====
+ - '''Symbolic Name in XML Configuration''': checkLogStatementFormat
+ - '''Dependant Tags in XML Configuration''': logFormatRegExp, checkLogItemFormat, processSubsequentLogStatementsAsOne
+
+The check inspects the string in each log statement and matches it against a given regular expression. The predefined regular expression corresponds to the current ETSI guidelines. The regular expression can be adapted and customized for each profile however by changing the
+content of the '''logFormatRegExp''' tag in a profile of the XML configuration. In addition, the first regexp group is matched against the name of outer compound of the log statement, i.e., the function, testcase, or altstep name. If the first group is empty, the latter additional check will be ignored. That means, if T3Q shall not check for the containing construct, there must be an artificial empty first group in the specified regexp. 
+
+The current default regular expression is:
+{{{
+[\*]{3}\s([fta]_[a-zA-Z0-9]+?):\s(INFO|WARNING|ERROR|PASS|FAIL|INCONC|TIMEOUT):\s.*?[\*]{3}
+}}}
+
+The '''checkLogStatementFormat''' setting enables checking the ''whole'' log statement (joining multiple log items within a single log statement as one, variables are currently substituted by an empty string). If the individual log items need to be checked, the '''checkLogItemFormat''' setting shall be enabled instead. The same regular expression is used for checking individual log items. Note that even though the same regular expression. both checks are independent, meaning both can be enabled at the same time, with one checking the individual log items within a log statement and the other combining those log items and checking their concatenation (ignoring variables). Furthermore, by enabling the '''processSubsequentLogStatementsAsOne''' setting, subsequent log statements can be combined and analyzed as one (again ignoring variables within log statements), in a way similar to how log items are analyzed together within a log statement. This setting has no effect if '''checkLogStatementFormat''' is disabled. 
+
+Note that subsequent log statements (without any other statements in between) are always combined when the '''processSubsequentLogStatementsAsOne''' setting is enabled. This may in some cases lead to unreliable results, if, for example, one well-formed log statement is followed by another not well-formed one, the combination of the two may still yield a valid log statement with the setting enabled.
+
+Note also if the '''processSubsequentLogStatementsAsOne''' setting is enabled, the subsequent log statements that are combined together are analyzed as a bundle starting with the first log statement in the sequence, meaning that the subsequent log statements are not analyzed individually again.
+
+
+'''Example:'''
+
+[[Include(source:trunk/t3q-examples/checkLogFormat/checkLogFormat.ttcn3, text/x-rst)]]
+
+
+==== External Function Invocation Must Be Preceded By A Log Statement ====
+ - '''Symbolic Name in XML Configuration''': checkExternalFunctionInvocationPrecededByLogStatement
+ - '''Dependant Tags in XML Configuration''': -
+
+Checks whether any invocation of an external function is preceded by a log statement. The examples shall generated warnings for
+all the invocations that do not have a log statement preceding them directly (tagged as ''bad'').
+
+'''Example:'''
+
+[[Include(source:/trunk/t3q-examples/checkExternalFunctionInvocationPrecededByLogStatement/checkExternalFunctionInvocationPrecededByLogStatement.ttcn3, text/x-rst)]]
+
+Note that if an external function is called within a constant or a template definition on the module level, an information message will be provided that in such a context it is not possible to have a log statement following it. Note also that if a function definition cannot be resolved, a corresponding information message will be provided as well.
+
+==== Inconclusive or Fail Setverdict Statement Must be Preceded by a Log Statement ====
+ - '''Symbolic Name in XML Configuration''': checkInconcOrFailSetVerdictPrecededByLog
+ - '''Dependant Tags in XML Configuration''': - 
+
+Checks whether setverdict statements that set inconc or fail verdicts are preceded by log statements. In the example, the first
+alt statement represents the expected syntax whereas the second alt statement fails to have log statements before the two existing 
+fail and inconc setverdict statements.
+
+'''Example:'''
+
+[[Include(source:trunk/t3q-examples/checkInconcOrFailSetVerdictPrecededByLog/checkInconcOrFailSetVerdictPrecededByLog.ttcn3, text/x-rst)]]
+