0% found this document useful (0 votes)

6 views24 pages

BTCEmbedded Platform

The document outlines the process of creating a profile within the BTC Embedded Platform and details various coverage metrics such as Statement Coverage, Condition/Decision Coverage (C/DC), and Modified Condition/Decision Coverage (MC/DC). It emphasizes the necessity for each decision and condition to be evaluated at least once, including all outcomes for decisions and conditions, as well as the requirement for function entries and exits to be invoked. Additionally, it notes that BTC Embedded Platform reports MC/DC statistics that align with C/DC values.

Uploaded by

Cristian Daniel Gyorfi

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

6 views24 pages

BTCEmbedded Platform

Uploaded by

Cristian Daniel Gyorfi

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 24

BTC Embedded Platform

Create Profile - Step 1

Create Profile - Step 2
Create Profile - Step 3
Create Profile - Step 4
Create Profile - Step 5
Statement Coverage [from BTC Embedded Platform Concepts and Use Cases]

Each C-statement needs

to be executed / traversed at least once.
Expressions and Conditions [from BTC Embedded Platform Concepts and Use
Cases]

Atomic Boolean expressions

are built using relational operators such as <, >, ==

Conditions in BTC Embedded Platform

=> atomic Boolean expressions and negations of these expressions
=> conditions can not contain other conditions

Decisions
are build on conditions:decisions consist of one or more conditions
=> x < 7 && a == b
=> x ^ y || !(x == 7 && a+7 == 25)
Condition / Decision Coverage

In Wikipedia, Condition / Decision coverage is characterised as follows:

"Every point of entry and exit in the program has been invoked at least
once, every condition in a decision in the program has taken all possible
outcomes at least once, and every decision in the program has taken all
possible outcomes at least once."
Condition / Decision Coverage [from BTC Embedded Platform Concepts and
Use Cases]

In BTC EmbeddedPlatform, Condition / Decision Coverage (C/DC) is defined as

follows:
• Every decision has taken all possible outcomes (true, false) at least once.
• Every condition appearing in a decision has taken all possible outcomes (true,
false) at least once.

• For Switch-Case Statements, all cases need to be visited at least once, including
the Default-case

• Each function entry shall be seen at least once. Note that all function callers are
not needed to be explicitly mentioned, as these are implicitly covered by the
other demands above. The same applies for function exits.
C/DC Coverage [from BTC Embedded Platform Concepts and Use Cases]

x>y&&z==c
=> terminates after traversing x > y if x is less or equal y, as the outcome of
the entire conjunction is obviously false. In this example, condition z == c is not
evaluated at all.

=> condition "z == c" can only be covered in states where x is greater than y

=> a condition is traversed only if the outcome of its decision is not yet
determined, the condition’s evaluation can independently affect the decision’s
outcome
Condition / Decision Coverage [from BTC Embedded Platform Concepts and
Use Cases]

In BTC EmbeddedPlatform, Condition / Decision Coverage (C/DC) is defined as

follows.
• Every decision has taken all possible outcomes (true, false) at least once.
• Every condition appearing in a decision has taken all possible outcomes (true,
false) at least once.
• For Switch-Case.Statements, all cases need to be visited at least once, including
the Default-case
• Each function entry shall be seen at least once. Note that all function callers are
not needed to be explicitly
mentioned, as these are implicitly covered by the other demands above. The same
applies for function exits.
• Conditions in a decision can only be covered if the decision’s outcome is not yet
determined from the short-circuit left-to-right calculation.
• From the short-circuit evaluation setting, a condition can independently affect the
decision’s outcome if the left-to-right calculation reaches that condition.
MC/DC Coverage [from BTC Embedded Platform Concepts and Use Cases]

was originally defined for non-short-circuit evaluation languages such as

ADA