Geração semi‐automática de artefatos no desenvolvimento de software a partir de testes funcionais

Texto

(1) . . . . Pós‐Graduação em Ciência da Computação Geração Semi‐Automática de Artefatos   no Desenvolvimento de Software   a partir de Testes Funcionais Por Willame Pereira de Oliveira Dissertação de Mestrado . UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN ‐ CENTRO DE INFORMÁTICA PÓS‐GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO [email protected] www.cin.ufpe.br/~posgraduacao . RECIFE, AGOSTO DE 2011. . .

(2) . UFPE ‐ Universidade Federal De Pernambuco Cin ‐ Centro De Informática Pós‐Graduação Em Ciência Da Computação . . Willame Pereira de Oliveira . Geração Semi‐Automática de Artefatos no Desenvolvimento de Software a partir de Testes Funcionais Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação, área de concentração em Engenharia de Software, do Programa de Pós‐graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco. ORIENTADOR: Silvio Romero de Lemos Meira, PhD. CO‐ORIENTADOR: Pedro de Alcântara dos Santos Neto, Dr. . RECIFE, AGOSTO DE 2011. . . . ii.

(3) CATALOGAÇÃO NA FONTE        Bibliotecária Jane Souto Maior, CRB4‐571 . . Oliveira, Willame Pereira GERAÇÃO SEMI‐AUTOMÁTICA DE ARTEFATOS NO DESENVOLVIMENTO DE SOFTWARE A PARTIR DE TESTES FUNCIONAIS / Willame Pereira Oliveira – Recife: O Autor, 2011. 104 folhas: il., fig., tab. . Orientador: Silvio Romero de Lemos Meira. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2009.   . Inclui bibliografia. . 1. Tecnologia da informação – Ciência da computação. I. Meira, Silvio Romero de Lemos (orientador). II. Título. . 004 . . CDD (22. ed.)   . MEI2011‐109 . . . iii.

(4) Dedico este trabalho a Deus, a minha mãe e a toda família, a minha namorada, aos amigos e professores que me deram todo o suporte para chegar até aqui. . v.

(5) Agradecimentos Agradeço a Deus, pois sem Ele meus sonhos, incluindo o do mestrado, não existiriam. Agradeço à minha mãe por todo esforço e apoio na realização desse objetivo. Agradeço a toda minha família, que me apoiou bastante e da qual tenho muito orgulho. Agradeço a Ana Caroline, minha namorada, cuja paciência já estava se esgotando de tanto me ver sentado à frente deste trabalho. Agradeço à Dona Inês e ao Lailson Bandeira por terem me acolhido muito bem, sendo minha família nos primeiros meses em que estive em Recife. Agradeço a todos os meus amigos de longa data que contribuíram de alguma forma com este trabalho. Agradeço aos recentes amigos do laboratório da UFPI, principalmente ao Cleiton Moura, cuja ajuda foi essencial para concretização deste trabalho. Agradeço aos amigos da Infoway que não só contribuíram com minha ida a Recife como também com a realização deste trabalho. Agradeço a todos os professores que acreditaram que eu chegaria até aqui. Agradeço ao meu orientador Silvio Meira pelas conversas que contribuíram bastante nas minhas tomadas de decisão durante o mestrado. Por fim, e não menos especial, agradeço ao meu co‐orientador Pedro de Alcântara. Ele tem sido não só um excelente co‐orientador, mas também um amigo e pai. Sem ele, eu não sei o que seria do meu mestrado e deste trabalho. Serei eternamente grato. . Enfim, a todos, meus sinceros agradecimentos. . . . . vi.

(6) . Reflexão . “O fracasso jamais me surpreenderá, se minha decisão de vencer for suficientemente forte” – O.G Mandino. . . vii.

