0% found this document useful (0 votes)
18 views46 pages

White Box Testing AVNIET

The document discusses white box and black box testing methodologies, detailing their definitions, techniques, and applications in software testing. White box testing involves analyzing the internal structure of a program, while black box testing focuses on functional requirements without knowledge of internal workings. Various testing techniques such as basis path testing, cyclomatic complexity, equivalence partitioning, and boundary value analysis are also covered.

Uploaded by

nmknmknmk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views46 pages

White Box Testing AVNIET

The document discusses white box and black box testing methodologies, detailing their definitions, techniques, and applications in software testing. White box testing involves analyzing the internal structure of a program, while black box testing focuses on functional requirements without knowledge of internal workings. Various testing techniques such as basis path testing, cyclomatic complexity, equivalence partitioning, and boundary value analysis are also covered.

Uploaded by

nmknmknmk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 46

White Box Testing

&
Black box testing

Dr.Murali Krishna. Namana, Dept of AI&DS


White Box Testing
VGNT
White-box testing, sometimes called
clear box testing
glass-box testing,
transparent testing,
structured based testing

Analysis of internal structured of component or system


White-box testing
VGNT
 Unit testing
 Integration testing
 System testing
 Who use white box testing
 1.developers (to test their own code)
 2. Testers ( especially in embedded sw)
Using white-box testing methods, you can
derive test cases that

 guarantee that all independent paths within a


module have been exercised at least once
 exercise all logical decisions on their true
and false sides,
 Execute all loops at their boundaries and
within their operational bounds,
 Exercise internal data structures to ensure
their validity
Basis path testing - proposed by Tom

– Flow Graph Notation


– Independent Program Paths
– Deriving Test Case
– Graph Matrices

Control Structure Testing


Aim of Basis path testing

 Simply defining the set of execution paths

 The designer measure the logical complexity

Execution Paths

enables the test case designer to derive a logical complexity measure of a


procedural design and use this measure as a guide for defining a basis set of
execution paths.
Flow Graph Notation

 It simply represent the control flow called as


flow graph (program graph)
 Each structured build corresponding flow
graph symbol

each circle represents  source code statement


Cyclomatic Complexity

 Cyclomatic complexity is a software metric that provides a


quantitative measure of the
logical complexity of a program
 cyclomatic complexity defines the number of independent
paths in the basis set of a program and provides us with an
upper bound forn the number of tests that must be
conducted to ensure that all statements have been
executed at least once.
 independent path is any path through the program that
introduces at least one new set of processing statements or
a new condition
Flowchart

A flowchart is used to
depict program control
structure

the flowchart into a


corresponding flow graph
flow graph
Each circle, called a flow graph
node, represents one or more
procedural statements

A sequence of process boxes


and a decision diamond can
map into a single node

The arrows on the flow graph,


called edges or links, represent
flow of control.

An edge must terminate at a


node, even if the node does not
represent any procedural
statements

Areas bounded by edges and


nodes are called regions
Independent Program Paths

 at least one new set of processing statements


or a new condition.
 independent path must move along at least
one edge
To know how many paths
Cyclomatic complexity provides the
answer (software metric)

