An Introduction To Ttcn3 Second Edition Colin Willcock Thomas Dei

An Introduction To Ttcn3 Second Edition Colin
Willcock Thomas Dei download
https://ebookbell.com/product/an-introduction-to-ttcn3-second-
edition-colin-willcock-thomas-dei-4306902
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
An Introduction To Ttcn3 Colin Willcock Thomas Dei Stephan Tobies
https://ebookbell.com/product/an-introduction-to-ttcn3-colin-willcock-
thomas-dei-stephan-tobies-984188
Archaeology An Introduction To The Worlds Greatest Sites Guidebook
Eric H Cline
https://ebookbell.com/product/archaeology-an-introduction-to-the-
worlds-greatest-sites-guidebook-eric-h-cline-10990448
An Introduction To Early Buddhist Soteriology Freedom Of Mind And
Freedom By Wisdom G A Somaratne
https://ebookbell.com/product/an-introduction-to-early-buddhist-
soteriology-freedom-of-mind-and-freedom-by-wisdom-g-a-
somaratne-44887694
An Introduction To Six Sigma And Process Improvement 2nd Edition James
R Evans
https://ebookbell.com/product/an-introduction-to-six-sigma-and-
process-improvement-2nd-edition-james-r-evans-44913594

An Introduction To Conservation Biology 3rd Edition Richard B Primack
https://ebookbell.com/product/an-introduction-to-conservation-
biology-3rd-edition-richard-b-primack-44975620
An Introduction To Bioanalysis Of Biopharmaceuticals Seema Kumar
https://ebookbell.com/product/an-introduction-to-bioanalysis-of-
biopharmaceuticals-seema-kumar-44992290
An Introduction To Knot Theory Graduate Texts In Mathematics 175
Softcover Reprint Of The Original 1st Ed 1997 Wbraymond Lickorish
https://ebookbell.com/product/an-introduction-to-knot-theory-graduate-
texts-in-mathematics-175-softcover-reprint-of-the-original-1st-
ed-1997-wbraymond-lickorish-44992914
An Introduction To The Theory Of Number 5th Edition Ivan Niven
https://ebookbell.com/product/an-introduction-to-the-theory-of-
number-5th-edition-ivan-niven-45136082
An Introduction To New Media And Cybercultures Pramod K Nayar
https://ebookbell.com/product/an-introduction-to-new-media-and-
cybercultures-pramod-k-nayar-45766740

AN INTRODUCTION
TO TTCN-3
An Introduction to TTCN-3, Second Edition.
Colin Willcock, Thomas Deiß, Stephan Tobies, Stefan Keil, Federico Engler and Stephan Schulz.
© 2011 John Wiley & Sons, Ltd. Published 2011 by John Wiley & Sons, Ltd. ISBN: 978-0-470-66306-6

AN INTRODUCTION
TO TTCN-3
SECOND EDITION
Colin Willcock and Thomas Deiß
Nokia Siemens Networks GmbH & Co. KG, Germany
Stephan Tobies
European Microsoft Innovation Center, Germany
Stefan Keil
Research In Motion Deutschland GmbH, Germany
Federico Engler
TeliaSonera CIS, Sweden
Stephan Schulz
Conformiq Inc., Finland
A John Wiley and Sons, Ltd., Publication

This edition first published 2011
© 2011 John Wiley & Sons Ltd.
LTE is a trademark of ETSI. LTE and LTE Advanced logos have been reproduced by permission of
ETSI – http://www.3GPP.org/
Registered office
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offices, for customer services and for information about how to apply for permission to
reuse the copyright material in this book please see our website at www.wiley.com.
The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright,
Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any
form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK
Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available
in electronic books.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and
product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective
owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed
to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding
that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is
required, the services of a competent professional should be sought.
Library of Congress Cataloging-in-Publication Data
An introduction to TTCN-3 / Colin Willcock . . . [et al.].
p. cm.
Includes bibliographical references and index.
ISBN 978-0-470-66306-6 (cloth)
1. Telecommunication systems–Testing–Data processing. 2. Computer
networks–Testing–Data processing. 3. Programming languages (Electronic
computers) I. Willcock, Colin. II. Title.
TK5102.84.I58 2011
005.13–dc22
2010037017
Print ISBN: 978-0-470-66306-6 (HB)
ePDF ISBN: 978-0-470-97791-0
oBook ISBN: 978-0-470-97790-3
ePub ISBN: 978-0-470-97789-7
Typeset by Laserwords Private Limited, Chennai, India

Contents
List of Figures xiii
List of Tables xv
About the Authors xxiii
Foreword xxv
Preface xxvii
Acknowledgements xxix
Abbreviations and Acronyms xxxi
1 Introduction 1
1.1 TTCN-3 as a Language 3
1.2 The Development of TTCN-3 5
1.2.1 Future Development 6
1.3 Summary 6
2 TTCN-3 by Example 7
2.1 TTCN-3 Test Suite 7
2.1.1 Problem Domain 7
2.1.2 Test Purpose 9
2.1.3 TTCN-3 Modules 10
2.1.4 Data Types and Messages 10
2.1.5 Components and Ports 13
2.1.6 A First Test Case 14
2.1.7 Handling Erroneous Situations 15
2.1.8 Default Behaviour 16
2.1.9 Multi Component TTCN-3 17
2.1.10 Procedure-Based Communication 19
2.2 TTCN-3 Test Systems 21
2.2.1 High-Level View of a Test System 23
2.3 Summary 24

vi Contents
3 Basic TTCN-3 25
3.1 Basic Constructs 25
3.1.1 Identifiers 25
3.1.2 Modules 26
3.1.3 Scope 26
3.1.4 Constants 27
3.1.5 Variables 28
3.1.6 Comments 28
3.1.7 Basic Data Types 28
3.1.8 Subtypes 29
3.1.9 Functions 30
3.1.10 Pre-Defined Functions 32
3.1.11 Parameters with Default Values 32
3.2 Basic Statements 34
3.2.1 Operators, Expressions and Assignments 34
3.2.2 The Conditional Statements 36
3.2.3 Loops 36
3.2.4 Labels and Goto 39
3.2.5 The log Statement 39
3.2.6 The Control Part 40
3.2.7 Preprocessing Macros 42
3.3 Summary 44
4 Single Component TTCN-3 45
4.1 Ports 46
4.2 Components 47
4.3 Test Cases 48
4.3.1 Main Test Component 48
4.3.2 Test Case Verdict 49
4.3.3 Test Case Invocation 50
4.3.4 Test Case Parameters 52
4.3.5 Test Case Behaviour 53
4.3.6 Test Case Termination 53
4.4 Templates 54
4.5 Message-Based Communication 55
4.5.1 Send 55
4.5.2 Receive 56
4.5.3 Check 57
4.5.4 Receive on Several Ports 59
4.6 Timers 59
4.7 Alt Statement 62
4.7.1 Boolean Guards 64
4.7.2 Repeat Statement 65
4.7.3 Alt Statements vs. Stand-Alone Blocking Statements 65
4.8 Altsteps 66

Contents vii
4.9 Default Altsteps 69
4.10 Functions 73
4.10.1 Restrictions on the Runs on Clause 75
4.11 Summary 76
5 Multi Component TTCN-3 77
5.1 Multi Component Test Case Example 78
5.2 Test Components 79
5.2.1 Main Test Component and Test System Interface 79
5.2.2 Parallel Test Components 81
5.2.3 Creation of Test Components 81
5.2.4 Alive Test Components 83
5.2.5 Component References 83
5.2.6 Stopping Parallel Test Components 86
5.2.7 Await Termination of Test Components 87
5.2.8 Checking Execution Status of Test Components 87
5.2.9 Verdict Computation 89
5.3 Mappings and Connections 89
5.3.1 Mappings 89
5.3.2 Connections 91
5.3.3 Many-to-One Mappings and Connections 91
5.4 Component Type Extension 94
5.5 Miscellaneous Port Operations 94
5.6 SUT Addresses 95
5.7 Putting the Pieces Together 95
5.8 Summary 98
6 Procedure-Based Communication 99
6.1 Procedure- versus Message-Based Communication 99
6.2 An Example – the Directory Service 100
6.3 Procedure-Based Communication in TTCN-3 100
6.3.1 Non-Blocking Signatures 103
6.4 Communication Operations 103
6.5 Procedure-Based Communication on the Client Side 104
6.5.1 The call Statement 104
6.5.2 The getreply Operation 105
6.5.3 The catch Operation 107
6.5.4 On Defaults, Deadlocks and Timed Invocations 108
6.5.5 Non-Blocking Use of the call Operation 110
6.6 Procedure-Based Communication on the Server Side 113
6.6.1 The getcall Operation 113
6.6.2 The reply Operation 115
6.6.3 The raise Operation 116
6.7 Addressing 116
6.8 Summary 119

viii Contents
7 Modular TTCN-3 121
7.1 Modules 122
7.1.1 Definition of a Module 122
7.1.2 Modularisation of TTCN-3 Test Suites 123
7.2 Group Definitions 123
7.3 Importing 124
7.3.1 Visibility of TTCN-3 Definitions 125
7.3.2 About Transitivity of Imports and Cyclic Imports 126
7.3.3 Restricting the Import of TTCN-3 Definitions 127
7.3.4 Module Prefixing of Imported Definitions 130
7.3.5 Transitive Import 131
7.3.6 Importing from Other Languages 131
7.4 Module Parameters 131
7.5 Attributes 132
7.5.1 Accessing Attribute Values 133
7.5.2 Scoping of Attributes 134
7.5.3 Assigning Attributes to Imported Definitions 135
7.5.4 Using Attributes to Define Encodings 135
7.6 Summary 137
8 TTCN-3 Data Types 139
8.1 The Session Initiation Protocol 140
8.2 Subtyping 141
8.2.1 Type Aliasing 142
8.2.2 Value List 143
8.2.3 Value Ranges 143
8.2.4 Field Value Restriction for Structured Types 144
8.2.5 Type Lists 145
8.2.6 Character Set Restrictions for Strings 145
8.2.7 Length Restrictions for Strings and List Types 145
8.2.8 Subtyping of Subtypes 147
8.2.9 Type Conversion 147
8.3 TTCN-3 Built-in Types 147
8.3.1 The Boolean Type 148
8.3.2 The Integer Type 148
8.3.3 The Float Type 150
8.3.4 The Charstring and the Universal Charstring Type 151
8.3.5 The Verdicttype Type 153
8.3.6 The Binary String Types Bitstring, Hexstring and Octetstring 153
8.3.7 The Default Type 155
8.4 User-Defined Types 155
8.4.1 The Enumerated Type 156
8.4.2 The Record Type 156
8.4.3 The Set Type 160
8.4.4 The Union Type 160
8.4.5 The List Types 162

Contents ix
8.5 Nested Type Definitions 168
8.6 Encoding and Decoding of Data 169
8.7 Summary 170
9 Advanced Type Topics 173
9.1 Type Compatibility 173
9.1.1 Strict Type Compatibility 174
9.1.2 Type Compatibility for Structured and Special Types 176
9.2 The Anytype Type 177
9.2.1 Using the anytype for Generic Protocol Definitions
and Data Types 180
9.3 The Address Type 181
9.4 Recursive Type Definitions 182
9.5 Foreign Type Systems 185
9.5.1 Using ASN.1 Types in TTCN-3 186
9.5.2 Using IDL Types in TTCN-3 190
9.5.3 Mapping XML to TTCN-3 191
9.6 Summary 195
10 Templates 197
10.1 A First Look at TTCN-3 Templates 197
10.2 The TTCN-3 Match Operation 199
10.3 Template Definition for One Specific Value 200
10.4 Template Definitions with Matching Expressions 201
10.4.1 The ‘any’ Matching Expression 201
10.4.2 Value Lists 201
10.4.3 Complemented Value List 202
10.4.4 Value Ranges 202
10.4.5 More about Matching Expression for Structured Types 204
10.4.6 More about Matching Expressions for List-Like Types 206
10.4.7 More about Matching Expressions for String Types 210
10.5 Template Definitions for Signatures 214
10.6 Assignment, Access of Templates and the Pre-Defined Functions
Isvalue and Valueof 217
10.7 Summary 219
11 Advanced Templates 221
11.1 Template Definitions for Complex Type Structures 221
11.2 Template References 223
11.3 Template Parameterisation 224
11.3.1 Value Parameters 224
11.3.2 Template Parameters 224
11.3.3 About the Use of Template Parameterisation 225
11.4 Selective Modification of Other Templates 225
11.5 Explicit versus Implicit Template Definitions 227
11.6 Restricting Template Usage 228

