White Box Testing: Classification of Whit e Box.

1. This is also known as glass box, clear box, and open box testing.

2. In white box testing, test cases are created by looking at the code to detect any Potential failure scenarios.

3. The suitable input data for testing various APIs and the special code paths that Need to be tested by analyzing the source code for the application block.

4. Therefore, the test plans need to be updated before starting white box testing and only after a stable build of the code is available.

5. White box testing assumes that the tester can take a look at the code for the application block and create test cases that look for any potential failure scenarios.

6. During white box testing, analyze the code of the application block and prepare test cases for testing the functionality to ensure that the class is behaving in accordance with the specifications and testing for robustness.

7. A failure of a white box test may result in a change that requires all black box testing to be repeated and white box testing paths to be reviewed and possibly changed.

i. Static Testing- Inspections, Structured Walkthroughs, Technical Review:

1. Inspection

i. Inspections are the most formal type of reviews.

ii. They are highly structured and require training for each participant.

iii. Inspections are different from peer reviews and walkthroughs in that the person who presents the code, the presenter or reader, isn’t the original programmer.

iv. These forces someone else to learn and understand the material being presented, potentially giving a different slant and interpretation at the inspection meeting.

v. The other participants are called inspectors.

vi. Each is tasked with reviewing the code from a different perspective, such as a User, a tester, or a product support person.

vii. This helps bring different views of the product under review and very often Identifies different bugs.

viii. One inspector is even tasked with reviewing the code backward—that is, from the end to the beginning—to make sure that the material is covered evenly And completely.

2. Walkthrough:

i. Walkthroughs are the next step up in formality from peer reviews.

ii. In a walkthrough, the programmer who wrote the code formally presents (Walks through) it to a small group of five or so other programmers and testers.

iii. The reviewers should receive copies of the software in advance of the review so they can examine it and write comments and questions that they want to ask at the review.

iv. Having at least one senior programmer as a reviewer is very important.

3. Technical Review:

i. Formal Review:

• A formal review is the process under which static white-box testing is performed.

• A formal review can range from a simple meeting between two programmers to a detailed, rigorous inspection of the code.

There are four essential elements to a formal review

1. Identify Problems:

2. Follow Rules:

3. Prepare: -

4. Write a Report: -

ii. Peer Reviews:

• The easiest way to get team members together and doing their first formal reviews of the software is through peer reviews, the least formal method.

• Sometimes called buddy reviews, this method is really more of a discussion.

• Peer reviews are often held with just the programmer who wrote the code and one or two other programmers or testers acting as reviewers.

• Small group simply reviews the code together and looks for problems and oversights.

• To assure that the review is highly effective all the participants need to make sure that the four key elements of a formal review are in place: Look for problems, follow rules, prepare for the review, and write a report.

• As peer reviews are informal, these elements are often scaled back. Still, just getting together to discuss the code can find bugs.

ii. Structural Testing-Code Functional Testing, Code Coverage Testing, Code Complexity Testing.

1. Data Flow (Code Functional Testing)

i. Data flow coverage involves tracking a piece of data completely through the software.

ii. At the unit test level this would just be through an individual module or function.

iii. The same tracking could be done through several integrated modules or even through the entire software product—although it would be more time consuming to do so.

iv. During data flow, the check is made for the proper declaration of variables declared and the loops used are declared and used properly.

For example

1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“enter the number “);
6. scanf(“%d”,&n);
7. for(i =1 ;i <=n;i++)
8. fact = fact * i;
9. printf (“the factorial of a number is ”%d”, fact);
10. }

2. Data Coverage (Code Coverage Testing)

i. The logical approach is to divide the code just as you did in black-box testing into its data and its states (or program flow).

ii. By looking at the software from the same perspective, you can more easily map the white-box information you gain to the black-box cases you’ve already written.

iii. Consider the data first. Data includes all the variables, constants, arrays, data structures, keyboard and mouse input, files and screen input and output, and I/O to other devices such as modems, networks, and so on.

For example

1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“enter the number “);
6. scanf(“%d”,&n);
7. for(i =1 ;i <=n;i++)
8. fact = fact * i;
9. printf (“the factorial of a number is %d”, fact);
10. }

The declaration of data is complete with the assignment statement and the variable declaration statements. All the variable declared are properly utilized.

3. Program Statements and Line Coverage (Code Complexity Testing)

i. The most straightforward form of code coverage is called statement coverage or line coverage.

ii. If you’re monitoring statement coverage while you test your software, your goal is to make sure that you execute every statement in the program at least once.

iii. With line coverage the tester tests the code line by line giving the relevant output.

For example

1. #include<stdio.h>
2. void main()
3. {
4. int i , fact= 1, n;
5. printf(“enter the number “);
6. scanf(“%d”, &n);
7. for(i =1 ;i <=n; i++)
8. fact = fact * i;
9. printf (“the factorial of a number is %d”, fact);
10. }

4. Branch Coverage (Code Complexity Testing)

i. Attempting to cover all the paths in the software is called path testing.

ii. The simplest form of path testing is called branch coverage testing.

iii. To check all the possibilities of the boundary and the sub boundary conditions and it’s branching on those values.

iv. Test coverage criteria requires enough test cases such that each condition in a decision takes on all possible outcomes at least once, and each point of entry to a program or subroutine is invoked at least once.

v. Every branch (decision) taken each way, true and false.

vi. It helps in validating all the branches in the code making sure that no branch leads to abnormal behavior of the application.

5. Condition Coverage (Code Complexity Testing)

i. Just when you thought you had it all figured out, there’s yet another Complication to path testing.

ii. Condition coverage testing takes the extra conditions on the branch statements into account