FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS DANIELE FERNANDES FERREIRA MIRIAN KARIME PIEVE NUNES

Transcrição

1 FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS DANIELE FERNANDES FERREIRA MIRIAN KARIME PIEVE NUNES INTEGRAÇÃO DOS MÉTODOS UNIQUE INPUT/OUTPUT (UIO) E DISTINGUISHING SEQUENCE (DS) À FERRAMENTA WEB-PERFORMCHARTS SÃO JOSÉ DOS CAMPOS - SP 2010

2 2 Daniele Fernandes Ferreira Mirian Karime Pieve Nunes INTEGRAÇÃO DOS MÉTODOS UNIQUE INPUT/OUTPUT (UIO) E DISTINGUISHING SEQUENCE (DS) À FERRAMENTA WEB-PERFORMCHARTS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados. Orientador: Profª. Me. Érica Ferreira de Souza SÃO JOSÉ DOS CAMPOS 2010

3 3 Daniele Fernandes Ferreira Mirian Karime Pieve Nunes INTEGRAÇÃO DOS MÉTODOS UNIQUE INPUT/OUTPUT (UIO) E DISTINGUISHING SEQUENCE (DS) À FERRAMENTA WEB-PERFORMCHARTS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados. ALESSANDRO OLIVEIRA ARANTES, ME AMITA MURALIKRISHNA, ME ÉRICA FERREIRA DE SOUZA, ME / / DATA DE APROVAÇÃO

4 4 Dedicamos este trabalho a todos que o tornaram possível.

5 5 AGRADECIMENTOS Agradecemos primeiramente a Deus, por ter nos permitido ingressar na Faculdade de Tecnologia de São José dos Campos e pela capacidade de realizar este trabalho. Aos nossos pais e familiares por torcerem pelo nosso sucesso e nos apoiarem durante o desenvolvimento deste trabalho. À nossa orientadora Érica Souza pela presença, disponibilidade e paciência durante as etapas deste trabalho. Além de sua atenção motivadora a todo momento. Ao Alessandro Arantes pela ajuda, atenção e por ter compartilhado seus conhecimentos, essenciais para o direcionamento deste trabalho. Agradecemos também aos colegas de classe que de alguma forma contribuíram para a realização deste trabalho. Finalmente, ao Profº Vijaykumar pela atenção e disposição para possibilitar a concretização deste trabalho.

6 6 O futuro pertence àqueles que acreditam na beleza de seus sonhos. Elleanor Roosevelt

7 7 RESUMO A Web-PerformCharts é uma ferramenta de teste de software desenvolvida no Instituto Nacional de Pesquisas Espaciais (INPE) que possibilita a geração de casos de testes através da Internet. Esta ferramenta converte uma especificação em Statecharts, que é uma representação sintética de sistemas críticos e complexos, em uma Máquina de Estados Finito (MEF). A ferramenta em questão foi criada de forma a automatizar a geração de casos de teste, podendo também ser utilizada de forma remota. Atualmente a Web-PerformCharts pode gerar casos de teste com base nos métodos de teste Transition Tour (TT) e Switch Cover. No entanto, alunos e pesquisadores do INPE acreditam que outros métodos, como o Unique Input/Output (UIO) e o Distinguishing Sequence (DS), também podem ser integrados à ferramenta. Diante deste contexto, este trabalho tem como objetivo investigar o comportamento dos métodos DS e UIO e da ferramenta Web-PerformCharts, a fim de incorporar tais métodos ao ambiente da Web-PerformCharts. Palavras chave: Web-PerformCharts, métodos de teste, Statecharts, Máquinas de Estados Finitos.

8 8 ABSTRACT The Web-PerformCharts is a tool for testing software developed at the National Institute for Space Research (INPE) that enables the generation of test cases through the Internet. This tool converts a specification from Statecharts, which is a formal representation of complex and critical systems, to a Finite State Machine (FSM). The tool in question was created to automate the generation of test cases, it can also be used remotely. Nowadays, the Web- PerformCharts can generate test cases based on test methods Transition Tour (TT) and Switch Cover. However, students and researchers from INPE believe that other methods such as the Unique Input / Output (UIO) and Distinguishing Sequence (DS), can also be integrated into the tool. In this context, this study aims to investigate the behavior of DS and UIO methods and Web-PerformCharts tool in order to incorporate these methods to the environment of Web-PerformCharts. Keywords: Web-PerformCharts, Test method, Test cases, Statecharts, Finite State Machine.

9 9 LISTA DE FIGURAS Figura 1. Relação entre falha, erro e detecção Figura 2. Modelo de 3 universos. Uma simplificação do modelo de 4 universos de Avizienis Figura 3. Ciclo de Vida em "V" Figura 4. MEF: diagrama de transição de estados Figura 5. Especificação em Statecharts de um sistema com duas máquinas e um reparador. 29 Figura 6. Representação da busca em largura do método UIO Figura 7. MEF para exemplo dos métodos Figura 8. Fluxograma do método de teste UIO Figura 9. Máquina de Estado Finito: Implementação do método DS Figura 10. Fluxograma do método de teste DS Figura 11. Arquitetura da ferramenta Web-PerformCharts Figura 12. Tela de login antiga da ferramenta Web-PerformCharts Figura 13. Tela de login atual da ferramenta Web-PerformCharts Figura 14. Tela de acesso inicial antiga Figura 15. Tela de acesso inicial atualizada Figura 16. Upload do PCML na Web-PerformCharts Figura 17. A opção Run PerformCharts é ativada para gerar a MEF a partir do arquivo PCML Figura 18. Escolha de método de teste para geração de casos de teste Figura 19. Metodologia anterior dos métodos DS e UIO Figura 20. Metodologia atual dos métodos DS e UIO Figura 21. Diagrama de sequência para geração de casos de teste a partir dos métodos DS e UIO adaptados Figura 22. Diagrama de geração de casos de teste Figura 23. MEF do modelo em Statecharts da Figura Figura 24. Geração de casos de teste a partir do método UIO Figura 25. MEF para geração de casos de teste do método DS Figura 26. Geração de casos de teste a partir do método DS Figura 27. Estrutura da tabela uiotestcase Figura 28. Estrutura da tabela dstestcase Figura 29. Fluxograma para geração de casos de teste... 56