x Contents
11.7 Template Variables and Computing Functions 229
11.8 Structuring of Template Definitions for Complex Types 230
11.9 Summary 231
12 Extension Packages 233
12.1 Static Test Configurations 234
12.2 Real-Time in TTCN-3 237
12.3 Type Parameterisation 238
12.3.1 Value Parameterisation of Types 238
12.3.2 Types as Parameters 240
12.4 Behaviour Types 241
12.5 Summary 244
13 TTCN-3 Test Systems in Practice 245
13.1 The Anatomy of a TTCN-3 Test System 245
13.1.1 The TTCN-3 Executable 247
13.2 Test System Execution of a Simple Test Case 247
13.2.1 Test System and Test Case Initialisation 247
13.2.2 Preparation of Communication Channels towards the SUT 248
13.2.3 Handling of Communication towards the SUT 250
13.2.4 Starting of TTCN-3 Timers 250
13.2.5 Handling Incoming Communication from the SUT 251
13.2.6 Handling Timeouts and Stopping of Timers 252
13.2.7 Teardown of Communication Channels towards the SUT 252
13.3 More about the SUT Adapter 253
13.3.1 Execution Threads in the SA 253
13.3.2 Management of TRI Information 254
13.3.3 Procedure-Based Communication with the SUT 254
13.3.4 Dynamic SUT Adapter Configuration 254
13.3.5 Distributed SUT Adapter Implementations 255
13.4 More about the Platform Adapter 256
13.4.1 TRI Timing Operations 256
13.4.2 Non-Real-Time Implementation 256
13.4.3 External Functions 256
13.5 More about External Codecs 257
13.5.1 Access to the TTCN-3 Values 257
13.5.2 Encoder Implementation 258
13.5.3 Decoder Implementation 259
13.5.4 Advanced Aspects of Codec Implementations 259
13.6 Documentation Comments 260
13.7 Summary 261
14 Frameworks 263
14.1 Frameworks and Test Suites 263
14.2 TTCN-3 Libraries 264
14.3 Design of Frameworks 265

Contents xi
14.4 Example: the IPv6 Testing Framework 265
14.4.1 Module Structure and Identifiers 265
14.4.2 Test Case Functions 266
14.4.3 Test Purpose Functions 267
14.4.4 Protocol Library Functions 269
14.5 Summary 269
15 Advice and Examples 271
15.1 TTCN-3 Style Guide 271
15.1.1 Motivation 271
15.1.2 Examples 272
15.2 Suggestions for Modularisation 274
15.3 Template Specification for Complex Message Definitions 276
15.3.1 Example Implementation of a SIP Message Interchange 277
15.3.2 A SIP Type Definition 277
15.3.3 Specification of the Expected SIP Request 278
15.3.4 Specification of the 200 OK Response 278
15.3.5 About the Benefits of Smart Template Definitions 281
15.4 Useful Behaviour 283
15.4.1 Convert Conditions to Verdicts 283
15.4.2 Unexpected Messages 283
15.4.3 Waiting 285
15.4.4 Successful Altstep 286
15.4.5 Additional String Conversion Functions 287
15.4.6 Binary Addition 288
15.5 Test Component Synchronisation 288
15.5.1 Synchronisation with Alive Components 291
15.5.2 Synchronisation via a Protocol 292
16 LTE Testing with TTCN-3 301
16.1 LTE Description 301
16.2 LTE Test Suite 302
16.2.1 Test System Overview 302
16.2.2 LTE Test Suite Overview 303
16.2.3 Test Case Definitions 304
16.2.4 Test Behaviour Definition 305
16.2.5 EUTRA Parallel Test Component 305
16.2.6 Test Suite Module Structure 305
16.2.7 RRC Message Definitions 307
16.3 Summary 309
17 Closing Thoughts and Future Directions 311
References 313
Index 315

List of Figures
Figure 1.1 TTCN-3 presentation formats 4
Figure 1.2 An example of the tabular presentation format 4
Figure 1.3 An example of the graphical presentation format 5
Figure 2.1 The few steps needed to resolve a local host name 8
Figure 2.2 The steps of resolving a remote host name 9
Figure 2.3 A simple test purpose described with an MSC diagram 10
Figure 2.4 Logically, a name server has an application and a network interface 18
Figure 2.5 The configuration for our multi component test using four parallel
test components 19
Figure 2.6 A schematic overview of a TTCN-3 test system 23
Figure 3.1 Scope hierarchy 27
Figure 4.1 The ticket vending machine as the system under test 46
Figure 5.1 Entities in remote DNS name resolution 79
Figure 5.2 Message exchange for remote DNS name resolution 80
Figure 5.3 Test components in the DNS server test system configuration 83
Figure 5.4 DNS test system configuration after mapping 90
Figure 5.5 Test configuration with two client test components 92
Figure 13.1 Conceptual model of a TTCN-3 test system 246
Figure 13.2 Interaction of test system entities when executing the DNS test case 249
Figure 13.3 Interactions during DNS test system and test case initialisation 249
Figure 13.4 Interaction performed to set up UDP IP transport 249
Figure 13.5 Interactions performed to send a message to the SUT 250
Figure 13.6 Interaction for starting a timer 251
Figure 13.7 Interactions after reception of a message from the SUT 251
Figure 13.8 Interaction to stop a timer 252
Figure 13.9 Interaction in case of a timeout 252
Figure 13.10 Interaction to tear down a communication channel 253

xiv List of Figures
Figure 13.11 Test system with distributed SA implementation 255
Figure 14.1 Layered test suite implementation 265
Figure 14.2 Abstracted IPv6 test suite module structure with dependencies 266
Figure 15.1 Example SIP message exchange 277
Figure 15.2 Message based synchronisation with multiple test components 291
Figure 15.3 Synchronisation of test component execution with alive components 293
Figure 15.4 Message exchange to synchronise test components 294
Figure 15.5 Test configuration with synchronisation components 295
Figure 16.1 LTE architecture 302
Figure 16.2 LTE test system architecture 303
Figure 16.3 EUTRA component type 306

List of Tables
Table 2.1 Creating our first TTCN-3 module 11
Table 2.2 The definition of our DNS message type 12
Table 2.3 A send template for our DNS message type 12
Table 2.4 A parameterised send template for our DNS questions 13
Table 2.5 A parameterised receive template for our DNS answers 13
Table 2.6 The definition of our single port and single component 14
Table 2.7 Our first test case assumes the correct answer will arrive
without problems 15
Table 2.8 Our extended test case is now able to handle incorrect
incoming replies 16
Table 2.9 Our test case is now able to also handle missing answers 17
Table 2.10 Signatures for procedures and the definition of a
procedure-based port 20
Table 2.11 A parameterised template for the AddEntry signature 20
Table 2.12 Using procedure-based communication from inside a TTCN-3
function 21
Table 3.1 The main structure of a TTCN-3 module 26
Table 3.2 Examples of basic data types 29
Table 3.3 Subtyping of basic data types 30
Table 3.4 Basic use of functions 32
Table 3.5 Use of parameters with default values 33
Table 3.6 Priority of operators 35
Table 3.7 Use of basic expressions 35
Table 3.8 Chained if-else statements 36
Table 3.9 Example select-case statement 37
Table 3.10 Functions with parameters and a return value 38
Table 3.11 log, label and goto statements by example 39
Table 3.12 The complete host name look-up example 40

xvi List of Tables
Table 3.13 Named Basic Scope Units 43
Table 4.1 Types for the ticket vending machine 46
Table 4.2 Port types for the ticket vending machine 47
Table 4.3 Ports with several message types 47
Table 4.4 Interface of the ticket vending machine 48
Table 4.5 State of a test system 48
Table 4.6 A test case with empty behaviour 49
Table 4.7 Test cases setting the local verdict 49
Table 4.8 Test cases setting the local verdict and verdict reason 50
Table 4.9 Control part invoking test cases 51
Table 4.10 Upper bound on test case execution time 51
Table 4.11 A test case with parameters 52
Table 4.12 Using a component variable 53
Table 4.13 Template definitions 54
Table 4.14 Templates as parameters 55
Table 4.15 Send statements 56
Table 4.16 Receive statement 57
Table 4.17 Value redirection 58
Table 4.18 Check statements 58
Table 4.19 Receiving on several ports 59
Table 4.20 Timer declarations 60
Table 4.21 Timer start and expiration 61
Table 4.22 The alt statement 62
Table 4.23 An alt statement dealing with unexpected SUT behaviour 63
Table 4.24 Boolean guards 64
Table 4.25 Repeat statement to await enough cash 66
Table 4.26 Expansion of stand-alone blocking statements 66
Table 4.27 An altstep to wait for timer expiration 67
Table 4.28 Use of an altstep in an alt statement 67
Table 4.29 Altstep with local definition 68
Table 4.30 Use of several altsteps 69
Table 4.31 Optional statement blocks in altstep-branches 69
Table 4.32 Altstep receiving any message 70
Table 4.33 Default altsteps 70
Table 4.34 Alt statement with explicit defaults 71
Table 4.35 Altstep to check for timeout of component timer 71
Table 4.36 Stand-alone altstep 72

List of Tables xvii
Table 4.37 Test case with multiple defaults 72
Table 4.38 Function to describe behaviour 73
Table 4.39 Using a function defining behaviour 74
Table 4.40 Recursive function 74
Table 5.1 The test system interface for testing a DNS server 80
Table 5.2 A type definition for a main test component 81
Table 5.3 A test case definition including a reference to a test system interface 81
Table 5.4 The component type definition for parallel DNS test components 81
Table 5.5 Establishment of a test configuration with multiple test components 82
Table 5.6 DNS test component creation as alive components in variable
initialisation 82
Table 5.7 Parallel DNS test component behaviours 84
Table 5.8 Starting of parallel DNS test components 85
Table 5.9 Waiting for DNS test component termination 88
Table 5.10 The running operation 88
Table 5.11 Mapping of DNS component ports 89
Table 5.12 Unmapping of DNS ports 90
Table 5.13 Port and component definitions for transmitting time values 92
Table 5.14 Many-to-one connections and mappings 92
Table 5.15 Storing value and sender of a message 93
Table 5.16 Selective receive 93
Table 5.17 Specifying the recipient of a message 93
Table 5.18 Specifying a list of recipient’s for a message 94
Table 5.19 Component definitions using extension 94
Table 5.20 Logging of port status information 95
Table 5.21 Complete definition of tc remoteDNSResolution
with concurrent PTC execution 96
Table 5.22 Alternative test case specification using sequential test execution 97
Table 6.1 IDL description of the directory service 101
Table 6.2 The signature definitions for the directory interface 101
Table 6.3 TTCN-3 port definitions for procedure-based communication 102
Table 6.4 Setting John’s password 105
Table 6.5 Specifying constraints for the return value 106
Table 6.6 Parameter redirection 107
Table 6.7 Assignment notation for parameter redirection 107
Table 6.8 Return value redirection 107
Table 6.9 Catching exceptions 108

xviii List of Tables
Table 6.10 Constraining exception information 109
Table 6.11 Value redirection with catch 109
Table 6.12 Timed calls and catching a timeout exception 110
Table 6.13 Performing non-blocking calls 111
Table 6.14 Catching exceptions from non-blocking calls 111
Table 6.15 Getting replies from non-blocking functions 112
Table 6.16 Getting rid of pending replies and exceptions 113
Table 6.17 Setting fail verdict for any exception 113
Table 6.18 Accepting calls in TTCN-3 114
Table 6.19 Constraining accepted calls 114
Table 6.20 Redirecting incoming parameters 115
Table 6.21 Using addresses in procedure-based communication 117
Table 6.22 Accepting calls from specified components 118
Table 6.23 TTCN-3 definitions for the DirectoryManager interface 118
Table 6.24 Logging into the directory service 119
Table 7.1 Example module definitions for DNS protocol types 123
Table 7.2 DNS protocol type module definitions with groups 124
Table 7.3 Importing all definitions from another module 125
Table 7.4 Declaring other modules to be friends 126
Table 7.5 Example of mixed visibility 126
Table 7.6 Example of friend visibility 127
Table 7.7 Resolving a name clash between local and imported definitions 131
Table 7.8 Defining module parameters with and without default values 132
Table 7.9 Assigning encode or variant attributes 134
Table 7.10 Assigning attributes to whole groups or modules 135
Table 7.11 Assigning attributes when importing 135
Table 7.12 Example use of encoding attributes for textual encoding 136
Table 8.1 A SIP message inviting Bob to a call 140
Table 8.2 Bob’s SIP reply to the invitation 141
Table 8.3 Some examples for subtype violations 142
Table 8.4 Defining value lists 143
Table 8.5 Example field value restrictions for structured types 144
Table 8.6 Defining of and subtyping with type lists 145
Table 8.7 Character set restrictions 146
Table 8.8 String length units 146
Table 8.9 Comparing type-incompatible values is a type error 148
Table 8.10 Example of Boolean variables and Boolean operators 148

List of Tables xix
Table 8.11 Useful integer subtypes 149
Table 8.12 A slightly improved version of Euclid’s algorithm for the greatest
common divisor 149
Table 8.13 Using float2int 150
Table 8.14 Some examples for charstring and universal charstring literals 151
Table 8.15 Appending CR/LF to a charstring 152
Table 8.16 Defining and using enumerated types 156
Table 8.17 Record type definitions and values 157
Table 8.18 Partially defined record values 158
Table 8.19 Record types with optional fields 159
Table 8.20 Defining and using set types 160
Table 8.21 Defining and using union types 161
Table 8.22 Using ischosen 162
Table 8.23 Defining record-of types and values 164
Table 8.24 Element access for record-of value 165
Table 8.25 Defining and using arrays 165
Table 8.26 Partially defined arrays 166
Table 8.27 Matrix multiplication using arrays 167
Table 8.28 Defining set-of types and values 168
Table 8.29 Example nested type definitions 169
Table 8.30 Example use of encvalue and decvalue 170
Table 9.1 Correctly and incorrectly typed expressions 175
Table 9.2 Strict type compatibility for communication operations 176
Table 9.3 Using explicit types to disambiguate implicit templates 177
Table 9.4 Exploiting component type compatibility for function reuse and
invocation 178
Table 9.5 Using the anytype 178
Table 9.6 Correct and incorrect access to values stored in an anytype value 179
Table 9.7 Using the anytype in the presence of imported types 179
Table 9.8 A generic transport protocol, first attempt 180
Table 9.9 A generic transport protocol, second attempt 181
Table 9.10 Using address in sender redirection and addressing 182
Table 9.11 Using IP addresses for the address type 183
Table 9.12 A recursive type definition for binary trees, first attempt 183
Table 9.13 Using unions to define recursive types with finite values 184
Table 9.14 Recursively calculating the sum of node values in a BinaryTree 185
Table 9.15 Creating cyclic data structures with recursive types 185

