Ambiente integrado de teste automatizado

FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA – UNIFOR
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
CURSO CIÊNCIA DA COMPUTAÇÃO

AMBIENTE INTEGRADO DE TESTE AUTOMATIZADO

VIRGILIO ROCHA XIMENES

Fortaleza – Ceará
2012

VIRGILIO ROCHA XIMENES


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


Virgílio Rocha Ximenes

PARECER: ______________________________

DATA: ___/___/____

BANCA EXAMINADORA:

________________________________________________
Rafael Garcia Barbosa, MSc.

________________________________________________
Alex Silveira da Costa, MSc.

4

AGRADECIMENTOS

Inicialmente, agradeço a Deus, pelo amor, pelas oportunidades
concedidas, pela esperança, pelo conforto, pela vida, e por ter me dado condições
físicas e emocionais para chegar até aqui, pois posso dizer as palavras que estão
nas sagradas escrituras: “Até aqui nos ajudou o Senhor”.

Agradeço aos meus pais, pois, se não fossem eles, eu não estaria aqui, e
pelo carinho e dedicação que nunca deixaram faltar. A minha mãe, pela cobrança e
pela educação que moldaram meu caráter. A meu pai, pela sabedoria e paciência
que 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, pelo
conhecimento compartilhado, pela oportunidade e orientação neste estudo.

Agradeço a todos os professores da UNIFOR, em especial ao Roberto
Façanha, a Sandra e ao Fernando Parente, pelo conhecimento transmitido, pela
paciência e atenção dispensada ao longo dos semestres.

Agradeço a todos os meus amigos, Vitor Rifane, Rodrigo Gato, Marilia
Feitoza, Leandro Almeida e tantos outros, pela amizade, pelas brincadeiras, pelas
conversas, pelo apoio e pelas saídas para lanchar no Baixinho.

5

RESUMO

Estudos revelam que o retrabalho é responsável direto pelo atraso e por grande
parte dos custos envolvidos em um projeto. A principal maneira de reduzir o
retrabalho é através dos testes, porém estes são executados manualmente. Este
trabalho objetiva apresentar um ambiente com algumas ferramentas integradas com
o objetivo de automatizar a disciplina de teste. O foco do trabalho é a ferramenta
Jenkins, que é responsável pela criação e manutenção do ambiente integrado de
teste. Abordam-se as principais características da disciplina de testes, bem como
sua automação, suas vantagens e desvantagens. E, por fim, faz-se um estudo de
caso em que se pode aplicar a automação de testes em desenvolvimento de
aplicações. A linguagem de programação alvo é a linguagem Java, por ser a
linguagem adotada pela faculdade.

6

ABSTRACT

Studies reveal that the rework is directly responsible for the delay and for much of the
costs involved in a project. The main way to reduce rework is through tests, but they
are executed manually. This study presents an environment with some integrated
tools with the goal of automating the test discipline. The focus of the work is the tool
Jenkins, who is responsible for the creation and maintenance of the integrated test
environment. It addresses the key features of the discipline of testing and its
automation, advantages and disadvantages. In the end a study case in which one
can apply the automated testing applications under development. The target
programming language is Java, because it is the language adopted by the college.

7

LISTA DE ABREVIATURAS
API – 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 Subversion

TDD – 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

LISTA DE FIGURAS
Figura 1 – Modelo em “V” do processo de testes …………………………………… 14

Figura 2 – Grafo de complexidade ciclomática de um software …………………… 18

Figura 3 – Utilização da ferramenta de análise estática ……………………………. 32



Figura 6 – Utilização da ferramenta de teste unitário em um script ……………….. 37

Figura 7 – Interface gráfica da ferramenta de teste de carga ……………………… 39

Figura 8 – Utilização da ferramenta de teste de carga em um script ……………… 40

Figura 9 – Realização da implantação do ambiente automatizado …………………42

Figura 10 – Telas do sistema que sofrerá a execução das ferramentas de teste… 45

Figura 11 – Configuração do ambiente e visualização dos resultados…………….. 48

9

LISTA DE TABELAS
Tabela 1 – Tabela comparativa entre as ferramentas de análise estática…………. 43

10

SUMÁRIO
INTRODUÇÃO .......................................................................................................... 11
1. 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 ...................................................................................... 23
2 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....................................................................................................... 42
3 ESTUDO DE CASO ............................................................................................... 44
3.1 Especificação ................................................................................................... 44
3.2 Configuração do ambiente ............................................................................... 46
3.3 Análise dos resultados ..................................................................................... 48
CONCLUSÃO............................................................................................................ 50
REFERÊNCIAS ......................................................................................................... 52

11

INTRODUÇÃO

Um estudo realizado na PUC-Rio mostra que um dos responsáveis pelos
atrasos nos projetos de software é o retrabalho, sendo, também, responsável por
45% dos custos envolvidos em um projeto, e o custo de um retrabalho aumenta de
acordo com a fase do projeto. O retrabalho é caracterizado por mudar o foco dos
profissionais de produzir uma nova funcionalidade para realizar correções de
defeitos em funcionalidades que foram, ou não, já homologadas (STAA, 2011).

A maneira mais eficaz de reduzir o retrabalho é através da execução
sistemática de testes. Entretanto, muitas vezes a qualidade é assegurada através de
testes 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 ser
muito cansativo executar um vasto conjunto destes testes. Esta abordagem de
execução manual dos testes traz consigo vários problemas, pois, com a crescente
complexidade do software, alguns testes ou cenários de teste deixam de ser
executados, facilitando o surgimento de erros de regressão. O erro de regressão
surge quando uma funcionalidade que estava funcionando deixa de funcionar após
alguma alteração no software.

Autores indicam, exaustivamente, o uso de ferramentas de automação de
teste para manter a viabilidade de execução dos testes e o aumento de
produtividade. Isso advém do fato de que, com o tempo, aumenta-se a quantidade
de casos de testes e, sem o uso de uma ferramenta adequada, torna-se impossível
a 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, para
determinados casos, o software continue funcionando corretamente. Com a
execução automática dos testes, será possível reduzir não só o retrabalho, mas
também o custo envolvido em um projeto, pois uma vez que a rotina de teste seja
escrita, poderá ser reutilizada quantas vezes forem necessárias.

O teste automatizado é executado mais rápido, e com a evolução do
software 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

não é mais na automática. Existem ferramentas onde é possível realizar testes em
vá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 gradualmente
com as iterações de desenvolvimento (MYERS, 2004). Para esta finalidade, existem
os testes de regressão, que permitem quantificar a evolução da qualidade do
software, mantendo e executando testes realizados anteriormente.

O objetivo geral deste trabalho é apresentar diversas ferramentas
utilizadas em testes automatizados, de modo que estas venham a compor um
ambiente 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 vantagens
dos testes automatizados, ferramentas que realizam os diversos tipos de testes e
um ambiente integrado de teste composto pelas ferramentas apresentadas.