V(G)= E - N + 2 (E= no of flow


graph edges , N=no of flow graph
nodes. 11-9+2=4
V(G) = P + 1 (P= number of
predicate nodes ) 3+1=4
Graph Matrices

 graph matrix is a square matrix whose size


(i.e., number of rows and columns) is equal to
the number of nodes on the flow graph
 Each row and column corresponds to an
identified node, and matrix entries correspond
to connections (an edge) between nodes.
 link weigh (1 (a connection exists) or 0 (a
connection does not exist)
Connection matrix

weighting to indicate
connections (0 or 1)

Each letter has been


replaced with a 1,
indicating that a
connection exists
Control Structure Testing

 basis path testing is simple and highly effective,


it is not sufficient in itself
 Condition Testing
 Data Flow Testing
 Loop Testing
Condition Testing
a test-case design method that exercises the
logical conditions contained in a program module.
 A relational expression takes the form
 E1<relational-operator> E2
 E1 & E2 are arithmetic expressions and
<relational-operator> is
 If a condition is incorrect, then at least one
component of the condition is incorrect.
Data Flow Testing

 Select the test paths of a prog


 According to the location of
 definitions and uses of different variables in
a prog

Loop Testing

 Loop testing is a white-box testing technique


that focuses exclusively on the validity of loop
constructs.
 Four different classes of loops can be defined:
simple loops,
concatenated loops,
nested loops,
unstructured loops
simple loops
 The following set of tests can be applied to
simple loops, where n is the maximum number
of allowable passes through the loop
 1. Skip the loop entirely.
 2. Only one pass through the loop.
 3. Two passes through the loop.
 4. m passes through the loop where m < n.
 5. n -1, n, n +1 passes through the loop
Tests are designed to answer the
following questions:

 • How is functional validity tested?


 • How is system behavior and performance tested?
 • What classes of input will make good test cases?
 • Is the system particularly sensitive to certain input
values?
 • How are the boundaries of a data class isolated?
 • What data rates and data volume can the system
tolerate?
 • What effect will specific combinations of data have on
system operation?
BLACK-BOX TESTING

 Black-box testing, also called behavioral testing,


focuses on the functional require-
 ments of the software.
 black-box testing enables the software test
engineer to test of input conditions that will fully
exercise all functional requirements for a
program.
 Black-box testing is not an alternative to white-
box techniques
Black-box testing attempts to find
errors in the following categories:

(1) incorrect or missing functions,


(2) interface errors,
(3) errors in data structures or external data
base access,
(4) behavior or performance errors,
(5) initialization and termination errors.
 Graph-Based Testing Method
 Equivalence Partitioning
 Boundary Value Analysis
Equivalence Partitioning
 Testers can divide possible inputs into groups or
“partitions”, and test only one example input from
each group.
 For example, if a system requires a user’s birth
date and provides the same response for all
users under the age of 18, and a different
response for users over 18, it is sufficient for
testers to check one birth date in the “under 18”
group and one date in the “over 18” group.
 If an input condition specifies a range, one valid
and two invalid equivalence classes are defined.

 If an input condition requires a specific


guidelines:

value, one valid and two invalid


equivalence classes are defined
 If an input condition specifies a member of a
set, one valid and one invalid equivalence class
are defined.
 If an input condition is Boolean, one valid and
one invalid class are defined.
testing the boundary values of
valid and invalid partitions.

Boundary Value Analysis


 Testers can identify that a system has a
special response around a specific boundary
value.
 For example, a specific field may accept
only values between 0 and 99. Testers can
focus on the boundary values (-1, 0, 99 and
100), to see if the system is accepting and
rejecting inputs correctly
Graph-Based Testing
Method
 graph drawing that depicts the link between the
causes (inputs) and the effects (output), which trigger
the effects.
 The first step in black-box testing is to understand the
objects, that are modeled in software and the
relationships that connect these objects
 next step
 define a series of tests that verify “all objects have the
expected relationship to one another
 the software engineer begins by creating a graph
—a collection of nodes that represent objects;
 links that represent the relationships between
objects;
 node weights that describe the properties of a
node
 link weights that describe some characteristic of a
link
Nodes are represented
as circles
Product metrics

 Software quality,
 metrics for analysis model,
 metrics for design model,
 metrics for source code,
 metrics for testing,
 metrics for maintenance
Examples of Metrics from Everyday
Life

 Working and living


– Cost of utilities for the month
– Cost of groceries for the month
– Amount of monthly rent per month
– Time spent at work each Saturday for the past month
– Time spent mowing the lawn for the past two times
 College experience
– Grades received in class last semester
– Number of classes taken each semester
– Amount of time spent in class this week
– Amount of time spent on studying and homework this week
– Number of hours of sleep last night
 Travel
– Time to drive from home to the airport
– Amount of miles traveled today
– Cost of meals and lodging for yesterday
Software Quality
Definition:
 Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards, and implicit characteristics
that are expected of all professionally developed
software
 Three important points in this definition
 Explicit software requirements (clarity )
 Specific standards
33
 set of implicit requirements (understanding)
Why have Software Product
Metrics?

 Help software engineers to better understand


the attributes of models to assess the quality
of the software

 Provide
a systematic way to assess quality
based on a set of clearly defined rules
Properties of Software Quality
Factors-McCall Quality Factors

 Some factors can be directly measured (e.g.


defects -- during testing)
 Other factors can be measured only
indirectly (e.g., usability or maintainability)

 Software quality factors can focus on three important aspects


– Product operation: what about operational characteristics
– Product revision: what about ability to change
– Product transition: what about adaptability to new environments
Software Quality
ISO 9126 Software Quality Factors
Functionality
The degree to which the software satisfies stated needs
Reliability
The amount of time that the software is available for use
Usability
The degree to which the software is easy to use
Efficiency
The degree to which the software makes optimal use of system resources
Maintainability
The ease with which repair and enhancement may be made to the software
Portability
The ease with which the software can be transposed from one environment
to another
Metrics for the Analysis Model

 Function Points
 Metrics for specification quality
 First proposed by Albrecht in 1979; hundreds of books and papers
-- functions points

 for measuring the functionality delivered by a system


 Using historical data, function points can be used to

– Estimate the cost or effort required to design, code, and test the software
– Predict the number of errors that will be encountered during testing
– estimate the number of components and/or the number of projected source code
lines in the implemented system

 FP are Derived using the relationship - based on


1) Countable (direct) measures of the software’s information domain
2) Assessments of the software’s complexity
Information Domain Values

 Number of external inputs


