What are test techniques

Course: Software Test / Test Techniques


A possible division (another into black box, white box, gray box: see here) of the test techniques would be: static and dynamic techniques.
With static techniques, the software is also tested (just like with dynamic techniques), but the software is tested in the process Not executed. The aim of both variants is, among other things, to find anomalies (you can read more goals for testing here). You could also put it another way: with the dynamic test techniques the software can interact / react, while with the static techniques the software just lies dead in front of us like a skeleton and we dissect it like a pathologist - uh ... - examine it can.
You can find examples of some techniques in: Standard for Software Component Testing by BCS SIGIST.

static test techniques

manual application [edit]

The following test techniques focus primarily on people's ability to analyze and think. Different types of reviews are used for this purpose:

automated application [edit]

For the static analysis tools, the test object should have a formal structure / syntax (the test object can therefore also be something other than the source text). Then the tools look for specific ones inspect. Possible tools are:
Compiler: check e.g. the syntax of the respective programming language or calculate metrics
Analyzers: this can, for example, be "just" a spell checker
Modeling tools: these first create, for example, a model from the specification or from the source code so that the other tools can be used
and other open source or commercial tools (see discussion)

dynamic test techniques

In contrast to the static techniques, the test object is now brought to execution.

systematic test techniques

You can find an overview of black box, white box and gray box in this article.

Black box [edit]

White box [edit]

The white box techniques can be grouped into data flow based and control flow based.

  1. control flow based (Here is an explanation of the sense and use of control flow graphs and CSDs!)
    1. Statement coverage test(statement coverage test)
    2. Branch coverage testbranch coverage test
    3. Condition / decision coverage test (decision condition coverage)
    4. simple condition coverage test(simple condition coverage test)
    5. minimal multiple condition coverage test(modified condition decision coverage or minimal multicondition coverage test)
    6. Multiple constraint coverage test(multiple condition coverage test)
    7. Path coverage test(path coverage test)
  2. data flow based
Data flow-based techniques build on control flow-based test techniques and expand them further.
Data is stored in variables. These variables have a defined life cycle:
undefined / undeclared (u): Variable has neither a value nor a memory location
declared (d): Variable has no defined value, but memory has already been allocated.
initialized (i): Assignment of a value to a variable,
referenced (r): Reading / using the variable value,
Then there can be many data flow anomalies: e.g. dr, id, ii.
This should be illustrated using a modified part of the source code from the BubbleSort algorithm:
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 assume that the source code now contains errors (lines 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 has not yet been defined, *) (* is used *) 14c. a [i + 1]: = a [i]; (* ii-anomaly: there are now two a [i + 1] assignments (line 14b + 14c), *) (* which should make you puzzled. *) 15. INC (swaps); 16. END

Gray box [edit]

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

Dynamic analysis tools

  • GUI capture and playback: Record the actions on the screen in a test script. This type of tool has disadvantages such as considerable effort when reusing the test script.
  • data driven: The advantage here is that the same recorded test (= test script) can be repeated with different input data, which the user can easily add via e.g. Excel.
  • keyword-driven / actionword-driven: Difference to data-driven: each line of the input data now also contains a keyword, which specifies what to do with the data. Think of it as a function that says what to do with the test data.
  • interaction-driven: If something has been changed in the test scripts themselves, the maintenance effort is reduced, since changes are carried over to all other test scripts that use this changed test script. Here you can simply drag and drop the text modules / test scripts from the database.
  • Comparators / comparison tools
  • dynamic analysis tools
  • Coverage analyzers
  • Test frame
  • Debugger
  • and other

non-systematic test techniques