1 / 75

Csci565: Graph Theory for Testers

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

temima
Télécharger la présentation

Csci565: 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

Presentation Transcript


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

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

  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 (undirected) 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 edge j • Row sum represents degree of nodes • Column sum represents the endpoints of an edge 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 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

  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 • Can 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 • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

  26. Csci565: Theory and Practice of Software Testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  45. Firing example 2H2 + O2 2H2O 2 MakeH2o H2 2 H2O O2 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. 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

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

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

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

More Related