Csi565: Graph Theory for Testers

1. Csi565: Graph Theory for Testers Software testing techniques Spring 2012 Csci565: Theory and Practice of Software Testing

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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 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

8. Incidence matrices Csci565: Theory and Practice of Software Testing

9. Adjacency matrices • A useful supplement to the incidence matrix • The incidence matrix of G=(V,E) with m nodes and n edges is an mm 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

10. adjacency matrices Csci565: Theory and Practice of Software Testing

11. 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

12. 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

13. 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

14. Directed graph n2 n1 e1 e4 e2 n5 n4 n3 e3 e5 n7 n6 Csci565: Theory and Practice of Software Testing

15. 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

16. 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 nito node nj, otherwise it is 0 • Row sum represents outdegrees • Column sum represents indegrees Csci565: Theory and Practice of Software Testing

17. adjacency matrices for directed graph Csci565: Theory and Practice of Software Testing

18. 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

19. Reachability matrices for directed graph Csci565: Theory and Practice of Software Testing

20. 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

21. 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

22. 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

23. 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

24. Csci565: Theory and Practice of Software Testing

25. Modeling Method Guidance Csci565: Theory and Practice of Software Testing

26. 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

27. 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

28. 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”

29. 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

30. 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

31. 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

32. Example: A Very Simple Finite State Model of the Clock Csci565: Theory and Practice of Software Testing

33. 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

34. 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

35. 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

36. 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

37. State Transition Diagram for the Clock Model Csci565: Theory and Practice of Software Testing

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. Formal Semantics • Transition t is enabled iff • pt‘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

46. Firing example 2H2 + O2 2H2O 2 MakeH2o H2 2 H2O O2 Csci565: Theory and Practice of Software Testing

47. Firing example 2H2 + O2 2H2O 2 MakeH2o H2 2 H2O O2 Csci565: Theory and Practice of Software Testing

48. 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

49. 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

50. 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