Este trabalho está organizado da seguinte forma: no primeiro capítulo
será apresentada uma visão geral da área de teste, bem como as técnicas e as
principais fases. O capítulo 2 trata da automação de teste, através da apresentação
do contexto da automação, das técnicas de revisão e de ferramentas que irão
compor o ambiente. No último capítulo, será apresentado um estudo de caso, onde
será apresentada a montagem e a criação do ambiente integrado de teste, bem
como a execução dos testes e a visualização dos relatórios gerados pelas próprias
ferramentas. No final, serão apresentadas as conclusões, indicando algumas das
vantagens na utilização de um ambiente integrado.

13

1. TESTE DE SOFTWARE

1.1 Visão geral

O software tem feito cada vez mais parte da vida das pessoas, através de
computadores, tablets e, até mesmo, de celulares. Com isso, as pessoas têm ficado
cada vez mais exigentes. Portanto, o desafio é desenvolver software com qualidade
e segurança em um curto período de tempo, mantendo um baixo custo, além de
atender os requisitos do produto.

A atividade de teste vem exatamente para isso, pois, encontrar um bug no
início do desenvolvimento é menos custoso para o projeto, além de tornar o software
mais confiável uma vez que um software testado possui uma confiabilidade maior.
Com esta qualidade agregada devido ao teste, pode-se, também, fazer uma
medição desta qualidade em relação aos erros encontrados (ALMEIDA, 2012).

De acordo com Myers (2004), existe uma psicologia por detrás dos testes
que afirma que os programadores se mostram resistentes aos testes, pois afirmam
que o teste serve apenas para mostrar que não existem erros no programa, ou que o
propósito do teste é mostrar que o programa atende às funcionalidades
corretamente, ou que o teste é o processo de estabelecer a confiança de que o
programa faz aquilo que foi feito para fazer. Porém, se o teste for elaborado sob a
perspectiva de que o programa não possui falhas, este será elaborado de modo a
atingir a sua meta que é a de não encontrar falhas. Por outro lado, se houver a
crença de que o programa possui falhas, a ação será de encontrar o máximo de
erros possíveis ou não conformidades. Portanto, a definição de teste que o testador
deve possuir em mente é a de que o teste é o processo de executar um programa
com a intenção de encontrar erros. E compreender bem a definição de teste pode
fazer 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 do
desenvolvimento, pois, no desenvolvimento, a primeira etapa é a especificação de
requisitos, e a última é a codificação. Inicialmente são executados os testes unitários
e, por último, os de aceitação, onde incidem respectivamente em cada um. Portanto,

14

o primeiro teste a ser executado é sobre o que foi elaborado por último, e o último
teste 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 consistem
em: Planejamento dos testes, onde se define uma proposta de teste baseada no
prazo, no custo e na qualidade esperada; especificação dos testes, onde se
identifica os casos de testes que deverão ser construídos e modificados de acordo
com as solicitações do cliente; modelagem dos testes, onde se faz a identificação
de todos os elementos necessários para a implementação de cada caso de teste
especificado; preparação do ambiente, etapa que visa disponibilizar um ambiente
de teste pronto para rodar os testes planejados nas etapas anteriores, sem
intervençã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, de
modo a garantir a conformidade do produto com os requisitos; análise dos
resultados, etapa em que é feito um balanço de acordo com os resultados dos
testes, e, por fim, o encerramento do processo, etapa em que é feito um
fechamento do processo, comparando os resultados alcançados com o esperado.

15

A etapa de planejamento dos testes é uma etapa que contém
características mais gerenciais do que técnicas, e deve ser subdivida nas seguintes
etapas: estudo do projeto, avaliação de impacto, análise de esforço, definição de
possíveis cenários e aprovação do planejamento. O estudo do projeto é uma
avaliação realizada sobre o que se espera do software a ser construído bem como
os riscos do projeto e os respectivos impactos, avaliando, também, os requisitos sob
a perspectiva de custo, prazo e esforço. A avaliação de impacto pode ser vista como
a avaliação das exigências de criação e modificação de casos de teste, adequações
ao processo de teste, aquisição e adequação às ferramentas de teste, além da
modificaçã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, o
esforç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ção
das propostas aceitas.

Após o planejamento dos testes, há a especificação dos testes, onde
há um estudo dos requisitos, a identificação dos casos de testes e o refinamento do
projeto de teste. O estudo dos requisitos busca avaliar os requisitos funcionais e não
funcionais, identificando as inconsistências e estabelecendo o aceite dos
documentos. Na subetapa de identificação dos casos de testes, identifica-se cada
requisito e seu respectivo caso de uso, identificando, em cada caso de uso, seus
fluxos (básico, alternativo e exceção) e os casos de testes que irão incidir sobre
cada fluxo. Paralelamente, a arquitetura dos testes deve ser especificada, avaliando
adequações na automação para a preparação do ambiente, da execução dos testes
e da análise dos resultados. Após isso, o refinamento do projeto de teste serve para
reavaliar as estimativas iniciais de custo, prazo e esforço, reavaliar riscos do projeto
e estabelecer um cronograma detalhado baseado no cronograma-macro.

Depois do planejamento dos testes, vem a atividade de modelagem de
testes, que é o momento de criação dos roteiros de testes, incluindo procedimentos
para iniciar, executar, validar e realizar uma limpeza após a execução do caso de
teste, além de detalhar a massa de entrada de dados, identificando opções
parametrizáveis para gerar testes variados, mantendo a rastreabilidade entre o caso
de teste e a massa de dados de entrada. A massa de dados de saída também deve

16

ser detalhada através da identificação dos pontos de validação, da análise dos
dados, 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 de
execução dos testes, que inclui a especificação das configurações necessárias para
a execução dos testes.

Em seguida, vem a preparação do ambiente, que é feita através das
configurações especificadas e informações geradas, além, é claro, da instalação da
versão do software a ser testado.

Neste momento, tem-se a execução dos testes, que é feita pela
execução dos testes progressivos, que são disparados em funcionalidades
disponibilizadas a cada nova versão, e os testes regressivos, que são executados
sobre funcionalidades que estavam homologadas nas versões anteriores. Além da
execução, propriamente dita, tem-se a identificação de não conformidades com os
requisitos, tanto para os testes progressivos quanto para os regressivos.

Após a execução, há a análise dos resultados, que vem para revisar os
resultados em não conformidades levantados pela execução dos testes, revisar
testes progressivos em conformidade, atualizar o baseline, formalizar os defeitos
encontrados, através do isolamento de cada caso de teste que apontou como
resultado uma não conformidade da coleta de evidências que comprovam a não
conformidade, do detalhamento das condições que indicam a não conformidade, da
classificação de cada defeito encontrado.

Então, finalmente, tem-se o encerramento do processo, que é feito pela
extração de indicadores, como, por exemplo, quantidade de erros por funcionalidade
ou, até mesmo, um gráfico apresentando a evolução ou regressão do software, pelo
resumo 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ível
testar software em diferentes paradigmas, embora o paradigma orientado a objeto
venha a facilitar o desenvolvimento desta atividade. Como dito anteriormente, o

17

