UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FERRAMENTA CASE PARA AUTOMATIZAR A CRIAÇÃO DE TESTES DE UNIDADE Área de Engenharia de Software por Antonio Carlos Silva Fabiane Barreto Vavassori Benitti, Dra Orientadora Itajaí (SC), novembro de 2007

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FERRAMENTA CASE PARA AUTOMATIZAR A CRIAÇÃO DE TESTES DE UNIDADE Área de Engenharia de Software por Antonio Carlos Silva Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Fabiane Barreto Vavassori Benitti, Dra. Itajaí (SC), novembro de 2007

3 DEDICATÓRIA Dedico todos os meus esforços a meus pais, Orlando Geroncio Silva e Telma Regina Silva, aos meus irmãos, Camila Cristina Silva e Orlando Geroncio Silva Junior e a minha namorada Roberta Aracy Melo. ii

4 AGRADECIMENTOS Agradeço aos meus pais pelo apoio não apenas durante a graduação, mas por toda minha vida. Aos meus irmãos que souberam me compreender mesmo em momentos de maior tensão. Agradeço a minha namorada, por toda paciência, força e atenção e por compreender a minha ausência durante o desenvolvimento deste projeto. Agradeço a todos os professores do curso de Ciência da Computação que contribuíram de forma direta ou indireta para alcançar este objetivo. Agradeço em especial a minha orientadora a professora Fabiane Barreto Vavassori Benitti e a professores como André Luis Alice Raabe, Cesar Albenes Zeferino entre outros, que marcaram de forma especial minha vida acadêmica nesta instituição. Agradeço aos colegas de graduação, pelos momentos de descontração e ajuda nos estudos. Agradeço ainda em especial ao colega Elieser Ademir de Jesus, por suas contribuições e desafios propostos, alguns dos quais enfrentados em conjunto. A todos estes, deixo meu agradecimento por terem ajudado a concluir mais esta etapa em minha vida. iii

5 SUMÁRIO LISTA DE ABREVIATURAS... vi LISTA DE FIGURAS... vii RESUMO... ix ABSTRACT...x 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA TESTE DE SOFTWARE O processo de teste de software Teste de Unidade FERRAMENTAS CASE Automatização de testes Integração entre ferramentas CASE utilizando XMI GERAÇÃO DE CÓDIGO Ferramenta Velocity FERRAMENTAS PARA TESTE DE SOFTWARE JUnit Objecteering UML CodePro AnalytiX PROJETO REQUISITOS Requisitos funcionais Requisitos não funcionais Regras de negócio CASOS DE USO DIAGRAMA DE CLASSES XML SCHEMA PADRÕES DE PROJETO UTILIZADOS DESENVOLVIMENTO TÉCNICA DE DESENVOLVIMENTO TDD iv

6 4.2 IMPLEMENTAÇÃO DA FERRAMENTA Implementação do analisador de arquivos no padrão XMI Implementação da definição dos casos de teste Implementação da validação dos casos de teste Implementação do gerador de código fonte para os casos de teste FERRAMENTA UNITCASE Funcionamento da ferramenta Demonstração da ferramenta CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS...81 APÊNDICE A DETALHAMENTO DOS CASOS DE USO...85 A.1 UC01 CRIAR PROJETO A.2 UC02 ABRIR PROJETO A.3 UC03 SALVAR PROJETO A.4 UC04 FECHAR PROJETO A.5 UC05 CRIAR CASO DE TESTE A.6 UC06 DEFINIR O SETUP A.7 UC07 CRIAR STUB A.8 UC08 VALIDAR CASO DE TESTE A.9 UC09 GERAR CÓDIGO FONTE APÊNDICE B DETALHAMENTO DAS CLASSES DO MODELO DE DOMÍNIO...96 B.1 CLASSES DO PACOTE MODELO B.2 CLASSES DO PACOTE CASODETESTE APÊNDICE C XML SCHEMA PARA A FERRAMENTA...98 APÊNDICE D XMI UTILIZADO NA DEMONSTRAÇÃO DA FERRAMENTA v

