Uma abordagem para validação de protocolos de comunicação em ambientes de simulação

Texto

(1)Pós-Graduação em Ciência da Computação. “UMA ABORDAGEM PARA VALIDAÇÃO DE PROTOCOLOS DE COMUNICAÇÃO EM AMBIENTES DE SIMULAÇÃO” Por. Marco Antonio de Oliveira Domingues Dissertação de Mestrado. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, AGOSTO/2004.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. MARCO ANTONIO DE OLIVEIRA DOMINGUES. “UMA ABORDAGEM PARA VALIDAÇÃO DE PROTOCOLOS DE COMUNICAÇÃO EM AMBIENTES DE SIMULAÇÃO”. ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. ORIENTADOR: DJAMEL FAWZI HADJ SADOK. RECIFE, AGOSTO/2004.

(3)

(4) A minha mãe e a Deus por ter me dado minha mãe.. i.

(5) Agradecimentos. A Deus. Aos meus pais. Aos amigos Jeísa, João, Lincoln, Eduardo, Barreto, Stênio, Eleonora, Galiza, Karol e Ribeiro. Aos professores Judith Kelner e Djamel Sadok. A Carlos Kamienski e Claudionor Coelho. E a todos os amigos não citados, antigos e recentes, cuja amizade foi essencial para a continuidade deste trabalho.. ii.

(6) Sumário Resumo. ix. Abstract. x. 1.. 1. Introdução 1.1 1.2 1.3 1.4. 2.. O processo de Simulação 2.1 2.2 2.3 2.4 2.5 2.6 2.7. 3.. Motivação.............................................................................................................................................. 1 Objetivo ................................................................................................................................................ 2 Trabalhos relacionados ....................................................................................................................... 3 Estrutura da dissertação...................................................................................................................... 3 5. O uso de simulação ............................................................................................................................. 5 Classificação dos modelos de simulação .......................................................................................... 6 Terminologia ........................................................................................................................................ 7 Estratégia para modelagem e simulação........................................................................................... 8 Métodos para validação de modelos ................................................................................................. 9 Ambientes e linguagens de simulação............................................................................................. 11 Considerações finais .......................................................................................................................... 13. Testes em sistemas. 15. 3.1 Escopo dos testes de software......................................................................................................... 15 3.2 Tipos de testes.................................................................................................................................... 16 3.3 Testes de conformidade.................................................................................................................... 18 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 3.3.10. Visão geral da recomendação OSI 9646...............................................................................................19 O processo de avaliação de conformidade...........................................................................................21 Classificação dos testes de conformidade.............................................................................................24 Abordagens de testes ...............................................................................................................................24 Pontos de controle e observação - PCO ..............................................................................................25 Funções abstratas de testes .....................................................................................................................27 Métodos de testes locais e distribuídos.................................................................................................28 Métodos de testes coordenados e remotos ..........................................................................................28 Preparação para os testes ........................................................................................................................29 Ferramentas de suporte a sistemas de testes........................................................................................34. 3.4 Considerações finais .......................................................................................................................... 36 4.. Estudo de caso. 37. 4.1 Visão geral da pilha TCP/IP............................................................................................................ 37 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5. Estrutura do segmento TCP...................................................................................................................38 Transporte orientado à conexão ............................................................................................................40 Multiplexação/demultiplexação de processos de aplicação ..............................................................42 Controle de fluxo......................................................................................................................................43 Controle de congestionamento ..............................................................................................................45. 4.2 Aplicação do arcabouço de testes.................................................................................................... 47 4.2.1. Definição das especificações e propósitos de teste.............................................................................49. iii.

(7) 4.2.2 4.2.3. Derivação, implementação e mapeamento dos casos de teste..........................................................59 Análise dos resultados da aplicação dos testes ....................................................................................66. 4.3 Considerações finais .......................................................................................................................... 67 5.. Conclusão. 68. 5.1 Contribuições ..................................................................................................................................... 68 5.2 Trabalhos Futuros ............................................................................................................................. 69 5.3 Considerações Finais......................................................................................................................... 70 6.. Referências. 71. iv.

(8) Lista de Figuras Figura 3.1 Atividades e recomendações relacionadas no arcabouço de testes de conformidade[4]21 Figura 3.2 Visão geral do processo de testes de conformidade...........................................................23 Figura 3.3 Arquitetura conceitual de testes.............................................................................................25 Figura 3.4 Possíveis PCOs em uma arquitetura conceitual [4] ............................................................27 Figura 3.5 (a) Método de teste local (b) Método de teste distribuído [4]...........................................28 Figura 3.6 (a) Método de teste coordenado (b) método de teste remoto ..........................................29 Figura 3.7 Visão detalhada do processo de testes de conformidade ..................................................29 Figura 3.8 Uma árvore de comportamento para uma chamada telefônica........................................33 Figura 4.1 Conexão lógica entre aplicações [39] ....................................................................................37 Figura 4.2 Estrutura do segmento TCP ..................................................................................................39 Figura 4.3 Estabelecimento de conexão TCP [40] ................................................................................41 Figura 4.4 Encerramento da conexão TCP [40] ....................................................................................42 Figura 4.5 Fluxo de desenvolvimento de testes de conformidade......................................................49 Figura 4.6 MSC TP_TCP_001 .................................................................................................................50 Figura 4.7 MSC TP_TCP_002 .................................................................................................................51 Figura 4.8 MSC TP_TCP_003 .................................................................................................................52 Figura 4.9 MSC TP_TCP_004 .................................................................................................................53 Figura 4.10 MSC TP_TCP_005 ...............................................................................................................54 Figura 4.11 MSC TP_TCP_006 ...............................................................................................................55 Figura 4.12 MSC TP_TCP_007 ...............................................................................................................56 Figura 4.13 MSC TP_TCP_008 ...............................................................................................................57 Figura 4.14 MSC TP_TCP_009 ...............................................................................................................58 Figura 4.15 MSC TP_TCP_010 ...............................................................................................................59. v.

(9) Lista de Tabelas Tabela 3.1 Caso de teste relativo à árvore de comportamento de uma ligação telefônica ..............34 Tabela 4.1 Caso de teste TC_TCP001 ....................................................................................................60 Tabela 4.2 Caso de teste TC_TCP002 ....................................................................................................60 Tabela 4.3 Caso de teste TC_TCP003 ....................................................................................................61 Tabela 4.4 Caso de teste TC_TCP004 ....................................................................................................61 Tabela 4.5 Caso de teste TC_TCP005 ....................................................................................................62 Tabela 4.6 Caso de teste TC_TCP006 ....................................................................................................62 Tabela 4.7 Caso de teste TC_TCP007 ....................................................................................................63 Tabela 4.8 Caso de teste TC_TCP008 ....................................................................................................64 Tabela 4.9 Caso de teste TC_TCP009 ....................................................................................................64 Tabela 4.10 Caso de teste TC_TCP010 ..................................................................................................65 Tabela 4.11 Veredicto dos casos de teste................................................................................................66. vi.