10 10 LISTA DE TABELAS Tabela 1. MEF: tabela de transição de estados Tabela 2. Operações da MEF na Figura Tabela 3. Sequências entrada e saída de cada estado da MEF Tabela 4. Entradas e saídas obtidas Tabela 5. Descrição do método UIO Tabela 6. Descrição do método DS Tabela 7. Saídas obtidas a partir de cada estado quando se aplica a sequência DS... 37

11 11 LISTA DE ABREVIATURAS E SIGLAS ABREVIATURAS E SIGLAS DS GTSC INPE ISO/IEC LAC MEF PCML PHP TBM TT UIO UNICAMP V&V XML SIGNIFICADOS Distinguishing Sequence Geração Automática de Casos de Teste Baseada em Statecharts Instituto Nacional de Pesquisas Espaciais International Organization for Standardization/ International Electrotechnical Commission Laboratório Associado de Computação Máquinas de Estados Finitos Performcharts Marckup Language Hypertext Preprocessor Testes Baseados em Modelos Transition Tour Unique Input/Output Universidade de Campinas Verificação e Validação extensible Markup Language

12 12 SUMÁRIO INTRODUÇÃO Motivação Problema Proposta de Solução Organização do Trabalho TESTES DE SOFTWARE Definição Técnicas de teste de Software Funcional Estrutural Testes baseados em modelos Diagrama de Estados Statecharts Métodos de teste para MEF Unique-Input-Output Sequence (UIO) Fluxograma do método de teste UIO Distinguishing Sequence (DS) Fluxograma do método de teste DS Ferramentas de teste de software Web-PerformCharts Arquitetura Trabalhos relacionados INTEGRAÇÃO DOS MÉTODOS DE TESTE À FERRAMENTA WEB- PERFORMCHARTS Ferramenta Web-PerformCharts Interface gráfica Metodologia da ferramenta Adaptação dos métodos DS e UIO Metodologia anterior... 49

13 13 Metodologia atual Resultados obtidos Banco de dados Fluxograma de geração de casos de teste CONSIDERAÇÕES FINAIS Contribuições e conclusões Publicação Trabalhos Futuros REFERÊNCIAS... 61

14 14 INTRODUÇÃO Atualmente, no mercado de software, as empresas estão à procura de modelos e processos de teste que garantam qualidade dos seus sistemas computacionais, criando produtos de qualidade e sem erros, a fim de atender as necessidades dos clientes. Projetos mal sucedidos, com prazos excedidos e sistemas com falhas, trazem a insatisfação dos clientes, gastos com manutenções e comprometem a imagem da empresa. Surge, então, o desafio da redução de custos e de tempo para o desenvolvimento do software e ainda a necessidade de automatizar os serviços e melhoria da qualidade do mesmo (PRESSMAN, 1995). Para que um software seja considerado de qualidade ele deve possuir um conjunto de características que são: i) funcionalidade: inclui adequação, interoperabilidade e conformidade; ii) confiabilidade: compreende tolerância a falhas, recuperabilidade, maturidade; iii) usabilidade: inclui operacionabilidade, intelegibilidade e apreensibilidade; iv) eficiência: abrange tempo e recursos; v) manutenibilidade: inclui modificabilidade, estabilidade e testabilidade; e, vi) portabilidade: compreende adaptabilidade, instabilidade, conformidade e capacidade de ser substituído (ISO/IEC 9126, 1991). Os termos falha, erro e defeito possuem diversas definições na engenharia de software. Neste contexto, estes termos são definidos da seguinte maneira (AVIZIENIS, 2001): i) defeito desvio do comportamento esperado ou especificado do sistema; ii) erro parte do estado do sistema que pode levar a um defeito; iii) falha a causa de um erro. Erro e falha podem ser determinados no conceito de causa e consequência. Um erro pode ser definido como consequência de uma falha, e assim, ocasionar um defeito como mostra a Figura 1.

15 15 Ativação Propagação Falha Erro Defeito Figura 1. Relação entre falha, erro e detecção (AVIZIENIS, 2001) A Figura 2 representa uma simplificação do modelo de 4 universos, determinado por Avizienis. Como mostra o modelo, falhas podem ser toleradas, defeitos não. Figura 2. Modelo de 3 universos. Uma simplificação do modelo de 4 universos de Avizienis (AFONSO, 2006). A detecção de erros, e posteriores falhas nos sistemas, e a garantia de confiabilidade e qualidade dos sistemas podem ser adquiridas quando são realizadas atividades de teste em todas as fases de desenvolvimento do sistema, principalmente daqueles considerados críticos e complexos, como software em aplicações espaciais. A realização da atividade teste de software, de forma automatizada torna o trabalho do testador mais rápido e consistente. Existem ferramentas de teste de software que já solucionam este problema. Porém, cada ferramenta possui finalidades diferentes e são dependentes de métodos de teste, que serão apresentados no contexto deste trabalho. Os métodos de teste são responsáveis por gerar os casos de teste a partir de modelos de sistema. A integração destes métodos às ferramentas de teste é importante para que o teste de software seja realizado, gerando assim os casos de teste.

16 16 Motivação O software, quando não testado de forma sistemática e criteriosamente, pode falhar e causar perdas e danos sociais, econômicos e ambientais. Alguns exemplos de software considerados críticos que falharam e causaram perdas significativas são (PULLUM, 2001): i) destruição do foguete Ariane 5 em 1996; ii) perca do Mars Climate Orbiter em 1999 antes de completar um ano de lançamento; iv) mars Polar Lander Sinais estranhos provocaram aterragem incorreta em 1999; vi) explosão da usina nuclear de Chernobyl em 1986; vii) entre outros. Tais desastres, e assim como outros, podem ser evitados se realizadas atividades de teste que permitem uma análise dinâmica do sistema, identificando e eliminando erros que possam persistir (MALDONADO, 2004). Alguns grupos de pesquisa de teste de software no INPE trabalham fortemente com atividades relacionadas a testes de sistemas críticos através de dois ambientes: o ambiente de Geração Automática de Casos de Teste Baseada em Statecharts (GTSC) (SANTIAGO, 2007) e a ferramenta Web-PerformCharts (ARANTES, 2008). A ferramenta Web-PerformCharts integra métodos apropriados para a geração dos casos de teste e, com isso, automatiza o processo de teste de software. No entanto, existe uma necessidade de integrar novos métodos de teste ao seu ambiente. Atualmente a ferramenta possui apenas dois métodos implementados, sendo eles os métodos Transition Tour (TT) e o Switch Cover (ARANTES, 2008). Está no escopo deste trabalho o estudo dos métodos de teste Unique Input/Output (UIO) e o método Distinguishing Sequence (DS) (LEE, 1996) e a ferramenta Web-PerformCharts.