objetivo 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 que
devem ser observados constantemente. Testar é o processo de executar um
programa com a intenção de encontrar erros. Um bom caso de teste é aquele que
tem alta probabilidade de encontrar um erro ainda não encontrado; um teste bem
sucedido é 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 o
comportamento externo do sistema. Para usar esta metodologia, o testador deve ver
o software, literalmente, como uma caixa preta. Sua meta é ser completamente
despreocupado sobre o comportamento interno e a estrutura do programa. Deve se
concentrar, portanto, em encontrar circunstâncias em que o programa não se
comporte de acordo com as especificações (MYERS, 2004).

Segundo Pressman (2005), este teste tem por objetivo encontrar erros
das seguintes categorias: funções incorretas ou omitidas, erros de interface, erros de
estrutura de dados ou de acesso à base externa, erros de comportamento ou
desempenho, erros de iniciação ou de término.

Numa situação ideal, todas as possibilidades são testadas, mas, na
maioria dos casos, isso é muito difícil, ou quase impossível. Portanto quanto mais
entradas forem testadas, mais rico será o teste. A abordagem mais utilizada, na
prá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ão
derivados da especificação, e esta, por sua vez, pode estar ambígua em relação ao
sistema produzido, e como resultado as entradas especificadas podem não ser as
mesmas aceitas para o teste.

18

Apesar de necessário, esse tipo de teste é insuficiente para identificar
certos riscos em um projeto de software.

1.2.2 Teste caixa-branca

Complementar ao teste caixa-preta, tem-se o teste caixa-branca, ou teste
estrutural, analisando diretamente o código-fonte para analisar aspectos como: teste
de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos ou
complexidade ciclomática.

Segundo Myers (2004), o objetivo é fazer com que cada declaração no
programa seja executada pelo menos uma vez. Se o testador executar, via caso de
teste, todos os possíveis caminhos de controle de fluxo pelo programa, então o
programa será completamente testado. Porém, se considerarmos um programa
comum, com uma estrutura de repetição, que repete vinte vezes um dado conjunto
de instruções e, dentro desse conjunto de instruções, temos algumas estruturas de
controle 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ível
caminho.

Figura 2 – Grafo de complexidade ciclomática de um software

19

Uma das possíveis desvantagens do uso deste tipo de teste é que nem
sempre os testes que envolvem as estruturas de um sistema vislumbram as
funcionalidades e iterações esperadas do sistema, o que torna este tipo de teste
desnecessário ou, até mesmo, inviável. Outra desvantagem é a inserção de erros
atravé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 de
desenvolver 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 que
serã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 bastante
utilizada em teste de integração.

A atual implementação da metodologia caixa-cinza é altamente
dependente do uso de uma aplicação utilizada para executar e validar o teste em
questão, o depurador. Estudos confirmam que esta metodologia pode ser aplicada
em tempo real usando o software executando na plataforma de destino, o que
expande as capacidades desta metodologia, por incluir não apenas o caminho para
cobertura de verificação, mas também o melhor e o pior caso. Também possibilita
verificar e validar requisitos de performance, requisitos funcionais e estruturais em
um único caso de teste com o mesmo formato usado para verificar e validar
requisitos funcionais (COULTER, 2001).

1.2.4 Técnicas não funcionais

Estas técnicas são chamadas de não funcionais, não por estarem
vinculadas a funcionalidades do sistema, mas sim por estarem vinculadas a
restrições de usabilidade. Portanto, são técnicas que avaliam questões como
segurança, desempenho, usabilidade, entre outros aspectos.

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 determinados
componentes continuam funcionando após alguma alteração; teste de desempenho,
para verificar se o desempenho do software está dentro de um limite aceitável dentro
de determinado cenário; teste de stress, para analisar o comportamento do sistema
em condições anormais de demanda. Para verificar se um software é adequado ao
uso, tem-se o teste de usabilidade; ou para verificar seu funcionamento a partir da
liberação do produto para pequenos grupos de usuários trabalhando em um
ambiente 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-se
o módulo a ser testado com as novas funcionalidades e testa-o. Por outro lado, na
abordagem bottom-up, testa-se primeiro as unidades mais básicas, até testar o
módulo. Devido à dificuldade de se realizar testes na abordagem top-down, a
abordagem bottom-up é a mais escolhida.

Como visto anteriormente, existem diversos tipos de testes, e cada tipo de
teste tem um foco diferente, para testar características diferentes. Serão abordados
os seguintes tipos de testes: teste unitário, teste de integração, teste de sistema e
teste de aceitação.

1.3.1 Fase de teste unitário

Segundo Pressman (2005), o teste unitário, ou de unidade, focaliza o
esforço de verificação na menor unidade de projeto do software. A complexidade
dos testes e dos erros descobertos é reduzida, por conta da limitação do escopo
estabelecido para o teste. Este tipo de teste enfoca a lógica interna de
processamento 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

branca, pois a estrutura de dados local é examinada para garantir que os dados
armazenados temporariamente mantenham sua integridade durante todo o algoritmo
testado. Todos os caminhos independentes ao longo da estrutura de controle são
analisados, para garantir que todos os comandos da unidade tenham sido
executados pelo menos uma vez. As condições limites também são testadas, para
garantir que a unidade trabalhe adequadamente nos limiares estabelecidos. Testes
de fluxo de dados são executados inicialmente, pois se os dados não entram e saem
corretamente, 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 teste
unitário, verificamos que as unidades estão funcionando individualmente, por que
duvidar que eles não funcionem conjuntamente?” Dados podem ser perdidos através
de uma interface ou chamadas a sub-rotinas; quando combinadas, podem não
produzir o resultado esperado.

O teste de integração é a fase em que se verifica a interface entre os
componentes. As unidades devem ser integradas e testadas conjuntamente. Este
tipo de teste pode expor defeitos nas interfaces ou nas interações. O objetivo deste
teste é verificar funcionalidades, desempenho e confiabilidade. Este tipo de teste é
uma técnica sistemática para construir a arquitetura do software enquanto conduz
testes para descobrir erros associados às interfaces. Normalmente, aplica-se,
também o teste de regressão neste momento para verificar se novos erros foram
introduzidos 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 sistema
completo ou programa, pois isso seria redundante com o teste funcional. O propósito
deste teste é comparar o software com o objetivo original. O teste de sistema é o
processo de tentar demonstrar a forma como o programa não cumpre os seus
objetivos; e, por definição, este teste é impossível se não houver um conjunto de
objetivos mensuráveis para o software (MYERS, 2004).

22

