Theory and Practice of Co-verification Process: UniTesK Story - PowerPoint PPT Presentation

About This Presentation
Title:

Theory and Practice of Co-verification Process: UniTesK Story

Description:

Theory and Practice of. Co-verification Process: UniTesK Story. RedVerst group of ISP RAS ... loss caused by inadequate testing infrastructure for US economy1 ... – PowerPoint PPT presentation

Number of Views:32
Avg rating:3.0/5.0
Slides: 102
Provided by: victorvk
Category:

less

Transcript and Presenter's Notes

Title: Theory and Practice of Co-verification Process: UniTesK Story


1
Theory and Practice ofCo-verification Process
UniTesK Story
  • RedVerst group of ISP RAS
  • http//www.ispras.ru/groups/rv/rv.html
  • Alexander K. Petrenko (petrenko_at_ispras.ru)
  • Victor V. Kuliamin (kuliamin_at_ispras.ru)

2
Overview
  • Introduction Why co-verification?slides 3-13
  • Main part What is UniTesK?Solving Engineering
    Problemsslides 14-55
  • Case studiesslides 56-64

3
What do these numbers mean?
9 1
180 ?109 21 ?109
total revenue of US software development companies loss caused by inadequate testing infrastructure for US economy1
  • The Economic Impacts of Inadequate Infrastructure
    for Software Testing,
  • NIST Report, May 2002

4
Waterflow Process Model
Requirements
Design
Implementation
Testing
Deployment
5
Iterative Process Model
Requirements
Design
Implementation
Testing
Deployment
6
Race for Quality CMM Certified Organizations
According to Compiled List of Organizations
Publicly Announced their Maturity
Levels, http//seir.sei.cmu.edu/pml/
7
Race for Flexibility Agile Development Methods
Percent of organizations using modern development
processes
According to The Decision is in Agile versus
Heavy Methodologies by Robert Charette, Cutter
IT Journal, vol. 2, No. 19 http//www.cutter.com/f
reestuff/apmupdate.html
8
Need for Quick Change Response
Percent of organizations recognizing more than
50 of projects as agile
According to The Decision is in Agile versus
Heavy Methodologies by Robert Charette, Cutter
IT Journal, vol. 2, No. 19 http//www.cutter.com/f
reestuff/apmupdate.html
9
Inadequate Quality of Software
Loss Potential Cost Reduction Total Sales
Software Vendors 21.2?109 10.6?109 180?109
Software Users 38.3?109 11.7?109
Total 59.5?109 22.2?109
The Economic Impacts of Inadequate Infrastructure
for Software Testing, NIST Report, May 2002
10
Evolution of Testing
  • Localization of errors
  • Demonstration of errors
  • Testing is the process of executing a program or
    system with the intent of finding errors Myers,
    1979
  • The purpose of testing is to show that a program
    has bugs Hetzel, 1988
  • Evaluation of quality
  • Testing is the process of operating a system or
    component under specified conditions, observing
    or recording the results, and making an
    evaluation of some aspect of the system or
    component IEEE 90

11
Co-verification
  • Verification confirms that activity products
    properly reflect the requirements specified for
    them at the beginning of the activity.
  • Co-verification process
  • Perform verification of activity before
    proceeding to the dependent activities
  • Prepare all the artifacts needed for verification
    concurrently with main activity products

12
Traditional Development Process
Business Modeling
Deployment
Requirements
Integration
Architecture Design
Implementation
Component Design
13
Co-verification Development Process
Business Modeling
Deployment
Requirements
Integration
Architecture Design
Implementation
Component Design
14
Main Part Overview
  • Traditional approaches to verification
  • UniTesK approach
  • Example

15
Traditional Software Development Process
Design and development Verification
  • Requirements Analysis
  • Design
  • Implementation and debugging
  • Requirements Elicitation
  • Test Case Design
  • Test Implementation
  • Test Execution
  • Test Result Analysis

