Changes between Version 1 and Version 2 of Documentation/T3Q/Quality-Checks/Log-Statements
- Timestamp:
- 02/17/12 12:51:20 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Documentation/T3Q/Quality-Checks/Log-Statements
v1 v2 1 === Log Statements === 2 ==== Log Format Must Match the Format of a Regular Expression ==== 3 * '''Symbolic Name in XML Configuration''': checkLogStatementFormat 4 * '''Dependant Tags in XML Configuration''': logFormatRegExp, checkLogItemFormat, processSubsequentLogStatementsAsOne 1 5 2 === Log Statements === 3 4 ==== Log Format Must Match the Format of a Regular Expression ==== 5 - '''Symbolic Name in XML Configuration''': checkLogStatementFormat 6 - '''Dependant Tags in XML Configuration''': logFormatRegExp, checkLogItemFormat, processSubsequentLogStatementsAsOne 7 8 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 9 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. 6 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. 10 7 11 8 The current default regular expression is: 9 12 10 {{{ 13 11 [\*]{3}\s([fta]_[a-zA-Z0-9]+?):\s(INFO|WARNING|ERROR|PASS|FAIL|INCONC|TIMEOUT):\s.*?[\*]{3} 14 12 }}} 13 The '''checkLogStatementFormat''' setting enables checking the ''whole'' log statement where multiple log items within a single log statement are joined as one. In case of string concatenation and/or use of non-chastring elements (e.g. variable references, constant references, parameter references, or function calls), all non-charstring elements are currently substituted by an empty string. Note that charstring elements used as parameters in e.g. function calls currently will also be taken into consideration when checking the log statement format. 15 14 16 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. 15 For individual log items, the '''checkLogItemFormat''' setting can be enabled instead. The same regular expression is used for checking individual log items. Note that even though the same regular expression is used, 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 non-charstring elements as noted above). Due to possible confusion introduced by this additional check and its questionable usefulness, it should be considered deprecated and will be removed in future releases. 16 17 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. 17 18 18 19 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. … … 20 21 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. 21 22 22 23 23 '''Example:''' 24 24 25 25 [[Include(source:trunk/t3q-examples/checkLogFormat/checkLogFormat.ttcn3, text/x-rst)]] 26 26 27 ==== External Function Invocation Must Be Preceded By A Log Statement ==== 28 * '''Symbolic Name in XML Configuration''': checkExternalFunctionInvocationPrecededByLogStatement 29 * '''Dependant Tags in XML Configuration''': - 27 30 28 ==== External Function Invocation Must Be Preceded By A Log Statement ==== 29 - '''Symbolic Name in XML Configuration''': checkExternalFunctionInvocationPrecededByLogStatement 30 - '''Dependant Tags in XML Configuration''': - 31 32 Checks whether any invocation of an external function is preceded by a log statement. The examples shall generated warnings for 33 all the invocations that do not have a log statement preceding them directly (tagged as ''bad''). 31 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''). 34 32 35 33 '''Example:''' … … 40 38 41 39 ==== Inconclusive or Fail Setverdict Statement Must be Preceded by a Log Statement ==== 42 -'''Symbolic Name in XML Configuration''': checkInconcOrFailSetVerdictPrecededByLog43 - '''Dependant Tags in XML Configuration''': -40 * '''Symbolic Name in XML Configuration''': checkInconcOrFailSetVerdictPrecededByLog 41 * '''Dependant Tags in XML Configuration''': - 44 42 45 Checks whether setverdict statements that set inconc or fail verdicts are preceded by log statements. In the example, the first 46 alt statement represents the expected syntax whereas the second alt statement fails to have log statements before the two existing 47 fail and inconc setverdict statements. 43 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. 48 44 49 45 '''Example:''' 50 46 51 47 [[Include(source:trunk/t3q-examples/checkInconcOrFailSetVerdictPrecededByLog/checkInconcOrFailSetVerdictPrecededByLog.ttcn3, text/x-rst)]] 52