Segundo Myers (2004), existem algumas categorias principais de teste de
sistema, não que todas sejam aplicáveis a todos os softwares existentes, mas que
devem ser observadas, que são: teste de instalação, onde pode ser realizado
apenas na documentação, como um exercício mental sobre a documentação,
analisando se ela é suficiente; teste de carga, que é submeter o software a uma
carga alta de dados com o intuito de mostrar que o software se torna inutilizável para
uma determinada massa de dados; teste de stress, que é submeter o software a um
volume máximo de dados em um curto espaço de tempo, ou simular o número
má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 os
usuários, são fáceis de entender e de aprender, as mensagens de erro são fáceis de
analisar e diagnosticar ou precisam de um PhD em ciências da computação; teste
de segurança, que verifica se os mecanismos de proteção incorporados ao software
irã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 sistema
integrado e requer instrumentação tanto de hardware, para verificar utilização de
recursos, quanto de software, para verificar instruções ou registrar eventos; teste de
recuperação é um teste que força o erro de diversos modos e verifica se a
recuperaçã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 o
sistema ser disponibilizado. Tem por objetivo comparar os requisitos iniciais e as
atuais necessidades do usuário final. Normalmente, são conduzidos por um grupo
restrito de usuários finais em um ambiente similar, ou idêntico, ao que será utilizado
pelo software. Não é objetivo, portanto, encontra falhas, pois estas já foram
detectadas e resolvidas; o objetivo é verificar se o software faz aquilo que lhe foi
solicitado. Nesta fase, ocorrem os processos de verificação e validação para verificar
se o que foi especificado foi entregue e se o que foi entregue atende às
expectativas.

23

1.3.5 Teste de operação

O teste de operação é a fase em que o teste é conduzido pelos
administradores 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 modo
a garantir o suporte ao negócio. Esta fase é aplicável somente a softwares que são
pró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 a
execução e repetição de um vasto conjunto de testes é uma tarefa muito
dispendiosa e cansativa. É considerado normal que os testadores não verifiquem
novamente todos os casos a cada mudança. É partindo desta ideia que surgem os
erros de software, trazendo prejuízo para as equipes de desenvolvimento que
perdem muito tempo para identificar e corrigir os erros, além do estresse causado
tanto para a equipe quanto pelo usuário final causado pelo atraso na entrega, e do
descrédito atribuído à empresa, que entrega software com qualidade duvidosa.
Como é necessário muito esforço para executar todo o conjunto de testes
manualmente, dificilmente toda a bateria de testes será executada novamente a
cada alteração, o que facilita a entrada de erros de regressão, e a tendência é que
isso se repita até que a manutenção se torne uma tarefa tão custosa que a
reconstrução comece a ser levada em consideração (BERNARDO, KON, 2008).

Com a crescente exigência por software de qualidade, padrões de
qualidades impostos pelas pessoas de um modo geral e o advento de algumas
metodologias que recomendam, ou até explicitam, o uso intensificado dos testes
automatizados, como, por exemplo, o XP e TDD, que reconhecem que prevenir
defeitos é mais fácil e barato que identificá-los e corrigi-los posteriormente, o uso de
testes automatizados vem se tornando cada vez mais frequente.

24

Testes automatizados são rotinas que exercitam funcionalidades do
software sendo testados e fazem verificações automáticas nos efeitos colaterais
obtidos. A grande vantagem é que todos os casos de teste podem ser fácil e
rapidamente repetidos a qualquer momento e com pouco esforço (BERNARDO,
KON, 2008).

Alguns testes, por exemplo, podem ser facilmente reproduzidos
automaticamente, o que manualmente seria muito difícil, ou quase impossível, por
exemplo, simular inúmeros usuários acessando o sistema, através de uma
ferramenta, é necessário, apenas, uma simples configuração, o que chega a ser
trivial. Por outro lado, nem sempre é vantajoso automatizar os testes, pois existem
situações em que o teste manual é mais adequado. Por exemplo, se a interface de
usuário for mudar consideravelmente, qualquer automação teria que ser feita
novamente, ou quando o software é muito simples que não valha a pena o uso de
testes automatizados, o teste manual continua sendo uma boa opção. Então, antes
de 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á motivo
para automatizá-lo (SANTOS, NETO, 2009).

A automação de um conjunto de teste geralmente demanda bem mais
esforço que sua execução manual, mas, quando automatizado, sua execução é
bastante simples. Assim, em algumas situações, automatizar é a melhor maneira de
economizar tempo e recurso (SANTOS, NETO, 2009).

Portanto, o teste automatizado não exclui o processo manual, pelo
contrário, entra como uma abordagem auxiliar excluindo as tarefas repetitivas ou
impraticáveis. Pois, assim como há algumas vantagens em automatizar, existem
algumas vantagens em testes manuais.

No próximo capitulo, será apresentado o contexto de automação de
testes, bem como algumas técnicas de revisão, algumas ferramentas de teste,
através da abordagem do objetivo, e como utilizar cada uma.

25

2 AUTOMAÇÃO DE TESTE

Antes de decidir automatizar um conjunto de testes, é preciso analisar o
software e quais testes serão construídos. O principal motivo para se automatizar um
teste é a necessidade de executá-lo diversas vezes. Em um caso típico, existe a
necessidade de se executar testes várias vezes. Isso normalmente é suficiente para
justificar 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 a
execução e repetição de um vasto conjunto de testes executados manualmente é
uma tarefa cara e entediante. É normal e compreensivo que os testadores não
verifiquem todos os casos de testes a cada mudança do código. E tão critico quanto
este cenário é o efeito “bola de neve”, pois, ao se realizar uma correção, dificilmente
toda 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 alguma
forma. Os testes automatizados, embora venham a exigir mais tempo para
programar, dão mais segurança na manutenção e permitem a execução a qualquer
momento (SANTOS, NETO, 2009).

A automação de um conjunto de testes, geralmente, demanda bem mais
esforço que sua execução manual, mas, depois de automatizado, a execução é
bastante simples, portanto, automatizar os testes é uma boa maneira de economizar
tempo e dinheiro. Porém, mesmo automatizando parte do processo de teste, o
Retorno de Investimento (ROI) não é imediato, pois nem sempre ele tem um retorno
em curto prazo.

2.2 Técnicas de revisão

26

Cunha (2010) afirma que as ferramentas automatizadas de teste podem
ser classificadas como ferramentas de verificação de código fonte, ferramentas
de automatização na execução dos testes e ferramentas de gerenciamento. As
ferramentas são agrupadas de acordo com a função que executam. Esta
classificação auxilia na obtenção de ferramentas apropriadas para cada tipo de
análise a ser executada sobre o software e na obtenção de métricas, que auxiliam
na 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 alguns
checklists de erros e heurísticas que identificam problemas comuns. Para alguns
erros e heurísticas é possível automatizar o processo de verificação em relação a
essas listas, o que resultou no desenvolvimento de analisadores estáticos
automatizados (SOMMERVILLE, 2007).

Os verificadores estáticos são ferramentas de software que varrem o
código fonte ou mesmo o código objeto, sem a execução do software. Este tipo de
ferramenta é utilizado para verificar se o software foi produzido dentro de padrões
estabelecidos de codificação, identificar código que não será executado, também
chamado de código morto, retirar classes de defeitos, etc. Este tipo de ferramenta
não verifica se o código realiza o que deveria realizar, portanto não verifica a
funcionalidade, analisando somente se o código está bem escrito (CUNHA, 2010).

Os verificadores estáticos de código podem verificar regras de estilo de
programação, erros ou ambos. Regras de estilo podem ajudar a prevenir certos tipos
de erros e melhorar a qualidade do software, porém as violações a essas regras não
implica, necessariamente, em um erro, mas podem ser vistas como um alerta de que
um trecho de código é crítico de alguma forma (TERRA, BIGONHA, 2008).

