Runtime analysis overview

The runtime analysis tools are designed to closely monitor the behavior of your application for debugging and validation purposes. These features use source code insertion to instrument the source code providing dynamic analysis of the application while it is running, either on a native or embedded target platform.

The following tools are available:
  • Code coverage performs code coverage analysis.
  • Memory profiling analyzes memory usage and detects memory leaks.
  • Performance profiling provides metrics on execution time for each procedure/function/method of the application. For C language, it also provides an estimation of WCET.
  • Control Coupling provides coverage information on Control Coupling that represent the interactions between modules (C language only).
  • Data Coupling provides coverage information on def/use pairs identified in the application (C language only).
  • Worst Stack Size computes an estimation of the maximum of the application stack size (C language only).
  • Runtime tracing draws a real-time UML sequence diagram of your application.

Each of these runtime analysis tools can be used alone or together with the component testing features. When the source code is run with any of the runtime analysis tools engaged, either alone or in a component test, the source code is instrumented. The resulting instrumented code is then executed and the result is dynamically displayed in the corresponding reports.

Note: Instrumentation of the source code generates a certain amount of overhead, which can impact application size and performance.

Runtime analysis tools can analyze source code that complies with ANSI 89, ANSI 99, C99, and K&R C specifications.

Code coverage

Source code coverage consists of identifying which portions of a program are executed or not during a given test case. Source code coverage is recognized as one of the most effective ways of assessing the efficiency of the test cases applied to a software application.

The code coverage tool can provide the coverage information for the following source code elements:
  • Statement blocks, decisions, and loops.
  • Function or procedure calls.
  • Basic conditions, modified conditions/decisions (MC/DC), multiple condition, and forced condition.
  • Procedure entries and exits.
  • Terminal or potentially terminal statements
  • Statements that can't be covered in C.

For more information, see Code review overview.

Memory profiling

Runtime memory errors and leaks are among the most difficult errors to locate and the most important to correct. The symptoms of incorrect memory use are unpredictable and typically appear far from the cause of the error. The errors often remain undetected until triggered by a random event, so that a program can seem to work correctly when in fact it's only working by accident. Memory profiling helps you detect HEAP memory allocation problems and leaks.

After execution of an instrumented application, the Memory Profiling report provides a summary diagram and a detailed report for both byte and HEAP memory block usage. The summary diagrams give you a quick overview of HEAP memory usage in blocks and bytes, including:
  • The total HEAP memory allocated during the execution of the application.
  • The HEAP memory that remains allocated after the application was terminated.
  • The maximum HEAP memory usage encountered during execution

The detailed section of the report lists memory usage events identified as errors or warnings.

For more information, see Memory profiling overview.

Restriction: With HCL OneTest™ Embedded for Eclipse IDE, static and stack memory are not checked, only dynamically allocated memory is checked.

Performance profiling

The performance profiling tool provides performance data for each software component so that you can locate the performance bottlenecks. With this information, you can concentrate your optimization efforts on those portions of code, which can lead to significant improvements in performance.

The Performance Profiling report provides function profiling data for your program and its components so that you can see exactly where your program spends most of its time. A Top Functions graph provides a high level view of the largest time consuming functions in your application. The Performance Summary section of the report indicates, for each instrumented function, procedure, or method (collectively referred to as functions), the number of calls and the time spent in the function and in its descendants. And for C language, it provides the Worst Case Estimation Time. For more information, see Performance Profiling Results.

Runtime tracing

Runtime Tracing is a tool for monitoring real-time dynamic interaction analysis of your source code by generating trace data, which is dynamically turned into a UML sequence diagram. The diagram displays a lifeline of the interactions of the source code components. For more information, see Runtime tracing overview.

Control Coupling

HCL OneTest™ Embedded introduces a new coverage level called “Control Coupling" for C language that consists in verifying that all the interactions between modules have been covered by at least one test. This new coverage level is implemented in HCL OneTest™ Embedded as follows:
  • Modules on C language and compilation units (example: C files that are independently compiled).
  • Interactions are calls between 2 functions that are in 2 different compilation units.
  • Control Coupling is not a simple interaction. It is a control flow in the calling module that ends with an interaction with another module.

For more information, see Control Coupling overview.

Data Coupling

HCL OneTest™ Embedded introduces a new coverage level called “Data Coupling" for C language that consists to verify that all the global variables of the application under test has been consumed in read (also called use) and write (also called def) during the tests, as following:
  • For each global variable, HCL OneTest™ Embedded identifies the def and use. Then it considers all the possible def/use pair as a data coupling.
  • To cover a Data Coupling, i.e. a def/use pair, it should exist at least one test that has executed this def and this use.

For more information, see Data Coupling.

Worst Stack Size

Static analysis and Dynamic analysis are used to provide an estimation of the worst stack size.

For more information, see Worst Stack Size overview.