TTCN-3 (notação de teste e controle de teste versão 3) é uma linguagem de teste fortemente tipada usada em testes de conformidade de sistemas de comunicação. TTCN-3 é escrito por ETSI na série ES 201 873[1] e padronizado por ITU-T na série Z.160.[2] A TTCN-3 tem seus próprios tipos de dados e pode ser combinado com as definições de tipo ASN.1, IDL e XML.

Organização padrão editar

O padrão ITU-T TTCN-3 faz parte da Série Z e é organizado em várias partes:

  • Z.161 - Linguagem central que define a notação textual central.
  • Z.162 - Formato de apresentação tabular (TFT) - Uma maneira de apresentar os testes em uma apresentação tabular.
  • Z.163 - Formato de apresentação gráfica (GFT) - Uma forma de apresentar os testes graficamente com uma representação semelhante ao MSC.
  • Z.164 - Semântica operacional - Define como o TTCN-3 é executado.
  • Z.165 - TRI - Define a API fornecida e necessária com um testador.
  • Z.166 - TCI - Define a API fornecida e necessária com um controlador de teste.
  • Z.167 - ASN.1 - Define como usar os tipos de dados ASN.1 em um conjunto de testes TTCN-3.
  • Z.168 - Mapeamento IDL para TTCN-3.
  • Z.169 - Usando esquema XML com TTCN-3.

Organização de linguagem editar

Módulo
O contêiner de nível superior em uma suíte de teste é um módulo. Geralmente é um arquivo.
Componente
O componente é uma entidade de execução. Um caso de teste ou uma função é executada em um componente.
Porta
Os componentes se comunicam entre si ou com o SUT por meio de portas mapeadas entre si.
Caso de teste
Um caso de teste é uma sequência de envios e recebimentos. Quando uma mensagem é enviada para o SUT (sistema em teste), várias respostas possíveis podem ser recebidas.
Alternativa
Como um caso de teste é uma sequência de estímulos seguida por um conjunto de respostas possíveis, a notação inclui alternativas. É uma forma compacta de listar todas as alternativas possíveis em um cenário.
Template
Ao enviar ou receber informações os valores dos parâmetros são de suma importância. Devem ser definidos ao serem enviados e verificados ao serem recebidos. A construção do template visa definir os valores dos parâmetros no momento do envio ou verificar os valores dos parâmetros no momento do recebimento. Uma vez que os parâmetros podem ser bastante complexos, definir e verificar os valores não é uma questão de uma única linha. O modelo permite uma verificação complexa em uma única instrução para que o caso de teste permaneça legível.
Veredicto
O veredicto é o resultado da execução de um caso de teste. Possui 5 valores possíveis: Nenhum, aprovado, inconc, reprovado ou erro.

Aplicações editar

A TTCN-3 foi usada para definir conjuntos de testes de conformidade para os protocolos SIP, WiMAX e DSRC padrão.

A OMA adotou em 2008 uma estratégia de usar o TTCN-3 para traduzir alguns dos casos de teste em uma especificação de teste habilitadora em uma representação executável.[3]

O projeto AUTOSAR promoveu (em 2008) o uso do TTCN-3 na indústria automotiva.[4]

O projeto 3GPP promoveu o uso do TTCN-3 na indústria móvel.[5]

Arquitetura editar

Durante a execução, a arquitetura é organizada da seguinte forma:

  • TE: Executável TTCN-3 é a forma executável do conjunto de testes.
  • TRI: TTCN-3 Runtime Interface é a interface entre o TE e o SUT. Está dividido em 2 partes:
    • SA: Adaptador do sistema.
    • PA: Adaptador de plataforma.
  • TCI: TTCN-3 Control Interfaces é a interface para controlar a execução do teste. Está dividido em:
    • TM: Gerenciamento de teste.
    • TL: Registro de teste.
    • CD: Codificação e decodificação.
    • CH: Manuseio de componentes.

Exemplo de código editar

Este é um exemplo TTCN-3 com seu equivalente gráfico em MSC (gráfico de sequência de mensagens).

 
Representação MSC (gráfico de sequência de mensagens) de um cenário básico TTCN-3 (notação de teste e controle de teste).
module TestSystem {

// Define um subtipo de inteiro
type integer myNewType (0..50)

// Declara o tipo de estrutura de solicitação com 2 campos
type record Request {
  myNewType param1,
  charstring param2
  }

// Declara o tipo de estrutura de resposta com um campo
type record Answer {
  myNewType param1
  }

// Declara uma porta de comunicação baseada em mensagem
type port cEnv_type message {
  out Request;
  in Answer;
  }

// Declara o componente no qual o caso de teste será executado
type component sSystem {
  port cEnv_type cEnv;
  }

// Os modelos definem os valores dos parâmetros de saída
// e verificam os valores dos parâmetros de entrada
template Request Good_Req := {param1 := 42, param2 := "olá !" };
template Answer All_is_OK := {param1 := 0};

// Define o caso de teste 1 que será executado no componente do sistema
testcase testcase1() runs on sSystem
  {
  // Envia mensagem de solicitação com (42, "olá!") como parâmetros
  cEnv.send(Good_Req);
  // Uma alternativa para as 2 respostas possíveis
  alt
    {
    // Recebemos resposta com 0 como parâmetro
    []cEnv.receive(All_is_OK)
      {
      // Pass verdict !
      setverdict(pass)
      }
    // Ou recebemos outra coisa
    []cEnv.receive
      {
      // Fail verdict
      setverdict(fail)
      }
    }
  }

// Controla automaticamente a execução de partes de casos de teste de cadeias
control {
  var verdicttype verdict1;
  verdict1 := execute(testcase1());
  }
}

Veja também editar


Referências

Ligações externas editar