(10) Abreviações e acrônimos ASN1 ASP ATC ATM ATS CATG CBR CCITT CT CWND DCTM ETS ETSI FIFO FTP GPSS HTTP. ICS IP ISDN ISO ITU-T IUT IXIT LIFO LT MPyT MSC MSS Ns OSI PCO PCTR PDU PICS PIXIT PSTS SAP SCS. Abstract Syntax Notation One Abstract Service Primitive Abstract Test Case Abstract Test Method Abstract Test Suite Computer-Aided Test Case Generation Constant Bit Rate Consultative Committee for International Telegraphy and Telephony Conformance Tests Congestion Window Dynamic Conformance Test Method Executable Test Suite European Telecommunications Standards Institute First In First Out File Transfer Protocol General Purpose Simulation System Hyper-Text Transfer protocol Implementation Conformance Statement Internet Protocol Integrated Services Digital Network International Standards Organization International Telecommunications Union-Telecommunications Standard Sector Implementation Under Test Implementation Extra Information for Testing Last In First Out Lower Tester Multi-Party Testing context Message Sequence Chart Maximum Segment Size Network Simulator – 2 Open System Interconnection Point of Control and Observation Protocol Conformance Test Report Protocol Data Unit Protocol /Profile Implementation Conformance Statement Protocol /Profile Implementation Extra Information for Testing Profile Specific Test Specification Service Access Point System Conformance Statement vii.

(11) SDL SIP SPyT SUT TC TCP TCP2 TMP TP TTCN UDP UML UT. Specification Description Language Session Initiation Protocol Single-Party Testing context System Under Test Test Case Transmission Control Protocol Test Coordination Procedures Test Management Protocols Test Purpose Testing and Test Control Notation / Tree and Tabular Combined Notation User Datagram Protocol Unified Modeling Language Upper Tester. viii.

(12) Resumo O uso de técnicas de simulação para implementar cenários de testes em protocolos de comunicação tem crescido bastante nos últimos anos. Centros de pesquisas acadêmicos e industriais têm dedicado especial interesse em simulação de ambientes com variados graus de complexidade, sobretudo pelo baixo custo e pela rapidez com que os experimentos podem ser implementados, corrigidos, aplicados e reproduzidos em comparação com um ambiente real de operação. Apesar disso, as técnicas de simulação inerentemente envolvem alto nível de abstração na modelagem e mapeamento dos cenários, o que pode comprometer a representatividade e confiabilidade dos resultados obtidos. O arcabouço de testes de conformidade proposto pela ITU-T/ISO através das recomendações OSI-9646 tem sido amplamente utilizado pela indústria de telecomunicações na certificação de seus produtos. Esse arcabouço abrange todas as fases do desenvolvimento dos testes de conformidade, desde planejamento, derivação e implementação do conjunto de testes até a fase de aplicação e análise dos resultados dos testes. O propósito fundamental dos testes de conformidade é verificar se uma implementação se comporta de modo consistente em relação às suas especificações, proporcionando dessa maneira um mecanismo para aumentar o grau de interoperabilidade entre produtos certificados de fabricantes distintos. Para a descrição dos testes, foi definida a linguagem TTCN – Testing and Test Control Notation, cuja característica abstrata permite que um conjunto de testes possa ser integrado a diversas implementações de um mesmo protocolo. Em sua terceira versão, essa linguagem também permite a descrição e implementação de testes de performance e de robustez. Este trabalho propõe adaptar o arcabouço de testes de conformidade como um método de validação de protocolos de comunicação em ambientes de simulação, considerando os aspectos relevantes da modelagem abstrata e permitindo o mapeamento de não-conformidade no cenário de simulação antes da realização dos experimentos, dessa forma, possibilitando aumentar a confiabilidade dos cenários utilizados em simulações de protocolos de comunicação. Palavras-chave: Testes de conformidade, TTCN, simuladores, protocolos de comunicação. ix.

(13) Abstract The use of simulation techniques to implement test scenarios for communication protocols has been increasing over the last few years. Academic and industrial research centers have a special interest in variablecomplexity simulation environments, mainly due to the low cost and the high speed of implementing, correcting, applying and reproducing the experiments, as compared to a real and operational environment. However, simulation techniques inherently involve a high abstraction level in the scenario modeling and mapping, which can compromise the representation and trustworthiness of the obtained results. The conformance test framework proposed by ITU-T/ISO through OSI-9646 recommendations has been widely used by the telecommunications industry for certifying its products. This framework encloses the phases of conformance tests development, since planning, derivation and implementation until test application and analysis. The main goal of conformance tests is to verify if an implementation behaves consistently in relation to its specifications, providing a mechanism to increase the interoperability degree between certified products from different vendors. The TTCN (Testing and Test Control Notation) language was design to describe the tests. This language has a high level of abstraction, allowing a set of tests to be integrated to many different implementations of the same protocol. Presently in the third version, this language also allows the description and implementation of performance and robustness tests. This work proposes an adaptation of the conformance test framework as a method of validation of communication protocols in simulation environments, considering the relevant aspects of abstract modeling and allowing the mapping of features whose tests failed in the simulation scenario before the realization of the experiments, thus making possible the increase in trustworthiness of the scenarios used in communication protocols simulations.. Keywords: Conformance test, TTCN, simulators, communication protocols.. x.

(14) 1. Introdução Neste capítulo será apresentada uma breve introdução acerca dos problemas abordados nesta dissertação, enfatizando o emprego do arcabouço de testes de conformidade como método para validação de cenários de simulação de protocolos de comunicação.. 1.1 Motivação O crescimento da quantidade e diversidade das aplicações suportadas pela Internet estimulou a criação de novos protocolos de comunicação e até mesmo a adaptação de características de protocolos já existentes a esses novos requisitos operacionais, tais como critérios de segurança, transporte multicast, mobilidade de dispositivos, busca em sistemas compartilhados, suporte a qualidade de serviço, entre outros. Diferentes técnicas têm sido usadas para realizar experimentos visando desenvolver, adaptar e testar esses novos requisitos. As diferenças entre elas podem ser no custo (pessoal, material, equipamentos, etc.), na exatidão dos resultados, e na facilidade da operação dos cenários. Analisadores de protocolos, testbeds e laboratórios de teste em escala são ambientes que, por usarem implementações reais, geram resultados bastante próximos dos que seriam obtidos no ambiente real de operação. Porém, os custos de montagem de testbeds e laboratórios são altos, e normalmente não são adaptáveis a outros protocolos além da reconfiguração ser demasiadamente lenta. Em contrapartida, os ambientes de simulação têm sido cada vez mais empregados no desenvolvimento de protocolos de comunicação, principalmente pela reprodutibilidade, rapidez na manutenibilidade dos cenários e pelos custos relativamente mais baixos [1]. Embora sejam muitas as vantagens, os cenários fornecidos por simuladores de protocolos de comunicação não representam com fidelidade o comportamento do ambiente real. Essa característica dos simuladores em proporcionar abstração de certos detalhes de funcionalidades pode conduzir à inserção de “erros” (características ausentes ou parcialmente implementadas) que precisam ser identificados e tratados. Ademais, em ferramentas públicas, como é o caso do Network Simulator – version 2 (ns-2) [2], alguns protocolos fornecidos na própria distribuição apresentam poucas e nem sempre válidas funcionalidades, reduzindo o escopo de análise dos resultados gerados com essas implementações. 1.