17 17 Problema Existe a necessidade de integrar os métodos de teste DS e UIO à ferramenta Web- PerformCharts. Tais métodos já foram desenvolvidos, entretanto não foram incorporados à ferramenta devido às diferenças dos ambientes em que foram desenvolvidos visto que, a ferramenta foi desenvolvida em linguagem Hypertext Preprocessor (PHP) e C++ e os métodos em linguagem Java. A integração desses métodos de teste na ferramenta Web-PerformCharts é importante para possibilitar a realização de testes em sistemas críticos, baseados em Statecharts, utilizando-se de novos critérios de geração de casos de teste. Proposta de Solução Para a realização deste trabalho, deverá ser feito um estudo dos métodos de teste DS e UIO de modo que possa ser feita a integração destes ao ambiente da ferramenta Web-PerformCharts, possibilitando a geração de casos de teste para software embarcado, usando especificações em Statecharts (HAREL, 1987). Para integrar em um único ambiente métodos de teste, deverá se conhecer o ambiente Web- PerformCharts, compreender os algoritmos de geração de casos de testes e implementar na Web-PerformCharts os métodos UIO e DS. A partir da integração destes métodos é possível fazer estudos de custo e eficiência dos resultados obtidos com a execução dos métodos de teste em diferentes sistemas (SOUZA, 2010).

18 18 Organização do Trabalho Este trabalho está organizado da seguinte forma: O Capítulo 1 apresenta a introdução ao assunto, a motivação, o relato do problema que levou ao desenvolvimento do trabalho e a proposta de solução para o problema detectado. O Capítulo 2 expõe conceitos e definições sobre teste de software e técnicas de teste de software (Funcional e Estrutural), abordagem sobre Testes Baseados em Modelos (Statecharts e diagrama de estados), que é o método utilizado no presente trabalho, apresentação dos métodos de teste - DS e UIO, trabalhos relacionados e ferramentas de teste de software. O Capítulo 3 mostra a contribuição para integração dos métodos. Análises e alterações realizadas nos métodos e na ferramenta também são apresentadas neste capítulo. O Capítulo 4 apresenta as contribuições, conclusões, dificuldades e publicação referentes a esse trabalho, além das experiências adquiridas ao término deste e a proposta de trabalhos futuros relacionados ao tema do trabalho apresentado. Finalmente, o Capítulo 5 mostra as referências utilizadas para estudos e análises do tema abordado a fim de possibilitar o desenvolvimento do trabalho proposto.

19 19 TESTES DE SOFTWARE O objetivo do Capítulo 2 é apresentar conceitos e definições de teste de software. O capítulo está organizado como segue: a seção 2.1 apresenta a importância de se executar a atividade de teste para detecção de erros no software e conceitos relacionados; a seção 2.2 mostra as técnicas de teste de software (Funcional e Estrutural); a seção 2.3 mostra conceitos sobre testes baseados em modelos (Diagrama de estados e Statecharts) que é o método utilizado no trabalho; a seção 2.4 apresenta alguns exemplos de métodos de teste para MEF, em destaque os UIO e DS que fazem parte do escopo do trabalho; a seção 2.5 apresenta ferramentas de teste de software dentre elas a Web-PerformCharts abordada no escopo deste trabalho e a seção 2.6 relata alguns trabalhos relacionados ao escopo do trabalho. Definição O teste de software é um elemento da garantia da qualidade de software que ao ser realizado deve ser rigoroso e bem planejado, pois se ocorrer alguma falha no sistema o custo de atendimento a ela pode ser alto. O teste de software representa uma revisão final de uma especificação, projeto e codificação (PRESSMAN, 2000). A principal função do teste é encontrar erros no software construído, para isso o engenheiro de software cria casos de testes. Para o teste é necessário que o desenvolvimento olhe novamente as noções de correção preconcebidas de software e que quando erros sejam descobertos os conflitos de interesse sejam superados (PRESSMAN, 2002). A atividade de teste ainda é importante para a eliminação de erros que persistem, embora existam métodos, técnicas e ferramentas com a finalidade de evitar a introdução de erros no produto, e a atividade de teste ainda continua sendo a melhor maneira de se detectar e eliminar erros que persistem (MALDONADO, 1991).

20 20 Descobrir um erro por meio de um bom caso de teste executando um programa é o objetivo da fase de teste, segundo Myers (1979). Um bom caso de teste é aquele que revela defeitos no software e um caso de teste de sucesso é aquele que detecta defeitos ainda não descobertos. Os resultados, que confirmam a garantia da qualidade do software, são obtidos através dos processos de teste. Estes devem estar presentes em todo o ciclo de desenvolvimento do software, ou seja, desde o início da implementação até a obtenção da conformidade do produto. O momento em que os testes são iniciados, definidos e alinhados é conhecido como ciclo de vida em V, onde, os processos de fazer e verificar estão presentes desde o passo inicial até a final do projeto, conforme mostra a Figura 3 (BASTOS 2007). Figura 3. Ciclo de Vida em "V" Fonte: (BASTOS, 2007) Existem processos de verificação e análise dos sistemas computacionais que são termos conhecidos como Verificação e Validação (V&V). Esses termos asseguram que o software siga suas especificações e atenda as necessidades do cliente. Esses processos permitem uma

