Csci565: Graph Theory for Testers

1 / 75

# Csci565: Graph Theory for Testers - PowerPoint PPT Presentation

Csci565: Graph Theory for Testers. Software testing techniques Spring 2009. Objectives. Discuss graph theory and white-box, black-box, conformance testing, etc. Graphs Degree of a node Incidence matrices Adjacency matrices Connectedness Condensation graph Directed graphs

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about 'Csci565: Graph Theory for Testers' - temima

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

### Csci565: Graph Theory for Testers

Software testing techniques

Spring 2009

Csci565: Theory and Practice of Software Testing

Objectives
• Discuss graph theory and white-box, black-box, conformance testing, etc.
• Graphs
• Degree of a node
• Incidence matrices
• Connectedness
• Condensation graph
• Directed graphs
• Paths and semi-paths
• Reach-ability matrix
• Strong components
• Model Based testing using
• Finite State Machines
• Petri nets
• Statecharts
• ..

Csci565: Theory and Practice of Software Testing

Graphs theory
• Graph theory?
• Has nothing to do with graph or graphics
• An area of math dealing with entities (nodes) and the connections (links) between the nodes

Csci565: Theory and Practice of Software Testing

Graph: formal definition
• A graph is an abstract mathematical structure defined from two sets:
• V={n1, n2,…nm} of nodes
• E={e1,e2,…em} of edges

Csci565: Theory and Practice of Software Testing

A graph with 7 nodes and 5 edges (undirected)

n2

n1

e1

e4

e2

n5

n4

n3

e3

e5

n7

n6

Csci565: Theory and Practice of Software Testing

Degree of a node
• The degree
• Refers to the number of edges that have a node as an endpoint , denoted by deg(n)
• Indicates the extent of integration testing that is appropriate for the object
• E.g. deg(n1) =2

Csci565: Theory and Practice of Software Testing

Incidence matrices
• Alternative to visual presentation of graph
• The incidence matrix of G=(V,E) with m nodes and n edges is an mn matrix
• We have 1 in row i, column J
• iff node i is an endpoint of edge j
• Row sum represents degree of nodes
• Column sum represents the endpoints of an edge

Csci565: Theory and Practice of Software Testing

Incidence matrices

Csci565: Theory and Practice of Software Testing

• A useful supplement to the incidence matrix
• The Adjacency matrix of G=(V,E) with m nodes and n edges is an mm matrix
• We have 1 in row i, and col. J iff
• there is an edge between node i and node j,
• zero otherwise
• Used to identify paths and hence equivalence relation to simplify a graph and hence testing

Csci565: Theory and Practice of Software Testing

Csci565: Theory and Practice of Software Testing

Paths
• A path is a sequence of edges such that, for any adjacent pair of edges ei, ej in the sequence, the edges share a common (node) endpoint
• Can be described as sequences of edges or nodes

Csci565: Theory and Practice of Software Testing

Connectedness
• Nodes ni and nj are connected iff they are in the same path
• Connectedness is an equivalence relation can be checked easily
• Reflexive(every node is in path of 0 length with itself)
• Symmetric n1, and 2 in same path, then n2 and n1 is also in the same path
• transitive

Csci565: Theory and Practice of Software Testing

Component and condensation graphs
• Connectedness defines a partition (or component) on the node set of a graph
• Components of a graph is maximal set of connected nodes
• E.g. Components
• S1={n1,n2,n3,n4,n5,n6} and S2={n7}
• Condensation graph
• Used as a Simplification mechanism
• Creating a graph by replacing a set of connected nodes (or components) by a condensing node
• The implication for testing is that component are stand alone elements and hence can be tested separately

Csci565: Theory and Practice of Software Testing

Directed graph

n2

n1

e1

e4

e2

n5

n4

n3

e3

e5

n7

n6

Csci565: Theory and Practice of Software Testing

Types of nodes
• source node: a node with in-degree zero
• Sink node: a node with out-degree=0
• Transfer node: node having in-degree =out-degree of nonzero

Csci565: Theory and Practice of Software Testing

Directed graph: The testing implication
• The implication for testing
• Initial node
• Terminal node
• Edges represents software concepts
• Sequential behaviors
• Control info
• Time-ordered events
• Define/uses concepts

Csci565: Theory and Practice of Software Testing

Adjacency matrix of a directed graph (AMD)
• The AMD of G=(V,E) with m nodes is an mm matrix where a(i,j) is a 1 iff there is an edge from node i to node j, otherwise it is 0
• Row sum represents outdegrees
• Column sum represents indegrees