(7) Geração Semi‐Automática de Artefatos no Desenvolvimento de Software a partir de Testes Funcionais . Resumo Diversos artefatos precisam ser criados durante o processo de desenvolvimento de software. Esses artefatos incluem diagramas, documentos do projeto, modelos UML, código fonte, testes, entre outros. No entanto, criar alguns desses artefatos pode demandar muito tempo e recursos. A geração de documentos, por exemplo, é uma tarefa onerosa e não indicada pela maioria dos processos ágeis. Manter documentos atualizados é algo dispendioso, uma vez que é necessário refletir cada mudança do código nos artefatos relacionados. Este trabalho apresenta uma abordagem que consiste no reuso de testes funcionais para geração semi‐ automática de diversos artefatos no desenvolvimento de software. Essa abordagem, denominada Desenvolvimento Totalmente Dirigido por Teste, visa contribuir para uma redução de custos e aumento da produtividade no processo de desenvolvimento. Mesmo possuindo uma abrangência maior, o foco deste trabalho é apresentar o uso dessa ideia para semi‐ automação do relatório de alteração de software, a partir do protótipo da ferramenta TChangeReport. É apresentado também o TWork, um arcabouço desenvolvido para servir de base para a construção das ferramenta desse projeto. E, por fim, é relatado um estudo experimental, realizado em ambiente acadêmico, e uma aplicação do método e da ferramenta em ambiente industrial feitos com o intuito de avaliar se a ferramenta TChangeReport pode reduzir o esforço na criação do relatório de alteração e ainda manter qualidade compatível com a geração manual. Palavras‐chave: Testes de software, testes funcionais, reuso de testes funcionais, artefatos do desenvolvimento de software, documentos de projeto de software, relatório de alteração de software, estudo experimental. . . viii.

(8) Semi‐Automatic Generation of Artifacts in Software Development from Functional Tests . Abstract Several artifacts must be created during software development. Diagrams, project plan, UML models, source code and test are examples of these artifacts. However, the creation of artifacts can require a lot of time and resources. Documents generation, for instance, is a time‐ consuming task that is not recommended by the agile processes in general. To keep a document up to date is very difficult, once it is required to reflect all the source code changes in each related document. This work presents an approach to semi‐automatic generation of several software development artifacts, based on the reuse of functional test. The approach, named Totally Test Driven Development (TTDD), aims decreasing cost and improving productivity and quality of the software development. This work presents the method and a specific application of it, in order to generate the software change report, by using the TChangeReport tool. It is also presented TWork, a framework for the construction of tools related to the TTDD project. Finally, it is also presented an experimental study, performed in an academic environment, and an application of the method and the tool in an industrial environment in order to evaluate the use of the ideas in practice. . Keywords: Software testing, functional testing, reuse of functional testing, software development artifacts, project documents, software change report, experimental study. . . ix.

(9) Índice 1. . INTRODUÇÃO .......................................................................................................................................... 15 1.1 CONTEXTO ....................................................................................................................................................... 16 1.2 MOTIVAÇÃO ..................................................................................................................................................... 18 1.2.1 RELATÓRIO DE ALTERAÇÃO DE SOFTWARE.......................................................................................................... 19 1.3 OBJETIVOS ....................................................................................................................................................... 21 1.3.1 OBJETIVO GERAL .......................................................................................................................................... 21 1.3.2 OBJETIVOS ESPECÍFICOS ................................................................................................................................. 21 1.4 CONTRIBUIÇÕES CIENTÍFICAS ................................................................................................................................ 22 1.5 TRABALHOS RELACIONADOS ................................................................................................................................. 22 1.6 ESTRUTURA DA DISSERTAÇÃO ............................................................................................................................... 24 . 2. . TESTES DE SOFTWARE ............................................................................................................................. 27 2.1 2.2 2.3 2.4 2.5 2.6 . 3. . INTRODUÇÃO .................................................................................................................................................... 28 TIPOS DE TESTE .................................................................................................................................................. 29 TESTES FUNCIONAIS ............................................................................................................................................ 30 FERRAMENTAS PARA O TESTE FUNCIONAL ............................................................................................................... 31 A FERRAMENTA SELENIUM IDE ............................................................................................................................ 32 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 34 . DESENVOLVIMENTO TOTALMENTE DIRIGIDO POR TESTE ......................................................................... 35 3.1 INTRODUÇÃO .................................................................................................................................................... 36 3.2 TESTES DE ACEITAÇÃO ........................................................................................................................................ 39 3.3 TESTE DE DESEMPENHO E ESTRESSE ...................................................................................................................... 40 3.4 TESTES DE USABILIDADE ...................................................................................................................................... 41 3.5 DOCUMENTAÇÃO DE USUÁRIO ............................................................................................................................. 42 3.6 RELATÓRIO DE ALTERAÇÃO DE SOFTWARE .............................................................................................................. 43 3.6.1 MÉTODO DE AUTOMAÇÃO .............................................................................................................................. 44 3.7 DISCUSSÕES SOBRE O TTDD ................................................................................................................................ 45 3.8 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 45 . 4. . O ARCABOUÇO TWORK ........................................................................................................................... 47 4.1 4.2 4.3 4.4 4.5 . 5. . A FERRAMENTA TCHANGEREPORT ........................................................................................................... 56 5.1 5.2 5.3 5.4 5.5 . 6. . INTRODUÇÃO .................................................................................................................................................... 48 TECNOLOGIAS UTILIZADAS ................................................................................................................................... 49 ARQUITETURA ................................................................................................................................................... 50 TUTORIAL ......................................................................................................................................................... 53 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 55 . INTRODUÇÃO .................................................................................................................................................... 57 ARQUITETURA ................................................................................................................................................... 58 TUTORIAL ......................................................................................................................................................... 60 DISCUSSÕES SOBRE A FERRAMENTA ....................................................................................................................... 64 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 67 . ESTUDO EXPERIMENTAL .......................................................................................................................... 68 6.1 DEFINIÇÃO DOS OBJETIVOS .................................................................................................................................. 69 6.1.1 RESUMO DA PROPOSTA .................................................................................................................................. 70 6.2 PLANEJAMENTO ................................................................................................................................................ 70 6.2.1 CONTEXTO DE SELEÇÃO .................................................................................................................................. 70 6.2.2 FORMULAÇÃO DE HIPÓTESES ........................................................................................................................... 71 6.2.3 SELEÇÃO DE VARIÁVEIS ................................................................................................................................... 72 6.2.4 SELEÇÃO DE PARTICIPANTES ............................................................................................................................ 72 6.2.5 PROJETO DO EXPERIMENTO ............................................................................................................................. 72 . x.