Portanto, é possível listar alguns benefícios da análise estática, que
seriam: encontrar erros e códigos de risco; fornecer um retorno objetivo aos
programadores 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

e a equipe de uma perspectiva diferente; e retirar certas classes de defeitos, o que
possibilita 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 softwares
específicos para controlar a execução dos testes. A comparação dos resultados
esperados com os resultados obtidos, a configuração das pré-condições de teste e
outras funções de controle e relatório de teste podem ser obtidas através destes
softwares. Normalmente, a automação de teste envolve automatizar um processo
manual já existente que utiliza um processo descritivo formal.

As ferramentas de automação têm por objetivo auxiliar diretamente na
execução dos testes; através do apoio ao processo de testes. Elas permitem reduzir
as falhas introduzidas pela intervenção humana, aumentar a produtividade a médio e
longo prazo e, principalmente, possibilita tratar a automação de testes como um
projeto, uma vez que será necessário prazo e esforço para o levantamento das
ferramentas a serem utilizadas, configuração das mesmas e adequação do processo
de desenvolvimento para utilização das ferramentas (CUNHA, 2010).

Os tipos de automação são, normalmente, agrupados de acordo com a
forma como os testes automatizados interagem com a aplicação. Os tipos são
agrupados em dois paradigmas: baseados na interface gráfica, onde os testes
interagem 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 da
aplicaçã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 automatizados
costumam 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 na
interface de programação de aplicativos (Application Programming Interface – API) e
o Test Harness.

28

Na abordagem de testes automatizados baseados na interface gráfica, os
testes 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 do
usuário enquanto ele estiver usando a aplicação. Estas ações são gravadas em um
script, que pode ser reproduzido (playback) em outro momento.

Os testes automatizados dirigidos a dados representam uma vertente dos
testes baseados na interface gráfica. Basicamente, funcionam como um mecanismo
para 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, o
que, consequentemente, diminui a complexidade e o tempo de manutenção.

Os testes dirigidos à palavra-chave foram criados para dar suporte aos
testes de aceitação explicitados pelas metodologias ágeis. Eles são realizados
através da interface gráfica da aplicação. Normalmente a ferramenta oferece um
conjunto pré-definido de palavras-chaves para permitir a criação dos testes. Cada
palavra-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 de
comandos e parâmetros pré-determinados. Uma ferramenta de CLI interpreta os
comandos e parâmetros, executa a função selecionada e apresenta o resultado. O
objetivo é fornecer uma interface para o mundo exterior que não seja dependente da
GUI.

Uma API representa um conjunto de operações expostas por uma
aplicação com o intuito de permitir que outras possam acessar ou consumir as suas
funcionalidades. A automação baseada na API faz uso dessa característica para
guiar a execução dos testes. Uma das vantagens do uso da API é que a aplicação
externa 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 de
negócio que prega o uso racional e inteligente da automação. É um tipo que pode
ser construído por meio de pequenos programas para testar uma API, uma interface
de linha de comando, ou qualquer outra forma. Nesta abordagem não importa o

29

meio, desde que não haja interações com a interface gráfica. O objetivo é exercitar
as funcionalidades críticas do software que realizam variações difíceis de serem
testadas por meios normais.

2.2.3 Ferramentas de gerenciamento

As ferramentas de gerenciamento normalmente são utilizadas para fazer
a gestão de testes e defeitos. Por exemplo, uma ferramenta que permite que sejam
cadastrados os defeitos encontrados no software durante os testes. Essas
ferramentas auxiliam a gerenciar quais módulos devem ser testados e a escolher a
data de execução, entre outras atividades. Elas são responsáveis por fornecer uma
interface entre as ferramentas de execução, por realizar o gerenciamento de defeitos
e 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 de
teste de software. Por meio de uma gestão, é possível acompanhar a qualidade do
software em teste com base nos defeitos cadastrados pelos testadores ao longo de
um ciclo de teste. Com base nesses dados, é possível identificar áreas
problemáticas da aplicação onde os riscos são maiores e planejar atividades
preventivas (CAETANO, 2007).

A gestão de defeitos pode ser realizada por meio de ferramentas
automatizadas chamadas de bug tracking system. Estas ferramentas oferecem um
repositório onde os membros da equipe podem cadastrar os defeitos, acompanhar o
ciclo 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 de
teste. Esta gestão pode ser utilizada através de ferramentas de gerenciamento de
teste (test management system). Estas ferramentas oferecem um banco de dados
onde os líderes de testes poderão criar suítes com casos de testes, atribuir os casos
de testes aos testadores, acompanhar o status da execução deles e emitir os
relatórios com métricas e estatísticas.

30

2.3 Ambiente para execução de teste automatizado

A qualidade e a produtividade da atividade de testes são diretamente
dependentes do critério de testes utilizados e da existência de uma ferramenta de
testes que os suportem. Sem a utilização de uma ferramenta automatizada, a
aplicação de um critério torna-se uma atividade propensa a erros e limitada a
programas 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 teste
utilizados durante a atividade de teste podem ser facilmente revalidados após uma
alteração.

Atualmente, várias ferramentas de teste podem ser incorporadas ao
ambiente de desenvolvimento, e esta prática é comum, pois as ferramentas são
configuradas 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ém
existem 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 de
teste unitário, como o JUnit, e as que auxiliam em testes de carga, de estresse e de
desempenho, como o JMeter, através da utilização dos testes unitários criados pelo
JUnit.

Estas ferramentas citadas foram escolhidas para uso neste trabalho por
terem foco em Java, por serem gratuitas, de fácil instalação e utilização. Também
podem apresentar os resultados de suas verificações em vários formatos, o que
facilita 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álise
estática de código utilizada no desenvolvimento do software para verificar se o

31

có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 aplicativo
responsável pela execução.

O checkstyle disponibiliza uma série de módulos que podem ser
configurados para alterar o nível de rigor das regras que serão validadas. Caso a
regra 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 de
có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 esta
abordagem parece desnecessária, mas a longo prazo, o código gerado torna-se
mais legível e reutilizável, melhorando, assim, a sua manutenção.

O checkstyle foi desenvolvido em Java, dando-lhe a capacidade de
independência de sistema operacional. Depois de instalado, para executar o
checktyle é extremamente simples, bastando apenas invocá-lo via script de
automação, informando o diretório de fontes, um arquivo de configuração e o tipo de
saída a ser gerado, ou através da interface da IDE, conforme Figura 3.

Esta ferramenta é ideal para projetos onde se deseja forçar os
desenvolvedores e seguir um estilo padronizado de programação. Por ser altamente
configurável e dar suporte a qualquer padrão, ela permite verificar muitos aspectos
do código-fonte.

O checkstyle possui uma grande quantidade de módulos, cujo nível de
rigor pode ser configurado entre obrigatório e opcional. Um módulo verifica a adição
de comentários aos métodos, classes e pacotes, o que facilita o entendimento do
código, uma vez que não será necessário estudar o método ou a classe para
entendê-la. Outro, checa adesão à convenção de nomes para métodos e classes
estabelecidos pela fabricante e que é utilizada pelo mercado. Outro, verifica se
existem blocos de instruções vazios, um bloco de decisão vazio, por exemplo. Existe
um módulo responsável por checar se há condições lógicas muito complicadas, o

