Your SlideShare is downloading. ×

TCC Virgilio Rocha Ximenes

801
views

Published on

Monografia abordando um ambiente integrado de teste automatizado, mostrando benefícios e, como criar um.

Monografia abordando um ambiente integrado de teste automatizado, mostrando benefícios e, como criar um.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
801
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – UNIFOR CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT CURSO CIÊNCIA DA COMPUTAÇÃOAMBIENTE INTEGRADO DE TESTE AUTOMATIZADO VIRGILIO ROCHA XIMENES Fortaleza – Ceará 2012
  • 2. VIRGILIO ROCHA XIMENESAMBIENTE INTEGRADO DE TESTE AUTOMATIZADO Monografia apresentada para obtenção dos créditos da disciplina de Trabalho de Conclusão - TCC do Centro de Ciências Tecnológicas da Universidade de Fortaleza, como parte das exigências para graduação no Curso de Ciências da Computação. Orientador: Rafael Garcia Barbosa, MSc. Fortaleza – Ceará 2012
  • 3. 3 AMBIENTE INTEGRADO DE TESTE AUTOMATIZADO Virgílio Rocha XimenesPARECER: ______________________________DATA: ___/___/____BANCA EXAMINADORA: ________________________________________________ Rafael Garcia Barbosa, MSc. ________________________________________________ Alex Silveira da Costa, MSc.
  • 4. 4 AGRADECIMENTOS Inicialmente, agradeço a Deus, pelo amor, pelas oportunidadesconcedidas, pela esperança, pelo conforto, pela vida, e por ter me dado condiçõesfísicas e emocionais para chegar até aqui, pois posso dizer as palavras que estãonas sagradas escrituras: “Até aqui nos ajudou o Senhor”. Agradeço aos meus pais, pois, se não fossem eles, eu não estaria aqui, epelo carinho e dedicação que nunca deixaram faltar. A minha mãe, pela cobrança epela educação que moldaram meu caráter. A meu pai, pela sabedoria e paciênciaque me fizeram chegar aonde cheguei. Agradeço a minha namorada, Ticiana Castelo Branco, pelo apoio,carinho, pela compreensão, paciência e dedicação durante este período. Agradeço ao meu orientador, Prof. Rafael Garcia, pela paciência, peloconhecimento compartilhado, pela oportunidade e orientação neste estudo. Agradeço a todos os professores da UNIFOR, em especial ao RobertoFaçanha, a Sandra e ao Fernando Parente, pelo conhecimento transmitido, pelapaciência e atenção dispensada ao longo dos semestres. Agradeço a todos os meus amigos, Vitor Rifane, Rodrigo Gato, MariliaFeitoza, Leandro Almeida e tantos outros, pela amizade, pelas brincadeiras, pelasconversas, pelo apoio e pelas saídas para lanchar no Baixinho.
  • 5. 5 RESUMOEstudos revelam que o retrabalho é responsável direto pelo atraso e por grandeparte dos custos envolvidos em um projeto. A principal maneira de reduzir oretrabalho é através dos testes, porém estes são executados manualmente. Estetrabalho objetiva apresentar um ambiente com algumas ferramentas integradas como objetivo de automatizar a disciplina de teste. O foco do trabalho é a ferramentaJenkins, que é responsável pela criação e manutenção do ambiente integrado deteste. Abordam-se as principais características da disciplina de testes, bem comosua automação, suas vantagens e desvantagens. E, por fim, faz-se um estudo decaso em que se pode aplicar a automação de testes em desenvolvimento deaplicações. A linguagem de programação alvo é a linguagem Java, por ser alinguagem adotada pela faculdade.
  • 6. 6 ABSTRACTStudies reveal that the rework is directly responsible for the delay and for much of thecosts involved in a project. The main way to reduce rework is through tests, but theyare executed manually. This study presents an environment with some integratedtools with the goal of automating the test discipline. The focus of the work is the toolJenkins, who is responsible for the creation and maintenance of the integrated testenvironment. It addresses the key features of the discipline of testing and itsautomation, advantages and disadvantages. In the end a study case in which onecan apply the automated testing applications under development. The targetprogramming language is Java, because it is the language adopted by the college.
  • 7. 7 LISTA DE ABREVIATURASAPI – Application Programming Interface (Interface de Programação de Aplicação)CLI – Command Line Interface (Interface de Linha de Comando)CVS – Concurrent Version System (Sistema de Versões Concorrentes)IDE – Integrated Development Environment (Ambiente Integrado de Desenvolvimento)SCM – Source Code Management (Sistema de Controle de Versão)SQL – Structured Query Language (Linguagem Consulta Estruturada)SVN – Apache SubversionTDD – Test-Driven Development (Desenvolvimento Orientado a Teste)WAR – Web Archive (Arquivo de Aplicação Web)XML – Extensible Markup Language (Linguagem de Marcação Extensível)
  • 8. 8 LISTA DE FIGURASFigura 1 – Modelo em “V” do processo de testes …………………………………… 14Figura 2 – Grafo de complexidade ciclomática de um software …………………… 18Figura 3 – Utilização da ferramenta de análise estática ……………………………. 32Figura 4 – Utilização da ferramenta de análise estática ……………………………. 33Figura 5 – Utilização da ferramenta de análise estática ……………………………. 35Figura 6 – Utilização da ferramenta de teste unitário em um script ……………….. 37Figura 7 – Interface gráfica da ferramenta de teste de carga ……………………… 39Figura 8 – Utilização da ferramenta de teste de carga em um script ……………… 40Figura 9 – Realização da implantação do ambiente automatizado …………………42Figura 10 – Telas do sistema que sofrerá a execução das ferramentas de teste… 45Figura 11 – Configuração do ambiente e visualização dos resultados…………….. 48
  • 9. 9 LISTA DE TABELASTabela 1 – Tabela comparativa entre as ferramentas de análise estática…………. 43
  • 10. 10 SUMÁRIOINTRODUÇÃO .......................................................................................................... 111. TESTE DE SOFTWARE...................................................................................... 13 1.1 Visão geral .................................................................................................... 13 1.2 Técnicas de testes ........................................................................................ 16 1.2.1 Teste caixa-preta ...................................................................................... 17 1.2.2 Teste caixa-branca ................................................................................... 18 1.2.3 Teste caixa-cinza...................................................................................... 19 1.2.4 Técnicas não funcionais ........................................................................... 19 1.3 Fases ............................................................................................................ 20 1.3.1 Fase de teste unitário ............................................................................... 20 1.3.2 Fase de teste de integração ..................................................................... 21 1.3.3 Fase de teste de sistema ......................................................................... 21 1.3.4 Teste de aceitação ................................................................................... 22 1.3.5 Teste de operação.................................................................................... 23 1.4 Automação de teste ...................................................................................... 232 AUTOMAÇÃO DE TESTE ...................................................................................... 25 2.1 Contexto de testes automatizados ................................................................... 25 2.2 Técnicas de revisão ......................................................................................... 25 2.2.1 Ferramentas de verificação de código fonte ............................................... 26 2.2.2 Ferramentas de automação ....................................................................... 27 2.2.3 Ferramentas de gerenciamento ................................................................. 29 2.3 Ambiente para execução de teste automatizado .............................................. 30 2.3.1 Checkstyle .................................................................................................. 30 2.3.2 Findbugs.................................................................................................... 32 2.3.3 PMD ........................................................................................................... 34 2.3.4 JUnit ........................................................................................................... 36 2.3.5 JMeter ........................................................................................................ 38 2.3.6 Jenkins ....................................................................................................... 40 2.4 Conclusões....................................................................................................... 423 ESTUDO DE CASO ............................................................................................... 44 3.1 Especificação ................................................................................................... 44 3.2 Configuração do ambiente ............................................................................... 46 3.3 Análise dos resultados ..................................................................................... 48CONCLUSÃO............................................................................................................ 50REFERÊNCIAS ......................................................................................................... 52
  • 11. 11 INTRODUÇÃO Um estudo realizado na PUC-Rio mostra que um dos responsáveis pelosatrasos nos projetos de software é o retrabalho, sendo, também, responsável por45% dos custos envolvidos em um projeto, e o custo de um retrabalho aumenta deacordo com a fase do projeto. O retrabalho é caracterizado por mudar o foco dosprofissionais de produzir uma nova funcionalidade para realizar correções dedefeitos em funcionalidades que foram, ou não, já homologadas (STAA, 2011). A maneira mais eficaz de reduzir o retrabalho é através da execuçãosistemática de testes. Entretanto, muitas vezes a qualidade é assegurada através detestes manuais realizados após o desenvolvimento de um módulo específico ou, atémesmo, do sistema inteiro. Porém tais testes são lentos e incompletos, além de sermuito cansativo executar um vasto conjunto destes testes. Esta abordagem deexecução manual dos testes traz consigo vários problemas, pois, com a crescentecomplexidade do software, alguns testes ou cenários de teste deixam de serexecutados, facilitando o surgimento de erros de regressão. O erro de regressãosurge quando uma funcionalidade que estava funcionando deixa de funcionar apósalguma alteração no software. Autores indicam, exaustivamente, o uso de ferramentas de automação deteste para manter a viabilidade de execução dos testes e o aumento deprodutividade. Isso advém do fato de que, com o tempo, aumenta-se a quantidadede casos de testes e, sem o uso de uma ferramenta adequada, torna-se impossívela execução de todos os casos de testes descritos em tempo hábil. Desta forma, serápossível garantir um alto nível de qualidade mesmo após mudanças, pois existiráuma rotina que será executada sempre que solicitada, garantindo que, paradeterminados casos, o software continue funcionando corretamente. Com aexecução automática dos testes, será possível reduzir não só o retrabalho, mastambém o custo envolvido em um projeto, pois uma vez que a rotina de teste sejaescrita, poderá ser reutilizada quantas vezes forem necessárias. O teste automatizado é executado mais rápido, e com a evolução dosoftware e do teste, o cenário do caso teste continua a ser executado, facilitando,assim, o teste de regressão, portanto o que era um problema na abordagem manual
  • 12. 12não é mais na automática. Existem ferramentas onde é possível realizar testes emvários níveis, garantindo a qualidade desde o nível mais baixo, o nível de código, atéo nível mais alto, o nível de interface. Porém, Myers afirma que devem ser evitados testes descartáveis, isto é,testes que possuem uma vida útil, pois a qualidade do software piora gradualmentecom as iterações de desenvolvimento (MYERS, 2004). Para esta finalidade, existemos testes de regressão, que permitem quantificar a evolução da qualidade dosoftware, mantendo e executando testes realizados anteriormente. O objetivo geral deste trabalho é apresentar diversas ferramentasutilizadas em testes automatizados, de modo que estas venham a compor umambiente integrado, a partir do qual será realizado um estudo de caso. Além disso,apresentar uma visão geral da área de testes de software, mostrando as vantagensdos testes automatizados, ferramentas que realizam os diversos tipos de testes eum ambiente integrado de teste composto pelas ferramentas apresentadas. Este trabalho está organizado da seguinte forma: no primeiro capítuloserá apresentada uma visão geral da área de teste, bem como as técnicas e asprincipais fases. O capítulo 2 trata da automação de teste, através da apresentaçãodo contexto da automação, das técnicas de revisão e de ferramentas que irãocompor o ambiente. No último capítulo, será apresentado um estudo de caso, ondeserá apresentada a montagem e a criação do ambiente integrado de teste, bemcomo a execução dos testes e a visualização dos relatórios gerados pelas própriasferramentas. No final, serão apresentadas as conclusões, indicando algumas dasvantagens na utilização de um ambiente integrado.
  • 13. 131. TESTE DE SOFTWARE1.1 Visão geral O software tem feito cada vez mais parte da vida das pessoas, através decomputadores, tablets e, até mesmo, de celulares. Com isso, as pessoas têm ficadocada vez mais exigentes. Portanto, o desafio é desenvolver software com qualidadee segurança em um curto período de tempo, mantendo um baixo custo, além deatender os requisitos do produto. A atividade de teste vem exatamente para isso, pois, encontrar um bug noinício do desenvolvimento é menos custoso para o projeto, além de tornar o softwaremais confiável uma vez que um software testado possui uma confiabilidade maior.Com esta qualidade agregada devido ao teste, pode-se, também, fazer umamedição desta qualidade em relação aos erros encontrados (ALMEIDA, 2012). De acordo com Myers (2004), existe uma psicologia por detrás dos testesque afirma que os programadores se mostram resistentes aos testes, pois afirmamque o teste serve apenas para mostrar que não existem erros no programa, ou que opropósito do teste é mostrar que o programa atende às funcionalidadescorretamente, ou que o teste é o processo de estabelecer a confiança de que oprograma faz aquilo que foi feito para fazer. Porém, se o teste for elaborado sob aperspectiva de que o programa não possui falhas, este será elaborado de modo aatingir a sua meta que é a de não encontrar falhas. Por outro lado, se houver acrença de que o programa possui falhas, a ação será de encontrar o máximo deerros possíveis ou não conformidades. Portanto, a definição de teste que o testadordeve possuir em mente é a de que o teste é o processo de executar um programacom a intenção de encontrar erros. E compreender bem a definição de teste podefazer uma grande diferença no sucesso de seus esforços. Na Figura 1, é apresentado o modelo em V, que é um modelo tradicional,utilizado durante a execução dos testes, que é uma ordem inversa a dodesenvolvimento, pois, no desenvolvimento, a primeira etapa é a especificação derequisitos, e a última é a codificação. Inicialmente são executados os testes unitáriose, por último, os de aceitação, onde incidem respectivamente em cada um. Portanto,
  • 14. 14o primeiro teste a ser executado é sobre o que foi elaborado por último, e o últimoteste o que foi elaborado logo no começo da fase de desenvolvimento (MORAIS,2011). Figura 1 – Modelo em “V” do processo de testes. Bartie (2007) separa o processo de teste em sete etapas, que consistemem: Planejamento dos testes, onde se define uma proposta de teste baseada noprazo, no custo e na qualidade esperada; especificação dos testes, onde seidentifica os casos de testes que deverão ser construídos e modificados de acordocom as solicitações do cliente; modelagem dos testes, onde se faz a identificaçãode todos os elementos necessários para a implementação de cada caso de testeespecificado; preparação do ambiente, etapa que visa disponibilizar um ambientede teste pronto para rodar os testes planejados nas etapas anteriores, semintervenção humana que interrompa o processo de teste; execução dos testes,etapa em que ocorre a execução em si e conferência dos testes planejados, demodo a garantir a conformidade do produto com os requisitos; análise dosresultados, etapa em que é feito um balanço de acordo com os resultados dostestes, e, por fim, o encerramento do processo, etapa em que é feito umfechamento do processo, comparando os resultados alcançados com o esperado.
  • 15. 15 A etapa de planejamento dos testes é uma etapa que contémcaracterísticas mais gerenciais do que técnicas, e deve ser subdivida nas seguintesetapas: estudo do projeto, avaliação de impacto, análise de esforço, definição depossíveis cenários e aprovação do planejamento. O estudo do projeto é umaavaliação realizada sobre o que se espera do software a ser construído bem comoos riscos do projeto e os respectivos impactos, avaliando, também, os requisitos soba perspectiva de custo, prazo e esforço. A avaliação de impacto pode ser vista comoa avaliação das exigências de criação e modificação de casos de teste, adequaçõesao processo de teste, aquisição e adequação às ferramentas de teste, além damodificação do ambiente. A definição de possíveis cenários é o momento em que háuma busca por uma identificação de cenários diversos que alteram o prazo, oesforço, o custo ou a qualidade do projeto, há também a definição do cronograma-macro, os riscos e o plano de ação para cada cenário. A aprovação do planejamentoé a parte em que se deseja obter o aceite das propostas de cenários e a divulgaçãodas propostas aceitas. Após o planejamento dos testes, há a especificação dos testes, ondehá um estudo dos requisitos, a identificação dos casos de testes e o refinamento doprojeto de teste. O estudo dos requisitos busca avaliar os requisitos funcionais e nãofuncionais, identificando as inconsistências e estabelecendo o aceite dosdocumentos. Na subetapa de identificação dos casos de testes, identifica-se cadarequisito e seu respectivo caso de uso, identificando, em cada caso de uso, seusfluxos (básico, alternativo e exceção) e os casos de testes que irão incidir sobrecada fluxo. Paralelamente, a arquitetura dos testes deve ser especificada, avaliandoadequações na automação para a preparação do ambiente, da execução dos testese da análise dos resultados. Após isso, o refinamento do projeto de teste serve parareavaliar as estimativas iniciais de custo, prazo e esforço, reavaliar riscos do projetoe estabelecer um cronograma detalhado baseado no cronograma-macro. Depois do planejamento dos testes, vem a atividade de modelagem detestes, que é o momento de criação dos roteiros de testes, incluindo procedimentospara iniciar, executar, validar e realizar uma limpeza após a execução do caso deteste, além de detalhar a massa de entrada de dados, identificando opçõesparametrizáveis para gerar testes variados, mantendo a rastreabilidade entre o casode teste e a massa de dados de entrada. A massa de dados de saída também deve
  • 16. 16ser detalhada através da identificação dos pontos de validação, da análise dosdados, comparando os dados esperados com os dados efetivamente retornados e,também, garantindo a rastreabilidade. E, por fim, tem-se a elaboração do plano deexecução dos testes, que inclui a especificação das configurações necessárias paraa execução dos testes. Em seguida, vem a preparação do ambiente, que é feita através dasconfigurações especificadas e informações geradas, além, é claro, da instalação daversão do software a ser testado. Neste momento, tem-se a execução dos testes, que é feita pelaexecução dos testes progressivos, que são disparados em funcionalidadesdisponibilizadas a cada nova versão, e os testes regressivos, que são executadossobre funcionalidades que estavam homologadas nas versões anteriores. Além daexecução, propriamente dita, tem-se a identificação de não conformidades com osrequisitos, tanto para os testes progressivos quanto para os regressivos. Após a execução, há a análise dos resultados, que vem para revisar osresultados em não conformidades levantados pela execução dos testes, revisartestes progressivos em conformidade, atualizar o baseline, formalizar os defeitosencontrados, através do isolamento de cada caso de teste que apontou comoresultado uma não conformidade da coleta de evidências que comprovam a nãoconformidade, do detalhamento das condições que indicam a não conformidade, daclassificação de cada defeito encontrado. Então, finalmente, tem-se o encerramento do processo, que é feito pelaextração de indicadores, como, por exemplo, quantidade de erros por funcionalidadeou, até mesmo, um gráfico apresentando a evolução ou regressão do software, peloresumo do processo de testes e a avaliação final do processo.1.2 Técnicas de testes A atividade de teste não depende de tecnologia, uma vez que é possíveltestar software em diferentes paradigmas, embora o paradigma orientado a objetovenha a facilitar o desenvolvimento desta atividade. Como dito anteriormente, o
  • 17. 17objetivo do teste é executar um programa com a intenção de encontrar erros,independente, portanto, de tecnologia. Segundo Myers (2004), dentre os princípios do testador, existem três quedevem ser observados constantemente. Testar é o processo de executar umprograma com a intenção de encontrar erros. Um bom caso de teste é aquele quetem alta probabilidade de encontrar um erro ainda não encontrado; um teste bemsucedido é aquele que detecta um erro ainda não encontrado.1.2.1 Teste caixa-preta O teste caixa-preta, também chamado de teste funcional, avalia ocomportamento externo do sistema. Para usar esta metodologia, o testador deve vero software, literalmente, como uma caixa preta. Sua meta é ser completamentedespreocupado sobre o comportamento interno e a estrutura do programa. Deve seconcentrar, portanto, em encontrar circunstâncias em que o programa não secomporte de acordo com as especificações (MYERS, 2004). Segundo Pressman (2005), este teste tem por objetivo encontrar errosdas seguintes categorias: funções incorretas ou omitidas, erros de interface, erros deestrutura de dados ou de acesso à base externa, erros de comportamento oudesempenho, erros de iniciação ou de término. Numa situação ideal, todas as possibilidades são testadas, mas, namaioria dos casos, isso é muito difícil, ou quase impossível. Portanto quanto maisentradas forem testadas, mais rico será o teste. A abordagem mais utilizada, naprática, é obter uma amostra que represente os possíveis valores de entrada. Um dos problemas deste tipo de teste é que os casos de teste sãoderivados da especificação, e esta, por sua vez, pode estar ambígua em relação aosistema produzido, e como resultado as entradas especificadas podem não ser asmesmas aceitas para o teste.
  • 18. 18 Apesar de necessário, esse tipo de teste é insuficiente para identificarcertos riscos em um projeto de software.1.2.2 Teste caixa-branca Complementar ao teste caixa-preta, tem-se o teste caixa-branca, ou testeestrutural, analisando diretamente o código-fonte para analisar aspectos como: testede condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos oucomplexidade ciclomática. Segundo Myers (2004), o objetivo é fazer com que cada declaração noprograma seja executada pelo menos uma vez. Se o testador executar, via caso deteste, todos os possíveis caminhos de controle de fluxo pelo programa, então oprograma será completamente testado. Porém, se considerarmos um programacomum, com uma estrutura de repetição, que repete vinte vezes um dado conjuntode instruções e, dentro desse conjunto de instruções, temos algumas estruturas decontrole de fluxos aninhadas, há que testar todas as possibilidades da Figura 2,sendo cada nó do grafo um conjunto de instruções e cada aresta um possívelcaminho. Figura 2 – Grafo de complexidade ciclomática de um software
  • 19. 19 Uma das possíveis desvantagens do uso deste tipo de teste é que nemsempre os testes que envolvem as estruturas de um sistema vislumbram asfuncionalidades e iterações esperadas do sistema, o que torna este tipo de testedesnecessário ou, até mesmo, inviável. Outra desvantagem é a inserção de errosatravés do acesso ao código interno de um sistema.1.2.3 Teste caixa-cinza O teste caixa-cinza é uma combinação dos testes caixa-branca e caixa-preta, pois envolve ter acesso ao algoritmo e estrutura de dados, com o intuito dedesenvolver casos de teste a serem executados como caixa-preta. Um exemplo de teste caixa-preta seria quando o código de duas unidadesé estudado, através da abordagem caixa-branca, para projetar casos de teste queserão conduzidos através de interfaces expostas, através da abordagem caixa-preta.Esta metodologia pode ser usada em outros níveis de teste, embora seja bastanteutilizada em teste de integração. A atual implementação da metodologia caixa-cinza é altamentedependente do uso de uma aplicação utilizada para executar e validar o teste emquestão, o depurador. Estudos confirmam que esta metodologia pode ser aplicadaem tempo real usando o software executando na plataforma de destino, o queexpande as capacidades desta metodologia, por incluir não apenas o caminho paracobertura de verificação, mas também o melhor e o pior caso. Também possibilitaverificar e validar requisitos de performance, requisitos funcionais e estruturais emum único caso de teste com o mesmo formato usado para verificar e validarrequisitos funcionais (COULTER, 2001).1.2.4 Técnicas não funcionais Estas técnicas são chamadas de não funcionais, não por estaremvinculadas a funcionalidades do sistema, mas sim por estarem vinculadas arestrições de usabilidade. Portanto, são técnicas que avaliam questões comosegurança, desempenho, usabilidade, entre outros aspectos.
  • 20. 20 Existem outras técnicas de teste, cada uma com um objetivo específico,como, por exemplo, o teste de regressão para analisar se determinadoscomponentes continuam funcionando após alguma alteração; teste de desempenho,para verificar se o desempenho do software está dentro de um limite aceitável dentrode determinado cenário; teste de stress, para analisar o comportamento do sistemaem condições anormais de demanda. Para verificar se um software é adequado aouso, tem-se o teste de usabilidade; ou para verificar seu funcionamento a partir daliberação do produto para pequenos grupos de usuários trabalhando em umambiente controlado, teste alfa, ou não controlado, teste beta (SANTOS, NETO,2009).1.3 Fases Segundo Myers (2004), existem duas abordagens que chamam atenção,a Top-down e a Bottom-up. Na abordagem top-down, ou incremental, incrementa-seo módulo a ser testado com as novas funcionalidades e testa-o. Por outro lado, naabordagem bottom-up, testa-se primeiro as unidades mais básicas, até testar omódulo. Devido à dificuldade de se realizar testes na abordagem top-down, aabordagem bottom-up é a mais escolhida. Como visto anteriormente, existem diversos tipos de testes, e cada tipo deteste tem um foco diferente, para testar características diferentes. Serão abordadosos seguintes tipos de testes: teste unitário, teste de integração, teste de sistema eteste de aceitação.1.3.1 Fase de teste unitário Segundo Pressman (2005), o teste unitário, ou de unidade, focaliza oesforço de verificação na menor unidade de projeto do software. A complexidadedos testes e dos erros descobertos é reduzida, por conta da limitação do escopoestabelecido para o teste. Este tipo de teste enfoca a lógica interna deprocessamento e de estrutura de dados dentro dos limites de um componente. Pela definição, tem-se que o teste unitário é um teste do tipo caixa-
  • 21. 21branca, pois a estrutura de dados local é examinada para garantir que os dadosarmazenados temporariamente mantenham sua integridade durante todo o algoritmotestado. Todos os caminhos independentes ao longo da estrutura de controle sãoanalisados, para garantir que todos os comandos da unidade tenham sidoexecutados pelo menos uma vez. As condições limites também são testadas, paragarantir que a unidade trabalhe adequadamente nos limiares estabelecidos. Testesde fluxo de dados são executados inicialmente, pois se os dados não entram e saemcorretamente, os outros testes são questionáveis (PRESSMAN, 2005).1.3.2 Fase de teste de integração Segundo Pressman (2005), uma questão pertinente é: “Após o testeunitário, verificamos que as unidades estão funcionando individualmente, por queduvidar que eles não funcionem conjuntamente?” Dados podem ser perdidos atravésde uma interface ou chamadas a sub-rotinas; quando combinadas, podem nãoproduzir o resultado esperado. O teste de integração é a fase em que se verifica a interface entre oscomponentes. As unidades devem ser integradas e testadas conjuntamente. Estetipo de teste pode expor defeitos nas interfaces ou nas interações. O objetivo desteteste é verificar funcionalidades, desempenho e confiabilidade. Este tipo de teste éuma técnica sistemática para construir a arquitetura do software enquanto conduztestes para descobrir erros associados às interfaces. Normalmente, aplica-se,também o teste de regressão neste momento para verificar se novos erros foramintroduzidos com a adição de novas unidades ou alteração das existentes.1.3.3 Fase de teste de sistema O teste de sistema não é um processo de teste de funções de um sistemacompleto ou programa, pois isso seria redundante com o teste funcional. O propósitodeste teste é comparar o software com o objetivo original. O teste de sistema é oprocesso de tentar demonstrar a forma como o programa não cumpre os seusobjetivos; e, por definição, este teste é impossível se não houver um conjunto deobjetivos mensuráveis para o software (MYERS, 2004).
  • 22. 22 Segundo Myers (2004), existem algumas categorias principais de teste desistema, não que todas sejam aplicáveis a todos os softwares existentes, mas quedevem ser observadas, que são: teste de instalação, onde pode ser realizadoapenas na documentação, como um exercício mental sobre a documentação,analisando se ela é suficiente; teste de carga, que é submeter o software a umacarga alta de dados com o intuito de mostrar que o software se torna inutilizável parauma determinada massa de dados; teste de stress, que é submeter o software a umvolume máximo de dados em um curto espaço de tempo, ou simular o númeromáximo de usuários acessando ou de ações ao mesmo tempo; teste de usabilidade,importante para verificar se as interfaces de usuário são especificas para osusuários, são fáceis de entender e de aprender, as mensagens de erro são fáceis deanalisar e diagnosticar ou precisam de um PhD em ciências da computação; testede segurança, que verifica se os mecanismos de proteção incorporados ao softwareirão, de fato, proteger os dados de invasões impróprias; teste de desempenho, que éprojetado para medir o desempenho de um software no contexto de um sistemaintegrado e requer instrumentação tanto de hardware, para verificar utilização derecursos, quanto de software, para verificar instruções ou registrar eventos; teste derecuperação é um teste que força o erro de diversos modos e verifica se arecuperação da falha é adequadamente realizada.1.3.4 Teste de aceitação O teste de aceitação é um tipo de teste caixa-preta, realizado antes de osistema ser disponibilizado. Tem por objetivo comparar os requisitos iniciais e asatuais necessidades do usuário final. Normalmente, são conduzidos por um gruporestrito de usuários finais em um ambiente similar, ou idêntico, ao que será utilizadopelo software. Não é objetivo, portanto, encontra falhas, pois estas já foramdetectadas e resolvidas; o objetivo é verificar se o software faz aquilo que lhe foisolicitado. Nesta fase, ocorrem os processos de verificação e validação para verificarse o que foi especificado foi entregue e se o que foi entregue atende àsexpectativas.
  • 23. 231.3.5 Teste de operação O teste de operação é a fase em que o teste é conduzido pelosadministradores do ambiente final onde o software será disponibilizado. Nesta fase,devem ser feitas simulações para garantir que o sistema entre em produção comêxito. Envolve testes de instalação, segurança, confiabilidade, entre outros, de modoa garantir o suporte ao negócio. Esta fase é aplicável somente a softwares que sãopróprios de uma dada organização. Em alguns casos, o software a ser implantado éum software substituto, portanto deve-se garantir que o suporte ao negócio serámantido.1.4 Automação de teste A execução manual de um caso de teste é rápida e efetiva, mas aexecução e repetição de um vasto conjunto de testes é uma tarefa muitodispendiosa e cansativa. É considerado normal que os testadores não verifiquemnovamente todos os casos a cada mudança. É partindo desta ideia que surgem oserros de software, trazendo prejuízo para as equipes de desenvolvimento queperdem muito tempo para identificar e corrigir os erros, além do estresse causadotanto para a equipe quanto pelo usuário final causado pelo atraso na entrega, e dodescrédito atribuído à empresa, que entrega software com qualidade duvidosa.Como é necessário muito esforço para executar todo o conjunto de testesmanualmente, dificilmente toda a bateria de testes será executada novamente acada alteração, o que facilita a entrada de erros de regressão, e a tendência é queisso se repita até que a manutenção se torne uma tarefa tão custosa que areconstrução comece a ser levada em consideração (BERNARDO, KON, 2008). Com a crescente exigência por software de qualidade, padrões dequalidades impostos pelas pessoas de um modo geral e o advento de algumasmetodologias que recomendam, ou até explicitam, o uso intensificado dos testesautomatizados, como, por exemplo, o XP e TDD, que reconhecem que prevenirdefeitos é mais fácil e barato que identificá-los e corrigi-los posteriormente, o uso detestes automatizados vem se tornando cada vez mais frequente.
  • 24. 24 Testes automatizados são rotinas que exercitam funcionalidades dosoftware sendo testados e fazem verificações automáticas nos efeitos colateraisobtidos. A grande vantagem é que todos os casos de teste podem ser fácil erapidamente repetidos a qualquer momento e com pouco esforço (BERNARDO,KON, 2008). Alguns testes, por exemplo, podem ser facilmente reproduzidosautomaticamente, o que manualmente seria muito difícil, ou quase impossível, porexemplo, simular inúmeros usuários acessando o sistema, através de umaferramenta, é necessário, apenas, uma simples configuração, o que chega a sertrivial. Por outro lado, nem sempre é vantajoso automatizar os testes, pois existemsituações em que o teste manual é mais adequado. Por exemplo, se a interface deusuário for mudar consideravelmente, qualquer automação teria que ser feitanovamente, ou quando o software é muito simples que não valha a pena o uso detestes automatizados, o teste manual continua sendo uma boa opção. Então, antesde se automatizar um determinado teste, deve-se analisar a necessidade dele, pois,caso determinado teste não tenha a necessidade de ser reexecutado, não há motivopara automatizá-lo (SANTOS, NETO, 2009). A automação de um conjunto de teste geralmente demanda bem maisesforço que sua execução manual, mas, quando automatizado, sua execução ébastante simples. Assim, em algumas situações, automatizar é a melhor maneira deeconomizar tempo e recurso (SANTOS, NETO, 2009). Portanto, o teste automatizado não exclui o processo manual, pelocontrário, entra como uma abordagem auxiliar excluindo as tarefas repetitivas ouimpraticáveis. Pois, assim como há algumas vantagens em automatizar, existemalgumas vantagens em testes manuais. No próximo capitulo, será apresentado o contexto de automação detestes, bem como algumas técnicas de revisão, algumas ferramentas de teste,através da abordagem do objetivo, e como utilizar cada uma.
  • 25. 252 AUTOMAÇÃO DE TESTE Antes de decidir automatizar um conjunto de testes, é preciso analisar osoftware e quais testes serão construídos. O principal motivo para se automatizar umteste é a necessidade de executá-lo diversas vezes. Em um caso típico, existe anecessidade de se executar testes várias vezes. Isso normalmente é suficiente parajustificar a automação dos testes (SANTOS, NETO, 2009).2.1 Contexto de testes automatizados A execução manual de um caso de teste é rápida e efetiva, mas aexecução e repetição de um vasto conjunto de testes executados manualmente éuma tarefa cara e entediante. É normal e compreensivo que os testadores nãoverifiquem todos os casos de testes a cada mudança do código. E tão critico quantoeste cenário é o efeito “bola de neve”, pois, ao se realizar uma correção, dificilmentetoda a bateria de teste será executada, o que leva a erros de regressão(BERNARDO e KON, 2008). O teste, portanto é um elemento fundamental na garantia da qualidade.Contudo, a sua realização de forma sistemática exige tempo e recurso. Assim, éimportante que os testadores utilizem ferramentas que o automatizem de algumaforma. Os testes automatizados, embora venham a exigir mais tempo paraprogramar, dão mais segurança na manutenção e permitem a execução a qualquermomento (SANTOS, NETO, 2009). A automação de um conjunto de testes, geralmente, demanda bem maisesforço que sua execução manual, mas, depois de automatizado, a execução ébastante simples, portanto, automatizar os testes é uma boa maneira de economizartempo e dinheiro. Porém, mesmo automatizando parte do processo de teste, oRetorno de Investimento (ROI) não é imediato, pois nem sempre ele tem um retornoem curto prazo.2.2 Técnicas de revisão
  • 26. 26 Cunha (2010) afirma que as ferramentas automatizadas de teste podemser classificadas como ferramentas de verificação de código fonte, ferramentasde automatização na execução dos testes e ferramentas de gerenciamento. Asferramentas são agrupadas de acordo com a função que executam. Estaclassificação auxilia na obtenção de ferramentas apropriadas para cada tipo deanálise a ser executada sobre o software e na obtenção de métricas, que auxiliamna medição da qualidade do produto.2.2.1 Ferramentas de verificação de código fonte As técnicas de inspeção de código são uma forma de análise estática,onde o programa é analisado sem ser executado. Estas inspeções seguem algunschecklists de erros e heurísticas que identificam problemas comuns. Para algunserros e heurísticas é possível automatizar o processo de verificação em relação aessas listas, o que resultou no desenvolvimento de analisadores estáticosautomatizados (SOMMERVILLE, 2007). Os verificadores estáticos são ferramentas de software que varrem ocódigo fonte ou mesmo o código objeto, sem a execução do software. Este tipo deferramenta é utilizado para verificar se o software foi produzido dentro de padrõesestabelecidos de codificação, identificar código que não será executado, tambémchamado de código morto, retirar classes de defeitos, etc. Este tipo de ferramentanão verifica se o código realiza o que deveria realizar, portanto não verifica afuncionalidade, analisando somente se o código está bem escrito (CUNHA, 2010). Os verificadores estáticos de código podem verificar regras de estilo deprogramação, erros ou ambos. Regras de estilo podem ajudar a prevenir certos tiposde erros e melhorar a qualidade do software, porém as violações a essas regras nãoimplica, necessariamente, em um erro, mas podem ser vistas como um alerta de queum trecho de código é crítico de alguma forma (TERRA, BIGONHA, 2008). Portanto, é possível listar alguns benefícios da análise estática, queseriam: encontrar erros e códigos de risco; fornecer um retorno objetivo aosprogramadores para ajudá-los a reconhecer onde foram precisos ou imprecisos;fornecer ao líder de projeto uma oportunidade para estudar o código-fonte, o projeto
  • 27. 27e a equipe de uma perspectiva diferente; e retirar certas classes de defeitos, o quepossibilita que a equipe concentre-se mais nas deficiências do projeto (TERRA,BIGONHA, 2008).2.2.2 Ferramentas de automação A automação de teste pode ser alcançada pelo uso de softwaresespecíficos para controlar a execução dos testes. A comparação dos resultadosesperados com os resultados obtidos, a configuração das pré-condições de teste eoutras funções de controle e relatório de teste podem ser obtidas através destessoftwares. Normalmente, a automação de teste envolve automatizar um processomanual já existente que utiliza um processo descritivo formal. As ferramentas de automação têm por objetivo auxiliar diretamente naexecução dos testes; através do apoio ao processo de testes. Elas permitem reduziras falhas introduzidas pela intervenção humana, aumentar a produtividade a médio elongo prazo e, principalmente, possibilita tratar a automação de testes como umprojeto, uma vez que será necessário prazo e esforço para o levantamento dasferramentas a serem utilizadas, configuração das mesmas e adequação do processode desenvolvimento para utilização das ferramentas (CUNHA, 2010). Os tipos de automação são, normalmente, agrupados de acordo com aforma como os testes automatizados interagem com a aplicação. Os tipos sãoagrupados em dois paradigmas: baseados na interface gráfica, onde os testesinteragem diretamente com a interface gráfica através da simulação de um usuário;e baseados na lógica de negócio, onde os testes exercitam as funcionalidades daaplicação sem interagir com a interface gráfica. Este último implica, muitas vezes,em alterar a aplicação para torná-la testável (CAETANO, 2007). Quanto ao tipo de automação, as ferramentas de testes automatizadoscostumam ser agrupadas em cinco tipos: baseadas na interface gráfica (capture /playback); dirigidas a dados (data-driven); dirigidas a palavra-chave (keyword-driven); baseadas na linha de comando (command line interface – CLI); baseadas nainterface de programação de aplicativos (Application Programming Interface – API) eo Test Harness.
  • 28. 28 Na abordagem de testes automatizados baseados na interface gráfica, ostestes são realizados por meio da interface gráfica fornecida pela aplicação.Normalmente a ferramenta fornece um recurso para capturar (capture) as ações dousuário enquanto ele estiver usando a aplicação. Estas ações são gravadas em umscript, que pode ser reproduzido (playback) em outro momento. Os testes automatizados dirigidos a dados representam uma vertente dostestes baseados na interface gráfica. Basicamente, funcionam como um mecanismopara auxiliar a execução de testes que repetem as mesmas ações várias vezes,porém com dados diferentes. A principal vantagem é a reutilização dos scripts, oque, consequentemente, diminui a complexidade e o tempo de manutenção. Os testes dirigidos à palavra-chave foram criados para dar suporte aostestes de aceitação explicitados pelas metodologias ágeis. Eles são realizadosatravés da interface gráfica da aplicação. Normalmente a ferramenta oferece umconjunto pré-definido de palavras-chaves para permitir a criação dos testes. Cadapalavra-chave é um comando de alto nível que representa uma ação do usuário. Já o teste automatizado baseado na linha de comando afirma que,normalmente, a lógica de negócio da aplicação não deve ser amarrada à interface.Em virtude disso, a lógica pode ser exercida através da execução de um conjunto decomandos e parâmetros pré-determinados. Uma ferramenta de CLI interpreta oscomandos e parâmetros, executa a função selecionada e apresenta o resultado. Oobjetivo é fornecer uma interface para o mundo exterior que não seja dependente daGUI. Uma API representa um conjunto de operações expostas por umaaplicação com o intuito de permitir que outras possam acessar ou consumir as suasfuncionalidades. A automação baseada na API faz uso dessa característica paraguiar a execução dos testes. Uma das vantagens do uso da API é que a aplicaçãoexterna se abstrai da forma como as operações são implementadas. O Test Harness é um tipo de automação de teste baseado na lógica denegócio que prega o uso racional e inteligente da automação. É um tipo que podeser construído por meio de pequenos programas para testar uma API, uma interfacede linha de comando, ou qualquer outra forma. Nesta abordagem não importa o
  • 29. 29meio, desde que não haja interações com a interface gráfica. O objetivo é exercitaras funcionalidades críticas do software que realizam variações difíceis de seremtestadas por meios normais.2.2.3 Ferramentas de gerenciamento As ferramentas de gerenciamento normalmente são utilizadas para fazera gestão de testes e defeitos. Por exemplo, uma ferramenta que permite que sejamcadastrados os defeitos encontrados no software durante os testes. Essasferramentas auxiliam a gerenciar quais módulos devem ser testados e a escolher adata de execução, entre outras atividades. Elas são responsáveis por fornecer umainterface entre as ferramentas de execução, por realizar o gerenciamento de defeitose de requisitos, gerar os resultados e os relatórios de progresso de testes (CUNHA,2010). A gestão de defeitos é uma das atividades primordiais de um processo deteste de software. Por meio de uma gestão, é possível acompanhar a qualidade dosoftware em teste com base nos defeitos cadastrados pelos testadores ao longo deum ciclo de teste. Com base nesses dados, é possível identificar áreasproblemáticas da aplicação onde os riscos são maiores e planejar atividadespreventivas (CAETANO, 2007). A gestão de defeitos pode ser realizada por meio de ferramentasautomatizadas chamadas de bug tracking system. Estas ferramentas oferecem umrepositório onde os membros da equipe podem cadastrar os defeitos, acompanhar ociclo de vida destes defeitos e emitir um relatório de gestão. Já a gestão de testes é o coração de um processo de testes de software.Ela é importante para o planejamento e controle das atividades de um projeto deteste. Esta gestão pode ser utilizada através de ferramentas de gerenciamento deteste (test management system). Estas ferramentas oferecem um banco de dadosonde os líderes de testes poderão criar suítes com casos de testes, atribuir os casosde testes aos testadores, acompanhar o status da execução deles e emitir osrelatórios com métricas e estatísticas.
  • 30. 302.3 Ambiente para execução de teste automatizado A qualidade e a produtividade da atividade de testes são diretamentedependentes do critério de testes utilizados e da existência de uma ferramenta detestes que os suportem. Sem a utilização de uma ferramenta automatizada, aaplicação de um critério torna-se uma atividade propensa a erros e limitada aprogramas muito simples (MALDONADO et al., 2006). Outro fator importante para um bom ambiente de automatização de testeé o suporte oferecido pelas ferramentas aos testes de regressão. Os casos de testeutilizados durante a atividade de teste podem ser facilmente revalidados após umaalteração. Atualmente, várias ferramentas de teste podem ser incorporadas aoambiente de desenvolvimento, e esta prática é comum, pois as ferramentas sãoconfiguradas em vários níveis. Exemplo disso são as ferramentas checkstyle,findbugs e PMD. Estas ferramentas realizam a análise estática de código, porémexistem certos testes que são executados por uma ferramenta e por outra não. Além das ferramentas de análise estática, existem as ferramentas deteste unitário, como o JUnit, e as que auxiliam em testes de carga, de estresse e dedesempenho, como o JMeter, através da utilização dos testes unitários criados peloJUnit. Estas ferramentas citadas foram escolhidas para uso neste trabalho porterem foco em Java, por serem gratuitas, de fácil instalação e utilização. Tambémpodem apresentar os resultados de suas verificações em vários formatos, o quefacilita a integração com ferramentas de integração contínua, como a que seráutilizada, o Jenkins.2.3.1 Checkstyle O checkstyle, como dito anteriormente, é uma ferramenta de análiseestática de código utilizada no desenvolvimento do software para verificar se o
  • 31. 31código gerado atende a um conjunto de regras. A instalação do checkstyle é extremamente simples, bastando, apenas,instalar o plug-in na IDE desejada, por exemplo, o Eclipse; e baixar o aplicativoresponsável pela execução. O checkstyle disponibiliza uma série de módulos que podem serconfigurados para alterar o nível de rigor das regras que serão validadas. Caso aregra desejada não esteja especificada, é possível definir algumas próprias,aumentando, assim, a capacidade da ferramenta. Assim como explicado no tópico 2.2.1 sobre as ferramentas de análise decódigo fonte, o checkstyle não verifica se a rotina está funcionando corretamente,mas checa se o código gerado atende aos padrões de codificação. Inicialmente estaabordagem parece desnecessária, mas a longo prazo, o código gerado torna-semais legível e reutilizável, melhorando, assim, a sua manutenção. O checkstyle foi desenvolvido em Java, dando-lhe a capacidade deindependência de sistema operacional. Depois de instalado, para executar ochecktyle é extremamente simples, bastando apenas invocá-lo via script deautomação, informando o diretório de fontes, um arquivo de configuração e o tipo desaída a ser gerado, ou através da interface da IDE, conforme Figura 3. Esta ferramenta é ideal para projetos onde se deseja forçar osdesenvolvedores e seguir um estilo padronizado de programação. Por ser altamenteconfigurável e dar suporte a qualquer padrão, ela permite verificar muitos aspectosdo código-fonte. O checkstyle possui uma grande quantidade de módulos, cujo nível derigor pode ser configurado entre obrigatório e opcional. Um módulo verifica a adiçãode comentários aos métodos, classes e pacotes, o que facilita o entendimento docódigo, uma vez que não será necessário estudar o método ou a classe paraentendê-la. Outro, checa adesão à convenção de nomes para métodos e classesestabelecidos pela fabricante e que é utilizada pelo mercado. Outro, verifica seexistem blocos de instruções vazios, um bloco de decisão vazio, por exemplo. Existeum módulo responsável por checar se há condições lógicas muito complicadas, o
  • 32. 32que dificulta a legibilidade do código. Um módulo verifica se existem procedimentosque lançam tipos de erros ilegais e/ou genéricos, pois, pela regra definida pelaferramenta, erros devem ser específicos de modo a facilitar o tratamento deles. Figura 3 – Utilização da ferramenta de análise estática2.3.2 Findbugs O findbugs, assim como o checkstyle, também é uma ferramenta deanálise estática de código, mas com uma diferença: ele opera sobre o código objeto,o bytecode. Esta ferramenta trabalha, basicamente, com categorias de problema decorretude, quando o código parece estar fazendo algo que o desenvolvedor nãopretende ou necessita fazer, como é o caso da atribuição de um valor nulo para umavariável; más práticas, quando o código viola alguma boa prática, por exemplo, ocódigo sobrescreve o método equals, mas não sobrescreve o hashCode, pois,segundo o fabricante da linguagem, a máquina virtual utiliza o hashCode paraverificar se dois objetos são iguais no método equals; vulnerabilidade de código,
  • 33. 33quando o código permite ações não desejadas, como no caso de um possívelataque de injeção de SQL. Assim como o checkstyle, o findbugs também é desenvolvido em Java,garantindo a portabilidade de sistema operacional. A instalação também é análoga,seguindo os mesmos passos, que consistem em: baixar o aplicativo para que possaser executado através de uma chamada e baixar o plug-in na IDE desejada. A execução do findbugs também é bastante simples. Depois de instalado,basta invocá-lo através de um script e informar o diretório de fontes e a localizaçãodos bytecodes. Ele também pode ser invocado através da interface disponibilizadana IDE, conforme ilustra a Figura 5. É possível definir no findbugs o nível de severidade de cada problemareportado pela ferramenta e indicar a partir de qual nível de severidade se desejaanalisar no código-fonte. Figura 4 – Utilização da ferramenta de análise estática O findbugs possui uma grande variedade de módulos, cujo nível de
  • 34. 34esforço pode ser configurado entre mínimo, padrão e máximo. Em algumasocasiões, especialmente em projetos grandes, ocorre estouro de memória quando oesforço é máximo. Para solucionar este problema, a ferramenta possibilita configurara quantidade de memória a ser utilizada. Existe um módulo da ferramenta que checa se os recursos alocadosforam devidamente liberados, por exemplo, conexões com banco de dados, streamsde arquivos, etc. Existe outro módulo que verifica se as comparações entre objetosdo tipo String são efetuadas corretamente, comparando o valor da propriedade, nãoo objeto. Outro módulo verifica se os operadores de curto-circuito estão sendoutilizados, pois estes operadores otimizam a leitura da expressão lógica. Um módulointeressante é o que verifica possíveis ataques de injeção de SQL, pois, em algunscasos, é possível que o usuário realize determinadas operações no banco em quenão é possível pelos meios normais de utilização do software. Outro checa se háuma possível invocação de uma propriedade com valor nulo, o que ocasionaria umerro de referência nula. Além desses, há um módulo que verifica se o valor deretorno de uma função está sendo ignorado.2.3.3 PMD O PMD, tal qual as ferramentas anteriores, é uma ferramenta de análiseestática de código. A instalação do PMD também segue a mesma simplicidade das outrasferramentas, portanto basta instalar o plug-in da IDE desejada e baixar o aplicativopara execução. Esta ferramenta é desenvolvida em Java, assim como as ferramentasanteriores, e, assim como o checkstyle, o PMD permite a criação de novas regras.Contudo, a execução do PMD difere um pouco das outras ferramentas, pois elepossui um add-on chamado Copy-Paste Detector (CPD), que verifica a existência decódigo duplicado. Porém, para executar somente o PMD, a ideia é a mesma, comomostra a Figura 6. Neste caso, faz-se necessário apontar para o arquivo deconfigurações, para o diretório de fontes e definir o tipo de saída. Para executar oCPD, presente na mesma ferramenta, basta invocá-lo, informando o diretório de
  • 35. 35fontes e a quantidade mínima de tokens para considerar um código duplicado,conforme ilustrado na mesma imagem. Assim como o checkstyle, o PMD tem evoluído bastante, pois foramadicionados verificadores para outros propósitos. E, graças à possibilidade deexpansão da ferramenta, os desenvolvedores podem escrever novos detectores depadrões de erro através da utilização tanto de Java quanto de XPath, que é umconjunto de regras definidos em um arquivo XML (TERRA e BIGONHA, 2008). Tanto o checkstyle quanto o PMD trabalham sobre o código-fonte,enquanto que o findbugs sobre o código-objeto. Embora as ferramentas sejamanalisadores estáticos e funcionem sobre o mesmo objeto, os objetivos dasferramentas são completamente distintos, portanto uma ferramenta não exclui aoutra, pelo contrário, complementa, aumentando, assim, o nível e a quantidade deregras verificadas no código. Figura 5 – Utilização da ferramenta de análise estática O PMD possui uma grande variedade de módulos. Um módulo éresponsável por verificar se existe uma concatenação de Strings em um laço de
  • 36. 36repetição, pois, segundo a fabricante do Java, o objeto String é imutável, portantouma concatenação gera um novo objeto, ocupando mais memória. Para otimizareste processo, existem os construtores de String, que são o StringBuilder ou oStringBuffer. Existe outro que é responsável por verificar se existem trechos decódigo muito aninhados, o que vem a dificultar a legibilidade do código. Também épossível verificar com outro módulo a existência de código desnecessário, ou código“morto”, que é aquele trecho de código que jamais será executado. Outro módulocheca a complexidade ciclomática de um trecho de código, com a prerrogativa deque este trecho precisa ser reescrito. Quando o método é excessivamente longo,outro módulo alerta sobre isso, afirmando que existem procedimentos do métodoque podem ser extraídos para novos métodos. Se o nome de uma determinadavariável é curto, de uma a três letras, outro módulo lançará um erro, pois nomesmuito pequenos dificultam o entendimento da finalidade da variável. Além de existirum módulo para verificar a obrigatoriedade do uso das chaves, para tornar o códigomais legível.2.3.4 JUnit O JUnit é um framework de teste utilizado para a realização de testeunitário automatizado do tipo caixa-branca, onde o programador pode criar ummodelo padrão de testes para ser executado de forma sequencial. Existem algumas vantagens em se utilizar o JUnit, como a possibilidadeda criação rápida de código de teste, aumentando, assim, a qualidade do software.Uma vez escritos, os testes podem ser executados rapidamente sem a interrupçãoda atividade de desenvolvimento. A ferramenta checa os resultados dos testes efornece uma resposta imediata. Um benefício importante é o baixo custo, uma vezque a ferramenta é grátis. Esta ferramenta é desenvolvida em Java, assim como as demais. Parainstalar basta baixar o aplicativo. Outra grande vantagem desta ferramenta é que elaé facilmente integrável às várias IDE’s e ferramentas de automação, como o Ant e oMaven.
  • 37. 37 Para utilizar esta ferramenta através de um script de automação, oprocesso é um pouco mais complexo. Neste caso, é necessário alterar o classpathda aplicação apontando para o diretório que contém os bytecodes, o código fonte dosoftware, o código fonte dos casos de teste, além, é claro, da própria ferramenta.Além disso, é necessário indicar qual tipo de saída desejada, conforme mostra aFigura 6. No momento da criação dos testes, existem duas rotinas que sãoexecutadas sempre: uma que é chamada antes de executar cada rotina de teste, osetUp, e outra, que é chamada após a execução de cada rotina de teste, otearDown. Outras duas rotinas também são executadas sempre antes de umaclasse de teste, beforeClass; e outra, que é executada após, afterClass. Assim épossível garantir que o ambiente se encontra com a mesma configuração antes edepois da execução de cada rotina de teste. O JUnit trabalha com o conceito de assertivas. Uma das boas práticas éexecutar uma assertiva para cada condição e isolar cada uma em uma rotinadistinta, pois assim a complexidade da assertiva é menor e, caso haja uma falha, acomplexidade do erro é reduzida. Figura 6 – Utilização da ferramenta de teste unitário
  • 38. 38 Ao adotar o JUnit como framework de teste unitário, é possível obteralgumas vantagens uma vez que o framework checa os resultados dos testes efornece uma resposta imediata, pois não é necessário executar toda a rotina detestes para apresentar os resultados. Outra vantagem é o fato de ser orientado aobjetos, tornando a escrita de casos de teste mais fácil e natural para os usuáriosJava. Ele fornece uma ótima API para criação de casos de teste, favorecida peloconceito de assertivas. Outra vantagem que vale ressaltar é o fato de ser grátis.2.3.5 JMeter O JMeter é uma ferramenta utilizada para testes de carga e dedesempenho. Para o JMeter, os usuários do sistema são representados comothreads. Dentro de um script, as threads executam a sequência de passosdeterminada. Cada thread simula um usuário. Thread é uma forma de um processo dividir a si mesmo em duas ou maistarefas que podem ser executadas concorrentemente (TANENBAUM, 2011). O JMeter possui uma interface gráfica para se criar scripts de teste, comomostra a Figura 7, onde é possível definir as ações do usuários que serãoexecutadas. Embora o JMeter consiga trabalhar a nível de interface gráfica, estaferramenta não consegue interpretar JavaScript, quando se trata de aplicação WEB.É possível também executar os testes criados através do JUnit, fazendo uso deouvintes (listeners) disponibilizados pela ferramenta. A região amarela mostra uma barra de menu que auxilia na criação de umarquivo de um plano de teste, com as opções como novo, abrir, fechar, salvar, entreoutras, e também na execução do plano. Já a região vermelha auxilia na criação dos procedimentos a seremexecutados pelo caso de teste, através da definição de thread groups, que serãoexecutados como os usuários utilizadores da aplicação e na ação de cada usuário. Por sua vez, a região verde é possíbilita definir os parâmetros que serão
  • 39. 39utilizados por cada ação. Por exemplo, quantas vezes cada ação será executada.Isso facilita a criação do plano de teste. Com o JMeter, também é possível fazertestes em páginas web, porém, como dito anteriormente, ele não executa o códigoJavaScript. Figura 7 – Interface gráfica da ferramenta de teste de carga O JMeter também é desenvolvido em Java, e também pode ser invocadoatravés de um script de automação, como mostra a Figura 8. Para invocá-lo, deve-seinformar o caminho para o diretório-raiz da ferramenta, o plano de teste a serutilizado e onde deve ser salvo o arquivo de saída. É possível, ainda, indicar aquantidade de usuários que executará a rotina e quantas vezes ela será executada.Para gerar o plano de teste, é necessário executar a ferramenta através da interfacegráfica, criar os passos a serem executados e salvar o plano.
  • 40. 40 Figura 8 – Utilização da ferramenta de teste de carga em um script2.3.6 Jenkins A integração contínua tornou-se muito importante no mercado dedesenvolvimento de software e isso, provavelmente, ocorreu devido ao grandeimpacto causado pelas metodologias ágeis, pois ela garante que todo o sistema teráum mínimo de funcionamento a cada build, mesmo que a equipe seja grande ediversas partes do código sejam alteradas ao mesmo tempo (GUERRA, 2008). O build pode ser executado de diversas formas a qualquer instante,através de solicitação do usuário, via configuração para executar periodicamente ouatravés de configuração para executar a cada commit. A grande vantagem da integração continua está na resposta imediata.Quando se dá a execução do build e algo quebra, a compilação ou um teste, aequipe toma conhecimento imediatamente, através de e-mail ou de um alerta. Aintegração contínua é uma forma de trazer mais segurança em relação a mudanças,
  • 41. 41pois caso algo errado ocorra, a equipe será devidamente avisada. O Jenkins é uma ferramenta de integração contínua, escrito em Java,capaz de ser executado em servlet containers, como Tomcat, Jetty, entre outros. Elepossui suporte para várias ferramentas de SCM, incluindo CVS, SVN e Git, e podeexecutar o ANT e o Maven. O Jenkins é a nova versão do Hudson. No estudo de caso, esta ferramenta será responsável por criar o ambienteintegrado de teste, onde haverá um ambiente que executa a chamada do script deautomação e que será responsável por exibir os relatórios da execução de cada tipode teste. Uma grande vantagem desta ferramenta é a existência de diversos plug-ins, que ampliam as capacidades da ferramenta e permitem a geração de relatóriosgráficos para cada teste. Com o relatório gráfico, é possível verificar o problemarelatado e encontrar a linha no código fonte onde o problema ocorre. Ao entrar na tela inicial do Jenkins, deve ser feita a configuração para queele possa exibir os relatórios desejados. Para isso, os plug-ins correspondentesdevem ser instalados. Como as ferramentas em estudo são Checkstyle, PMD,Findbugs, JUnit e JMeter, os seus respectivos plug-ins serão instalados, conformemostra a Figura 9. (a) (b)
  • 42. 42 (c)Figura 9 – Fluxo de onde ir para instalar os plug-ins: Tela inicial do jenkins (a), como acessar a lista de plug-ins (b), lista de plug-ins disponíveis (c).2.4 Conclusões As ferramentas apresentadas, de forma geral, são utilizadasconcomitantemente, de modo a compor um ambiente integrado de testeautomatizado. Embora existam ferramentas de mesma categoria, como checkstyle,Findbugs e PMD, os objetivos destas são diferentes. Enquanto a primeira verifica seo código atende a padrões de codificação, a segunda analisa padrões de erros esugere otimizações no código, e a última verifica outros padrões de erros e decodificação, sugerindo uma “limpeza” no código, através da remoção de códigos nãoutilizados. Para ilustrar melhor, a Tabela 1 mostra de forma resumida a diferençaentre estas ferramentas.
  • 43. 43 Tabela 1 – Tabela comparativa entre as ferramentas de análise estáticaCARACTERÍSTICA CHECKSTYLE FINDBUGS PMDComentário de código Sim Não NãoBloco catch vazio Sim Não SimAtribuição em subexpressão Não Não SimConexão com banco de dados Não Sim Simnão encerradaNão utilização de operador Não Sim Simlógico de curto-circuitoNome de variável Sim, verifica se Não Sim, verifica se inicia com letra inicia com letra minúscula minúscula e se tem mais de 4 caracteresUtilização de comparação em Sim Sim Simvez de método de comparaçãoIgnorar valor de retorno Não Sim Não No próximo capítulo, será apresentado o estudo de caso com o ambientemontado, mostrando o funcionamento das ferramentas no ambiente integrado.
  • 44. 443 ESTUDO DE CASO O estudo de caso visa apresentar o funcionamento das ferramentas noque se refere à execução dos testes de sistemas. Ele apresenta alguns exemplos detestes executados sobre uma aplicação existente, rodando testes com as seguintesferramentas checkstyle, findbugs e pmd, para análise estática de código, testesunitários com o JUnit; teste de carga e desempenho com o JMeter em um ambientegráfico que executa um script Ant e apresenta o relatório de cada tipo de teste. O objeto de estudo consiste em configurar um projeto no Jenkins, aplicaras ferramentas, configurar os relatórios e analisar os resultados.3.1 Especificação Como o foco do trabalho é apresentar um ambiente integrado de testeautomatizado, testes estes baseados em técnicas caixa-branca e utilizando aferramenta de integração contínua Jenkins, foi utilizada a aplicação para executar ostestes, simulando a utilização deste ambiente integrado em um ambiente dedesenvolvimento real. Com o intuito de demonstrar o funcionamento das ferramentas, e porconsequência do ambiente, foi escolhido um cenário de execução onde serãoexecutados os testes. O cenário consiste em uma aplicação Web de um sistema degerenciamento de eventos, que possui uma tela de cadastros de eventos, outra paracriação de dormitórios, outra de alocação de pessoas nos dormitórios, um formuláriopara efetuar o recebimento de pagamento e opções para geração de relatórios, alémda tela de login, conforme mostra a Figura 10, que sofrerá as execuções dasferramentas de análise estática que indicarão os pontos de falha ou melhoria, dostestes unitários e do teste de desempenho.
  • 45. 45 (a) (b) (c) (d) Figura 10 – Contendo algumas telas do sistema Web: Tela de login de acesso aosistema (a), tela de cadastro de evento (b), tela de cadastro de dormitório (c) e a tela de cadastro de participante (d). Para realizar o cadastro de evento ou de dormitório, o usuário deve serum administrador. Esta verificação é realizada na camada de controle. Já pararealizar o cadastro de participante não se faz necessário que seja um administrador.A validação dos dados é realizada na cama de modelo. O checkstyle foi configurado para verificar regras que se atenhamsomente a convenção de codificação da linguagem. Já o Findbugs e o PMD foramconfigurados para executarem as regras padrões, executadas quando não se éexplicitada nenhuma configuração adicional, e serão configurados para executaremcom esforço máximo, coletando a maior quantidade de falhas possível. Finalmente, após as execuções, serão gerados relatórios paraapresentarem os resultados das execuções.
  • 46. 463.2 Configuração do ambiente Inicialmente será necessário alterar o script de automação de build doprojeto para configurar as ferramentas para exportarem seus resultados comoarquivo XML. Esta configuração se faz necessária para que os plug-ins dasferramentas consigam interpretá-los e exibi-los de forma gráfica. Após isso, todas asoutras atividades serão realizadas na ferramenta de integração contínua. Portanto, o próximo passo é configurar o projeto dentro da ferramenta,atribuindo-lhe um nome e escolhendo o tipo do projeto; para o estudo de caso, seráescolhido o tipo de projeto free-style. Este tipo de projeto contém alguns elementos que facilitam a sua criaçãoe configuração, em que um dos elementos consiste em uma configuração queindique a ferramenta SCM, como CVS (sistema de versões concorrentes), ou SVN(Apache Subversion), que mantém o código fonte. Ferramentas SCM facilitam agerência de configuração através do versionamento do software; outra configuraçãoé responsável por controlar quando a ferramenta irá executar uma construção, pois,em certos casos, é interessante que a construção seja executada em determinadoperíodo, como ocorre em alguns frameworks de mercado que possuem a construçãonoturna (nightly build), como o Hibernate ou JBoss, ou a cada alteração no código.Existe uma configuração responsável por indicar quais scripts são responsáveis pelaconstrução, que será responsável por orquestrar a construção; há uma configuraçãoque possibilita o armazenamento de fingerprints, que são os artefatos que devemser armazenados e vinculados à versão da construção, como resultados dos testes,documentação, resultado dos testes, executáveis, entre outros. Também é possívelconfigurar para notificar, através de e-mail, algumas pessoas com o resultado daconstrução, isso facilita o acompanhamento do projeto por parte do gerente ou dosdesenvolvedores. Após isso, será possível configurar, dentre outras características, ospassos a serem executados durante e após a execução do script. A apresentaçãodos relatórios é uma ação pós-construção, pois é na construção que os testes sãoexecutados e os resultados são gerados e exportados para arquivo do tipo XML.
  • 47. 47 Após a execução da construção, nota-se uma alteração na interface, queagora possibilita ver os resultados das ferramentas. A partir das novas opções épossível visualizar os resultados através de um relatório gráfico que é alterado deacordo com as construções executadas. É possível visualizar a categoria de erro, opacote, a unidade e o trecho de código que contém o erro encontrado. Através do relatório, é possível acompanhar o progresso, regresso, ou aconstância do projeto uma vez que o gráfico se altera a cada construção realizada.Também é possível navegar pelo relatório com o intuito de encontrar o pacote, aunidade ou a linha de código da unidade em que a falha ocorreu. Após selecionar orelatório desejado, clicando no gráfico ou nas opções que aparecem à esquerda,serão listados os pacotes contendo as unidades que possuem aquela categoria dedefeito ou falha e, após selecionar o pacote, serão exibidas as unidades e, aoselecionar a unidade, serão exibidas as linhas que possuem a falha, conformemostra a Figura 11. (a) (b) (c) (d)
  • 48. 48 (e) (f)Figura 11 – Fluxo de configuração de um projeto: Tela inicial do Jenkins,destacando a opção que habilita a criação de novo projeto (a), tela de configuraçãodo nome e do tipo do projeto (b), configuração dos relatórios das ferramentas (c),novas opções habilitadas após a execução e geração dos relatórios (d),apresentação dos pacotes que possuem certas categorias de erro (e), e unidade quepossui os erros analisados (f). Para os testes realizados pelo JUnit, o resultado é apresentado quandoocorre uma falha. Os resultados são apresentados textualmente e o status do build émarcado como instável. A indicação é o ícone amarelo ao lado do nome do projeto.3.3 Análise dos resultados De acordo com os resultados obtidos na execução do cenário proposto,observou-se que as ferramentas de análise estática apresentam o resultadoesperado, desde a execução dos testes até a apresentação dos resultados, com apossibilidade de uma checagem configurável. Esta configuração pode ser geral oupor projeto, e a invocação desta configuração fica a cargo de cada ferramenta,através do script de automação. A criação e a manutenção do ambiente também sãofacilitadas graças ao Jenkins, que automatiza estes processos. A facilidade deacesso à informação e de compreensão desta também são auxiliadas pelos plug-insda ferramenta de integração contínua. Há muitas vantagens na utilização do Jenkins como ferramenta deintegração contínua, como a vantagem da facilidade e disponibilidade de acesso ede compreensão da informação, pois a ferramenta de integração contínua procuraagrupar por ferramenta de teste, grupo de erro e pacote de unidades, e exibir um
  • 49. 49gráfico em área 2D, de modo a tornar mais claro e objetivo os resultados dasexecuções dos testes. Outra vantagem é a capacidade de customizar ocomportamento da ferramenta, fazendo com que seja possível adequar tanto oprocesso de desenvolvimento existente quanto a ferramenta em si. Por outro lado, existem cenários em que o ambiente não apresentou oresultado esperado, pois eram cenários que estavam desenvolvidos de modo a nãofacilitar, ou até mesmo impedir, o desenvolvimento de testes unitários, devido ao altograu de acoplamento e à baixa coesão. No estudo de caso, estava bastantecomplicado simular um cenário de cadastro de evento ou de dormitório uma vez queas validações estavam espalhadas pelo código quando deveriam estar agrupadas. Aboa prática de desenvolvimento afirma que não é aconselhável realizar validaçõesna camada de modelo. Também foram detectados alguns problemas, como o plug-in para o JUnitapresentar, ocasionalmente, uma falha que impedia a geração do relatório gráfico,fazendo com que a saída fosse simplesmente textual, embora seja possível rastrearo ponto de falha. Portanto, em linhas gerais, pode-se afirmar que o ambiente integrado deteste possui boa aplicabilidade, devido à sua facilidade de instalação, configuração emanutenção. As ferramentas, isoladamente, auxiliam no desenvolvimento e namanutenção do software, e também servem de alerta para pontos onde existemerros em potencial. Devido à integração das ferramentas com uma IDE, é possível, também,não gerar um processo extra, evitando adicionar trabalho à equipe dedesenvolvimento, mantendo, assim, esta focada em seu serviço. Em longo prazo, aequipe de desenvolvimento tratará de evolução do software, reduzindo o retrabalhoe, consequentemente, o custo do projeto.
  • 50. 50 CONCLUSÃO Neste trabalho são demonstradas as fases de criação, utilização eaplicação de um ambiente integrado de teste automatizado, através de ferramentade análise estática de código, como as ferramentas Checkstyle, Findbugs e PMD,teste unitário com JUnit e teste de desempenho com o JMeter. Neste caso, foiabordada desde a invocação de cada chamada através de um script de automação,passando pela configuração de cada ferramenta, até a exportação dos resultados,tudo em um ambiente integrado de teste. Inicialmente é apresentada a visão geral de testes, mostrando o seuplanejamento, o plano de execução, a execução, a análise dos resultados e oencerramento do processo. Em seguida, são apresentadas as técnicas de teste,mostrando as principais características de cada uma. Depois são ilustradas as fasesde teste, e, por fim, é definida uma proposta de automação, pois a execução manualdestes testes levaria muito tempo. A ideia é que a execução automatizada é maisrápida e evolui juntamente com o software, obtendo ganho no tempo de resposta eexecutando os mesmos testes. Adiante, é apresentado o contexto dos testes automatizados, mostrandoque automatizar um teste é uma decisão de projeto que deve ser encarada deacordo com a necessidade do que se espera do produto. São apresentadas técnicasde revisão e categorias de ferramentas, onde cada ferramenta apresentada possuiuma gama de configurações e realizam análises estáticas sobre o código, auxiliandoo desenvolvimento e a manutenção pela equipe de desenvolvimento. As ferramentasde testes unitários, que seriam responsáveis por testar os fluxos do sistema deforma rápida e efetiva. Por fim, é apresentada uma ferramenta que integra todas asoutras apresentadas em um ambiente limpo e configurável, sendo responsável porrealizar as construções do produto e apresentar os resultados de forma clara eobjetiva. Em seguida, é demonstrado, através de um estudo de caso, a criação e aconfiguração do ambiente integrado, mostrado as vantagens e desvantagens doambiente. O objetivo é apresentar e avaliar o funcionamento e a execução dos
  • 51. 51testes em um dado cenário, e apresentar os resultados de modo a acompanhar aevolução do software em relação ao tempo de desenvolvimento. Diante da análise efetuada sobre as ferramentas levantadas no estudo, oJenkins destacou-se por oferecer integração com outras ferramentas através deplug-ins, facilitando a coleta e apresentação dos resultados. Além disso, tambémexiste a facilidade de configuração do projeto e de configuração da utilização dasferramentas. Como parte integrante do ambiente de teste de desenvolvimento, oJMeter se destaca por facilitar o teste de desempenho que, em um ambiente deteste manual, torna-se muito difícil, ou até mesmo impossível. Portanto, a criação de um ambiente integrado de teste é essencial paraprojetos de médio e grande porte uma vez que nele haverá informações necessáriaspara auxiliar no processo de tomada de decisão quanto ao projeto, mostrando deforma clara o seu andamento, apresentando pontos que necessitam de um cuidadoespecial, por exemplo, trechos que demoram a ser executados, ou que rapidamentechegam a uma situação de demora. Vale ressaltar que não é possível mensurar o valor economizado emvirtude da utilização dos testes. Dentre as práticas comuns, está a de avaliarcomparativamente com outros projetos semelhantes, porém em que não foramadotadas rotinas automatizadas de teste. A partir deste trabalho, podem ser originados trabalho futuros, como o usode ferramentas de captura e repetição de eventos sobre a interface gráfica, como,por exemplo, o Selenium, e a realização destes testes, simulando o acesso demúltiplos usuários através do JMeter, ou o desenvolvimento de testes paradispositivos móveis, abordando o Selenium for Android.
  • 52. 52 REFERÊNCIASALMEIDA, Carla. Introdução teste de Software. Disponível em:<http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx>. Acesso em: 03 ago. 2012.BERNARDO, Paulo Cheque. KON, Fabio. A Importância dos TestesAutomatizados. (Engenharia de Software Magazine, p. 1-7, 2008).BARTIE, Alexandre. Processo de Teste de Software – Parte 01. Disponível em:<http://imasters.com.br/artigo/6102/des_de_software/processo_de_teste_de_software_-_parte_01>. Acesso em: 01 ago. 2012.CAETANO, Cristiano. Automação e Gerenciamento de Testes. São Paulo: DigitalWorks.CAETANO, Cristiano. Introdução à Automação de Testes Funcionais. Disponívelem: <http://www.testexpert.com.br/?q=node/178>. Acesso em: 27 set. 2012.CUNHA, Simone. Ambientes de Teste. Disponível em:<http://testwarequality.blogspot.com.br/p/ambientes-de-testes.html>. Acesso em: 19set. 2012.GUERRA, Cauê. Integração Contínua e o processo Agile. Disponível em:<http://blog.caelum.com.br/integracao-continua/>. Acesso em: 16 out. 2012.PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo: PearsonEducation do Brasil, p. 315-347, 2005.MALDONADO, Jose Carlos. BARBOSA, Ellen Francine. VINCENZI, Auri MarceloRizzo. DELAMARO, Marcio Eduardo. SOUZA, Simone do Rocio Senger de. JINO,Marcio. Introdução ao Teste de Software. (Universidade de São Paulo, p.1-49,2006).MORAIS, Lenildo. MATOS, Renata. Transição de Testes Tradicionais para Ágeis:Uma Experiência Prática.MYERS, Glenford J. The art of software testing. (Corey Sandler, p. 5-20, 2004).NOGUEIRA, Elias. Automação de Teste - Decisão por Automatizar. Disponívelem: <http://sembugs.blogspot.com.br/2010/04/automacao-decisao-por-automatizar.html>. Acesso em: 8 abr. 2010.TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 3 ed. São Paulo:Prentice Hall, 2011. p. 50-105.
  • 53. 53TERRA, Ricardo. BIGONHA, Roberto S. Ferramentas para Análise Estática deCódigos Java (Departamento de Ciência da Computação - UFMG, p. 1-6, 2008).SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: PearsonEducation, 2007. Cap. 22, p. 339-353.STAA, Arndt von; JUNIOR, Gilberto Pavoni. Retrabalho corrói eficiência do testede Software, Brasil 2011. Disponível em <http://itweb.com.br/48984/retrabalho-corroi-eficiencia-do-teste-de-software/> Acesso 04/2012.