(10) 6.2.6 AMEAÇAS PARA VALIDADE .............................................................................................................................. 74 6.3 OPERAÇÃO ....................................................................................................................................................... 77 6.3.1 PREPARAÇÃO ............................................................................................................................................... 78 6.3.2 EXECUÇÃO ................................................................................................................................................... 78 6.4 ANÁLISE E INTERPRETAÇÃO .................................................................................................................................. 79 6.4.1 DISCUSSÃO .................................................................................................................................................. 81 6.5 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 81 7. . APLICAÇÃO NA INDÚSTRIA ...................................................................................................................... 82 7.1 7.2 7.3 7.4 7.5 7.6 7.7 . 8. . INTRODUÇÃO .................................................................................................................................................... 83 A EMPRESA ....................................................................................................................................................... 83 PARTICIPANTES .................................................................................................................................................. 83 PROCEDIMENTOS ............................................................................................................................................... 83 RESULTADOS ..................................................................................................................................................... 84 DISCUSSÃO ....................................................................................................................................................... 85 CONSIDERAÇÕES DO CAPÍTULO ............................................................................................................................. 87 . CONCLUSÕES E TRABALHOS FUTUROS ..................................................................................................... 88 8.1 CONSIDERAÇÕES FINAIS ...................................................................................................................................... 89 8.2 CONTRIBUIÇÕES ................................................................................................................................................ 90 8.3 TRABALHOS FUTUROS ......................................................................................................................................... 91 . 9. . APÊNDICES .............................................................................................................................................. 93 9.1 9.2 9.3 9.4 . APÊNDICE A: PRINCIPAL TRECHO DO TEMPLATE DO RELATÓRIO ................................................................................ 94 APÊNDICE B: GUIA DO ESTUDO EXPERIMENTAL ..................................................................................................... 95 APÊNDICE C: RESULTADO DETALHADO DO ESTUDO ................................................................................................ 97 APÊNDICE D: QUESTIONÁRIO PÓS‐EXPERIMENTO .................................................................................................. 98 . 10. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................................ 99 . xi.