32

que dificulta a legibilidade do código. Um módulo verifica se existem procedimentos
que lançam tipos de erros ilegais e/ou genéricos, pois, pela regra definida pela
ferramenta, erros devem ser específicos de modo a facilitar o tratamento deles.

Figura 3 – Utilização da ferramenta de análise estática

2.3.2 Findbugs

O findbugs, assim como o checkstyle, também é uma ferramenta de
aná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 de
corretude, quando o código parece estar fazendo algo que o desenvolvedor não
pretende ou necessita fazer, como é o caso da atribuição de um valor nulo para uma
variável; más práticas, quando o código viola alguma boa prática, por exemplo, o
có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 para
verificar se dois objetos são iguais no método equals; vulnerabilidade de código,

33

quando o código permite ações não desejadas, como no caso de um possível
ataque 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 possa
ser 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ção
dos bytecodes. Ele também pode ser invocado através da interface disponibilizada
na IDE, conforme ilustra a Figura 5.

É possível definir no findbugs o nível de severidade de cada problema
reportado pela ferramenta e indicar a partir de qual nível de severidade se deseja
analisar no código-fonte.


O findbugs possui uma grande variedade de módulos, cujo nível de

34

esforço pode ser configurado entre mínimo, padrão e máximo. Em algumas
ocasiões, especialmente em projetos grandes, ocorre estouro de memória quando o
esforço é máximo. Para solucionar este problema, a ferramenta possibilita configurar
a quantidade de memória a ser utilizada.

Existe um módulo da ferramenta que checa se os recursos alocados
foram devidamente liberados, por exemplo, conexões com banco de dados, streams
de arquivos, etc. Existe outro módulo que verifica se as comparações entre objetos
do tipo String são efetuadas corretamente, comparando o valor da propriedade, não
o objeto. Outro módulo verifica se os operadores de curto-circuito estão sendo
utilizados, pois estes operadores otimizam a leitura da expressão lógica. Um módulo
interessante é o que verifica possíveis ataques de injeção de SQL, pois, em alguns
casos, é possível que o usuário realize determinadas operações no banco em que
nã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 um
erro de referência nula. Além desses, há um módulo que verifica se o valor de
retorno de uma função está sendo ignorado.

2.3.3 PMD

O PMD, tal qual as ferramentas anteriores, é uma ferramenta de análise
estática de código.

A instalação do PMD também segue a mesma simplicidade das outras
ferramentas, portanto basta instalar o plug-in da IDE desejada e baixar o aplicativo
para execução.

Esta ferramenta é desenvolvida em Java, assim como as ferramentas
anteriores, 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 ele
possui um add-on chamado Copy-Paste Detector (CPD), que verifica a existência de
código duplicado. Porém, para executar somente o PMD, a ideia é a mesma, como
mostra a Figura 6. Neste caso, faz-se necessário apontar para o arquivo de
configurações, para o diretório de fontes e definir o tipo de saída. Para executar o
CPD, presente na mesma ferramenta, basta invocá-lo, informando o diretório de

35

fontes 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 foram
adicionados verificadores para outros propósitos. E, graças à possibilidade de
expansão da ferramenta, os desenvolvedores podem escrever novos detectores de
padrões de erro através da utilização tanto de Java quanto de XPath, que é um
conjunto 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 sejam
analisadores estáticos e funcionem sobre o mesmo objeto, os objetivos das
ferramentas são completamente distintos, portanto uma ferramenta não exclui a
outra, pelo contrário, complementa, aumentando, assim, o nível e a quantidade de
regras verificadas no código.


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

repetição, pois, segundo a fabricante do Java, o objeto String é imutável, portanto
uma concatenação gera um novo objeto, ocupando mais memória. Para otimizar
este processo, existem os construtores de String, que são o StringBuilder ou o
StringBuffer. Existe outro que é responsável por verificar se existem trechos de
có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ódulo
checa a complexidade ciclomática de um trecho de código, com a prerrogativa de
que este trecho precisa ser reescrito. Quando o método é excessivamente longo,
outro módulo alerta sobre isso, afirmando que existem procedimentos do método
que podem ser extraídos para novos métodos. Se o nome de uma determinada
variável é curto, de uma a três letras, outro módulo lançará um erro, pois nomes
muito pequenos dificultam o entendimento da finalidade da variável. Além de existir
um módulo para verificar a obrigatoriedade do uso das chaves, para tornar o código
mais legível.

2.3.4 JUnit

O JUnit é um framework de teste utilizado para a realização de teste
unitário automatizado do tipo caixa-branca, onde o programador pode criar um
modelo padrão de testes para ser executado de forma sequencial.

Existem algumas vantagens em se utilizar o JUnit, como a possibilidade
da 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ção
da atividade de desenvolvimento. A ferramenta checa os resultados dos testes e
fornece uma resposta imediata. Um benefício importante é o baixo custo, uma vez
que a ferramenta é grátis.

Esta ferramenta é desenvolvida em Java, assim como as demais. Para
instalar 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 o
Maven.

37

Para utilizar esta ferramenta através de um script de automação, o
processo é um pouco mais complexo. Neste caso, é necessário alterar o classpath
da aplicação apontando para o diretório que contém os bytecodes, o código fonte do
software, 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 a
Figura 6.

No momento da criação dos testes, existem duas rotinas que são
executadas sempre: uma que é chamada antes de executar cada rotina de teste, o
setUp, e outra, que é chamada após a execução de cada rotina de teste, o
tearDown. Outras duas rotinas também são executadas sempre antes de uma
classe 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 e
depois 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 rotina
distinta, pois assim a complexidade da assertiva é menor e, caso haja uma falha, a
complexidade do erro é reduzida.

Figura 6 – Utilização da ferramenta de teste unitário

38

Ao adotar o JUnit como framework de teste unitário, é possível obter
algumas vantagens uma vez que o framework checa os resultados dos testes e
fornece uma resposta imediata, pois não é necessário executar toda a rotina de
testes para apresentar os resultados. Outra vantagem é o fato de ser orientado a
objetos, tornando a escrita de casos de teste mais fácil e natural para os usuários
Java. Ele fornece uma ótima API para criação de casos de teste, favorecida pelo
conceito 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 de
desempenho. Para o JMeter, os usuários do sistema são representados como
threads. Dentro de um script, as threads executam a sequência de passos
determinada. Cada thread simula um usuário.

Thread é uma forma de um processo dividir a si mesmo em duas ou mais
tarefas que podem ser executadas concorrentemente (TANENBAUM, 2011).

O JMeter possui uma interface gráfica para se criar scripts de teste, como
mostra a Figura 7, onde é possível definir as ações do usuários que serão
executadas. Embora o JMeter consiga trabalhar a nível de interface gráfica, esta
ferramenta 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 de
ouvintes (listeners) disponibilizados pela ferramenta.