7 LISTA DE ABREVIATURAS CASE DTD DVSL GEF GUI IDE JFC MDA MOF MVC OMG RF RN RNF SGML TCC TDD UC UML UNIVALI VTL W3C XMI XML XP XSLT Computer Aided Software Engineering Document Type Definition Declarative Velocity Style Language Graphical Editing Framework Graphical User Interface Integrated Development Environment Java Foundation Classes Model Driven Architecture Meta Object Facility Model View Control Object Management Group Requisito Funcional Regra de Negocio Requisito Não Funcional Standardized Generalized Markup Language Trabalho de Conclusão de Curso Test Driven Development Use Case Unified Modeling Language Universidade do Vale do Itajaí Velocity Template Language World Wide Web Consortium XML Metadata Interchange Extensible Markup Language Extreme Programming Extensible Stylesheet Language Transformation vi

8 LISTA DE FIGURAS Figura 1. Processo de teste para detecção de defeitos... 9 Figura 2. Etapas de teste Figura 3. Visão de teste de caixa branca Figura 4. Visão de teste de caixa preta Figura 5. Elementos básicos para uma instância de um documento XMI Figura 6. XML Schema com a definição para o elemento XMI Figura 7. Documento instância XMI contendo informações sobre uma classe Figura 8. Diagrama de Classes exemplo Figura 9. Documento instância XMI exemplificando a tradução das associações entre classes Figura 10. Geração de código baseada em templates Figura 11. Arquitetura da ferramenta Velocity Figura 12. Exemplo de uso da ferramenta Velocity Figura 13. Arquivo de templates HelloWorld.vm Figura 14. Arquivo de exemplo VelocityTest.java Figura 15. Saída gerada para o template HelloWorld.vm Figura 16. Pacote de Classes do framework JUnit Figura 17. Classe com o caso de teste para execução com o framework JUnit Figura 18. Execução do caso de um caso de teste utilizando a ferramenta Eclipse Figura 19. Classe execução com o framework JUnit utilizando o 38 Figura 20. Ferramenta Objecteering UML Figura 21. Caso de teste utilizando a ferramenta Objecteering UML Figura 22. Interface padrão do módulo JUnit Test Generation da ferramenta CodePro AnalytiX Figura 23. Casos de uso para a ferramenta proposta Figura 24. Diagrama de classes para o pacote modelo da ferramenta proposta Figura 25. Diagrama de classe para o pacote casodeteste para a ferramenta proposta Figura 26. Estrutura do elemento raiz unitcase Figura 27. Estrutura do elemento Projeto Figura 28. Estrutura do elemento Classe Figura 29. Estrutura do elemento Gerenciador Figura 30. Estrutura do elemento Stub Figura 31. Estrutura do elemento Método Figura 32. Estrutura do elemento SetUp Figura 33. Modelo para exemplificar o uso do padrão Composite Figura 34. Modelo para demonstrar o padrão visitor Figura 35. Classe Projeto que exemplifica o uso do padrão Singleton Figura 36. Método para geração de código da classe Gerador Figura 37. Template em linguagem VTL para geração de código fonte em Java Figura 38. Diagrama de atividades para a ferramenta proposta Figura 39. Diagrama de seqüência utilizado para definição dos casos de teste na ferramenta Figura 40. Diagrama de classes para construção do estudo de caso Figura 41. Código fonte para a classe Produto Figura 42. Código fonte para a classe CarrinhoDeCompras Figura 43. Interface para definir as informações do projeto Figura 44. Interface para definição dos objetos do SetUp Figura 45. Opção para criar um novo caso de teste Figura 46. Interface para criação de um novo caso de teste vii

