Software Verification Graph Model 2

2 Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases Specs Design Source Applied to DNF Specs FSMs Source Input Models Integ Source

Call Graph The most common graph for structural design testing Nodes : Units (in Java – methods) Edges : Calls to units Example call graph A BCD FE Node coverage : call every unit at least once (method coverage) Edge coverage : execute every call at least once (call coverage)

Overestimating the calls relation public class C { public static C cFactory(String kind) { if (kind == "C") return new C(); if (kind == "S") return new S(); return null; } void foo() { System.out.println("You called the parent's method"); } public static void main(String args[]) { (new A()).check(); } class S extends C { void foo() { System.out.println("You called the child's method"); } class A { void check() { C myC = C.cFactory("S"); myC.foo(); } The static call graph includes calls through dynamic bindings that never occur in execution. A.check() C.foo()S.foo()CcFactory(string)

Contex Insensitive Call graphs public class Context { public static void main(String args[]) { Context c = new Context(); c.foo(3); c.bar(17); } void foo(int n) { int[] myArray = new int[ n ]; depends( myArray, 2) ; } void bar(int n) { int[] myArray = new int[ n ]; depends( myArray, 16) ; } void depends( int[] a, int n ) { a[n] = 42; } main C.fooC.bar C.depends

Contex Sensitive Call graphs public class Context { public static void main(String args[]) { Context c = new Context(); c.foo(3); c.bar(17); } void foo(int n) { int[] myArray = new int[ n ]; depends( myArray, 2) ; } void bar(int n) { int[] myArray = new int[ n ]; depends( myArray, 16) ; } void depends( int[] a, int n ) { a[n] = 42; } main C.foo(3) C.bar(17) C.depends(int ( 3),a,2)

Context Sensitive CFG exponential growth A B D F H C E G I J 1 context A 2 contexts AB AC 4 contexts ABD ABE ACD ACE 8 contexts … 16 calling contexts …

Data Flow at the Design Level Caller : A unit that invokes another unit Callee : The unit that is called Callsite : Statement or node where the call appears Actual parameter : Variable in the caller Formal parameter : Variable in the callee

9 Example Call Site A  B (x)  end A B (Y)  end B Caller Actual Parameter Formal Parameter Callee interface Applying data flow criteria to def-use pairs between units is too expensive Too many possibilities But this is integration testing, and we really only care about the interface …

Inter-procedural DU Pairs If we focus on the interface, then we just need to consider the last definitions of variables before calls and returns and first uses inside units and after calls Last-def : The set of nodes that define a variable x and has a def-clear path from the node through a callsite to a use in the other unit –Can be from caller to callee (parameter or shared variable) or from callee to caller as a return value First-use : The set of nodes that have uses of a variable y and for which there is a def-clear and use-clear path from the callsite to the nodes

Example Inter-procedural DU Pairs FX = 14  y = G (x)  print (y) G (a) print (a)  b = 42  return (b) Caller Callee DU pair 11 B (int y) Z = yT = y print (y) Last Defs 2, 3 First Uses 11, 12 callsite first-use last-def x = 5 x = 4 x = 3 B (x)

© Ammann & Offutt 12 1 // Program to compute the quadratic root for two numbers 2 import java.lang.Math; 3 4 class Quadratic 5 { 6 private static float Root1, Root2; 7 8 public static void main (String[] argv) 9 { 10 int X, Y, Z; 11 boolean ok; 12 int controlFlag = Integer.parseInt (argv[0]); 13 if (controlFlag == 1) 14 { 15 X = Integer.parseInt (argv[1]); 16 Y = Integer.parseInt (argv[2]); 17 Z = Integer.parseInt (argv[3]); 18 } 19 else 20 { 21 X = 10; 22 Y = 9; 23 Z = 12; 24 } 25 ok = Root (X, Y, Z); 26 if (ok) 27 System.out.println 28 (“Quadratic: ” + Root1 + Root2); 29 else 30 System.out.println (“No Solution.”); 31 } // Three positive integers, finds quadratic root 34 private static boolean Root (int A, int B, int C) 35 { 36 float D; 37 boolean Result; 38 D = (float) Math.pow ((double)B, (double2-4.0)*A*C ); 39 if (D < 0.0) 40 { 41 Result = false; 42 return (Result); 43 } 44 Root1 = ( float ) ((-B + Math.sqr t(D))/(2.0*A)); 45 Root2 = ( float ) ((-B – Math.sqrt (D))/(2.0*A)); 46 Result = true; 47 return (Result); 48 } / /End method Root } // End class Quadratic Example – Quadratic

13 1 // Program to compute the quadratic root for two numbers 2 import java.lang.Math; 3 4 class Quadratic 5 { 6 private static float Root1, Root2; 7 8 public static void main (String[] argv) 9 { 10 int X, Y, Z; 11 boolean ok; 12 int controlFlag = Integer.parseInt (argv[0]); 13 if (controlFlag == 1) 14 { 15 X = Integer.parseInt (argv[1]); 16 Y = Integer.parseInt (argv[2]); 17 Z = Integer.parseInt (argv[3]); 18 } 19 else 20 { 21 X = 10; 22 Y = 9; 23 Z = 12; 24 } last-defs shared variables

14 25 ok = Root (X, Y, Z); 26 if (ok) 27 System.out.println 28 (“Quadratic: ” + Root1 + Root2); 29 else 30 System.out.println (“No Solution.”); 31 } // Three positive integers, finds the quadratic root 34 private static boolean Root (int A, int B, int C) 35 { 36 float D; 37 boolean Result; 38 D = (float) Math.pow ((double)B, (double2-4.0)*A*C); 39 if (D < 0.0) 40 { 41 Result = false; 42 return (Result); 43 } 44 Root1 = (float) ((-B + Math.sqrt(D)) / (2.0*A)); 45 Root2 = (float) ((-B – Math.sqrt(D)) / (2.0*A)); 46 Result = true; 47 return (Result); 48 } / /End method Root } // End class Quadratic last-deffirst-use last-defs

15 Quadratic – Coupling DU-pairs Pairs of locations: method name, variable name, statement (main (), X, 15) – (Root (), A, 38) (main (), Y, 16) – (Root (), B, 38) (main (), Z, 17) – (Root (), C, 38) (main (), X, 21) – (Root (), A, 38) (main (), Y, 22) – (Root (), B, 38) (main (), Z, 23) – (Root (), C, 38) (Root (), Root1, 44) – (main (), Root1, 28) (Root (), Root2, 45) – (main (), Root2, 28) (Root (), Result, 41) – ( main (), ok, 26 ) (Root (), Result, 46) – ( main (), ok, 26 )

16 Types of Def-Use Pairs def use A () intra-procedural data flow (within the same unit) def A() use B() A() B() F () object-oriented direct coupling data flow inter-procedural data flow def A () B () use last-def A () first-use B () full coupling object-oriented indirect coupling data flow def A() use B() M () N() F() A() M() B() N()

Example of Control Flow Graph public static String collapseNewlines(String argStr) { char last = argStr.charAt(0); StringBuffer argBuf = new StringBuffer(); for (int cIdx = 0 ; cIdx < argStr.length(); cIdx++) { char ch = argStr.charAt(cIdx); if (ch != '\n' || last != '\n') { argBuf.append(ch); last = ch; } return argBuf.toString(); }

File ADT Example class FileADT has three methods: open (String fName) // Opens file with name fName close () // Closes the file and makes it unavailable write (String textLine ) // Writes a line of text to the file Valid sequencing constraints on FileADT: 1.An open (f) must be executed before every write (t) 2.An open (f) must be executed before every close () 3.A write (f) may not be executed after a close () unless there is an open (f) in between 4.A write (t) should be executed before every close () s1s1 s2s2 s3s3 s4s4 s5s5 s6s6 open (f) write(t) close ()

Static Checking Is there a path to a write() that does not go through an open() ? Is there a path to a close() that does not go through an open() ? Is there a path from a close() to a write()? Is there a path from an open() to a close() that does not go through a write() ? (“write- clear” path) s1s1 s2s2 s3s3 s4s4 s5s5 s6s6 open (f) write(t) close () Is there a path that violates any of the sequencing constraints ? [ 1, 3, 4, 6 ] – ADT use anomaly!

Static Checking close () s1s1 s2s2 s3s3 s4s4 s5s5 s8s8 open (f) write (t) s6s6 s7s7 close () Consider the following graph : [ 7, 3, 4 ] – close () before write () !

Inheritance & Polymorphism Caution : Ideas are preliminary and not widely used Example inheritance hierarchy graph A B C D Classes are not executable, so this graph is not directly testable We need objects A B C D a b d c objects What is coverage on this graph ?

Coverage on Inheritance Graph Create an object for each class ? This seems weak because there is no execution Create an object for each class and apply call coverage? OO Call Coverage : TR contains each reachable node in the call graph of an object instantiated for each class in the class hierarchy. OO Object Call Coverage : TR contains each reachable node in the call graph of every object instantiated for each class in the class hierarchy. Data flow is probably more appropriate …

© Ammann and Offutt Class 4 Access Control (in Java) Class 1 inheritance Class 3Class 2 Package Class 5 private membersdefaultprotected memberspublic members

24 Additional Definitions Inheritance : If class B inherits from class A, then all variables and methods in A are implicitly in B, and B can add more –A is the parent or ancestor –B is the child or descendent An object reference obj that is declared to be of type A can be assigned an object of either type A, B, or any of B’s descendents –Declared type : The type used in the declaration: A obj; –Actual type : The type used in the object assignment: obj = new B(); Class (State) Variables : The variables declared at the class level, often private

Polymorphism The same variable can have different types depending on the program execution If B inherits from A, then an object of type B can be used when an object of type A is expected If both A and B define the same method M (B overrides A), then the same statement might call either A’s version of M or B’s version

Testing OO Software 1.Intra-method testing : Testing individual methods within classes 2.Inter-method testing : Multiple methods within a class are tested in concert 3.Intra-class testing : Testing a single class, usually using sequences of calls to methods within the class 4.Inter-class testing : More than one class is tested at the same time (integration)

Example DU Pairs and Anomalies B +h () +i () -x A -u -v -w +h() +i() +j() +l() C +i () +j () -y MethodDefs Uses A::h (){A::u, A::w} A::i (){A::u} A::j (){A::v}{A::w} A::l(){A::v} B::h(){B::x} B::i(){B::x} C::i() C::j(){C::y} Consider what happens when an overriding method has a different def-set than the overridden method def-use DU anomaly DU anomaly A::h() calls j(), B::h() does not

Polymorphism Headaches (Yo-Yo) A +d () +g () +h () +i () +j () +l () Actual type B k() h()i() C j()i()l() A d()j()g()h()i()l() Object is of actual type A A::d ()

29 Polymorphism Headaches (Yo-Yo) A +d () +g () +h () +i () +j () +l () B +h () +i () +k () B h()i()k() Actual type B k() h()i() C j()i()l() A d()j()g()h()i()l() C j()i()l() A d()j()g()h()i()l() Object is of actual type B B::d ()

30 Polymorphism Headaches (Yo-Yo) A +d () +g () +h () +i () +j () +l () B +h () +i () +k () C +i () +j () +l () C j()i()l() B h()i()k() Actual type B k() h()i() C j()i()l() A d()j()g()h()i()l() C j()i()l() A d()j()g()h()i()l() B h()i() k() A d()j()g()h()i()l() Object is of actual type C, C::d ()

31 OO Faults and Anomalies AcronymFault / Anomaly ITUInconsistent Type Use SDAState Definition Anomaly SDIHState Definition Inconsistency SDIState Defined Incorrectly IISDIndirect Inconsistent State Definition ACB1Anomalous Construction Behavior (1) ACB2Anomalous Construction Behavior (2) ICIncomplete Construction SVAState Visibility Anomaly

32 Inconsistent Type Use (ITU) No overriding (no polymorphism) C extends T, and C adds new methods (extension) An object is used “as a C”, then as a T, then as a C Methods in T can put object in state that is inconsistent for C Vector -array +insertElementAt() +removeElementAt() Stack +pop (): Object +push (): Object call // Stack is empty! s.push (“Steffi”); s.push (“Joyce”); s.push (“Andrew”); dumb (s); s.pop(); void dumb (Vector v) { v.removeElementAt (v.size()-1); }

33 State Definition Anomaly (SDA) X extends W, and X overrides some methods The overriding methods in X fail to define some variables that the overridden methods in W defined W v u m() n() X x n() Y w m() W::m () defines v and W::n() uses v X::n () uses v Y::m () does not define v For an object of actual type Y, a data flow anomaly exists and results in a fault if m() is called, then n()

34 State Definition Inconsistency (SDIH) Hiding a variable, possibly accidentally If the descendant’s version of the variable is defined, the ancestor’s version may not be W v u m() n() X x n() Y v m() Y overrides W’s version of v Y::m() defines Y::v X::n() uses v … getting W’s version of v For an object of type Y, a data flow inconsistency may exist and result in a fault if m() is called, then n() overrides (hides)

35 Anomalous Construction Behavior (ACB1) Constructor of W calls a method f() A child of W, X, overrides f() X::f() uses variables that should be defined by X’s constructor W W() f() X x f() Calls Uses Overrides When an object of type X is constructed, W() is run before X(). When W() calls X::f(), x is used, but has not yet been given a value!

36 State Visibility Anomaly (SVA) A private variable v is declared in ancestor W, and v is defined by W::m() X extends W and Y extends X Y overrides m(), and calls W::m() to define v W -v m() X Y Overrides, calls W -v m() X Y Overrides, calls Overrides X::m() is added later Y:m() can no longer call W::m()!

37 Testing Goals We want to test how a method can interact with instance bound to object o: –Interactions occur through the coupling sequences Need to consider the set of interactions that can occur: –What types can be bound to o? –Which methods can actually execute? (polymorphic call sets) Test all couplings with all type bindings possible

38 Web Applications and Other Distributed Software distributed software data flow use B() P1 def A() message P2 “message” could be HTTP, RMI, or other mechanism A() and B() could be in the same class or accessing a persistent variable such as in a web session Beyond current technologies

Topics 1. UML test 2. Web site test 3. Portal test 4. Flowchart test 5. Documentation test 6. Security test