Testing the Software with X-Ray

Glasses
Topics!

- Dynamic white-box testing

- The difference between debugging and dynamic white-box testing
- Unit and integration testing
- How to test low-level functions
- The data areas that need to be tested at a low level
- How to force a program to operate a certain way
- What different methods you can use to measure the thoroughness of your
testing
 Dynamic White-Box Testing

 Dynamic white-box testing, in a nutshell, is using information

you gain from seeing what the code does and how it works to
determine what to test, what not to test, and how to approach
the testing.

 Another name commonly used for dynamic white-box testing

is structural testing because you can see and use the
underlying structure of the code to design and run your tests.
The four areas that dynamic white-box testing covers
are:

 Directly testing low-level functions, procedures, subroutines,

or libraries. In Microsoft Windows, these are called
Application Programming Interfaces (APIs).
 Testing the software at the top level, as a completed program,
but adjusting your test cases based on what you know about the
software’s operation.
Continue…

 Gaining access to read variables and state information from the

software to help you determine whether your tests are doing
what you thought.

 Measuring how much of the code and specifically what code

you “hit” when you run your tests and then adjusting your tests
to remove redundant test cases and add missing ones.
 Dynamic White-Box Testing versus
Debugging
 The goal of dynamic white-box testing is to find bugs. The
goal of debugging is to fix them.

 They do overlap, however, in the area of isolating where and

why the bug occurs.
 Testing the Pieces
From a testing perspective, there are two reasons for the high
cost:
 It’s difficult and sometimes impossible to figure out exactly
what caused the problem.

 Some bugs hide others. A test might fail. The programmer

confidently debugs the problem and makes a fix, but when the
test is rerun, the software still fails.
 Unit and Integration Testing

 Testing that occurs at the lowest level is called unit testing or

module testing.
 As the units are tested and the low-level bugs are found and
fixed, they are integrated and integration testing is performed
against groups of modules.
 This process of incremental testing continues, putting together
more and more pieces of the software until the entire product—
or at least a major portion of it—is tested at once in a process
called system testing.
Continue…

 There are two approaches to this incremental testing: bottom-

up and top-down.
 In bottom-up testing you write your own modules, called test
drivers, that exercise the modules you’re testing.
 These drivers send test-case data to the modules under test,
read back the results, and verify that they’re correct.
 An Example of Unit Testing

 What this function does is take a string of numbers, – or +

signs, and possible extraneous characters such as spaces and
letters, and converts them to a numeric value.
 The C language function that performs this operation is atoi(),
which stands for “ASCII to Integer.”
 If you’re the software tester assigned to perform dynamic
white-box testing on this module, what would you do?
Reading Assignment

 https://www.imperva.com/learn/application-security/black-
box-testing
/