9 Figura 47. Interface para definição e visualização do caso de teste Figura 48. Interface para criação de um novo Stub Figura 49. Barra de ferramentas utilizada na definição do diagrama de seqüência Figura 50. Interface para adicionar um Stub ao caso de teste Figura 51. Interface para definição da mensagem Figura 52. Interface para adicionar um Objeto ao caso de teste Figura 53. Caso de teste testadicionaproduto Figura 54. Interface para validação dos casos de teste Figura 55. Interface para geração de código fonte Figura 56. Código gerado pela ferramenta para o caso de teste Figura 57. Execução do caso de teste utilizando o framework JUnit Figura 58. XML Schema para a ferramenta proposta Figura 59. XMI utilizado na demonstração da ferramenta viii

10 RESUMO SILVA, Antonio Carlos. Ferramenta CASE para automatizar a criação de testes de unidade. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A engenharia de software tem por objetivo fornecer ao engenheiro de software a base necessária para a construção de sistemas de alta qualidade e de modo produtivo. O teste de software compreendido pela engenharia de software tem como foco garantir esta qualidade dos sistemas, fornecendo métodos e técnicas a fim de detectar erros comumente presentes nos softwares. O processo de desenvolvimento de software deve abranger uma etapa para aplicação dos testes, um dos testes iniciais aplicados ao sistema é o teste de unidade, que acontece antes mesmo da total codificação do sistema. O teste de unidade muitas vezes é desenvolvido e aplicado pelo programador, o que acaba por aumentar ainda mais a carga de trabalho deste profissional. Para auxiliar nesta fase dos testes, inúmeras ferramentas visam automatizar uma série de processos, como por exemplo, o framework JUnit que fornece além de uma biblioteca para criação de casos de teste um ambiente para execução dos testes de unidade de forma automatizada. Mesmo utilizando o framework JUnit a criação dos casos de teste é feita através de implementação em código fonte, o que acaba por justificar a necessidade do próprio desenvolvedor criar os casos de teste para os testes de unidade. Assim, a proposta para este trabalho de conclusão é o desenvolvimento de uma ferramenta CASE (Computer Aided Software Engineering, Engenharia de Software Auxiliada por Computador) para auxiliar na fase de teste de unidade, permitindo a criação de casos de teste sem que o usuário tenha de implementá-los em código fonte, mais sim de forma visual por meio de mensagens entre os objetos do seu modelo de classes no padrão XMI. Palavras-chave: Engenharia de Software. Teste de Software. Teste de Unidade. ix

11 ABSTRACT The software engineering has as objective to provide to the software engineer the necessary base for the construction of systems of high quality and productive way. The test of software understood by the software engineering has as focus to guarantee this quality of the systems, supplying methods and techniques in order to detect errors usually present in software. The process of software development must include a stage for application of the tests, one of the applied initial tests to the system is the unit test, that happens before exactly of the total codification of the system. A lot of times the unit test is developed and applied by the developer, that finishes increasing still more the load of work of this professional. For aiding in this phase of the tests, innumerable tools aim at automatizing a series of processes, such as, JUnit framework that supplies besides a library for creation of test cases, an environment for the execution of the unit tests of automatized form. Although using JUnit framework the creation of the test cases is made through implementation in source code, that finishes justifying the necessity of proper developer creates the test cases for the unit tests. Thus, the proposal for this conclusion work is the development of a CASE tool (Computer Aided Software Engineering, Software Engineering aided by computer) to aid in the phase of unit test, allowing the creation of test cases without the user has to implement them in source code, but of a visual form by messages among the objects of its model of classes in XMI standard. Keywords: Software Engineering. Test of Software. Unit Test. x