– Each external input initiate from a user or is transmitted from
another application
– They provide distinct application-oriented data or control
information
– They are often used to update internal logical files
 Number of external outputs
– Each external output is derived within the application and provides
information to the user
– This refers to reports, screens, error messages, etc.
– Individual data items within a report or screen are not counted
separately
Information Domain Values
(continued)

 Number of external inquiries


– An external inquiry is defined as an online input that results in the
generation of some immediate software response
– The response is in the form of an on-line output
 Number of internal logical files
– Each internal logical file is a logical grouping of data that resides
within the application’s boundary and is maintained via external
inputs
 Number of external interface files
– Each external interface file is a logical grouping of data that
resides external to the application but provides data that may be of
use to the application
Function Point Computation
1) Identify/collect the information domain values
2) Complete the table shown below to get the count total
• Associate a weighting factor (i.e., complexity value) with each count
based on criteria established by the software development
organization
3) Evaluate and sum up the adjustment factors (see the next two
slides)
• “Fi” refers to 14 value adjustment factors, with each ranging in value
from 0 (not important) to 5 (absolutely essential)
4) Compute the number of function points (FP)
FP = count total * [0.65 + 0.01 * sum(Fi)]
Computing function point
 Information Weighting Factor
 Domain Value Count Simple Average Complex
 External Inputs _____ x 3 4 6 = _____
 External Outputs _____ x 4 5 7 = ____
 External Inquiries _____ x 3 4 6 = ____
 Internal Logical Files _____ x 7 10 15 = ____
 External Interface Files _____ x 5 7 10 = _____
Count total ________
Value Adjustment Factors
(continued)
8) Are the internal logical files updated on-line?
9) Are the inputs, outputs, files, or inquiries complex?
10) Is the internal processing complex?
11) Is the code designed to be reusable?
12) Are conversion and installation included in the design?
13) Is the system designed for multiple installations in different
organizations?
14) Is the application designed to facilitate change and for ease of
use by the user?

45
Value Adjustment Factors

1) Does the system require reliable backup and recovery?


2) Are specialized data communications required to transfer
information to or from the application?
3) Are there distributed processing functions?
4) Is performance critical?
5) Will the system run in an existing, heavily utilized operational
environment?
6) Does the system require on-line data entry?
7) Does the on-line data entry require the input transaction to be
built over multiple screens or operations?

(More on next slide) 46

You might also like