Csci565: Theory and Practice of Software Testing

Csci565: Theory and Practice of Software Testing

Paths and semi-paths
• Direction is important therefore
• Directed path (a sequence of edges ei and ej, the terminal node of ei is the initial node of ej )
• Cycle (directed path that begins and ends at the same node)
• Directed semi-path (for adjacent pair of ei, the initial (terminal) node of the first edge is the initial (terminal) node of the second edge
• E.g., n1 and n3

Csci565: Theory and Practice of Software Testing

Reachability matrices for directed graph

Csci565: Theory and Practice of Software Testing

N-connectedness
• Connectedness of directed graph
• 0-connected (no path between ni, and nj)
• 1-connected (semi-path between ni, and nj )
• 2-connected(a path between ni, and nj )
• 3-connected (a path between ni to nj, and apath between nj, and ni)
• Strong components

Csci565: Theory and Practice of Software Testing

Directed graph

n2

n1

e1

e4

e2

n5

n4

n3

e3

n1 and n7 0-c

n2 and n4 1-c

n1 and n6 2-c

n3 and n6 3-c

e5

n7

e6

n6

Csci565: Theory and Practice of Software Testing

Graphs for testing
• Program graph or flowgraph ( code testing)
• Finite State machines (blackbox)
• A computational model consisting of a finite number of states and transitions between those states, possibly with accompanying actions
• Petri nets (blackbox)
• Sysetm behavior
• Statecharts (blackbox)
• System behavior
• Behavior diagrams specified as part of the Unified Modeling Language (UML).
• statechart depicts the states that a system or component can assume,
• shows the events or circumstances that cause or result from a change from one state to another.

Csci565: Theory and Practice of Software Testing

Graph theory and Model-Based testing
• Models
• A method (way) of representing the behavior of a system
• Simpler than the system they describe
• Help us to understand and predict the system’s behavior

Csci565: Theory and Practice of Software Testing

Life is too short for manual testing
• MBST?
• Black-box technique that can be used
• To construct the behavioral aspects of system early in the development lifecycle
• Exposes ambiguities in the specification and design of the software under construction
• Embodies behavioral information that can be reused in future testing, even when the specification change
• Easier to update than a suite of individual tests

Csci565: Theory and Practice of Software Testing

1. create model

The model-based testing process: Build or Borrow

requirements

model

6. Revise the model

RTM

Model Coverage

2. Generate abstract test cases

results

4. Run the SUT

Test cases

5. Analyze the result

Platform Independent Test cases

Platform Specific Test Cases

3. Generate concrete test cases

Test scripts

Test Result

Csci565: Theory and Practice of Software Testing

Modeling Maturity level
• Level 0: No specification
• Level 1: Textual (very informal)
• Level 2: Text with Diagram (textual spec is augmented by diagrams)
• Level 3: Models with text ( a set of well-defined diagrams/text)
• Level 4: Precise models (MDA)
• Level 5: Models only (model-to-code)

Csci565: Theory and Practice of Software Testing

Model-based testing experience reports
• IBM
• Used a model-based test generator known as GOTCHA-TCBeans to generate test cases from FSM models
• FSM model was created from English SPEC
• Microsoft
• At least three generation of model-based testing tools developed and used within Microsoft over the past few years
• TMT: TEST MODEL TOOLKIT (1ST ) developed by IE team and won the best testing practice award
• ASML/T AND SPEC EXPLORER by FSE found bugs in early versions of web services implementations

Csci565: Theory and Practice of Software Testing

Limitations with MBT
• No insurances to find all the differences between the model and its implementation
• Requires different skills from manual test design
• Model designers must be able to ABSTRACT and design models
• Works with functional testing and test maturity

Csci565: Theory and Practice of Software Testing

Modeling Method Guidance

Csci565: Theory and Practice of Software Testing

Examples of models
• a typical example of a model in computing is
• Finite state machine (or state graph)
• Petri Nets

tired

fresh

sleep

Csci565: Theory and Practice of Software Testing

Example: A Very Simple Finite State Model of the Clock

Csci565: Theory and Practice of Software Testing

Test cases
• We could use this very simple state model as a basis for tests, where following a path in the model is equivalent to running a test:
• Setup: Put the Clock into its Analog display mode
• Action: Click on “Settings\Digital”
• Outcome: Does the Clock correctly change to the Digital display?

Csci565: Theory and Practice of Software Testing

Actions
• the following actions in the Clock:
• Start the Clock application
• Stop the Clock application
• Select Analog setting
• Select Digital setting

Csci565: Theory and Practice of Software Testing

Operational modes
• Two modes of operations:
• system mode
• NOT_RUNNING means Clock is not running
• RUNNING means Clock is running
• setting mode
• ANALOG means Analog display is set
• DIGITAL means Digital display is set

Csci565: Theory and Practice of Software Testing

State Transition Diagram for the Clock Model

Csci565: Theory and Practice of Software Testing

Generate Sequences of Test Actions from the Model:1
• Generate Sequences of Test Actions from the Model
• Unusual (random) combination
• Start
• Analog
• Analog
• Analog
• Analog
• Analog
• Stop

Csci565: Theory and Practice of Software Testing

Petri Nets: Informal Definition
• Directed, weighted, bipartite graph
• places
• transitions
• arcs (places to transitions or transitions to places)
• weights associated with each arc
• Initial marking (assigns a non-negative integer to each place)

Csci565: Theory and Practice of Software Testing

Formal definition: Petri nets

T: transitions

F  {PT}  {TP})

