Entire WBT is done by developers. It
is the testing of each and every line of code in the program. Developers do
WBT, sends the s/w to testing team. The testing team does black box testing and
checks the s/w against requirements and finds any defects and sends it to the
developer. The developers fixes the defect and does WBT and sends it to the
testing team. Fixing defect means the defect is removed and the feature is
working fine.
Test
engineers should not be involved in fixing the bug because,
1) if they spend time in fixing the
bug, they lose time to catch some more other defects in the s/w
2) fixing a defect might break a lot
of other features. Thus, testers should always identify defects and developers
should always be involved in fixing defects.
WBT
consists of the following tests :
a)
Path testing
Write flow graphs and test all the
independent paths.
Writing flow graphs means – flow graphs means representing
the flow of the program, how each
program is interlinked with one another.
Test all independent paths – Consider a path from main( ) to
function 7. Set the parameters and test if the program is correctly in that
path. Similarly test all other paths and fix defects.
b)
Condition testing
Test all the logical conditions for
both true and false values i.e, we check for both “if” and “else” condition.
If(
condition) - true
{
…….
…….
}
Else
- false
{
…..
…..
}
The program should work correctly
for both conditions i.e, if condition is true, then else should be false and
vice-versa
c)
Loop testing
Test the loops(for, while, do-while,
etc) for all the cycles and also check for terminating condition if working
properly and if the size of the condition is sufficient enough.
For ex, let us consider a program
where in the developer has given about 1lakh loops.
{
While ( 1,00,000 )
…….
…….
}
We cannot test this manually for all
1lakh cycles. So we write a small program,
Test
A
{
……
…… }
Which checks for all 1lakh loops. This Test A is known as unit
test. The test program is written in the same language as the source code
program. Developers only write the test program.
Let
us consider the above case as shown in the figure. Suppose the project consists
of Requirement A,B,C,D,E. Then the developer writes the Codes A,B,C,D,E for the
corresponding requirements. The program consists of 100s of lines of code.
As developers do WBT, they test the 5 programs
line by line of code for defects. If in any the program, there is a defect, the
developers identify the defect and rectifies it, and they again have to test
the program and all the programs again. This involves a lot of time and effort
and slows down the project completion time.
Let
us consider another case. Suppose the client asks for requirement changes, then
the developers have to do the necessary changes and test the entire 5 programs
again. This again involves a lot of time and effort.
This drawback can be
corrected in the following manner.
We
write a test program for the corresponding program. The developers write these
test programs in the same language as the source code. The developers then run
these test programs also called as unit test programs. These test programs
connect to the main programs and run as the programs. Thus if there is any
requirement change or defects in the program, then the developers simply make
the changes either in the test program / main program and run the test program
as a whole.
The
collection of test programs is known as test
suite.
As
early as we catch the bug, cost of fixing the bug will be less. If we delay in
catching the bug, cost of fixing the bug increases exponentially.
Let
us consider a program for the calculator. Let us consider the addition
function.
The
other test programs are,
Y
= callAdd.myAdd (10.5, 5.2)
If
( Y = 15.7)
{
Print (“test is pass”)
}
Else
{
Print(“test is fail”)
}
Similarly
we do for,
Z
= 9,00,000 and 1,00,000
P
= -10, -5
In
all the above test programs, the variables of X, Y, Z, P are calling the function
add.java and getting the add. We do the addition manually and check for the
remaining results. We can see that the test programs are more tedious and
lengthy and time consuming.
Thus,
we have readymade programs.
Like,
for example, we have a ready-made
program named Junit which has a
feature named Assert which runs the
above and compares the 2 values and automatically prints pass or fail.
Thus
we can replace the test programs with these simple programs,
Import
Junit
X
= callAdd.myAdd (10, 5)
Call Assert (X, 15)
It
automatically prints pass or fail. Similarly we can do for the other tests for
Y, Z and P.
d) From memory
point of view of testing
The
size of code of a program increases because,
i) The logic used by the programmer may vary. If
one developer writes a code of 300kb file size, then another developer may
write the same program using different logic and write of code of 200kb file
size.
ii ) Reuse of code is
not there : for
example, if for 5 programs of the same s/w, the 1st ten lines of the
program is the same. Then we can write these ten lines as a separate function
and write a single function call using which the 5programs can access this
function. Also, if any defect is there we can simply change the line of code in
the function rather than all the programs.
iii ) Developers declare so many
variables, functions which may never be used in any part of the program. Thus,
the size of the program increases.
For ex,
Int
i = 10 ;
Int
j = 15 ;
String
S = “hello” ;
.
. . . .
.
. . . .
.
. . . .
. . . .
.
. . . .
Int
a = j ;
Create
user
{
. . . .
. . . . 100 lines of code
. . . .
}
In the above program, we can see
that the integer i has never been called anywhere in the program and also the
function create user has never been
called anywhere in the program. Thus this leads to memory wastage.
We cannot recognize this error
manually by checking the program because of the large program. Thus we have
ready-made tools to check for unnecessary variables and functions.
|
Program
A
Int
i = 10
Int
j = 15
String
S = “hello”
. .
. .
. .
. .
Int
a = j
Create
user ( )
{
. . . .
. . . .
. . . .
}
|
Programs A, B, and C is given as
input to D. D goes into the programs and checks for unused variables. It then
gives the result. The developer can then click on the various results and call
or delete the unused variables and functions.
This tool is specific only for C,
C++ languages. For other languages, we have other similar tools.
iv
) The developer
doesn’t use already existing inbuilt functions and sits and writes the entire
function using his logic. Thus leads to waste of time and also delays.
Let us consider there is an already
inbuilt function sort ( ). Instead
the developer sits and writes his own program mysort ( ). This leads to waste of time and effort. Instead he
could have used a single function call
sort ( ).
e
) Test for response time/ speed/ performance of the program
The reasons for slow performance
could be,
i ) Logic used
ii ) Switch case – Do not use nested if, instead use switch case
iii ) Also there must be appropriate
use of “or” and “and” for conditional cases.
As the developer is doing WBT, he
sees that the program is running slow or the performance of the program is
slow. The developer cannot go manually through the code and check which line of
the code is slowing the program.
We have a tool by name Rational Quantify to do this job
automatically. As soon as all the programs are ready. This tool will go into
the program and runs all the programs. The result is shown in the result sheet
in the form of thick and thin lines. Thick lines indicate that the piece of
code is taking longer time to run. When we double-click on the thick line, then
the tool automatically takes us to the line/piece of code which is also colored
differently. We can modify that code and again use rational quantify. When the
sequence of lines are all thin, we know that the performance of the program has
improved.
Developers do a lot of WBT
automatically rather than manually because it saves time.
Difference
between White Box Testing and Black Box testing
1)
White Box Testing 2)
Black Box Testing
a)
1) Done by
developers
2) Done by test engineers
b) 1) Look
into the source code and test the logic of the code
2) Verifying the
functionality of the application against requirement specifications
c) 1) Should
have knowledge of internal design of the code
2) No need to have knowledge
of internal design of the code
d)
1) Should have
knowledge of programming
2) No need to have knowledge
of programming
0 comments:
Post a Comment