White Box Testing

Front 1

White box methods

Back 1

Base their tests on the softwareʼs actual architecture or code itself

Front 2

Code Coverage

Back 2

Design tests to execute every method, statement or instruction of the program
at least once

Front 3

Logic Path / Decision Point Coverage

Back 3

Design tests to cover every path of execution in the program at least once

Front 4

Mutation Testing

Back 4

Involves creating many slightly different versions of the code by mutating (changing operations) in each version. Used to check sufficiency of test suites in detecting faults

Front 5

Code Injection

Back 5

Refers to modifications of the
source or executable code being tested in order to make tests
more effective (possible because white box)

Front 6

Instrumentation Injection

Back 6

Adding code to instrument the actions of the program
at every method, statement or instruction during testing,
to keep track of properties such as execution coverage

Front 7

Performance Instrumentation

Back 7

Involves adding code to log the actual time or space used by each method or statement of the program during execution

Front 8

Assertion Injection

Back 8

Adding strict run-time assertion code to every method, statement or instruction in the program during testing,
to help localize the cause of failures

Front 9

Fault Injection

Back 9

Adding code to simulate run-time faults, to test fault handling

Front 10

Three Levels of White Box Implementation

Back 10

1) source level
2) executable code level
3) execution sampling level

Front 11

Source Level Implementation

Back 11

Create a copy of the program with new statements inserted to log coverage (Code Injection by Source Modification)

Front 12

Executable Code Level Implementation

Back 12

Create a copy of the program code with instructions inserted to log coverage. In order not to change addresses, modify code to execute new instructions out of line (Code Injection by Executable Code Modification)

Front 13

Sampling Level Implementation

Back 13

Use a timer or other frequent regular interrupt to randomly sample where we are executing. Interrupt return address tells us where we are executing when each interrupt happens (Do not change the executable code at all)

Front 14

Advantages of path coverage

Back 14

- Covers all basic blocks (like block testing)
- Covers all conditions (does all of decision/condition testing)
- Requires fewer tests!
- Automatable

Front 15

Disadvantages of path coverage

Back 15

Does not take data complexity into account

Front 16

Mutation testing

Back 16

White box method for checking the adequacy of a test suite. For each mutant, we run the test suite on the mutant and
compare the results to the saved results from the original. If the results differ, then the mutant has been “killed” (detected) by the test suite. If the results do not differ, then the test suite is inadequate to
detect the mutant, and a new test must be added to the suite
to “kill” that mutant