21 21 revisão do projeto e inspeção de código até chegar ao teste do produto e devem estar presentes em todo o ciclo de desenvolvimento. Os resultados dos processos são analisados se estão como especificados através dessas atividades (SOMMERVILLE, 2004). O termo Validação destina-se em avaliar se o software atende às perspectivas do cliente, enquanto Verificação é destinada para realizar verificações/revisões nos documentos de requisitos, de design e de modelos de dados, para que os erros sejam detectados ainda em fase de projeto e verificar se os requisitos funcionais e não funcionais estão sendo atendidos. De acordo com Boehm (1979) a diferença entre validação e verificação pode ser expressa pelas frases: (SOMMERVILLE, 2004) Validação - O produto que está em construção, é o produto correto? Verificação - O produto que está sendo construído está sendo construído de maneira correta? Os testes podem aumentar a confiança de que o software desempenha as funções especificadas e acentuar algumas características relacionadas à qualidade do produto, se conduzido sistemática e criteriosamente, porém não prova que um programa está correto (VINCENZI, 1988). O ideal seria se o programa fosse executado com todas as entradas possíveis, mas para se realizar o teste é necessário tempo e recursos, e por isso o teste exaustivo é impraticável. É necessário determinar quais casos de teste utilizar e que o número dos mesmos não seja grande e ainda assim encontrar todos os erros existentes. A confiabilidade do software e sua garantia podem ser garantidas através dos dados que são coletados, conforme a condução do teste (MALDONADO, 1997; MALDONADO et al, 1998). As técnicas e métodos que estão sendo elaborados têm o objetivo de oferecer uma maneira sistemática e rigorosa para se selecionar um subconjunto do domínio de entrada e ainda, de maneira eficiente mostrar erros que existem não ultrapassando restrições de tempo e custo relacionados a um projeto de software (VINCENZI, 1998).

22 22 Técnicas de teste de Software Técnicas e métodos de teste fornecem ao desenvolvedor uma abordagem sistemática e teórica para condução e avaliação da qualidade do software. As técnicas de teste são complementares e o importante é saber como utilizá-las de forma que os benefícios de todas sejam melhor explorados, de maneira que levem a uma realização da atividade de teste de boa qualidade. Isto inclui baixo custo e eficácia (HOWDEN, 1987). As técnicas mais conhecidas são: teste estrutural, teste funcional e teste baseado em erros. Para o propósito deste trabalho foi feito um estudo mais detalhado da técnica de teste Funcional. Funcional Também conhecido como teste caixa-preta são analisados os requisitos funcionais do software. Não existe preocupação com a estrutura lógica interna do sistema. O objetivo é verificar se o sistema executa suas funções normais de maneira correta (PRESSMAN, 2002). Na sequência, são apresentadas algumas técnicas utilizadas no Teste Funcional (PRESSMAN, 2002): Particionamento em classes de equivalência: divide o domínio de entrada do programa em classes de dados (classes de equivalências). Após, seleciona-se casos de teste, fundamentando que um elemento de uma dada classe a representaria. Deve ser gerado um caso de teste diferente para cada uma das classes inválidas, ou seja, os dados de teste são derivados a partir das classes de equivalência. Assim, o número de casos de testes necessários torna-se restritos (MALDONADO, 2004).

23 23 Análise do Valor Limite: este método complementa o método Particionamento em classes de Equivalência. Ao invés de se escolher um elemento da classe, selecionamse os casos de teste nas extremidades da classe, onde se encontra a maior concentração de erros, com isso os valores de entrada são exercitados de forma mais rigorosa. O espaço de saída é particionado e são exigidos casos de testes que criem resultados também nos limites de tais classes de saída. Grafo de Causa-Efeito: este método estabelece requisitos de teste com base nas combinações possíveis de condições de entrada, diferente dos métodos anteriores. Primeiro, as condições de entrada (causa) e as ações (efeito) são analisadas. Após, as causas e efeitos serem levantados, são relacionados através da criação de um grafo. Os casos de teste são derivados a partir da conversão deste grafo em uma tabela de decisão. Testes Baseados em Modelos (TBM): faz uso de informações a respeito do aspecto funcional do sistema cuja representação é feita em um modelo. Tal modelo é baseado nos requisitos funcionais, especifica ações possíveis e as saídas que são esperadas. Para este trabalho, é utilizado para estudo o método de teste funcional: Teste Baseados em Modelos (TBM), abordado na seção 2.3. Estrutural A técnica de Teste Estrutural é também conhecida como caixa-branca, neste caso fundamentase na estrutura interna da implementação. Algumas questões são levantadas quando se perguntam pela necessidade de se testar os detalhes do sistema quando se poderia empregar um maior esforço na garantia de que todos os requisitos foram atendidos. Ou seja, por que gastar esforço em teste caixa-preta? Estas questões são respondidas na natureza dos defeitos do software (PRESMAN, 2002):

24 24 Erros de lógica. Alguns erros só são detectados quando o teste de caminhos se inicia. O caminho lógico pode ser considerado como não provável de ser executado sendo que ele pode ser executado em base regular. Erros de digitação podem ser detectados quando um programa é demonstrado em código-fonte ou em uma linguagem de programação. Os métodos de teste estrutural se baseiam em diferentes componentes e conceitos de programas para que se possam detectar os requisitos de teste. Testes baseados em modelos O comportamento e as características que um sistema deve possuir são representados através de uma especificação (modelo). Pode ser descrita textualmente em linguagem natural (exemplo: português) ou mais formalmente e complexa. Esta última só é útil se for possível, a partir dela, aumentar a compreensão do sistema juntamente com a possibilidade de analisá-la algoritmicamente (forma sistemática de verificar as propriedades da especificação) (SIMÃO, 2001). Uma especificação clara e precisa é parte importante no desenvolvimento do trabalho e no de teste. A atividade de teste, primeiramente busca identificar o que o sistema deveria fazer, ou seja, antes de qualquer ação deve-se saber qual seria o resultado correto para depois analisá-lo e verificar se está correto ou não. Nesta tarefa, um modelo é de grande valia, pois, se bem desenvolvido, apreende o que é essencial no sistema (DELAMARO, 2007). No entanto, para saber se o modelo está correto ele deve ser testado. Se for considerado correto, o modelo se torna peça importantíssima para o teste, pois, além de separar os comportamentos corretos e errôneos, gera scripts e cenários de teste (DELAMARO, 2007). A criação de modelos não é uma novidade no ambiente de testadores. Modelos sempre foram criados, ainda que informais, visto que sem um modelo não seria possível a visualização do