(15) Em alguns casos, para tornar possível o uso dos protocolos do ns-2, é necessário a edição e correção do código da implementação [3]. Geralmente essa correção é realizada sem o emprego de técnicas que validem a implementação em relação às especificações do protocolo. O emprego do arcabouço de testes de conformidade descrito nas recomendações OSI-9646 [4] pode ser utilizado nesse contexto como ferramenta de validação dessas implementações de protocolos. Os testes de conformidade têm sido largamente aplicados pela indústria de telecomunicações como ferramenta para certificação de sistemas com protocolos de comunicação operando em tempo real. O propósito desses testes é relacionar características funcionais e comportamentais de um determinado protocolo, gerar e aplicar casos de teste relativos a essas características à implementação do protocolo e analisar quais itens não estão em conformidade com as especificações [5].. 1.2 Objetivo As vantagens obtidas com o uso de processos de modelagem e simulação como ferramenta de análise de comportamento de protocolos de comunicação têm feito com que essas técnicas ocupem cada vez mais espaço no meio acadêmico. Essa dissertação tem como principal objetivo estender o uso dos testes de conformidade às implementações de protocolos de comunicação em ambientes de simulação visando a validação das funcionalidades implementadas referentes às especificações do protocolo. Para atingir esse objetivo, outros objetivos secundários devem ser observados, dentre eles: •. Realizar estudo acerca do emprego de metodologias de modelagem e simulação, sobretudo no Network Simulator;. •. Realizar levantamento teórico sobre as especificações do protocolo alvo utilizado no estudo de caso;. •. Gerar um conjunto de casos de teste abstratos aplicáveis a quaisquer instâncias do protocolo alvo;. •. Fornecer um tutorial de desenvolvimento, aplicação e análise do arcabouço de testes de conformidade.. 2.

(16) 1.3 Trabalhos relacionados Trabalhos recentes têm estendido o uso da metodologia de testes de conformidade para outras fases do desenvolvimento de software utilizando os registros gerados como documentação da descrição do comportamento do sistema. Uma abordagem envolvendo a geração de casos de teste a partir da especificação formal de um sistema é apresentada em [6]. Nesse trabalho são descritas as atividades pertinentes à aplicação da metodologia de testes de conformidade previstas nas recomendações ISO-9646, gerando os casos de teste em TTCN (Tree and Tabular Combined Notation) a partir das especificações de um sistema em SDL (Specification and Description Language). Em [7] é apresentada uma proposta para integrar componentes de casos de teste TTCN na modelagem UML2.0 (Unified Modelling Language). Essa abordagem admite especificações de testes para modelos UML relativos a aspectos de estrutura e comportamento, permitindo interoperabilidade com técnicas de testes caixa-preta já existentes. Um método dinâmico de testes de conformidade é proposto em [8]. Enquanto o método convencional apresenta uma seqüência estática de testes, o método dinâmico denominado DCTM (Dynamic Conformance Test Method) seleciona diferentes seqüências de testes, baseado na falha de testes intermediários. Essa escolha dinâmica da seqüência evita que testes que estão conformes1 tenham veredicto não-conforme devido a testes anteriores que já obtiveram esse veredicto.. 1.4 Estrutura da dissertação Esta dissertação encontra-se organizada da seguinte forma. No Capítulo 2 são abordados os principais conceitos e características referentes ao processo de simulação, incluindo uma classificação dos modelos de simulação, uma estratégia para modelagem e simulação, e métodos para validação de modelos. O Capítulo 3 apresenta os tipos de testes que podem ser realizados em sistemas, enfatizando a metodologia dos testes de conformidade. São descritos conceitos relacionados a essa metodologia, bem como os procedimentos que devem ser realizados durante a fase de preparação dos testes de conformidade.. Neste trabalho serão utilizados os termos CONFORME, NÃO-CONFORME e INCONCLUSIVO para representar respectivamente PASS, FAIL e INCONCLUSIVE, apresentados na seção 3.3.2. 1. 3.

(17) No Capítulo 4, é apresentado um estudo de caso que utiliza o arcabouço de desenvolvimento de testes de conformidade para testar uma implementação do protocolo TCP no Network Simulator. As características do TCP e de sua implementação no ns são descritas, e os resultados obtidos são apresentados e discutidos. As conclusões, incluindo a enumeração das contribuições e dos trabalhos futuros, são apresentadas no Capítulo 5. Finalmente, o Capítulo 6 relaciona as referências utilizadas nessa dissertação.. 4.

(18) 2. O processo de Simulação Esse capítulo aborda a importância do processo de simulação, apresentando a classificação dos modelos de simulação e os principais conceitos relacionados a esse processo. Também é apresentada uma estratégia para modelagem e simulação, métodos utilizados para validação de modelos, e alguns ambientes e linguagens de simulação.. 2.1 O uso de simulação O avanço tecnológico das últimas décadas proporcionou oportunidades para utilização de abordagens mais completas no tratamento de sistemas complexos, impossíveis de serem resolvidos sem o auxílio de alguma ferramenta computacional. O desenvolvimento de aplicações ou sistemas em áreas de atuação que envolvam riscos à vida ou ainda onde os custos relativos aos testes sejam impeditivos tornou-se um campo fértil para a utilização de técnicas de modelagem e simulação. Alguns desses sistemas, muitas vezes chamados de missão crítica, realizam funções essenciais e não podem ser interrompidos ou finalizados. O processo de simulação envolve a geração de modelos que estabeleçam relações de comportamento com o ambiente real e a posterior análise dos resultados. Segundo [9], simulação de sistemas é o processo de projetar um modelo computacional a partir de um sistema real e conduzir experimentos com este modelo com o propósito de entender seu comportamento e/ou avaliar estratégias para sua operação, dentro dos limites impostos por um critério ou um conjunto de critérios. Contudo, o emprego de métodos de simulação tem escopo muito mais amplo. É possível realizar descrições de comportamento de um dado sistema, construir teorias e hipóteses considerando as observações efetuadas sobre ele e, sobretudo, utilizar este modelo para prever comportamento futuro caso sejam modificadas suas condições normais de operação. Tendo em vista que os resultados do sistema real não são obtidos de maneira trivial, como conseqüência tem-se o uso de técnicas de simulação. O processo de simulação apresenta muitas vantagens em relação a outros métodos de análise de sistemas. Dentre elas podem ser citadas a capacidade de previsão de desempenho, adaptabilidade do modelo às variações de condições de testes e operação, menor custo, capacidade de reprodução e controle de experimentos, menor consumo de tempo para a captação dos 5.