W: F  N – {0}

Csci565: Theory and Practice of Software Testing

Petri Nets: Properties

Properties: (1) P  T = Ø (2) P  T  Ø (3)F  (P  T)  (T  P)

(4) W: F  N-{0}

//relate non-zero value to f

//default value of W is 1

State defined by marking: M: P  N

Csci565: Theory and Practice of Software Testing

Petri Nets (PN): Terminologies
• Input places
• Arrows go from places to transition
• Output places
• Arrows go from transitions to places
• Enabled Transition
• T is enabled if each of its input places contains token such that M(p’) ≥ W

Csci565: Theory and Practice of Software Testing

Transition (firing) rule
• A transition t is enabled if each input place ( or t) p has at least w(p,t) tokens
• An enabled transition may (or may not) fire
• A firing on an enabled transition t removes w(p,t) from each input place p, and adds w(t,p’) to each output place p’

Csci565: Theory and Practice of Software Testing

Formal Semantics
• Transition t is enabled iff
• pt‘s input places (i.e., t), M(p)  W()
• Firing of t
• produces a new marking M’ in places that are either t's input or output places or both
• if p =t (i.e. p is input place)
• M'(p) = M(p) - W()
• if p= t (i.e., p is output place)
• M'(p) = M(p) + W()
• if p= t t (i.e., p is both an input and an output place)
• M'(p) = M(p) - W() + W()

Csci565: Theory and Practice of Software Testing

Firing example

2H2 + O2 2H2O

2

MakeH2o

H2

2

H2O

O2

Csci565: Theory and Practice of Software Testing

Firing example

2H2 + O2 2H2O

2

MakeH2o

H2

2

H2O

O2

Csci565: Theory and Practice of Software Testing

Some typical interpretations of places
• Places represent
• Pre/post conditions
• Conditions/conclusions (in logical setting)
• Input signals/output signals
• Input data/output data
• Buffers
• Resources needed/released

Csci565: Theory and Practice of Software Testing

Some typical interpretations of transitions
• Transitions represent
• Actions
• Events
• Signal processor
• Clause in logic
• processor

Csci565: Theory and Practice of Software Testing

Vending

Machine

accept_coin

insert_coin (x)

reject_coin

give_snak

select_snak (X)

No_change_returned

Vending machine

Csci565: Theory and Practice of Software Testing

Vending Machine Requirements
• The machine dispenses only two snack bar products
• 20c
• 15c
• The machine accepts only two kinds of change
• 10c
• 5c
• The machine does not return any change

Csci565: Theory and Practice of Software Testing

Take 15c snack bar

15 cents

5 cents

Deposit 10c

Deposit 5c

Deposit 5c

0 cent

Deposit 5c

Deposit 5c

Deposit 10c

20 cents

10 cents

Deposit 10c

Take 20c snack bar

Vending Machine : FSM’s represntation

Csci565: Theory and Practice of Software Testing

Take 15c bar

Deposit 10c

15c

5c

Deposit 5c

Deposit 5c

Deposit

5c

Deposit

5c

0c

Deposit 10c

20c

10c

Deposit 10c

Take 20c bar

Vending Machine: PN’s version

Csci565: Theory and Practice of Software Testing

Vending Machine: Some Scenarios
• Scenario 1
• Deposit 5c, deposit 5c, deposit 5c, deposit 5c, take 20c snack bar
• Scenario 2
• Deposit 10c, deposit 5c, take 15c snack bar
• Scenario 3
• Deposit 5c, deposit 10c, deposit 5c, take 20c snack bar