xx List of Tables
Table 9.16 Data type definitions for DNS in ASN.1 187
Table 9.17 Importing ASN.1 modules into TTCN-3 188
Table 9.18 TTCN-3’s equivalent to the ASN.1 module from Table 9.16 188
Table 9.19 Correspondence between ASN.1 type as TTCN-3 types 189
Table 9.20 Using NULL type and value in TTCN-3 190
Table 9.21 IDL definitions for a simple directory service 191
Table 9.22 The result for mapping the DirectoryService IDL file to TTCN-3 192
Table 9.23 XML phonebook Schema 193
Table 9.24 XML phonebook Schema converted into TTCN-3 194
Table 9.25 Example of a TTCN-3 template using XML types 194
Table 9.26 The encoding of the phonebook entry template 195
Table 10.1 Example template definitions 198
Table 10.2 The definition of the simplified HostPort type 198
Table 10.3 Template definitions with constant reference and constant expressions 198
Table 10.4 Some simple example template definitions with matching expressions 199
Table 10.5 An example use of the TTCN-3 match operation 199
Table 10.6 Example template definitions for one specific value 200
Table 10.7 Example template definitions with the ‘any’ matching expression 202
Table 10.8 Example template definitions with value lists 203
Table 10.9 Example template definition with a complemented value list 203
Table 10.10 Example template definitions with a value range 204
Table 10.11 User-defined template definitions with any expression for fields 205
Table 10.12 Example template definitions with the ‘any-or-none’ expression 205
Table 10.13 Example template definition with ifpresent matching attribute 206
Table 10.14 Example template definition to omit a field 206
Table 10.15 Using ‘any-or-none’ in record of templates 207
Table 10.16 Matching for set of templates 208
Table 10.17 Example template definitions with length matching attribute 208
Table 10.18 Matching permutations 209
Table 10.19 Template definitions with superset and subset matching
expressions 210
Table 10.20 String template definitions with any matching expression 211
Table 10.21 Using the length matching attribute with strings 212
Table 10.22 List of TTCN-3 character escape sequences 212
Table 10.23 Text template definitions with character escape sequences 213
Table 10.24 Template definition with concatenation 214
Table 10.25 Text template definitions with regular expressions 215

List of Tables xxi
Table 10.26 Text string extraction using the TTCN-3 regexp operation 216
Table 10.27 Example signature template definitions 216
Table 10.28 Using valueof and isvalue 217
Table 10.29 Types and applicable matching expressions 218
Table 11.1 Verbose value template for a complex type 222
Table 11.2 Decomposition of a template definition with template references 223
Table 11.3 Template definitions with value parameters 225
Table 11.4 Template definition with template parameters 225
Table 11.5 Base template and modified template definitions 226
Table 11.6 Base template and modified template definitions with parameters 227
Table 11.7 Send operation with implicit DNS message template 227
Table 11.8 Template causing a runtime error 228
Table 11.9 Templates with restrictions 228
Table 11.10 Computing a template 229
Table 11.11 Implicitly setting template fields 230
Table 12.1 Static test configuration 235
Table 12.2 Creating a static test configuration 235
Table 12.3 Test case on static test configuration 236
Table 12.4 Executing a test case on a static test component 237
Table 12.5 Send message at specific time 237
Table 12.6 Retrieving the reception time 238
Table 12.7 Value parameterisation of types 239
Table 12.8 Instantiation of value parameterisation of a type 239
Table 12.9 Generic protocol definition with type parameter 240
Table 12.10 Use of type parameters 241
Table 12.11 Behaviour types for sorted trees of character strings 242
Table 12.12 Calling a parameter of a behaviour type 243
Table 12.13 Behaviour values 243
Table 13.1 The example DNS server test case 248
Table 13.2 TTCN-3 type definitions for the DNS message and a value 258
Table 13.3 Documenting a function 260
Table 14.1 Typical IPv6 test case function implementation 267
Table 14.2 IPv6 test purpose function 268
Table 14.3 IPv6 library function implementation 269
Table 15.1 Prefixes of identifiers 273
Table 15.2 Example modularisation of a protocol testing test suite 275
Table 15.3 An example structured SIP TTCN-3 protocol type definition 279

xxii List of Tables
Table 15.4 Definition and example use of SIP INVITE templates 281
Table 15.5 A SIP 200 OK response definition 282
Table 15.6 The INVITE message exchange 283
Table 15.7 A SIP INVITE and BYE message exchange 284
Table 15.8 Setting the verdict according to a Boolean condition 284
Table 15.9 Receive unexpected messages 285
Table 15.10 Wait for some time 285
Table 15.11 Wait without defaults 286
Table 15.12 Waiting without being interrupted 286
Table 15.13 Successful altstep 287
Table 15.14 charstring and universal charstring conversion
functions 288
Table 15.15 Conversion of a string to a float value 289
Table 15.16 Addition of bitstring values 290
Table 15.17 Example test synchronisation with alive test components 292
Table 15.18 Synchronisation message and port definitions 294
Table 15.19 General synchronisation component type for synchronisation slaves 295
Table 15.20 Common slave synchronisation function to wait to start
execution in a given phase 295
Table 15.21 Common slave synchronisation function for indicating the end
of a phase to the master 296
Table 15.22 Example use of common slave synchronisation functions 296
Table 15.23 Common function to manage slave component references 297
Table 15.24 General synchronisation component type for synchronisation master 297
Table 15.25 Common master synchronisation function to start a phase on
slave components 297
Table 15.26 Common master synchronisation function to wait for the end
of a given phase from all slaves 298
Table 15.27 Example use of master synchronisation functions 298
Table 16.1 Example test case from LTE test suite 304
Table 16.2 Definition of EUTRA PTC 306
Table 16.3 Test group areas for LTE test suite 307
Table 16.4 Example test step 308
Table 16.5 Example SRB template 308
Table 16.6 SRB_COMMON_REQ type definition 309
Table 16.7 C_Plane_Request_Type definition 309
Table 16.8 RRC_MSG_Request_Type definition 309

About the Authors
Colin Willcock
Colin Willcock is currently manager for 3GPP Radio Access Network Standardisation
at Nokia Siemens Networks. He received a BSc from Sheffield University in 1986,
an MSc from Edinburgh University in 1987, and a PhD in parallel computation from
the University of Kent in 1992. Colin was part of the core ETSI team that developed
the TTCN-3 language and spent many years leading and participating in the TTCN-3
language maintenance. In the past, he has worked on numerous standardisation efforts at
ETSI, ITU-T, and 3GPP, focusing on various aspects of formal specification languages.
He was the project leader for the European TT-medal project, which strove to improve
test methodology and languages for software-intensive systems and also lead the D-MINT
project, which aimed to improve test methodology and languages for software-intensive
systems and explored the use of model-based testing in an industrial context.
Thomas Deiß
Thomas Deiß is a Senior System Specialist at Nokia Siemens Networks. He received
an MSc in Computer Science and a PhD in Natural Sciences from the University of
Kaiserslautern in 1990 and 1999. He is currently specifying transport features for mobile
communication systems. Before joining Nokia Siemens Networks, Thomas developed
the Nokia Research Center TTCN-2 and TTCN-3-based test systems, developed course
materials and taught courses about TTCN-3, and has participated for several years in
TTCN-3 standardisation. He was a contributor to the European TT-medal and D-MINT
projects, which strove to improve test methodology and languages for software-intensive
systems and explored the use of model-based testing in an industrial context.
Stephan Tobies
Stephan Tobies is a Software Design Engineer at the European Microsoft Innovation
Center where he works on software verification. He received an MSc in Computer Science
and a PhD in Natural Sciences from the University of Technology in Aachen in 1998 and
2001. He has been actively involved with TTCN-3 until 2005 while working as a Senior
Research Engineer at Nokia Research Center. During that time, he has been a member of
ETSI Strategic Task Force 253, which was responsible for the maintenance and extension

xxiv About the Authors
of the TTCN-3 standard. He has been a lead developer of an industry-grade TTCN-3
tool and has been working in the area of TTCN-3 language development and test system
implementation.
Stefan Keil
Stefan Keil is a software developer at Research In Motion. He received an MSc in
Electrical Engineering from the Ruhr University in Bochum in 1996. Stefan has worked
for Alcatel as a programmer in the field of fixed line communications and a technical
trainer for broadband communication fibre technology. From 2000 to 2007 he worked as
a Research Engineer at Nokia Research Center in the area of test system implementation,
TTCN-3 tool development, and training. At Nokia Siemens Network he worked from
2007 to 2009 in software specification for base station software. In 2009 Stefan started
working for Research In Motion in the field of embedded software development on end
user devices.
Federico Engler
Until December 2004, Federico Engler has been a Principal Engineer at Nokia Research
Center. He studied computer science at Uppsala University from 1989 till 1993. After that,
he started working for Telelogic, where he was involved in standardisation issues around
TTCN-2, TTCN-3, and ASN.1, as well as TTCN-3 tool development. In January 2003,
Federico started working for Nokia in the area of automated test solutions, which involved
the mapping, documentation, and synchronisation of test-related activities at a Nokia-wide
level. He has also been involved in activities around improved visualisation and documen-
tation of tests and test results within Nokia. Federico is currently working for TeliaSonera
CIS where he leads the development of portal-based telecommunications applications.
Stephan Schulz
Stephan Schulz is currently the Chief Technology Officer at Conformiq Inc. He received
an MSc and PhD in Computer Engineering from University of Arizona at Tucson in
1997 and 2001. Prior to his positions at Conformiq he has worked as a resident testing
expert at ETSI’s Centre for Testing and Interoperability as well as a Senior Research
Engineer at Nokia Research Center. Throughout his career he has been consulting different
users and organisations on TTCN-3 deployment as well as test suite and test system
development. He has been an editor of the TTCN-3 Runtime Interface (TRI) standard,
lead TTCN-3 architect in various ETSI Specialist Task Forces, designer of ETSI’s official
TTCN-3 web site, and author of many publications on the testing of text-based protocols
with TTCN-3. He has been developing and teaching TTCN-3 courses as well as co-
chaired four TTCN-3 User Conferences. In 2010, he was elected chairman of ETSI’s
Technical Committee Methods for Testing and Specification which is overseeing TTCN-3
standardisation.

Foreword
TTCN first saw the light of day as a fledgling language in the mid-1980s. With a
major modernization of TTCN over 10 years ago, resulting in TTCN-3, it has arguably
progressed to be the de facto international standardised language for writing test
specifications for reactive systems. Here at ETSI, TTCN is the cornerstone of many
complex test specifications, covering a wide range of technologies, including 3GPP
LTE™
,1
Intelligent Transport Systems, eHealth, Voice Over IP and IPv6.
I had the pleasure of working with Dr. Colin Willcock and Professor Jens Grabowski
to produce the very first edition of the core specification of TTCN-3. Since that time, the
language has gone from strength to strength. It has a growing body of users, good tool
support and, most importantly, a dedicated and very active maintenance team. Indeed,
TTCN-3 is a living language, continuous improvements and the addition of new features,
demanded by the user community, means that this book too has been updated. This second
edition addresses those new features admirably.
As is common with any programming language, the language specification is often
not the first place a user will go to learn her new craft. Often, this will be done by
reading a good textbook (or at least looking at the examples). Unfortunately, the TTCN-3
community has not had this luxury – until now, that is. This very first TTCN-3 book
fulfils a long-awaited need and I see its publication as a milestone in the evolution of the
language. The authors of this book are uniquely qualified to explain the details of TTCN-3
as applied to practical, real-life situations. They have a wide experience of contributing
to the development of TTCN-3, building TTCN-3 tools and test systems and using the
language in serious commercial projects, ranging from mobile communications to the
automotive industry.
The essence of TTCN-3 is really quite simple, which partly explains its increasing
popularity. The early chapters of this book capture this essence and provide the novice
reader with a clear and intuitive introduction to the language. For the more demanding
reader, subsequent chapters delve into the language in greater depth.
This excellent book is likely to be regarded as the definitive TTCN-3 user’s companion
for many years to come.
Anthony Wiles
European Telecommunications Standards Institute (ETSI)
1 ™LTE is a trade mark of ETSI.

Preface
At this point in time, nearly 10 years after the first TTCN-3 core language standard was
published and 5 years after the first version of this book appeared it seems the right
moment to bring out a new revised and extended version. In this second version of the
book we have integrated the 4000+ change requests that have been added to the language
since the first version of the book came out. In addition we have added a new chapter on
testing frameworks and a new chapter explaining LTE [1] testing using TTCN-3.
Looking back over the 10 years, I feel somewhat like a parent to the language. I was
there all those years ago at its inception and I look back to those early days with nostalgia
and affection. It was a pleasure to work in that small focused team at ETSI trying to define
and develop a global testing language. Like any child we had high hopes for TTCN-3, but
also great uncertainty of whether it would ever match those hopes and aspirations. After
the first standards were published, there followed a hectic period of dissemination and
one important milestone following another. The official TTCN-3 launch event, the first
commercial TTCN-3 tool set, the TT-Medal European project, the first TTCN-3 book,
the further development and maintenance of the language at ETSI. I had the pleasure of
leading or involvement in all these development steps along the way.
Now, 10 years later the TTCN-3 language has grown, both in terms of use and func-
tionality to become a global testing language in terms of geography and a wide spread
testing technology in terms of industrial domains where it is used. TTCN-3 and automated
software testing are no longer the major focus for me, with others taking over the mantel
of maintaining and extending the language. To use the parent analogy, I feel the child is
now making its own way in the world without me. However it is still with a certain pride
and affection that I watch the success of the language from the side lines.
Colin Willcock
Nokia Siemens Networks (NSN)