16
Co-verification Process
Design and development Verification
  • Requirements Analysis
  • Design
  • Implementation and debugging
  • Requirements Elicitation
  • Test Case Design
  • Test Implementation
  • Test Execution
  • Test Result Analysis

17
UniTesK Approach
UniTesK
Tools
.N_at_T
J_at_T
CTesK
VDMTesK
Uniform Test Architecture
Uniform Specification Extension
Integration with Development Environments
Foundations
Model Based Testing
18
Requirements Formalization
Requirements
Formal Specifications
19
Co-verification Support
Formal Specifications
Requirements
Ambiguity? Incompleteness?
Inconsistency?
20
Engineering Problems (1)
  • Specification technique should support
  • Easy transformation of requirements into
    specifications
  • Easy automation of further test development
  • Functional test coverage definition
  • High reusability of specifications
  • Specification notation should not require special
    education and skills

21
Specification Techniques
  • ExecutableImperative state based specifications
  • ConstraintsState based data type constraints,
    pre- and postconditions, internal invariants
  • AxiomaticAction based axioms

22
Comparison of Specification Techniques
23
Comparison Results
24
Specification Notation
  • Specification language
  • Suitable for capture abstract properties
  • Has formal semantics
  • Requires complex mediator layer for
    implementation
  • Requires special education, mastering is enduring
  • Extension of programming language
  • Abstract concepts can be added by libraries
  • Ambiguous parts of language can be excluded
  • Complex mediators are not required
  • Mastering can be made more effective
  • Facilitates co-verification

25
UniTesK Specification Technique
  • Uniform Specification Extension
  • Constraint Specifications
  • Preconditions and postconditions of operations
  • Data type constraints
  • Functional coverage description based on
    specification structure

26
UniTesK Specification Technique
  • Constraint Specifications
  • Preconditions and postconditions of operations
  • Data type constraints

specification Operation() pre block, returning
Boolean value post block, returning Boolean
value use _at_ to refer to pre-value of expressions
invariant Inv() block, returning Boolean value
27
J_at_va Specification Extension of Java
  • specification package pqueue
  • public class PQueueSpecification
  • specification public void enq(Object obj, int
    prty)
  • reads obj, prty
  • updates items.?, priorities.?
  • pre return obj ! null
  • post
  • int i 0
  • for(i 0
  • i lt items.size()
  • priorities.elementAt(i) gt prty
  • i
  • )
  • ...

28
Coverage Goals Definition
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- ----------------------
------------------------
---------------------------------------------
------------------------------------------------
-- ---- --------------------------
-----------
Requirements
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- -----------------------
-----------------------
----------------------------------------------
-----------------------------------------------
--- ---- ------------------------------
-------
Test Case 1 --------------- --------------- ------
--
1
2
3
29
Co-verification Support
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- ----------------------
------------------------
---------------------------------------------
------------------------------------------------
-- ---- --------------------------
-----------
UniTesK supports this transformation with
techniques and tools
Testable Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- -----------------------
-----------------------
----------------------------------------------
-----------------------------------------------
--- ---- ------------------------------
-------
Software -----------------------------------
---------------- ----------------------------
----------------------- ---------------------
------------------------------
--------------------------------------------------
- -------------------------------------------
-------- ------------------------------------
--------------- -----------------------------
---------------------- ----------------------
-----------------------------
--------------------------------------------------
-
30
Engineering Problems (2)
  • Automatic extraction of coverage goals from the
    specification structure
  • More than one coverage metric is needed
  • Test designer should be able to introduce
    additional goals

31
Several Levels of Coverage Metrics
1.2.1 1.2.2
1.1 1.2 1.3
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- -----------------------
-----------------------
----------------------------------------------
-----------------------------------------------
--- ---- ------------------------------
-------
1.3.1 1.3.2 1.3.3
1
2
2.1 2.2
3
3.1.1 3.1.2 3.1.3
3.1 3.2
32
Definition of Coverage Goals Functionality
Branches
  • Functional coverage description based on
    specification structure