Csci565: Theory and Practice of Software Testing

Modeling concurrency

t2

marked graph:

each place has

exactly one

incoming arc

and one

outgoing

arc.

t1

t4

t3

Csci565: Theory and Practice of Software Testing

Modeling concurrency

concurrency

t2

t1

t4

t3

Csci565: Theory and Practice of Software Testing

C1-arriving

C2-arriving

Take

order

Take

order

C1-waiting

cooking

C2-waiting

eating

eating

Get food

Serve food

Serve food

Csci565: Theory and Practice of Software Testing

Example: In a Restaurant (Two Scenarios)
• Scenario 1( sequential serving)
• Waiter takes order from customer 1
• serves customer 1
• takes order from customer 2
• serves customer 2
• Scenario 2 (Interleave serving)
• Waiter takes order from customer 1
• takes order from customer 2
• serves customer 2
• serves customer 1

Csci565: Theory and Practice of Software Testing

Waiter

free

Customer 1

Customer 2

Take

order

Take

order

wait

Order

taken

wait

eating

eating

Tell

kitchen

Serve food

Serve food

Example: In a Restaurant (Scenario 1)

Csci565: Theory and Practice of Software Testing

Waiter

free

Customer 1

Customer 2

Take

order

Take

order

wait

Order

taken

wait

eating

eating

Tell

kitchen

Serve food

Serve food

Example: In a Restaurant (Scenario 2)

Csci565: Theory and Practice of Software Testing

Modeling dataflow computation

Compute x = (a+b)/(a-b)

a

copy

+

/

X=(a+b)/(a-b)

R(a+b)

a

If (a-b)0

b

a-b

copy

-

R(a-b)

No-result

b

If (a-b)=0

Csci565: Theory and Practice of Software Testing

Problems with Petri nets
• Petri nets (Good)
• The ability of easily modeling concurrency
• synchronization aspects,
• the intuitive graphic notation,
• the formal semantics that supports powerful analysis capabilities and the availability of
• several supporting tools
• Not widely used in software engineering,

Csci565: Theory and Practice of Software Testing

UML

Csci565: Theory and Practice of Software Testing

Statecharts : A Visual Formalism for Complex Systems
• Origins Of Statecharts
• FSMs
• STDs
• HarelStatecharts
• Limitations of State Machines
• Doesn’t
• Provide State Hierarchy
• provide History Info.
• support Concurrent States

Csci565: Theory and Practice of Software Testing

Semantics of Statecharts
• State
• Event
• Transitions
• Event [Guard] / Action Transition

Csci565: Theory and Practice of Software Testing

Example for Statechart Semantics

Csci565: Theory and Practice of Software Testing

More features of Statecharts
• Generalization
• Simplifies by Factorization
• Orthogonality
• Simplifies by Segmentation
• History Info.
• To memorize the substate last visited

Csci565: Theory and Practice of Software Testing

Example for Generalization

Csci565: Theory and Practice of Software Testing

Example for Orthogonality

Csci565: Theory and Practice of Software Testing

Example for History state

Csci565: Theory and Practice of Software Testing

Importance of Testing Statecharts

Statecharts play crucial role in modeling

• Safety-critical systems
• Networking Protocols
• GUIs (Graphical User Interfaces)
• OOD (Object-Oriented Design)

Csci565: Theory and Practice of Software Testing

Methodology of Testing SCs

Csci565: Theory and Practice of Software Testing

Coverage Metrics
• State Coverage
• Ratio of number of states covered and total number of states in the given state model
• Event Coverage
• Ratio of number of events covered and total number of events in the given state model
• Transition Coverage
• Ratio of number transitions exercised and total number of transitions in the given state model
• State-Event Coverage
• Ratio of state-event pairs exercised and number of states multiply number of events in the given state model

Csci565: Theory and Practice of Software Testing

Statechart Spec. and Test Case’s Formats

Csci565: Theory and Practice of Software Testing

Acknowledgement/references
• Harry Robinson: Finite State Model-Based Testing on a Shoestring    (1999 Software Testing Analysis and Review West Conference )
• Petri nets and software engineering
• Practical Model-Based Testing by Mark Utting and Bruno Legeard, Morgan Kaufmann Publisher

Csci565: Theory and Practice of Software Testing

Any q u e s t i o n s?

Csci565: Theory and Practice of Software Testing