(19) resultados e simplicidade em relação aos métodos analíticos. Além disso, o tempo, variável importante como escalonador dos processos, pode ser controlado, expandido ou comprimido. Dessa forma, os modelos de simulação podem ser quase tão detalhados quanto os sistemas reais. Apesar de ser uma excelente ferramenta de análise, existem certas precauções que devem ser levadas em consideração quando se utiliza o processo de simulação: a modelagem dos sistemas precisa ser criteriosamente planejada, considerando, sobretudo, o nível de abstração necessária para cada processo; freqüentemente o tratamento dos dados resultantes da simulação requer análise estatística não trivial; a modelagem e realização dos experimentos consomem muitos recursos, principalmente tempo; e a tentativa de simplificação na modelagem ou nos experimentos visando economia de recursos costuma fornecer resultados insatisfatórios.. 2.2 Classificação dos modelos de simulação A classificação dos modelos de simulação está relacionada às mudanças de valor das variáveis de estado, à forma como sofrem alterações ao longo do tempo e a eventos. A seguir é apresentada a classificação dos modelos de simulação quanto ao tipo dos eventos: •. Modelos de eventos discretos ou modelos discretos – esses modelos mantém o estado de suas variáveis durante determinado intervalo de tempo e modificam seus valores somente em momentos bem definidos, conhecidos como tempo de ocorrência do evento. Para esses tipos de modelos, a variação do tempo pode ser discreta ou contínua;. •. Modelo de eventos contínuos – nesses modelos, as variáveis de estado podem alterar seus valores continuamente ao longo do tempo simulado. Os modelos contínuos podem ser ainda contínuos ou discretos no tempo, sendo subordinados aos valores das variáveis dependentes, que podem estar disponíveis em qualquer instante do tempo simulado ou apenas em momentos específicos.. Alguns modelos contínuos podem ser discretizados, isto é, tratados como modelos discretos após algumas suposições realizadas sobre as variáveis de estado. Existe também a possibilidade de modelagem mista, na qual as variáveis de estado dependentes do tempo podem alterar seus valores continuamente ou discretamente ao longo do tempo. Aplicações utilizando modelos de eventos discretos e contínuos podem ser encontrados em [10]. 6.

(20) 2.3 Terminologia Nessa seção serão descritos os termos e conceitos comumente usados em simulação [10]. •. Variáveis de estado – definem o estado do sistema e constituem o conjunto de informações necessárias para a compreensão dos eventos que estão ocorrendo em um determinado momento da simulação. Tais variáveis podem ser utilizadas para recuperar completamente o ambiente de simulação em caso de interrupção do processo.. •. Eventos – são acontecimentos, programados ou não, que podem provocar uma mudança no estado de um sistema. Qualquer mudança de estado é provocada pela ocorrência de um evento. São exemplos de eventos: a chegada de um cliente à fila de um servidor, o início de processamento de uma CPU, o envio de mensagens entre entidades de um protocolo de comunicação, etc.. •. Entidades e atributos – uma entidade representa um objeto dentro de um modelo de simulação. Pode apresentar características estáticas (por exemplo, um caixa em um supermercado ou uma CPU escalonando processos) ou dinâmicas (como peças que se movem por uma fábrica ou clientes que chegam à fila de um caixa de banco). As características que definem totalmente uma entidade são chamadas de atributos.. •. Recursos e filas de recursos – um recurso é uma entidade estática que fornece serviços a entidades dinâmicas. Um recurso pode ter a capacidade de servir a uma ou mais entidades dinâmicas simultaneamente operando como um servidor paralelo. Se uma entidade dinâmica não puder dispor de um recurso solicitado, deverá aguardar pelo recurso em uma fila. O processamento de uma fila depende da política de tratamento adotada, sendo as mais comuns o controle FIFO (First In First Out) e o controle LIFO (Last In First Out). Caso o recurso venha a ser alocado, a entidade dinâmica o reterá por um determinado período de tempo chamado tempo de processamento. O recurso também pode assumir vários estados. Os mais comuns são: “ocupado”, “livre”, “bloqueado”, “em falha” e “indisponível”.. •. Métodos de modelagem – para cada simulação uma visão do sistema real é construída. Essa abstração consiste em uma série de entidades ou transações que 7.

(21) fluem através do sistema. Tais entidades interagem com recursos participando de atividades na simulação de acordo com certas condições que determinam a seqüência das interações. Normalmente, observam-se três métodos de modelagem que diferem fundamentalmente na forma com que eventos futuros podem ser programados:. por. eventos,. onde. a. seqüência. dos. eventos. depende. incondicionalmente do tempo de simulação; por atividades, onde a estratégia de busca do próximo evento é baseada tanto no tempo programado para sua ocorrência quanto em testes condicionais; e por processos, onde a seqüência de simulação acompanha o fluxo intuitivo das entidades do mundo real.. 2.4 Estratégia para modelagem e simulação Em [11], é descrita uma abordagem para formulação de soluções de problemas através da utilização de processos de modelagem e simulação, envolvendo as seguintes fases: •. Formulação e análise do problema – o estudo do processo de simulação inicia-se com a formulação e compreensão do problema, através da definição e elucidação de seus objetivos. Nessa fase devem ser respondidas questões de projeto do tipo: a) Qual é o objetivo no estudo do problema e quais os resultados esperados? b) Quais os critérios utilizados para avaliação de desempenho e validação do sistema? c) Quais restrições serão impostas ao modelo abstraído do sistema real?. •. Planejamento do projeto – nessa fase deve ser levado em consideração o escalonamento dos recursos disponíveis no que diz respeito a pessoal técnico, suporte estrutural, gerência e equipamentos necessários à atividade do projeto, bem como a criação de um cronograma de atividades.. •. Formulação do modelo conceitual – deve-se criar uma síntese do projeto utilizando alguma ferramenta de descrição gráfica ou algorítmica para definir os componentes, descrevendo as variáveis e interações que constituem a abstração, partindo de um modelo mais simples e acrescentando funcionalidades até atingir todas as características previstas. As preocupações pertinentes a essa fase estão relacionadas com a escolha da estratégia de modelagem (contínua ou discreta), com 8.

