Structural Testing Or Whitebox Testing Techniques

Structure-Based or Structural Testing or Whitebox Testing Techniques

Different testing techniques are there, each helpful for a particular defect. Those different testing techniques are again categorized. There are two different categories:

  • Static Techniques
  • Dynamic Techniques

Again, the Dynamic Techniques is divided into three more different categories:

  • Specification-based Testing, Which is also called behavioral techniques or Black Box Testing
  • Structure-based Testing, Also Called Structural Testing techniques Or White Box Testing Technique.

Static Technique Diagram

Static Technique Diagram
Static Technique Diagram

Dynamic Technique Diagram

Dynamic Technique Diagram
Dynamic Technique Diagram

In this post, we are going to discuss structure-based testing. The structure-based testing technique uses the software or application’s internal structure to derive the test cases. This structure-based technique is mainly used for two purposes: test coverage measurement and structural test case design. Structural bae testing is also called the “Glass Box Testing Technique” or “White Box Testing Technique.”

What is White Box Testing?

White box testing is one type of code-based testing because here, the testers responsible for testing the software are to know the internal structure of the software. In this testing, the test cases are calculated after analyzing the internal structure of the system-based code, branch, path, and condition coverage.

That’s why the white box testing mainly covers the following steps:

  • Verifying security loops in the code
  • Verifying the broken paths in the code
  • Verifying the specified flow structure
  • Verifying the desired output
  • Verifying the condition loop to check the functionality
  • Verifying each line and section

Structure-based testing can be applied to different levels of testing:

  • Unit or Component Testing
  • Integration Testing
  • System Testing
  • Acceptance Testing

Due to the structure-based testing technique, we can get to know how much code coverage is happening. We can also measure the percentage of code that has been covered by a test suite at the time of executing the test suite. There is a rule for calculating the code overage, and each test suite needs to be satisfied that that is:

Coverage = (Number of coverage items exercised / Total number of Coverage items) * 100

We Can calculate the number of code coverage by using:

  • Statement
  • Decision (Branch)
  • Path Coverage

Now, let us go through each of the above things and try to understand each one. But before that, let us take a scenario that can easily help us with the above coverage.

Example Scenario:

Read X
Read Y

IF X+Y > 100 THEN
Print “Large”

ENDIF

If X > 50 THEN
Print “X Large”

ENDIF

To better understand the flow of code, we have created a simple flow chart that will help you understand the Statement, Decision (Branch), and Path coverage.

Flor Chart
Flor Chart

From the above diagram

Nodes (|====|,<>) represent statements of code [E.g., entry, exit, decisions]
Edges ( —– ) represent links between nodes

Statement Coverage

Statement coverage is a white box testing technique where all the statements of the source code are executed at least once. To Calculate the statement coverage, we have to find the shortest number of paths that cover all the nodes.

It is a good measure for testing each statement but not a good technique for testing the control flow. Cantata++ is one of the most popular tools for testing code coverage.

From the above flow chart, in the case of “Yes,” all the nodes are covered while traversing through each statement of code and the traversing path (A1-B2-C4-5-D6-E8). So, all the nodes (A, B, C, D, and E) are covered by traveling through only one way.

Statement coverage (SC) =1

Branch/Decision Coverage

Branch coverage covers both (true and false). In this coverage, we try to cover all possible outcomes of each condition, like if-else, for loop, and other conditional loop statements, at least once.

This type of white box testing technique ensures that every possible branch from each decision point in the code is executed at least once. To calculate Branch coverage, find the minimum number of paths that ensure coverage of all the edges. We can use the TCAT path to determine the decision or branch coverage.

In the above example, in case of traversing through a ‘Yes’ decision, path (A1-B2-C4-5-D6-E8), maximum numbers of edges (1, 2, 4, 5, 6, and 8) are covered, but edges 3 and 7 are left out. To cover these edges, we have to follow (A1-B3-5-D7). So by traveling through two paths (Yes, No), all the edges (1, 2, 3, 4, 5, 6, 7, 8) are covered.

Branch Coverage /Decision Coverage (BC) = 2

Path Coverage

In this coverage technique, we should execute every statement in the program, guaranteeing that the statements are executed at least once. This coverage technique ensures that all the paths are covered from beginning to end. In the above flow chart, the possible paths are:

A1-B3-5-D7
A1-B2-C4-5-D6-E8
A1-B2-C4-5-D7
A1-B3-5-D6-E8
Path coverage (PC) = 4

Condition Coverage

This is much related to the decision coverage, but it has better sensitivity to the control flow. In condition coverage, it reports the outcomes of both true and false conditions. Let us take an example to understand the condition coverage:

IF (“X && Y”)

To find the condition coverage, the following tests will be sufficient:

TEST 1: X=TRUE, Y=FALSE
TEST 2: X=FALSE, Y=TRUE

Final Words:

Structural testing is more concerned with how the system works rather than the functionality of the software or application. Structural Testing provides more coverage to the testing. Structural testing helps perform thorough testing on software.

I love open-source technologies and am very passionate about software development. I like to share my knowledge with others, especially on technology that's why I have given all the examples as simple as possible to understand for beginners. All the code posted on my blog is developed, compiled, and tested in my development environment. If you find any mistakes or bugs, Please drop an email to softwaretestingo.com@gmail.com, or You can join me on Linkedin.

Leave a Comment