12 1 INTRODUÇÃO O software está presente em praticamente todas as áreas, cumprindo com seu papel em tornar a vida mais confortável, eficiente e efetiva, em muitos momentos, explicitamente ou sem se fazer notar (PFLEEGER, 2004). A engenharia de software é um dos campos da ciência da computação que tem como foco a construção de sistemas computacionais tão grandes e/ou tão complexos que são construídos por uma equipe de desenvolvedores e uma equipe de engenheiros (GHEZZI e JAZAYERI, 1991). A engenharia de software, segundo Inthurn (2001), fornece ao engenheiro as bases para construção de sistemas computacionais de alta qualidade e de modo produtivo, definindo ainda a engenharia de software como uma disciplina para o desenvolvimento de sistemas, englobando três elementos: métodos, ferramentas e procedimentos. Assim um processo de desenvolvimento totalmente efetivo deve considerar as relações entre estes elementos, abrangendo ainda todo o ciclo de vida de um software, sendo este ciclo de vida divido em: estudo inicial, análise, projeto, implementação, teste, documentação, instalação (implantação) e manutenção. Dentre todas as etapas do ciclo de vida de um software, a etapa de teste está focada em garantir a qualidade do software em desenvolvimento, sendo definido por Hetzel (1987) como: o processo de executar um programa ou sistema com a finalidade de encontrar erros. Teste é a medida de qualidade do software. A etapa de teste visa encontrar defeitos comumente presentes num projeto de software e são muitos os fatores que levam a existência desses defeitos, um grande número de requisitos, a complexidade dos algoritmos e soluções propostas, o tamanho do projeto de software, bem como o número de pessoas envolvidas no seu desenvolvimento. Estas falhas podem ser identificadas e corrigidas em diversos momentos durante o projeto de desenvolvimento de um software (PFLEEGER, 2004). Assim a etapa de testes interage diretamente com outras etapas dentro do projeto de desenvolvimento de um software, para cada uma destas interações são definidos diferentes requisitos para a execução, para compreender estes requisitos os testes estão divididos em: teste de unidade, teste de integração, teste funcional, teste de desempenho, teste de aceitação e teste de instalação (PFLEEGER, 2004).

13 O teste de unidade, conhecido também por teste de componente ou teste de módulo, é definido por Thomas et al. (2004), como um teste projetado para verificar uma única unidade de software de forma isolada das demais unidades. Em projetos orientados a objetos, uma unidade de implementação é uma classe ou um método de uma classe. Para os testes de unidade existem duas abordagens mais comuns, a abordagem tradicional citada por Macgregor e Sykes (2001), Paula Filho (2003) e Pfleeger (2004), onde a criação e execução dos testes de unidades são de responsabilidade do programador, fazendo parte do fluxo de implementação. A segunda abordagem para o teste de unidade conhecida por TDD (Test Driven Development), proposta por Beck (2002), tem como foco o planejamento dos testes de unidade, onde estes são modelados e mesmo gerados durante a fase de análise, apenas a execução dos testes ocorre durante implementação. Existem diversas ferramentas CASE (Computer-Aided Software Engineering, Engenharia de Software auxiliada por computador) que suportam o TDD ou a abordagem tradicional. Estas abordagens diferem principalmente no uso de ferramentas para geração de casos de teste, como o CodePro AnalytiX (INSTATION, 2007), por exemplo, que auxilia principalmente na técnica mais tradicional, fazendo a leitura do código fonte do software para automatizar a geração dos casos de teste. Já para a técnica proposta por Beck (2002), existem ferramentas como o Objecteering (OBJECTEERING, 2007), em que os casos de testes são gerados com base em diagramas durante a fase de análise, sem a necessidade de código implementado. A execução dos testes em geral ocorre utilizando um software em comum para as duas abordagens, como por exemplo, o JUnit (JUNIT, 2007), responsável por automatizar execução dos testes de unidade escritos na linguagem Java. Assim, diversas ferramentas para criação dos testes de unidade se baseiam apenas em uma das técnicas, considerando que uma das principais diferenças entre as ferramentas está na entrada dos dados, pois a criação dos testes ocorre de forma semelhante, através de uma interface gráfica onde o usuário da ferramenta tem pouco ou quase nenhum contato com a linguagem em que o código final será gerado. Dados estes fatores, este trabalho tem como proposta o desenvolvimento de uma ferramenta CASE para geração dos testes de unidade, a fim de apoiar ambas as abordagens. O principal objetivo da ferramenta é possibilitar a criação dos testes de unidade tendo como base 2

