Code Coverage Testing

(1) 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).

(2) 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.

(3) 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) }

(11)

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

i)Path Coverage

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

2.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.

3.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) }

ii) Condition Coverage

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

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

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

4. 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.

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

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

7. Just when you thought you had it all figured out, there‘s yet another complication to path testing.

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