Test design strategies are applied according to the type of application under test and the
types of bugs sought. Each strategy has a distinct scope and a distinct set of assumptions and limitations. A test design for a given project will involve a combination of strategies: each strategy has its own advantages and limitations, and each must be applied where appropriate. A well chosen set of strategies will form a
test plan.
| Test Design Strategy |
Description |
|
Data-Flow Testing |
A technique keyed off of a program's variables. Tests are created for selected variables and are applied to the use of the variable in calculations, to the definition of the variable, and to the use of the variable in a predicate (in Boolean expressions, relational operators, and relational expressions). Misuse of global variables is a common source of bugs. Object Oriented Programming is a data-flow paradigm, which is why data-flow graphs are so often part of the OOP development methodology.
|
|
Control-Flow Testing (aka Branch Testing) |
Tests are based on the logical expressions that define decisions in software, where a decision is either a logical predicate a function of logical predicates(aka Conditions). In theory, values that satisfy all combinations of decision conditions should be used as test data inputs, for each decision point in the program. One of the tricks of Control Flow Test Design is to select the proper minimal subset of satisfying values. However, control-flow bugs are not as common as they used to be because structured programming languages minimize them. In modern development environments unit testing should eliminate all control flow bugs.
|
| Boundary Value Testing |
A strategy for limiting the set of possible test data in an effort to increase relative bug yield. Exploiting the known preponderance of bugs at and around range and domain boundary values, value or level comparisons, limits, and so forth, the strategy advocates selecting test data as close to these boundaries above and below. This is probably the most commonly used test design strategy. However, it is possible to apply the strategy in an inneffective way due to some misconceptions about its proper scope.
|
|
Equivalence Class Partitioning |
A strategy aimed at selecting the test data with the highest potential yield of bug exposure. Derived from set theoretic concepts the method relies on an essentially intuitive division of data types into groups all sharing a common property or relation, such that only one characteristic representative need be used for testing, and not the entire set. The explanation of the strategy is often accompanied by some misconceptions.
|
| Cause and Effect Graphing |
Cause-effect graphing is a technique that aids in selecting, in a systematic way, a high-yield set of test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in the specification.
|
|
Transaction-Flow Testing |
Identifies all branches, loops, queues and processes that communicate by messages and defines test cases for these.
|
|
Loop Testing |
Loop bugs tend to be caught by the operating system or the runtime resident portion of the compiler because they will cause memory boundary violations, detectable pointer errors, reading beyond end of file, and stuff like that.
|
|
Logic-based Testing |
Translate specifications that are dominated by logic and combinations of cases into either decision tables or Boolean algebra and develop functional test cases from those representations.
|
|
Domain Testing |
A more sophisticated version of boundary testing. Used for numerical processing with lots of conditional logic: tax forms, payroll processing, financial calculations and spreadsheet applications.
|
|
State Testing |
State-graph tests yield their biggest payoffs during the design of the tests rather than during the running thereof.
|
| Syntax Testing |
Not much required in modern programming environments as it once was but of historical interest nevertheless
|