TTCN-3 (Testing and Test Control Notation versión 3) es un lenguaje de prueba fuertemente tipado que se utiliza en las pruebas de conformidad de los sistemas de comunicación. TTCN-3 está escrito por ETSI en la serie ES 201 873, [1] y estandarizado por ITU-T en la serie Z.160. [2] TTCN-3 tiene sus propios tipos de datos y se puede combinar con definiciones de tipos ASN.1 , IDL y XML .
Organización estándar
El estándar ITU-T TTCN-3 es parte de la Serie Z y está organizado en varias partes:
- Z.161 - Lenguaje central que define la notación textual central
- Z.162 - Formato de presentación tabular (TFT): una forma de presentar las pruebas en una presentación tabular
- Z.163 - Formato de presentación gráfica (GFT): una forma de presentar las pruebas gráficamente con una representación similar a la del MSC
- Z.164 - Semántica operacional - Define cómo se ejecuta TTCN-3
- Z.165 - TRI: define la API proporcionada y requerida con un probador
- Z.166 - TCI: define la API proporcionada y requerida con un controlador de prueba
- Z.167 - ASN.1 - Define cómo utilizar los tipos de datos ASN.1 en un conjunto de pruebas TTCN-3
- Z.168 - Mapeo IDL a TTCN-3
- Z.169 - Uso de esquema XML con TTCN-3
Organización del idioma
- Módulo
- El contenedor de nivel superior en una suite de pruebas es un módulo. Suele ser un archivo.
- Componente
- componente es una entidad de ejecución. Se ejecuta un caso de prueba o una función en un componente.
- Puerto
- Los componentes se comunican entre sí o con el SUT a través de puertos que se asignan entre sí.
- Caso de prueba
- Un caso de prueba es una secuencia de envíos y recepciones. Cuando se envía un mensaje al SUT (Sistema bajo prueba) se pueden recibir varias respuestas posibles.
- Alternativa
- Dado que un caso de prueba es una secuencia de estímulos seguida de un conjunto de posibles respuestas, la notación incluye alternativas. Es una forma compacta de enumerar todas las alternativas posibles en un escenario.
- Plantilla
- Al enviar o recibir información, el valor de los parámetros es de suma importancia. Deben definirse cuando se envían y deben verificarse cuando se reciben. La construcción de la plantilla tiene como objetivo definir los valores de los parámetros cuando se envían o verificar los valores de los parámetros cuando se reciben. Dado que los parámetros pueden ser bastante complejos, definir y verificar los valores no es cuestión de una sola línea. La plantilla permite una verificación compleja en una sola declaración para que el caso de prueba permanezca legible.
- Veredicto
- El veredicto es el resultado de la ejecución de un caso de prueba. Tiene 5 valores posibles: none, pass, inconc, fail, error.
Aplicaciones
TTCN-3 se ha utilizado para definir conjuntos de pruebas de conformidad con los protocolos estándar SIP , WiMAX y DSRC .
La Open Mobile Alliance adoptó en 2008 una estrategia de utilizar TTCN-3 para traducir algunos de los casos de prueba en una especificación de prueba habilitadora en una representación ejecutable. [3]
El proyecto AUTOSAR promovió (2008) el uso de TTCN-3 dentro de la industria automotriz. [4]
El proyecto 3GPP promovió el uso de TTCN-3 dentro de la industria móvil. [5]
Arquitectura
Al ejecutar la arquitectura se organiza de la siguiente manera:
- TE: TTCN-3 Executable es la forma ejecutable del conjunto de pruebas.
- TRI: La interfaz de tiempo de ejecución TTCN-3 es la interfaz entre el TE y el SUT. Se divide en 2 partes:
- SA: Adaptador de sistema
- PA: Adaptador de plataforma
- TCI: TTCN-3 Control Interfaces es la interfaz para controlar la ejecución de la prueba. Se divide en:
- TM: Gestión de pruebas
- TL: Registro de prueba
- CD: codificación y decodificación
- CH: Manipulación de componentes
Código de ejemplo
Este es un ejemplo de TTCN-3 con su equivalente gráfico en MSC ( Message Sequence Chart ).
módulo TestSystem { // Definir un subtipo de tipo entero integer myNewType ( 0 .. 50 ) // Declarar el tipo de estructura de solicitud con 2 campos tipo registro Solicitud { myNewType param1 , cadena de caracteres param2 }// Declarar el tipo de estructura de respuesta con un registro de tipo de campo Respuesta { myNewType param1 }// Declarar un tipo de puerto de comunicación basado en mensajes port cEnv_type message { solicitud de salida ; en respuesta ; }// Declare el componente en el que se ejecutará el caso de prueba tipo componente sSystem { puerto cEnv_type cEnv ; }// Las plantillas definen los valores de los parámetros salientes // y verifican la plantilla de los valores de los parámetros entrantes Request Good_Req : = { param1 : = 42 , param2 : = "hello!" }; plantilla Respuesta All_is_OK : = { param1 : = 0 }; // Definir testcase1 que se ejecutará en el componente sSystem testcase testcase1 () se ejecutará en sSystem { // Enviar mensaje de solicitud con (42, "¡hola!") Como parámetros cEnv . enviar ( Good_Req ) ; // Una alternativa para las 2 posibles respuestas alt { // Recibimos Respuesta con 0 como parámetro [] cEnv . recibir ( Todo_es_OK ) { // ¡Pasa el veredicto! setverdict ( pasar ) } // O recibimos algo más [] cEnv . recibir { // Fallo en el veredicto setverdict ( fail ) } } }// Control de la ejecución de casos de prueba de cadenas de piezas control automático { var vedicttype vedict1 ; veredicto1 : = ejecutar (caso de prueba1 ()) ; }}
Ver también
Referencias
- ^ Página ETSI TTCN-3
- ^ Serie Z
- ^ Grupo de trabajo de interoperabilidad de OMA
- ^ Áreas de aplicación de TTCN-3, sitio web oficial de TTCN-3 de ETSI, consultado el 17 de noviembre de 2015
- ^ Centro de competencia móvil 3GPP RAN5