(11) Lista de Figuras FIGURA 2.1. PROCEDIMENTO DE TESTE DE LOGIN ................................................................................................................... 28 FIGURA 2.2. CASO DE TESTE PARA LOGIN INVÁLIDO ................................................................................................................ 29 FIGURA 2.3. SELENIUM IDE ............................................................................................................................................... 32 FIGURA 2.4. TRECHO DE UM SCRIPT DE TESTE ........................................................................................................................ 33 FIGURA 3.1. DADOS DE UM SCRIPT DE TESTE FUNCIONAL ......................................................................................................... 37 FIGURA 3.2. DIAGRAMA DE ATIVIDADES DO MÉTODO TTDD .................................................................................................... 38 FIGURA 3.3. COMPARAÇÃO ENTRE DUAS VERSÕES DE UM SCRIPT DE TESTE .................................................................................. 44 FIGURA 4.1. FUNCIONAMENTO TWORK ............................................................................................................................... 48 FIGURA 4.2. DIAGRAMA DE CLASSES UML DO TWORK ........................................................................................................... 50 FIGURA 4.3. ESTRUTURA BÁSICA DE UM COMPONENTE DE EXTRAÇÃO DE TESTE ............................................................................ 51 FIGURA 4.4. MODELO UML DE REPRESENTAÇÃO DE TESTE FUNCIONAL ...................................................................................... 53 FIGURA 4.5. TESTES SELENESE HTML PARA O LOGIN DE UMA APLICAÇÃO WEB ............................................................................ 53 FIGURA 4.6. EXEMPLO DE INFORMAÇÕES CONTIDAS NO MODELO DE SAÍDA DO TWORK ................................................................. 54 FIGURA 5.1. FLUXO DE CRIAÇÃO DO RELATÓRIO DE ALTERAÇÃO COM A TCHANGEREPORT ............................................................. 57 FIGURA 5.2. ARQUITETURA TCHANGEREPORT ....................................................................................................................... 58 FIGURA 5.3. DIAGRAMA DE CLASSES UML DA TCHANGEREPORT .............................................................................................. 60 FIGURA 5.4. DUAS VERSÕES DOS TESTES FUNCIONAIS DA APLICAÇÃO ......................................................................................... 61 FIGURA 5.5. INTERFACE PRINCIPAL DA TCHANGEREPORT ......................................................................................................... 61 FIGURA 5.6. SUMÁRIO DO DOCUMENTO GERADO................................................................................................................... 62 FIGURA 5.7. TRECHO DO RELATÓRIO DE ALTERAÇÃO GERADO .................................................................................................. 62 FIGURA 5.8. TRECHO DO RELATÓRIO GERADO APÓS AJUSTES MANUAIS ...................................................................................... 64 FIGURA 6.1. DISTRIBUIÇÃO DOS PARTICIPANTES DO ESTUDO..................................................................................................... 71 FIGURA 6.2. TEMPOS OBTIDOS NO ESTUDO POR PARTICIPANTES ................................................................................................ 79 FIGURA 9.1. PRINCIPAL TRECHO DO TEMPLATE DO RELATÓRIO DE ALTERAÇÃO ............................................................................. 94 FIGURA 9.2. QUESTIONÁRIO PÓS‐EXPERIMENTO .................................................................................................................... 98 . . xii.

(12) Lista de Tabelas TABELA 1 ‐ PROJETO DO EXPERIMENTO ................................................................................................................................ 73 TABELA 2 ‐ RESULTADOS OBTIDOS NO ESTUDO ....................................................................................................................... 79 TABELA 3 ‐ GUIA DO TREINAMENTO E DO EXPERIMENTO MANUAL ............................................................................................. 95 TABELA 4 ‐ GUIA DO TREINAMENTO E EXPERIMENTO AUTOMÁTICO ............................................................................................ 96 TABELA 5 ‐ RESULTADO DETALHADO DO ESTUDO .................................................................................................................... 97 . xiii.

(13) Principais Abreviações Abreviações . Significado . ATDD . Acceptance Testing Driven Development . GCS . Gerência de Configuração de Software . GNU . General Public License . IDE . Integrated Development Environment . J2SE . Java 2 Standard Edition . RTF . Rich Text Format . SST . Software Sob Teste . TDD . Test Driven Development . TTDD . Totally Tests Driven Development . UML . Unified Modeling Language . XML . Extensible Markup Language . . xiv.

(14) . Capítulo  . 1 1. Introdução Este capítulo relata o contexto e as principais motivações para realização deste trabalho, lista os objetivos de pesquisa almejados, as contribuições científicas esperadas, os trabalhos relacionados e, finalmente, mostra como está estruturada a presente Dissertação. . 15.