post if(a b) ... branch Case 1 ...
else if(!c d) ... branch Case 2 ... else
... branch Case 3 ...
Branches Disjuncts
Case 1 a
Case 1 !a ? b
Case 2 !a ? !b ? !c ? d
Case 3 !a ? !b ? c
Case 3 !a ? !b ? !c ? !d
33
Definition of Additional Coverage Goals Marked
Paths
post if(a b c)
if(a) mark a holds
branch Case 1 ...
Branches Marked Paths Disjuncts
Case 1 a holds Case 1 a
Case 1 Case 1 !a ? b
Case 1 Case 1 !a ? !b ? c
34
Test Implementation
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- -----------------------
-----------------------
----------------------------------------------
-----------------------------------------------
--- ---- ------------------------------
-------
Test Case 1 --------------- --------------- ------
--
Test Program
Test Scenario
35
Co-verification Support
Formal Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- ----------------------
------------------------
---------------------------------------------
------------------------------------------------
-- ---- --------------------------
-----------
Testable Specifications pre
--------------------------- post
---------------------------
--------------------------------------------------
--------------------------------------
-------- ------------ ----------------------
--------------- -----------------------
-----------------------
----------------------------------------------
-----------------------------------------------
--- ---- ------------------------------
-------
UniTesK supports this transformations with
techniques and tools
Software -----------------------------------
---------------- ----------------------------
----------------------- ---------------------
------------------------------
--------------------------------------------------
- -------------------------------------------
-------- ------------------------------------
--------------- -----------------------------
---------------------- ----------------------
-----------------------------
--------------------------------------------------
-
Test Scenario
36
Engineering Problems (3)
  • Test construction technique should ensure
    coverage goals achievement
  • Test designer should be able to introduce
    additional tests
  • Tests should be decoupled with implementation

37
Overview of UniTesK Approach to Test
Implementation
  • Test construction technique traversal of FSM
  • FSM is constructed in so far that its traversal
    ensures coverage
  • FSM represented implicitly as test scenario
  • Implicit representation saves a lot of work
  • Test scenarios can be
  • Generated on the base of templates and
    specifications
  • Developed manually
  • Developed in mixed way
  • Mediators are used to decouple test scenarios and
    implementation
  • The same three ways to develop mediators

38
UniTesK Test Architecture
  • From specification we can generate oracle to
    check the conformance of system behavior
  • The entire test is constructed as a test sequence
    intended to achieve some coverage
  • Test sequence required is produced on-the-fly
    during test execution as a transition tour of FSM
    model

39
UniTesK Test Architecture
Test sequence construction
Test Engine
Test Action Iterator
Oracle
Specification
Target system
40
Test Sequence Construction
Test Engine
Executes
Describes
Test Action Iterator
41
Engineering Problems FSM Construction (4)
  • Implicit specifications are hard to resolve
  • Nondeterminism
  • Huge numbers of states and transitions

42
Factorization Based on Coverage Goals
Helps to cope with state explosion and
nondeterminism
I. B. Bourdonov, A. S. Kossatchev, V. V.
Kuliamin. Using Finite State Machines in Program
Testing. Programming and Computer Software, Vol.
26, No. 2, 2000, pp. 61-73
43
Implicit State Machine Description
Allows not to resolve implicit constraints Makes
factorization easier
44
State Machine Construction Based on Coverage Goals
operation domain defined by precondition
parameters
2
3
coverage goals
1
states
resulting implicit FSM description
45
Test Sequence Construction for Implicit FSM
Test Engine
Executes and obtains the complete structure
Test Action Iterator
46
Test Scenario
Test sequence construction
Test Engine
Test Action Iterator
Test Scenario
Oracle
Specification
Target system
47
Using Nondeterministic FSMs Bounded Queue
add
Empty
Empty
empty
Single element
Single element
Intermediate
Intermediate
Almost full
Almost full
fill
Full
Full
remove
48
Testing Concurrency
  • Fair Concurrency Axiom Concurrent execution of
    several operations is correct if and only if it
    is equivalent to somehow ordered one
  • So, to test the concurrent execution of calls we
    should check that it behaves like some sequence
    of the same calls
  • The system can be modeled as an ordinary FSM
  • Test engine generates pairs, triples, and so on,
    of concurrent actions
  • System not satisfying Fair Concurrency Axiom
    should be modeled as asynchronous FSM

