Defect Detection:: Test Case Design at

White Box

by

Dr. Rizwan
 White Box Testing
 White box testing is also know as Glass Testing or Open box
testing is detailed examination of internal structure and logic of
code.
 This examination is demonstrated through test cases creation
by looking at the code to detect any potential failure scenarios.
 Disadvantages of White Box Testing

 This approach generates test inputs, but a test also requires

expected outcomes to compare against.
 Code-based test case design cannot tell whether the outcomes
produced by the software are the correct values – it is the
specification for the code that tells you what it should do.
 So this approach is incomplete, since it cannot generate expected
outcomes.
 It is very difficult to look into every corner of the code, some
code will go unchecked.
 Disadvantages of White Box Testing
 Another problem with this approach is that it only tests code that
exists and cannot identify code that is missing.
 It is also testing that 'the code does what the code does.'
 This is generally not the most useful kind of testing, since we normally
want to test that 'the code does what it should do.‘
 Software works as coded' (not 'as specified').
 This approach cannot find specification defects or missing specifications.
 Advantages of White Box Testing

 As tester has knowledge of the source code it is easy to find

errors.
 White box testing helps us to identify memory leaks.
 When we allocate memory using malloc( ) in C, we should explicitly release that
memory also.
 If this is not done then over time, there would be no memory available for
allocating memory on requests.
 Performance analysis:
 Code coverage tests can identify the areas of a code that are executed most
frequently.
 Extra efforts can be then made to check these sections of code.
 Advantages of White Box Testing
 Due to testers knowledge of code , maximum coverage is
attained during test scenario.
 He or she can then see if the program diverges from its
intended goal.
 Static Software Testing

 Static testing refers to a type of software testing that is

performed without executing the code
 Involves examining the software artifacts, such as
requirements, design documents, source code, and other
documentation, to identify defects, improve quality, and
enhance the overall software development process
 Static Software Testing Types
 Reviews
 Inspections
 Walkthroughs
 Software Reviews vs Inspection vs Walkthrough
Differe Review Inspection Walkthrough
nce
Nature Collaborative evaluation of a Is a formal and well-structured A walkthrough is a guided tour
software artifact by a group of evaluation process for software through a software artifact led
participants artifacts by the author or creator

Objectiv The primary goal is to identify The main objective is to detect The purpose is to present and
e defects, improve quality, and defects, ensure compliance with explain the artifact, gather
gather feedback on the artifact standards, and improve quality feedback, and clarify its content

Approac Reviewers examine the artifact Involves a defined set of roles The author guides the
h individually before the review and responsibilities, with specific participants through the artifact,
meeting, providing their insights entry and exit criteria. The highlighting its key aspects,
and raising questions or process includes a thorough explaining the rationale behind
concerns during the meeting. examination of the artifact decisions, and soliciting input or
The focus is on the content, against predefined checklists or suggestions. The focus is on
correctness, and adherence to criteria to identify issues comprehension, understanding,
standards systematically and knowledge sharing

Interacti Discussions and feedback Follow a more formal process, Participants actively engage in
on sharing are crucial during the with a designated moderator discussions, ask questions,
review meeting to capture leading the session and provide feedback, and offer
8
different perspectives and foster participants adhering to suggestions
collaboration inspection guidelines
Structural or White-box Testing (WBT)

 WBT can also follow the generic testing process but

 Planning plays a much less important role in WBT than in BBT
 Reasons:
 Due to extensive implementation details, WBT is typically limited to a
small scale
 Defect fixing is made easy through the dual role played by the
programmers as testers

9
Coding Standards and Guidelines
 There are 3 reasons for adherence to a standard or
guidelines:
 Reliability It's been shown that code written to a specific
standard or guideline is more reliable and secure than code that
isn't.
 Readability/ Maintainability Code that follows set standards
and guidelines is easier to read, understand and maintain.
 Portability Code often has to run on different hardware or be
compiled with different compilers. If it follows a set of
standards, it will likely be easier - or even completely painless -
to move it to a different platform.
Generic Code Review Checklist
Data Reference Errors
• bugs caused by using a variable, constant, array, string, or
record that hasn’t been properly declared or initialized

Data Declaration Errors

• bugs are caused by improperly declaring or using variables or
constants.

Computation Errors
• computational or calculation errors. The calculations don’ t
result in the expected result.

Comparison Errors
• <, >, =, not =, true, false. Comparison and decision errors are very
susceptible to boundary condition problems.
 Source Code Checklist
 Is the design implemented completely and correctly?
 Are there missing or extraneous functions?
 Is each loop executed the correct number of times?
 Will each loop terminate?
 Will the program terminate?
 Are all possible loop fall-throughs correct?
 Are all CASE statements evaluated as expected?
 Is there any unreachable code?
 Are there any off-by-one iteration errors?
 Source Code Checklist
 Are there any dangling ELSE clauses?
 Is pointer addressing used correctly?
 Are priority rules and brackets in arithmetic expression
evaluation used as required to achieve desired results?
 Are boundary conditions considered? (e.g., null or negative
values, adding to an empty list, etc.)
 Are pointer parameters used as values and vice-versa?
 Interfaces
 Is the number of input parameters equal to then number of