(15) 1.1. Contexto . Diversos artefatos precisam ser criados durante o processo de desenvolvimento de software. Esses artefatos incluem diagramas, documentos do projeto, modelos UML, o próprio código do software, que é considerado o principal artefato na abordagem ágil, testes de software, dentre outros.   O teste de software é uma das atividades relacionadas à garantia da qualidade de software (SOMMERVILLE, 2003). O teste pode ser categorizado de acordo com seus objetivos (IEEE, 2004). Um tipo de teste bastante conhecido é o teste funcional, que deve verificar se o comportamento do software está em conformidade com as especificações, analisando se determinadas entradas causam as saídas esperadas. Também existem testes que focam nos requisitos não‐funcionais, tendo como objetivo verificar a conformidade do produto com características associadas ao comportamento, como desempenho, segurança e usabilidade. Documentos são também artefatos de grande relevância para o desenvolvimento de software, no entanto, não são tão reconhecidos e referenciados como o teste de software. A Documentação de Usuário, por exemplo, é um material impresso ou eletrônico que provê informações para os usuários sobre o uso de um software (IEEE, 2001). Essa documentação é útil para o usuário entender como manusear o produto e para dirimir dúvidas que podem surgir ao longo do tempo. Outro documento é o Relatório de Alteração de Software. Ele é responsável por relatar as mudanças realizadas entre duas versões de um produto. Sua criação e manutenção é uma das tarefas da Gerência de Configuração de Software (GCS) (IEEE, 1990). Esse documento é útil principalmente para o usuário final entender as alterações entre versões de um software e evitar possíveis chamados técnicos por falta do conhecimento dessas alterações. Existem diversas ferramentas na literatura voltadas para oferecer apoio à automação da geração de cada um dos artefatos relatados anteriormente. Para o teste funcional, por exemplo, há ferramentas que se baseiam na captura e re‐execução (capture/playback) de ações realizadas nas telas do Software Sob Teste (SST), como o Selenium1. Para os testes não‐funcionais, como testes de desempenho (DENARO et al, 2004), . 1. http://seleniumhq.org. 16.

(16) há ferramentas como o JMeter2. Dentre os diversos trabalhos para apoio à Documentação de Usuário, há o de Jungmayr e Stumpe (1998) que propuseram o uso de modelos, descrevendo a interação de usuários com o software, para gerar esse documento. Para auxílio à automação do Relatório de Alteração, tem‐se a ferramenta JDiffChaser3. No entanto, o uso dessas ferramentas exige conhecimento e esforço. Por conta disso, nem sempre tais artefatos são utilizados no desenvolvimento de software. Neste trabalho é definido um método (“método” na acepção de (HOUAISS & VILAR, 2001)), denominado “Totally Test Driven Development” (TTDD), ou “Desenvolvimento Totalmente Dirigido Por Teste” em português, que visa gerar, de forma semi‐automática, diversos artefatos no desenvolvimento a partir do reuso de testes funcionais automatizados, a um baixo custo. O teste funcional é, dentre os tipos de teste, o mais conhecido e utilizado por empresas de desenvolvimento (MCT, 2007). Por possuírem uma riqueza de informações em sua estrutura, esses testes, como demonstra essa abordagem, podem ser reutilizados para auxiliar a geração de artefatos como testes de desempenho, Documentação de Usuário, Relatório de Alteração e ainda outros não discutidos, como o teste de aceitação (IEEE, 2044) e o teste de usabilidade (MATERA et al, 2002).   Trabalhos anteriores (SANTOS et al, 2008) (SANTOS et al, 2010) (FÉ et al, 2010) demonstraram que o reuso de testes funcionais pode trazer resultados significativos para automação de testes de desempenho e Documentação de Usuário. É importante destacar que o TTDD é uma contribuição deste trabalho. Os trabalhos anteriores relatam estudos que foram os precursores para o surgimento do TTDD e que atualmente constituem apenas uma pequena parte do que prescreve esse método. Além do método TTDD, neste trabalho são discutidos os artefatos passíveis de automação e, além disso, são apresentadas as seguintes instâncias desse método:   •. O TWork, um arcabouço para ser a base de criação de todas as ferramentas de geração de artefatos baseadas no reuso de testes;  . •. Um método para automação da geração do Relatório de Alteração de Software e o protótipo de uma ferramenta, denominada TChangeReport, que implementa esse método e que foi construída a partir do TWork. . 2 3. http://jakarta.apache.org/jmeter/ http://sourceforge.net/projects/jdiffchaser/. 17.

