a test selection language for co opn specifications
Download
Skip this Video
Download Presentation
A Test Selection Language for CO-OPN Specifications

Loading in 2 Seconds...

play fullscreen
1 / 24

A Test Selection Language for CO-OPN Specifications - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

A Test Selection Language for CO-OPN Specifications. Levi L úcio, Luis Pedro and Didier Buchs University of Geneva. Presentation Plan. The CO-OPN Modeling Language CO-OPN as a prototyping tool Testing Theory Stating hypotheses about the SUT for test selection

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' A Test Selection Language for CO-OPN Specifications' - nibaw


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a test selection language for co opn specifications

A Test Selection Language for CO-OPN Specifications

Levi Lúcio, Luis Pedro

and Didier Buchs

University of Geneva

presentation plan
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
presentation plan1
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
the co opn modeling language
The CO-OPN Modeling Language
  • CO-OPN (Concurrent Object-Oriented Petri Nets) is a formal specification language, with clearly stated semantics. Based on:
    • Algebraic Data Types: data and associated operations
    • Petri Nets: behavior
  • It includes object based concepts:
    • Class
      • Attributes: places in a Petri Net
      • Methods: guarded transitions in a Petri Net
  • Powerful synchronization mechanism
    • Coordination of the components of a specification
      • Objects
      • Contexts (stateless coordination units)
    • “All or nothing” semantics (sequence / parallel / choice)
structure of a co opn specification
Structure of a CO-OPN Specification

Contexts

Coordinate

Coordinate

(instances of) Classes

Coordinate

Use

Algebraic Data Types

example specification in co opn
Example specification in CO-OPN
  • A (simple) mobile phone is composed by:
    • A card containing (among other things) the personal identification number (PIN) to activate the phone;
    • A phone controller holding (among other things) the state of the phone, which can be:
      • Off
      • Standby (waiting for the correct PIN)
      • Idle (ready to receive or make calls)
  • In our specification the user can perform two actions:
    • Turn on the phone;
    • Insert a PIN number
class phonecontroller
Class PhoneController

Algebraic Data Types

Typed values (+ operations) inside the Petri Net places…

co opn as a prototyping tool
CO-OPN as a Prototyping Tool
  • Our tool (CoopnBuilder) is able to produce Java code from a CO-OPN specification. We can then execute the specification…
sut system under test verification
SUT (System Under Test) Verification
  • We can “run” the specification to make sure the prototype will act as expected, but…
    • What if the prototype is changed / extended, or simply implemented in a language other than Java?
    • There is no way of keeping a record of previously tested behaviors (for example for regression testing…)
  • Solution: devise a testing language to include test modules in CO-OPN specifications:
    • The test module will use the specification to generate syntactically and semantically meaningful tests;
    • Prototype execution provides an easy way of deciding what should be the result of a given test case when it is applied to the SUT (System Under Test).
presentation plan2
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
presentation plan3
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
testing theory

T0

H0

Reduce

test

set

Increase

hypothesis

strength

T1

H1

Tk-1

Hk-1

Tk

Hk

Testing Theory
  • Problem: How do we select “interesting” tests?
  • In the general case, the amount of tests for a given system is infinite:
    • Infinite domains for operation’s domains;
    • Infinite paths of execution in the SUT’s state space.
  • It is necessary to restrict the “exhaustive” test set to a practicable one. This is done by providing hypotheses about the functioning of the SUT:
testing process
Testing Process

Does P satisfy SP?

P

SP

Test Selection

(Hypotheses H Application)

Test Set T

Test

Procedure

Execution of P using T

Correction of P

Oracle

P satisfies, or not, T!

no

inconclusive

yes

P satisfies, or not, H

no

yes

P does not satisfy SP

Undefined

P satisfies SP!

presentation plan4
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
presentation plan5
Presentation Plan
  • The CO-OPN Modeling Language
    • CO-OPN as a prototyping tool
  • Testing Theory
    • Stating hypotheses about the SUT for test selection
  • A Test Selection Language for CO-OPN Specifications
    • Language Structure
    • Hypotheses
      • On Paths
      • On Values
  • Conclusion
test language structure
Test Language Structure

Hypotheses

constraints over the

exhaustive test set

HML (Hennessy-Milner Logic)

next <_> operator

not, and operators

CO-OPN event pairs

input event (method), output event (gate)

(black-box approach)