(22) o nível de abstração do modelo, com a geração e coleta dos resultados, e com o modo como serão inseridos os dados e capturados os resultados no modelo. •. Verificação e validação – uma vez implementado o modelo no ambiente de simulação, faz-se necessário realizar a verificação do código, buscando erros de sintaxe e lógica, e a validação do modelo implementado, visando assegurar que, não obstante as abstrações inseridas, o modelo mantém significativa representatividade do sistema real. Na Seção 3.3 será apresentada uma proposta utilizada na verificação e validação de modelos e sistemas.. •. Determinação do intervalo de confiança – é preciso determinar a confiabilidade dos valores obtidos para as variáveis de interesse do sistema estudado e, para isso, são utilizados intervalos de confiança. Um intervalo de confiança compreende um intervalo numérico que possui uma probabilidade igual a (1-α) de incluir o verdadeiro valor da variável ou medida de desempenho sob análise. Dessa forma, (1-α) representa o nível de confiança do intervalo e α, denominado nível de significância, representa o erro admitido ao se concluir a presença do verdadeiro valor da variável no intervalo calculado.. •. Realização dos experimentos – nessa fase, o principal objetivo é maximizar a quantidade de informações relevantes obtidas realizando um mínimo de replicações dos experimentos. Para isso deve ser calculado um intervalo de confiança que represente essa quantidade. Os resultados gerados devem ser analisados, muitas vezes apresentando a necessidade de realização de um número maior de replicações para que se possam atingir os objetivos estipulados nas fases anteriores.. 2.5 Métodos para validação de modelos Dentre os métodos voltados à solução de problemas de sistemas em geral, a utilização de simulação é uma das mais intuitivas e simples no que se refere à aprendizagem e aplicação do processo. Entretanto, a não observação de critérios de verificação e validação dos modelos utilizados pode conduzir a resultados insatisfatórios. Em [10], são relacionados alguns erros comuns na abordagem por simulação que podem contribuir para o insucesso do projeto: objetivos com pouca clareza, pouca afinidade com as ferramentas de apoio à construção dos modelos de simulação e principalmente a escolha de critérios 9.

(23) inadequados à definição do grau de abstração dos modelos. Simulações de padrões e protocolos de comunicação, por exemplo, precisam ser verificados e validados a fim de observar se o comportamento do modelo está de acordo com o esperado ou ainda escolher a solução mais apropriada dentre um conjunto de soluções possíveis para um determinado problema. Contudo, freqüentemente observa-se a utilização de modelos de simulação para protocolos de comunicação sem que seja empregado o rigor necessário à validação da implementação, sobretudo em ferramentas de domínio público, como o Network Simulator [2]. Validação de um modelo consiste em assegurar que o modelo e as abstrações adotadas em sua construção produzam resultados mais próximos possíveis dos que seriam observados nos sistemas reais. Na prática, é quase impossível a criação de modelos idênticos aos sistemas reais, e na verdade este não é um objetivo a ser alcançado pelo processo de simulação. Normalmente, a implementação de um modelo visa a análise, a observação da atuação e do desempenho do sistema em condições diferenciadas daquelas observadas no ambiente de manipulação do sistema real, caso esse sistema exista. O sistema de validação do ns-2 é realizado através de um conjunto de casos de teste (escritos em OTcl), chamado “validate”, aplicados aos protocolos disponíveis em sua distribuição. A validação consiste em executar esses testes e comparar os arquivos de saída gerados com os arquivos contidos na distribuição. Porém, o conjunto de testes abrange apenas os protocolos mais estáveis do ns-2, havendo na distribuição protocolos que não são validados por esses testes. Além disso, mesmo os protocolos que são considerados “validados” apresentam aspectos que não são testados pelo conjunto de testes. Assim, fica sob responsabilidade do usuário verificar se as características relevantes para sua pesquisa são validadas pelos testes e, em caso negativo, buscar outras técnicas para validar tais características. Implementar um ambiente completo de simulação com todos os elementos que compõem um sistema pode ser bastante dispendioso, tanto com relação ao tempo de implementação quanto ao custo envolvido no processo. Assim, abstrações são inseridas para reduzir esses custos. Contudo, as hipóteses e abstrações embutidas no modelo não devem invalidar os resultados. Algumas abordagens para validação envolvendo métodos formais são úteis para verificar a funcionalidade e os estados de um sistema. Podem ser empregadas técnicas como a teoria das filas ou redes de Petri [13]. Entretanto, é comum, que o método analítico empregue versões mais simples do modelo, podendo gerar resultados não tão representativos quanto os obtidos utilizando o sistema 10.

(24) real. Atualmente, verifica-se que muitos projetos empregam a experiência de especialistas em simulação para inserir restrições na construção do modelo desde as fases iniciais, de modo a garantir que o modelo apresente relativa identidade com o sistema real. Tais testes, conhecidos como testes de Turing, consistem na apresentação de dois conjuntos diferentes de resultados aos especialistas. O primeiro conjunto contém resultados do sistema real enquanto o outro contém resultados do modelo. Se o especialista não conseguir distinguir os relatórios é porque não existem razões contundentes para invalidar o trabalho de modelagem. É trivial observar que, quando o processo de simulação é utilizado como ferramenta para análise de um sistema ainda em projeto, medições reais não existem, e essa técnica, portanto, não pode ser empregada. Em modelos simulados utilizados para comparação com sistemas existentes, pode-se empregar técnicas de validação baseadas na comparação estatística entre medições obtidas em um sistema real e no modelo simulado. Em [10], observa-se que a validação completa de um modelo é irrealizável. Efetivamente, pode-se verificar que um modelo é válido apenas para algumas situações. Investigar todas as possibilidades requer o emprego muito grande de recursos, e mesmo que esses recursos sejam empregados, computacionalmente seria impossível chegar a um resultado positivo em tempo hábil. Desta forma, a abstração do modelo pode inserir discrepâncias nos resultados do processo de simulação e somente o emprego de técnicas de validação suficientemente exaustivas seria capaz de dirimir todas as eventuais divergências entre o modelo simulado e o sistema real, entretanto com um custo computacional não viável.. 2.6 Ambientes e linguagens de simulação Linguagens de aplicação geral, como C, C++ e Java, podem ser utilizadas no desenvolvimento de cenários de simulação. Para auxiliar essa tarefa, algumas bibliotecas (pacotes) são criadas e disponibilizadas, como C++SIM [14] e JavaSim [15]. Contudo, há linguagens específicas voltadas para simulação que facilitam bastante a modelagem de sistemas. Algumas dessas linguagens serão brevemente descritas a seguir: •. SIMULA [16] – primeira linguagem específica para simulação, introduz conceitos e 11.