49
Asynchronous FSM
  • Some transitions are fired by a stimulus
  • Some transitions are fired along with a reaction
  • Some transitions are empty, modeling internal
    operation

/y
b/
/x
a/
a/
b/
Possible behavior input aba ouput
yyx xxyxyyyx
xyyyxy all possible outputs
xyxyyx, xyxyyxxyyx, xyyxxyyx
/y
/x
50
Co-verification Support Changes
Interface changed
???
Software -----------------------------------
-------- ------------------------------------
------- -------------------------------------
------ --------------------------------------
---
51
Engineering Problems (5)
  • Tests and implementation should be decoupled
  • Tests can be reused many times
  • Easy regression testing
  • Specification should be as abstract as possible
  • Specification should be even more reusable than
    tests

52
Mediator
  • Mediator decouples specification and
    implementation

Target system
53
Mediator Construction
Test Engine
Test Action Iterator
Test Scenario
Oracle
Specification
Mediator
Mediator in Extended Language
Target system
54
Open State Testing
  • Mediator constructs new model state only on the
    base of new implementation state
  • Requires Implementation state should be
    accessible by public fields or reliable observers
  • Implies Current model state actually corresponds
    to implementation one
  • Detected failure demonstrates a fault in the last
    operation
  • Transition tour is sufficient to ensure
    reliability

Mediator
Target system
call
call
response
get state data
state data
construct new model state
55
Hidden State Testing
  • Mediator constructs new model state on the base
    of old one and implementation call results
  • Implies Current model state is actually a
    hypothesis
  • Detected failure can be manifestation of a fault
    in any previously called operation
  • Transition tour is insufficient to ensure
    reliability

Mediator
Target system
call
call
response
construct new model state
56
UniTesK Practice Overview
  • UniTesK tools
  • UniTesK history
  • Training courses
  • QUTILUI project
  • Other case studies

57
UniTesK Tools
  • J_at_T
  • CTesK
  • VDMTesK
  • .N_at_T

58
UniTesK History
  • pre-UniTesK
  • 1994 1996ISP RAS Nortel Networks contract
    onfunctional test suite development for Switch
    Operating System kernel
  • Hundreds of bugs found in the OS kernel, which
    had been 10 years in use
  • About 600K lines of Nortel code tested by
    2000But failed to be introduced in Nortel
    processes

59
UniTesK Tools History
  • 2000
  • Conception
  • 2001
  • J_at_T Prototype
  • CTesK Lite
  • 2002
  • VDM TesK
  • J_at_T Product
  • 2003
  • J_at_T 1.2
  • CTesK Full
  • .N_at_T

60
Sqrt Specification in J_at_va and Extended C
  • class SqrtSpecification
  • specification static double sqrt(double x)
  • reads x
  • pre return x gt 0
  • post
  • if(x 0)
  • branch "Zero argument"
  • return sqrt 0
  • else
  • branch "Positive argument"
  • return sqrt gt 0
  • Math.abs((sqrtsqrt-x)/x
  • lt epsilon

specification double SQRT(double x) reads
(double)x pre return x gt 0. coverage
ZP if(x 0.) return (ZERO, "Zero
argument") else return (POS, "Positive
argument") post if(coverage(ZP,
ZERO)) return SQRT 0. else
return SQRT gt 0.
abs((SQRTSQRT - x)/x) lt
epsilon
operation signature declaration
functional branches definition
postcondition
access constraints
precondition
61
Training Courses
CTesK training was conducted for Tercom
(Russia) J_at_T training was conducted for
Systematic Software Engineering
(Denmark),Saarland University (Germany)
62
QUTILUI Project
  • GoalRedesign of SOS Queue Manipulation Utilities
    Subsystem
  • Activities
  • Requirements elicitation
  • Specification development
  • Specification review
  • Architecture design
  • Component design
  • Implementation
  • Testing and debugging