25 25 resultado, se ele foi aceitável ou não. O impasse é a decisão de qual formato de modelo utilizar. Um modelo informal, além de impedir a automatização dos testes, é de conhecimento apenas de um testador. Para gerar um plano e scripts de teste, o profissional deve ter conhecimento de uma sequência de ações necessárias para o uso do sistema (DELAMARO, 2007). Nas seções e 2.3.2, são abordados conceitos sobre diagrama de estados e Statecharts. Ambos são considerados representações de um determinado elemento. Diagrama de Estados MEF são grafos, compostas por estados e transições entre eles, causadas por eventos. Diagramas de estados são representações gráficas de MEF. Além disso, estes diagramas também especificam ações e atividades realizadas em resposta a eventos (FRANCÊS, 2001). Os estados podem ser representados no diagrama por círculos e as transições (mudanças de estado) por arcos direcionados. Os arcos representam o formato entrada e saída. A Figura 4 mostra um exemplo de MEF por meio de um diagrama de transição de estados. A MEF em exemplo aponta o comportamento de um extrator de comentários. As entradas são sequências composta por símbolos *, / e v, sendo v um caracter qualquer diferente de * e / e o comentário é uma sequência de caracteres iniciada por /* e finalizada por */.

26 26 Figura 4. MEF: diagrama de transição de estados Fonte: (DELAMARO et al, 2007) A Tabela 1 e a Tabela 2 mostram, respectivamente, a MEF da Figura 4 representada através de uma tabela de transição e as operações e ações aplicadas sobre ela. Tabela 1. MEF: tabela de transição de estados (DELAMARO et al, 2007) Entrada /Estado * / V * / V 1 Ignore Ignore Ignore empty-bf Ignore Ignore acc-bf acc-bf acc-bf acc-bf deacc-bf; print acc-bf Tabela 2. Operações da MEF na Figura 4 Fonte: (DELAMARO et al, 2007) Operação Ignore Ação nula Ação empty-bf Buffer := <> acc-bf deacc-bf Print Buffer := buffer concatenado com o caractere corrente Buffer := buffer com o caractere mais à direita truncado Imprime o conteúdo do buffer

27 27 Algumas propriedades que uma MEF pode satisfazer são (DELAMARO et al, 2007): Propriedade 1. Podem ser formalmente conhecidas por tuplas. M = (X, Z, S, S 0, f z, f s ), onde: X: conjunto finito não-vazio de símbolos de entrada; Z: conjunto finito de símbolos de saída; S: conjunto finito não-vazio de estados; S 0 : S é o estado inicial; f z : (S X) Z consiste na função de saída; f s : (S X) S consiste na função de próximo estado. Propriedade 2. Uma máquina de estado é considerada completamente especificada se trata todas as entradas em todos os estados. Se isso não ocorrer, ela é considerada parcialmente especificada, o que a torna inviável, pois o teste de conformidade é fraco; Propriedade 3. É conectada, se para cada par de estado existe caminho por transição; Propriedade 4. Se não existe estados equivalentes (possuem a mesma entrada e a mesma saída) a máquina é considerada (reduzida); Propriedade 5. É determinística 1 se possui uma única transição, para qualquer dado estado e para uma dada entrada. Caso contrário, é não-determinística. Classes modeladas pela máquina de estado são limitadas, já que o conjunto de estados que a máquina de estado atinge é finito, por isso é difícil se ter todas as questões do modelo. Para aumentar a capacidade de modelagem foram sugeridas extensões à MEF, como Statecharts e Estelle (DELAMARO et al, 2007). 1 Determinística: Uma MEF determinística determina o próximo estado baseada somente no estado atual e no próximo símbolo de entrada.

28 28 Statecharts Proposta por Harel em 1987, Statecharts é uma técnica de especificação formal para descrever o aspecto comportamental de sistemas reativos, através de Máquinas de Estados Finitos Estendidas (MEFEs). Essa técnica permite a descrição clara e realística, e, ao mesmo tempo formal da dinâmica dos sistemas reativos, de tal maneira que permite também uma simulação detalhada do sistema (MALDONADO, 1991). Statecharts é uma extensão do diagrama de estados, no entanto, a estes foram adicionadas algumas características peculiares (FRANCÊS, 2001). As características dessa técnica, além de a tornarem mais atrativa, a diferenciam das outras técnicas formais. São elas: i) modelo apresentado através de hierarquia de MEF, que torna o modelo mais claro, dando visibilidade a aspectos de concorrência; ii) broadcasting ou reação em cadeia, permite descrever a sincronização entre os componentes ortogonais do modelo; iii) ortogonalidade, que possibilita descrever o paralelismo entre componentes do modelo especificado; e iv) história, que permita a lembrança de estados que já foram visitados (MALDONADO, 1991). Statecharts são fundamentados nos seguintes elementos básicos: estados, eventos, condições, ações, expressões, variáveis, rótulos e transições (FRANCÊS, 2001). Estados são usados para descrever componentes de um sistema. Estados de um Statechart representam os valores das variáveis em determinado instante do sistema e dividem-se em dois grupos: básicos e nãobásicos. Básicos são os que não possuem subestados. Não-básicos são divididos em subestados e pode ser de dois tipos: OR ou AND (FRANCÊS, 2001). Se o estado é classificado com o tipo OR, o sistema estará sempre em um único subestado em um determinado instante. Já se for classificado do tipo AND, o estado estará em mais de um subestado. Eventos consistem na entidade que gera uma alteração no comportamento atual do sistema. Alguns eventos como true (condição) e false (condição) são proporcionados pelos Statecharts, que em sua notação são abreviados para tr (condição), fs (condição), respectivamente (FRANCÊS, 2001). Ações são elementos utilizados para representar os