(25) características de orientação a objetos. Surgiu como uma extensão da linguagem ALGOL 60 desenvolvida para facilitar a descrição formal de configuração e regras de operação de sistemas utilizando eventos discretos. A execução de um programa em SIMULA consiste em um ou mais processos que interagem entre si, sendo cada processo uma instância de uma classe (conceitualmente, um objeto). Como uma linguagem de programação de propósitos gerais, SIMULA apresenta facilidades de processamento; •. GPSS (General Purpose Simulation System) [17] – linguagem voltada para o desenvolvimento de simulações de eventos discretos. Provê um conjunto de componentes abstratos de vários tipos e um conjunto de operadores, denominados blocos, que realizam ações sobre os componentes. Um programa de simulação em GPSS consiste em uma seqüência de blocos através dos quais os componentes se movem. À medida que os componentes passam através dos blocos, o GPSS coleta estatísticas sobre o comportamento dessa transação. Apresenta algumas variações (por exemplo, GPSS/H, GPSS/VX e GPSS/C) e é bastante adequada para simulação do funcionamento de fábricas;. •. Simscript [18] – linguagem de simulação desenvolvida para modelagem de eventos discretos e modelagem mista (discreta/contínua). Possui uma sintaxe “English-like”, projetada para facilitar a escrita e o entendimento de programas de simulação. Os objetos do mundo real são representados por entidades, seus valores são armazenados em atributos e seu comportamento é descrito por processos ou eventos. A simulação consiste na execução de processos/eventos, executados de acordo com um agendamento. Processos/eventos podem ainda agendar a execução de outros processos/eventos. Assim como SIMULA, Simscript permite a concorrência de processos/eventos e apresenta algumas facilidades para manipulação de dados, tratamento estatístico e geração de números aleatórios.. As linguagens de simulação podem estar embutidas em ambientes de simulação. Estes ambientes apresentam ferramentas gráficas que permitem construir graficamente modelos e visualizar resultados. A seguir serão apresentados três dos ambientes mais utilizados para simulação de sistemas. •. Simulink [19] – ambiente para modelagem, simulação e análise de sistemas 12.

(26) dinâmicos, os quais podem ser lineares ou não-lineares, modelados em tempo contínuo ou discreto. Permite a construção de modelos utilizando diagramas de blocos através de uma interface gráfica. Simulink apresenta uma biblioteca ampla de blocos de fontes, consumidores, componentes lineares e não-lineares, e conectores. Além disso, blocos podem ser modificados ou criados para atender as necessidades do usuário. Para analisar os resultados, Simulink possui integração com MATLAB [20], uma linguagem de alto nível para computação numérica que oferece funções matemáticas para álgebra linear (matrizes e vetores), estatística e otimização, entre outras. •. SIMUL8 [21] – ambiente integrado para criação de modelos de simulação de eventos discretos. Direcionado para a área de negócios, é apropriado para modelar o funcionamento de fábricas, centrais telefônicas e empresas em geral. Em outras palavras, permite modelar e analisar o desempenho de uma configuração de máquinas e pessoas. Um modelo SIMUL8 consiste de cinco elementos chave: um ponto de entrada, uma fila (ou área de armazenamento), um centro de trabalho (pessoas, máquinas, etc.), um ponto de saída e um recurso. Resultados e medidas de desempenho, como taxa de saída e estatísticas sobre a fila, são coletados automaticamente durante a execução do modelo.. •. Dymola (Dynamic Modeling Laboratory) [22] – ambiente para modelagem (orientada a objetos) e simulação de sistemas físicos. Permite composição hierárquica de modelos, modelagem multi-domínio (isto é, modelagem de sistemas que são compostos por subsistemas de domínios diferentes) e reuso de componentes e modelos. Um modelo Dymola é criado através de sua interface gráfica, gerando scripts em Modelica, uma linguagem orientada a objetos para modelagem de sistemas grandes, heterogêneos e complexos. Cada variável de cada componente é armazenada automaticamente em Dymola, podendo ser armazenados em arquivos ou manipulados através dos scripts em Modelica. Dymola oferece ainda animação 3D e simulação em tempo real.. 2.7 Considerações finais Esse capítulo abordou os principais aspectos referentes ao processo de simulação. Inicialmente foi discutida a importância da simulação, expondo suas aplicações e vantagens, e 13.

(27) precauções que devem ser consideradas ao utilizar processos de simulação. Em seguida foi apresentada a classificação dos modelos de simulação, a qual está relacionada aos conceitos de variáveis de estado, à forma como estas sofrem alterações ao longo do tempo e a eventos. Os termos e conceitos mais utilizados em simulação foram descritos e uma estratégia para modelagem e simulação foi apresentada. Também foram feitos comentários em relação a alguns métodos para validação dos modelos de simulação, tendo sido listados os erros mais comuns envolvidos nessa abordagem, e discutidos a necessidade de validação de modelos e o uso de técnicas mais apropriadas ao objetivo do processo. Finalmente, alguns ambientes e linguagens de simulação, como Simscript e Simulink, foram expostos. O capítulo seguinte discorrerá sobre testes em sistemas, enfatizando testes de conformidade.. 14.

(28) 3. Testes em sistemas Esse capítulo apresenta os tipos de testes que podem ser realizados em sistemas, enfatizando a metodologia dos testes de conformidade. Essa metodologia de desenvolvimento de testes, descrita na recomendação OSI-9646 (adotada também pelo ITU-T sob a recomendação X.290) [4], é apresentada, sendo descritos os seu principais conceitos e características relacionados.. 3.1 Escopo dos testes de software Em engenharia de software os testes são atividades essenciais para que se possa alcançar o nível de qualidade especificada no projeto do sistema. Normalmente são empregados em testes recursos na ordem de quarenta por cento do custo (esforço) total do projeto. Freqüentemente a atividade de testes insere tantos erros em um produto quanto à própria implementação. Contudo, o custo para corrigir um erro na fase de manutenção é muito maior do que o custo para corrigi-lo na fase de desenvolvimento, o que justifica a preocupação com o planejamento dos testes desde a fase inicial do projeto [23]. Para assimilar a importância dos testes em desenvolvimento de sistemas, é necessário compreender as atribuições inerentes aos conceitos de verificação e validação, dois termos comumente utilizados para definir o processo de testes. Em [24], verificação está relacionada com a necessidade de o sistema estar de acordo com suas especificações e validação está relacionada com a necessidade de o sistema atingir os propósitos esperados pelo usuário. Para satisfazer os objetivos de validação e verificação podem ser empregadas técnicas de checagem estáticas e dinâmicas. As técnicas estáticas envolvem análises e checagem dos elementos utilizados no projeto do sistema, tais como especificações, requisitos, diagramas de projeto e análise no código fonte dos programas através de métodos formais. As técnicas dinâmicas objetivam demonstrar a operacionalidade de uma implementação através de sua execução exaustiva ou ainda estimulando a implementação através da aplicação de casos de teste. Um caso de teste é um procedimento desenvolvido para verificar funcionalidades específicas de uma implementação para o qual são definidos um conjunto de entradas e condições de execução e cujos resultados são comparados com resultados previamente elencados. É evidente a importância dos testes no desenvolvimento de qualquer sistema. Em [25] são formalizados os objetivos ou regras por trás da aplicação dos testes em sistemas: 15.

