Lecture10 White Box Testing
Lecture10 White Box Testing
(SE3613)
SQE-SE3613 1
White Box Testing
• White box testing techniques analyze the internal structures the used
data structures, internal design, code structure, and the working of the
software rather than just the functionality as in black box testing.
• It is also called glass box testing clear box testing or structural testing.
White Box Testing is also known as transparent testing or open box
testing.
• White box testing is also known as structural testing or code base
testing, and it is used to test the software’s internal logic, flow, and
structure. The tester creates test cases to examine the code paths and
logic flows to ensure they meet the specified requirements.
SQE-SE3613 2
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
• Branch Coverage
• Branch coverage technique is used to cover all branches of the control flow graph. It
covers all the possible outcomes (true and false) of each condition of decision point at
least once. Branch coverage technique is a white box testing technique that ensures that
every branch of each decision point must be executed.
• Function coverage
• The number of functions that are called and executed at least once in the source code
• Condition Coverage/Expression Coverage
• The number of Boolean condition/expression statements executed in the conditional
statement.
3
Statement Coverage Testing
• In this technique, the aim is to traverse all statements at
least once. Hence, each line of code is tested. In the case of a
flowchart, every node must be traversed at least once. Since
all lines of code are covered, it helps in pointing out faulty
code.
SQE-SE3613 4
Example 1– Statement and Decision Coverage
Test case 1: a =2
1.Test (int a)
2.{ Statement Coverage= 83.33%
3. If(a>4)
Test case 2: a =6
4. a=a*3
5. Print (a) Statement Coverage= 100%
6.}
5
Example 2 - Statement and Decision Coverage
• A vending machine dispenses either hot or cold drinks. If you
choose a hot drink (e.g. tea or coffee), it asks if you want milk
(and adds milk if required), then it asks if you want sugar (and
adds sugar if required), then your drink is dispensed.
Test 1: Cold drink
Test 2: Hot drink with milk and sugar
6
Cont..
7
Example 3 - Statement and Decision Coverage
• If you are flying with an economy ticket, there is a possibility that
you may get upgraded to business class, especially if you hold a
gold card in the airlines frequent flier program. If you don't hold
a gold card, there is a possibility that you will get bumped off the
flight if it is full and you check in late.
• Three tests have been run:
• Test 1: Gold card holder who gets upgraded to business class
• Test 2: Non-gold card holder who stays in economy
• Test 3: A person who is bumped from the flight
SQE-SE3613 8
SQE-SE3613 Ibrar Arshad 9
Branch Coverage
• Branch coverage technique is used to cover all branches of
the control flow graph. It covers all the possible outcomes
(true and false) of each condition of decision point at least
once. Branch coverage technique is a white box testing
technique that ensures that every branch of each decision
point must be executed.
• However, branch coverage technique and decision coverage
technique are very similar, but there is a key difference
between the two. Decision coverage technique covers all
branches of each decision point whereas branch testing
covers all branches of every decision point of the code.
SQE-SE3613 10
Example
• Read X
• Read Y
• IF X+Y > 100 THEN
• Print "Large"
• ENDIF
• If X + Y<100 THEN
• Print "Small"
• ENDIF
SQE-SE3613 11
Control flow graph
SQE-SE3613 12
Function Testing
• In white box testing, function coverage is a metric that
measures how many of the defined functions in a software
are called during testing. It's calculated by dividing the
number of functions executed by a test suite by the total
number of functions in the software.
SQE-SE3613 14
Condition Coverage
• Condition coverage is a white-box testing technique that focuses on the evaluation of individual
conditions within a decision-making statement. A condition is a Boolean expression that can
evaluate to either true or false.
• Condition coverage requires that each condition in a decision statement be tested with both true
and false outcomes at least once.
• Condition Coverage = (Total count of conditions executed / Total count of conditions in the source
code) * 100
For example, consider the following code snippet:
SQE-SE3613 16
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
17
Data Flow Testing
1.read x, y;
2.if(x>y)
3. a = x+1
else Variable
Defined at
node
Used at
node
4. a = y-1 x 1 2, 3
5. print a; y 1 2, 4
a 3, 4 5
18
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
19
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
SQE-SE3613 20
Software
Difference Review
Reviews vs Inspection
Inspection
vs Walkthrough
Walkthrough
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 by
participants artifacts the author or creator
Objective The primary goal is to identify The main objective is to detect The purpose is to present and
defects, improve quality, and gather defects, ensure compliance with explain the artifact, gather
feedback on the artifact standards, and improve quality feedback, and clarify its content
Approach Reviewers examine the artifact Involves a defined set of roles and The author guides the
individually before the review responsibilities, with specific entry participants through the artifact,
meeting, providing their insights and exit criteria. The process highlighting its key aspects,
and raising questions or concerns includes a thorough examination of explaining the rationale behind
during the meeting. The focus is on the artifact against predefined decisions, and soliciting input or
the content, correctness, and checklists or criteria to identify suggestions. The focus is on
adherence to standards issues systematically comprehension, understanding,
and knowledge sharing
Interaction Discussions and feedback sharing Follow a more formal process, with Participants actively engage in
are crucial during the review a designated moderator leading discussions, ask questions,
meeting to capture different the session and participants provide feedback, and offer
perspectives and foster adhering to inspection guidelines suggestions
SQE-SE3613 Ibrar Arshad 21
collaboration