29 29 efeitos do paralelismo em statecharts. Transições consistem na representação gráfica para ressaltar uma mudança de estado no sistema. Rótulos provêem algum significado adicional, no entanto são opcionais e podem ser acrescentados às setas. A Figura 5 ilustra um sistema modelado em Statecharts. O paralelismo é representado através do uso de linhas pontilhadas separando os componentes. Figura 5. Especificação em Statecharts de um sistema com duas máquinas e um reparador Fonte: (VIJAYKUMAR, 2006) Métodos de teste para MEF Os métodos 2 para geração de casos de teste são aplicados sobre uma MEF, e, para que sejam percorridas, representações em Statecharts são convertidas em MEF. Neste contexto, um caso de teste é uma sequência de símbolos de entrada derivada da MEF (CHOW, 1978). Existem alguns métodos para a geração de casos de teste a partir de MEF: 2 Na literatura, os métodos de geração de casos de teste também são chamados de critérios de teste, porém em todo contexto deste trabalho será usado o termo método.

30 30 Método TT (Transition Tour) Parte do início, atravessa todas as transições e volta ao início. Permite detectar erros de saída mas não erros que a transição leva a MEF a um estado diferente que deveria levar. Método W Permite a distinção de todos os estados e detecção de erros das estruturas. Método UIO (Unique input/output) Seqüência de identificação de estado. Não é garantido para as implementações com erro, já que uma entrada leva a uma saída na especificação correta. Método DS (Seqüência de distinção) Cada saída é diferente se a seqüência de entrada é aplicada a cada estado diferente. Os métodos Transition Tour, Switch Cover, UIO e DS podem ser considerados como exemplos de métodos de geração de casos de teste (ARANTES, 2008). Para o presente trabalho, serão abordados os métodos UIO e DS, apresentados nas seções e 2.4.3, respectivamente. Unique-Input-Output Sequence (UIO) O método de teste UIO deriva uma sequência única de entrada e saída (UIO) para cada estado de uma máquina. Um estado pode ser identificado conforme a observação da sequência de saída gerada por meio da sequência de entrada, visto que uma entrada possuirá somente uma única saída. Tal método só poderá ser aplicado em MEF determinísticas, completas, fortemente conectadas e mínimas (SOUZA, 2010). Para se gerar o conjunto de teste utilizando tal método são necessários dois passos. O primeiro passo é encontrar a sequência de entrada e saída únicas para cada estado da MEF e o segundo passo consiste em como o método encontra a β-sequence.

31 31 Primeiro Passo Para se encontrar a sequência de entrada e saída de cada estado de uma MEF deve-se partir de um estado s i da MEF. É realizada uma busca em largura a fim de detectar se a entrada e saída daquele estado são únicas em relação aos demais estados da MEF. Caso seja única a entrada e a saída a busca em largura é finalizada e têm-se, então, a sequência de entrada e saída para o estado si. Caso contrário, a busca é continuada para que as entradas e saídas sejam comparadas e verificadas se são únicas para cada estado da MEF. A Figura 6 mostra como a busca em largura acontece. A busca se inicia no estado 1 (um) a fim de encontrar a entrada e saída únicas para este estado em relação aos demais estados da MEF. É analisada a entrada e saída 1/0 e (do estado 1 para o 6 (seis)). Se não for uma sequência de entrada e saída únicas para o estado 1, analisa-se então, a entrada e saída 0/0 (do estado 1 para o estado 2 (dois)). Se não for encontrada a sequência de entrada e saída, a árvore é percorrida concatenando as transições visitadas, ou seja, 1/0 e 0/1, após 1/0 e 1/1. E assim por diante, até que a sequência de entrada e saída do estado 1 seja encontrada. A utilização da busca em largura no método UIO garante que as sequências de entrada e saída sejam as menores para cada estado. Utilizando a MEF mostrada na Figura 7, é possível encontrar a sequência de entrada e saída para cada estado da MEF, como pode ser observado na Tabela 3. Com isso as sequências de entrada e saída são únicas para cada estado dentro da MEF. Segundo Passo O segundo passo do método UIO consiste em encontrar a β-sequence 3 da MEF que é formada por uma subsequence, ou seja, a β-sequence é igual ao somatório de subsequences, e cada subsequence é um conjunto de entradas que parte de um estado inicial s i até um estado final s j de uma transição (s i, s j ). A β-sequence concatenada com a sequência de entrada e saída unica de um estado, origina a sequência de teste para aquele estado da MEF. Para fazer a junção das entradas e saídas 3 (SOUZA, 2010). Uma β-sequence é uma sequência de símbolos de entrada que leva a MEF a um estado s

32 32 únicas e da β-sequence, leva-se em consideração a qual estado a entrada e saída única pertence. Para saber em qual subsequence da β-sequence colocar a entrada e saída correspondente, deve-se considerar o estado de destino da transição que está sendo alcançado a partir do estado inicial. Figura 6. Representação da busca em largura do método UIO Fonte: (SOUZA, 2010) Tabela 3. Sequências entrada e saída de cada estado da MEF Fonte: (SIDHU e LEUNG, 1989) Estado Entrada e saída únicas 0 B/λ 1 A/1 A/1 2 B/0 3 B/1 B/1 4 A/1 A/0 Utilizando a MEF da Figura 7, foram geradas as sequências de entrada e saída como mostra a Tabela 4.

33 33 Figura 7. MEF para exemplo dos métodos Fonte: (SIDHU e LEUNG, 1989) Tabela 4. Entradas e saídas obtidas Fonte: (SIDHU e LEUNG, 1989) Estado Entrada e saída únicas 0 B 1 A A 2 B 3 B B 4 A A A Tabela 5 apresenta as subsequences da β-sequence com suas relativas entradas, saídas e as transições percorridas. Nesta mesma tabela, também podem ser observadas, através da coluna Transição (mudanças de caminhos), as transições que foram atingidas a fim de se gerar a sequence da β-sequence.