(17) Por fim, para avaliar as ideias apresentadas, foi realizado um estudo experimental com o intuito de verificar se a TChangeReport realmente contribui para uma redução no esforço de criação do Relatório de Alteração e ainda contribui para manter ou aumentar a qualidade desse documento. Além disso, foi realizada uma aplicação do protótipo da ferramenta em um ambiente industrial para avaliar sua aceitação e a de seu método de automação. . 1.2. Motivação . O Relatório de Alteração, a Documentação de Usuário, o teste de desempenho e estresse, o teste de aceitação e o teste de usabilidade, todos são artefatos de importância para o desenvolvimento de software. Porém, muitos desses artefatos não são realidades nas organizações devido aos elevados custos que introduzem no processo de desenvolvimento. Os testes não‐funcionais, como os testes de desempenho e estresse, por exemplo, são pouco utilizados, em parte por conta do custo associado, como também por falta de conhecimento das ferramentas existentes que apóiam na criação dos mesmos (MCT, 2007).   Além disso, criar e manter documentos, como a Documentação de Usuário e o Relatório de Alteração de Software, são tarefas que costumam ser evitadas por muitos profissionais, pois geralmente são vistas como tarefas custosas e repetitivas. De um modo geral, os métodos ágeis não prescrevem a criação de documentos devido a seus custos associados (MANIFESTO ÁGIL, 2011). Embora haja divergência sobre o assunto, é certo que a criação de documentos e sua manutenção acarretam em custo e esforço nos projetos. Muitas das vezes os documentos se tornam obsoletos pouco tempo após sua criação devido à incapacidade de atualização contínua. Essa dificuldade de manutenção de documentos atualizados se deve, em grande parte, ao fato de que o código fonte de um software evolui rapidamente e acompanhar essa evolução na documentação associada é muito caro. Esses problemas são alguns dos motivos que justificam a necessidade por métodos e ferramentas baseadas em código que apóiem a geração automática desses artefatos. A abordagem proposta neste trabalho, o TTDD, descreve a possibilidade de geração semi‐ automática de artefatos ligados ao desenvolvimento a partir do reuso de testes funcionais 18.

(18) automatizados. O TTDD tem como principal objetivo reduzir os custos na criação desses artefatos e permitir maior produtividade no desenvolvimento. Com essa abordagem pode ser possível, por exemplo, trabalhar com métodos ágeis e ainda possuir artefatos ligados à documentação, uma vez que os custos para sua geração tendem a ser bastante reduzidos como demonstrarão os estudos relatados no decorrer deste trabalho. Outra intenção do TTDD é promover a qualidade no desenvolvimento de software. Manter testes funcionais automatizados é uma tarefa dispendiosa, porém, como mencionado na seção anterior, o teste funcional é um dos tipos de teste mais conhecido e utilizado nas empresas de desenvolvimento de software. Como o TTDD atribui maior valor ao teste funcional automatizado, ele pode motivar a prática dessa importante atividade para a garantia da qualidade do software. De acordo com o método TTDD, e como já dito anteriormente, os diversos artefatos que podem ter sua geração auxiliada a partir dos testes são: Relatório de Alteração de Software, Documentação de Usuário, testes de desempenho e estresse, testes de aceitação e testes de usabilidade. Cada um desses artefatos será melhor discutido no Capítulo 3. Como todas as ideias do TTDD partem de um mesmo princípio, que é o reuso de testes para automação da geração de artefatos, justifica‐se a necessidade por uma ferramenta comum que possa ser reusada na implementação de cada uma dessas ideias. Diante disso, é proposto o TWork, um arcabouço que agrega os conhecimentos relativos à extração de informações dos testes funcionais para serem reusadas na automação da geração dos artefatos do TTDD. A próxima seção apresenta a motivação associada à automação do Relatório de Alteração de Software, o artefato do TTDD foco deste trabalho. . 1.2.1 Relatório de Alteração de Software O Relatório de Alteração de Software, ou Relatório de Mudanças, tem um papel importante porque usuários em geral gostariam de saber o que foi modificado de uma versão para outra de um software. Isso evita erros dos usuários durante a operação do sistema, além da economia de recursos por parte da equipe de desenvolvimento, pois, uma vez sabendo o que foi alterado, os usuários poderiam evitar muitos chamados técnicos.   19.

