UML Testing Profile Graphical Testing With UML The

UML Testing Profile Graphical Testing With UML The UML Testing Profile Eric Samuelsson eric. samuelsson@telelogic. com © Telelogic AB

UML Testing Profile Agenda • Background • Key concepts • Advanced concepts • Summary © Telelogic AB

UML Testing Profile Background • Test technologies are not on par with modern design technologies such as model-driven architectures (MDA) • There’s a need for a widespread graphical test language • OMG realized this and issued and RFP for a graphical testing profile to UML – Using the UML ensures widespread use across a wide range of application areas – Numerous tool vendors support UML – UML is a proven de facto standard – But UML is focused on definition of system structure and behavior and has no built-in testing constructs. . . © Telelogic AB

UML Testing Profile RFP • Issued by OMG in July 2001 • LOI’s submitted by – Telelogic, Rational, Sof. TEAM, FOKUS, Ericsson, Motorola, IBM • One joint submission • Initial submission made in April 2002 • Revised initial submission made in June 2002 – Terminology changes – Elaboration of Test Data • Final submission in January 2003 © Telelogic AB

UML Testing Profile Requirements and restrictions • Define structural and behavioral test concepts • Conformance testing only – Black-box functional testing • Based upon the UML meta-model – UML 2. 0 as proposed by the U 2 Partners – Inter-operation with existing technologies – TTCN 3 – Junit –. . . © Telelogic AB

UML Testing Profile Current proposal • A graphical testing language based the current UML 2 metamodel • Reusing as many UML concepts as possible – Recognition important for UML users – No need to re-invent the wheel • Designed with TTCN 3 in mind – Semantics basically follows TTCN 3 semantics – But caters for other technologies like JUnit as well © Telelogic AB

UML Testing Profile Current proposal • Defined as a UML profile – Will be recognized by UML users • Basically a number of stereotypes – Easy to implement for tool vendors • Models will be interchangeable – Any tool implementing XMI will be able to exchange models UML «import» «profile» Testing Profile «metaclass» Behavioral. Feature «stereotype» Test. Case © Telelogic AB

UML Testing Profile Key Concepts • Test Architecture – Test Context, Test Configuration – Test Component, SUT – Arbiter • Test Behavior – Test Case – Verdict, Validation Action – Defaults • Test Data – Logical partitions, Pattern matching • Test Deployment © Telelogic AB

UML Testing Profile Test Objective • An informal description of what to test in one test case • Commonly expressed using natural language ”Verify that if a user inserts and authorizes a valid card correctly, he is able to withdraw money if he has sufficient funds. ” • Can also be expressed using other diagrams, such as use case diagrams and sequence diagrams Withdrawal Client <<include>> Tester Invalid. Pin © Telelogic AB

UML Testing Profile Test Case • A specification of one test, including – Test objective – Test behavior • Defined as a Behavioral. Feature in UML • It’s method is the behavior of the test case «test. Case» +valid. Withdrawal() : Verdict «test. Context» ATMContext «test. Case» +valid. Withdrawal() : Verdict +invalid. PIN() : Verdict -authorize. Card() : Verdict © Telelogic AB

UML Testing Profile Test Behavior • Describes the expected behavior of a test case • Defined using any type of UML behavior – Interactions, statemachines and activities • Facilitates specification of arbitrarily complex behavior Idle Wait. Code © Telelogic AB

UML Testing Profile Test Architecture • A complete specification of all types used in the tests – An ordinary UML package – Contains Test Contexts, Test Components, Ports, Interfaces, etc. «test. Architecture» ATMTest © Telelogic AB

UML Testing Profile Test Architecture Example «test. Architecture» ATMTest IAccount «test. Context» ATMContext «test. Component» HWEmulator be. Port «test. Case» +valid. Withdrawal() : Verdict +invalid. PIN() : Verdict -authorize. Card() : Verdict -pin. Ok : Boolean -entered. PIN : String -message : String hw. Com «test. Component» Bank. Emulator * IScreen, ICard. Machine, IMoney. Box IATM accounts Account balance : Integer number : String credit(a : Integer) debit(a : Integer) ATM: : Card. Data * cards pin. Code : Integer number : String is. Pin. Correct(c: Integer) : Boolean © Telelogic AB

UML Testing Profile Test Component • Implements (parts of ) the behavior of one or more test cases • Each test case is normally executed by several components • Ordinary classes or components «test. Component» HWEmulator -pin. Ok : Boolean -entered. PIN : String -message : String hw. Com 0. . 1 IScreen, ICard. Machine, IMoney. Box IATM -current. Card ATM: : Card. Data pin. Code : Integer number : String is. Pin. Correct(c: Integer) : Boolean © Telelogic AB

UML Testing Profile Test Context • A classifier that contains – a number of test cases and their behavior and objectives – default behavior used by the test cases – configuration of test components – test control behavior • Can be a class, a component or a collaboration «test. Context» ATMContext «test. Case» +valid. Withdrawal() : Verdict +invalid. PIN() : Verdict -authorize. Card() : Verdict © Telelogic AB

