White Box Testing

Look from an internal perspective. This technique looks based on the source code.

• choose inputs to exercise paths through the code. Also known as glass-box, transparent, or structural testing.

Method Coverage (MC): each and every method has been called at least once Statement Coverage (SC): all statements in a method have been executed at least once. Branch Coverage (BC): each and every possible branch from eaech decision point is executed at least once. Path Coverage (PC): all possible execution paths are ececuted at least once.

• In general, not possible to achieve full path covage because programs contains loops and some paths might be infeasible/
• Only possible to achieve PC up to a certain depth in a loop. It is possible to achieve full path coverage in programs without loops (or only hard-bounded loops)

Path sensitization is the process of determining test input values that will cause a particular path to be taken.

• In general, it is an undecidable problem.
• Must be solved heuristically
• Gets complicated as size increases.

100% coverage is never a guarantee of fault-free software. However, reaerch has shown that in general, higher code coverage results inm ore faults revealed.

Loops

So how do you deal with loops given that testing all possible iterations of loops can be infeasible/impractical?

We use loop boundary adequacy, a test suite that satisfies the loop boundayr adequacy criterion if for ever loop L,

• there is a test case which iterates L zero times
• there is a test case which iterates L once
• there is a test case which iterates L more than once

Loop boundary adeequcy is usually combined with other adequacy crtieria such as MC,SC, BC, etc.

Bigger Picture

Blackbox testing pros:

• Testing from the user perspective
• Can find holes in the specification/requirements --> bot verification and validation
• Easy to analyze and produce test cases

Black box testing cons/limitation:

• Not implementation aware
• Potentially subjective i.e., depends on the opinions and experince of the test engineer.

White box testing pros:

• Testing from developer perspective
• Implementation-aware
• More objective i.e., not dependent on the test engineer's opinion

Whitebox testing cons/limitation:

• Not always available
• Can miss unimplemented parts of specs/requirements
• Developed tests can be more fragile as they are tightly coupled to the specific implementation
• requires high knowledge of the code and programming in general

Ideally, we use both whitebox and blackbox testing.

Structural testing is a check and balance on the specification-based tests.

The first step of a test engineer should be to derive test cases out of any requirements-based technique. Once requirements are fully covered, test engineers then perform structurual testing to cover what is misssing from the structrual point of view. Any divergences sould be bought back to the requirements-based testing phase.

Blackbox and whitebox testing are views we take towards testing:

• both can be applied at unit, integration, and system levels.