Acknowledgements
We would like to thank those people without whom this book would never have been
written. First and foremost are our families and friends, who supported us and bore our
(physical or mental) absence while we wrote this book. Next we would like to thank
the people in the ETSI task forces who have shaped TTCN-3 and continue to advance
the language and its use in many areas. We would also like to thank the European ITEA
programme, which has supported the transfer of TTCN-3 technology to European industry
through the TT-Medal project. Lastly, we would like to thank the test engineers in our
companies with whom we have worked and whose application of TTCN-3 in the real
world has contributed much to our TTCN-3 experience.

Abbreviations and Acronyms
The text in this book contains a number of abbreviations and acronyms. The list below
describes all their meanings in one single place.
ASN.1 Abstract Syntax Notation One
CORBA Common Object Request Broker Architecture
DNS Domain Name System
EMM Evolved Mobility Management
EPS Evolved Packet System
ETSI European Telecommunication Standardisation Institute
FTP File Transfer Protocol
GSM Global System for Mobile Communications
IDL Interface Definition Language
IP Internet Protocol
ISO International Standardisation Organisation
ISP Internet Service Provider
IMS IP Multimedia Subsystem
IUT Implementation Under Test
ITU-T International Telecommunication Union – Telecommunication
Standardisation Sector
HTTP Hyper Text Transfer Protocol
LTE Long Term Evolution
MAC Medium Access Control
MSC Message Sequence Chart
MTC Main Test Component
NAS Non-Access Stratum
OMA BCAST Open Mobile Alliance Mobile Broadcast Services Enabler Suite
OMG Object Management Group
PA Platform Adapter
PTC Parallel Test Component
RAT Radio Access Technology
RFC Request For Comments

xxxii Abbreviations and Acronyms
RLC Radio Link Control
RPC Remote Procedure Call
RRC Radio Resource Control
RTS RunTime System
SA SUT Adapter
SIP Session Initiation Protocol
SMTP Simple Mail Transfer Protocol
STF Specialist Task Force
SUT System Under Test
TCI TTCN-3 Control Interface
TCP Transmission Control Protocol
TE TTCN-3 Executable
TETRA Terrestrial Trunked Radio
TRI TTCN-3 Runtime Interface
TSI Test System Interface
TTCN-3 Testing and Test Control Notation Version 3
UDP User Datagram Protocol
UE LTE User Equipment or mobile device
UTRA Universal Terrestrial Radio Access
VHDL Very High Speed Integrated Circuit Hardware Description Language
WiMAX Worldwide Interoperability for Microwave Access
XML Extensible Markup Language
XSD XML Schema

1
Introduction
The Testing and Test Control Notation Version 3 (TTCN-3) is an internationally
standardised language for defining test specifications for a wide range of computer
and telecommunication systems. It allows the concise description of test behaviour by
unambiguously defining the meaning of a test case pass or fail. The predecessor of
TTCN-3, TTCN-2, has been used successfully for over a decade, mostly in testing
telecommunications systems. In this third revision of TTCN, the best parts of the
previous testing language have been combined and extended with a powerful new
textual syntax to create a universal testing language whose application area is no longer
restricted to testing telecommunication systems.
Five years after the publication of the first edition of this book a lot of things have
happened in the TTCN-3 community. TTCN-3 is celebrating its 10th anniversary and has
grown into a 10 part standard with four extension packages to date. It has grown into a
global testing language used well beyond telecommunication and standardisation. We are
witnessing a rapid uptake of the language in Asia – especially India and China – which
today provides already more than 40% of all testing services worldwide. TTCN-3
has established itself in the automotive and medical domain, with the banking sector
promising to be the next big application area. The continued success and propagation
of the language is visible in the annual international TTCN-3 User Conference which
reflects these developments. In addition, TTCN-3 has further strengthened its position
in standardisation and is used increasingly for certification and acceptance testing: In
telecommunication, the third Generation Partnership Program (3GPP) [2] has decided to
perform all of their future test suite development including their prestigious test suite for
Long Term Evolution (LTETM1
) [1] /4G terminals using TTCN-3 (see Chapter 16). The
Open Mobile Alliance (OMA) [3] is using TTCN-3 for their test suite development in
service provision and broadcasting across mobile networks. The WiMAX Forum [4] is
using TTCN-3 for certifying the conformance of terminals and the interoperability of
terminals and network elements. In the automotive domain, the influential AUTOSAR
consortium [5] – composed of all the major car manufacturers, suppliers and service
1 ™LTE is a trade mark of ETSI.

2 An Introduction to TTCN-3
providers – has adopted TTCN-3 for the specification of its compliance test suites.
And in the internet domain, TTCN-3 test suites are used in the context of certification
of the IPv6 ready program [6]. Last but not least the European Telecommunication
Standardisation Institute (ETSI) is continuing to use TTCN-3 in a wide range of
application areas including Next Generation Networks (NGNs), electronic passport, radio
technology as well as evaluating test execution traces at their interoperability events [7].
This book provides a solid introduction to the TTCN-3 language and its use. All the
important concepts and constructs of the language are explained in a tutorial style, with
the emphasis on extensive examples. This book also introduces the larger picture of how
the testing language is related to the overall task of test system implementation. By doing
so, it becomes the perfect companion to the available TTCN-3 language standards [8–21],
filling the gaps like style guide, structuring and application. In addition, this book points
out some of the dangers and pitfalls of TTCN-3 on the basis of our personal TTCN-3
experience from language standardisation, tool implementation and applying TTCN-3 for
a number of years in the real world. The style and level of this book make it suitable
for both engineers, learning and applying the language in the real world, and students,
learning TTCN-3 as part of their studies. Although this book is intended to be accessible
to a wide audience, it does assume that the reader has some basic knowledge of soft-
ware programming.
This second edition of the book has been updated and revised to cover the additions,
changes and extensions to the TTCN-3 language since the first version was published.
In addition to this extensive new material caused by language evolution the book also
contains a new section on testing frameworks and a major new example domain: LTE
testing using TTCN-3. This domain is not just covered in the text but also in the form of
downloadable tools and a test suite. This book is structured to present concepts in an
order that offers the quickest start to the efficient use of the TTCN-3 language. In
Sections 1.1 and 1.2, we discuss the advantages of using TTCN-3. Chapter 2 then goes
on to introduce a complete example to get a first hands-on impression of the language
and lists all the additional parts that are necessary to transform the TTCN-3 code into
a working test system. In Chapter 3, we then move on to present the basic language
concepts of TTCN-3, including basic types, operators and expressions, as well as the
language constructs for control flow. In Chapter 4, the subject of test specification in
TTCN-3 is considered in more detail by discussing the language constructs that are
most commonly used for non-concurrent testing. Test cases, test verdicts and message-
based communication are a few of the topics that are considered. Concurrent TTCN-3 is
described in Chapter 5; the key issues considered are the usage and synchronisation aspects
of test components. The importance of procedure-based communication is highlighted by
providing a separate chapter, Chapter 6, which provides an in-depth discussion of this
communication paradigm. Chapter 7 considers the issue of modularity, which is needed
to address the issues of code re-usability as well as multi-user development. Chapter 8
provides a thorough introduction to the TTCN-3 type system, leaving more complex type
topics such as external type systems to Chapter 9. Templates and advanced aspects of
their use are brought up in Chapters 10 and 11. Chapter 12 considers TTCN-3 extension
packages in general and the extension package for real-time testing specifically. With all

Introduction 3
the language parts described in detail, Chapter 13 then provides a detailed description of
how TTCN-3 test systems work in practice. In Chapter 14 we consider frameworks for
testing and Chapter 15 can be seen as a utility chapter that provides a collection of code
examples and common sense advice. Chapter 16 rounds off the book by introducing LTE
testing using TTCN-3. This provides the link to the tools and test suite available on the
companion website which will enable you not just to read about TTCN-3, but actually
experiment with it.
1.1 TTCN-3 as a Language
TTCN-3 is a language designed specifically for testing. Many constructs are similar
to those in other programming languages but are extended with additional concepts
not available elsewhere. These concepts include built-in data matching, distributed test
system architecture and concurrent execution of test components. TTCN-3 has a larger
type system than normal programming languages and includes native types for lists, test
verdicts and test system components. In addition, TTCN-3 provides direct support for
timers as well as for message-based and procedure-based communication mechanisms.
TTCN-3 is an internationally standardised test language [8–21]. Within these
documents, the meaning of each and every language element is clearly and precisely
specified. This means that a test script written in TTCN-3 is unambiguous. This precise
definition of the language also leads to tool vendor independence, since every tool should
execute a given test case in exactly the same way. Tool vendor independence facilitates
easy moving from one TTCN-3 toolset to another and greatly helps in testing projects
where test tools from different vendors are used in parallel. The language is designed to
provide a single general-purpose testing language suitable for a wide range of testing
applications. It can be used across the whole product development cycle. In this way,
TTCN-3 can provide major benefits in terms of return on investment in testing tools,
training and, naturally, product quality.
At its heart, TTCN-3 has a powerful, intuitive textual format for defining test scenarios,
that is similar to conventional procedural programming languages. This textual format is
referred to as the TTCN-3 core notation [8]. This book concentrates on this core notation,
with the following chapters describing in detail its syntax and use.
In addition to the core notation, TTCN-3 also supports the specification of test scenarios
using other presentation formats. A TTCN-3 presentation format provides an alternative
way of specifying test scenarios visually or in a context-specific manner. All presentation
formats can be converted into the core notation while preserving their meaning as shown
in Figure 1.1. Two presentation formats have been standardised initially. The standardised
tabular presentation format [9] was designed to give the test developers the ‘look and feel’
of the existing TTCN-2 tabular format. This format was introduced to provide an easy
migration path for existing TTCN-2 users into the TTCN-3 world. An example is shown
in Figure 1.2. The graphical presentation format [10] uses an extended version of an
MSC-like Message Sequence Charts [22] notation for specifying test scenario behaviour
as shown in Figure 1.3. Neither of the two presentation formats has gained acceptance
by the TTCN-3 community. Therefore they are not considered further in this book.

Tabular
format
MSC
format
Text format
TTCN-3 User
Presentation
formatn
TTCN-3
Core
Language
Figure 1.1 TTCN-3 presentation formats.
Figure 1.2 An example of the tabular presentation format.

Introduction 5
Figure 1.3 An example of the graphical presentation format.
1.2 The Development of TTCN-3
The direct predecessor of TTCN-3, TTCN-2, was developed by ISO as part of the
overall methodology for testing protocol layers in the Open Systems Interconnection
(OSI) seven-layer architecture [23]. TTCN-2 was first standardised in the late 1980s by
ITU-T [24] and ISO [25]. It has been successfully applied within the area of confor-
mance testing for telecommunications protocols. Nevertheless, a number of problems and
shortcomings were limiting its possibilities to be used as a more general purpose testing
language. In 1998, ETSI, the European Telecommunication Standardisation Institute, set
up the Specialist Task Force (STF) 133 to develop a new improved version of TTCN,
taking the known issues into account. This action resulted in the birth of TTCN-3. Over
the following two years, the TTCN-3 language was developed with the involvement and
input of most of the major tools and telecommunication companies. The official launch
of the TTCN-3 language took place in October 2000 at Sophia Antipolis, France.
When developing TTCN-3, four major areas of improvement needed to be considered
and addressed in relation to TTCN-2. These areas were productivity, expressive power,
flexibility and extensibility.
The aspect of productivity was simply addressed by developing the core language
to resemble other well-known, modern programming languages. By making TTCN-3 a
textual language, it made it easier for users to edit and learn the new concepts. TTCN-3
also provides significantly extended functionality that makes the language powerful and
suitable for a wider range of testing applications. Some of these extensions include better
support of new types of testing such as special constructs and features for the testing
of IP-based systems and text-based protocols like Session Initiation Protocol SIP [26].

Another major extension provides support for testing systems based on remote procedure
calls, using, for example CORBA or web services.
Finally, TTCN-3 is extensible: TTCN-3 has explicit hooks and mechanisms built-in
to the language that allow new features and notations to be easily integrated. Some
new features are self-contained, for example the integration of IDL [27] and XML [28]
type definitions as well as the definition of a common set of documentation tags. New
parts in the set of TTCN-3 standards have been defined for these features, see [14–16].
Other new features are more multi-faceted and require the extension of the notation,
the operational semantics, as well as other parts of the standard. Behaviour types, type
parameterisation, as well as test deployment support are examples of such multi-faceted
extensions. These extensions have been defined by separate extension packages, including
the relevant modifications to the core language, operational semantics and the other parts
of the TTCN-3 standards, see [17–19].
Both the introduction of new parts to the standard as well as the definition of extension
packages, allow new features to be introduced while keeping the core language stable.
1.2.1 Future Development
TTCN-3 was designed to be a general-purpose testing language that could be used in
many application areas. With time, this has spread its usage into many new fields where
standardised testing languages have not been used before. Using TTCN-3 in these new
areas has generated requests for additions to the language that can provide better support
for testing requirements from domains such as real-time testing or performance testing.
TTCN-3 is actively maintained through a well-defined change request process handled
by ETSI. The change request process provides a mechanism to balance the needs for
stability and backwards compatibility with the calls for extended functionality from new
users. Additionally, changes to TTCN-3 are well-documented and the reasoning behind
the changes can be followed.
1.3 Summary
In this introduction, we have briefly presented the background and most important
concepts of TTCN-3. We have seen that the language has a long history, which
originates from the world of telecommunications. In the past decade, the worlds of
telecommunications and the Internet have moved much closer together and the systems
to be tested are constantly becoming more dynamic and complex in their nature. To meet
these new challenges, the existing standardised test language, TTCN-2, was re-designed
and extended to result in TTCN-3. The following chapter introduces an example that,
even though simple in nature, contains many of the testing issues found in modern
communication systems.