14 um diagrama de classes no formato XMI 1. Desta forma, o usuário poderá, após a criação dos testes, auxiliado pela ferramenta, gerar o código dos casos de testes para que este seja então executado por uma ferramenta externa, como o JUnit (JUNIT, 2007), por exemplo. O principal objetivo da ferramenta proposta é possibilitar além de um ganho de produtividade para as equipes que realizam os testes de unidade, a possibilidade de arquivar estes testes junto ao projeto de forma que possa ser utilizado ou verificado posteriormente. 1.1 PROBLEMATIZAÇÃO Formulação do Problema Obter uma melhor qualidade em um produto de software não é apenas um aspecto desejado e sim essencial, tendo em vista o custo ao qual uma falha em um software pode causar ao cliente e a empresa responsável pelo seu desenvolvimento. Dado este fator, não são poucos os esforços em manter um processo de desenvolvimento que possa minimizar estas falhas, identificando-as o quanto antes para que possam ser verificadas e eliminadas. Para colaborar com este objetivo, o teste de software deve estar presente em todo o processo de desenvolvimento, pois este é um dos responsáveis por garantir a qualidade do software em desenvolvimento, baseando-se principalmente na simulação de inúmeras tarefas as quais o software deverá apoiar baseado em suas funcionalidades. Este processo, mesmo que bem formalizado e parametrizado, acaba por tornar-se custoso, dada as inúmeras possibilidades que um software pode apresentar. O teste de unidade, considerado como uma das etapas iniciais do teste de software, em alguns processos de software iniciando antes mesmo da fase de desenvolvimento, este é apontado em muitos processos, como uma responsabilidade do programador. Por conseqüência, pode acabar por sobrecarregar as atividades já desempenhadas por este, levando-o ainda a omitir-se na criação de casos de teste mais complexos, aumentando assim a chance de uma falha não ser detectada antes que o produto chegue ao cliente (BECK, 2002). 1 XMI (XML Metadata Interchange) é o padrão estabelecido pela OMG (Object Management Group) para troca de metadados utilizando XML (Extensible Markup Language). O padrão XMI permite a troca de metadados entre as ferramentas de modelagem que o implementam (OMG, 2007). 3

15 1.1.2 Solução Proposta Este projeto tem como proposta o desenvolvimento de uma ferramenta CASE que permita auxiliar na criação dos casos de teste para os testes de unidade, possibilitando ainda que estes possam ser gerados sem a necessidade de contato direto com a linguagem fonte ao qual o software foi originalmente desenvolvido. Com o auxílio da ferramenta proposta, os casos de teste passam a ser concebidos de forma visual, utilizando para isto o diagrama de seqüência definido pela UML, assim a tarefa aproxima-se em muito do papel já desempenhado pelo analista que utiliza outras ferramentas baseadas em modelos UML. A ferramenta tem por objetivo, permitir a criação de um projeto de casos de teste para um determinado modelo, para isso o usuário deve seguir os seguintes passos: 1. Importação do modelo: este passo se dá informando o local onde está contido o arquivo contendo os dados do modelo no padrão XMI; 2. Definição dos casos de teste: nesta etapa por meio de diagramas de seqüência o usuário define os casos de uso para o modelo importado; 3. Geração do código fonte: por fim o usuário tem a opção de gerar o código fonte para os casos de teste do modelo, possibilitando sua execução pelo framework JUnit. 1.2 OBJETIVOS Objetivo Geral O objetivo geral deste projeto é desenvolver uma ferramenta CASE para automatizar o planejamento e geração dos testes de unidade Objetivos Específicos Pesquisar conceitos relativos a teste de software com ênfase em teste de unidade; Pesquisar e analisar soluções similares para planejamento e geração dos testes de unidade; Especificar os requisitos do sistema; 4