(19) Porém, gerar um Relatório de Alteração é uma tarefa cansativa e bastante propensa a erros, uma vez que exige a análise do status do software antes e após as mudanças. Se imaginarmos uma grande equipe trabalhando em um mesmo software, pode ficar bastante difícil sua criação.   Citando um caso real, a Infoway4, uma empresa de Teresina‐PI voltada para consultoria e soluções em tecnologia para gestão de saúde, parceira neste projeto, possuía uma equipe de dez desenvolvedores trabalhando, em paralelo, em várias partes de um software em um de seus projetos. Sempre antes de se implantar uma liberação, era necessário integrar as diversas partes desse software e fazer um relatório contendo todas as alterações introduzidas pela nova versão, visando assim criar um relato das mudanças para os usuários da aplicação. Isso era necessário para que o usuário final pudesse não só conhecer, mas também validar essas alterações. Essa tarefa demandava muito tempo do gerente do projeto, responsável pelo relatório, e era bastante sujeita a erros, uma vez que várias alterações eram esquecidas. Uma solução inicial que poderia ser pensada para esse caso seria exigir que cada desenvolvedor se responsabilizasse pelo relato de suas alterações e que o gerente do projeto apenas as unisse em um único documento. Porém, essa ideia ainda exigiria que cada membro da equipe dedicasse um bom tempo à criação do documento. E, como já dito na seção anterior, manter documentos é uma atividade geralmente evitada devido aos seus custos associados. Dado o cenário descrito, é justificável a necessidade por uma ferramenta que auxilie a automação da geração do Relatório de Mudanças de Software. Neste trabalho é apresentado um método baseado na reutilização de duas versões dos testes funcionais de uma aplicação para geração semi‐automática de tal artefato. É apresentada também a TChangeReport, o protótipo de uma ferramenta que implementa esse método.   Com o uso da ideia proposta, diante do problema real citado, cada desenvolvedor poderia manter o foco na criação dos testes funcionais do que implementou e o gerente do projeto apenas reutilizaria esses testes para geração do relatório. Assim, a equipe, além de se beneficiar em qualidade no desenvolvimento e manter o foco nos testes, pode se beneficiar também em redução de esforço na geração do Relatório de Alteração ao reusar os testes para tal tarefa. . 4. http://www.infoway-pi.com.br. 20.

(20) 1.3. Objetivos . Esta seção lista o objetivo geral e os objetivos específicos desta Dissertação. . 1.3.1 Objetivo Geral Contribuir para redução de custos e aumento de produtividade no processo de desenvolvimento de software ao propor um método de semi‐automação da geração de diversos artefatos no processo de desenvolvimento, facilitando a adoção de documentação até mesmo em processos baseados nos princípios ágeis. Além disso, objetiva‐se valorizar ainda mais a prática de teste, devido ao reuso de testes funcionais automatizados como insumo para a semi‐automação de outros artefatos. . 1.3.2 Objetivos Específicos O objetivo geral pode ser decomposto nos seguintes objetivos específicos: 1. Apresentar uma visão básica da área de testes, explicando os principais conceitos úteis para entendimento deste trabalho; 2. Propor o método TTDD e discutir os vários artefatos do desenvolvimento que podem ter sua geração auxiliada por essa abordagem; 3. Propor o TWork, um arcabouço desenvolvido para ser a base de implementação das ferramentas de geração de artefatos do TTDD; 4. Propor um método para semi‐automação da geração do Relatório de Alteração de Software a partir do reuso de testes funcionais e uma ferramenta, denominada TChangeReport, que implementa esse método; 5. Realizar um estudo experimental em ambiente acadêmico com o intuito de avaliar a TChangeReport, verificando se essa ferramenta reduz os custos na criação do documento e ainda mantém ou melhora a qualidade do relatório; 6. Avaliar o método de semi‐automação do Relatório de Alteração e a ferramenta TChangeReport em um ambiente industrial. . 21.

(21) 1.4. Contribuições Científicas . Com este trabalho, espera‐se fornecer as seguintes principais contribuições: •. Fornecer um método para semi‐automação da geração de diversos artefatos no desenvolvimento de software a partir do reuso de testes, de forma a:   o Reduzir custos no processo de desenvolvimento, automatizando tarefas mais simples e deixando para as pessoas, as tarefas mais nobres, promovendo maior produtividade nesse processo; o Fortalecer a ideia de reusar artefatos do desenvolvimento para geração de outros; o Estímulo a pesquisas partindo do mesmo princípio do reuso de testes, além de estimular pesquisas para reduzir o esforço na criação e manutenção de testes funcionais, pois isso reforça a abordagem; o Facilitar a introdução de alguns artefatos, como documentos, na abordagem ágil; o Promover a qualidade ao atribuir maior valor ao teste, servindo de motivação à prática dessa importante atividade para a garantia da qualidade de um produto de software. . •. Fornecer um arcabouço que pode ser reutilizado para a construção de ferramentas do TTDD; . •. Fornecer um método de automação do Relatório de Alteração baseado no reuso de duas versões de testes funcionais de um software; . •. Fornecer uma ferramenta para semi‐automação da geração do Relatório de Alteração de Software. . 1.5. Trabalhos Relacionados . Foram realizadas pesquisas no intuito de se encontrar trabalhos relacionados ao método TTDD e ao TWork, porém nenhum foi encontrado. Na literatura existem ferramentas que propõem automação da geração de testes de desempenho e estresse, Documentação de Usuário, dentre 22.

