Software testing/Design technique

One possible classification (another one could be black box, white box, grey box: see here) of the design techniques could be: static and dynamic techniques.
The static techniques also test software (like the dynamic ones), but the software is not executed during this. Goal of both types it is amongst others to find anomalies (more goals you can read here). We could also phrase it like this: software interacts/reacts while dynamic testing - but for the static techniques software just lies like a skeleton before us and we can dissect it like a pathologist.
Examples to some of the techniques you can find in: Standard for Software Component Testing from BCS SIGIST.

static design techniques

manual

For the following design techniques the ability of humans to analyze and think is of primary importance. For this there are used different kind of reviews:

• informal review
• walkthrough
• technical review
• inspection
• management review
• audit

with tools

Tools for static analysis need the test object to have a formal structure/syntax (so a test object can also be something else than source code). Then the tools search for certain patterns. Tools can be:

Compiler: they check if e.g. for the syntax of the used programming language or they calculate metrics
analyzer: e.g. this can be also "just" a program for spell checking
tools for modeling: they create first a model of e.g. the specification or the source code - so other tools can start
also other open source and commercial tools (please see discussion)

dynamic design techniques

In complement to static techniques the testobject is being executed for testing.

systematic techniques

An overview about black box, white box and grey box you can find in the article here.

black box

• equivalence partitioning
  
• classification tree method
  
• boundary value analysis
  
• domain analysis testing
  
• decision table testing
  
• state transition test
  
• uses case test
  
• process cycle test
  
• pairwise testing (orthogonal arrays, Allpairs algorithm)
  
• data cycle test
  
• elementary comparison test
  
• semantic test
  
• syntax test
  
• random test
  
• smoke test
  

white box

white box design techniques can be grouped into control flow based or data flow based.

control flow based

• statement coverage
• branch coverage
• decision condition coverage
• simple condition coverage
• modified condition decision coverage or minimal multicondition coverage
• multiple condition coverage
• path coverage

(todo: explaining advantages of control flow graphs and CSD)

data flow based
Data flow based techniques build on and extend control flow based techniques. Data is saved in variables and these variables have a defined lifecycle:

undeclared/undefined (u): variable has no value and no memory

declared (d): variable has no defined value, but there is already memory assigned

initialized (i): assign a value to the variable

referrenced (r): use/read of the value of the variable

Then there can be many dataflow anomalies: e.g. dr, id, ii. This shall be explained with one part of the source code of the algorithm BubbleSort:

 4.         temp, swaps : INTEGER;
..
13.                 IF ~(a[i] <= a[i 1]) THEN
14a.                     temp   := a[i];
14b.                     a[i]   := a[i 1]; 
14c.                     a[i 1] := temp;
15.                      INC(swaps);
16.                 END

Let's say the source code has now anomalies (line 14a - 14c):

 4.         temp, swaps : INTEGER;
..
13.                 IF ~(a[i] <= a[i 1]) THEN
14a.                                     (* line 14a is now deleted                                    *) 
14b.                     a[i 1] := temp; (* dr-anomaly: variable temp from line 4 was not yet defined, *)
                                         (*             but it is used.                                *)
14c.                     a[i 1] := a[i]; (* ii-anomaly: there are now two a[i 1] (line 14b   14c)      *)
                                         (*             this should make you wonder.                   *)
15.                      INC(swaps);
16.                 END

grey box

Here the advantages of black box and white box techniques are combined to design better tests.
(TODO: examples)

tools for dynamic analysis

• test execution tools

• GUI-capture and playback: Actions on the screen are recorded in a test script. These type of tools have disadvantages like more effort when reusing due to editing of the script.
• data driven: The advantage here is: the same recorded test (which is saved in a test script - like above) can be repeated with different input data (which the user adds e.g. over Excel).
• keyword-driven/actionword-driven: difference to data-driven: each line of input data has now its own keyword, which tells what to do with the input-data. Imagine it like this: the keyword is something like a function, which tells what to do.
• interaction-driven: If something has changed on the testscripts itself, the maintenance effort decreases, because other testscripts, which work with this test script get changed automatically. The scripts/modules can be taken by drag and drop from the database.

• comparator/comparison tools
• dynamic analysis tools
• coverage tools
• test frameworks
• debugger
• and other

non-systematic techniques

• ad-hoc/explorative testing
• intuitive
• weak point testing
• testing based on a defect taxonomy