16 Realizar a modelagem e especificação do sistema; Implementar o sistema: o Implementar um reconhecedor para o padrão XMI; o Permitir a configuração e planejamento dos testes de unidade; o Permitir a geração de código Java para os testes de unidade; Testar o sistema; e Documentar o desenvolvimento do sistema. 1.3 Metodologia A metodologia utilizada para o desenvolvimento deste projeto teve como base as etapas: 1. Estudo: esta etapa teve como objetivo, além do estudo dos conceitos envolvidos no processo de teste de software, a ampliação dos conhecimentos nas tecnologias necessárias para o desenvolvimento do projeto e a pesquisa de soluções similares já existentes; 2. Especificação: nesta etapa foram realizadas as atividades com o objetivo especificar e projetar a ferramenta a desenvolvida e para atingir este objetivo foram utilizados alguns dos diagramas da UML que serviram como base para a implementação; 3. Desenvolvimento: as atividades de implementação da ferramenta proposta neste trabalho foram divididas em: o Implementação do analisador de arquivos no padrão XMI; o Implementação da criação dos casos testes; e o Implementação da geração de código fonte. 4. Avaliação: para avaliação da ferramenta foi desenvolvido um projeto contendo seu respectivo diagrama de classes e código fonte Java, o qual foi utilizado como base para as atividades de avaliação da ferramenta; e 5. Documentação: esta etapa teve como objetivo a documentação do projeto desenvolvido, tendo como base o material produzido durante a implementação e avaliação do projeto. 5

17 1.4 Estrutura do trabalho Este trabalho é apresentado em quatro capítulos: introdução, fundamentação teórica, projeto e considerações finais. No primeiro capítulo é apresentada uma introdução aos conceitos envolvidos a este trabalho, onde é identificada a necessidade de uma ferramenta ao qual propõe-se desenvolver, inclusive citando brevemente algumas das soluções similares já existentes, e em seguida são apresentados os objetivos aos quais a solução proposta deve compreender. O capítulo 2 tem por objetivo apresentar os conceitos envolvidos de forma mais abrangente, tratando especificamente dos temas: Teste de software; Ferramentas CASE; Geração de código; e Ferramentas para teste de software. Neste capítulo são citados inúmeros autores e materiais disponíveis para permitir um maior embasamento para a concepção da ferramenta proposta. No capítulo seguinte, a fundamentação teórica apresenta o desenvolvimento do projeto, onde são elencados os requisitos funcionais, requisitos não funcionais e regras de negócio, identificados a partir do estudo realizado. Em seguida, são apresentados os casos de uso e os protótipos da interface do sistema, seguido de um exemplo de criação de um projeto de teste de unidade da forma como deseja-se que a ferramenta permita ao usuário esta criação. Neste capítulo consta ainda o diagrama de classes, onde contém os principais atributos e relacionamentos das classes de negócio, e ao fim deste, é apresentado o XML Schema que define o modelo de persistência, o qual será em XML. O capítulo quatro descreve o desenvolvimento da ferramenta, destacando as etapas envolvidas em sua implementação. Neste capítulo é apresentada ainda uma demonstração do uso da ferramenta implementada, seguindo um passo a passo orientado a descrever as suas principais funcionalidades. O último capítulo apresenta as conclusões deste projeto, em que são abordados os objetivos deste trabalho, as dificuldades encontradas em seu desenvolvimento e as soluções encontradas. Ainda neste capítulo são abordadas as possíveis melhorias e expansões para a ferramenta desenvolvida, com intuito de direcionar os esforços na possível continuidade deste projeto. 6

