1 / 89

890 likes | 1.06k Vues

Csi565: Graph Theory for Testers. Software testing techniques Spring 2012. Objectives. Discuss graph theory and whitebox testing Graphs Degree of a node Incidence matrices Adjacency matrices Connectedness Condensation graph Directed graphs Paths and semi-paths Reachability matrix

Télécharger la présentation
## Csi565: Graph Theory for Testers

**An Image/Link below is provided (as is) to download presentation**
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.
Content is provided to you AS IS for your information and personal use only.
Download presentation by click this link.
While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

**Csi565: Graph Theory for Testers**Software testing techniques Spring 2012 Csci565: Theory and Practice of Software Testing**Objectives**• Discuss graph theory and whitebox testing • Graphs • Degree of a node • Incidence matrices • Adjacency matrices • Connectedness • Condensation graph • Directed graphs • Paths and semi-paths • Reachability matrix • Strong components • Finite State Machines • Petri nets 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**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 mn matrix • We have 1 in row i, column J • iff node i is an endpoint of j • Row sum represents degree of nodes • Column sum represents the endpoints of an edge • Every edge MUST have two endpoints Csci565: Theory and Practice of Software Testing**Incidence matrices**Csci565: Theory and Practice of Software Testing**Adjacency matrices**• A useful supplement to the incidence matrix • The incidence matrix of G=(V,E) with m nodes and n edges is an mm matrix • We have 1 in row i, and colum J • iff there is an edge between node i and node j, zero otherwise Csci565: Theory and Practice of Software Testing**adjacency matrices**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 • A path can also 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 • Connectness is an equivalence relation can be checked easily • Reflexive • Symmetric • transitive Csci565: Theory and Practice of Software Testing**Component and condensation graphs**• Component of a graph is maximal set of connected nodes • E.g. • {n1,n2,n3,n4,n5,n6} and {n7} • Condensation graph • Creating a graph by replacing each component 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**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 • Loop • … 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 mm matrix where a(i,j) is a 1 • iff there is an edge from node nito node nj, otherwise it is 0 • Row sum represents outdegrees • Column sum represents indegrees Csci565: Theory and Practice of Software Testing**adjacency matrices for directed graph**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 ( loop:a path between ni to nj, and apath between nj, and ni) Csci565: Theory and Practice of Software Testing**Directed graph**n2 n1 e1 e4 e2 n5 n4 n3 e3 n1 and 7 0c n2 and n6 1c n1 and n6 2c n3 and n6 3c 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) • Mathematical model used to specify and verify concurrent/distributed systems • Statecharts (blackbox) • 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**• Model Based testing? • Refers to the automation of the design of black-box tests • 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 behaviors Csci565: Theory and Practice of Software Testing**Modeling Method Guidance**Csci565: Theory and Practice of Software Testing**Model-Based testing: Maturity level**• The CMM (Capability Maturity Model) for software its newer form CMMI (Capability Maturity Model Integration) for software Eng are well established methods for maturing and improving the maturity of the software companies Csci565: Theory and Practice of Software Testing**CMMI: levels**• The CMM identify five maturity levels: • Level 1: Ah hoc and chaotic processes • Level 2: Managed: requirements are managed, and process are planned and measured • Level 3: Processes are standardized across the organization and customized for each project • Level 4 (Quantitatively managed): Process are measured and controlled using statistic • Level 5: Optimizing where processes are continually improved Csci565: Theory and Practice of Software Testing**Testing maturity Level**• A muter test process is an important condition for adopting MBT • there have been many proposal for process improvement models for testing • Testing Maturity Model by Illinois Institute of Tech • Test Process Improvement (TPI) from Sogeti • Level 0 to 13 • E.g., level 7 requires “Managed test automation”**UML/OCL and MDA**• UML/OCL and MDA (model-driven archieture) has identified six levels of modelling maturity for UML models • Level 0, No spec • Level 1, textual • Level 2, Text with Diagrams • Level 3, Models with Text • Level 4, Precise Models • Level 5 Models only (model-to-code generation) Csci565: Theory and Practice of Software Testing**MBT experience Report**• Model-based testing at IBM • Reports significant cost reductions as well as good fault-finding capability in two industrial case studies • Generate test cases from FSM • Used TCTranslator to translate the abstract tests into C and Java test scripts • Model-based testing at Microsoft • Test Model Toolkit (TMT), ASML/T, Spec Explore 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) 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**Use model to Generate 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: • Startthe Clock application • Stopthe Clock application • Select Analog setting • Select Digital setting Csci565: Theory and Practice of Software Testing**The rules for actions**• The rules for these actions in the Clock application are as follows: • Start • If the application is NOT running, the user can execute the Start command. • If the application is running, the user cannot execute the Startcommand. • After the Start command executes, the application is running. • Stop • If the application is NOT running, the user cannot execute the Stop command. • If the application is running, the user can execute the Stop command. • After the Stop command executes, the application is not running. • Analog • If the application is NOT running, the user cannot execute the Analog command. • If the application is running, the user can execute the Analog command. • After the Analog command executes, the application is in Analog display mode. • Digital • If the application is NOT running, the user cannot execute the Digital command. • If the application is running, the user can execute the Digital command. • After the Digital command executes, the application is in Digital display mode. 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**What is model-based software testing (MBST)?**• 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 changes • Easier to update than a suite of individual tests 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**A quadruple (P,T,F,W) P: places; 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<f> 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 • pt‘s input places (i.e., t), M(p) W(<p,t>) • 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(<p,t>) • if p= t (i.e., p is output place) • M'(p) = M(p) + W(<t,p>) • if p= t t (i.e., p is both an input and an output place) • M'(p) = M(p) - W(<p,t>) + W(<t,p>) 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 • Task or job • 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

More Related