# Elementary comparison testing

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Elementary_comparison_testing
> Markdown URL: https://mediated.wiki/source/Elementary_comparison_testing.md
> Source: https://en.wikipedia.org/wiki/Elementary_comparison_testing
> Source revision: 1306187737
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

**Elementary comparison testing** (**ECT**) is a [white-box](/source/White-box_testing), [control-flow](/source/Control_flow), [test-design](/source/Test_design) methodology used in [software development](/source/Software_development).[1][2] The purpose of ECT is to enable detailed testing of complex software. Software code or [pseudocode](/source/Pseudocode) is tested to assess the proper handling of all decision outcomes. As with [multiple-condition coverage](/source/Code_coverage)[3] and [basis path testing](/source/Basis_path_testing),[1] coverage of all independent and isolated conditions is accomplished through [modified condition/decision coverage (MC/DC)](/source/Modified_condition/decision_coverage).[4] Isolated conditions are aggregated into connected situations creating formal [test cases](/source/Test_case_(software)). 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](/source/Test_case_(software)) 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](/source/Modified_condition/decision_coverage) approach isolates every condition, neglecting all possible subpath combinations and path coverage.[1]

T=n+1

where

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

The decision d_i consists of a combination of elementary conditions

\begin{align}
\Sigma &= \{0, 1\}\\
C&=\{c_0, c_1, c_2, c_3,..., c_n\}
\end{align}

\epsilon : C \to \Sigma \times C

D \subseteq C^* \,;\; d_i \in D

The transition function \alpha is defined as

\alpha : D \times \Sigma^* \to \Sigma \times D

Given the transition \vdash

\vdash \subseteq (\Sigma \times D \times \Sigma^*) \times (\Sigma \times D \times \Sigma^*)

S_j=(b_j, d_m, v_j) \vdash (b_{j+1}, d_n, v_{j+1})

E_j=(a_j, c_j) \vdash (a_{j+1}, c_k)

(b_{j+1}, d_n) = \alpha(d_m, v_j); (b_{j+1}, c_k) = \epsilon(c_j); a_j \in \Sigma,

the isolated test path P_m consists of

\begin{align}
P_m &= (b_0, d_0, v_0) \vdash ... \vdash (b_i, d_i, v_i) \vdash^*(b_n, d_n, v_n) \\
    &= (b_0, c_0) \vdash ... \vdash (b_m, c_m) \vdash^* (b_n, c_n)
\end{align}

b_i \in \Sigma; c_m \in d_i; v \in C^*; d_0=S; d_n=E.

## 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 r = 2^n possible condition value combinations

\forall{i} \in \{1,...,n\},\ c_i\mapsto\{0,\ 1\}.

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

T = \log_2(r)+1 = n + 1.

\forall{i}\in\{1,...,n\} there are 0<e<i+1 edges from parent nodes c_i and s = 2 edges to child nodes from c_i.

Each individual condition c_i connects to at least one path

\forall{i}\in\{1,...,n-1\} , \ c_i\mapsto\{0,\ 1\}

from the maximal possible n connecting to c_n isolating c_n.

All predecessor conditions c_i;\ i<n 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:

T = n-1+2 = n+1.

[Q.E.D.](/source/Q.E.D.)

## Test-case design steps

1. Identify decisions
1. Determine test situations per decision point ([Modified Condition / Decision Coverage](/source/Modified_condition/decision_coverage))
1. Create logical test-case matrix
1. 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 -20\% for members or for expensive vacations, -10\% for moderate vacations with workday departures, and 0\% 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: <8;\ 8-15;\ >15
- Price (euros): <500;\ 500-1000;\ >1000
- Membership card: none; silver; gold; platinum
- Departure date: workday; weekend; holiday

T = 3 \times 3 \times 4 \times 3 = 108 possible combinations (test cases).

Example in [Python](/source/Python_(programming_language)):

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

Table 1: Example D1 MC/DC Outcome Decision D1 1 0 Conditions c1 c2 c3 c1 c2 c3 c1 \text{days}>15 1 0 0 0 0 0 c2 \text{price}>1000 0 1 0 0 0 0 c3 \text{member} 0 0 1 0 0 0