mobile phone example revisited
Mobile Phone Example Revisited
  • Let us create a test module for an extended version of the Mobile phone CO-OPN specification:
    • A (simple) mobile phone is composed by:
      • A card containing (among other things) the personal identification number (PIN) to activate the phone. The card gets blocked after 3 wrong attempts at inserting a PIN.
      • A phone controller holding (among other things) the state of the phone, which can be:
        • Off
        • Standby (waiting for the correct PIN)
        • Idle (ready to receive or make calls)
    • In our specification the user can perform two actions:
      • Turn on the phone;
      • Insert a PIN number,
      • Reset the card when it becomes blocked
test module for the mobile phone

Exported constraints

Locally defined constraints

Imported Algebraic Data Types

Variables used in constraint definition

Constraints’

Semantics

Test Module for the Mobile Phone

ConstraintSet NatelBehaviors;

Interface

Constraints

insertPins;

block;

reachOn;

Body

Constraints

nWrongPins;

Use

Boolean;

Pin;

Axiom

[] in nWrongPins;

f in nWrongPins => f . HML(<insertPin(newPin(1 1 1 1)),pinResult(false)>) in nWrongPins;

f in nWrongPins, depth(f) <= 3 => HML(<turnOn,null>) . f . HML(<m,g>) in insertPins;

depth(f) <= 3 => HML(<turnOn,null>) . f . HML(<resetCard,null>) in block;

depth(f) <= 3 => HML(<turnOn,null>) . f . HML(<insertPin(newPin(1 2 3 4)),phoneReady>) in reachOn;

Variables

f : HML;

m : method;

g : gate;

End NatelBehaviors;

hypotheses on paths
Hypotheses on Paths
  • The language allows defining the shape of sequences of input/output pairs that will be used to generate tests:

[] in nWrongPins;

f in nWrongPins => f . HML(<insertPin(newPin(1 1 1 1)),pinResult(false)>) in nWrongPins;

f in nWrongPins, depth(f) <= 3 => HML(<turnOn,null>)} . f . HML(<m,g>) in insertPins;

  • nWrongPins (local constraint) defines an (infinite) sequence of insertPin inputs with a wrong PIN;
  • insertPins defines a sequence of operations starting by turnOn, followed by a sequence of at most three insertPin inputs with a wrong PIN and finishing by any input/output pair.

Examples of tests generated by the insertPin constraint:

HML(<turnOn,null>,<insertPin(newPin(1 1 1 1)),pinResult(false)>,<resetCard,null>),false

HML(<turnOn,null>,<insertPin(newPin(1 1 1 1)),pinResult(false)>, <insertPin(newPin(1 1 1 1)),

pinResult(false)>,<insertPin(newPin(1 1 1 1),pinResult(false)>,<resetCard,null>),true

HML(<turnOn,null>,<insertPin(newPin(1 2 3 4)),pinResult(true)>,true

...

hypotheses on values
Hypotheses on Values
  • By default, the tests generated by the pinTest will correspond to all values of type Pin - large amount
  • Solution 1:

Axioms

HML(<turnOn,null>,<insertPin(p), g>) in pinTest;

Variables

p : Pin;

g : gate;

uniformity(p) => HML(<turnOn,null>,<insertPin(p), g>) in pinTest

  • Choose one value from the domain - equivalent to random testing…
  • Corresponds to the hypotheses: “if insertPin works well for one PIN, it will work well for all PINs”.
hypotheses on values 2

P is the good PIN

=> Send pinResult(true)

insertPin(p)

P is a wrong PIN

=> Send pinResult(false)

Hypotheses on Values (2)
  • Solution 2:

subUniformity(p) => HML(<turnOn,null>,<insertPin(p), g>) in pinTest

  • Choose one value from each equivalence class of the behavior of the insertPin operation.
  • In order to decompose the behavior of an operation we need to analyze its choice points…
  • This is done by analyzing the CO-OPN specification.
    • Feature under development, using Prolog for symbolic execution and constraint resolution.
managing non determinism in the sut
Managing Non-Determinism in the SUT
  • We would like to manage behaviors of the SUT which cannot be calculated in test generation time…
    • Example: an e-banking application proposes a challenge as part of the authentication mechanism. How do we calculate the reply to the challenge in order to login successfully during the test?
  • Solution: Introduce the possibility to have “external” functions that will perform calculations in testing time.
    • In the e-banking case there would be a function to calculate the answer to the challenge in function of the proposed value.
conclusion
Conclusion
  • We have presented a test selection language intended at testing software (and possibly hardware) prototypes specified in CO-OPN;
  • The test selection is done by the test engineer, assisted by the tool while decomposing the behavior of the operations in a specification;
  • The tool is currently half implemented. We envisage on the short term a case study to fully validate our ideas, also in terms of scalability.
ad