Software Development Cross Solution - Index of - Free

White-box testing uses inside knowledge
At the deepest levels of testing, you’ll find white box tests. This is
where you know exactly what’s going on inside the code, and you
do your best to make that code break. If you put aside the fact that
you have to fix the code when it does break, white-box testing can
actually be fun: it becomes a challenge to dig into code and generate
problem situations that will cause errors and crashes.
When doing white-box testing you should be familiar with the code
you’re about to test. You still care about functionality, but you should
also be thinking about the fact that method X is going to divide
by one of the numbers you’re sending in... is that number being
checked properly? With white-box testing you’re generally looking
for:
Testing all the different branches of code. With white-box testing
you should be looking at all of your code. You can see all of the if/
elses and all the case and switch statements. What data do you need to
send in to get the class you’re looking at to run each of those branches?
Proper error handling. If you do feed invalid data into a method, are
you getting the right error back? Is your code cleaning up after itself nicely
by releasing resources like file handles, mutexes, or allocated memory?
Working as documented. If the method claims it’s thread-safe, test the
method from multiple threads If the documentation says you can pass
null in as an argument to a method and you’ll then get back a certain set
of values, is that what’s really going on? If a method claims you need a
certain security role to call it, try the method with and without that role.
Proper handling of resource constraints. If a method tries to
grab resources—like memory, disk space, or a network connection—what
does the code do if it can’t get the resource it needs? Are these problems
handled gracefully? Can you write a test to force the code into one of
those problematic conditions?
White-box tests tend to be code-on-code
Since white-box tests tend to get up close and personal with the code they’re trying to test,
it’s common to see them written in code and run on a machine rather than exercised by a
human. Let’s write some code-on-code tests now...
Download at WoweBook.Com
testing and continuous integration
White-box testing
TestGoodDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
Order
DBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
TestInsufficientDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
TestInvalidDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
MySqlDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
you are here 4 243
DB
check balances, etc.
saveOrder(...) insert into ...
saveGC(...)
update amnt ...
Most code works
great when things are
going as expectedthe
so-called “happy
path”-but what
about when things go
off-track?
Black-box testing
looked at error
messages, but what
about what the code
left around when
things go wrong?
That’s for whitebox
testing to
examine.