arguments?
 Do parameter and argument attributes match?
 Do the units of parameters and arguments match?
 Are any input-only arguments altered?
 Are global variable definitions consistent across modules?
 Are any constants passed as arguments?
 Are any functions called and never returned from?
 Are returned VOID values used?
 Are all interfaces correctly used as defined in the Software
Design Description?
 Data and Storage
 Are data mode definitions correctly used?
 Are data and storage areas initialized before use, correct fields accessed
and/or updated?
 Is data scope correctly established and used?
 If identifiers with identical names exist at different procedure call
levels, are they used correctly according to their local and global scope?
 Are all pointers based on correct storage attributes?
 Is the correct level of indirection used?
 Are any string limits exceeded?
 Are all variables EXPLICITLY declared?
 Are all arrays, strings, and pointers initialized correctly?
 Are all subscripts within bounds?
 Are there any non-integer subscripts?
 Maintainability and Testability
 Is the code understandable (i.e., choice of variable names, use of
comments, etc.)
 Is there a module header?
 Is there sufficient and accurate commentary to allow the reader to
understand the code?
 Does the formatting and indenting style add to the readability of the
code?
 Are coding conventions followed?
 Is tricky or obscure logic used?
 Is the code structured to allow for easier debugging and testing?
 Is the code structured so that it could be easily extended for new
functions?
 Are there any unnecessary restrictions to extensions due to code
structure?
 Error Handling
 Are all probable error conditions handled?
 Are error messages and return codes used?
 Are they meaningful and accurate?
 Are the default branches is CASE statements handled correctly?
 Does the code allow for recovery from error conditions?
 Is range checking done where appropriate to isolate the source
of an error?
 Complexity Warning

 As code is broken into smaller modules to decrease complexity,

structural complexity increases
 Some modules may have high complexity but are very easy to
comprehend and easy to test
 High complexity numbers are only an indicator of something to
investigate
 How Complex Should Code Be?

 <10: Simple module, not much risk

 10-20: More Complex; moderate risk

 20-50: Complex; high risk

 >50: Untestable; extremely high risk

 Control Flow Graph

 How to Draw a Control Flow Graph

 Number all the statements of a program

 Numbered statements:
 Represent nodes of the flow graph

 An edge from one node to another node exists:

 If execution of the statement representing the first node can result in
transfer of control to the other node
 We need to analyze code
 Control-flow
 Dataflow
Types of Control Flow Graph
Types of Control Flow Graph
Types of Control Flow Graph
Types of Control Flow Graph
 Data Flow Testing
 Data Flow Testing is a method that is used to find the test
paths of a program according to the locations of definitions and
uses of variables in the program
 It has nothing to do with data flow diagrams
 It is concerned with
• Statements where variables receive values,
• Statements where these values are used or referenced
Advantages/Disadvantages of Data Flow Testing
 Advantages of Data Flow Testing:
 Data Flow Testing is used to find the following issues-
• To find a variable that is used but never defined
• To find a variable that is defined but never used
• To find a variable that is defined multiple times before it is
use,
• Deallocating a variable before it is used
 Disadvantages of Data Flow Testing
• Time consuming and costly process
• Requires knowledge of programming languages
 Data Flow Testing
1.read x, y;
2.if(x>y)
3. a = x+1
else
4. a = y-1
5. print a;

Defined at Used at
Variable
node node

x 1 2, 3

y 1 2, 4

a 3, 4 5
 White Box Testing
 White box testing utilizes the logical flow through a program to propose test
cases.
 Logical flow means the way in which certain parts of a program may be
executed as we run the program. Logical flow of a program can be
represented by a control flow graph.
 Most common white box testing methods are:
 Statement Coverage
 Decision/Branch Coverage
 Condition Coverage
 Path Coverage
Structural or White-box Testing (WBT)
 Verifies the correct implementation of internal units (statements, data
structures, blocks etc.) and relations among them
 Connection between execution behavior and internal units needs to be made
in WBT
 Various software tools are used for this purpose
 The simplest form of WBT is Statement Coverage Testing.

29
 White Box Testing Techniques
 Coverage/Code coverage
Code Coverage = (Number of lines of code executed)/(Total
Number of lines of code in a system component) * 100
 Statement Coverage/Block coverage
 The number of statements that have been successfully executed in the
program source code
 Decision Coverage/Branch Coverage
 The number of decision control structures that have been successfully
executed in the program source code
 Function coverage
 The number of functions that are called and executed at least once in
the source code
 Statement Coverage

 The goal is to design test cases so that every statement of the

program is executed at least once

 An error in a program can not be discovered unless the part of

the program containing the error is executed (based on
observation)
 Statement Coverage

int abs(int x ) {
if ( x ≥ 0 )
x = 0 - x;
return x;
}
Structural or White-box Testing (WBT)
 Statement Coverage Testing

If A = 3, B = 9

33
Structural or White-box Testing (WBT)
 Statement Coverage Testing

If A = -3, B = -9

34
 Branch Coverage

 The goal is to design test cases to ensure that each branch is