63
QUTILUI Project Results
  • Bugs removed
  • No bugs found after the project end!
  • 25 decrease of implementation size
  • Design documentation appeared
  • And it became actual!
  • Tests demonstrated conformance with requirements

-------- -------- ----
- - - - - - - - - - - - - - - - - - - - - - - - -
- - -
64
Other Examples of UniTesK Usage
  • IPv6 implementations
  • Microsoft Research
  • Mobile IPv6 (in Windows CE 4.1)
  • mpC Workshop
  • Debug API
  • mpC expression static and dynamic semantics
  • Optimization units in Intel compilers
  • UniTesK tools
  • J_at_T test system runtime support
  • Components of J_at_va translator
  • CTesK abstract types library
  • Lanit-Tercom
  • IPv6 implementation
  • DSP software

65
Appendices
  • References slide 66
  • Detailed comparison of specification techniques
    slide
    67-69
  • Priority Queue Example
  • Description slide 70
  • Specifications slides 71-79
  • Functional branches slides 80-82
  • Additional coverage goals slides 83-86
  • FSM construction slides 87-91
  • Test scenario slides 92-96
  • Mediator and its usage slides 97-101

66
References
  1. V. Kuliamin, A. Petrenko, I. Bourdonov, A.
    Kossatchev. UniTesK Test Suite Architecture //
    Proceedings of FME2002 conference, Copenhagen,
    Denmark, LNCS, No. 2391, 2002, pp. 77-88.
  2. V. Kuliamin, A. Petrenko, I. Burdonov, A.
    Demakov, A. Jarov, A. Kossatchev, S. Zelenov.
    J_at_va extension of Java for real-life
    specification and testing // Proc. of Andrei
    Ershov Fourth International Conference PCI01,
    Novosibirsk, LNCS, Vol. 2244, 2001, pp.301-308.
  3. A. Petrenko, V. Kuliamin, I. Bourdonov, A.
    Kossatchev. Experiences in using testing tools
    and technology in real-life applications //
    Proceedings of SETT01, India, Pune, 2001
  4. A. Petrenko. Specification Based Testing Towards
    Practice // Proceedings of PSI01, Novosibirsk,
    LNCS 2244, 2001, pp.157-162.
  5. A. Petrenko, A. Vorobiev. Industrial Experience
    in Using Formal Methods for Software Development
    in Nortel Networks // Proceedings of Testing
    Computer Software Conference TCS 2000,
    Washington, June, 2000.
  6. I. Bourdonov, A. Kossatchev, V. Kuliamin. Using
    Finite State Machines in Program Testing //
    Programming and Computer Software, Vol. 26, No.
    2, 2000, pp. 61-73.
  7. I. Bourdonov, A. Kossatchev, A. Petrenko, and D.
    Galter. KVEST Automated Generation of Test
    Suites from Formal Specifications // Proceedings
    of World Congress of Formal Methods, Toulouse,
    France, LNCS, No. 1708, 1999, pp. 608-621

67
Executable Specifications
  • Are very close to some implementation
  • Are easy to use in the industry
  • Can be transformed into prototypes
  • Are not close to requirements( v e½ln
    lim(xn1 ½(xn x/xn)) )
  • Unsuitable for test coverage measurement
  • Can cause problems with conformance checkingHow
    to compare the results?
  • Are highly reusable as executable code
  • But are low reusable as criteria of correctness