2
TTCN-3 by Example
To properly introduce the most important concepts of TTCN-3, we will start by looking at
a real-life example. The example is based on the Internet’s Domain Name System (DNS)
[29] and aims at verifying that a DNS server is able to properly resolve host names to
their corresponding IP addresses. The example in this section is highly simplified in order
to allow us to focus on TTCN-3 related issues rather than on details of the particular
problem domain.
When referring to the implementation or element, that is to be tested, the term imple-
mentation under test (IUT) is often used. If the IUT is part of a larger system and we
can only communicate indirectly with the IUT and it is more appropriate to use the term
system under test (SUT). In this book, we will only use the term SUT, as this naming is
more general and applies also for the minimal case where we can talk directly with the
IUT, and the IUT is the same as the SUT.
In the following sections, we will present an initial test case, showing how to test
that a specific host name is correctly resolved. For this particular example, we will go
through the necessary definitions for data types, messages and test behaviour. We will
then extend this test case in three directions. Firstly, we will extend it to handle situations
in which the SUT does not behave as expected. Secondly, we will show how several
different interfaces of the SUT can be connected to different components of the test system
to allow us to test different parts concurrently. The third and last extension will show
how to use procedure-based communication as a potential complement to message-based
communication.
2.1 TTCN-3 Test Suite
2.1.1 Problem Domain
To create a good test solution from scratch, a test developer needs to understand the
problem domain. It is important to know the details about the information or messages
that are going to be exchanged, the interfaces that are going to be used, and of course the

particular behaviour that needs to be verified. For this purpose, this section introduces the
relevant aspects of the problem domain so that we can design a test solution that properly
reflects the relevant parts.
The Internet’s DNS is basically a large distributed database implemented by a world-
wide collection of so-called name servers. These name servers contain information that
allows applications to look up, in other words, resolve, the IP address for a given host.
The need for such a system is rooted in the difference between how humans and machines
handle information. Humans are good at handling images and simple names, but poor at
handling numerical data. Machines are the other way around. To bridge the gap between
these two worlds, the DNS hides IP addresses from humans and applications by allowing
them to refer to hosts using mnemonic names, such as "www.nokia.com". Applications
that need the IP number to perform a given action (for example Internet browsers with
HTTP [30], mail programs with SMTP [31] or file transfer applications with FTP [32])
can connect to a name server to obtain the IP address on the basis of the name they have
been provided with. This IP address is then used to connect to the remote machine.
Despite the enormous task of simultaneously resolving host names to IP addresses, the
DNS works (mostly) reliably and fast because of the beauty of its design. Every owner
of a subnet (for example Internet service provider (ISP) or company) is responsible for
maintaining two or more local name servers that know the IP addresses of all the hosts
within their own domain. If a user or application queries a local name server for the IP
address of a host within the same domain, the server will immediately be able to provide
an answer without the involvement of external DNS servers. The communication between
the client and the local name server for this simple case is depicted in Figure 2.1.
If a query involves resolving the name of a machine in an external domain, the local
DNS server will not immediately know the answer. Instead, it needs to turn to a so-called
root name server to get information about yet another DNS server that probably knows
the answer to the query. This more complex communication is depicted in Figure 2.2.
Even though the extra steps are not visible to the client, this situation needs to be
handled differently by the local name server. This approach clearly keeps the information
distributed in several places and for this reason requires a well-defined behaviour from
its individual components. Our first test case will now have a look at how we can test the
correct behaviour of a local name server that knows the IP address for a host within its
Figure 2.1 The few steps needed to resolve a local host name.

TTCN-3 by Example 9
Figure 2.2 The steps of resolving a remote host name.
own domain. We will, in this section, gradually extend the coverage of our test definitions
in order to allow us to deal with more and more complex situations.
2.1.2 Test Purpose
Understanding the problem domain is one of the major prerequisites for creating good
tests. Documenting and understanding which parts of the problem domain need to be
tested is an equally important requirement. A test purpose is a description that describes
in prose or in some more formal manner (for example message sequence charts (MSCs))
the objectives of a given test. Test purposes can be used both as documentation for
individual tests and as guidance for test writers that need to implement tests on the basis
of some kind of description. The choice of notation for test purposes is subject to ongoing
discussions, but as guidance, it can be useful to remember that the more informal a test
purpose description is, the greater is the risk that the description can be interpreted in
different ways by different people. Ambiguous descriptions are clearly something that
should be avoided at all costs.

Figure 2.3 A simple test purpose described with an MSC diagram.
In this chapter, we will be using simple MSCs like the one in Figure 2.3 to describe
the purposes of our tests. From this diagram, we can deduce that the test only involves
the tester and the local name server. We can also deduce that the test is performed by first
sending a query for "www.nokia.com" to the local name server, which should then
be followed by the reception of the correct IP address, which is 172.21.56.98. It is
of course possible to add more information to this MSC diagram and also to combine it
with prose to remove as much ambiguity as possible from the test description.
The problem we are trying to solve in our example is to test a local name server to
make sure it is able to correctly resolve both local and remote host names. The reason for
this is obvious. If our local name server is unable to function correctly, the communication
between machines in the subnet will break down completely, or communication will be
directed to unexpected partners. This is a serious situation that needs to be avoided by
properly testing the server before deployment in the network.
2.1.3 TTCN-3 Modules
Before we start developing our test cases, we need to know how we should structure
our test code. TTCN-3 code is collected in TTCN-3 modules. A module can contain test
definitions and also a control part that defines how the different tests are to be executed.
A module can import definitions from other modules, providing a flexible mechanism
for modularisation. To be able to start defining our data types, values and test cases, we
first need to create a module. Table 2.1 shows how this looks in TTCN-3 code. From the
figure you can also see that TTCN-3 comments may use both C and C++ style, that is a
comment is either enclosed with "/*" and "*/" or it reaches from a "//" to the end
of the line.
2.1.4 Data Types and Messages
Before we can define any test cases in our test module, we need to have a look at
the messages that are going to be exchanged between the test system and the SUT. The

TTCN-3 by Example 11
Table 2.1 Creating our first TTCN-3 module
/* --------------------------------------------------------------
* File: DNSTester.ttcn
* Desc: This is our small test suite for testing some simple name
* server behaviour.
* --------------------------------------------------------------
*/
module DNSTester {
// Here we will add our definitions.
// Here we will add our control part.
// The control part must come after the definitions.
}
communication between the client and the DNS server takes place by using DNS messages
[29]. Real DNS messages are rather complex, and we will not be going into the details
of them in this book. What we will do is to simplify such a message to a format that
better fits our simple example. In general, it is good to remember that the structure of
the messages to be exchanged is not arbitrary. The structure of these messages is often
defined by a standard or other document that describes in detail the implementation we
are about to test.
For our purposes, there are only two types of DNS messages. These are question and
answer messages. Furthermore, these messages have the same format so a particular flag
in the message is needed to indicate if the message is a question message or an answer
message. A DNS message also contains an identification field, that is a 16-bit integer
generated by the client application in order to allow the client to identify the answer for
a previously generated query. Real DNS messages also contain a body part that allows a
single DNS message to contain several questions or several answers simultaneously, but
in our example we limit the number of questions or answers in a single DNS message
to one.
Our DNS messages will be defined using the TTCN-3 record type. Records are used
to define ordered structured types that are collections of basic or other structured type
elements. In Table 2.2, our DNS message type is defined as a record that contains the
four elements that make up our simplified messages. To represent the message kind field,
we have used an enumerated type to create an enumeration with the two elements
e_Question and e_Answer. To improve the readability of our code, we use prefixes
for identifiers to give an immediate hint of what the identifier represents. Chapter 13
explains in further detail the naming conventions used throughout this book. The message
identification is represented with an integer field that has been subtyped to the range of
values that can be represented by 16 bits. Our question and answer fields are represented
as character strings. The answer element in our messages is marked optional as it will
not be present in DNS question messages.
Once we have defined the types we are going to use, we need to start thinking about
the actual instances of the types – the messages – that are going to be exchanged in
the test process. In TTCN-3, these ‘instances’ are called templates. Templates are used to
either transmit specific values or to test whether received values are contained in the set of

Table 2.2 The definition of our DNS message type
// Simple type definitions to match the protocol structure
type integer Identification( 0..65535 ); // 16-bit integer
type enumerated MessageKind {e_Question,e_Answer};
type charstring Question;
type charstring Answer;
// The definition of our DNS message type.
type record DNSMessage {
Identification identification,
MessageKind messageKind,
Question question,
Answer answer optional
}
expected messages, which are represented by a template specification. In our example, we
will be using templates for sending queries to the SUT and for matching incoming replies.
Templates are powerful because they allow not only specific values to be specified, but
also ranges, lists and matching attributes that together provide a compact and powerful
mechanism to describe sets of expected messages and provide automatic checking that
received data conforms to the specifications we have described. Templates will be handled
in more detail later on in this book. Here, we just introduce them briefly.
A template for a given type must specify a value or matching expression for each and
every field of its type. Table 2.3 shows the definition of a template for our DNS message
type. In this case, the template represents a DNS question as the messageKind field is
set to e_Question. The identification field is set to an arbitrary number, in this case
12345, and the question refers to the host name to be resolved: "www.nokia.com".
As a question must not contain an answer part, the answer field has been marked absent
with the attribute omit.
There is a drawback with our definition in Table 2.3 and, that is that the template is
rather hard-wired. When we want to send several questions to our DNS server by defining
them in this manner, it would mean that we would have to define a template for each
individual question, and each of these definitions would contain the same messageKind
Table 2.3 A send template for our DNS message type
// A possible template for the DNS message type.
template DNSMessage a_NokiaQuestion := {
identification := 12345,
messageKind := e_Question,
question := "www.nokia.com",
answer := omit
}

Table 2.4 A parameterised send template for our DNS questions
// A parameterized template for DNS questions based on DNSMessage.
template DNSMessage a_DNSQuestion( Identification p_id,
Question p_question ) := {
identification := p_id,
messageType := e_Question,
question := p_question,
answer := omit
}
Table 2.5 A parameterised receive template for our DNS answers
// A parameterized template for DNS answers based on DNSMessage.
template DNSMessage a_DNSAnswer( Identification p_id, Answer p_answer ) := {
identification := p_id,
messageType := e_Answer,
question := ?,
answer := p_answer
}
and answer field. To avoid these repeated definitions, we can use parameterisation to
allow a more flexible and reusable solution.
Table 2.4 shows a modification of a_NokiaQuestion. The template has been
renamed to a_DNSQuestion as it now can be reused for all DNS questions. Two
parameters have been added for those fields that change between different questions. The
first parameter is the identification number that needs to be different for each individual
question to allow correct mapping to incoming answers. The second parameter contains
the string with the actual host name we want to resolve. As a DNS question always
has the messageKind field set to e_Question, this particular field does not need
to be parameterised. This also applies to the answer field that always is omitted in
question messages.
We now also need to define a template for the expected DNS answers. Table 2.5 defines
a parameterised template, which is similar to a_DNSQuestion in Table 2.4. It contains
two parameters. The first one is for the identification number and the second is for the
string that represents the expected reply from the server. The messageKind field is fixed
as replies always have this field set to e_Answer and the question field is marked
with the matching attribute ?, which means that this field may contain any value, but that
we ignore what this value is. We can do this because the identification field contains the
same id as the outgoing question, and this allows us to couple them more effectively.
2.1.5 Components and Ports
With our data types and templates ready to be used, we now need to start looking at
the test solution from an architectural point of view. TTCN-3 allows a test developer to

Table 2.6 The definition of our single port and single component
// DNS messages are allowed to move in and out through ports of this type.
type port DNSPort message {
inout DNSMessage
}
// Our single component uses one single port to communicate with the SUT.
type component DNSClient {
port DNSPort serverPort
}
use a single or several test components to perform a testing task. The components can
communicate with each other and with the SUT. The points at which communication
takes place are called ports. A port is modelled as an infinite first-in-first-out (FIFO)
queue in the receive direction. The queue stores incoming messages or calls until they are
processed by the component that owns that particular port. Our initial example will only
use one single component and one single port to communicate with the SUT. Each port
has a type, which defines the used communication paradigm (message- or procedure-based
communication) and specifies the types of messages that can be sent and received by that
port. Table 2.6 shows how we can define a port type in TTCN-3. Our port type is called
DNSPort and uses message-based communication. The example specifies a port type that
can both send and receive messages of type DNSMessage. It is also possible within a
port type specification to only send messages of a certain type (out) or to only receive
messages of a certain type (in). In our example, the same type of DNS message is used
for questions and answers, so our port type allows DNS messages in both directions.
The single component for the initial example will only have a single port of type
DNSPort. The component is named DNSTester and contains one single port, which
we name serverPort, as shown in Table 2.6.
2.1.6 A First Test Case
We are now finally ready to start writing our first test case. This test case will be
very simple; indeed, it will be incapable of dealing with an erroneous SUT. For the
purpose of providing a simple example, we will assume that we are performing the
test within the nokia.com domain and that we are looking for the IP address of
www.research.nokia.com. From our test system, we will query the local name server
for this IP address and observe what actually happens.
Table 2.7 shows how small our initial test case turns out to be with the definitions
we have given so far. The test case is called tc_ExampleTestResolveNokia1
and runs on a DNSTester component. The test case initiates execution by sending
a DNS question via the serverPort port to the SUT asking for the IP address of
www.research.nokia.com. It then waits for a matching incoming answer that should
contain the IP address 172.21.56.98. In case such a message is received, the test case
sets the verdict to pass and stops execution. TTCN-3 allows you to set different verdicts

