SPONSORS:






View RSS Feed

thomasdfg

How to Perform White Box Testing – Explained with a Simple Example

Rate this Entry
by , 05-16-2016 at 04:25 AM (101 Views)
In my career so far, I have seen the testers to be the most enthusiastic community in the software industry. The reason being, that testers always have something in their scope to learn. Be it domain, process or technology, a tester can have a holistic development if they wish to. But as they say “There is always a dark side”. Testers also avoid one type of testing which they feel is very complicated and developer’s piece of cake. Yes, you have guessed it right. It’s the “WHITE BOX TESTING”.

White box and black box testing:

If we go by definition, “White box testing” (also known as clear, glass box or structural testing) is a testing technique which evaluates the code and internal structure of the program.

It’s the counterpart of Black box testing.

In simple words – In Black box testing, we test the software from a user’s point of view, but in White box, we see and test the actual code. In Black box, we do testing without seeing the internal system code, but in White box we do see and test the internal code.

White box testing technique is used by both developers as well as testers. It helps them understand which line of code is actually executed and which is not. This may indicate that there is either missing logic or a typo, which eventually can lead into some negative consequences.

Steps to perform White box testing:

Step #1 – Understand the functionality of the application through its source code. Having said that, it simply means that the tester must be well versed with the programming language and other tools and techniques used to develop the software.

Step #2 – Create the tests and execute them.

When we discuss about testing, “coverage” is the most important factor. Here I will explain how to have maximum coverage in the context of White box testing.
The three main White box testing Techniques are:

Statement Coverage
Branch Coverage
Path Coverage

Let’s understand these techniques one by one with a simple example.

#1 Statement coverage

In programming language, statement is nothing but the line of code or instruction for the computer to understand and act accordingly. A statement becomes an executable statement when it gets compiled and converted into the object code and performs the action when the program is in running mode.

Hence “Statement Coverage”, as the name suggests, is the method of validating that each and every line of code is executed at least once.

#2 Branch Coverage

“Branch” in programming language is like the “IF statements”. If statement has two branches: true and false.

So in Branch coverage (also called Decision coverage), we validate that each branch is executed at least once.

In case of a “IF statement”, there will be two test conditions:

One to validate the true branch and
Other to validate the false branch

Hence in theory, Branch Coverage is a testing method which when executed ensures that each branch from each decision point is executed.

#3 Path Coverage

Path coverage tests all the paths of the program. This is a comprehensive technique which ensures that all the paths of the program are traversed at least once. Path Coverage is even more powerful that Branch coverage. This technique is useful for testing the complex programs.

Let’s take a simple example to understand all these white box testing techniques.
White box testing example
Consider below simple pseudo code:

1 INPUT A & B
2 C = A + B
3 IF C>100
4 PRINT “IT’S DONE”

For Statement Coverage – we would need only one test case to check all the lines of code.
That means: If I consider TestCase_01 to be (A=40 and B=70), then all the lines of code will be executed Now the question arises:

Is that sufficient?
What if I consider my Test case as A=33 and B=45?

Because Statement coverage will only cover the true side, for the pseudo code, only one test case would NOT be sufficient to test it. As a tester, we have to consider the negative cases as well.

Hence for maximum coverage, we need to consider “Branch Coverage”, which will evaluate the “FALSE” conditions.

In real world, you may add appropriate statements when condition fails.

So now the pseudo code becomes:
1 INPUT A & B
2 C = A + B
3 IF C>100
4 PRINT “IT’S DONE”
5 ELSE
6 PRINT “IT’S PENDING”

Since Statement coverage is not sufficient to test the entire pseudo code, we would require Branch coverage to ensure maximum coverage.

So for Branch coverage, we would require two test cases to complete testing of this pseudo code.

TestCase_01: A=33, B=45

TestCase_02: A=25, B=30

With this, we can see that each and every line of code is executed at least once.

Here are the conclusions so far:

Branch Coverage ensures more coverage than Statement coverage
Branch coverage is more powerful than Statement coverage,
100% Branch coverage itself means 100% statement coverage,
100 % statement coverage does not guarantee 100% branch coverage

Now let’s move on to the Path Coverage:

As said earlier, Path coverage is used to test the complex code snippets, which basically involves loop statements or combination of loops and decision statements.

Now to ensure maximum coverage, we would require 4 test cases. How?

Simply – there are 2 decision statements, so for each decision statement we would need to branches to test. One for true and other for false condition. So for 2 decision statements, we would require 2 test cases to test the true side and 2 test cases to test the false side, which makes total of 4 test cases.

Conclusion

Note that the statement, branch or path coverage does not identify any bug or defect that needs to be fixed. It only identifies those lines of code which are either never executed or remains untouched. Based on this further testing can be focused on.

Relying only on black box testing is not sufficient for maximum test coverage. We need to have combination of both black box and white box testing techniques to cover maximum defects.

If done properly, White box testing will certainly contribute to the software quality. It’s also good for testers to participate in this testing as it can provide the most “unbiased” opinion about the code.

Comments


vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 06:02 PM.

Copyright BetaSoft Inc.