68
Constraint Specifications
  • Have the structure similar with implementation
  • Are easy to use in the industry
  • But have different form
  • Are close to requirements in most cases
  • Are easy to construct from requirements
  • Suitable for test coverage measurement
  • Counterexample memory management subsystem
  • Can be directly used in conformance checking
  • Special constructs enabling reuse can be added

69
Axiomatic Specifications
  • Are far from common implementations and have
    greatly different structure
  • Can hardly be introduced in the industry
  • Are usually far from requirements
  • Are hard to develop in real-life projects
  • Can hardly be used for coverage measurement
  • But sometimes are the only appropriate form
  • Can be used for conformance checking
  • But sharpen error localization problems
  • Reusability is a problem

70
Priority Queue Example
0
5
2
enq ()
enq ()
deq ()
enq ()
5
5
4
3
1
1
size ()
  • void enq (Object obj, int priority)priority ?
    Min_Priority, Max_Priority
  • Object deq ()
  • int size ()

71
Model State Definition
  • public class PQueueSpecification
  • // List of elements of the queue
  • public Vector items new Vector()
  • // Accompanying list of their priorities
  • public IntList priorities new IntList()

72
Data Integrity Constraints Lists are not Null
  • public class PQueueSpecification
  • public List items new List()
  • public IntList priorities new IntList()
  • invariant ListsAreNotNull()
  • return items ! null priorities ! null

73
Data Integrity Constraints Lists Sizes are
Equal
  • public class PQueueSpecification
  • invariant ListsSizesAreEqual()
  • return items.size() priorities.size()

74
Data Integrity Constraints Priorities Lie in
the Range
  • public class PQueueSpecification
  • public static int Min_Priority
  • public static int Max_Priority
  • invariant PrioritiesLieInTheRange()
  • for(int i 0 i lt priorities.size() i)
  • if( priorities.get(i) lt Min_Priority
  • priorities.get(i) gt Min_Priority
  • )
  • return false
  • return true

75
Data Integrity Constraints Priorities do not
Increase
  • public class PQueueSpecification
  • invariant PrioritiesDoNotIncrease()
  • for(int i 1 i lt priorities.size() i)
  • if( priorities.get(i-1) lt priorities.get(i)
    )
  • return false
  • return true

76
Operation Specification size() Method
  • public class PQueueSpecification
  • specification public int size ()
  • reads this.?
  • pre return true
  • post
  • return size items.size()

77
Operation Specification enq() Method
  • public class PQueueSpecification
  • specification public void enq (Object obj, int
    prty)
  • reads obj, prty
  • updates this.?
  • pre return obj ! null
  • post
  • int i 0
  • for(i 0
  • i lt items.size() priorities.get(i)
    gt prty
  • i
  • )
  • PQueueSpecification new_state
    (PQueueSpecification)_at_clone()
  • new_state.items.add(i, obj)
  • new_state.priorities.add(i, prty)

78
Auxiliary Methods
  • public class PQueueSpecification
  • public boolean equals (PQueueSpecification
    other)
  • return items.equals(other.items)
  • priorities.equals(other.priorities)
  • public Object clone ()
  • PQueueSpecification result new
    PQueueSpecification()
  • result.items (List)items.clone()
  • result.priorities (IntList)priorities.clone(
    )
  • return result

79
Operation Specification deq() Method
  • public class PQueueSpecification
  • specification public Object deq ()
  • updates this.?
  • post
  • if(items.isEmpty())
  • return deq null items.isEmpty()
  • else
  • PQueueSpecification new_state
    (PQueueSpecification)_at_clone()
  • Object result new_state.items.first()
  • new_state.items.removeFirst()
  • new_state.priorities.removeFirst()
  • return this.equals(new_state) deq
    result