Table 2.7 Our first test case assumes the correct answer will arrive without problems
// Our first test case! This small test case will behave very poorly in case
// of an erroneous SUT. More about this later!
testcase tc_ExampleTestResolveNokia1() runs on DNSClient {
serverPort.send( a_DNSQuestion( 12345, "www.research.nokia.com" ) );
serverPort.receive( a_DNSAnswer( 12345, "172.21.56.98" ) );
setverdict( pass );
stop;
}
// Our small control part.
control {
execute( tc_ExampleTestResolveNokia1() );
}
on the basis of the results of a given test. The pass verdict is used to specify that a given
test has passed and the SUT has behaved as expected. The fail verdict is used to specify
that a given test has not passed because the SUT behaviour was not as expected. The
inconc verdict is used when it is impossible to deduce whether the observed behaviour
is a pass or a fail, for example because the test system was unable to communicate
with the SUT.
Observe finally that the test expects the incoming answer to contain the same identifi-
cation number that was sent out with the original question.
Now that we have defined our first test case, the last step to enable it to execute is to
call it. This test case execution is defined within the control part of the module. Table 2.7
shows the control part that is needed to run this single test case.
Our first test case turned out to be very compact and elegant, but it has a couple of
weaknesses, which we will have a look at in the following section.
2.1.7 Handling Erroneous Situations
The first problem with tc_ExampleTestResolveNokia1 that we need to address is
its inability to handle unexpected answers from the SUT. When a message arrives at the
port of our test system, the message is checked – in TTCN-3 terms matched – to see if
the incoming values conform to the template for the particular receive statement. In the
current test case, if an incorrect identification number comes in or an IP address does
not match what we are expecting, then the receive statement will block forever. The
received message will stay on top of the input queue without ever being removed because
there is no receive alternative that can match and remove an unexpected reply at this
point in the test case.
To resolve this situation, we can use the TTCN-3 alt construct, which allows us to
specify that several different alternatives of behaviour can take place at a given point. An
alt statement that contains several alternatives will block until any one of its alternatives
matches. If we extend our initial test case and add an alternative that will match incorrect
replies, the test case will not block in the same manner, and we will be able to state that

Table 2.8 Our extended test case is now able to handle incorrect incoming replies
// Our modified test case is now able to properly handle incorrect/invalid
// incoming messages.
testcase tc_ExampleResolveNokia2() runs on DNSClient {
serverPort.send( a_DNSQuestion( 12345, "www.research.nokia.com" ) );
alt {
// Handle the case when the expected answer comes in.
[] serverPort.receive( a_DNSAnswer( 12345, "172.21.56.98" ) ) {
setverdict( pass );
}
// Handle the case when unexpected answers come in.
[] serverPort.receive {
setverdict( fail );
}
}
stop;
}
the incoming message was not the expected one and thus the test has failed. Table 2.8
shows the modified test case. After the send statement, we have added an alt statement
that contains two alternatives. The first one is the same receive statement that we had in
our original test case. The second one is a receive statement without parameters, which
means that it matches any incoming message, which has not been previously matched by
any of the alternatives above it.
The test case in Table 2.8 is able to handle incorrect replies, but it does not cover
the case when a reply might never turn up. If the name server is down or seriously
congested for some reason, the test case will still be blocked until a reply comes in,
which might never happen. This situation needs to be handled in a better way and can be
resolved by using timers. If a timer is started when the DNS question is sent out, we can
specify that we require the incoming reply to show up within a given amount of time.
By catching timeouts, we can now extend our test case further to handle the problem of
missing replies, as shown in Table 2.9. A timer called replyTimer is started and set to
run for 20 seconds directly after the DNS question is sent. The alt statement has been
extended with a third alternative, that is able to catch a timeout from the timer if no reply
is received from the SUT within this time.
2.1.8 Default Behaviour
When reading the previous section, you will probably have noticed that TTCN-3’s way
of dealing with unexpected or untimely SUT behaviour could lead to considerable code
duplication: if, for every receive statement that can fail to match, we need to add at
least two additional cases to catch incorrect or missing responses, then our test cases will
soon grow out of proportion and become impossible to maintain or even understand. For
this reason, TTCN-3 contains a construct called default behaviour. Default behaviour can
be seen as a catch mechanism that allows the test author to handle unexpected situations
implicitly. Instead of having to write TTCN-3 code to handle these situations explicitly

Table 2.9 Our test case is now able to also handle missing answers
// Our test case is now able to handle incorrect replies as well as
// missing replies.
testcase tc_ExampleResolveNokia3() runs on DNSClient {
timer replyTimer;
server.send( a_DNSQuestion( 12345, "www.research.nokia.com" ) );
replyTimer.start( 20.0 );
alt {
// Handle the case when the expected answer comes in.
[] serverPort.receive( a_DNSAnswer( 12345, "172.21.56.98" ) ) {
setverdict( pass );
replyTimer.stop;
}
// Handle the case when unexpected answers come in.
[] serverPort.receive {
setverdict( fail, "Unexpected response from SUT" );
replyTimer.stop;
}
// Handle the case when no answer comes in.
[] replyTimer.timeout {
setverdict( fail, "No response since 20 sec from SUT" );
}
}
stop;
}
in each place where they may occur, the test author can do this in one single place and
define that such behaviour should be used implicitly when none of the explicitly available
alternatives matches. Default behaviour will be handled in detail later on in this book.
2.1.9 Multi Component TTCN-3
So far in this section, we have simplified things to make sure we only use one test
component and one port. In real-life testing, situations are often more complex than this,
involving more than one interface of the SUT. In many cases, tests that require access
to more than one interface can be adequately structured by having one dedicated test
component per interface. In the following example, we are going to extend the tests of
our name server so that we examine how the server behaves when it receives a query
that it is not able to answer itself. If such a query reaches a local name server, the server
consults a root name server to obtain the address of a third server, that is supposed to
know the answer (in the real world, some caching of recently resolved names is kept
within the local name server, but for the sake of our example, we assume that such a
cache does not exist and hence every non-local query leads to a request to a root name
server). Root name servers differ from local name servers in that they maintain extensive
lists of domains and of name servers responsible for those domains. The root name server
will in most cases not provide the final answer itself (root servers are few in the world

and need to avoid being congested), but will provide the address to an authoritative name
server for the domain that contains the host we are trying to look up. This means that
our local name server needs to first communicate with a root name server and then with
at least one more, remote DNS server to obtain a reply for the initial query. These steps
have been previously depicted in Figure 2.2.
If we take a closer look at our local name server, then it is connected to the Internet
via its network link, meaning one single point of physical connection. Logically, on the
other hand, the name server can be seen as having two kinds of interfaces. The first
interface is the interface used by clients or applications to query the server (usually via
User Datagram Protocol (UDP) port 53). The second interface is the network interface
that the server uses when it itself needs to place a new query. These two interfaces are
depicted in Figure 2.4.
It would be possible to extend our test case to test the scenario described above using
a single test component, but this requires the test case to handle all possible permutations
of message exchanges between the involved parts, and such a test case would explode in
size and become difficult to understand and maintain. It is far better to create multiple
test components that act as the client, the root name server, and the remote name server,
respectively. We will not show or develop the TTCN-3 code for such a multi component
solution this early in the book. We will rather just explain which steps need to be taken
in order to create this test solution.
Figure 2.4 identifies that our SUT has two different interfaces. These interfaces need
to be described at the TTCN-3 level in what is called the test system interface (TSI). The
TSI defines the common interface that different test components will share towards the
SUT when the tests are executed.
Once we have identified the TSI, we need to focus on the test components that are
going to take part in our tests. For the scenario we wish to test, we are going to use four
different test components. One component is called the Main Test Component (MTC) and
is responsible for creating the parallel test components needed for the test (as well as to
collect their individual verdicts and calculate a global, final verdict for the whole test).
In our example, we have decided that the MTC does not participate actively in the tests
itself, but there is no limitation in the language and you can decide to use a more ‘active’
MTC if you wish. Apart from the MTC, we are going to use three additional parallel test
components. One of them will take the role of a client sending the query that the local
Figure 2.4 Logically, a name server has an application and a network interface.

Figure 2.5 The configuration for our multi component test using four parallel test components.
name server is not able to answer on its own. This component will be connected to the
application interface of the SUT and run basically the same behaviour that we used in
the single component case. A second test component will act as the root server and the
third component will take the role of the remote name server, which the root name server
specifies as the authoritative server. These two last components will be connected to the
network interface of the SUT.
By default, the MTC is the first component that executes. It will start off by creating
the three parallel test components that we need for our test. Once these components are
created, the MTC will map their ports to the TSI as depicted in Figure 2.5. When this
configuration is established, the MTC will start different test behaviours on the different
test components. The two test components on the network side are passive and wait for
actions to take place from the SUT. The client component, on the other hand, is active and
will initiate the whole test when it starts to run. Each parallel test component will reach
its own, individual verdict reflecting its view of the test execution. The MTC will wait
until all parallel test components have terminated, and then (automatically) calculate the
final verdict.
2.1.10 Procedure-Based Communication
Until now, we have been looking at message-based communication. It is important to high-
light that TTCN-3 can also handle procedure-based communication. To give an example
of this, we will have a look at a different interface of the local name server that we can
control and combine with the tests we have previously defined. As we have learned so
far, a local name server keeps a table with mappings from host names to IP addresses

for its domain. Let us assume, for the purpose of our example, that the test system has
access to a management interface that allows it to control and manipulate the contents
of the name server table before or during the execution of tests. This would allow us to
control the presence or absence of entries in the mapping table and would provide us with
greater control and diversity over what we are testing.
In our example, we use procedure-based communication to manage the local name
server by using its available management software interface. We wish to make calls to this
interface to put the server in some defined initial state before the tests are initiated. To be
able to use procedure-based communication, we first need to define so-called procedure
signatures. These signatures give us information about the parameters that need to be
present in a call as well as information about return values or exceptions that might be
raised. We will use signatures to specify procedures in the SUT that can be called from
within the test system, but of course signatures can also be used the other way around,
meaning that the SUT can call procedures provided by the test system. In Table 2.10, we
see the signature definitions for three management procedures that allow us to clear the
mapping table, and to add and delete entries from the table. Following these definitions,
a procedure-based port type is declared so that only the test system can invoke these
procedures in ‘outgoing’ calls. If the keyword in had been used instead, it would have
meant the SUT was allowed to call the procedures in the test system.
To be able to call the procedures specified by these signatures, we now need to specify
signature templates in a similar way as is done for structured types in message-based
communication. Instead of referring to a type when creating these templates, we refer
to a signature instead. The elements in the template are then simply the parameters in
the signature. Table 2.11 shows how we can create a parameterised template for the
AddEntry signature.
Table 2.10 Signatures for procedures and the definition of a procedure-based port
// Our three signatures for the management of name table contents.
signature ClearTable () return boolean;
signature DeleteEntry( in charstring name ) return boolean;
signature AddEntry ( in charstring name, in charstring ip_addr )
return boolean;
// Our procedure-based port for remote management of table contents.
type port ManagementPort procedure {
out ClearTable, DeleteEntry, AddEntry
}
Table 2.11 A parameterised template for the AddEntry signature
// A parameterized template for the AddEntry procedure signature.
template AddEntry a_AddEntry( charstring p_name,
charstring p_ipAddress ) := {
name := p_name,
ip_address := p_ipAddress
}

Table 2.12 Using procedure-based communication from inside a TTCN-3 function
function f_ClearMappingTable( ManagementPort p_mgmtPort ) return boolean {
var boolean v_result;
// Make a call and wait a maximum of 10 seconds for a reply.
p_mgmtPort.call( a_ClearTable, 10.0 ) {
// If the reply takes place, save the return value and then return it
[] p_mgmtPort.getreply( a_ClearTable ) -> value v_result {
return v_result;
}
// If no reply shows up and we get a timeout, return false.
[] p_mgmtPort.catch( timeout ) {
return false;
}
}
}
Now that we have our procedure signatures and signatures templates, we are able to
start issuing calls to these procedures. Let us assume that our test cases, before starting
to communicate with the SUT on its client interface, first make sure to clear the server’s
mapping table and then initialise it with a set of known values. Table 2.12 shows how a
TTCN-3 function can be used to implement the part that clears the mapping table. The
function has no parameters but returns a boolean value depending on whether its actions
were performed successfully or not.
The function starts out by issuing the call to the ClearTable procedure, using the
a_ClearTable signature template. Observe that it is possible and recommended to use
a time limit for how long the test system will wait for a reply from the called procedure.
The code block following the call – the call statement’s body – is able to catch several
different reactions to the procedure call. In the best of cases, the procedure returns and
provides some kind of return value (if that has been specified in the signature). If for
some reason no reply is returned, the code in Table 2.12 is able to catch a timeout and
take following actions from that. It is also possible to specify in a signature definition if
the called procedure can raise exceptions of different kinds. If the procedure can do that,
the body of a call to such a procedure should also contain additional catch alternatives to
handle such exceptions.
In this example for procedure-based communication, we have only introduced how the
test system can issue calls to recipients outside the test system code. To make this test
example even more interesting, it would also have been possible to keep the mapping
table code inside the test system and allow the SUT to issue look-up calls that the tester
itself would have been able to answer in either correct or incorrect ways. Even if such an
example would have been interesting to show here, it is simply too complex to include
in this tutorial book.
2.2 TTCN-3 Test Systems
So far, we have introduced TTCN-3 code segments that together make up a collection
of simple tests. This collection is often referred to as a test suite and in this particular