A região amarela mostra uma barra de menu que auxilia na criação de um
arquivo de um plano de teste, com as opções como novo, abrir, fechar, salvar, entre
outras, e também na execução do plano.

Já a região vermelha auxilia na criação dos procedimentos a serem
executados pelo caso de teste, através da definição de thread groups, que serão
executados 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

utilizados 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 fazer
testes em páginas web, porém, como dito anteriormente, ele não executa o código
JavaScript.

Figura 7 – Interface gráfica da ferramenta de teste de carga

O JMeter também é desenvolvido em Java, e também pode ser invocado
através de um script de automação, como mostra a Figura 8. Para invocá-lo, deve-se
informar o caminho para o diretório-raiz da ferramenta, o plano de teste a ser
utilizado e onde deve ser salvo o arquivo de saída. É possível, ainda, indicar a
quantidade 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 interface
gráfica, criar os passos a serem executados e salvar o plano.

40

Figura 8 – Utilização da ferramenta de teste de carga em um script

2.3.6 Jenkins

A integração contínua tornou-se muito importante no mercado de
desenvolvimento de software e isso, provavelmente, ocorreu devido ao grande
impacto 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 e
diversas 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 ou
atravé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, a
equipe toma conhecimento imediatamente, através de e-mail ou de um alerta. A
integração contínua é uma forma de trazer mais segurança em relação a mudanças,

41

pois 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. Ele
possui suporte para várias ferramentas de SCM, incluindo CVS, SVN e Git, e pode
executar 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 ambiente
integrado de teste, onde haverá um ambiente que executa a chamada do script de
automação e que será responsável por exibir os relatórios da execução de cada tipo
de 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órios
gráficos para cada teste. Com o relatório gráfico, é possível verificar o problema
relatado 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 que
ele possa exibir os relatórios desejados. Para isso, os plug-ins correspondentes
devem ser instalados. Como as ferramentas em estudo são Checkstyle, PMD,
Findbugs, JUnit e JMeter, os seus respectivos plug-ins serão instalados, conforme
mostra a Figura 9.

(a) (b)

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 utilizadas
concomitantemente, de modo a compor um ambiente integrado de teste
automatizado. Embora existam ferramentas de mesma categoria, como checkstyle,
Findbugs e PMD, os objetivos destas são diferentes. Enquanto a primeira verifica se
o código atende a padrões de codificação, a segunda analisa padrões de erros e
sugere otimizações no código, e a última verifica outros padrões de erros e de
codificação, sugerindo uma “limpeza” no código, através da remoção de códigos não
utilizados. Para ilustrar melhor, a Tabela 1 mostra de forma resumida a diferença
entre estas ferramentas.

43

Tabela 1 – Tabela comparativa entre as ferramentas de análise estática
CARACTERÍSTICA CHECKSTYLE FINDBUGS PMD

Comentário de código Sim Não Não

Bloco catch vazio Sim Não Sim

Atribuição em subexpressão Não Não Sim

Conexão com banco de dados Não Sim Sim
não encerrada

Não utilização de operador Não Sim Sim
lógico de curto-circuito

Nome 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
caracteres

Utilização de comparação em Sim Sim Sim
vez de método de comparação

Ignorar valor de retorno Não Sim Não

No próximo capítulo, será apresentado o estudo de caso com o ambiente
montado, mostrando o funcionamento das ferramentas no ambiente integrado.

44

3 ESTUDO DE CASO

O estudo de caso visa apresentar o funcionamento das ferramentas no
que se refere à execução dos testes de sistemas. Ele apresenta alguns exemplos de
testes executados sobre uma aplicação existente, rodando testes com as seguintes
ferramentas checkstyle, findbugs e pmd, para análise estática de código, testes
unitários com o JUnit; teste de carga e desempenho com o JMeter em um ambiente
grá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, aplicar
as ferramentas, configurar os relatórios e analisar os resultados.

3.1 Especificação

Como o foco do trabalho é apresentar um ambiente integrado de teste
automatizado, testes estes baseados em técnicas caixa-branca e utilizando a
ferramenta de integração contínua Jenkins, foi utilizada a aplicação para executar os
testes, simulando a utilização deste ambiente integrado em um ambiente de
desenvolvimento real.

Com o intuito de demonstrar o funcionamento das ferramentas, e por
consequência do ambiente, foi escolhido um cenário de execução onde serão
executados os testes.

O cenário consiste em uma aplicação Web de um sistema de
gerenciamento de eventos, que possui uma tela de cadastros de eventos, outra para
criação de dormitórios, outra de alocação de pessoas nos dormitórios, um formulário
para efetuar o recebimento de pagamento e opções para geração de relatórios, além
da tela de login, conforme mostra a Figura 10, que sofrerá as execuções das
ferramentas de análise estática que indicarão os pontos de falha ou melhoria, dos
testes unitários e do teste de desempenho.

45

(a) (b)

(c) (d)