80
Functionality Branches in size() Method
  • public class PQueueSpecification
  • specification public int size ()
  • reads this.?
  • pre return true
  • post
  • branch Single branch
  • return size items.size()

81
Functionality Branches in enq() Method
  • specification public void enq (Object obj, int
    prty)
  • reads obj, prty
  • updates this.?
  • pre return obj ! null
  • post
  • int i 0
  • for(i 0
  • i lt items.size() priorities.get(i) gt
    prty
  • i
  • )
  • branch Single branch
  • PQueueSpecification new_state
    (PQueueSpecification)_at_clone()
  • new_state.items.add(i, obj)
  • new_state.priorities.add(i, prty)

82
Functionality Branches in deq() Method
  • specification public Object deq ()
  • updates this.?
  • post
  • if(items.isEmpty())
  • branch Empty queue
  • return deq null items.isEmpty()
  • else
  • branch Nonempty queue
  • PQueueSpecification new_state
    (PQueueSpecification)_at_clone()
  • Object result new_state.items.firstElement
    ()
  • new_state.items.removeFirstElement()
  • new_state.priorities.removeFirstElement()
  • return this.equals(new_state) deq
    result

83
Additional Coverage Tasks enq()
1
0
5
2
7
4
5
5
4
3
1
1
1
1
1
1
84
Additional Coverage Tasks deq()
5
5
4
3
1
1
5
4
3
1
85
Marked Paths in enq() Method
  • post
  • int i 0
  • for(i 0
  • i lt items.size() priorities.get(i) gt
    prty
  • i
  • )
  • if( items.isEmpty() )
  • mark "Insertion in the empty queue"
  • else if( prty gt priorities.maximum() )
  • mark "Insertion in the head"
  • else if( prty priorities.maximum() prty
    priorities.minimum() )
  • mark "Insertion with single existing
    priority"
  • else if( prty priorities.maximum() )
  • mark "Insertion with maximum priority"
  • else if( prty lt priorities.minimum() )
  • mark "Insertion in the tail with new
    priority"
  • else if( prty priorities.minimum() )

86
Marked Paths in deq() Method
  • post
  • if(items.isEmpty())
  • branch Empty queue
  • ...
  • else
  • if( items.size() 1 )
  • mark "Single element in the queue"
  • else if( !(priorities.maximum()
    priorities.get(1)) )
  • mark "Single element with maximum priority,
    several elements in the queue"
  • else if( priorities.toSet().size() gt 1 )
  • mark "Several elements with maximum
    priority, there are other priorities"
  • else
  • mark "Several elements in the queue with
    the same priority"
  • branch Nonempty queue

87
Priority Queue Example enq() Coverage Goals
  • if( items.isEmpty() )
  • mark "Insertion in the empty queue"
  • else if( prty gt priorities.maximum() )
  • mark "Insertion in the head"
  • else if( prty priorities.maximum() prty
    priorities.minimum() )
  • mark "Insertion with single existing priority"
  • else if( prty priorities.maximum() )
  • mark "Insertion with maximum priority"
  • else if( prty lt priorities.minimum() )
  • mark "Insertion in the tail with new priority"
  • else if( prty priorities.minimum() )
  • mark "Insertion with minimum priority"
  • else if( !priorities.contains(prty) )
  • mark "Insertion in the middle with new
    priority"
  • else
  • mark "Insertion in the middle with existing
    priority"

States
Empty queue
Single priority is used
At least two priorities are used
At least three priorities are used
?
Arguments
At least three different priorities should be
provided
88
Priority Queue Example deq() Coverage Goals
  • if(items.isEmpty())
  • branch Empty queue
  • else
  • if( items.size() 1 )
  • mark "Single element in the queue"
  • else if( !(priorities.maximum()
    priorities.get(1)) )
  • mark "Single element with maximum priority,
    several elements in the queue"
  • else if( priorities.toSet().size() gt 1 )
  • mark "Several elements with maximum priority,
    there are other priorities"
  • else
  • mark "Several elements in the queue with the
    same priority"

