140 likes | 340 Views
GFT The Graphical Format of TTCN-3. Ina Schieferdecker. GFT v2. Presents TTCN-3 behavior only Gives local view on test components Based on MSC Uses additional symbols e.g. for ports, altsteps, component handling Defines a one-to-one mapping (up to graphical placement) between CN and GFT
E N D
GFTThe Graphical Format of TTCN-3 Ina Schieferdecker
GFT v2 • Presents TTCN-3 behavior only • Gives local view on test components • Based on MSC • Uses additional symbols e.g. for ports, altsteps, component handling • Defines a one-to-one mapping (up to graphical placement) between CN and GFT • Aligned with TTCN-3 2nd edition
Just a small example altstepGuestDefault() runs on GuestType altstep GuestDefault() runs on GuestType { // *** // *** Purpose: Default behaviour for // *** message based ports // *** [] P1.receive(charstring : ?) { P1.send(standardConversation); repeat; } [] any timer.timeout { setverdict(fail); } [] any port.receive { setverdict(inconc); } } // *** Purpose: Default behaviour for // *** message based ports CP self P1 GuestType pCPtype gPCOtype alt charstring ? standardConversation fail inconc
GFT v2 Document • Main sections • Overview • GFT language concepts • Mapping between GFT and TTCN-3 Core Notation • Module structure • GFT symbols • GFT diagrams • Instances in GFT diagrams • Elements of GFT diagrams • Annex • Annex A (normative): GFT BNF • Annex B (normative): Reference Guide for GFT • Annex C (normative): Mapping Rules from GFT to TTCN-3 Core Notation • Annex D (normative): Mapping Rules from TTCN-3 Core Notationto GFT • Annex E (informative): Examples • Annex F (informative): GFT to MSC Mapping
GFT at ETSI • The STF 187 Team • Paul Baker (Motorola) • Zhen Ru Dai (Uni Lübeck) • Jens Grabowski (Uni Lübeck) • Tamas Kasza (Ericsson) • Claude Martin (Actimage) • Johan Nordin (Telelogic) • Ekkart Rudolph (Uni Munich) • Ina Schieferdecker (FOKUS) • One CR, but can be rejected • Some editorial things
GFT at ITU-T • Issues raised at the ITU-T meeting, March 2002 on Annex F: GFT to MSC mapping: TD0061, TD3043, TD0065 • Answers given to these documents in the resp. MTS#34 TDs • Problem: misconception of that annex at ITU-T • Some issues clarified to be wrong or non-issues • Still some open points • An agreement about the objectives of that annex is very likely • Proposal: • separate Annex F from GFT and make it a separate TR • Revision of this TR on a voluntary basis • Approve GFT (e.g. without Annex F)
ITU View ETSI View GFT Annex C Annex D TTCN-3 Core MSC Part 4 MSC Semantics (?) Other parts of corresponding TTCN-3 modules TTCN-3 Engine Part 4 TTCN-3 Semantics
GFT at OMG • UML Testing Profile RfP adopted in July 2001 • Initial submission submitted Apr., 1st 2002 by • Rational • Motorola • Softeam • Telelogic • Fraunhofer FOKUS • Ericsson • IBM • Uni Lübeck (officially a supporter) • Supporters • iLogix • 41 companies will vote
GFT at OMG • Initial submission • Terminology • Test behavior • Test architecture • No test data • Presentation (and discussion) at Orlando meeting, June 2002 • Next meeting in Lübeck, May 2002 • Final submission delayed after UML 2.0, planned for January 2003
GFT at OMG • Due to • Differences in syntax and semantics of ITU-T MSC and OMG Interaction Diagrams • Concept of using any behavioral diagram for test definition • Proposals from the software testing community • GFT cannot be taken as such (we have to „talk“ meta-model and UML syntax) • However, the UML testing profile will be semantically consistent (in terms of a mapping) with TTCN-3 • Additions • Logical partitions in the data part • Arbiters to separate behavior and verdict handling • Test architecture and initial test configuration • Implicit assumptions about e.g. verdict assignment and timer handling
Test architecture Test component classes SUT classes
Test Case Initial test configurations Test behavior
Test behavior Test behavior reuse Implicit default timer Test behavior invocation Implicit verdict setting
Test behavior Explicit verdict setting