case we refer to it as an abstract test suite. The reason it is abstract is because it lacks
any system-specific information, like how messages need to be encoded or how commu-
nication with the SUT actually takes place. In our simple examples, where we send and
receive messages, we are never talking about the details how these messages are sent in
the real world. We are not mentioning anything about the bits or bytes that are going
to be exchanged between test system and SUT, or via which media the transmission is
going to take place. This abstraction is valuable when creating a test suite as it removes
system-specific details from the description of the test case behaviour, but to end up with
real-life tests that execute and interact with the real SUT, we need to move from the
abstract world into the concrete one.
Like any other programming language, TTCN-3 code is not executable by itself. It
either needs to be interpreted or translated into some executable format. Additionally,
we have to add information that allows the tests to execute against the real SUT. The
following parts outside of the TTCN-3 code need to be provided.
• Codecs. The messages defined in our tests need to be encoded into some format, that
is understood by the SUT before they are sent. Conversely, received messages will be
decoded from their encoded form into TTCN-3 value representation.
• SUT adaptation. All our message exchanges in the abstract test suite are defined
as operations referring to a specific port. When we use a TTCN-3 construction like
serverPort.send( a_template ), we do not specify what serverPort actu-
ally represents in the real world. The mapping of what a TTCN-3 port actually represent
in the real world, and the mapping between TTCN-3’s communication mechanism and
that of the SUT, need to be done in the SUT adapter.
• Platform adaptation. To handle situations when messages go missing, we have
introduced the use of timers in some of our example test cases. As timers are
implemented differently on different platforms and in different testing scenarios
we sometimes require different notions of time, the actual timer implementation
needs to be provided by the test system developer. The calling of TTCN-3 external
functions is also platform specific and hence also needs to be provided by the test
system developer.
• Test management. TTCN-3 provides the test developer with a control part to
specify the order in which the tests in the test suite should be executed. This is an
acceptable approach for stable test environments, where the tests and their order
seldom change. This approach, however, is less acceptable for test systems where
it is important to be able to constantly introduce changes in test execution without
the need of time-consuming re-compilations. Test management can provide better
support for the creation of test campaigns or for the customisation of log formats and
log handling.
To make sure that the previously listed functionality is added in an ordered and
well-defined manner, there exist two additional standard documents that describe the inter-
faces that need to be used for this purpose. The first interface of interest is the TTCN-3
Runtime Interface (TRI) [12]. The TRI defines the operations for the SUT and platform

adapters, respectively. The second interface is the TTCN-3 Control Interface (TCI) [13].
The TCI focuses on issues around test management, logging, encoders and decoders.
2.2.1 High-Level View of a Test System
Figure 2.6 shows a high-level view that summarises the anatomy of a test system. For
a detailed description of this subject, please refer to Chapter 13. In this section, we will
briefly introduce these different parts to give you a better feel for the overall mechanics
of test execution.
The box labelled ‘Generated Code’ in the middle of the picture represents the behaviour
specified on the TTCN-3 level, but in a suitable executable form. The module on its
right represents the TTCN-3 runtime system, which implements the TTCN-3 operational
semantics [11]. These two modules are often referred to as the TTCN-3 Executable (TE).
Below these two modules, the TRI interface specifies a set of functions that are used
to allow abstract operational concepts such as communication and timers to be mapped
to the specific SUT and execution environment.
The TCI interface consists of four sub-interfaces. The test management interface
(TCI-TM) is used to control the creation and execution of tests. The coding/decoding
interface (TCI-CD) is used to allow for the specification of external codecs. The
User Interface
TM : Management TL : Logging
CH
:
C
o
m
p
o
n
en
t
H
an
dl
i
ng
CD
:
Co
D
e
c
Generated
Code
Runtime
System
SUT Adapter Platform Adapter
TC
I
–
C
H
TC
I
–
C
D
TRI
TCI – TM TCI – TL
TCI
Figure 2.6 A schematic overview of a TTCN-3 test system.

Another Random Document on
Scribd Without Any Related Topics

beautiful way of helping her neighbour would no doubt have been to
a certain extent impracticable amid the many occupations of the
Member's wife.
Perhaps the most difficult thing in Miss Marjoribanks's way at this
otherwise satisfactory moment was the difficulty she found in
persuading society, first of the reality, and then of the justice, of the
step she had taken. Most of them, to tell the truth, had forgotten all
about Tom Marjoribanks. It is true that when Lucilla's intentions and
prospects were discussed in Grange Lane, as they had been so
often, it was not uncommon for people to say, "There was once a
cousin, you know"; but nobody had ever given very much heed to
the suggestion. When Lucilla went to tell Mrs Chiley of what had
happened, she was but inadequately prepared for the surprise with
which her intelligence was received. For it all seemed natural enough
to Miss Marjoribanks. She had gone on very steadily for a long time,
without thinking particularly about anybody, and disposed to accept
the most eligible and satisfactory person who happened to present
himself; but all the time there had been a warm corner in her heart
for Tom. And then the eligible person had not come, and she had
been worried and wearied, and had had her losses, like most other
people. And it had always been pleasant to remember that there
was one man in the world who, if she but held out a finger to him
——But then the people in Grange Lane were not capable of
discrimination on such a delicate subject, and had never, as was to
be expected, had the smallest insight into Lucilla's heart.
"You have something to tell me, Lucilla?" said old Mrs Chiley. "You
need not say no, for I can see it in your eyes. And how lucky it is the
Colonel is out, and we can have it all to ourselves! Come here and
sit by me, and tell me all—every word."
"Dear Mrs Chiley," said Lucilla, "you can always see what one means
before one says a word. And it has all happened so suddenly; but
the very first thing I thought of doing was to come and tell you."

Mrs Chiley gave her young friend, who was leaning over her, a hug,
which was the only answer which could be made to so touching a
speech, and drew Lucilla down upon a low chair that had been
placed by the side of her sofa. She kept Miss Marjoribanks's hand in
her own, and caressed it, and looked at her with satisfaction in every
line of her face. After waiting so long, and having so many
disappointments, everything was going to turn out so entirely as it
ought to do at last.
"I think I know what you are going to tell me, my dear," said Mrs
Chiley; "and I am so pleased, Lucilla. I only wonder you did not give
me a hint from the very first. You remember I asked you when you
came here that snowy evening. I was a hard-hearted old woman,
and I dare say you were very vexed; but I am so glad to think that
the Colonel never stood out against him, but gave his consent that
very day."
This was the moment, if there ever was such a moment, when
Lucilla lost courage. Mrs Chiley was so entirely confident as to what
was coming, and it was something so different that was really
coming; and it was hard upon Miss Marjoribanks to feel that she was
about to disappoint everybody's expectations. She had to clear her
throat before she spoke—she who was generally so ready for every
emergency; and she could not help feeling for the moment as if she
was a young girl who had run away with somebody, and deceived all
her anxious friends.
"Dear Mrs Chiley, I am afraid I am not going to say what you
expected," said Lucilla. "I am very comfortable and happy, and I
think it's for the best; and I am so anxious that you should like him;
but it is not the person you are thinking of. It is——"
Here the old lady, to Lucilla's surprise, rose up upon her pillows and
threw her arms round her, and kissed her over again, and fell a-
crying. "I always said how generous you were, Lucilla," cried Mrs
Chiley. "I knew it from the first. I was always fond of him, you know;
and now that he has been beaten, poor dear, and disappointed,

you've gone and made it up to him! Lucilla, other people may say
what they like, but it is just what I always expected of you!"
This unlooked-for burst of enthusiasm took Lucilla entirely by
surprise. She could not say in reply that Mr Cavendish did not want
her to make it up to him; but the fact that this was the only
alternative which occurred to Mrs Chiley filled Miss Marjoribanks with
a sense of something like positive guilt. She had deceived
everybody, and raised false expectations, and how was she to
explain herself? It was with humility and embarrassment that she
spoke.
"I don't know what you will say when you hear who it really is," she
said. "He has been fond of me all this time, though he has been so
far away. He went to India because I sent him, and he came back as
soon as ever he heard about—what had happened. And what could I
do? I could not be so ungrateful or so hard-hearted again, as to
send him away?"
"Lucilla, who is it?" said Mrs Chiley, growing pale—for she generally
had a little wintry bloom on her cheek like the China roses she was
so fond of. "Don't keep me like this in suspense."
"Dear Mrs Chiley," said Lucilla, with the brevity of excitement, "I
don't see what other person in the world it could be but my cousin
Tom."
Poor Mrs Chiley started, so that the sofa and Lucilla's chair and the
very room shook. She said herself afterwards that she felt as if
somebody had discharged a pistol into her breast. She was so
shocked and startled that she threw off all her coverings and the
Afghanistan blanket Mrs Beverley had sent, and put her tottering old
feet to the floor; and then she took her young friend solemnly by
both her hands.
"Oh, Lucilla, my poor dear!" she cried, "you have gone and done it
without thinking what you were doing. You have taken it into your
head that it was all over, and that there was nothing more to look

for. And you are only nine-and-twenty, Lucilla; and many a girl
marries very well—better than common—long after she's nine-and-
twenty; and I know for a fact—oh! my poor dear child, I know for a
certain fact!—that Mr Ashburton was coming forward. He as good as
said it to Lady Richmond, Lucilla. He as good as said, as soon as the
election was over—and now you have gone and got impatient, and
thrown yourself away!"
Miss Marjoribanks was quite carried away for the moment by this
flood of sorrowful eloquence. She was silenced, and had nothing to
answer, and accepted it as in some respect the just penalty for the
disappointment she was causing everybody. She let Mrs Chiley say
out her say, and then she restored the old lady to her sofa, and
made her comfortable, and covered her up with all her wraps and
blankets. Though she ran on in a feeble strain all the time weeping
and lamenting, Lucilla took no notice. She wrapped her old friend
up, and put her pillows just as she liked them, and sat down again
on the low chair; and by that time the poor old lady had sunk into a
faint sob of vexation and disappointment, and had given her
remonstrances up.
"Now, I will tell you all about it," said Miss Marjoribanks. "I knew you
would be surprised; and if it would be any comfort to you, dear Mrs
Chiley, to know that Mr Ashburton did——"
"And you refused him, Lucilla?" Mrs Chiley asked, with horror in her
face.
"Ought I to have accepted him when there was somebody I liked
better?" said Lucilla, with the force of conscious virtue, "and you
used always to say just the contrary. One great thing that supported
me was, that you would be sure to understand. I did not know it at
the time," said Miss Marjoribanks, with sweet confidence and
simplicity, "but I see it all now. Why it never came to anything
before, you know, was that I never could in my heart have accepted
anybody but Tom."

Mrs Chiley turned round with unaffected surprise, which was not
unmingled with awe. Up to this moment she had been under the
impression that it was the blindness, and folly, and stupidity of the
gentlemen which had kept it from ever coming to anything. It was
altogether a new light that broke upon her now, confusing, though
on the whole satisfactory; but for the moment she was struck dumb,
and had no answer to make.
"I never knew it myself until—quite lately," said Miss Marjoribanks,
with confidential tenderness, "and I don't think I could tell it to any
one but you. Dear Mrs Chiley, you have always taken such an
interest in me! I sent him away, you know, and thought I was only
fond of him because he was my cousin. And then there were all the
others, and some of them were very nice; but always when it came
to the point—And it never came into my head that Tom was at the
bottom of it all—never till the other day."
Mrs Chiley was still so much confounded by this unexpected
revelation that it was some time before she could find her voice; and
even now the light penetrated slowly into her mind, and it was only
by degrees that she accepted the new fact thus presented to her
faith—that it was not the gentlemen who were to blame—that it was
all Lucilla's or rather Tom Marjoribanks's fault.
"And Mr Ashburton, Lucilla?" she asked faintly.
"I am very sorry," said Miss Marjoribanks, "very, very sorry; but I
don't think I can blame myself that I gave him encouragement, you
know. I may have been foolish at other times, but I am sure I was
very careful with him. It was all the election that was to blame. I
spoke very frankly to him," Lucilla added, "for I knew he was a man
to do me justice; and it will always be a comfort to me to think that
we had our—our explanation, you know, before I knew it was Tom."
"Well, Lucilla, it is a great change," said Mrs Chiley, who could not
reconcile herself to the new condition of affairs. "I don't mean to
pretend that I can make up my mind to it all at once. It seems so

