Abstract Test Suites Development - A standard approach continued...

Abstract Test Suite - Contents

The TTCN is part of the ISO/IEC 9646 conformance-testing framework and is specially designed for the specification of tests of communication systems. The standard introduces the concept of abstract test suites (consisting of abstract test cases), a description of a set of test cases that should be executed for a system. The abstract tests are to be described using a formal language rather than informal language. TTCN is defined in order to describe the abstract test cases.

The reference of Abstract Syntax Notation (ASN.1) definitions from protocol specifications into TTCN ensures consistency between the information transferred in the system specification and test specification.

Abstract test suite consists of four parts,
Ø Suite Overview part
Ø Declarations part
Ø Constraints part
Ø Dynamic part

(a) Suites Overview part
The suite overview part is documentary feature comprised of indexes and page references. It contains table of contents and a description of the test suite, and its purpose is mainly to document the test suite to increase clarity and readability. The quick overview of the entire test suite is possible. The test suite overview consists of four tables:
· Test Suite Structure
· Test Case Index
· Test Step Index
· Default Index

(b) Declarations part
The declaration part is used for declaring types, variables, timers, PCO’s and test components. All the data types used in the test suite are declared in this section. The types can be TTCN or ASN.1 types. Declaring types in TTCN or ASN.1 is similar to type declarations in other programming language except that in TTCN or ASN.1 tables are used instead of files. The declarations part is concerned both with the definition of new (i.e. not predefined) data types and operations and the declaration of all the test suite components.

(c) Constraints Part
The constraints part is used for describing the values sent or received. The structured types PDUs and ASPs defined in the declarations part are used as models to describe the messages sent on PCO. The instances used for sending must be complete, but for receiving there is the possibility to define incomplete values using wildcards, ranges and lists. The constraint part contains the tables for all the ASP, PDU, structure and CM constraints both in the tabular form and the ASN.1.

(d) Dynamic Part

The actual tests are described in dynamic part. It contains all test cases, test steps, and default tables with test events and verdicts. The building blocks are test groups, test cases, test steps and test events. The dynamic part contains all the test cases, all the test steps in the test step library and the all the defaults in the default library.

Test Component










The test component comprises of the test group, test case, test events and test step.

Test event – is the smallest unit of test suite. It corresponds to sending and receiving of the messages and operations for manipulating timers.

Test step – grouping of test events, which is similar to subroutines and procedures in other programming languages.

Test case - fundamental building block in test suite. A test case tests particular feature or function in the implementation under test (IUT). Test case assigns a verdict depends on outcome of the test case.

Test group – grouping of test cases. The grouping can be done based on functionality or features. Test suite – highest level encompassing all the test components and serving as root of the tree.

Abstract Test Suites Development - A standard approach continued...

ISO 9646 and TTCN
ISO 9646 is a framework for conformance testing. ISO 9646 incorporates the TTCN language as ISO 9646-3. The ISO 9646 is a seven part standard as shown below















Testing Configuration or Architecture
One part of the standard is Test specification/Configuration. How is the test is set up, the responsibilities of different entities involved and the handling of the connections between these are all regulated in the standard.













PICS and PIXIT
The important item in the configuration of a test is to extract the abstract information from the test and this information can be provided during start up of the execution. The Protocol Implementation Conformance Statement (PICS) and Protocol Implementation Extra information (PIXIT) is structures as informal questionnaire. The answers can be mapped to parameters in TTCN and imported. PICS and PIXT contains different information.

PICS – It contains information regarding protocol. This could be optional parts, specific restrictions or adds-on. This information will serve as basis for determining which test cases are applicable.PIXIT – It contains information regarding physical set up and connection of the test that is not part of the protocol. This could be information regarding system under test hardware, socket.

Abstract Test Suites Development - A standard approach

INTRODUCTION

Over the years, the size and complexity of software in multi-process, distributed architecture systems running in different environment have grown dramatically. Verification & Validation has become an all-important activity in this context. The terms conformance and interoperability are both important characteristics for implementations. An implementation conforms if it meets all of the mandatory requirements of the written specification fully, and also meets those conditional requirements that it claims to meet. Conforming implementations have high probabilities of interoperating with other implementations conforming to the same specification.

Test suites formalize the means with which to establish conformance or interoperability. Test suites come in two forms: abstract and executable. A test suite comprises multiple test cases each designed to test a single requirement or option. An abstract test suite is like un-compiled source code. ISO (International Standards Organization) and ITU-T, while addressing this issue, suggest the usage of TTCN (Tree and tabular combined notation), which is test-equipment-independent. The TTCN language is part of the ISO/IEC 9646 (International Electro-technical Committee) conformance-testing framework and is specially designed for the specification tests of communication systems.

We will discuss standard approach for abstract test suite development. Definition of key concepts associated with the Abstract Test Suites. It also describes about form of abstract test suites and maintenance of ATS (Abstract Test Suite).

TTCN is the defacto standard test environment/Language for communication systems. This is used world wide to test telecommunication and data-communication equipment ranging from built in communication chips to huge switched and intelligent network services. TTCN is widely used for conformance testing. Conformance testing is the process of verifying that an implementation performs in accordance with a particular standard/specification. It is concerned with external behavior (black box) but not with performance/reliability/fault tolerance.

ISO/IEC 9646 (ITU X.290 series) is a seven part standard which defines a framework and methodology for conformance testing of implementations of OSI and ITU protocols. The TTCN is the third part of this standard, i.e. ISO/IEC 9646-3. The Versions 1 and 2 are developed by ISO as part of the widely used ISO/IEC-9646 conformance-testing standard. The ISO/IEC 9646-3 and ITU-T X.292 Updates/maintenance are done by ETSI. The Version 3 is developed by ETSI.

Conformance testing

Conformance testing is verification that an implementation meets the formal requirements of the referenced standards and, more precisely, that it meets the conformance clauses contained in the standards. During the test phase, the implementation is referred to as the Implementation Under Test (IUT). The primary objective of conformance testing is to increase the probability that different product implementations actually interoperate. The testing of performance and robustness are not part of the conformance testing process. No amount of testing can give a full guarantee of successful inter-working. The exhaustive testing of every possible aspect of protocol behavior is unrealistic and impractical for technical and economical reasons.

Conformance testing can however give a reasonable degree of confidence that an implementation, which passes the tests, will comply with the requirements in its communication with other systems. As such, conformance testing can be regarded as a prerequisite for inter-working. Any test can be easily contentious. When comparing a product with its specification, using testing tools, we could ask, in case of discrepancies: Is the product wrong? Is the specification ambiguous? Is the test biased? Is the testing method suitable? Is the testing process agreed and understood?


One-way to solve some of these questions in advance is to standardize: Use of standard protocol specifications, use of standard tests, use of standard methods, use of standard testing process. This is what Conformance Testing is about, based upon a standard testing methodology, as defined by ISO and CCITT. The benefits of conformance testing can be increased further. The use of standard methods, based on approved test suites developed for each OSI standard protocol, and on testing procedures, lead to the comparability of results produced by different testers, and thereby to the mutual recognition of test reports. This will minimize the need for repeated conformance testing, and minimize the associated costs.
 

© blogger templates 3 column | Make Money Online