1 / 59

An Introduction to version 3

An Introduction to version 3. Dr. Michael Ebner University Göttingen, Germany ebner@cs.uni-goettingen.de. About the speaker. Is researcher in the telematics group of Prof. Dr. D. Hogrefe at the Institute for Informatics, University of Göttingen, Germany

ellery
Download Presentation

An Introduction to version 3

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. An Introductionto version 3 Dr. Michael EbnerUniversity Göttingen, Germanyebner@cs.uni-goettingen.de

  2. About the speaker • Is researcher in the telematics group ofProf. Dr. D. Hogrefe at the Institute for Informatics, University of Göttingen, Germany • Is active in the research area of test automation, model-based testing, and protocol modeling • Working with TTCN-3 since 2000 • Influenced data types and synchronous communication of TTCN-3

  3. An Introduction toInstitute for Informatics,University of Göttingen Founded in 1737 by King George II (England), who also founded Princeton U (1746) and Columbia U (1754) George-August-Universität Göttingen 44 Nobel Prize-winner live(d) and work(ed) here Other 12 departments Department of Mathematics Gauß, Weber, Hilbert, … Center for Informatics 2000~ Institute for Informatics 01/2003~ Theory Group Prof. Waack Database GroupProf. May Distributed Systems Group, Prof. Switzer Softw. Eng. Group Prof. Grabowski Service Eng. GroupProf. Margaria Practical Informatics Group Prof. Neumair (GWDG) Telematics GroupProf. Hogrefe

  4. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  5. Why using a standardised test language? 1(3) Developer Testing throughout the process Integrator Heterogeneity increases SystemsIntegrator

  6. Why using a standardised test language? 2(3) Developer Testing tight to Development e.g. JUnit Integrator Testing tight to Services TTCN-3 SystemsIntegrator

  7. Why using a standardised test language? 3(3) • Standardised test language • improves communication • among developers • with the customer • improves transparency • one test language for all departments • No proprietary test languages • reduces costs • costs of training • usage of commercial test equipments (tools, test suites, etc.)

  8. What is TTCN-3 ? • The standardised (black-box) test specification and test implementation language. • Developed • by the European Telecommunications Standards Institute (ETSI) from 1999 to 2001. • based on the experiences from previous TTCN versions. • Applicable for all kinds of black-box testing for reactive and distributed systems, e.g. • Telecom systems (ISDN, ATM); • Mobile (telecom) systems (GSM, UMTS); • Internet (has been applied to IPv6); • CORBA based systems.

  9. TTCN stands for …??? • Tree and Tabular Combined Notation • For TTCN-1 and TTCN-2 • Testing and Test Control Notation • Since TTCN-3

  10. The TTCN-3 series of standards 1(3) TTCN-3 Core Notation Tabular Format ASN.1 Types & Values Other Types & Values 2 Other Types & Values 3 Graphical Format TTCN-3 User Presentation Format n Other Types & Values n

  11. The TTCN-3 series of standards 2(3) XML IDL C/C++ msc mi_synch1_conc1 TTCN-3 Core Notation mtc ISAP1 MSAP2 Tabular Format ASN.1 Types & Values Other Types & Values 3 Other Types & Values 2 Graphical Format TTCN-3 User UML Testing Profile Presentation Format n Other Types & Values n : testcase myTestcase () runson MTCType system TSIType {mydefault := activate (OtherwiseFail); verdict.set(pass); : connect(PTC_ISAP1:CP_ISAP1,mtc:CP_ISAP1); : map(PTC_ISAP1:ISAP1, system:TSI_ISAP1); : PTC_ISAP1.start(func_PTC_ISAP1()); PTC_MSAP2.start(func_PTC_MSAP2()); Synchronization(); allcomponent.done; log(”Correct Termination”); } :

  12. The TTCN-3 series of standards 3(3) ITU-T Recommendation (SG17 / WP3 / Q14) Z.140 Z.141 Z.142 Z.143 Z.144 Z.145 Z.146 • European Standard (ES) in 6 parts • ES 201 873-1: TTCN-3 Core Language • ES 201 873-2: TTCN-3 Tabular Presentation Format (TFT) • ES 201 873-3: TTCN-3 Graphical Presentation Format (GFT) • ES 201 873-4: TTCN-3 Operational Semantics • ES 201 873-5: TTCN-3 Runtime Interface (TRI) • ES 201 873-6: TTCN-3 Control Interface (TCI) • ES 201 873-7: Using ASN.1 with TTCN-3 • ES 201 873-8: Using IDL with TTCN-3 • ES 201 873-9: Using XML with TTCN-3 • ES 201 873-10: Using C/C++ with TTCN-3 (planned) New edition 3.1.1 of TTCN-3 since June 2005

  13. Concepts • Black-Box Testing with TTCN-3 • Test Configuration • Test Components • Communication Ports • Test Verdicts • Ingredients of TTCN-3 • Structure of TTCN-3 specs • Re-use of existing Code

  14. Black-box testing with TTCN-3 TTCN-3 Test Case Port.send(Stimulus) Port.receive(Response) Port System Under Test • Assignmentof aTest Verdict

  15. Test configuration 1(2) SUT TTCN-3 Test Case create start TC MTC TCs TC create start create start

  16. Test configuration 2(2) Test System Connected Ports INOUT TC2 OUT IN OUT IN Mapped Ports OUT IN Real Test System Interface Real Test System Interface SUT TC1 Abstract Test System Interface

  17. Test components MTC PTC1 Test System PTCn PTC2 Abstract Test System Interface Real test system connected to the SUT • There are three ‘kinds’ of components • Abstract Test System Interfacedefined as component • MTC (Main Test Component) • PTC (Parallel Test Component)

  18. Communication ports 1(2) P1 (out) P2 (in) P1.send (Msg) P2.receive (Msg) TC1 TC2 • Test components communicate via ports • A test port is modeled as an infinite FIFO queue • Ports have direction (in, out, inout) • There are three types of port • message-based, procedure-based or mixed

  19. Language Communication ports 2(2) getcall call replyorraiseexception getreply orcatchexception blocking blocking Caller Callee

  20. Test verdicts Verdict returned by the test case when it terminates P F F I I MTC PTC1 P PTCN setverdict(fail) setverdict(inconc) setverdict(pass) • Test verdicts: none < pass < inconc < fail < error • Each test component has its own local verdict, which can be set (setverdict) and read (getverdict). • A test case returns a global verdict

  21. Ingredients of TTCN-3 Data Types Test Data Test Configuration Test Behavior TTCN-3 • Built-in and user-defined generic data types (e.g., to define messages, service primitives, information elements, PDUs). • Actual test data transmitted/received during testing. • Definition of the components and communication ports that are used to build various testing configurations. • Specification of the dynamic test system behavior.

  22. Structure of TTCN-3 specs – TTCN-3 Modules Module Definitions Module Control • Modules are the building blocks of all TTCN-3 test specifications. • A test suite is a module. • A module has a definitions part and an (optional) control part. • Modules can be parameterized. • Modules can import definitions from other modules. Module

  23. Structure of TTCN-3 specs –Module definitions part Data Types Constants Signatures Data Templates Signature Templates Communication Ports Test Components Functions Altsteps Test Cases • Definitions are global to the entire module. • Data Type definitions are based on TTCN-3 predefined and structured types. • Templates define the test data. • Ports and Components are used in Test Configurations. • Functions, Altsteps and Test Cases define behavior.

  24. Structure of TTCN-3 specs – Module control part 1(2) Module Definitions Module Control • Module control is the ‘dynamic’ part of a TTCN-3 specification where the test cases are executed. • Local declarations, such as variables and timers may be made in the control part. • Basic programming statements may be used to select and control the execution of the test cases. Module

  25. Structure of TTCN-3 specs – Module control part 2(2) module … { … control{ var integer count; if(execute(SIP_UA_REC_V_001()) == pass) { // Execute test case 10 times count := 0; while( count <= 10) { execute(SIP_UA_REC_V_002()); count := count + 1; } // end while } // end if } // end control } // end module

  26. Reuse of existing code –The import mechanism 1(2) LibraryModule 3 import LibraryModule 1 implicit importof a definition requiredexplicitimport import MainModule import LibraryModule 2 • Main Module contains the control part, which specifies test suite execution. • Modules may reuse definitions from other (library) modules. • Implicit import of definitions via chains of imports is not allowed, i.e., an explicit import has to be added. • Reason: A module shall know all modules which it depends on.

  27. Reuse of existing code –The import mechanism 2(2) • Import allows to import • single definitions • definitions of a certain kind, and • groups of definitions from other modules. • Definitions may be imported recursively. • If several definitions are addressed, certain definitions can be excluded by using an except directive. import form ModuleOne { modulepar ModPar2; type RecordType_T2 } import from ModuleTworecursive { testcase T_case } import from ModuleThree all except { template all }

  28. Use of non–TTCN-3 code –Language mapping import ASN.1 Spec. XML Spec. : : XYZ Spec. TTCN-3Module languagemapping ASN.1 TTCN-3 XML : : XYZ • Importing non TTCN-3 definitions requires a language mapping onto TTCN-3. • The language mapping defines the meaning of non TTCN-3 definitions in TTCN-3 modules. • The language mapping may provide TTCN-3 additional features for imported definitions (e.g., operations for ASN.1 data types).

  29. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  30. Language Data types and test data –Constants, types, templates 1(2) Data Types Constants Signatures Data Templates Signature Templates Communication Ports Test Components Functions Altsteps Test Cases • TTCN-3 data types: • integer, char, universal char, float, boolean, objid • enumerated • bitstring, hexstring, octetstring, charstring, universal charstring, • record, record of, set, set of, union • anytype • verdicttype • address • Useful types • IEEE754float, long, byte, … • Iso8859string, utf16string, …

  31. Language Data types and test data –Constants, types, templates 2(2) const integer int_Const := 7; // Normal constant external const boolean bool_Const; // External constant type record Request { // Structured type definition RequestLine requestLine, ReqMessageHeader reqMessageHeader optional, charstring crlf, charstring messageBody optional } template Request Invite := { // template for the Request type requestLine := Request_Line("INVITE"), reqMessageHeader := Req_Mes_Header("INVITE"), crlf := ?, messageBody := omit }

  32. Language Encoding of Messages –Attributes 1(2) Language Element Attributes • Attributes can be assigned to all kinds of definitions, groups and modules. • Kinds of attributes • Encoding information • encode – attribute • variant – attribute • Values are standardized for ASN.1 encoding • Presentation information • display – attribute • Values are standardized for the graphical and tabular presentation format. • User-defined • extension - attribute

  33. Language Encoding of Messages –Attributes 2(2) group MyPDUs { type record MyPDU1 { … } group MySpecialPDUs { type record MyPDU3 { … } with {extension "MyVerySpecialRule"} type record MyPDU4 { … } } with {extension "MySpecialRule"} } with { display "PDU"; extension "MyRule" }

  34. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  35. Language Specifying test behavior –Alternative behavior 1(2) • … has to be specified whenever test component is ready to take a response from the SUT or a timeout. • … is typically defined by several alternatives, which • are evaluated according to their appearance • may be guarded • can be part of an altstep, which may be called explicitly or activated as default. • … forks the test behavior (the typical „tree“), but in TTCN-3 alternatives can be joined again after the end of an alternative behavior. • All other cases can be handled in an else branch.

  36. Language Specifying test behavior –Alternative behavior 2(2) alt { [] L1.receive(MyMessage1) { : // do something } [x>1] L2.receive(MyMessage2) {} [x<=1] L2.receive(MyMessage3) {} [] MyAltstep; // call of a altstep [else] stop // else branch }

  37. Language Specifying test behavior –Interleaved behavior • Shorthand for all alternative permutations • All messages must be received, but in any order interleave { [] PCO1.receive(MyMessageOne) {} [] PCO1.receive(MyMessageTwo) {} [] PCO1.receive(MyMessageThree) {} }

  38. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  39. TE – TTCN-3 Executable SA – System Adapter PA – Platform Adapter CD – Coder/Decoder TM – Test Management CH – Component Handling SUT – System Under Test Overview –The TTCN-3 test system ETSI ES 201 873-1: TTCN-3 Core Language ETSI ES 201 873-5: TTCN-3 Runtime Interface (TRI) ETSI ES 201 873-6:TTCN-3 Control Interfaces (TCI)

  40. Overview –Implementing TTCN-3 TE TTCN-3Executable compile Abstract Test Suite build TTCN-3 Runtime System Executable Test Suite SUT +

  41. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  42. TTCN-3 presentation formats – Overall view IDL C/C++ TTCN-3 Core Notation Tabular Format ASN.1 Types & Values Other Types & Values 2 Other Types & Values 3 Graphical Format TTCN-3 User Presentation Format n UML Testing Profile Other Types & Values n XML

  43. The graphical presentation format of TTCN-3 Page 1(2) testcase MyTestCase (in boolean internetService,inout integer nrPass) runs on MtcType system TestSystemtype mtc P1 CP mCPtype mPCOtype MtcType var reportType report var default def := activate (MyDefault()) map(self:P1, System:mPCO) if (internetservice) newInternetPTC()

  44. U2TP – A test case Data partition sd invalidPIN {readOnly} Integer invalidPIN; { current.isPinCorrect(invalidPIN) == false } current hwe «sut» atm Setting a timer Stimulus storeCardData(current) Stopping a timer Observation t1(2.0) display(”Enter PIN”) t1 isPinCorrect(invalidPIN) isPinCorrect(invalidPIN) Duration constraint {0 .. 3} isPinCorrect : false isPinCorrect : false display(”Invalid PIN”) Function return value Setting arbitrated verdict display(”Enter PIN again”) «validationAction» pass

  45. Table of contents • Overall view of TTCN-3 • TTCN-3 en detail • Types and values • Behavior specification • Implementation of TTCN-3 • Presentation formats • Final remarks

  46. Applicability for different test phases Host/target tests System integration and system test User acceptance test Features required for a test automation solution Test design (low-level, high-level, graphical) Scheduling of test runs Centralized/distributed test runs Log/trace analysis Test case management Support of standards Legend for the table on next slide … feature must be supported in this test phase ()… feature should be supported fully colored field… feature supported by TTCN-3 hatched colored field… feature partly supported by TTCN-3 Managing TTCN-3 projects –Potential usage 1(2)

  47. Managing TTCN-3 projects –Potential usage 2(2)

  48. Language extensions mechanisms Packages and profiles Extended communication mechanisms Broadcast / multicast(edition 3.0.0) Synchronization / coordination (edition 3.0.0) Real-time extensions Absolute time support Time-constrained operations Better performance testing support Implicit test configuration Implicit communication Performance measurement TTCN-3 extensionsWork items in standardization

  49. Tool providers Danet DaVinci Communication Open TTCN Telelogic Testing Technologies Strategic Test Solutions Internal tools used by Nokia Ericsson Motorola Existing test devices with TTCN-3 support(for telecommunication applications) Alcatel A1100 Navtel InterWatch Nethawk Tektronix G20 Current TTCN-3 tool providers

  50. Conclusions • TTCN-3 finds its way into practice • Lots of interest from industry and academia • Mature TTCN-3 standard • Stimulates further research & development • New application domains, e.g. automotive • Real-time and performance testing • Test patterns • Still possibilities to shape the future TTCN-3

More Related