UML Testing Profile Test Configuration • A specification of the structural aspects of test cases • Defines the parts participating in the test case and their interconnections – Test Components, SUT, Ports, Interfaces and Connectors • Defined as the internal structure of the Test Context «sut» atm : Bank. ATM be : Bank. Emulator net. Com be. Port atm. Port hw. Com hwe : HWEmulator accnts : Account [0. . *] © Telelogic AB

UML Testing Profile Test Control • Test execution can be controlled is two ways – By defining the classifier behavior of a test context – Or by invoking the test cases from outside of the context © Telelogic AB

UML Testing Profile Test Control by Classifier. Behavior sd ATMContext ref invalid. PIN() «test. Context» ATMContext «test. Case» +valid. Withdrawal() : Verdict +invalid. PIN() : Verdict -authorize. Card() : Verdict [verdict == pass] ref [verdict == fail] valid. Withdrawal() © Telelogic AB

UML Testing Profile Test Control by Invocation ad my. Op «test. Context» My. Test. Context My. Class -verdict : Verdict +my. Op() -context * «test. Case» +TC 1() : Verdict +TC 2() : Verdict -TC 3() : Verdict verdict : = context. TC 1() [verdict == pass] [else] verdict : = context. TC 2() © Telelogic AB

UML Testing Profile Test Data • Parameters, default values, return values are reused from UML without changes • Logical partitions • Pattern matching • TDB © Telelogic AB

UML Testing Profile Test Deployment • Test Deployment is important, but there is probably no difference between deploying test systems compared to ordinary UML systems. • We will try to reuse the existing UML deployment concepts without changes • Under investigation © Telelogic AB

UML Testing Profile Advanced Concepts • Test Evaluation – Verdict – Validation action – Arbiter • • Default behavior Structural and behavioral reuse © Telelogic AB

UML Testing Profile Test Evaluation • A number of concepts are used to evaluate test results – Verdicts – Validation actions – Arbiter © Telelogic AB

UML Testing Profile Verdicts and Validation Actions • Each test component is associated with a verdict • Validation Actions are used to set the verdict • A Validation Action sets the verdict of a test component and reports the verdict to the Arbiter «sut» Client ATM store. Card. Data(card. Data) display(”Enter PIN”) is. Pin. Correct(pin) alt true false setverdict(fail) © Telelogic AB

UML Testing Profile Arbiter • A test component that knows how to evaluate the test behavior • Separates test evaluation from test case specification – One behavior can yield different results • Each test context has a default arbiter – Implicit connections to all test components – TTCN 3 semantics • Advanced arbiters can be defined – Caters for more advanced semantics «arbiter» my. Arbiter set. Verdict(v : Verdict) © Telelogic AB

UML Testing Profile Default behavior • • • Defines behavior for unexpected observations Can be expressed using any UML behavior Can be applied to several different levels: – Test component sd authorize. Card – Message reception – Alternative statement «sut» Client –. . . ATM store. Card. Data(card. Data) enter. Pin. Default display(”Enter PIN”) is. Pin. Correct(pin) true © Telelogic AB

UML Testing Profile sd enter. Pin. Default self alt get. Status status. Ok Default expressed as interaction. . . setverdict(pass) display(”Connection lost”) setverdict(inconc) eject. Card() setverdict(fail) © Telelogic AB

UML Testing Profile enter. Pin. Default get. Status / ^status. Ok, setverdict(pass); . . . and as statemachine eject. Card / setverdict(fail) * display(”Connection lost”) / setverdict(inconc) The representations are semantically equivalent © Telelogic AB

UML Testing Profile Meta Default • Each test component has a meta default to cater for differences in semantics • Can be redefined Meta. Default * * / defer © Telelogic AB

UML Testing Profile Reuse of Test Structure and Behavior © Telelogic AB

UML Testing Profile «test. Context» ATMContext «sut» atm : Bank. ATM atm. Port be : Bank. Emulator net. Com accnts : Account [0. . *] be. Port ATM hw. Com hwe : HWEmulator ac: Authorization. Context Client © Telelogic AB

UML Testing Profile sd Valid. Withdrawal «sut» atm hwe atm. Port ref be net. Com ac. authorize. Card() select. Operation(withdrawal) true withdraw(amount) find. Account(card. Data) account debit. Account(account, amount) true deliver. Money(amount) display(”Take cash”) true © Telelogic AB

UML Testing Profile Summary • The testing profile enables complete graphical specification of tests for conformance testing of UML models – Defined as a UML profile – Reuses existing UML concepts whenever possible – Designed for inter-operation with TTCN-3 and other technologies • Due date – January 6 th, 2003 • More information – Testing Profile Consortium – OMG’s Testing Profile page © Telelogic AB