States
Empty queue
Single element in the queue
Single element with maximum priority, several
priorities
Several elements with maximum priority, several
priorities
Several elements with the single used priority
89
Priority Queue Example Analysis of Determinism
0
1
2
deq()
0 Empty queue
1 Single element in the queue
2 Several elements with single used priority
To make the behavior deterministic we should
split this state according to the number of
elements
90
Priority Queue Example Analysis of Determinism

0
1
2
3
deq()
A
0,1,2, Number of elements with maximum
priority
A Single element with maximum priority, several
priorities
To make the behavior deterministic we should
split this state according to the number of
elements with the next priority
And so on, for all priorities (by induction)
91
Priority Queue Example Resulting State
  • Resulting state S int ? int ismap from
    integers to integers, wherekey is priorityvalue
    is the number of queue elements having such the
    priority

92
Reference to Specification Object
  • scenario public class PQueueTestScenario
  • // Reference to the object under test
  • public PQueueSpecification queue

93
State Construction Method
  • scenario public class PQueueTestScenario
  • public AbstractGenState getGenState()
  • IntToIntMapGenState state new
    IntToIntMapGenState()
  • for(int p PQueueSpecification.Min_Priority
  • p lt queue.priorities.toSet().size()
  • p
  • )
  • int n queue.priorities.numberOf(p)
  • if( n ! 0 ) state.put(p, n)
  • return state

94
Definition of Test Actions size() method
  • scenario public class PQueueTestScenario
  • scenario public boolean size()
  • queue.size()
  • return true

95
Definition of Test Actions enq() method
  • scenario public class PQueueTestScenario
  • scenario public boolean enq()
  • Object arg new Object()
  • iterate( int priority PQueueSpecification.Mi
    n_Priority
  • priority lt PQueueSpecification.Max_P
    riority
  • priority
  • queue.priorities.toSet().size()
    lt 3
  • queue.priorities.contains(prior
    ity)
  • queue.priorities.numberOf(prior
    ity) lt 2
  • )
  • queue.enq(param, priority)
  • return true

96
Definition of Test Actions deq() method
  • scenario public class PQueueTestScenario
  • scenario public boolean deq()
  • queue.deq()
  • return true

97
Mediator for Priority Queue
  • mediator public class PQueueMediator
  • // Extends specification class
  • extends PQueueSpecification
  • // Reference to an implementation object
  • implementation public PriorityQueue target

98
Mediator Methods (Open State Testing)
  • mediator public class PQueueMediator
  • public int size()
  • return target.size()
  • public void enq(Object obj, int prty)
  • target.enq(obj, prty)
  • public Object deq()
  • return target.deq()

99
Model State Synchronization Method (Open State
Testing)
  • mediator public class PQueueMediator
  • public void mapStateUp()
  • items.clear()
  • priorities.clear()
  • if( target ! null )
  • for(int i target._clusters.size()- 1 i
    gt 0 i--)
  • Vector v (Vector)target._clusters.elemen
    tAt(i)
  • for(int j 0 j lt v.size() j)
  • items.add(v.elementAt(j))
  • priorities.add(i)

100
Mediator Methods (Hidden State Testing)
  • mediator public class PQueueMediator
  • public int size()
  • return target.size()
  • public void enq(Object obj, int prty)
  • target.enq(obj, prty)
  • items.add(obj)
  • priorities.add(prty)
  • public Object deq()
  • Object result target.deq()

101
Test Scenario Initialization
  • scenario public class PQueueTestScenario
  • public PQueueTestScenario()
  • setTestEngine ( new DeterministicFSM_TestEngin
    e() )
  • PQueueMediator.initClassState()
  • queue PQueueMediator.create(new
    PriorityQueue())
  • queue.attachOracle()
Write a Comment
User Comments (0)
About PowerShow.com