5. Subdomain Criteria

5. Subdomain Criteria
	Chapter 18. Dynamic Analysis

The standard and most widely used criterion for program-based testing is:

Statement coverage: that every statement in the program must be executed at least once.

There are more burdensome criteria than statement coverage:

Decision coverage: requires that every edge in the control flow graph of the program be executed – roughly that every branch in the program be executed both ways.

Consider applying these criteria to a procedure that returns the minimum of two numbers:

static int minimum (int a, int b) {
   if (a ≤b)
      return a;
   else
      return b;
}

For this code, statement coverage will require inputs with a less than b and vice versa. However, for the code:

static int minimum (int a, int b) {
   int result = b; 
   if (b ≤a)
      result = b;
   return result;
}

a single test case with b less than a will produce statement coverage, and the bug will be missed.

Decision coverage would require a case in which the if-branch is not executed, thus exposing the bug.

Another example of program-based subdomain criterion is the boundary testing: This requires that the boundary cases for every conditional be evaluated.

For example, if your program tests x < n, you would require test cases that produce x = n, x=n-1, and x=n+1.

5.1. Specification-based Subdomains

Specification-based criteria are also usually cast in terms of subdomains.

However, because specifications are usually informal – that is, not written in any precise notation – the criteria tend to be much vaguer.

The most common approach is to define subdomains according to the structure of the specification and the values of the underlying data types. For example:

The subdomains for a method that inserts an element into a set might include:
the set is empty.
the set is non-empty and the element is not in the set.
the set is non-empty and the element is in the set.

Moreover, in practice, testers make use of their knowledge of the kinds of errors that often arise in code. For example:

If you’re testing a procedure that finds an element in an array, you would likely put the element at the start, in the middle and at the end, simply because these are likely to be handled differently in the code.


4. Subdomains		6. Feasibility