(29) •. Testar é o processo de execução de um programa visando encontrar um erro;. •. Um bom caso de teste deve ter alta probabilidade de encontrar erros ainda não descobertos;. •. Um teste realizado com sucesso é aquele que encontra um erro ainda desconhecido.. Além destas características, o engenheiro de testes deve ter a preocupação de projetar os casos de teste de maneira a cobrir o máximo de ocorrências de erros possíveis, reduzindo o consumo de esforço e tempo. A realização satisfatória dos testes pode demonstrar que o sistema está funcionando de acordo com a especificação e que os requisitos de desempenho foram atendidos. Entretanto, não pode garantir a inexistência de erros; garante apenas que estes existem caso sejam detectados.. 3.2 Tipos de testes Na área de testes em sistemas, existem várias técnicas de geração de casos de teste cujo objetivo é encontrar falhas que conduzam à correção de erros em sua codificação. Há também técnicas cujo objeto de análise é o comportamento externo da implementação, não havendo preocupação explícita com a qualidade da codificação. Assim, os testes são classificados de acordo com as fases do processo de desenvolvimento, podendo ser testes de unidade, testes de integração, testes de validação ou testes de sistema (aceitação). •. Testes de unidade – verificam um elemento que possa ser logicamente tratado como unidade de implementação, por exemplo, uma sub-rotina ou um módulo. Em sistemas com tecnologia orientada a objetos, a classe é uma unidade típica. Os testes de unidade normalmente são realizados pelos próprios desenvolvedores a cada compilação do sistema, geralmente de forma automática [24]. Os testes de unidade podem ser realizados usando um caso de teste para cada método ou um caso de teste que envolva vários métodos. Essas escolhas são feitas pelo projetista de testes dependendo das medidas de qualidade do software previstas no plano de qualidade. Este pode especificar, por exemplo, que sejam feitos testes unitários para 100% dos métodos, ou que a cobertura seja de 100% dos métodos públicos e 50% dos métodos privados. Contudo, pelo menos um caso de teste por componente desenvolvido deve ser gerado, objetivando dessa forma, realizar a maior cobertura 16.

(30) de código possível. •. Testes de integração – verificam se as unidades já testadas funcionam corretamente quando interagem entre si e em conjunto com unidades já integradas. Esta técnica viabiliza a detecção de erros nas interfaces. A abordagem big bang [26] realiza o teste do sistema após o término da implementação de todas as unidades. Desta maneira, muitos erros são detectados e corrigidos, contudo, outros podem aparecer. Em uma outra abordagem o sistema pode ser testado através de integração incremental, onde cada unidade é integrada em pequenos segmentos, reduzindo o escopo de possibilidades de ocorrência de erros, tornando-os mais fáceis de se detectar e corrigir. Nesse contexto, unidades já integradas e verificadas sem erros podem voltar a apresentar erros. Esse tipo de teste, conhecido por teste de regressão, é a realização de um conjunto de casos de teste para garantir que modificações no código referentes a novas unidades integradas não introduzam comportamento indesejável no sistema.. •. Testes de validação – a validação de software é alcançada quando os critérios de validação previstos nas especificações dos requisitos de software são satisfeitos. Os testes denominados caixa-preta são a estratégia mais utilizada para aplicação desses tipos de casos de teste.. •. Testes de sistema (aceitação) – legitimam o produto, verificam se o sistema atende aos requisitos especificados, funcionais e não funcionais. O requisito é uma condição cuja exigência deve ser satisfeita. Se a condição é produzir algo, diz-se que o requisito é funcional. Se a condição é caracterizar algo (atributo, propriedade, comportamento, restrição, etc.), diz-se que o requisito é não-funcional [27]. O sistema deve ser testado com entradas reais visando detectar erros operacionais e/ou deficiência em desempenho. Tais testes são também conhecidos por testes alfa.. Os testes também podem ser classificados quanto ao método de aplicação durante a seleção dos testes. Podem ser testes estruturais e testes funcionais. •. Testes estruturais – focalizam a implementação do programa (código, funções, procedimentos e fluxo de dados e controle). Os casos de teste devem ser elaborados 17.

(31) para garantir que a maior abrangência possível das instruções do programa tenham sido exercitadas pelo menos uma vez. São também conhecidos como testes de caixa-branca; •. Testes funcionais – são testes cuja estrutura interna de composição do código não é relevante. São baseados na especificação ou no ambiente de operação do sistema. São também conhecidos por testes de caixa-preta ou testes de comportamento. Os testes de conformidade são um tipo de teste funcional [24].. Para sistemas distribuídos, além dos testes já citados, podem ser aplicados testes de interoperabilidade – para avaliar se sistemas desenvolvidos por equipes diferentes podem interagir; testes de performance – para aferir os limites das capacidades dos sistemas e testes de robustez – para estimar o quanto um sistema pode permanecer em funcionamento quando submetido a entradas não esperadas.. 3.3 Testes de conformidade Com o surgimento das redes de computadores, manifestou-se também a necessidade de interligação dos sistemas computacionais até então operando em modo stand alone. Cabe salientar que muito antes desse período, no sistema telefônico testes de conformidade já eram amplamente usados, trabalhando com comutação de circuitos, e obviamente seguindo as especificações dos protocolos de comunicação controlados pelo então CCITT (Consultative Committee for International Telegraphy and Telephony), hoje o atual ITU-T – International Telecommunications Union-Telecommunications Standard Sector [28]. Um protocolo de comunicação descreve regras com as quais as partes que desejam estabelecer comunicação devem se comprometer a utilizar para que a comunicação seja efetivada. Na década de 70, empresas como a Digital Equipment Corporation (Digital), IBM, e Xerox desenvolveram seus próprios protocolos e arquiteturas de rede. Entretanto, tornava-se nítida a insatisfação dos usuários dessas redes proprietárias, em virtude de não ser possível combinar no mesmo ambiente o uso de equipamentos de diferentes fabricantes. Em 1978, a ISO – International Standards Organization – editou um conjunto de protocolos baseados em uma arquitetura de sete camadas com a finalidade de descrever as funções e interfaces de cada uma delas, proporcionando assim um conjunto de procedimentos a serem seguidos por fabricantes de equipamentos de redes, objetivando a interoperação de seus produtos. 18.

