Elementary comparison testing. Elementary comparison testing (ECT) is a white-box, control-flow, test-design methodology used in software development. The purpose of ECT is to enable detailed testing of complex software. Software code or pseudocode is tested to assess the proper handling of all decision outcomes. As with multiple-condition coverage and basis path testing, coverage of all independent and isolated conditions is accomplished through modified condition/decision coverage (MC/DC). Isolated conditions are aggregated into connected situations creating formal test cases. The independence of a condition is shown by changing the condition value in isolation. Each relevant condition value is covered by test cases.

Test case
A test case consists of a logical path through one or many decisions from start to end of a process. Contradictory situations are deduced from the test case matrix and excluded. The MC/DC approach isolates every condition, neglecting all possible subpath combinations and path coverage.

where
 T is the number of test cases per decision and
 n the number of conditions.

The decision  consists of a combination of elementary conditions

The transition function  is defined as

Given the transition 

the isolated test path  consists of

Test case graph
A test case graph illustrates all the necessary independent paths (test cases) to cover all isolated conditions. Conditions are represented by nodes, and condition values (situations) by edges. An edge addresses all program situations. Each situation is connected to one preceding and successive condition. Test cases might overlap due to isolated conditions.

Inductive proof of a number of condition paths
The elementary comparison testing method can be used to determine the number of condition paths by inductive proof.

There are  possible condition value combinations

When each condition  is isolated, the number of required test cases  per decision is:

 there are  edges from parent nodes  and  edges to child nodes from .

Each individual condition  connects to at least one path

from the maximal possible  connecting to  isolating .

All predecessor conditions  and respective paths are isolated. Therefore, when one node (condition) is added, the total number of paths, and required test cases, from start to finish increases by:

Q.E.D.

Test-case design steps
 Identify decisions
 Determine test situations per decision point (Modified Condition / Decision Coverage)
 Create logical test-case matrix
 Create physical test-case matrix

Example

This example shows ETC applied to a holiday booking system. The discount system offers reduced-price vacations. The offered discounts are  for members or for expensive vacations,  for moderate vacations with workday departures, and  otherwise. The example shows the creation of logical and physical test cases for all isolated conditions.

Pseudocode

 if days > 15 or price > 1000 or member then
     return −0.2
 else if (days > 8 and days ≤ 15 or price ≥ 500 and price ≤ 1000) and workday then
     return −0.1
 else
     return 0.0

Factors

 Number of days: 
 Price (euros): 
 Membership card: none; silver; gold; platinum
 Departure date: workday; weekend; holiday

 possible combinations (test cases).

Example in Python:
if days > 15 or price > 1000 or member:
    return -0.2
elif (days > 8 and days <= 15 or price >= 500 and price <= 1000) and workday:
    return -0.1
else:
    return 0.0

Step 1: Decisions

Step 2: MC/DC Matrix

The highlighted diagonals in the MC/DC Matrix are describing the isolated conditions:

all duplicate situations are regarded as proven and removed.

Step 3: Logical test-Case matrix

Test cases are formed by tracing decision paths. For every decision  a succeeding and preceding subpath is searched until every connected path has a start  and an end :

Step 4: Physical test-case matrix

Physical test cases are created from logical test cases by filling in actual value representations and their respective results.

Test-case graph

In the example test case graph, all test cases and their isolated conditions are marked by colors, and the remaining paths are implicitly passed.

See also
 
 Control-flow graph
 Decision-to-decision path

References

Articles with example pseudocode
Articles with example Python (programming language) code
Software testing