(22) outros artefatos do TTDD, mas nenhuma parte do reuso de testes funcionais automatizados. A grande maioria dos trabalhos encontrados utiliza modelos descrevendo o software para auxiliar tais tarefas (JUNGMAYR & STUMPE, 1998) (PARIS & LINDEN, 1996) (GAROUSI et al, 2006) (HARTMAN & NAGIN, 2004).   Em relação a ferramentas para automação da geração do Relatório de Alteração de Software, somente uma foi encontrada: a JDiffChaser5. Ela é capaz de realizar a comparação de GUI (Graphical User Interface) e é voltada apenas para aplicações feitas em Java Swing. Essa ferramenta gera o relatório de alteração a partir de diferenças encontradas na comparação de imagens das duas versões de um software. Diferentemente da JDiffChaser, a TChangeReport não é limitada para uso somente com aplicações Desktop Java, sendo independente da tecnologia do software analisado. Ela somente depende da tecnologia dos testes funcionais, mas, como será descrito no decorrer do trabalho, possui um mecanismo que a torna flexível para aceitar como entrada testes criados com qualquer ferramenta de teste funcional. Há outros trabalhos que não estão diretamente relacionados ao propósito da TChangeReport, mas que merecem ser discutidos. O plug‐in do SVN6 (Subversion) para a IDE Eclipse7, por exemplo, utiliza a ferramenta Diff para mostrar o que foi alterado de uma versão para outra de um artefato. Esse artefato pode ser um caso de teste, classe, arquivo texto ou algum outro artefato do desenvolvimento. Essa ferramenta é um utilitário importante para auxiliar os desenvolvedores a controlar as versões dos artefatos de um projeto de software, permitindo o trabalho colaborativo. Diferentemente dessa ferramenta, a TChangeReport é voltada para geração do Relatório de Alteração de todo um software reutilizando, para isso, duas versões dos testes desse software. Ela realiza comparações entre os testes, mas, a partir disso, visa automatizar a geração do documento, que se destina principalmente ao usuário final do sistema, relatando que alterações no uso do sistema serão perceptíveis a ele. As duas versões dos testes utilizados na TChangeReport podem ser obtidas a partir de sistemas de controle de versão, como o SVN. . 5. http://sourceforge.net/projects/jdiffchaser/ http://subversion.apache.org/ 7 http://www.eclipse.org/ 6. 23.

(23) A JUnitMx (WLOKA et al, 2009) é uma ferramenta de teste de unidade que utiliza um modelo de mudanças para auxiliar os desenvolvedores na criação de novos testes de unidade. Ela grava todas as alterações realizadas no código da aplicação de maneira similar a um sistema de controle de versão. Por meio dessas mudanças, a ferramenta analisa quais são os testes afetados e os re‐executa, analisando a cobertura dos mesmos conforme feito por ferramentas de análise de cobertura, como o EclEmma8. A JUnitMx então fornece aos desenvolvedores um feedback quantitativo e informações detalhadas sobre os efeitos da mudança, que não só facilitam a escrita de mais testes eficazes, mas também motiva os desenvolvedores a conseguirem uma cobertura total dos testes realizados. A JUnitMx utiliza, portanto, um modelo de mudanças do código para auxiliar na criação de testes de unidade, diferentemente da TChangeReport, que utiliza um modelo de mudanças dos testes para auxiliar na geração do Relatório de Alteração, documento voltado principalmente para o usuário final. Dessa forma, as propostas deste trabalho, incluindo o TTDD, o TWork e a TChangeReport tendem a ser inovadoras, pois após várias pesquisas na literatura não foram encontrados trabalhos com proposta similar. . 1.6. Estrutura da Dissertação . As seções desta Dissertação encontram‐se estruturadas da seguinte forma: •. Capítulo 1 ‐ Introdução . Este capítulo relatou o contexto e as principais motivações para realização deste trabalho, listou os objetivos de pesquisa almejados, as contribuições científicas esperadas, os trabalhos relacionados e, finalmente, mostrou como está estruturada a presente Dissertação. •. Capítulo 2 ‐ Testes de Software . Este capítulo apresenta os conceitos da área de Testes essenciais para entendimento deste trabalho. • 8. Capítulo 3 ‐ Desenvolvimento Totalmente Dirigido Por Teste . http://www.eclemma.org/. 24.

Geração semi&#8208;automática de artefatos no desenvolvimento de software a partir de testes funcionais

Geração semi‐automática de artefatos no desenvolvimento de software a partir de testes funcionais