Figura 10 – Contendo algumas telas do sistema Web: Tela de login de acesso ao
sistema (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 ser
um administrador. Esta verificação é realizada na camada de controle. Já para
realizar 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 atenham
somente a convenção de codificação da linguagem. Já o Findbugs e o PMD foram
configurados para executarem as regras padrões, executadas quando não se é
explicitada nenhuma configuração adicional, e serão configurados para executarem
com esforço máximo, coletando a maior quantidade de falhas possível.

Finalmente, após as execuções, serão gerados relatórios para
apresentarem os resultados das execuções.

46

3.2 Configuração do ambiente

Inicialmente será necessário alterar o script de automação de build do
projeto para configurar as ferramentas para exportarem seus resultados como
arquivo XML. Esta configuração se faz necessária para que os plug-ins das
ferramentas consigam interpretá-los e exibi-los de forma gráfica. Após isso, todas as
outras 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ção
e configuração, em que um dos elementos consiste em uma configuração que
indique a ferramenta SCM, como CVS (sistema de versões concorrentes), ou SVN
(Apache Subversion), que mantém o código fonte. Ferramentas SCM facilitam a
gerê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 determinado
período, como ocorre em alguns frameworks de mercado que possuem a construção
noturna (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 pela
construção, que será responsável por orquestrar a construção; há uma configuração
que possibilita o armazenamento de fingerprints, que são os artefatos que devem
ser armazenados e vinculados à versão da construção, como resultados dos testes,
documentação, resultado dos testes, executáveis, entre outros. Também é possível
configurar para notificar, através de e-mail, algumas pessoas com o resultado da
construção, isso facilita o acompanhamento do projeto por parte do gerente ou dos
desenvolvedores.

Após isso, será possível configurar, dentre outras características, os
passos a serem executados durante e após a execução do script. A apresentação
dos relatórios é uma ação pós-construção, pois é na construção que os testes são
executados e os resultados são gerados e exportados para arquivo do tipo XML.

47

Após a execução da construção, nota-se uma alteração na interface, que
agora 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 de
acordo com as construções executadas. É possível visualizar a categoria de erro, o
pacote, 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 a
constâ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, a
unidade ou a linha de código da unidade em que a falha ocorreu. Após selecionar o
relató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 de
defeito ou falha e, após selecionar o pacote, serão exibidas as unidades e, ao
selecionar a unidade, serão exibidas as linhas que possuem a falha, conforme
mostra a Figura 11.

(a) (b)

(c) (d)

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ção
do 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 que
possui os erros analisados (f).

Para os testes realizados pelo JUnit, o resultado é apresentado quando
ocorre 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 resultado
esperado, desde a execução dos testes até a apresentação dos resultados, com a
possibilidade de uma checagem configurável. Esta configuração pode ser geral ou
por 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ão
facilitadas graças ao Jenkins, que automatiza estes processos. A facilidade de
acesso à informação e de compreensão desta também são auxiliadas pelos plug-ins
da ferramenta de integração contínua.

Há muitas vantagens na utilização do Jenkins como ferramenta de
integração contínua, como a vantagem da facilidade e disponibilidade de acesso e
de compreensão da informação, pois a ferramenta de integração contínua procura
agrupar por ferramenta de teste, grupo de erro e pacote de unidades, e exibir um

49

gráfico em área 2D, de modo a tornar mais claro e objetivo os resultados das
execuções dos testes. Outra vantagem é a capacidade de customizar o
comportamento da ferramenta, fazendo com que seja possível adequar tanto o
processo de desenvolvimento existente quanto a ferramenta em si.

Por outro lado, existem cenários em que o ambiente não apresentou o
resultado esperado, pois eram cenários que estavam desenvolvidos de modo a não
facilitar, ou até mesmo impedir, o desenvolvimento de testes unitários, devido ao alto
grau de acoplamento e à baixa coesão. No estudo de caso, estava bastante
complicado simular um cenário de cadastro de evento ou de dormitório uma vez que
as validações estavam espalhadas pelo código quando deveriam estar agrupadas. A
boa prática de desenvolvimento afirma que não é aconselhável realizar validações
na camada de modelo.

Também foram detectados alguns problemas, como o plug-in para o JUnit
apresentar, 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 rastrear
o ponto de falha.

Portanto, em linhas gerais, pode-se afirmar que o ambiente integrado de
teste possui boa aplicabilidade, devido à sua facilidade de instalação, configuração e
manutenção. As ferramentas, isoladamente, auxiliam no desenvolvimento e na
manutenção do software, e também servem de alerta para pontos onde existem
erros em potencial.

Devido à integração das ferramentas com uma IDE, é possível, também,
não gerar um processo extra, evitando adicionar trabalho à equipe de
desenvolvimento, mantendo, assim, esta focada em seu serviço. Em longo prazo, a
equipe de desenvolvimento tratará de evolução do software, reduzindo o retrabalho
e, consequentemente, o custo do projeto.

50

CONCLUSÃO

Neste trabalho são demonstradas as fases de criação, utilização e
aplicação de um ambiente integrado de teste automatizado, através de ferramenta
de 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, foi
abordada 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 seu
planejamento, o plano de execução, a execução, a análise dos resultados e o
encerramento 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 fases
de teste, e, por fim, é definida uma proposta de automação, pois a execução manual
destes testes levaria muito tempo. A ideia é que a execução automatizada é mais
rápida e evolui juntamente com o software, obtendo ganho no tempo de resposta e
executando os mesmos testes.

Adiante, é apresentado o contexto dos testes automatizados, mostrando
que automatizar um teste é uma decisão de projeto que deve ser encarada de
acordo com a necessidade do que se espera do produto. São apresentadas técnicas
de revisão e categorias de ferramentas, onde cada ferramenta apresentada possui
uma gama de configurações e realizam análises estáticas sobre o código, auxiliando
o desenvolvimento e a manutenção pela equipe de desenvolvimento. As ferramentas
de testes unitários, que seriam responsáveis por testar os fluxos do sistema de
forma rápida e efetiva. Por fim, é apresentada uma ferramenta que integra todas as
outras apresentadas em um ambiente limpo e configurável, sendo responsável por
realizar as construções do produto e apresentar os resultados de forma clara e
objetiva.

Em seguida, é demonstrado, através de um estudo de caso, a criação e a
configuração do ambiente integrado, mostrado as vantagens e desvantagens do
ambiente. O objetivo é apresentar e avaliar o funcionamento e a execução dos

51

testes em um dado cenário, e apresentar os resultados de modo a acompanhar a
evolução do software em relação ao tempo de desenvolvimento.

Diante da análise efetuada sobre as ferramentas levantadas no estudo, o
Jenkins destacou-se por oferecer integração com outras ferramentas através de
plug-ins, facilitando a coleta e apresentação dos resultados. Além disso, também
existe a facilidade de configuração do projeto e de configuração da utilização das
ferramentas. Como parte integrante do ambiente de teste de desenvolvimento, o
JMeter se destaca por facilitar o teste de desempenho que, em um ambiente de
teste manual, torna-se muito difícil, ou até mesmo impossível.

Portanto, a criação de um ambiente integrado de teste é essencial para
projetos de médio e grande porte uma vez que nele haverá informações necessárias
para auxiliar no processo de tomada de decisão quanto ao projeto, mostrando de
forma clara o seu andamento, apresentando pontos que necessitam de um cuidado
especial, por exemplo, trechos que demoram a ser executados, ou que rapidamente
chegam a uma situação de demora.

Vale ressaltar que não é possível mensurar o valor economizado em
virtude da utilização dos testes. Dentre as práticas comuns, está a de avaliar
comparativamente com outros projetos semelhantes, porém em que não foram
adotadas rotinas automatizadas de teste.

A partir deste trabalho, podem ser originados trabalho futuros, como o uso
de 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 de
múltiplos usuários através do JMeter, ou o desenvolvimento de testes para
dispositivos móveis, abordando o Selenium for Android.

52

REFERÊNCIAS

ALMEIDA, 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 Testes
Automatizados. (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_softwar
e_-_parte_01>. Acesso em: 01 ago. 2012.

CAETANO, Cristiano. Automação e Gerenciamento de Testes. São Paulo: Digital
Works.

CAETANO, Cristiano. Introdução à Automação de Testes Funcionais. Disponível
em: <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: 19
set. 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: Pearson
Education do Brasil, p. 315-347, 2005.

MALDONADO, Jose Carlos. BARBOSA, Ellen Francine. VINCENZI, Auri Marcelo
Rizzo. 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ível
em: <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

TERRA, Ricardo. BIGONHA, Roberto S. Ferramentas para Análise Estática de
Códigos Java (Departamento de Ciência da Computação - UFMG, p. 1-6, 2008).

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson
Education, 2007. Cap. 22, p. 339-353.

STAA, Arndt von; JUNIOR, Gilberto Pavoni. Retrabalho corrói eficiência do teste
de Software, Brasil 2011. Disponível em <http://itweb.com.br/48984/retrabalho-
corroi-eficiencia-do-teste-de-software/> Acesso 04/2012.

Ambiente integrado de teste automatizado

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (20)

Similar to Ambiente integrado de teste automatizado

Similar to Ambiente integrado de teste automatizado (20)

Ambiente integrado de teste automatizado