executed once

 Each decision is evaluated to true and false, at least once traversed

 Generally satisfies statement coverage

 Branch coverage has problems with multiple (compound)

conditions within a decision (&&, ||)
 Branch Coverage
/* x is valid if 0 ≤ x ≤ 100 */

int check (int x ){

if( x ≥ 0 && x ≤ 100 )

return TRUE;

else return FALSE;

}
Inputs Actual Output
Test Cases x
T1 -5
T2 5
 Branch Coverage
/* finding the maximum of two integers x and y */
int Max_check(int x, y, max) {
If (x>y) max = x;
else max = y;
}
Inputs Actual Output
Test Cases x y
T1 3 2
T2 2 4
 Condition Coverage

 The goal is to design test cases to ensure that each condition in a

decision takes on all possible outcomes at least once.
 Ensures that every condition within a decision is covered
 Consider the conditional expression:
((c1 and c2)or c3)
 Each of c1, c2, and c3 are exercised at least once,
i.e. given true and false values require 23 test cases.
 Useful if number of component conditions is small.
 Path Coverage
 A path can contain combination of statements, conditions and
branches grouped together in one path.
 In this way you can select statements, conditions and branches of
your own choices and group them in one path.
 Similarly, you can prioritize source code statement in to various
paths.
How to Design Test Case Through White Box
 Number each line of Code
 Derive Control and data Flow graph from numbered Code
 Partition data in to classes (If required).
 Generate test data against variable and design test case generate
actual output.
How to Design Test Case Through White Box
1. public class myBSearch{
2. public intsearch(intkey, int[] elemArray)
3. {
4. Int bottom = 0;
5. Int top = elemArray.Length-1;
6. Int mid=0;
7. Int index = -1;
8. Boolean found = false;
9. while (bottom <= top && found == false)
10. {
11. mid = (top + bottom) / 2;
12. if (elemArray[mid] == key)
13. {
14. index = mid;
15. found = true;
16. return index;
17. }
How to Design Test Case Through White Box
18. else
19. {
20. if (elemArray[mid] < key)
21. bottom = mid + 1;
22. else
23. top = mid -1;
24. }
25. }
26. return index;
27. }
28. }
29. }
Design Control Flow Graph
Design Control Flow Graph
Design Control Flow Graph
How to Design Test Case Through White Box
1. int main () {
2. float number1;
3. float number2;
4. float number3;
5. cout<<"Please enter Number 01:";
6. cin>>number1;
7. cout<<"Please enter Number 02:";
8. cin>>number2;
9. cout<<"Please enter Number 03:";
10. cin>>number3;
11. if (number1 > number2 && number1 > number3) {
12. cout<<"Number 01 is maximum… "<<endl;
13. }
14. else if (number2 > number1 && number2 > number3) {
15. cout<<"Number 02 is maximum…"<<endl;
16. }
17. else if (number3 > number1 && number3 > number2) {
18. cout<<"Number 03 is maximum…"<<endl;
19. }
How to Design Test Case Through White Box

20. else {
21. cout<<" Invalid entry for maximum "<<endl;
22. }
23. if (number1 < number2 && number1 < number3) {
24. cout<<"Number 01 is minimum…"<<endl;
25. }
26. else if (number2 < number1 && number2 < number3) {
27. cout<<"Number 02 is minimum…"<<endl;
28. }
29. else if (number3 < number1 && number3 < number2) {
30. cout<<"Number 03 is minimum…"<<endl;
31. }
32. else {
33. cout<<" Invalid entry for minimum "<<endl;
34. }
35. return 0;
36. }
How to Design Test Case Through White Box

Test Input Actual Output

Case Number 1 Number 2 Number 3

1 2 5 3 Number 2 is Max
Number 1 is Mini
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

2 9 5 2 Num 1 is Max
Num 3 is Mini
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

3 3 7 6 Number 2 is Max
Number 1 is Mini
How to Design Test Case Through White Box

Test Path Input Output

Case ID No. Num1 Num2 Num3

3 3 8 2 9 Number 3 is Max
Number 2 is Mini
How to Design Test Case Through White Box
1) main ( ) {
2) int num student, marks, subject, total ;
3) float average ;
4) num_student = 1;
5) while (num_student < = 40) {
6) total = 0 ;
7) subject = 1;
8) while (subject < = 5) {
9) Scanf ("Enter marks : % d”, & marks);
10) total = total + marks ;
11) subject ++;
12) }
13) average = total/5 ;
14) if (average > = 50)
15) printf ("Pass... Average marks = % f", average);
16) else
17) print ("FAIL ... Average marks are % f”, average) ;
18) num_student ++;
19) }
20) printf ("end of program") ;
21) }
 ECP

Feature Valid Invalid

Num_studen 0<Num_student<=40 Num_student>40
t 0<Num_student

Subject 0<Subject<=5 0<subject

Subject>5

Average 50< Average < 100 Average<50

Average> 100
How to Design Test Case Through White Box

I/P ECP Actual O/P

Num_std 0<Num_std <40 Average
Subject 0<Subject<=5
Average 50< Average < 100