SAZ6C SOFTWARE TESTING
Unit : I - V
UNIT I - SYLLABUS
Introduction Purpose Productivity and Quality in Software Testing Vs Debugging Model for Testing Bugs Types of Bugs Testing and Design Style
1 SAZ6C - SOFTWARE TESTING
INTRODUCTION
Definition
Software testing is used to check the software.
It is used to find the errors.
Testing is used to verifying the program code is right or
wrong.
It is a part of quality assurance.
2 SAZ6C - SOFTWARE TESTING
PURPOSE
Productivity and quality in software Goals for testing Phases in a tester’s mental life Test design
Testing isn’t everything The Pesticide Paradox and the complexity Barrier
3 SAZ6C - SOFTWARE TESTING
Productivity and Quality in Software
In production, every manufacturing stage is subjected to quality
control and testing.
There is a trade off between quality assurance cost and
manufacturing cost.
The manufacturing cost of the quality assurance software copy is
trivial.
The software manufacturing quality assurance is automated.
4 SAZ6C - SOFTWARE TESTING
Goals for testing
Primary goal: Bug prevention
Secondary goal: Bug discovery
A bug is manifested in deviations from expected behavior.
5 SAZ6C - SOFTWARE TESTING
Phases in a tester’s mental life
• Phase 0-there is no difference between testing and debugging. Other than in support of debugging, testing has no purpose.
• Phase1-the purpose of testing is to show that the software works.
• Phase2-the purpose of testing is to show that the software does not work
• Phase3-the purpose of testing is not proving anything, but to reduce the perceived risk of not working to an acceptable value.
• Phase4-testing is not an act. it is a mental discipline that results in low-risk software without much testing effort
6 SAZ6C - SOFTWARE TESTING
Test design The programming process in test design:
• Design,
• Test design,
• Code,
• Test code,
• Program inspection,
• Test inspection,
• Test debugging,
• Test execution,
• Program debugging
• Testing.
7 SAZ6C - SOFTWARE TESTING
Testing isn’t everything
The major methods in decreasing order of effectiveness are
Inspection methods
Design style
Static analysis methods
Languages
Design methodologies and development environment
8 SAZ6C - SOFTWARE TESTING
The Pesticide Paradox and Complexity Barrier
First law: The pesticide paradox: every method use to prevent or
find bugs leaves a residue of subtler bugs against which those
methods are ineffectual.
Second law: The complexity barrier: software complexity grows to
the limits of our ability to manage that complexity.
9 SAZ6C - SOFTWARE TESTING
10
Testing Vs Debugging
TESTING DEBUGGING
1. Testing starts with known
conditions
2. Testing should be
planned,designed,sheduled.
3. Testing is a demonstration of
error or apparent correctness
4. Testing proves programmers
failure.
5. Testing as executed should
strive to be predictable.
6. Much of the testing can be
done without design
knowledge.
7. Testing can often be done by
an outsider.
1. Debugging starts from unknown
initial conditions
2. Procedure and duration can not
be constrained
3. Debugging is a deductive
process
4. Debugging is the programmer’s vindication
5. Debugging demands
experimentation and freedom
6. Debugging is impossible
without detailed design
knowledge.
7. Debugging must be done by
an insider
SAZ6C - SOFTWARE TESTING
Model for Testing
• The project
• The environment
• The program
• Bugs
• Tests
• Testing and levels
• The role of models
11 SAZ6C - SOFTWARE TESTING
Bugs
• Definition:
Bugs are errors in the codes.
Bugs depend on frequency, correction cost, installation cost, and
consequences.
• Hypothesis
1.Benign bug hypothesis 2.Bug locality hypothesis
3.Control bug dominance 4.code/data separation
5.Lingua Salvator Est. 6.correction Abide
7.Silver bullets 8.sadism suffices
9.Angelic testers
• Categories : 1.Initialization 2.Call sequence 3.Wrong variables
12 SAZ6C - SOFTWARE TESTING
Types of bugs Requirements, features, and functionality bugs.
Structural bugs.
Data bugs.
Coding bugs.
Interface, integration, and system bugs.
Test and test design bugs.
Testing and design style.
13 SAZ6C - SOFTWARE TESTING
Requirements, features, and functionality bugs
Requirements and specifications
Feature bugs
Feature interaction
Specification and feature bug remedies
1.Short term support
2.Long term support
Testing techniques
14 SAZ6C - SOFTWARE TESTING
Structural, Coding and Data bugs
Structural Bugs
Control and sequence bugs
Logic bugs
Processing bugs
Initialization bugs
Data-flow bugs and anomalies
Coding Bugs
Source Code bugs
Syntax Bugs
Data Bugs
Dynamic versus static
Information, parameter, and control
Contents, structures, and attributes
15 SAZ6C - SOFTWARE TESTING
Testing and Design Style bugs Testing
Test criteria
Remedies 1.Test debugging
2.Test quality assurance
3.Test execution automation
4.Test design automation
Good design
1. Bugs before they occur.
2. They are easy to test.
3. Works best on good code and good designs.
Bad design-difficult to test.
16 SAZ6C - SOFTWARE TESTING
UNIT II - SYLLABUS Motivation and Assumptions
Controls Flow graphs
Path testing
Loops
More on testing Multi-entry/Multi-exit routines
Effectiveness of path testing
variations
17 SAZ6C - SOFTWARE TESTING
Motivation and Assumptions
Path testing is most applicable to new software for unit testing. It
is a structural technique.
Structured programming languages prevent many of the bugs targeted by path testing.
18 SAZ6C - SOFTWARE TESTING
Definition – Flow Graph and Control Flow Graph
Flow graph: Graphical representation of a program's structure.
Control Flow Graph A simplified, abstract, and graphical representation of a program’s control structure using process blocks, decisions and junctions.
19 SAZ6C - SOFTWARE TESTING
SAZ6C - SOFTWARE TESTING 20
Control Flow Graph
PROCESS BLOCK
A process block is a sequence of program statements
uninterrupted by either decisions or junctions.
Processes
DO PROCESS A
Control Flow graphs Versus Flowcharts
Control flow graphs don’t show the details of what is in a process
block.
In flowcharts every part of the process block is drawn.
Path Testing and its criteria
A path through a program is a sequence of instructions or statements. A path segment is a succession of consecutive links that belongs to some path.
The length of a path is measured by the number of links in it.
It is the structural model . It is the cornerstone of testing.
Selecting a set of test path through the program.
Criteria
Path testing(P∞)
Statement testing(P1)
Branch testing(P2)
21 SAZ6C - SOFTWARE TESTING
Loops and More on testing Multi-Entry/Multi-
Exit Routines
THE KINDS OF LOOPS
Single loops
Nested loops
Concatenated loops
Horrible loops
Multi-entry/multi-exit routine
Multi-entry/multi-exit routine structured by using a fictional entry case statements. The theory and tools issue 1.Well-formed 2.Ill-formed
22 SAZ6C - SOFTWARE TESTING
Effectiveness of path testing and variations
Path testing is more effective for unstructured than for structured software.
The test design process, at all levels, is at least as effective at catching
bugs as is running the test designed by process.
Variations
There are two main classes of variations
Strategies between P2 and total path testing.
Strategies weaker than P1 or P2.
23 SAZ6C - SOFTWARE TESTING
Achievable Paths
Predicates
Predicate Expressions
Predicate Coverage
Testing Blindness
24 SAZ6C - SOFTWARE TESTING
Definition
Predicates:
The logical function evaluated at a decision is called a Predicate.
A predicate associated with a path is called a Path Predicate.
Multi-Way Branches
The multiway branches computed GOTO's, case statements, or jump tables cannot be directly expressed in TRUE/FALSE terms. It describes alternatives by using multivalued logic.
25 SAZ6C - SOFTWARE TESTING
Definition
Inputs
Input includes all data objects referenced by the routine whose values
are fixed prior to entering it.
Example: A calling sequence, objects in data structure, values left in a
register.
Predicate Expressions
The act of symbolic substitution of operations along the path is called predicate interpretation. The path predicates are the specific form of the predicates of the decisions along the selected path after interpretation.
26 SAZ6C - SOFTWARE TESTING
Predicate Coverage
Predicate coverage has been achieved if all possible combination of
truth values corresponding to the selected path have been explored
under some test. Predicate coverage is stronger than branch coverage.
Testing Blindness Testing blindness is a pathological situation in which the desired path is achieved for the wrong reason. TYPES: 1.Assignment blindness - It occurs when the buggy predicate appears to work correctly. 2.Equality Blindness - It occurs when the path selected by a prior predicate results in a value that works both for the correct and buggy predicate. 3.Self Blindness - It occurs when the buggy predicate is a multiple of the correct predicate and as a result is indistinguishable along that path
Definition
27 SAZ6C - SOFTWARE TESTING
Path Instrumentation
Topics
Link Markers
Link Counters
Other Instrumentation Methods
Implementation
28 SAZ6C - SOFTWARE TESTING
Link markers and counters
Link Marker
A simple and effective form of instrumentation is called traversal
marker or link marker.
Link Counter
A less disruptive instrumentation method is based on counters. Link markers also leads us to double link counters.
Other Instrumentation Methods The methods can use to instrument paths are limited only by imagination. Instrumentation gives more information. Implementation Install probes is easy when programming in languages that support conditional assembly or conditional compilation. The counters and traversal markers can be implemented, and one need not be parsimonious with the number and placement of probes.
29 SAZ6C - SOFTWARE TESTING
TRANSACTION FLOW TECHNIQUES
Transaction flow testing techniques
The following link explains the testing techniques
30 SAZ6C - SOFTWARE TESTING
UNIT III - SYLLABUS
Data-Flow testing Strategies Terminology
The Strategies
Slicing, Dicing, Data Flow, and Debugging
31 SAZ6C - SOFTWARE TESTING
Data-Flow testing Strategies
Data-Flow testing strategies are based on selecting test path
segments also called sub paths.
Stronger path
Weaker path
32 SAZ6C - SOFTWARE TESTING
Terminology
A definition-clear path segment
A loop-free path segment
A simple path segment
A du path
33 SAZ6C - SOFTWARE TESTING
The Strategies All-du paths
All-Uses Strategy
All-p-Uses/Some-c-Uses and All-c-Uses/Some-p-Uses Strategies.
All-definitions Strategies
All-Predicated-uses, All-Computational uses Strategies
Ordering the Strategies
34 SAZ6C - SOFTWARE TESTING
Slicing, Dicing, Data Flow, and Debugging
A (static) program Slice is a part of a program.
A program dice is a part of a slice in which all statements which are
known to be correct have been removed.
Dynamic slicing is a refinement of static slicing in which only
statements on achievable paths to the statement.
35 SAZ6C - SOFTWARE TESTING
Topics: Domains and Paths A Domain is a Set
Domains, Paths, and Predicates
Domain Dimensionality
The Bug Assumptions
Restrictions
Let us follow the video to learn more about Domain, Domain
testing and paths
Domains and paths
36 SAZ6C - SOFTWARE TESTING
Domain Testing
Domains & Interface Testing
• Domain
• Range Function /
Routine Classify
37 SAZ6C - SOFTWARE TESTING
Domain Testing –
Interface Range/Domain Compatibility Testing
• Test each vary independently
• Find an inverse function
• Build a super domain
38 SAZ6C - SOFTWARE TESTING
Domain Testing
39 SAZ6C - SOFTWARE TESTING
Views Programs as input data classifiers
Verifies if the classification is correct
Domain Testing - Domains & Paths Domain Testing Model
40 SAZ6C - SOFTWARE TESTING
Two Views
• Based on Specs
• Functional Testing
• Based on Implementation information
• Structural Technique
• Variables
• Simple combinations of two variables
• Numbers from - to + • Input variables as numbers and Loop-free Programs.
Domains and Interface Testing
41 SAZ6C - SOFTWARE TESTING
Domains and Range
Closure Compatibility
Span Compatibility
Interface Range/Domain Compatibility Testing
Finding the values
Interface Range/Domain Compatibility Testing
42 SAZ6C - SOFTWARE TESTING
• Test each vary independently
• Find an inverse function
• Build a super domain
43 SAZ6C - SOFTWARE TESTING
UNIT IV - SYLLABUS
Linguistic metrics
Statement counts
Halstead’s metrics
Token count
Structural metrics
General and cyclamates complexity(mccabe’s metric) Path products & expressions
The case generation
LINGUISTIC METRICS
General
Lines of code, statements counts, and Related Metrics
Halstead’s Metrics
Token count
Introduction
44 SAZ6C - SOFTWARE TESTING
LINGUISTIC METRICS
Linguistic metrics measure property of text without
interpreting what is measured.
A metric is linguistic if its value doesn’t change when rearrange the text.
Applied mostly to program text
45 SAZ6C - SOFTWARE TESTING
COUNT AND NOT COUNT?
46 SAZ6C - SOFTWARE TESTING
HOW TO COUNT AND NOT COUNT?
The quality of comments materially affects maintenance cost.
The lines of code metrics has obvious difficulties.
The count depends on the printing format. The lines of code is as
good as other metric for small programs, but is optimistic for big
programs.
Lines Of Code Makes More Sense For Source Languages In
Which There’s A High Correlation Between Statement Count And Lines Of Code.
47 SAZ6C - SOFTWARE TESTING
STATEMENT COUNTS
The Difficulties With Lines Of Code Can Be Overcome By Using
Statement Instead.
This Evokes New Problems As Bad As Those Of Lines Of Code.
There’s No Simple Rule For Defining “Statement” Across Different Language.
Subjectivity Deciding What Is And What Is Not To Be Called
Statement.
48 SAZ6C - SOFTWARE TESTING
HALSTEAD’S METRICS
Halstead’s Metrics Are Based On A Combination Of Arguments Derived From Common Sense, Information Theory, And
Psychology.
Program Length, Which Is Not To Be Confused With The Number
Of Statements In A Program.
Halstead Defines A Program’s Vocabulary As The Sum Of The Number Of Distinct Operators And Operands.
N=vocabulary=n1+n2
49 SAZ6C - SOFTWARE TESTING
TOKEN COUNT
A token in a programming language is the basic syntactic unit from
which programs are constructed.
Tokens include keywords, labels, constants, strings, and variable
names
50 SAZ6C - SOFTWARE TESTING
General
Cyclamates Complexity(McCabe’s Metric)
Other structural Metrics
51 SAZ6C - SOFTWARE TESTING
STRUCTURAL METRICS
General and Cyclamates
Complexity(McCabe’s Metric)
Structure metrics take the opposite viewpoint of linguistic metrics.
Linguistic complexity is ignored while attention is focused on control-
flow or dataflow complexity.
Metrics based on the properties of flow graph models of programs
Cyclamates Complexity(McCabe’s Metric) link follows
Cyclamates Complexity(McCabe’s Metric)
52 SAZ6C - SOFTWARE TESTING
OTHER STRUCTURAL METRICS
• Cyclomatic complexity over data flow graphs should be as useful a
metrics as cyclomatic complexity over control flow graphs but corroboration
is still lacking
53 SAZ6C - SOFTWARE TESTING
PATH PRODUCTS & EXPRESSIONS
Path Products
Loops
Identity Elements
Path Sums
Distributive Laws
Absorption Rule
The following link explains the above concept
PATH PRODUCTS AND EXPRESSIONS
54 SAZ6C - SOFTWARE TESTING
THE CASE GENERATION GENERATORS, RECOGNIZERS, & APPROACH
1.High level syntax errors
2.Intermediate level syntax errors
3.Field syntax errors
4.Delimiter errors
5.Syntax value errors
6.State dependency errors TEST CASE DESIGN
1.Strategy
2.Top, intermediate, and field level syntax errors
3.Delimiter errors
4.Field value errors
5.Context dependent syntax errors
6.State dependency errors
55 SAZ6C - SOFTWARE TESTING
UNIT V - SYLLABUS
•Decision tables and Transition Testing
•States
• State graphs & Transition
• State Testing
56 SAZ6C - SOFTWARE TESTING
1. DECISION TABLES 2. TRANSITION TESTING
Decision tables and Transition Testing
57 SAZ6C - SOFTWARE TESTING
The following link explain the decision tables and transition testing
INTRODUCTION
STATE GRPAH
STATE TABLE
FINITE – STATE MACHINE
58 SAZ6C - SOFTWARE TESTING
FINITE – STATE MACHINE
Software Structure
Software Behavior
Specification Of S/W Behavior
Table Driven Software
59 SAZ6C - SOFTWARE TESTING
STATE GRPAHS
STATES
INPUTS & TRANSITIONS
OUTPUTS
STATE TABLES
60 SAZ6C - SOFTWARE TESTING
DEFINITION OF STATE
STATE OF THE UNION
STATE OF HELATH
COMBINATION OF CIRCUMSTANCES OR ATTRIBUTES
61 SAZ6C - SOFTWARE TESTING
STATE DIAGRAM
• States are represented as nodes
• A point in a network or diagram at which lines or pathways
intersect or branch
.
Connection Point
Redistribution Point
Communication end point
62 SAZ6C - SOFTWARE TESTING
STATE DIAGRAM
A Path In A Graph Is Sequence Of Edges which Connect A Sequence
Of Vertices
A path may be infinite, but a finite path always has a FIRST VERTEX,
called its start vertex, and a last vertex, called its END VERTEX
63 SAZ6C - SOFTWARE TESTING
INPUT & TRANSITIONS
•
•Term denoting either an
entrance or changes which
are inserted into a system and
which activate or modify
a process
•The process or a period of
changing from one state or
condition to another
•A directed relationship
between two states.
64 SAZ6C - SOFTWARE TESTING
PARTS
Source State - current state before transition fires.
Event Trigger - external stimulus that has the potential to cause a transition
to fire.
Guard Condition - a condition that must be satisfied before a transition can
fire.
Action - an executable atomic computation.
Target State - new state after transition fires
65 SAZ6C - SOFTWARE TESTING
OUTPUT
Term denoting either an exit or changes which exit a system and which
activate/modify a process
An output can be associated with any link
Outputs are represented by either letters or numbers
•SUCCESS
•Input –
•Output -
•FAILURE
•Input -
•Output -
66 SAZ6C - SOFTWARE TESTING
EXAMPLE
67 SAZ6C - SOFTWARE TESTING
STATE TABLES
3 important states
1.INPUT
2.TRANSITIONS
3.OUTPUT
3 important concepts 1.Each row of the table corresponds to a state
2.Each column corresponds to an input condition
3.The box at the intersection of a row & column specifies the next state & the output
68 SAZ6C - SOFTWARE TESTING
GOOD STATE GRAPHS & BAD
PRINCIPLES
1. Total No.Of States = Product Of The Factors
2. Exactly 1 Transition specified exactly 1 state
3. Every Transition = 1 O/P Action Specified
4.Sequence of I/P Same State
69 SAZ6C - SOFTWARE TESTING
STATE TESTING
•IMPACT OF BUGS
•PRINCIPLES
•LIMITATIONS AND EXTENSIONS
•WHAT TO MODEL
•GETTING THE DATA
•TOOLS
70 SAZ6C - SOFTWARE TESTING