Validation testing in software engineering

SUPERIOR GROUP OF COLLEGES, SARGODHA

Software
Engineering
LECTURE
PROF. MUHAMMAD BILAL QURESHI

Validation testing

Validation testing
• Validation testing follows integration testing
• The distinction between conventional and
object-oriented software disappears and
Focuses on user-visible actions and user-
recognizable output from the system

Validation-Test Criteria
• Designed to ensure that All functional requirements are
satisfied , All behavioral characteristics are achieved , All
performance requirements are attained
• Documentation is correct
• Usability and other requirements are met (e.g.,
transportability, compatibility, error recovery,
maintainability)
• After each validation test
– The function or performance characteristic conforms to
specification and is accepted
– A deviation from specification is uncovered and a
deficiency list is created

Configuration Review
• The intent of this review is to ensure that all
elements of the software configuration
•have been properly developed,
•are cataloged, and
•have the necessary detail to encourage the
support activities.

Alpha and Beta Testing
• Alpha testing conducted at the developer’s site by end users
– Software is used in a natural setting with developers
watching intently
– Testing is conducted in a controlled environment
• Beta testing conducted at end-user sites
– Developer is generally not present
– It serves as a live application of the software in an
environment that cannot be controlled by the developer
– The end-user records all problems that are encountered
and reports these to the developers at regular intervals
• After beta testing is complete, software engineers make
software modifications and prepare for release of the
software product to the entire customer base

SYSTEM
TESTING

SYSTEM TESTING
System testing is a series of different tests whose purpose is
to fully exercise the computer based system
• Recovery testing
– Tests for recovery from system faults
– Forces the software to fail in a variety of ways and verifies
that recovery is properly performed
– Tests reinitialization, check pointing mechanisms, data
recovery, and restart for correctness

Security Testing
– Verifies that protection mechanisms built into a
system will, in fact, protect it from improper access.
• Stress testing
– Executes a system in a manner that demands
resources in abnormal quantity, frequency, or
volume

Performance Testing
– Tests the run-time performance of software
within the context of an integrated system
– Often coupled with stress testing and
usually requires both hardware and software
instrumentation
– Can uncover situations that lead to
degradation and possible system failure

Deployment Testing
– Also known as configuration testing
– It examines all installations procedures that
will be used by customers

INTERNALAND
EXTERNAL VIEWS
OF TESTING

INTERNALAND EXTERNAL
VIEWS OF TESTING
•The first test approach takes an external view
and is called black-box testing.
•The second requires an internal view and is
termed white-box testing.

White box testing
• White box testing is also called as glass-box testing
• Using white-box testing methods 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
• Basis path testing is a white-box testing
technique
• The basis path method 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:
– a simple notation for the representation of
control flow, called a flow graph
– It also know as program graph

`
• Arrows called edges or links represent flow of
control
• Circles called flow graph nodes represent one or
more actions
• Areas bounded by edges and nodes called regions
• A predicate node is a node containing a condition

• Independent program paths:
– An independent path is any path through the
program that introduces at least one new set of
processing statements or a new condition
– independent path must move along at least one edge
that has not been traversed(pass through) before the
path is defined
– An independent path is any path through the
program that introduces at least one new set of
processing statements or a new condition
– independent path must move along at least one edge
that has not been traversed before the path is defined

– Example:

• Deriving test cases
– Using the design or code as a foundation,
draw a corresponding flow graph.
– Determine the cyclomatic complexity of
the resultant flow graph.
– Determine a basis set of linearly
independent paths.
– Prepare test cases that will force execution
of each path in the basis set

• Graph matrices
– A data structure, called a graph matrix, can
be quite useful for developing a software tool
that assists in basis path testing
– A 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

Black box testing
• Black-box testing, also called behavioral testing
• Black-box testing attempts to find errors in the
following categories:
– incorrect or missing functions
– interface errors
– errors in data structures or external database
access
– behavior or performance errors
– initialization and termination errors.

Graph-based testing methods
The first step in black-box testing is to understand the
objects that are modeled in software and the relationships
that connect these objects. Once this has been accomplished,
the next step is to define a series of tests that verify “all
objects have the expected relationship to one another”
[Bei95]. Stated in another way, software testing begins by
creating a graph of important objects and their relationships
and then planning a series of tests that will cover the graph
so that each object and relationship is exercised and errors
are uncovered.

To accomplish these steps, you begin 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 (e.g., a specific data
value or state behavior), and link weights that describe some
characteristic of a link. Nodes are represented as circles
connected by links that take a number of different forms. A
directed link (represented by an arrow) indicates that a
relationship moves in only one direction. A bidirectional
link, also called a symmetric link, implies that the
relationship applies in both directions. Parallel links are
used when a number of different relationships are stablished
between graph nodes.

These test cases are designed in an attempt to find
errors in any of the relationships. Beizer describes a
number of behavioral testing methods that can make
use of graphs:
Transaction flow modeling.
Finite state modeling
Data flow modeling.
Timing modeling.

Equivalence Partitioning
• Equivalence partitioning is a black-box
testing method that divides the input domain
of a program into classes of data from which
test cases can be derived
• equivalence classes for an input condition.
Using concepts introduced in the preceding
section, if a set of objects can be linked by
relationships that are symmetric, transitive,
and reflexive, an equivalence class is present

• Equivalence classes may be defined according to the
following guidelines:
1. If an input condition specifies a range, one valid and
two invalid equivalence classes are defined.
2. If an input condition requires a specific value, one valid
and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one
valid and one invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and one
invalid class are defined.

Boundary Value Analysis
• A greater number of errors occurs at the
boundaries of the input domain rather than in
the “center.” It is for this reason that
boundary value analysis (BVA) has been
developed as a testing technique
• Boundary value analysis leads to a selection
of test cases that exercise bounding values

• Guidelines for BVA are similar in many respects to those
provided for equivalence partitioning:
– If an input condition specifies a range bounded by values a
and b, test cases should be designed with values a and b and
just above and just below a and b.
– If an input condition specifies a number of values, test cases
should be developed that exercise the minimum and maximum
numbers.Values just above and below minimum and maximum
are also tested.
– Apply guidelines 1 and 2 to output conditions
– If internal program data structures have prescribed boundaries
(e.g., a table has a defined limit of 100 entries), be certain to
design a test case to exercise the data structure at its boundary.

Orthogonal Array Testing
• Orthogonal array testing can be applied to problems
in which the input domain is relatively small but too
large to accommodate complete testing
• The orthogonal array testing method is particularly
useful in finding region faults
• a single parameter value makes the software fault.
These faults are called single mode faults
• If there exists a consistent problem when specific
levels of two parameters occur together, it is called a
double mode fault

Validation testing in software engineering

More Related Content

Similar to Validation testing in software engineering

Recently uploaded

Validation testing in software engineering

Editor's Notes