18 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentados os principais conceitos necessários a implementação da solução proposta, que englobam: teste de software, ferramentas CASE, geração de código e ferramentas para teste de software. Na seção 2.1 é descrito o processo de teste de software, a organização dos testes e os tipos de testes com ênfase no teste de unidade. A seção seguinte, 2.2, apresenta os conceitos referentes a ferramentas CASE com ênfase em ferramentas para automatização de testes e a integração entre ferramentas utilizando o padrão XMI. A geração de código é abordada na seção 2.3, incluindo a descrição dos principais recursos da ferramenta Velocity, à qual será utilizada no desenvolvimento da solução proposta para implementação do gerador de código Java. Já a seção final deste capítulo apresenta três ferramentas que fornecem suporte para o processo de teste de software, onde inicialmente é apresentado o framework JUnit, o qual será responsável pela execução dos casos de teste gerados pela ferramenta proposta, e por fim outras duas ferramentas já presentes no mercado e analisadas como soluções similares a proposta. 2.1 TESTE DE SOFTWARE O teste de software é uma das etapas no ciclo de desenvolvimento de software que tem como principal objetivo encontrar os erros presentes em um software. Esta etapa é compreendida por sistemáticas aplicações de testes ao longo de todo o processo de desenvolvimento (MCGREGOR e SYKES, 2001). A etapa de testes é definida por Hetzel (1987) como: o processo de executar um programa ou sistema com a finalidade de encontrar erros. Teste é a medida de qualidade do software, uma definição que estabelece uma meta importante, encontrar erros, assim um teste bem sucedido é aquele que revela um erro ainda não descoberto (INTHURN, 2001). Apesar da intensa busca por um software isento de defeitos, as técnicas aplicadas para garantia da qualidade em sua grande maioria podem apenas melhorar a confiança no produto. Assim, mesmo após a correção de todos os defeitos que provocaram as falhas encontradas durante os testes, novos casos de teste poderiam apontar novos erros, ainda não identificados. Dado este fato, a execução dos testes de forma planejada e ordenada tem por objetivo cobrir o maior número de situações possíveis para evitar defeitos comuns ou mesmo defeitos em processos mais críticos (INTHURN, 2001).

19 A definição dos casos de teste é de responsabilidade da equipe de teste, e segundo Pfleeger (2004), a equipe de testes deve ser capaz de escolher dados de teste representativos, para mostrar que todas as combinações possíveis são tratadas apropriadamente O processo de teste de software O processo de teste proposto por Hetzel (1987), e também referenciado por Macgregor e Sykes (2001), aponta apenas três atividades, identificadas como: Análise: o produto a ser testado é analisado com o intuito de identificar características especiais que devem receber uma maior atenção na construção dos casos de teste; Construção: além da definição dos casos de teste, todos os artefatos necessários para a execução dos casos de teste são preparados e implementados, caso seja necessário; e Execução e Avaliação: os casos de teste definidos anteriormente são executados e seus resultados são avaliados, a fim de determinar se o resultado obtido foi exatamente o esperado, identificando as possíveis falhas do software. Outro modelo para o processo de testes é proposto por Sommerville (2003), também proposto por Maldonado e Fabbri (2001), que diferentemente do processo apresentado anteriormente este é composto por quatro atividades e não três, sendo estas: projeto de casos de teste, preparação dos dados de teste, execução dos casos de teste e comparação do resultado esperado com o resultado obtido durante a execução dos casos de teste. Estas atividades ocorrem ainda de forma seqüencial, dada a dependência de uma atividade com a outra, conforme apresentado na Figura 1. 8

20 Figura 1. Processo de teste para detecção de defeitos Fonte: Sommerville (2003). Inicialmente, para execução deste processo, projetam-se os casos de teste, os quais deverão gerar artefatos contendo todos os recursos necessários para a preparação e execução dos testes, incluindo ainda os resultados esperados para cada teste a ser executado. Para Macgregor e Sykes (2001), um dos maiores desafios envolvidos no teste de software refere-se à definição e organização dos casos de teste, pois desta partirão todas as definições para as próximas atividades, inclusive quanto à análise final. Seguindo então o processo proposto, com base nos casos de testes levantados, a atividade de preparação dos dados de testes, tem como objetivo preparar todo o ambiente onde os testes serão executados e é nesta fase que são estruturados os dados que servirão de entrada para a execução dos testes. A execução dos casos de testes se dá por três passos fundamentais, definidos por Inthurn (2001), sendo respectivamente: as entradas, processos e saídas. Onde as entradas já foram definidas na etapa anterior de preparação e os processos a serem executados já foram definidos no projeto dos casos de teste. Ao fim do processo obtêm-se então um comparativo entre os resultados gerados após a execução dos testes com os testes esperados, já levantados na fase inicial, com base neste comparativo é possível identificar se o produto em desenvolvimento esta atendendo aos critérios estabelecidos de forma adequada. 9