34 34 A primeira transição parte do estado 0 e vai para o estado 3. Neste caso, como o estado 3 é o estado destino, então deve ser concatenada à subsequence da β-sequence a entrada e saída do estado 3, que é B B (SOUZA, 2010). Tabela 5. Descrição do método UIO Fonte: (SOUZA, 2010) Subsequence da Subsequence + Transição β-sequence Entrada e Saída únicas A (0,3) A B B B (0,0) B B A A A A A (1,4) A A A A A A A A A A A B (1,2) A A A A B B A A A A (2,1) A A A A A A A A A B (2,3) A A A A B B B A A (3,4) A A A A A B (3,3) A B B B A A A (4,2) A A A B A A B (4,0) A A B B Fluxograma do método de teste UIO Na Figura 8 é exposto o fluxograma do método de teste UIO desde a interpretação da MEF em XML até a junção da subsequence com a entrada e saída única para cada estado da MEF.

35 35 Figura 8. Fluxograma do método de teste UIO Adaptado: (SOUZA, 2010) Distinguishing Sequence (DS) O método DS (GONENC, 1970) faz uso de uma sequência de distinção para geração dos casos de teste. Essa sequência distinta é uma sequência de símbolos de entrada que quando é aplicada como entrada ao estado da MEF, produz saídas distintas para cada um dos estados da MEF. Esse método possibilita, sabendo as saídas produzidas pela MEF como respostas à sequência de distinção, saber em qual estado a MEF estava originalmente. Com isso, além da existência da sequência de distinção, o método DS também pode somente ser aplicado em MEF determinísticas e completas, como o método UIO (SOUZA, 2010).

36 36 Nesse método, é relevante escolher a menor sequência de distinção para que se obtenha um conjunto menor de casos de teste. De acordo com Leung (1989), os testes são gerados através de dois passos. O primeiro passo consiste em encontrar a(s) sequência (s) de distinção e, caso exista, o segundo passo é localizar a β-sequence. Primeiro Passo: A sequência de distinção pode ser encontrada construindo-se, a partir da MEF, uma Árvore de Distinção (KOHAVI, 1978) que utiliza o conceito de grupos de incerteza. Estes grupos são grupos de estados que ainda não foram distinguidos e para os quais é necessário que alguma entrada seja apresentada à sequência para ela se tornar uma sequência de distinção. Essa árvore também contém grupos chamados triviais, ou seja, um grupo em que todos os conjuntos de estados são unitários ou vazios. Na Figura 9 mostra todos os exemplos de grupos existentes, e esta será usada como exemplo de implementação do método. Figura 9. Máquina de Estado Finito: Implementação do método DS Fonte: (DELAMARO et al., 2007) Segundo Passo O segundo passo consiste em construir uma β-sequence, como no método UIO. A Tabela 6 apresenta a descrição do método DS. Pode-se observar a subsequence concatenada com a sequência de distinção. Aplicando-se a menor sequência de distinção encontrada em cada subsequence da β-sequence, têm-se os seguintes casos de teste: ABB, BBB,

37 37 AAAAABB, AAAABBB, AAAABB, AAAABBB, AABB, ABBB, AAABB e AABBB (SOUZA, 2010). Tabela 6. Descrição do método DS Fonte: (SOUZA, 2010) Subsequence da β- Subsequence + Sequência Transição sequence Distinta A (0,3) A B B B (0,0) B B B A A A A A (1,4) A A A A A B B A A A A B (1,2) A A A A B B B A A A A (2,1) A A A A B B A A A B (2,3) A A A A B B B A A (3,4) A A B B A B (3,3) A B B B A A A (4,2) A A A B B A A B (4,0) A A B B B Tabela 7. Saídas obtidas a partir de cada estado quando se aplica a sequência DS Fonte: (SIDHU e LEUNG, 1989) Estado Entrada e saída únicas 0 λ λ λ

38 38 Fluxograma do método de teste DS O Fluxograma da Figura 10 apresenta o funcionamento do algoritmo implementado para o método DS desde a leitura da MEF, escrita em XML, até a concatenação da subsequence com a sequência de distinção. Observa-se que certas MEF podem não possuir sequência de distinção. Figura 10. Fluxograma do método de teste DS Adaptado: (SOUZA, 2010)

39 39 Ferramentas de teste de software Organizações de pesquisa espacial, como o INPE, desenvolve software embarcado em aplicações espaciais, consideradas complexas e críticas. Tais sistemas também podem ser considerados sistemas reativos, ou seja, respondem a estímulos a partir de seus dispositivos. Estas aplicações espaciais são não-tripuladas, logo, se ocorre alguma falha fica difícil a substituição do software acoplado em tais aplicações. Para isso, é importante que se faça a validação e verificação do software durante todo seu ciclo de vida (SANTIAGO et al, 2006). A fim de agilizar e otimizar os processos de testes, foram desenvolvidas ferramentas para a geração de casos de teste de forma automatizada. Alguns exemplos são a Condado (MARTINS et al.,1999), Performcharts (VIJAYKUMAR et al, 2002), a Geração de Casos de Teste para Sistemas Especificados em Statecharts (GTSC) (AMARAL, 2007) e a Web- PerformCharts (ARANTES, 2008). O INPE atualmente tem projetos sendo desenvolvidos em paralelos com três delas: a Performcharts, GTSC e a Web-PerformCharts. A Performcharts foi desenvolvida para realizar a conversão de uma representação em Statecharts, escrita em linguagem PCML (Performcharts Marckup Language) (AMARAL et al, 2004a) e (AMARAL et al, 2004b), em uma MEF, escrita em linguagem XML. Porém, não era possível fazer a geração de casos de teste utilizando apenas a Performcharts, para isso era necessário integrá-la à Condado, que é outra ferramenta independente capaz de gerar os casos de teste. Isto implicava em um processo demorado, pois obrigava o testador à gerar a MEF, convertê-la para a linguagem da Condado, e só então obter os casos de teste pela execução da mesma (ARANTES, 2008). A ferramenta de teste GTSC admite a geração de casos de teste a partir de uma especificação em Statecharts e modelos em MEF. Isto é possível, pois a MEF é obtida através de um arquivo em PCML em conjunto com a ferramenta Performcharts, incorporada à GTSC (ARANTES, 2008). Tais ferramentas foram desenvolvidas para o acesso local. Então, surgiu a necessidade de uma ferramenta que possibilitasse o acesso remoto para a criação de casos de teste. Foi criada