strange that you should have been setting your heart on some one
all these ten years, and never saying a word; I wonder how you
could do it. And when people were always in the hopes that you
would marry at home, as it were, and settle in Carlingford. I am sure
your poor dear papa would be as much astonished as anybody. And
I suppose now he will take you away to Devonshire, where his
mother lives, and we shall never see you any more." And once more
Mrs Chiley gave a little sob. "The Firs would almost have been as
good as Grange Lane," she said, "and the Member for Carlingford,
Lucilla!"
As for Miss Marjoribanks, she knelt down by the side of the sofa and
took her old friend, as well as the blankets and pillows would permit,
into her arms.
"Dear Mrs Chiley, we are going to buy Marchbank and settle," said
Lucilla, weeping a little for company. "You could not think I would
ever go far away from you. And as for being Member for Carlingford,
there are Members for counties too," Miss Marjoribanks said in her
excitement. It was a revelation which came out unawares, and
which she never intended to utter; but it threw a gleam of light over
the new world of ambition and progress which was opened to
Lucilla's far-seeing vision; and Mrs Chiley could not but yield to the
spell of mingled awe and sympathy which thrilled through her as she
listened. It was not to be supposed that what Lucilla did was done
upon mere unthinking impulse; and when she thought of
Marchbank, there arose in Mrs Chiley's mind "the slow beginnings of
content."
"But, Lucilla," the old lady said with solemnity, as she gave her a last
kiss of reconciliation and peace, "if all Grange Lane had taken their
oaths to it, I never could have believed, had you not told me, that,
after all, it was to be Tom!"

Chapter the Last
This was the hardest personal encounter which Miss Marjoribanks
was subjected to; but when the news circulated in Grange Lane
there was first a dead pause of incredulity and amazement, and then
such a commotion as could be compared to nothing except a sudden
squall at sea. People who had been going peaceably on their way at
one moment, thinking of nothing, were to be seen the next buffeted
by the wind of Rumour and tossed about on the waves of
Astonishment. To speak less metaphorically (but there are moments
of emotion so overwhelming and unprecedented that they can be
dealt with only in the language of metaphor), every household in
Grange Lane, and at least half of the humbler houses in Grove
Street, and a large proportion of the other dwellings in Carlingford,
were nearly as much agitated about Lucilla's marriage as if it had
been a daughter of their own. Now that he was recalled to their
minds in such a startling way, people began to recollect with greater
and greater distinctness that "there was once a cousin, you know,"
and to remember him in his youth, and even in his boyhood, when
he had been much in Carlingford. And by degrees the Grange Lane
people came to see that they knew a great deal about Tom, and to
remind each other of the abrupt end of his last visit, and of his going
to India immediately after, and of many a little circumstance in
Lucilla's looks and general demeanour which this dénouement
seemed to make plain.
Lady Richmond, though she was a little annoyed about Mr
Ashburton's disappointment, decided at once that it was best to
ignore that altogether, and was quite glad to think that she had
always said there must be somebody. "She bore up a great deal too
well against all her little disappointments," she said, when discussing
the matter. "When a girl does that one may be always sure there is
somebody behind—and you know I always said, when she was not

just talking or busy, that there was a preoccupation in Lucilla's eye."
This was a speech which Mrs Woodburn, as might have been
expected, made a great deal of—but, notwithstanding, it had its
effect in Grange Lane. Going back upon their recollections, most
people were able to verify the fact that Miss Marjoribanks had borne
her little disappointments very well, and that there was sometimes a
preoccupation in her eye. The first was beyond dispute; and as for
the second, it was a thing which did not require a very great stretch
of imagination to suppose—and the unexpected sensation of finding
at last a distinct bit of romance to round off Lucilla's history, was
pleasant to most people. If she had married Mr Ashburton, it would
have been (so far as anything connected with Miss Marjoribanks
could be) a commonplace conclusion. But now she had upset
everybody's theories, and made an altogether original and unlooked-
for ending for herself, which was a thing to have been expected from
Lucilla, though nobody could have foreseen the special turn which
her originality would take.
And nothing could have come in more appropriately after the
election, when people felt the blank of ordinary existence just
beginning to settle down upon them again. It kept all Carlingford in
conversation for a longer time than might be supposed in these busy
days; for there was not only the fact itself, but what they were to do,
and where they were to go, to be discussed. And then Tom himself
began to be visible about Grange Lane; and he had heaps of Indian
things among his baggage, and recollected so affectionately the
people he used to know, and dispensed his curiosities with such a
liberal hand, that the heart of Carlingford was touched. He had a
way of miscalculating distances, as has been said, and exercised
some kind of magnetic influence upon all the little tables and
unsteady articles of furniture, which somehow seemed to fall if he
but looked at them. But, on the other hand, John Brown, who had in
hand the sale of Marchbank, found him the most straightforward and
clear-headed of clients. The two had all the preliminaries arranged
before any other intending purchaser had time to turn the matter
over in his mind. And Tom had the old brick house full of workmen

before anybody knew it was his. When the summer had fairly
commenced he went over and lived there, and saw to everything,
and went so far as to fit up the drawing-room with the same well-
remembered tint of pale green which had been found ten years ago
to suit so well with Lucilla's complexion. It was perhaps a little
hazardous to repeat the experiment, for green, as everybody knows,
is a very trying colour; but it was a most touching and triumphant
proof that to Tom, at least, Lucilla was as young as ever, and had
not even begun to go off. It was Mr Holden who supplied everything,
and he was naturally proud of the trust thus reposed in him, and
formed the very highest opinion of his customer; and it was probably
from his enthusiasm on this subject that might be traced the
commencement of that singular revolution of sentiment in Grange
Lane, which suddenly woke up all in an instant without knowing
how, to recognise the existence of Mr Marjoribanks, and to forget
the undue familiarity which had ventured upon the name of Tom.
When Lucilla went over in the most proper and decorous way, under
the charge of Aunt Jemima, to see her future home, the sight of the
village at Marchbank was sweet to her eyes. That it was not by any
means sweet to any other sense did but enhance Miss
Marjoribanks's satisfaction. "A year after this!" she said to herself,
and her bosom swelled; for to realise clearly how much she had it in
her power to do for her fellow-creatures was indeed a pleasure. It
occupied her a great deal more than the gardens did, which Tom
was arranging so carefully, or even than the kitchen, which she
inspected for the information of Nancy; for at that time the drawing-
room was not fitted up. Lucilla's eyes went over the moral wilderness
with the practical glance of a statesman, and, at the same time, the
sanguine enthusiasm of a philanthropist. She saw of what it was
capable, and already, in imagination, the desert blossomed like a
rose before her beneficent steps, and the sweet sense of well-doing
rose in her breast. And then to see Tom at Marchbank was to see his
qualities. He was not a man of original mind, nor one who would be
likely to take a bold initiative. Considering all the circumstances, that
was a gift which was scarcely to be wished for; but he had a perfect

genius for carrying out a suggestion, which, it need scarcely be
added, was a faculty that, considering the good fortune which
Providence had so long reserved for him, made his character as near
perfect as humanity permits. Lucilla felt, indeed, as she drove away,
that approbation of Providence which a well-regulated mind, in
possession of most things which it desires, might be expected to
feel. Other delusive fancies had one time and another swept across
her horizon; but after all there could be no doubt that only thus
could she have been fitly mated, and full development afforded to all
the resources of her spirit. As the carriage passed the Firs she
sighed and put down her veil with a natural sentiment; but still she
felt it was for the best. The Member for Carlingford must be a busy
man, occupied about his own affairs, and with little leisure for doing
good to his fellow-creatures except in a parliamentary way. "And
there are members for counties as well," Lucilla, in the depths of her
soul, said to herself. Then there rose up before her a vision of a
parish saved, a village reformed, a county reorganised, and a
triumphant election at the end, the recompense and crown of all,
which should put the government of the country itself, to a certain
extent, into competent hands. This was the celestial vision which
floated before Miss Marjoribanks's eyes as she drove into
Carlingford, and recollected, notwithstanding occasional moments of
discouragement, the successful work she had done, and the good
she had achieved in her native town. It was but the natural
culmination of her career that transferred her from the town to the
county, and held out to her the glorious task of serving her
generation in a twofold way, among the poor and among the rich. If
a momentary sigh for Grange Lane, which was about to lose her,
breathed from her lips, it was sweetened by a smile of satisfaction
for the county which was about to gain her. The lighter preface of
life was past, and Lucilla had the comfort of feeling that its course
had been full of benefit to her fellow-creatures; and now a larger
sphere opened before her feet, and Miss Marjoribanks felt that the
arrangements of Providence were on the whole full of discrimination,
and that all was for the best, and she had not lived in vain.

This being the case, perhaps it is not necessary to go much further
into detail. Mr Ashburton never said anything about his
disappointment, as might have been expected. When he did mention
that eventful day at all, he said that he had happened accidentally to
be calling on Miss Marjoribanks the day her cousin came home, and
saw at once the state of affairs; and he sent her a very nice present
when she was married. After all, it was not her fault. If Providence
had ordained that it was to be Tom, how could Lucilla fly in the face
of such an ordinance? and, at the same time, there was to both
parties the consoling reflection, that whatever might happen to them
as individuals, the best man had been chosen for Carlingford, which
was an abiding benefit to all concerned.
Under all the circumstances, it was to be looked for that Miss
Marjoribanks's spirits should improve even in her mourning, and that
the tenacity with which she clung to her father's house should yield
to the changed state of affairs. This was so much the case, that
Lucilla took heart to show Mrs Rider all over it, and to point out all
the conveniences to her, and even, with a sigh, to call her attention
to the bell which hung over the Doctor's bedroom door. "It breaks
my heart to hear it," Miss Marjoribanks said; "but still Dr Rider will
find it a great convenience." It was a very nice house; and so the
new Doctor's wife, who had not been used to anything so spacious,
was very willing to say; and instead of feeling any grudge against
the man who was thus in every respect to take her father's place, so
sweet are the softening influences of time and personal well-being,
that Lucilla, who was always so good-natured, made many little
arrangements for their comfort, and even left the carpets, which was
a thing nobody could have expected of her, and which Aunt Jemima
did not scruple to condemn. "They are all fitted," Lucilla said, "and if
they were taken up they would be spoiled; and besides, we could
have no use for them at Marchbank." It was a very kind thing to do,
and simplified matters very much for the Riders, who were not rich.
But Aunt Jemima, in the background, could not but pull Lucilla's
sleeve, and mutter indistinct remarks about a valuation, which

nobody paid any particular attention to at the moment, as there
were so many things much more important to think of and to do.
And the presents that came pouring in from every quarter were
enough to have made up for twenty carpets. Lucilla got testimonials,
so to speak, from every side, and all Carlingford interested itself, as
has been said, in all the details of the marriage, as if it had been a
daughter of its own. "And yet it is odd to think that, after all, I shall
never be anything but Lucilla Marjoribanks!" she said, in the midst of
all her triumphs, with a certain pensiveness. If there could be any
name that would have suited her better, or is surrounded by more
touching associations, we leave it to her other friends to find out; for
at the moment of taking leave of her, there is something consoling
to our own mind in the thought that Lucilla can now suffer no
change of name. As she was in the first freshness of her youthful
daring, when she rose like the sun upon the chaos of society in
Carlingford, so is she now as she goes forth into the County to carry
light and progress there. And in this reflection there is surely comfort
for the few remaining malcontents, whom not even his own excellent
qualities, and Lucilla's happiness, can reconcile to the fact that after
all it was Tom.
[1] It may be mentioned here that this was an engagement that
none of the friends approved of, and that it was the greatest
possible comfort to Miss Marjoribanks's mind that she had nothing
to do with it—either one way or another, as she said.
[2] It is only justice to Miss Marjoribanks to say that she was not
addicted to fine writing; but then she was a person who liked to
have everything in keeping, and naturally an emergency such as
the present does not come every day, and requires to be treated
accordingly.

*** END OF THE PROJECT GUTENBERG EBOOK MISS
MARJORIBANKS ***
Updated editions will replace the previous one—the old editions will
be renamed.
Creating the works from print editions not protected by U.S.
copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.
START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK
To protect the Project Gutenberg™ mission of promoting the free
distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.
Section 1. General Terms of Use and
Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.
1.B. “Project Gutenberg” is a registered trademark. It may only be
used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.
1.E. Unless you have removed all references to Project Gutenberg:
1.E.1. The following sentence, with active links to, or other
immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
1.E.2. If an individual Project Gutenberg™ electronic work is derived
from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.
1.E.3. If an individual Project Gutenberg™ electronic work is posted
with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.
1.E.4. Do not unlink or detach or remove the full Project
Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute this
electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1

with active links or immediate access to the full terms of the Project
Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.
1.E.7. Do not charge a fee for access to, viewing, displaying,
performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.
1.E.8. You may charge a reasonable fee for copies of or providing
access to or distributing Project Gutenberg™ electronic works
provided that:
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information

about donations to the Project Gutenberg Literary Archive
Foundation.”
• You provide a full refund of any money paid by a user who
notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.
• You provide, in accordance with paragraph 1.F.3, a full refund of
any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.
• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.
1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™
electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.
1.F.
1.F.1. Project Gutenberg volunteers and employees expend
considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or

damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.
1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for
the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.
1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you
discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.
1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.
1.F.5. Some states do not allow disclaimers of certain implied
warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.
1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,
the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.
Section 2. Information about the Mission
of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.
Volunteers and financial support to provide volunteers with the
assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

An Introduction To Ttcn3 Second Edition Colin Willcock Thomas Dei

More Related Content

Similar to An Introduction To Ttcn3 Second Edition Colin Willcock Thomas Dei (20)

Recently uploaded (20)

An Introduction To Ttcn3 Second Edition Colin Willcock Thomas Dei