White box testing

White Box Testing

White Box Test
Concept: White box tests (also known as glass box tests or structural tests) focus on the procedural details of the software, so its design is strongly tied to the source code

The white box test is based on the design of test cases that uses the control structure of the procedural design to derive them. Through the white box test the software engineer can obtain test cases that:

  1. Ensure that all independent paths of each module, program, or method are exercised at least once.
  2. Exercise all the logical decisions on the true and false sides.
  3. Execute all loops at their operational limits.
  4. Exercise internal data structures to ensure validity.

That is why the White Box test is considered as one of the most important types of tests that are applied to software, achieving as a result that the number of errors in the systems decreases by a large percentage and therefore a higher quality and reliability.

Summary

[ hide ]

  • 1 Basic path
  • 2 Flow Graph Notation
    • 1 Node
    • 2 Edges
    • 3 Regions
  • 3 Cyclomatic Complexity
  • 4 Derivation of test cases
  • 5 References
  • 6 Sources

Basic path

The basic path test is a White Box testing technique proposed by Tom McCabe .

This technique allows obtaining a measure of the logical complexity of a design and using this measure as a guide for the definition of a basic set.

The idea is to derive test cases from a given set of independent paths through which the control flow can circulate. To obtain this set of independent paths, the associated Flow Graph is constructed and its cyclomatic complexity is calculated. The steps that are followed to apply this technique are:

  1. From the design or source code, the associated flow graph is drawn.
  2. The cyclomatic complexity of the graph is calculated.
  3. A basic set of independent paths is determined.
  4. The test cases that require the execution of each path of the basic set are prepared.

Test cases derived from the core set ensure that each statement in the program is executed at least once during testing.

Flow Graph Notation

To apply the basic path technique, a simple notation for the representation of the control flow must be introduced, which can be represented by a Flow Graph. Each node in the graph corresponds to one or more source code statements. Every segment of code in any program can be translated into a Flow Graph. To construct the graph, the notation for the instructions must be taken into account. A Flow Graph is made up of 3 fundamental components that help to prepare it, understand it, and provide us with information to confirm that the work is being done properly.

The components are:

Node

Each circle represented is called a node of the Flow Graph, which represents one or more procedural sequences. A single node can correspond to a sequence of processes or a decision statement. It may also be that they find nodes that are not associated, they are used mainly at the beginning and end of the graph.

Edges

The arrows in the graph are called edges and represent the control flow, they are analogous to those represented in a flow diagram. An edge must end at a node, even if the node does not represent any procedural statements.

Regions

Regions are the areas delimited by edges and nodes. The outer area of ​​the graph is also included, counting as one more region. The regions are listed. The number of regions is equivalent to the number of independent paths of the basic set of a program.

Any representation of the procedural design can be translated into a flow graph. When compound conditions are found in a design (one or more logical AND, NAND, NOR operators in a conditional statement), the generation of the flow graph becomes a bit more complicated.

Cyclomatic Complexity

Cyclomatic complexity is an extremely useful software metric as it provides a quantitative measure of the logical complexity of a program. The value calculated as cyclomatic complexity defines the number of independent paths in the basic set of a program and gives us an upper limit for the number of tests that must be performed to ensure that each statement is executed at least once. An independent path is any path in the program that introduces at least one new set of processing statements or one new condition. The independent path must be moved on at least one edge that has not been previously traveled. [1]

Derivation of test cases

After having prepared the Flow Graphs and the paths to be traveled, the test cases that will force the execution of each of these paths are prepared. The data is chosen so that the conditions of the predicate nodes are properly established, in order to check each path.

Test cases for each path.

Way 1: 1-2-3-5-6. Choose some X and Y such that it satisfies X> = 0 AND Y> = 0. X = 10 AND Y = 20. Path 2: 1-2-4-6. Choose some X such that X <0 holds. X = -15.

After preparing the test cases, each of these are executed and the results are compared with those expected. Once all the test cases have been completed, you will be sure that all the statements in the program have been executed at least once. It is important to note that some paths cannot be tested in isolation. In other words, the combination of data required to travel the path cannot be obtained with the normal flow of the program. In such cases, these roads are tested as part of another road test

 

Leave a Comment