(32) Todavia, não é condição suficiente especificar e padronizar protocolos de comunicação para garantir que implementações funcionem satisfatoriamente. É necessário que essas implementações sejam submetidas a métodos de verificação que possam avaliar o quanto seu comportamento está de acordo com as especificações do protocolo utilizado na codificação. Em outras palavras, é necessário avaliar se a implementação está em conformidade com as especificações do protocolo. Esta metodologia de testes é conhecida como testes de conformidade de protocolos. Apesar de terem sido projetados para avaliar protocolos OSI (Open System Interconnection), os testes de conformidade têm sido aplicados a um grupo cada vez maior de implementações de protocolos de comunicação. Para estabelecer os testes de conformidade, é necessário que a especificação do protocolo esteja disponível para a derivação dos testes, que esteja correta e tenha sido validada [27]. Tais testes verificam se as implementações atendem às especificações do protocolo (requisitos de conformidade), aferindo as capacidades e comportamentos estipulados no projeto de testes. Grosso modo, se a realização dos testes acontecer satisfatoriamente e gerar resultados positivos, a probabilidade de que equipamentos de fabricantes diferentes possam interoperar aumenta bastante. Entretanto, a aplicação de testes de conformidade não garante a eficiência da implementação. A ISO, através das recomendações OSI-9646, propôs um arcabouço de desenvolvimento de testes de conformidade. Nas seções seguintes serão apresentados detalhes dessa recomendação, classificação dos testes, principais conceitos e documentos necessários ao planejamento dos testes de conformidade.. 3.3.1 Visão geral da recomendação OSI 9646 O arcabouço de testes de conformidade editado pela ISO, Open System Interconnection 9646, é um conjunto de documentos divididos em sete partes, e descreve o arcabouço de testes de conformidade. Inicialmente o objetivo era aplicá-lo apenas para os protocolos OSI, entretanto também tem sido utilizado para avaliar outros tipos de protocolos, tais como ISDN – Integrated Services Digital Network, SIP – Session Initiation Protocol, etc. A Figura 3.1 ilustra as atividades pertinentes ao arcabouço de testes de conformidade e a correspondência dessas atividades com as responsabilidades de cada recomendação OSI9646. Uma breve descrição de cada uma das partes componentes do arcabouço OSI-9646 será apresentada a seguir: 19.

(33) •. ISO9646-1 – introduz os conceitos gerais relativos ao processo de elaboração e execução dos casos de teste e geração de relatórios de conformidade;. •. ISO9646-2 – descreve o processo de especificação da suíte de testes abstratos relativos à elaboração das especificações dos testes;. •. ISO9646-3 – define a notação de testes TTCN2 (Tree and Tabular Combined Notation), utilizada para descrever os casos de teste para um sistema;. •. ISO9646-4 – descreve o modo como os testes devem ser realizados, e quais as condições necessárias para aplicá-los;. •. ISO9646-5 – descreve os requisitos pertinentes aos laboratórios e clientes envolvidos no processo de realização dos testes e geração dos relatórios de conformidade;. •. ISO9646-6 – elabora as especificações dos perfis de testes (PTS) que serão utilizadas na definição dos grupos de perfis;. •. ISO9646-7 – relaciona os requisitos para a elaboração dos ICSs e SCSs e seus respectivos questionários. Esses documentos são utilizados pelos desenvolvedores, fornecedores de produtos e laboratórios de testes.. Nesse texto, dentre os documentos descritos acima, será dada maior ênfase às recomendações ISO9646-1 e ISO9646-2. Os termos PTS, ICS e SCS utilizados nessa seção serão descritos na seção 3.3.2.. 2. Na versão três, TTCN é chamada de Testing and Test Control Notation.. 20.

(34) Protocol Specifications. Service Definitions. OSI Protocol Defining Group. Abstract Test Suíte Specification ISO9646-2 Test Suite Structure and Test Purposes Profile Specification. Protocol Profile Test Specification ISO9646-6. TTCN ISO9646-3. Test Specifier. Profile Defining Group. Abstract Test Suites. Test Realizer Test Realization ISO9646-4. PTS. Means of Testing. Conformance Assessment Process ISO9646-5. Implementation Conformance Statements ISO9646-7. IUT, ICSs, IXITs Client and Test Laboratory T es ting the IU T. Test Reports. Figura 3.1 Atividades e recomendações relacionadas no arcabouço de testes de conformidade[4]. 3.3.2 O processo de avaliação de conformidade O processo de avaliação de conformidade compreende três fases. As referências detalhadas dessas fases podem ser encontradas na recomendação ISO-9646-1 e serão descritas a seguir: a) Preparação para os testes A fase de preparação dos testes, também conhecida por geração ou derivação dos testes, engloba a produção dos documentos necessários à confecção do ATS (Abstratc Test Suite) para um determinado protocolo (OSI). Esse conjunto de testes é dito “abstrato” no sentido de que os testes são desenvolvidos independentemente de qualquer linguagem ou ambiente de implementação, e baseados estritamente nas especificações do protocolo. Nesse tipo de teste, por ser abstrato, é permitido o mapeamento desse conjunto de testes para qualquer ambiente que implemente o protocolo. 21.

(35) Alguns documentos devem ser confeccionados nessa fase: ICS (Implementation Conformance Statement) – documento que relaciona as capacidades relevantes no(s) protocolo(s) que devem ser implementadas em um sistema; SCS (System Conformace Statement) – sumário dos ICSs envolvidos no projeto de testes; IXIT (Implementation Extra Information for Testing) – testes adicionais ao ICS relativos às características do ambiente onde a implementação será executada. A confecção de todos esses documentos não é obrigatória e depende do escopo dos testes. Também é nessa fase que serão escolhidos os ATMs (Abstract Test Methods) para descrever como uma IUT (Implementation Under Test) deve ser testada, e como preparar o SUT (System Under Test) – sistema de suporte à implementação, assim como todos os recursos necessários para a realização dos testes. Os detalhes dessa fase serão descritos na Seção 3.3.9. b) Realização dos testes Nessa fase é aconselhável uma revisão nos requisitos estáticos de conformidade conduzidos pela observação dos ICS e SCS, além de uma análise da consistência dos IXITs. Também é nessa fase que se realiza a seleção e parametrização dos testes baseados nos ICSs e IXITs, finalizando com um ou mais procedimentos de teste (test campaigns). Em outras palavras, é a execução propriamente dita dos testes de conformidade em uma implementação. O ATS deve ser adaptado ao ambiente de testes passando a chamar-se de ETS (Executable Test Suite) – que poderá então ser executado ou interpretado no ambiente real de testes. c) Produção dos relatórios de testes Os casos de teste implementados (ETS) são executados e após a realização dos testes são gerados arquivos (logs) contendo os resultados dos testes. Esses resultados dos testes de conformidade (verdict test) são gerados considerando as entradas e saídas da IUT obtidos a partir dos PCOs (Point of Control and Observation) e devem ter sido previamente definidos no ATS. Os resultados podem ter três estados: •. Conforme – indica que a característica que gerou o resultado observado no teste está de acordo com os requisitos de conformidade pressupostos nos propósitos de teste e casos de teste relativos a essa especificação;. •. Não-conforme – indica que a característica que gerou o resultado observado no caso de teste demonstra não estar em conformidade em pelo menos um requisito 22.