LCSAJ coverage is the most thorough of the attainable source code coverage metrics.
It is attainable in that the number of LCSAJs in a code base makes it practical and proportionate to exercise a large majority of them. And it is thorough in that achieving any given level of LSCAJ coverage exercises more of the code base than achieving the same level using a comparable coverage metric (including function, statement, and branch coverage).
The implementation of LCSAJ coverage analysis in the LDRA tool suite® is uniquely complete and thorough because of its application of static and dynamic techniques in combination.
An LCSAJ is a path fragment – a linear sequence of executable code. Each LCSAJ commences either from the start of the program or from a point to which control flow may jump. It is terminated either by a specific control flow jump or by the end of the program.
JJ-path – an abbreviation of “Jump-to-jump path” – is another name for an LCSAJ.
An LCSAJ is a path fragment. LCSAJ coverage is a white box testing method – that is, requires access to the source code, and presents results with reference to that source code.
LCSAJ coverage is a measure of how many LCSAJs are exercised by a particular test data set.
When combined, LCSAJs form a finite set of paths through the source code application under test. The finite nature of this set of paths means that it is feasible to test all LCSAJs. In contrast, while it may be desirable to attempt to test all control flow paths, it is not technically possible for anything other than the most trivial of programs. This is because even simple constructs, when used in combination, give rise to an exponentially large number of paths and any non-deterministic loop constructs will yield a potentially infinite number of paths.
The use of LCSAJ coverage forces the analysis of loops and the analysis of combinations of program constructs and hence ensures that more, potentially error yielding, aspects of a software application are analysed than with any other available method.
The illustration shows output from the LDRA tool suite indicating that more tests are required in this sample code to complete LCSAJ v branch coverage, and LCSAJ v statement coverage.
Successfully testing all LCSAJs demonstrates that a large set of the program paths are correct. LCSAJ coverage is particularly suited to the analysis of high integrity software applications.
One practical problem of using the LCSAJ coverage metric is that some LCSAJs can never be executed due to the conflicting conditions they contain. Some of those may be addressed using automated test tools, but where that remains impossible justification for their omission from the test schedule may be cited.
LCSAJ coverage was designed for use in the development of safety-critical applications. Functional safety standards including IEC 61508 (safety-related systems), ISO 26262 (automotive) and IEC 62304 (medical devices) recommend the use of code coverage analysis, with some standards including EN 50128 (railways) specifically recommending the use of LCSAJ coverage.
Secure coding has an important part to play in any defence-in-depth strategy. The white-box DAST provided by the LDRA tool suite enables compiled and executed code to be tested in the development environment or, better still, on the target hardware. Code coverage facilitates confirmation that all security and other requirements are fulfilled by the code, and conversely that all code fulfils one or more requirements. Standards including IEC 62443 (industrial automation) and ISO/SAE 21434 (automotive) recommend code coverage analysis for those reasons. LCSAJ coverage is the most effective code coverage testing mechanism for security- and safety-critical applications alike.
The LDRA tool suite measures the LCSAJ coverage attained when sets of test data are applied to the source code application under test.
The static analysis features of the tool suite identify all the vital control flow information for each procedure and the inter-procedural links. The interfaces are accurately delineated, the loop structure is exposed, and complexity metrics are generated. This information provides the basis for the definition of the LCSAJ “start, end, jump to” triples.
Structural coverage is collated as the code is then executed using the dynamic analysis features of the LDRA tool suite during unit, integration, and/or system test. The execution count is listed for each LCSAJ, unexecuted LCSAJs are highlighted, and the collated coverage statistics from multiple executions are tabulated.
Unreachable LCSAJs are also listed, which will always start from lines of code that are themselves unreachable. The removal of unreachable code yields more readable and efficient code and reduces the attack surface of the code base.
LCSAJ density is a maintainability metric. If a line of code is to be changed then the density informs the user how many LCSAJs (and hence paths) may be affected by that change. If the density is high then confidence that the change is correct for all LCSAJs will be reduced, and therefore an increased amount of regression testing will be required.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707