40 40 então a Web-PerformCharts, desenvolvida para proporcionar a geração de casos de teste através da Internet utilizando como base as especificações em Statecharts. A Web- PerformCharts é uma adaptação da ferramenta PerformCharts. Pode-se perceber a presença da Performcharts na Web-PerformCharts no momento em que o arquivo PCML é convertido em MEF, através de uma opção Run PerformCharts, contida na ferramenta. Foram escolhidos dois métodos para serem incorporados na Web-PerformCharts: Transition Tour e Switch Cover. Porém, é possível adicionar outros métodos na Web-PerformCharts, desde que esse método seja aplicado em uma representação MEF. Web-PerformCharts A Web-PerformCharts é a ferramenta de teste abordada no escopo deste trabalho. Na seção é apresentada a arquitetura, algumas características e funcionamento da ferramenta utilizada para a geração automatizada de casos de teste. Arquitetura A ferramenta PerformCharts foi modificada para ser hospedada em um servidor web utilizando um banco de dados e também para ser executada através de uma interface web. Com esta base de dados on-line, onde os casos de testes são armazenados, é possível salvar e carregar projetos de qualquer local para o servidor ao invés de manipular arquivos locais, que podem estar espalhados em vários computadores. O testador, uma vez logado no sistema, tem a capacidade de criar, editar ou excluir projetos e suas especificações PCML. O bom desempenho da ferramenta está diretamente ligado à

41 41 capacidade do servidor para suportar a carga de trabalho on-line bem como a memória de armazenamento (ARANTES, 2008). A Web-PerformCharts tem dois níveis de acesso para os usuários: Administrador: possui acesso a qualquer projeto, e pode criar contas de usuários; Usuário: que possui acesso somente aos projetos criados por ele. A ferramenta realiza o upload de um arquivo PCML ao servidor web. Então, o conteúdo deste arquivo é salvo em um banco de dados MySQL. Com isso, o usuário tem a opção de escolha entre os métodos Switch Cover e Transition Tour para que sejam gerados os casos de teste. A ferramenta é aberta para a execução de qualquer método que percorra uma MEF. A Figura 11 demonstra como a Web-PerformCharts gera os casos de teste e indica com o caminho Path A, a geração de casos de teste utilizando um dos métodos implementados. O caminho indicado como Path B demonstra a integração com o método Switch Cover da ferramenta Condado (ARANTES, 2008).

42 42 Figura 11. Arquitetura da ferramenta Web-PerformCharts Fonte: (ARANTES, 2008) Está no escopo deste trabalho a investigação da ferramenta Web-PerformCharts para a integração dos métodos UIO e DS, fazendo-os manipular dados da MEF armazenados em um banco de dados, sem perda de informações. Trabalhos relacionados O presente trabalho relaciona-se com alguns temas já desenvolvidos. Alguns deles são listados abaixo: Formal Methods for Protocol Testing: A Detailed Study (SIDHU, 1989)

43 43 Este artigo discute quatro métodos formais (TT, DS, UIO, W) para a geração de seqüências de teste a partir de sua especificação. Validação de Especificações de Sistemas Reativos: Definição e Análise de Critérios de Teste (SOUZA, 2000) Neste trabalho, foi apresentada a definição de métodos para o teste de especificações de sistemas reativos, descritos em Estelle e em Statecharts. Essa definição baseou-se em métodos de Fluxo de Controle e no Teste de Mutação (FABBRI et al.,1994), originalmente definidos para o teste de software. Geração de Casos de Teste para Sistemas Especificados em Statecharts (AMARAL, 2007) Amaral aborda sobre uma metodologia para geração de casos de teste para um sistema reativo especificado em Statecharts, de forma automática. Este trabalho visou permitir aos usuários da ferramenta de teste PerformCharts especificar o sistema através da linguagem de marcação baseada em XML ao invés da criação do programa em linguagem de programação C++. Web-PerformCharts: A Web-Based Test Case Generator From Statecharts Modeling (ARANTES, 2008) Neste artigo Arantes apresenta a idéia de se reduzir custos permitindo a descentralização de informações e de pessoas e a mobilidade através de uma ferramenta web. Com base nisso, foi idealizada a ferramenta Web-PerformCharts que tem o intuito utilizar banco de dados online como método de armazenamento que permite partilhar projetos desde a sua gestão. Avaliação de Custo e Eficiência de Critérios de Teste para Máquinas de Estados Finitos: Área Espacial (FERREIRA et al, 2008) Neste artigo, Ferreira mostra uma avaliação da relação custo e eficiência de alguns métodos de teste para MEFs. Os resultados obtidos levam em conta as características do software usado e do ambiente de teste proposto.

44 44 INTEGRAÇÃO DOS MÉTODOS DE TESTE À FERRAMENTA WEB- PERFORMCHARTS O capítulo 3 tem como objetivo apresentar como ocorreu a adaptação dos métodos UIO e DS e da ferramenta Web-PerformCharts para a realização da integração entre os mesmos. O capítulo está organizado da seguinte maneira: A seção 3.1 aborda sobre a ferramenta WEB- PerformCharts e divide-se nas seções e 3.1.2, as quais mostram respectivamente, as atualizações realizadas na interface da Web-PerformCharts e a metodologia anterior e atual da ferramenta. A seção 3.2 descreve a adaptação dos métodos DS e UIO e divide-se nas seções 3.2.1, 3.2.2, e as quais descrevem respectivamente a metodologia anterior, a metodologia atual, os resultados obtidos e a modelagem utilizada para realizar tal adaptação. A seção 3.3 mostra o fluxograma que apresenta uma visão geral de como ocorre o fluxo de execuções para geração de casos de teste. Ferramenta Web-PerformCharts Algumas adaptações ainda estão em andamento, no entanto, a URL para acessar a ferramenta é basta o usuário ter uma conta para poder acessar os recursos oferecidos pelo ambiente da Web-PerformCharts. As alterações realizadas até o presente momento estão sendo carregadas para o servidor original que hospeda a ferramenta.

45 45 Interface gráfica Foram realizadas alterações na interface da ferramenta como mostram as figuras a seguir: Figura 12. Tela de login antiga da ferramenta Web-PerformCharts Figura 13. Tela de login atual da ferramenta Web-PerformCharts