\begin{align}
d_1 &= \text{days} > 15\ \text{or}\ \text{price} > 1000\ \text{Eur}\ \text{or}\ \text{member} \\
c_1 &= \text{days} > 15 \\
c_2 &= \text{price} > 1000 \\
c_3 &= \text{member} \\
\end{align}

\begin{align}
d_2 &= (8 < \text{days} < 15\ \text{or}\ 500 < \text{price} < 1000\ \text{Eur})\ \text{and}\ \text{workday} \\
c_4 &= 8 < \text{days} < 15 \\
c_5 &= 500 < \text{price} < 1000\ \text{Eur}\\
c_6 &= \text{workday} \\
\end{align}

### Step 2: MC/DC Matrix

Table 2: Example D2 MC/DC Outcome Decision D2 1 0 Conditions c4 c5 c6 c4 c5 c6 c4 8<\text{days}<15 1 0 1 0 0 1 c5 500 < \text{price} < 1000 0 1 1 0 0 1 c6 \text{workday} 1 0 1 1 0 0

The highlighted diagonals in the [MC/DC](/source/Modified_condition/decision_coverage) Matrix are describing the isolated conditions:

(c_i,c_i) \mapsto \{1,0\}

all duplicate situations are regarded as proven and removed.

### Step 3: Logical test-Case matrix

Table 3: Example Logical Test Case Matrix Situation S_{j} T_1 T_2 T_3 T_4 T_5 T_6 T_7 \alpha(d_1, \mathbf{1}00) \mapsto (1, E) x \alpha(d_1, \mathbf{0}00) \mapsto (0, d_2) x x x x \alpha(d_1, 0\mathbf{1}0) \mapsto (1, E) x \alpha(d_1, 00\mathbf{1}) \mapsto (1, E) x \alpha(d_2, \mathbf{1}01) \mapsto (1, E) x \alpha(d_2, \mathbf{0}01) \mapsto (1, E) x \alpha(d_2, 0\mathbf{1}1) \mapsto (1, E) x \alpha(d_2, 11\mathbf{0}) \mapsto (0, E) x

Test cases are formed by tracing decision paths. For every decision d_i;\ 0 < i < n+1 a succeeding and preceding subpath is searched until every connected path has a start S and an end E:

\begin{align}
T_1&=(d_1, 100) \vdash (1, E) \\
T_2&=(d_1, 000) \vdash (0, d_2, 100) \vdash (1, E) \\
T_3&=(d_1, 010) \vdash (1, E) \\
\vdots \\
T_{n+1}
\end{align}

### Step 4: Physical test-case matrix

Table 4: Example Physical Test Cases Factor\Test Case T_1 T_2 T_3 T_4 T_5 T_6 T_7 days 16 14 8 8 8 price 1100 600 departure sa member silver Result 0 0 -10 1 1 1 -20 1 1 1

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

- [Code coverage#Multiple condition coverage](/source/Code_coverage#Multiple_condition_coverage)
- [Control-flow graph](/source/Control-flow_graph)
- [Decision-to-decision path](/source/Decision-to-decision_path)

## References

1. Lee Copeland (2004). *A Practitioners Guide to Software Test Design*, chapter 10. Artech House Publishers, Norwood. ISBN 0140289712.

1. ["All about the elementary comparison test | Testlearning"](https://www.testlearning.net/en/posts/elementary-comparison-test). *www.testlearning.net*. Retrieved 2022-09-02.

1. Glenford J. Myers (2004). *The Art of Software Testing, Second Edition*, p. 40., John Wiley & Sons, New Jersey. ISBN 0-471-46912-2.

1. Tim Kroom (2006). *TMap Next, for result driven testing*, p. 668. UTN Publishers, Rotterdam. ASIN B01K3PXI5U.

---
Adapted from the Wikipedia article [Elementary comparison testing](https://en.wikipedia.org/wiki/Elementary_comparison_testing) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Elementary_comparison_testing?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.