• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • Deutsch
    • English
  • Menu Menu
You are here: Home1 / FuSa__General2 / The non-intrusive measurement of structural coverage!

The non-intrusive measurement of structural coverage!

FuSa__General

The measurement of structural source code coverage is nowadays defined as an important procedure in many functional safety standards. The non-intrusive measurement of structural coverage offers completely new possibilities in the future. For a long time, it was industry-wide consensus that structural coverage should and could only be determined in so-called white-box tests. In many textbooks, the measurement of structural source code coverage is even promoted as an independent test method. The following blog post shows why things are likely to change in the future.

Introduction of structural source code coverage:

First a short introduction to structural source code coverage.

This is a measure of the degree to which source code is covered by testing. There are different measures of coverage. Usually you start with the coverage of the executable source code lines. This means that once each line of code has been executed, you have 100% coverage.

The famous MC/DC Coverage proves that each parameter within a condition has an effect on the result of the decision. The minimum number of test cases required is the number of variables in a decision + 1.

The following figure illustrates test cases to achieve MC/DC coverage:

Conclusions from practical work:

Across industries, it has been shown that the simple measurement of structural coverage is not a quality statement about the product. This also applies if 100% structural coverage is measured.

What is the reason for this?

Tests that only aim to measure structural coverage find hardly any errors. Good tests always include the observation of the data flow by software. Practice shows more and more clearly that requirements that define functional expectations of the software are needed to find errors.

The measurement of structural coverage represents a meaningful quality statement about the software, only if requirements are taken into account when creating the tests. It is generally accepted that it is practically impossible to create complete requirements and tests for a system. Structural coverage is a very efficient corrective for this particular methodological weakness. A low structural coverage can have only one of the following 3 causes:

  1. the requirements are not complete
  2. the tests are not complete
  3. the uncovered source code is not needed at all

Therefore, it makes no sense to treat structural source coverage measurement as an independent test method. The measurement only makes sense if the corresponding tests are based on requirements.

Conclusion:

In future pure White-Box-Tests (=Unit-Tests which only measure the structural Source Code Coverage) are not needed any more for any formal prove.

This means that for most industries, the pressure will increase to measure coverage at higher test levels. In embedded systems, this is usually the level at which the hardware and software are tested -The integration test. Only for this test level there are usually functional requirements are available.

However, up to now there was usually no technology at all to determine the structural source code coverage with a reasonable effort at this level.

This will change in the near future. The technology and tool development for the non-intrusive measurement of structural source code coverage is making great progress and will replace the classic source code instrumentation in the next few years according to my prognosis. Structural source code coverage can thus take on a completely new role in safety-relevant software development.

Are you ready for a functional safety workshop, to analyse improvement potentials in your development process, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.

 

2. November 2019/by HEICON Global Engineering GmbH
Tags: DO178C, Functional Safety, IEC61508, ISO 26262, non-intrusive Coverage, Software Testing, Validation and Verification, Verification
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
https://heicon-ulm.de/wp-content/uploads/2019/12/DI1A6023_klein_Functional_Safety.jpg 433 547 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2019-11-02 22:44:362021-02-03 21:46:16The non-intrusive measurement of structural coverage!
You might also like
AerospaceSupplements of DO 178C – Where do they come from and what is their content?
Requirement EngineeringRequirement Engineering – Aspects which even not considerd in theory!
IndustrialIEC 61508 – Tool qualification – When? Why? How?
Requirement EngineeringRequirement Categories – Why they are useful?
Validation and VerificationImplicit Testing – A good idea (Part 2)?
Functional SafetyQuality Assurance in functional safety projects – Where is the difference?

Categories

  • A_Requirement Engineering
  • B_Validation and Verification
  • C_Config- / Change Management
  • D_Security
  • FuSa__General
  • FuSa_Aerospace
  • FuSa_Agriculture
  • FuSa_Automotive
  • FuSa_Industrial
  • FuSa_Railway

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION

Functional Safety Basic Standard IEC 61508IndustrialRequirement EngineeringRequirement completeness using data- and control flow analysis
Scroll to top