SAZ6C SOFTWARE TESTING Unit : I - V€¦UNIT I - SYLLABUS ¾ Introduction ¾ Purpose ¾ Productivity and Quality in Software ¾ Testing Vs Debugging ¾ Model for Testing ¾ Bugs ¾

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.


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


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.


Goals for testing

Primary goal: Bug prevention

Secondary goal: Bug discovery

A bug is manifested in deviations from expected behavior.


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


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.


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


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.


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


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


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.


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


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


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.


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


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.


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.


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)


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


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.


Achievable Paths

Predicates

Predicate Expressions

Predicate Coverage

Testing Blindness


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.


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.


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


Path Instrumentation

Topics

Link Markers

Link Counters

Other Instrumentation Methods

Implementation


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.


TRANSACTION FLOW TECHNIQUES

Transaction flow testing techniques

The following link explains the testing techniques


http://slideplayer.com/slide/8031164/

UNIT III - SYLLABUS

Data-Flow testing Strategies Terminology

The Strategies

Slicing, Dicing, Data Flow, and Debugging


Data-Flow testing Strategies

Data-Flow testing strategies are based on selecting test path

segments also called sub paths.

Stronger path

Weaker path


Terminology

A definition-clear path segment

A loop-free path segment

A simple path segment

A du path


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


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.


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


http://slideplayer.com/slide/6675102/

Domain Testing

Domains & Interface Testing

• Domain

• Range Function /

Routine Classify


Domain Testing –

Interface Range/Domain Compatibility Testing

• Test each vary independently

• Find an inverse function

• Build a super domain


Domain Testing


Views Programs as input data classifiers

Verifies if the classification is correct

Domain Testing - Domains & Paths Domain Testing Model


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


Domains and Range

Closure Compatibility

Span Compatibility


Finding the values



• Test each vary independently

• Find an inverse function

• Build a super domain


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


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


COUNT AND NOT COUNT?


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.


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.


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


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


General

Cyclamates Complexity(McCabe’s Metric)

Other structural Metrics


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)


https://www.youtube.com/watch?v=wM2Cb-1XY-Y

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


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


https://www.youtube.com/watch?v=73-GzQO9lDE

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


UNIT V - SYLLABUS

•Decision tables and Transition Testing

•States

• State graphs & Transition

• State Testing


1. DECISION TABLES 2. TRANSITION TESTING

Decision tables and Transition Testing


The following link explain the decision tables and transition testing

https://www.youtube.com/watch?v=ED2iJXkdhCQ

https://www.youtube.com/watch?v=iQwn_jBQ39k

INTRODUCTION

STATE GRPAH

STATE TABLE

FINITE – STATE MACHINE


FINITE – STATE MACHINE

Software Structure

Software Behavior

Specification Of S/W Behavior

Table Driven Software


STATE GRPAHS

STATES

INPUTS & TRANSITIONS

OUTPUTS

STATE TABLES


DEFINITION OF STATE

STATE OF THE UNION

STATE OF HELATH

COMBINATION OF CIRCUMSTANCES OR ATTRIBUTES


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


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


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.


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


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 -


EXAMPLE


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


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


STATE TESTING

•IMPACT OF BUGS

•PRINCIPLES

•LIMITATIONS AND EXTENSIONS

•WHAT TO MODEL

•GETTING THE DATA

•TOOLS


Documents

SAZ6C SOFTWARE TESTING Unit : I - V€¦UNIT I - SYLLABUS ¾ Introduction ¾ Purpose ¾ Productivity and Quality in Software ¾ Testing Vs Debugging ¾ Model for Testing ¾ Bugs ¾