Teste de Software - Pos-graduação-ESAB

Copyright 2011, ESAB Escola Superior Aberta do Brasil
1

MDULO DE:

TESTE DE SOFTWARE

AUTORIA:

Me. PEDRO HENRIQUE MANNATO COUTINHO



2
Mdulo de: Teste de Software
Autoria: Pedro Henrique Mannato Coutinho

Primeira edio: 2011

CITAO DE MARCAS NOTRIAS

Vrias marcas registradas so citadas no contedo deste Mdulo. Mais do que simplesmente listar esses
nomes e informar quem possui seus direitos de explorao ou ainda imprimir logotipos, o autor declara estar
utilizando tais nomes apenas para fins editoriais acadmicos.
Declara ainda, que sua utilizao tem como objetivo, exclusivamente na aplicao didtica, beneficiando e
divulgando a marca do detentor, sem a inteno de infringir as regras bsicas de autenticidade de sua
utilizao e direitos autorais.

Todos os direitos desta edio reservados
ESAB ESCOLA SUPERIOR ABERTA DO BRASIL LTDA
http://www.esab.edu.br
Av. Santa Leopoldina, n 840/07
Bairro Itaparica Vila Velha, ES
CEP: 29102-040


3
Apresentao
O software passou a ser pea chave na competitividade de muitas empresas, fazendo
com que suas falhas provocassem diversos tipos de prejuzos. Nesse cenrio, para
garantir a qualidade dos softwares rea de teste vem ganhando cada vez mais
importncia e notoriedade.
Para obter a ateno necessria, os testes devem ser tratados com uma abordagem mais
sistemtica, deixando de ser uma atividade dentro do processo de desenvolvimento, e
passando a ter um processo prprio, com etapas, atividades, artefatos, tcnicas, equipe,
ambiente e ferramentas.

Objetivo
Apresentar de forma dinmica e agradvel os conceitos relacionados aos testes de
software e a sua importncia, em conjunto com demonstraes prticas. Proporcionar ao
aluno o aprendizado necessrio para colocar em prtica os principais aspectos dos testes
de software.
Para atingir esse objetivo, foram intercaladas unidades de conceituao e
recomendaes, com outras de demonstrao de ferramentas gratuitas e ricas em
funcionalidades, para apoiar diferentes atividades e etapas do processo de Teste do
Software.
Ementa
Apresentao dos seguintes temas: testes estticos, dinmicos, funcionais (caixa-preta),
estruturais (caixa-branca), tipos e nveis de testes, investimento em teste, custo da falha e
da correo, o processo de teste, planejamento, ambiente, equipe, casos de teste,


4
execuo, gesto dos defeitos, reviso e inspeo, desenvolvimento orientado a testes
(TDD) e integrao contnua. So apresentadas tambm 8 ferramentas gratuitas para:
cobertura de cdigo, teste unitrio, objetos "substitutos" (mock objects), gesto de
defeitos, gesto do processo de teste, teste de estresse e de performance, testes de
aplicaes web e integrao contnua.

Sobre o Autor
Mestre em Informtica (UFES -2007), Graduado em Cincia da Computao (UFES-
2004).
A Dissertao de Mestrado rendeu o terceiro lugar no prmio de dissertaes do SBIE
2008 (Simpsio Brasileiro de Informtica na Educao).
Diretor Executivo e scio fundador da empresa Projeta Sistemas de Informao. J foi
Vice-Presidente de Associativismo e Financeiro da ASSESPRO-ES.
Professor de Ps-Graduao Lato-Sensu em disciplinas presenciais e on-line. Faz parte
do corpo de consultores de tecnologia do SEBRAE-ES. Possui experincia atuando como
Gerente de Projeto, Analista de Sistema, Analista de Processos de Negcio (BPM),
Desenvolvedor, Pesquisador de Novas Tecnologias, Analista de Testes, dentre outros.
Atuou em projetos que tinham como clientes: Arcelor Mittal, Receita Federal, IBGE,
Sebrae, Grupo Coimex, ESAB, dentre outros. Atuou como analista e desenvolvedor do
software para o gerenciamento de empresas do mercado rent a car, ganhador do 1
Prmio do Plo de Software do Esprito Santo e um dos quatro finalistas do 6 Encontro
Nacional de Tecnologia e Negcios - Rio Info.


5

SUMRIO
UNIDADE 1 ......................................................................................................................... 7
Introduo ....................................................................................................................... 7
UNIDADE 2 ....................................................................................................................... 10
Conceitos de Testes I .................................................................................................... 10
UNIDADE 3 ....................................................................................................................... 13
Conceitos de Testes II.....................................................................................................13
UNIDADE 4 ....................................................................................................................... 17
Custos de Testar, da Correo e o Retorno de Investimento em Testes ...................... 17
UNIDADE 5 ....................................................................................................................... 23
Custos das Falhas ......................................................................................................... 23
UNIDADE 6 ....................................................................................................................... 26
O Processo de Teste ..................................................................................................... 27
UNIDADE 7 ....................................................................................................................... 32
Planejamento dos Testes .............................................................................................. 32
UNIDADE 8 ....................................................................................................................... 38
Ambiente de Testes ....................................................................................................... 38
UNIDADE 9 ....................................................................................................................... 43
A Equipe e os Papis nos Testes .................................................................................. 43
UNIDADE 10 ..................................................................................................................... 48
Tcnicas Estticas - Reviso e Inspeo ...................................................................... 48
UNIDADE 11 ..................................................................................................................... 51
Casos de Teste ............................................................................................................. 51
UNIDADE 12 ..................................................................................................................... 56
Execuo dos Testes .................................................................................................... 56
UNIDADE 13 ..................................................................................................................... 59
Gesto de Testes - Ferramenta TestLink ...................................................................... 59
UNIDADE 14 ..................................................................................................................... 64
Gesto de Defeitos ........................................................................................................ 64
UNIDADE 15 ..................................................................................................................... 68


6
Gesto de Defeitos - Ferramenta Mantis I ..................................................................... 68
UNIDADE 16 ..................................................................................................................... 73
Gesto de Defeitos - Ferramenta Mantis II.....................................................................73
UNIDADE 17 ..................................................................................................................... 77
Cobertura de Cdigo - Ferramenta EclEMMA ............................................................... 77
UNIDADE 18 ..................................................................................................................... 80
Testes de Unidade e Integrao - Ferramenta JUnit ..................................................... 80
UNIDADE 19 ..................................................................................................................... 86
Testes com Objetos Substitutos ou "Falsificados" (Mock Objects) - Ferramenta Mockito
...................................................................................................................................... 86
UNIDADE 20 ..................................................................................................................... 92
Desenvolvimento Orientado a Testes (TDD - Test Driven Devlopment) ....................... 92
UNIDADE 21 ..................................................................................................................... 96
Exemplo de TDD na Prtica .......................................................................................... 96
UNIDADE 22 ................................................................................................................... 102
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers ........................ 102
UNIDADE 23 ................................................................................................................... 105
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuao) . 105
UNIDADE 24 ................................................................................................................... 109
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuao) . 109
UNIDADE 25 ................................................................................................................... 114
Teste de Performance e Estresse - Ferramenta JMeter .............................................. 114
UNIDADE 26 ................................................................................................................... 118
Teste de Performance e Estresse - Ferramenta JMeter (Continuao) ...................... 118
UNIDADE 27 ................................................................................................................... 122
Integrao Contnua .................................................................................................... 122
UNIDADE 28 ................................................................................................................... 126
Integrao Contnua - Ferramenta Jenkins I ............................................................... 126
UNIDADE 29 ................................................................................................................... 131
Integrao Contnua - Ferramenta Jenkins II .............................................................. 131
UNIDADE 30 ................................................................................................................... 136
Consideraes Finais .................................................................................................. 136


7
UNIDADE 1
Objetivo: Realizar uma apresentao inicial do contedo do Mdulo de Teste de Software
Introduo

Bem vindo ao Mdulo Teste de Software!
O avano da tecnologia nas ltimas dcadas em reas que vo dos hardwares at as
linguagens de programao, proporcionaram o surgimento de milhares de software. A
utilizao da Internet potencializou ainda mais esse fato, fazendo com que diversas
aplicaes computacionais fizessem parte do nosso dia a dia. Assim, o software passou a
ser pea chave na competitividade de muitas empresas, fazendo com que suas falhas
provocassem diversos tipos de prejuzos. Nesse cenrio, para garantir a qualidade dos
softwares, a rea de teste foi ganhando cada vez mais importncia.
At a dcada de 90, os testes eram realizados na maioria das vezes pelos prprios
desenvolvedores, e eram tratados como uma atividade que tinha pouco tempo disponvel,
no cronograma do projeto de software, para ser realizada. Desde ento, diversos artigos,
ferramentas e livros sobre testes foram lanados, mas assim mesmo comum ver
empresas que no dedicam a ateno necessria a essa rea para garantia da qualidade.
Portanto, o objetivo deste Mdulo apresentar os principais pontos envolvidos com o
teste de software, com uma abordagem mais sistemtica; deixando de ser uma atividade
dentro do processo de desenvolvimento, e passando a ter um processo prprio, com
etapas, atividades, artefatos, ambiente, tcnicas, equipe e ferramentas.
Mesmo com todo avano em relao aos testes, nos ltimos anos; o teste de software
no uma "cincia exata". No entanto, teste exaustivo impossvel, e para realizar os
testes adequadamente importante realizar uma avaliao de risco.
A anlise de risco uma parte importante dos testes de software, visto que vai determinar
as reas que precisam ser mais cuidadosamente testadas e, em qual momento, se pode


8
considerar que os testes realizados foram suficientes para garantir uma confiana
adequada para liberar o software para produo.
Para atingir o objetivo, este Mdulo foi baseado em livros, artigos de especialistas,
revistas especializadas e manuais de ferramentas. Para fornecer uma abordagem
conceitual aliada prtica, 8 ferramentas gratuitas, relacionadas com diferentes partes do
teste de software, sero apresentadas.
O objetivo da apresentao dessas 8 ferramentas propiciar ao aluno o conhecimento
dos principais benefcios, facilidade de uso e o momento adequado para usar cada tipo de
ferramenta. Assim, o Mdulo no tem a pretenso de abranger todos os aspectos dessas
ferramentas, at porque, o manual delas extenso, impossibilitando abordar em um
mdulo.
A figura a seguir apresenta algumas das bibliografias utilizadas como base para
elaborao deste Mdulo.

Figura 1 Algumas referncias que serviram como base para este Mdulo

Um dos indicadores da importncia e aumento de notoriedade dos testes de software o
surgimento de vrias certificaes. Dentre elas, importante citar a Certificao Brasileira


9
em Teste de Software (CBTS) e a Qualificao Internacional de Teste de Software
(ISTQB - Internacional Software Testing Qualification), cujas referncias tambm foram
consultadas para a elaborao deste Mdulo.
Os modelos de processo de melhoria de software como CMMI (Capability Maturity Model
Integration) e o MPS.BR (Melhoria de Processos do Software Brasileiro) exigem a
implantao de testes de software. Por exemplo, para conquistar o nvel 3 do CMMI
preciso adotar uma abordagem sistemtica em relao aos testes, que se encontra nas
reas de Verificao e Validao deste modelo.
importante notar que as metodologias geis como o XP (eXtreme Programming)
contriburam com os conceitos de Integrao Contnua, Desenvolvimento Orientado a
Testes (TDD) e ferramentas de testes unitrios no modelo xUnit, que sero estudadas
neste Mdulo. Apesar de a origem ter sido em metodologias geis, qualquer metodologia
de desenvolvimento pode se beneficiar dessas prticas.

Organizao do Contedo
Nas prximas duas unidades deste Mdulo, sero abordados conceitos utilizados nas
demais unidades. Portanto, as Unidades 2 e 3 apresentam conceitos como testes
estticos, dinmicos, funcionais (caixa-preta), estruturais (caixa-branca), tipos e nveis de
testes. As unidades seguintes apresentam conceitos relacionados com o custo do teste,
custo da falha e da correo; o processo de teste; planejamento; ambiente; equipe; casos
de teste; execuo; gesto dos defeitos; reviso e inspeo; desenvolvimento orientado a
testes (TDD) e integrao contnua.
Sero apresentadas tambm 8 ferramentas gratuitas para: cobertura de cdigo, teste
unitrio, objetos "substitutos" (mock objects), gesto de defeitos, gesto do processo de
teste, teste de estresse e de performance, testes de aplicaes web e integrao
contnua.


10
UNIDADE 2
Objetivo: Conhecer os principais conceitos sobre os testes, que sero utilizados no
decorrer deste Mdulo
Conceitos de Testes I

Se os testes so to importantes, por que normalmente no se testa adequadamente?
Um dos principais fatores para responder essa pergunta entender que a presso por
menores prazos e valores negociados para desenvolver um software, dificilmente
contempla a realizao de testes de forma adequada. Os testes precisam de um
investimento inicial maior, mas como ser visto, ao longo deste mdulo, os prejuzos
provocados pelas falhas costumam justificar o investimento em um processo de testes.
Os softwares so desenvolvidos por seres humanos, que por mais dotados de
competncias, no so perfeitos, sendo passveis de cometer erros. A verdade que
infelizmente os erros estaro presentes no software, e se a equipe de desenvolvimento
no encontr-los, o cliente vai encontrar, j que cada vez que ele interage com o software,
ele est "exercitando" uma funcionalidade.
Delamaro, Maldonado e Jino citam no livro "Introduo ao Teste de Software" que o
desenvolvimento de software est sujeito a diversos tipos de influncias e problemas que
acabam por gerar um software diferente do que o cliente esperava. Dentre os diversos
fatores que podem causar esses problemas, eles identificam que a maioria ocasionado
por uma mesma origem, o erro humano.
Portanto, os testes devem ser realizados de uma maneira sistemtica, para evitar o
acontecimento de uma das "Leis de Murphy": "Se alguma coisa pode dar errado, dar. E
mais, dar errado da pior maneira, no pior momento e de modo que cause o maior dano
possvel."


11
Exceto em casos triviais, a execuo de testes exaustivos que testam todas as
possibilidades de combinaes, entradas, etc., no so viveis. Pode-se citar como
exemplo, uma demonstrao simples apresentada por Falbo (2008):
Suponha um programa que calcule o exponencial de nmeros inteiros x e y (x
y
). Para
testar todas as entradas possveis todos os nmeros inteiros de x e y combinados devem
ser testados, gerando uma cardinalidade de 2
n
* 2
n
, sendo "n" o nmero de bits usados
para representar um inteiro. Em uma arquitetura de 32 bits, a cardinalidade seria 2
64

(2
32
*2
32
). Se cada teste puder ser realizado em 1 milissegundo, seria necessrio
aproximadamente 5,85 milhes de sculos para executar todos os testes. Adicionalmente
mesmo que o teste exaustivo fosse executado, ele no garantiria que o software
corresponde sua especificao. Suponha que ao invs do x
y
o cliente tenha especificado
a raiz de x por y (
y
x), e o desenvolvedor por equvoco implementou a funo
apresentada no exemplo; esse erro no seria identificado pelo teste exaustivo, e sim pela
reviso dos requisitos ou teste de aceitao.
Portanto, como afirmou Djkistra O teste no pode nunca demonstrar a ausncia de
defeitos, apenas sua presena.
Mesmo no sendo possvel realizar testes exaustivos para provar que o software est
livre de defeitos a conduo sistemtica de testes em conjunto com as definies de
critrios, riscos e prioridades contribuem para aumentar a qualidade e confiana no
sistema.

Testes Estticos x Testes Dinmicos
As atividades relacionadas ao teste do software em si no envolvem somente a execuo
do programa, que o teste dinmico. Existem tambm os testes estticos, que no
precisam da execuo de um software (ou nem mesmo a sua existncia) para serem
realizados. Os testes estticos podem ser aplicados a diferentes artefatos como a reviso
de documentos de requisitos, anlise, do prprio cdigo fonte, etc.


12
Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)
Os testes funcionais tambm so conhecidos como "teste caixa-preta", pelo fato do
testador no precisar conhecer os detalhes da codificao. Nesse tipo de teste o testador
informa os dados de entrada e verifica se a sada/resultado est de acordo com o que era
esperado. Portanto, esse tipo de teste no tem como objetivo saber como a
funcionalidade foi implementada, mas sim quais so os resultados apresentados.
Avaliando somente a entrada e a sada, o teste de caixa-preta visa identificar defeitos do
tipo:
Se o sistema aceita entradas incorretas;
Se a sada produzida est correta;
Se existem erros na interface;
Se alguma funcionalidade est faltando;
Dentre outros.

J os testes estruturais, ou "testes caixa-branca" levam em considerao a estrutura do
cdigo fonte para identificar a implementao e se os diferentes caminhos esto sendo
cobertos por algum tipo de teste. Assim, os testes sero elaborados para: testar as
decises lgicas (verdadeiro/falso), testar os "loops" at o limite, as variveis estticas e
dinmicas, dentre outros.
O teste de caixa-branca no substitui o teste de caixa-preta, e vice-versa. Eles so
utilizados em conjunto; cada um com um objetivo distinto.

Figura 2 Teste Caixa-preta e Teste Caixa-branca


13
UNIDADE 3
Objetivo: Objetivo: Conhecer os principais conceitos sobre os testes, que sero utilizados
no decorrer deste Mdulo
Conceitos de Testes II

Nveis de Testes
Os nveis de testes normalmente so classificados como: teste unitrio, teste de
integrao, teste de sistema e teste de aceitao.
Os testes unitrios so realizados nas menores unidades do software, que normalmente
so os mtodos ou funes. Usualmente so os prprios desenvolvedores que realizam
os testes unitrios do prprio cdigo. O seu objetivo buscar por erros de lgica e
programao, nas unidades em separado, de forma a garantir que essas unidades
funcionem corretamente e isoladamente. A justificativa clara para realizar os testes de
unidade :, se uma unidade no funcionar isoladamente, ao ser integrada com outras
unidades, o erro ser propagado e mais tempo ser gasto para identific-lo. Os testes
unitrios podem ser realizados aps a implementao da unidade, ou at mesmo antes
de seu cdigo ser implementado, sendo essa ltima uma abordagem de metodologias
geis (Mais detalhes, a respeito de desenvolvimento orientado a testes, sero abordados
adiante).
Os testes de integrao verificam se as partes que funcionavam isoladamente continuam
a funcionar aps serem combinadas. Portanto, so verificadas as integraes entre
unidades, componentes, sistemas, camadas, etc.
As integraes podem ser do tipo "Big-Bang" ou incremental.
A integrao Big-Bang consiste da realizao do teste aps todas as unidades,
componentes, etc.; serem integrados, testando tudo de uma s vez. A integrao
incremental consiste em integrar e testar o programa gradativamente, comeando com


14
uma integrao pequena e testando; constituindo uma nova integrao somente quando
os testes da integrao menor forem bem sucedidos. A integrao Big-Bang mais
arriscada, porque quanto maior for a abrangncia da integrao mais difcil ser para
identificar a parte que originou a falha. Sem contar que testar a integrao, aps tudo ter
sido desenvolvido, faz com que os erros sejam encontrados tardiamente. Portanto, para
evitar esses tipos de problemas, recomenda-se o uso da Abordagem Incremental.
Testes de sistema avaliam o comportamento do sistema como um todo. Alm das
funcionalidades, as caractersticas no funcionais como: performance, segurana,
usabilidade, dentre outros, so avaliados. Esses quesitos podem ser avaliados tambm
nos outros nveis de teste, e devem ser feitos por completo nos testes de sistema. Nesse
nvel, importante que o ambiente de teste se parea, ao mximo, com o ambiente de
produo, de forma que os testes reproduzam o mximo possvel o uso real.
Testes de aceitao so realizados pelos clientes e/ou usurios do sistema com o objetivo
de verificar se o sistema est atendendo ao que era pretendido e foi especificado. Esse
nvel no tem como objetivo caar defeitos e sim verificar se o sistema est "conforme".
Engana-se quem pensa que esses testes devem ser realizados somente ao final do
desenvolvimento. Eles devem ser realizados o quanto antes, para que os desvios possam
ser corrigidos enquanto h tempo e no tenham sido propagados. Deixar os testes de
aceitao somente para o final representa um risco altssimo de reprovao do cliente,
gerando diversos tipos de prejuzos que englobam o custo do retrabalho, perda do tempo
certo para lanar o produto, dentre outros.

Tcnicas de Testes
A seguir, sero apresentadas algumas tcnicas de teste.
Teste de regresso: consiste em testar novamente o software (ou partes dele),
aps o desenvolvimento de uma mudana. Assim, o objetivo verificar se a
introduo de uma mudana, como por exemplo, novo cdigo ou at mesmo a
correo de um defeito, no provocou um novo defeito em uma parte do software
que funcionava corretamente, ou seja, verificar que no ocorreu nenhum "efeito
colateral". A reexecuo dos testes muitas vezes no realizada da forma


15
adequada por ser encarada como uma tarefa cansativa e repetitiva, mas preciso
avaliar o risco de uma parte que funcionava apresentar defeitos. Como os testes de
regresso so realizados muitas vezes, se tornam bons candidatos a serem
automatizados.
Teste de estresse: o objetivo do teste de estresse avaliar como o sistema se
comporta em condies extremas. Dessa forma, ele deve ser realizado para
consumir os recursos disponveis de forma anormal, testando: restries de
memria, espao em disco, CPU, dentre outros. Para isso, testa-se com
quantidade elevada de acessos simultneos, volume de dados acima da mdia
esperada, etc. Nessas condies o comportamento do sistema ser avaliado.
importante que o ambiente de testes seja o mais parecido possvel com o ambiente
de produo.
Teste de recuperao: verifica se o sistema ser restabelecido sua operao
normal e de forma ntegra aps ocorrer alguma falha, como por exemplo: queda da
rede, falha de hardware, perda de acesso ao banco de dados, dentre outros. Para
tanto, esses e outros tipos de falhas so provocadas pelo testador. O teste de
recuperao avalia no s a recuperao automtica do sistema, mas tambm os
procedimentos manuais necessrios. Dessa forma, os testes avaliam
procedimentos com respectivos checklilsts e podem envolver inclusive a
restaurao de backup. Portanto, verifica-se tambm se o backup est sendo
realizado e armazenado adequadamente. Outro ponto avaliado a quantidade de
tempo necessrio para o software se restabelecer, depois da realizao dos
procedimentos.
Teste de performance: o objetivo do teste de performance avaliar se o sistema
consegue obter um desempenho determinado em quesitos como, tempo de
resposta, utilizao do hardware, dentre outros. No deve ser confundido com o
teste de estresse, visto que, nesse caso, o objetivo verificar se a performance
est como esperada em condies normais, e no em condies extremas.
Teste de segurana: os testes de segurana so executados para garantir que os
mecanismos de segurana do software vo proteg-lo em relao integridade,
confidencialidade das informaes e proteo do software. Esse tipo de teste pode


16
necessitar de contratao de terceiros, visto que especialistas podero utilizar
tcnicas e conhecimentos especficos para invadir o software, sendo que esses
conhecimentos no costumam ser de conhecimento de analistas, desenvolveres e
testadores em geral.
Teste paralelo: a referncia do CBTS chama de teste paralelo a execuo da nova
verso do software em conjunto com uma verso antiga, para comparar se os
resultados apresentados so iguais.

Em relao performance de um site, a revista Exame PME, de Junho de 2011, traz
uma informao interessante. Na reportagem "Quem mais rpido vende mais" so
apresentados dados de uma pesquisa informando que:
Cada 1 segundo que um site demora a mais para carregar; significa perda de
7% das vendas
57% dos consumidores abandonam um site depois de esperar 3 segundos
para visualizar os dados
80 % desses consumidores no voltam ao site por pelo menos 6 meses
Desde 2008, a Amazon estima ter aumentado suas receitas em 1%, cada vez
que suas pginas ficaram um dcimo de segundo mais rpidas.


17
UNIDADE 4
Objetivo: Conhecer os custos envolvidos com os testes de software, bem como o retorno
de investimento proporcionado.
Custos de Testar; da Correo e o Retorno de Investimento em Testes.

Custos de Testar
O autor do livro "The Art of Software Testing" (A Arte de Testar Software), Glenford Myers
estima que 50% do custo total do projeto so gastos com as atividades relacionadas ao
teste de software. Embora outros autores apresentem estimativas diferentes importante
identificar onde esses custos esto alocados.
O teste de software consome recursos principalmente em:
Profissionais: horas gastas pelos profissionais da equipe (desenvolvedores,
analistas de teste, testadores, etc.) com atividades de testes, custos com
treinamento da equipe, dentre outros.
Equipamentos: mquinas necessrias para permitir a criao de um ambiente de
teste adequado, que permita simular o ambiente de produo.
Ferramentas: softwares necessrios para gerenciar o processo de teste e os
defeitos, preparar as bases de dados, realizar testes unitrios, de integrao,
aceitao, regresso, e demais testes.

Portanto, para implantar um processo de teste de software ser necessrio investir um
valor maior no incio. Entretanto, o retorno desse investimento tende a ser muito maior do
que se os testes no fossem realizados de forma planejada e organizada.


18
A figura abaixo demonstra, de forma simples, o aumento do investimento inicial com a
implantao de um processo de testes bem como retorno de investimento proporcionado.

Figura 3 Economia proporcionada ao investir em testes de software

Como se pode perceber, na imagem, a parte da esquerda representa um projeto que no
possui um processo de teste formalizado. Mesmo no sendo formalizado, esse projeto
consome recursos com testes; visto que alguns testes aleatrios so realizados pelos
desenvolvedores e eventualmente por algum outro membro da equipe. J no projeto da
direita, que possui um processo de teste estabelecido, o custo com a realizao dos
testes aumenta em relao ao anterior (custo com pessoas, ferramentas, etc.) e o custo
das falhas diminui, proporcionando uma economia ao longo do tempo. O "Custo da
Falha", representado de forma resumida na figura, engloba o custo do retrabalho,
correo e prejuzos ocasionados pela falha; desde prejuzo de imagem da equipe
desenvolvedora at prejuzos financeiros, como por exemplo, processos judiciais.


19
Custo da Correo
No processo de desenvolvimento de software com as etapas de: Especificao de
Requisitos, Anlise, Projeto, Implementao e Implantao; quanto mais tarde um defeito
for encontrado, maior ser o custo para corrigi-lo. E no difcil visualizar o motivo desse
aumento, visto que uma simples declarao errada, nos requisitos, pode gerar de duas a
trs decises equivocadas na etapa de anlise/projeto, podendo ocasionar uns vinte erros
introduzidos no desenvolvimento (Black, 2002). como se fosse uma bola de neve que
aumenta na medida em que ela desce morro abaixo.
Essa percepo de que: quanto mais cedo o defeito for encontrado mais barato ser a
sua correo antiga. Barry Boehm j abordava esse tpico em seu artigo de 1976 e
Glenford Myers em seu livro "The art of sotware testing" (A arte de testar software) de
1979. A declarao de Myers ficou famosa, sendo conhecida como a Regra 10 de
Myers, em que ele alega que o custo de corrigir um defeito aumenta 10x por cada etapa
em que o projeto de software avana.
O custo de correo aumenta ainda mais se o erro for detectado externamente (pelo
cliente), aps a entrega do software, do que internamente pela equipe
desenvolvedora/testadora. O especialista Rex Black (mais detalhes sobre ele ao final
desta unidade) estima que um defeito encontrado por um desenvolvedor, custa em mdia
$ 10 para ser corrigido, enquanto que, se for identificado por um testador custar $100 e
pelo cliente $ 1000. Para visualizar melhor esses custos importante pensar no processo.
Quando o desenvolvedor identifica o defeito, ele vai e corrige. Caso esse mesmo defeito
seja identificado por um testador, ele ter que reportar para que o desenvolvedor o
identifique e conserte. Em seguida, uma nova verso dever ser disponibilizada para o
testador verificar se o erro foi de fato corrigido e se nenhum outro foi introduzido com a
correo (realizao do teste de regresso). Portanto, pode-se perceber como mais
caro quando o defeito identificado pelo testador.
Quando o defeito identificado pelo cliente, alm dos passos descritos anteriormente,
existe o aumento do custo com o suporte tcnico que atender o cliente e de implantar a
nova verso do software, sem contar os possveis custos intangveis com processos
judiciais e impactos, na reputao da empresa desenvolvedora (Black,2010).


20
Adicionalmente, com o passar dos anos, os custos podem aumentar de maneira
exorbitante, visto que pode ser difcil encontrar algum desenvolvedor que trabalhou no
software (problema agravado se o software no tiver uma documentao adequada) e/ou
ento encontrar um profissional com experincia adequada em uma linguagem de
programao/plataforma que se tornou obsoleta.
Ento, se fcil perceber pelos motivos citados que quanto mais cedo o defeito for
identificado e corrigido, menor ser o seu custo, por que muitos gestores ignoram a
realizao adequada de testes? A resposta : eles no visualizam o teste como um
investimento.
Normalmente enxergam o teste como uma atividade custosa, que requer muito tempo e
investimento e que no ajudar o software ficar pronto mais cedo, em um cenrio que, na
maioria das vezes, a presso por prazo e as margens de lucro so bem pequenas.
Portanto, para visualizar que o teste deve ser visto como um investimento; importante
observar a situao descrita a seguir.

Retorno de Investimento
Para entender melhor o retorno de investimento proporcionado pelos testes, deve-se
tomar como base o seguinte estudo de caso hipottico, apresentado por Rex Black.
Um software implantando em um cliente possui uma nova verso liberada a cada 3
meses. Em mdia, cada nova verso possui 1000 novos defeitos. A equipe
desenvolvedora desse software encontra em mdia 250 erros antes de liberar a verso,
sendo que o restante (750) encontrado pelo cliente. Tendo como base a estimativa
anterior do prprio Rex Black, que um erro encontrado por um desenvolvedor custa em
mdia $10 e pelo cliente custa $ 1000, esse cenrio, que no possui um processo formal
de teste, gera um custo de $750.000 por verso, e uma insatisfao imensa no cliente.
Para tentar melhorar essa situao, o gerente do projeto consegue investir $ 70.000 por
verso em testes manuais para minimizar os impactos. Sendo assim, a equipe dedicada
para testes identifica mais 350 defeitos que so corrigidos antes de lanar a verso.


21
Partindo da estimativa que cada defeito encontrado por um testador custa em mdia
$100, o retorno do investimento 350%, conforme apresentado na tabela a seguir.

Opes para Investimento em Testes (Adaptado de Rex Black,2010)

TESTES
Sem
Processo
Formal
Processo
Manual
Teste
Automatizado
Equipe
$ 0 $ 60.000 $ 60.000
Infraestrutura
$ 0 $10.000 $10.000
Ferramentas e Automatizao
$ 0 $ 0 $12.500
Total
$ 0 $ 70.000 $ 82.500

Desenvolvimento
Defeitos Encontrados
250 250 250
Custo da Correo
2500 2500 2500

Testes
0 350 500
Custo da Correo
0 35.000 50.000

Suporte ao usurio
750 400 250
Custo da Correo
750.000 400.000 250.000

Custo da Qualidade
Investimento
$ 0 $ 70.000 $ 82.500
Custo da Correo
$ 752.500 $ 437.500 $ 302.500
Total
$ 752.500 $ 507.500 $ 385.000

Retorno do Investimento
N/A 350% 445%
Tabela 1 Retorno de Investimento em Testes adaptado de (Black, 2010)

Percebendo o retorno do investimento, o gerente do projeto consegue pleitear um
investimento de mais $12.500, por verso, para investir em automatizao dos testes,
encontrando 150 defeitos a mais. Dessa forma, o retorno de investimento obtido seria de
445%.


22
Apesar desse estudo de caso ser hipottico, o renomado especialista Rex Black afirma ter
presenciado retorno de investimento, em testes, variando de 50% a 3200%.
Entretanto, assim como qualquer outro investimento, somente disponibilizar a verba no
garantia de sucesso, visto que existem formas corretas e erradas de se investir. Se o
dinheiro no for investido com a equipe, ferramentas e tcnicas adequadas, o resultado
pode ser negativo e frustrante.

Conhea Rex Black:

Rex Black um dos especialistas mais reconhecidos em teste de
software. Autor de livros relacionados aos testes, dentre eles o popular
"Managing the Test Process" com mais de 25.000 cpias vendidas ao
redor do mundo. Tambm palestrante e autor de vrios artigos
(muitos deles podem ser encontrados em http://www.rbcs-us.com/).

Durante 4 anos foi presidente do ISTQB e um dos autores do Syllabus
da certificao desse instituto.


23
UNIDADE 5
Objetivo: Conhecer alguns prejizos causados por falhas de software, visualizando que
em alguns casos os custos podem ser muito altos
Custos das Falhas

O National Institute of Standards and Technology (NIST), ou em portugus Instituto
Nacional de Tecnologia e Padres, uma agncia do Departamento de Comrcio dos
Estados Unidos. Em 2002 o NIST elaborou um estudo para estimar o custo anual
provocado por falhas de software. O estudo foi intitulado "The Economic Impacts of
Inadequate Infrastructure for Software Testing", ou em portugus, "O Impacto Econmico
da Infraestrutura Inadequada para Testes de Software".
O impacto das falhas de software alto devido ao fato de muitos empreendimentos,
desde indstrias medicina, dependerem de software. Segundo estimativas desse
estudo, as falhas de software so predominantes e prejudiciais ao ponto de custar
economia americana $59,5 bilhes de dlares anualmente. Os autores estimaram
tambm que pouco mais de um tero desse valor ($22,2 bilhes) poderiam ser eliminados
com a implantao de processos de testes que permitissem identificar (e
consequentemente corrigir) mais cedo e de maneira mais efetiva os defeitos de software.
Algumas falhas de software podem causar prejuzos imensos. Vamos ver agora alguns
exemplos de falhas de software que viraram notcias.

Erros em escalas da GOL:
Veja a seguir parte da notcia publicada no portal Terra
(http://noticias.terra.com.br/brasil/noticias/0,,OI4602632-EI306,00-
Gol+diz+a+Anac+que+falha+em+software+causou+erro+em+escala.html) sobre o
transtorno provocado por uma falha de software:


24
"Gol diz Anac que falha em software causou erro em escalas
A Agncia Nacional de Aviao Civil (Anac)
informou nesta tera-feira que a companhia area
Gol disse que um problema no software para
planejamento de escala da tripulao gerou dados
incorretos que resultaram no "planejamento
inadequado da malha area e da jornada de
trabalho dos tripulantes". Hoje, a Gol foi convocada
pela agncia a apresentar um plano de ao para
atender os passageiros de voos cancelados ou atrasados. A companhia operava cerca de
70% dos voos atrasados ontem em todo o Pas.
De acordo com a Anac, a Gol afirmou que o problema no sistema aconteceu em julho,
durante um upgrade no programa. "Por essa razo, foi adotada novamente a configurao
de escala do ms anterior", disse a agncia, em nota: O sistema era utilizado h trs
meses, segundo a companhia, e com o conhecimento da Anac.

Autodestruio do Foguete Ariane 501
Em junho de 1996, aproximadamente 37 segundos aps o seu lanamento o foguete
Ariane 501 explodiu em voo.
O foguete possua um sistema referencial inercial (SRI) para medir a trajetria. O SRI 2
era o principal, sendo que o SRI 1 funcionava como sistema redundante para assumir em
caso de falhas no primeiro. Ao invs de enviar os dados corretos da altitude, o SRI 2
enviou um cdigo de erro decorrente de uma falha no software. S que o SRI 1 no pode
entrar em operao, visto que 72 milissegundos antes apresentou o mesmo problema que
o SRI 2.
A falha foi provocada pela converso de um float de 64 bits para um nmero inteiro com
sinal de 16 bits, referente velocidade horizontal para a plataforma. Na tentativa da
converso, foi gerado um nmero maior do que o comportado nos 16 bits. O motivo dessa
converso estar vulnervel no foi identificada, uma vez que nenhum comentrio no


25
cdigo fonte justificava esse fato, sendo que existiam outras converses com a proteo
adequada.
O foguete e a carga destruda estavam avaliados em $ 500 milhes de dlares.

Destruio da sonda da NASA Mars Climate Orbiter
A NASA enviou uma sonda para Marte para poder estudar o clima deste planeta. A sonda
Mars Climate Orbiter deveria entrar na rbita do planeta ao atingir uma altitude
aproximada de 150 km. Porm, devido a um erro de converso de medidas, a sonda
entrou em uma altitude inferior, provocando a sua destruio. A converso que no foi
realizada era de medidas inglesas para o sistema mtrico.
O veculo espacial foi lanado no dia 11 de dezembro de 1998 e seu ltimo sinal foi
recebido em 23 de setembro de 1999.
Os exemplos de incidentes apresentados nesta unidade apresentam alguns prejuzos
financeiros, e de tempo, ocasionados por falhas de software. Existem outras falhas
conhecidas que infelizmente alm das perdas financeiras, provocaram a perda de vidas,
como por exemplo, o caso do Therac-25; um acelerador mdico utilizado para tratar
tumores.
Com uma breve pesquisa na Internet possvel achar vrias outras falhas de software
que ficaram famosas.
possvel inclusive assistir o vdeo de destruio do foguete Ariane 5. Um dos
endereos disponveis : http://www.youtube.com/watch?v=gp_D8r-2hwk


26

Voc j presenciou algum prejuzo provocado por uma falha de software? Qual
(cuidado para no descrever detalhes confidenciais)? Ele poderia ter sido evitado com
a realizao adequada dos testes? Como?


27
UNIDADE 6
Objetivo: Entender a importncia do teste ser abordado como um processo e no como
uma atividade
O Processo de Teste
comum em projetos de software encontrar os testes sendo tratados como uma atividade
dentro do processo de desenvolvimento. Nessa abordagem, muitas vezes os testes so
iniciados aps a etapa de desenvolvimento. A figura abaixo ilustra esse caso.

Figura 4 Abordagem de Testes como uma Atividade no Processo de Desenvolvimento

Entretanto, para aumentar a qualidade do projeto, os testes precisam ter um processo
prprio no sendo mais tratado apenas como uma atividade dentro do processo de
desenvolvimento, conforme apresenta a figura abaixo.


28

Figura 5 Abordagem de Testes com um Processo Prprio

Essa abordagem importante para dar uma nfase maior aos testes. Assim, o teste
passa a ter as etapas estruturadas possuindo atividades, artefatos, mtodos, papis e
responsabilidades. Esse processo deve ser iniciado em paralelo com o incio do projeto
de software e, normalmente, deve ser realizados dentro do prazo do processo de
desenvolvimento, ou seja, de forma geral o cronograma do projeto no ser aumentado
para realizao dos testes.
Mesmo sendo um processo e no mais uma atividade, o processo de teste e o de
desenvolvimento esto interligados (conforme demonstrado a seguir no "Modelo em V"),
mas possuem alguns indicadores distintos. Tome como exemplo o indicador "Defeitos
Encontrados": quanto maior o nmero de defeitos encontrados, mais bem sucedido
considera-se os testes, e menos o processo de desenvolvimento.
Um processo constitudo por um conjunto de tarefas e atividades, sendo que algumas
podem ser sequenciais enquanto outras so realizadas em paralelo. De forma geral, as
principais atividades do processo de teste so: planejamento, preparao, especificao,
execuo e entrega/avaliao (Rios et al.,2007).


29
O Modelo V
A representao grfica que mais utilizada para demonstrar a integrao entre o
desenvolvimento e os testes o Modelo V. Existem algumas variaes do Modelo V, mas
de forma geral ele representado conforme figura abaixo.

Figura 6 Forma usual de representar o Modelo V

Outras formas de representao do modelo V diferentes da figura anterior existem. O
prprio Syllabus (documentao) da certificao de testes ISTQB, cita o modelo V sem
apresentar nenhuma figura e nem mesmo informar os nomes das quatro etapas de
desenvolvimento.
Alguns autores criticam esse modelo, como por exemplo, James Christie. Christie alega
que existem tantas variaes do modelo em V que na prtica podem significar qualquer
coisa. As representaes normalmente compartilham o formato de "V" com uma seta
ligando os estgios equivalentes em cada lado.
Mas qual o significado dessas setas?
1. O teste das entregas de cada etapa do desenvolvimento?
2. O planejamento dos testes em paralelo a cada etapa do desenvolvimento?


30

Seguem abaixo algumas crticas dos equvocos que podem ser ocasionados por conta da
interpretao do modelo V baseados em (Christie, 2008), e aproveitando o "gancho" das
crticas, algumas recomendaes de boas prticas de testes (que na verdade
independem do modelo adotado).
1. Desencoraja a participao do usurio avaliando as funcionalidades e interface
antes da etapa de "Teste de Aceitao", que de acordo com a representao
ocorre mais tardiamente no projeto.
a. Recomendao: Idealmente, a prototipao e testes cedo devem ser
includos para identificar problemas quando so mais baratos de resolver.
No raro encontrar projetos que so submetidos para o cliente aprovar
somente ao final e o cliente no aprova o que foi entregue, gerando um
imenso prejuzo (para ambas as partes) e insatisfao. Portanto o
planejamento do projeto deve contemplar os testes de aceitao em todas
as etapas, submetendo sempre que possvel s telas (mesmo que
prottipos) e funcionalidades para aprovao do cliente.
2. Caso ocorra o atraso no tempo do desenvolvimento, sobrar pouco tempo para
realizao dos testes, visto que a interpretao pode deixar a entender que os
testes so realizados aps o desenvolvimento.
a. Recomendao: importante que os testes ocorram em paralelo durante
todo o processo


31
3. Comear as respectivas revises e testes, em paralelo com as etapas de
desenvolvimento, no deve significar reviso e aceite ao final de cada etapa.
a. Recomendao: Revises e testes devem ser realizados enquanto os
documentos/diagramas so elaborados. Testadores devem se envolver na
reviso de documentos o mais cedo possvel ao longo do ciclo de
desenvolvimento.

Independente da representao grfica utilizada importante visualizar que o processo
de desenvolvimento e o de testes andam juntos para proporcionar um aumento na
qualidade do projeto do software.

Como os testes so realizados na empresa que voc trabalha? Existe algum tipo de
abordagem sistemtica (casos de teste, apoio por ferramentas, automatizao de
testes, definio de papis e processo, etc.)? Quais?


32
UNIDADE 7
Objetivo: Apresentar os fatores envolvidos em um bom planejamento de testes
Planejamento dos Testes

Para elaborar um planejamento de testes, importante identificar as seguintes questes,
conforme aponta McGregor e Sykes (2001):
Quem deve realizar os testes?
Quais partes devero ser testadas e receber mais ateno?
Em qual momento os testes sero realizados?
Como os testes sero realizados?
Quanto de teste adequado?

O planejamento dos testes visa minimizar os riscos e evitar desperdcios de tempo e
dinheiro. Se os testes forem realizados ao acaso, o esforo gasto tende a ser um prejuzo
e no proporcionar um retorno do investimento, visto que muitos defeitos no sero
identificados antes do software ir para produo.
E como em qualquer planejamento, o planejamento de testes aps ter sido realizado no
incio deve ser revisado e atualizado at o trmino do projeto, para no ficar engessado e
desatualizado, permitindo corrigir o rumo na ocorrncia de imprevistos. Se o planejamento
do desenvolvimento mudar, o planejamento de testes tem que ser reavaliado.
Esse planejamento feito em um documento de "Plano de Testes" que essencialmente
deve conter: o escopo, o processo de teste definido, os profissionais, ferramentas,
ambiente/hardware, estimativas financeiras, cronograma e riscos. Esses so itens
importantes, mas a composio do documento varia de empresa para empresa, sendo um


33
fator limitante os recursos disponveis principalmente de tempo e dinheiro. Um exemplo
de modelo de plano de testes o padro IEE 829.
Os autores do livro referncia para a certificao brasileira CBTS citam que o Plano de
Testes deveria seguir o modelo de Plano de Projeto do PMBOK, que o conjunto de
prticas para gesto de projetos, publicado pelo PMI (a principal associao mundial de
gerenciamento de projetos). Eles identificaram que possvel fazer uma relao entre os
dois modelos.
De forma geral, um bom Plano de Testes abordar questes como: o que ser testado, as
funcionalidades que sero testadas e as que no sero testadas em conjunto com o
motivo, o processo com as principais tcnicas e ferramentas que sero utilizadas, os
critrios para considerar os testes concludos, os artefatos que sero produzidos pelo
processo de testes (casos de testes, relatrios, etc.), indicadores de qualidade
(elaborados em conjunto com o cliente), a necessidade de aquisio de suprimentos
como hardware e software, necessidade de treinamento da equipe, as responsabilidades,
riscos do projeto de teste (ex: risco de determinado profissional ficar ausente, ou de ter
que utilizar uma ferramenta nova que ningum tem experincia), risco do negcio e das
funcionalidades do software, custo e cronograma previstos.
Abordando esses itens, o planejamento visa proporcionar aes preventivas ao invs de
reativas, de forma que os riscos sejam minimizados e as medidas (como por exemplo,
compra de hardware/software) sejam realizadas no momento certo para evitar atrasos.

Anlise dos Riscos
O planejamento est fortemente relacionado com a avaliao dos riscos que
fundamental para definir o que ser testado e em qual momento os testes podem ser
considerados terminados. Esse ponto bem importante porque no tem como realizar
testes exaustivos para garantir que o sistema est livre de defeitos ento preciso
garantir que as partes mais crticas do sistema foram testadas.
So avaliados os riscos, ou seja, potenciais situaes que se acontecerem podem gerar
diversos tipos de prejuzos e perdas para a organizao. Dessa forma, as ameaas e


34
vulnerabilidades so analisadas para identificar potenciais formas de controle que podem
prevenir, ou minimizar os prejuzos.
A anlise do risco avalia a probabilidade de ocorrncia com gravidade do impacto do dano
causado. Essa anlise deve ser feita ao longo de todo o projeto, uma vez que a gravidade
e o impacto podem mudar com o decorrer do tempo. Por exemplo, no incio do projeto a
probabilidade de invaso ao software quando estiver pronto pode ser alto, mas no
decorrer do desenvolvimento o surgimento de um componente de segurana que pode
ser acoplado ao software diminui os riscos.
A avaliao deve contemplar tanto os riscos referentes ao projeto e processo de teste em
si, quanto os riscos inerentes ao negcio, como por exemplo, as funcionalidades que
contemplam reas mais crticas.
Quanto ao projeto de teste os riscos j comeam no oramento e no cronograma. Se a
verba e/ou o tempo disponvel para os testes forem poucos, os testes sero realizados
inadequadamente, aumentando muito a probabilidade dos defeitos serem encontrados no
software j implantado, potencializando assim os prejuzos. Muitas vezes, a empresa que
est orando o desenvolvimento do software no contempla na proposta comercial o
custo e tempo para os testes, percebendo que tomou prejuzo somente no momento dos
testes de aceitao quando o cliente no aprova o que lhe foi apresentado. Portanto, no
fechamento do contrato fundamental negociar prazos e custos adequados que
contemplem a realizao dos testes. Outros riscos envolvem a qualificao da equipe,
utilizao de uma ferramenta nova para realizao dos testes, ambiente de teste pouco
parecido com o ambiente de produo, inadequao de metodologias, processo e
controle dos artefatos de teste.
A realizao dos testes custa dinheiro e o investimento necessrio aumenta na medida
em que a cobertura dos testes aumenta. A anlise de riscos bem realizada proporciona
uma destinao coerente dos esforos, priorizando as partes que apresentam maior
probabilidade de ocorrncia x impacto de perda (risco) de forma que o teste tenha o maior
nvel possvel de confiabilidade no tempo disponvel (Rios et al., 2007).


35
Portanto, necessrio realizar uma anlise de custo x benefcio para avaliar at que
ponto vale a pena investir em testes, respondendo perguntas como: "O custo da
ocorrncia do defeito muito maior do que o custo da sua preveno?".
Uma forma de se estabelecer a prioridade definir quantitativamente a probabilidade e
severidade (impacto) da ocorrncia. A tabela a seguir apresenta um exemplo simples de
anlise quantitativa de risco utilizando escalas como 1, 5, 10, 15; sendo que quanto maior
o nmero maior a prioridade.

Funcionalidade Probabilidade
Severidade
(Impacto)
Prioridade
(P.x S.)
Realizar Depsito em Conta 15 15 225
Encerrar Conta 5 10 50
Cadastrar Fornecedor 1 1 1
Tabela 2 Exemplo simples de clculo de prioridade de funcionalidade a ser testada

Algumas das formas de determinar o risco so: intuio baseada na experincia de
profissionais, consenso da equipe e estimativas. Essa ltima se baseia em dados para o
clculo, como por exemplo: "Quanto custa cada hora que essa mquina fica parada sem
produzir?", "Quanto se perder, por minuto, se o site ficar fora do ar?".
Adicionalmente, pode-se utilizar tambm o Princpio de Pareto adaptado, em que 20% do
software so responsveis por 80% das funcionalidades mais utilizadas. Para determinar
quais so essas funcionalidades mais utilizadas, se o software j estiver em produo
(vale lembrar que as manutenes tambm devem ser testadas), pode-se monitorar as
estatsticas de uso, e caso o software no esteja implantado, perguntar aos usurios.
Porm, importante perceber que o Princpio de Pareto, por si s, pode no ser
suficiente, visto que uma funcionalidade pode ser muito importante e raramente utilizada,
mas se falhar pode causar um grande prejuzo. Portanto, deve-se avaliar quando essa
informao ser til, atrelada a outras estimativas.


36
Trmino dos Testes
Um ponto muito importante relacionado ao projeto de testes o momento de identificar o
seu fim, para no acontecer: testes de menos, com uma interrupo, muito antes de
atingir a cobertura adequada (essa situao mais comum, principalmente por causa das
presses por prazos, ou inadequao em definir a cobertura apropriada); ou testes de
mais, implicando em custos, acima do necessrio, com o excesso de testes, pois o custo
adicional, com os testes, no compensa o custo que seria provocado pela falha.

Figura 7 Custo do teste comparado com nmero de defeitos que faltam ser corrigidos (Rios et
al.,2007)

Portanto, importante identificar o ponto de equilbrio. Esse ponto de equilbrio est
relacionando com aspectos de criticidade: quanto mais crtico o negcio, mais testes
devem ser realizados. Por exemplo, os testes de um software para controle de rota de
espaonaves muito mais crtico do que um software para gesto financeira pessoal, de
forma que o primeiro requer muito mais testes, visto que, o prejuzo ocasionado por uma
possvel falha pode ser muito alto.


37
Mas como se pode identificar esse ponto de interrupo? Rios e colaboradores (2007)
apontam algumas sugestes que podem ser utilizadas em conjunto para definir o
momento de trmino:
Quando intervalo de ocorrncia e identificao de defeitos aumenta muito de
horas para dias;
Quando a nova realizao de um ciclo de teste acha menos do que um nmero
determinado de "bugs";
Quando atinge determinado valor de cobertura sem descobrir novos defeitos;
De acordo com o nmero de defeitos encontrados e ainda no corrigidos,
considerando a respectiva severidade (ex: "existem defeitos, de alto ou mdio
risco, que ainda no foram corrigidos?").


38
UNIDADE 8
Objetivo: Entender os aspectos envolvidos com a preparao do ambiente de teste
Ambiente de Testes

preciso planejar tambm o ambiente em que os testes devem ser realizados. Engana-
se quem pensa que o ambiente se refere apenas ao hardware necessrio; ele engloba
toda a estrutura envolvida com a execuo dos testes, como por exemplo: sistemas
operacionais, browsers compatveis, a massa de dados a ser utilizada, e assim por diante.
As caractersticas do ambiente vo depender de alguns fatores. Quanto mais crtico o
software, mais o ambiente de teste deve ser parecido com o ambiente de produo. E em
alguns casos, o ambiente de produo pode ser o mais variado possvel. Por exemplo,
um grande site de vendas precisa rodar perfeitamente em diferentes browsers (e em
diferentes verses do mesmo) combinados com diferentes sistemas operacionais. Se uma
atualizao do site no rodar em um determinado browser padro, o prejuzo pode ser
grande; visto que seus clientes em um segundo podem acessar o site do concorrente.
Assim, a preparao do ambiente deve levar em considerao as caractersticas de cada
projeto. Um software com arquitetura cliente-servidor deve permitir a realizao adequada
de testes em ambientes que simulem bem a parte do cliente e tambm em ambientes que
simulem a parte do servidor.
Um software que precise ser testado com diferentes sistemas operacionais e
configuraes; pode utilizar as mquinas virtuais (ou "Virtual Machines"). Um mesmo
computador pode ser utilizado com diferentes mquinas virtuais. Cada mquina virtual
pode receber um sistema operacional diferente, reduzindo os custos. Assim, um nico
computador com um Windows 7 (ou qualquer outro sistema operacional) instalado, pode
ter uma mquina virtual com o Linux Ubuntu 10.10, outra com o Windows XP, outra com
Mac O.S, etc. A referncia do CBTS lembra um ponto importante; normalmente esses
ambientes no so recomendados para teste de performance, uma vez que a mquina


39
virtual pode no ter a quantidade suficiente de recursos alocados (ex: memria e
processamento) por estar sendo compartilhada com o sistema operacional do
computador.
Existem casos em que determinadas condies so proibitivas para a reproduo do
ambiente no local do desenvolvimento. Pode-se citar como exemplo fictcio, mas provvel,
uma indstria que contrata uma empresa para desenvolver um software. Essa indstria
pode ter uma estrutura de hardware muito cara que pode custar muito mais do que o
software que est sendo desenvolvido. Nesse caso, a empresa desenvolvedora tem que
realizar alguns tipos de testes no ambiente de testes da indstria, enviando alguns
participantes de sua equipe para l. importante perceber, que essa situao deve ser
prevista no planejamento dos testes.

Massa de Dados
A necessidade dos dados que sero utilizados nos testes varia de acordo com a
necessidade de cada tipo de teste. Os testes de unidades e integrao normalmente no
precisam de muitos dados, enquanto os testes de performance precisam, e para os testes
de homologao e aceitao interessante que tenha uma quantidade representativa.
Em alguns casos, ter dados reais de uma base j em produo relevante. Mas nem
sempre possvel obt-los seja porque no existe uma base de dados de produo
(sistema novo) ou porque a poltica de privacidade da empresa contratante no permite
que esses dados sejam acessados por terceiros. Caso seja possvel obter os dados reais
importante ter cuidado para camuflar dados confidenciais, substituindo-os ou
convertendo-os no momento da importao. Tambm preciso, avaliar se necessrio
utilizar todos os dados, ou se apenas uma parte deles seria mais adequada, filtrando o
que for relevante para reduzir a base. Em alguns casos, como nos testes de performance
e estresse, os dados geralmente no precisam ser reais, ou seja, em muitos casos podem
ser gerados aleatoriamente.
Outro ponto importante a se observar, na realizao de testes com dados reais, em
relao ao disparo de e-mails. Se a aplicao possui funcionalidades que disparam e-
mails, na base de teste fundamental adotar uma poltica que tratem os mesmo,


40
adotando medidas como substituir os e-mails originais por e-mails de teste, por exemplo.
Essa poltica visa evitar problemas maiores com as pessoas cadastradas no sistema.
Alm de ser incmodo para pessoa receber e-mails desse tipo, uma informao falsa
pode ser enviada causando confuso e problema. Por exemplo, se estiver sendo
realizado um teste em um sistema bancrio e um cliente que possua uma fortuna recebe
um e-mail disparado pelo ambiente de testes informando que sua conta foi zerada,
certamente seria gerado um transtorno. Outro ponto que deve ser observado, que a
aplicao no ambiente de testes deve estar apontando para um banco de dados de
testes, pois em alguns casos, por descuido, eles podem estar apontando para o banco de
produo, ocasionando a perda de dados importantes.
Quando no for possvel, ou no for necessrio obter dados reais, de acordo com o
objetivo e necessidade de volume dos testes, os mesmos podem ser gerados
manualmente ou ento automaticamente; sendo gerado de forma aleatria por alguma
ferramenta.
Como diferentes tipos de testes demandam de diferentes tipos de dados, vrias bases
com propsitos distintos so criadas. Aps essa criao, interessante fazer o backup
dessas bases, armazenando-os de forma adequada e categorizada, para futura
reutilizao em testes de regresso ou outros. Por exemplo, suponha um sistema que
gerencia planos de sade que de acordo com a idade do cliente cadastrado o valor e os
benefcios mudam. Os casos de testes vo ser elaborados para exercitar essa situao
de forma que um determinado cliente seja "envelhecido" nos testes, passando por
diferentes idades. Assim, um teste pode comear com "Joo da Silva" com 5 anos de
idade e no final dos testes, ele estar com 75 anos. Aps a realizao de alteraes no
sistema os testes de regresso vo precisar que "Joo da Silva" tenha 5 anos novamente,
bastando para isso restaurar a base previamente criada com essas condies.

Ferramentas
Faz parte de preparao, e utilizao do ambiente, o uso de ferramentas. As ferramentas
visam apoiar diversos aspectos relacionados aos testes, desde a gesto do processo de
teste em si at a execuo dos mesmos. Portanto, existem ferramentas para gerenciar os


41
testes, controle de defeitos, cobertura de cdigo e ainda, realizar testes de estresse,
facilitar os testes unitrios, comparar os resultados dos testes, dentre outros. Existem
ferramentas que atuam sobre uma atividade especfica enquanto outras contemplam mais
do que uma.
Apenas a aquisio da ferramenta no condio suficiente para obter o sucesso na
atividade que ela suporta. Portanto, existem os benefcios que podem ser conquistados e
tambm existem os riscos que so apresentados abaixo, baseados na referncia da
certificao do ISTQB:
Alguns possveis benefcios:
o Reduo de trabalhos repetitivos (ex: execuo de testes de regresso)
o Avaliao dos objetivos (ex: nmero de defeitos, cobertura de cdigo)
o Maior consistncia e possibilidade de repeties (ex: testes realizados por
uma ferramenta)
o Facilidade de acessar as informaes sobre os testes (ex: estatsticas e
grficos referentes ao progresso do teste, como nmero de defeitos graves
que faltam ser corrigidos)
Alguns riscos potenciais:
o Criar expectativas falsas sobre a ferramenta, como por exemplo,
funcionalidades oferecidas e facilidade de uso;
o Subestimar o tempo necessrio para iniciar o uso da ferramenta, assim
como, custo e esforo necessrio para conseguir utilizar a mesma;
o Subestimar o esforo necessrio para manter atualizados os artefatos
gerados pelas ferramentas;
o Tentar utilizar a ferramenta para tudo, mesmo quando a realizao manual
seria mais adequada.

Ao longo deste Mdulo, sero apresentadas algumas ferramentas gratuitas, que se forem
bem empregadas podem auxiliar bastante nos testes. Essas ferramentas servem para
demonstrar conceitos para voc saber escolher qual tipo de ferramenta ser adequada ao


42
seu projeto. Entretanto, o Mdulo no tem a pretenso de abranger todos os aspectos
dessas ferramentas, at mesmo porque o manual delas extenso. Assim, problemas com
instalao e utilizao das ferramentas no devem ser retiradas na sala de aula, e sim
nos manuais encontrados em fruns de discusso da internet, dentre outros meios
adequadamente disponveis na web para essa finalidade.
Algumas ferramentas demonstradas so especficas para linguagem de programao
Java. Uma vez entendido os benefcios oferecidos por determinado tipo de ferramenta,
independente da linguagem de programao, basta pesquisar na internet por uma
ferramenta similar para a sua linguagem de programao preferida.

Existem ferramentas que facilitam a gerao, extrao e manipulao de
dados, como por exemplo a ferramenta gratuira Kettle da suite Pentaho,
disponvel em http://kettle.pentaho.com/.
Para crirar as "Virtual Machines" uma opo gratuita o Virtual Box -
http://www.virtualbox.org/.


43
UNIDADE 9
Objetivo: Apresentar as abordagens para montar a equipe de testes, bem como os papis
existentes
A Equipe e os Papis nos Testes

Conforme visto anteriormente, as atividades relacionadas com os testes devem ser
iniciadas junto com projeto de software. Dessa forma, a equipe de testes inicia sua
participao no incio do projeto para detectar defeitos o mais cedo possvel, visando
evitar a propagao dos mesmos e tentar corrigi-los enquanto os custos so menores.
A equipe de testes utilizar os artefatos gerados pela equipe de desenvolvimento para
test-los ou planejar testes de outros artefatos.
Para montar a equipe de testes, existem algumas abordagens que vo desde utilizar os
prprios desenvolvedores at terceirizar os testes para equipe externa. A estratgia
utilizada depende muito das condies do projeto, como custo, prazo, dentre outros. O
ideal uma equipe de testes dedicada (seja ela interna ou terceirizada), mas muitas
vezes esse objetivo difcil de alcanar por restries financeiras. Mas importante ter
em mente que: dificilmente se obtm resultados satisfatrios quando o desenvolvedor
testa o prprio cdigo. Alguns motivos so:
O testador precisa trabalhar de maneira isenta e independente e os seres humanos
tendem (mesmo que de forma inconsciente) a encobrir os seus prprios enganos.
difcil ter motivao psicolgica para elaborar casos de testes que mostram que
seu cdigo possui defeitos
Ao desenvolver utilizou-se uma lgica de raciocnio que precisa ser modificada,
para tentar identificar os possveis defeitos.


44
O desenvolvedor possui uma lista de atividades para desenvolver e normalmente
fica ansioso. Quando termina uma atividade, tem a inteno de logo comear outra
e no parar e ficar testando o que j fez.
Essas dificuldades no so exclusivas de desenvolvedores de software, por isso, esto
presentes em qualquer tipo de construo intelectual. Voc j tentou revisar um texto
depois que escreveu? E revisar novamente aps outra pessoa ter feito uma reviso
seguida de correes? Muitas pessoas consideram essa atividade torturante.

Abordagens para montar a equipe
A seguir, algumas vantagens e desvantagens de montar a equipe de testes com os
desenvolvedores e outra com profissionais designados somente para essa funo, com
base na referncia da certificao CBTS (Rios et al., 2007).
1. Alocar equipe de desenvolvimento para realizar os testes
Nesse caso, um desenvolvedor (ou analista) deve testar a funcionalidade do outro, de
forma que o responsvel nunca deve testar o que ele mesmo produziu (com exceo dos
testes unitrios e alguns tipos de integrao).
Para isso, importante que os desenvolvedores passem por treinamentos que permitam
desempenhar melhor a funo de testador, adquirindo conhecimentos com tcnicas,
documentos e ferramentas de testes.
Apesar dessa abordagem envolver menores investimentos iniciais e permitir alcanar
resultados positivos, o gerenciamento passa ser mais trabalhoso, uma vez que
necessrio organizar o tempo e sincronizar cronogramas de forma a no atrapalhar o
trabalho do outro desenvolvedor (seja por interrupo ou espera da realizao dos testes
para poder prosseguir).
Alm da dificuldade de sincronizar cronogramas, outros riscos envolvidos so: os
desenvolvedores tero uma tendncia a realizar os testes de maneira mais informal.
Assim, dificilmente mantero os documentos de testes atualizados, portanto, no tero
conhecimento a respeito do negcio.


45
2. Alocar equipe independente para realizar os testes
A equipe independente pode ser da prpria empresa desenvolvedora ou ento uma
equipe externa, terceirizada. Essa abordagem tem um custo inicial maior, visto que mais
pessoas estaro envolvidas e alocadas no projeto. Porm, tende a proporcionar um
retorno financeiro maior ao longo do tempo, principalmente se for contabilizado o custo de
corrigir os defeitos encontrados no software em produo.
A qualidade final maior devido : dedicao de tempo maior, conhecimento mais
especializado nas tcnicas, ferramentas e metodologias de teste.
Para funcionar bem, preciso gerenciar alguns pontos, como por exemplo: a equipe de
desenvolvimento pode achar que a responsabilidade sobre a qualidade somente da
equipe de testes, diminuindo o seu padro de qualidade e existe uma tendncia de
desentendimento entre as duas equipes, que pode ser ocasionado principalmente se os
testadores reportarem os erros com linguagem inapropriada (ex: deboche, agressividade,
etc.).
Beizer j dizia, em 1990: "Testadores, quebrem o software como de sua
responsabilidade, e teste com fora, mas no sinta prazer com a dor do programador"
(traduo livre).

Papis no Processo de Teste
A equipe de desenvolvimento responsvel por realizar os testes unitrios e de
integrao. Em relao equipe de testes, normalmente os papis existentes so:
Gerente de Teste: esse papel semelhante ao gerente de projetos, e normalmente
encontrado apenas em equipes maiores.
Lder do Projeto de Teste: lidera um projeto de teste especfico
Arquiteto de Teste: tem como responsabilidade preparar o ambiente de testes e
escolher as ferramentas que sero utilizadas
Analista de Teste: elabora os casos de teste


46
Testador: executa os casos de teste
Pode ser que profissionais acumulem alguns papis (tanto de teste como de
desenvolvimento), de acordo com a necessidade e porte da equipe e projeto. Em relao
automatizao dos testes e aos testes de performance, essa atribuio, dependendo da
equipe, fica sob responsabilidade do testador ou do analista de teste.

Certificaes para Profissionais de Testes
Existem no mercado vrias certificaes para os profissionais de testes. Abaixo so
relacionadas trs delas (2 delas j citadas neste mdulo) que so bem aceitas no Brasil,
juntamente com algumas informaes adicionais. Vale ressaltar que essas informaes
servem apenas para dar uma pequena noo, visto que os valores, tempo, nmero de
questes podem mudar.
CBTS - Certificao Brasileira de Teste de Software
o ALATS (Associao Latino-Americana de Teste de Software)
o Material de apoio para a certificao: Livro Base de Conhecimento em Teste
de Software, 2 edio.
o Valor: R$ 300 reais.
o Nmero de Questes: 100 questes.
o Percentual de Acerto para aprovao: 75%
o Durao: 3 horas.
o Formato: Mltipla escolha.
o Site: http://www.alats.org.br

CTFL Foundation - Certified Tester, Foundation Level
o ISTQB(International Software Testing Qualifications Board)
o Material de apoio para a certificao: "Foundation Level Syllabus" e
"Glossary of Terms" (ambos possuem traduo para portugus).
o Valor: R$ 350 reais.
o Nmero de Questes: 40 questes.


47
o Durao: 1 hora.
o Formato: Mltipla escolha.
o Site: http://www.bstqb.org.br/

CSTE - Certified Software Tester
o QAI - Quality Assurance Institute
o Material de apoio para a certificao: Common Body of Knowledge(CBOK).
o Valor: U$ 350 dlares.
o Nmero de Questes: 100 mltipla-escolha e 20 dissertativas curtas
o Durao: 4 horas e meia.
o Formato: Mltipla escolha e dissertativa.
o Site: http://www.softwarecertifications.org/qai_cste.htm

Uma alternativa de terceirizao da equipe de testes que vem ganhando popularidade,
principalmente no exterior o "CrowdTest" (algo como"teste da multido").

Tarefa Dissertativa
Acesse a sua sala de aula para realizar a seguinte tarefa dissertativa:
Pesquise em artigos e sites e faa uma sntese, com suas prprias palavras, sobre
"CrowdTest".


48
UNIDADE 10
Objetivo: Entender a importncia de realizar revises e inspees nos artefatos do
processo de desenvolvimento
Tcnicas Estticas - Reviso e Inspeo

As tcnicas de Teste Dinmico necessitam da execuo do cdigo fonte para serem
realizadas. Portanto pode-se citar como exemplo, a execuo dos testes unitrios e dos
testes de performance como tcnicas de Teste Dinmico.
J as tcnicas de Teste Esttico no esto relacionadas execuo do cdigo fonte, que
pode muitas vezes nem existir ainda. So exemplos de testes estticos, as revises de
artefatos como especificao de requisitos, diagrama de classes, inspeo do cdigo
fonte, dentre outros. Portanto, muitas das tcnicas de Teste Esttico so realizadas
"manualmente", como a leitura de documentos para identificar inconsistncias.
Como estudado anteriormente, quanto mais cedo um defeito for identificado, menor o
custo da sua correo. Para evitar que defeitos introduzidos nos artefatos, como
especificao de requisitos, diagramas de classe, etc., se propaguem para os demais
artefatos, importante realizar a reviso desses documentos.
Para facilitar a leitura, os defeitos dos artefatos citados nesta Unidade, so mais
abrangentes do que o conceito de defeito que ser estudado, abstraindo o conceito para
qualquer tipo de problema. Ao revisar os requisitos e diagramas os tipos de problema
procurados so (Kalinowski,2008):
Omisso: falta de informaes relevantes a respeito do sistema, como por
exemplo, parte importante no definida, ausncia de classes, diagramas, etc.
Ambiguidade: a descrio do texto ou diagramas permite que a mesma informao
seja interpretada de diferentes formas


49
Inconsistncia: informaes no mesmo artefato ou em artefatos distintos so
conflitantes entre si
Fato Incorreto: a informao textual ou diagramtica no condiz com a verdade
Informao Estranha: informaes que no so necessrias ou no so utilizadas
Outros: os demais tipos de defeito, como posicionamento errado de informaes
em determinada seo.

A realizao da reviso deve iniciar o quanto antes e no somente ao trmino de uma
fase. As revises podem seguir processos informais ou formais. Segundo o Syllabus do
ISTQB, a reviso formal normalmente contempla as etapas de planejamento, kick-off,
preparao individual, reunio de reviso, correo e acompanhamento. No planejamento
so definidas as tcnicas a serem empregadas e os revisores, dentre outros. A fase de
kick-off contempla a distribuio dos documentos, e explicao para os participantes
sobre os objetivos, documentos e processos. A preparao individual consiste na reviso
individual antes da reunio, de forma que cada revisor identifique os problemas,
comentrios e sugestes. Na reunio de reviso, os participantes discutem as anotaes
realizadas previamente e decidem com a ajuda do moderador os defeitos (e os pontos
que no so defeitos) e possveis encaminhamentos. O retrabalho (correo) a etapa de
correo dos defeitos, normalmente pelo autor do artefato. O acompanhamento consiste
em verificar se os defeitos foram devidamente corrigidos e a necessidade de uma nova
reviso.
As abordagens para leitura normalmente so: ad hoc, baseadas em checklists e tcnicas
de leitura de software. A leitura ad hoc no possui um mtodo definido, sendo sua eficcia
dependente da habilidade do revisor. A leitura baseada em checklist (ou lista de
verificao) no apresenta uma metodologia sistemtica, mas sim um conjunto de
caractersticas de defeitos conhecidos previamente, que devem ser verificados (Falbo,
2008). J a tcnica de leitura de software visa adotar uma postura mais sistemtica na
realizao da reviso. Pode-se citar como exemplo, a Tcnica de Leitura Orientada a
Objetos (OORT - Object-Oriented Reading Techniques). A OORT estabelece
procedimentos para reviso de documentos e diagramas do projeto orientados a objeto


50
(Mafra e Travassos; 2005). Duas dimenses so analisadas, a leitura horizontal
(verificao de consistncia de artefatos de uma mesma fase) e leitura vertical
(verificao de artefatos produzidos em fases diferentes) (Falbo, 2008). Assim, so
apresentadas tcnicas que verificam, por exemplo, a consistncia dos casos de uso com
o diagrama de classes.
Na inspeo do cdigo fonte, algumas atividades podem ser apoiadas por ferramentas.
Por exemplo, a ferramenta Checkstyle (http://checkstyle.sourceforge.net/) verifica se o
cdigo fonte dos desenvolvedores segue um padro como nomenclatura de mtodos,
cdigo duplicado, etc. J a ferramenta gratuita FindBugs (http://findbugs.sourceforge.net/),
para Java, analisa estaticamente o cdigo fonte e aponta possveis defeitos, baseados em
padres conhecidos. Dentre as inmeras anlises realizadas, aponta variveis que no
so inicializadas, possveis ocorrncias de excees de "null pointer", indicao de
problemas de performance com cdigo desnecessrio, tratamento incorreto de excees,
etc.


51
UNIDADE 11
Objetivo: Conhecer os conceitos e contedo dos casos de Teste
Casos de Teste

O Caso de Teste um dos artefatos do processo de teste. Seu objetivo documentar os
cenrios de teste de forma a verificar se os resultados esperados esto sendo atingidos.
Normalmente, utiliza-se os casos de uso (do processo de desenvolvimento) para elaborar
os casos de teste, sendo que cada cenrio do caso de uso pode ser coberto por um ou
mais casos de testes. Entretanto, existem alguns casos de testes que so baseados em
requisitos no funcionais, como por exemplo, desempenho, e dessa forma no utilizam os
casos de uso como base.
Como os casos de uso so utilizados como base, caso eles sejam alterados os casos de
teste precisam ser revisados. Por isso, importante manter a rastreabilidade entre a
especificao de requisitos e casos de teste. Uma boa ferramenta de gesto de teste
deve oferecer a funcionalidade para realizar essa rastreabilidade.

Contedo do Caso de Teste
O contedo do caso de teste, normalmente, composto por valores de entrada, pr-
condies de execuo, os passos/procedimentos e resultados esperados. Essas
informaes normalmente so utilizadas, mas o contedo do documento pode ser
adaptado pela equipe.
Segue abaixo uma possibilidade de campos para compor um caso de teste:
Autor: autor do caso de teste
Id: nmero que identifica o caso de teste
Ttulo: deve descrever brevemente o caso de teste


52
Pr-condies: condio que deve ser atendida antes do teste ser executado. Por
exemplo, pode ser necessrio ter um cliente cadastrado com um filho de 17 anos
Dados de entrada: indica os dados que sero informados durante o teste
Procedimentos: descreve os passos que devem ser realizados para executar o
teste, indicando qual passo realizado pelo testador e qual realizado pelo
sistema.
Dados de sada: dados que foram modificados ou produzidos durante a execuo
do teste.
Ps-condies: situaes que devem ser verificadas ao trmino do teste, como
mudanas de status e outras alteraes ocasionadas pelo teste.
Ambiente: utilizado para informar caractersticas do ambiente, como por exemplo,
uma verso do sistema operacional e do browser.
Tipo de execuo: se o teste deve ser executado manualmente ou
automaticamente
Rastreabilidade: indica os artefatos do desenvolvimento (ex: o caso de uso,
requisito) que serviram como base para criao do caso de teste.
Observaes: informaes adicionais que o analista de teste queira passar para o
testador

Esses campos podem ser modificados de acordo com a necessidade da equipe, que pode
querer, por exemplo, unificar os "dados de sada" e "ps-condies" que compem os
resultados esperados. importante ressaltar que os resultados esperados devem estar
presentes, caso contrrio o testador pode julgar um resultado errado, mas aparentemente
correto como vlido.
A seguir apresentado um caso de teste elaborado a partir de um cenrio de caso de uso
imaginrio, de nmero RN025, que especifica um depsito em conta bancria,
determinando que os depsitos acima de R$ 14.999,99 devem enviar um e-mail para o
dono da conta.


53
<CT0125 - Realizar depsito de R$ 15.000,00>
Autor Joo Gomes Pereira
Data 14/08/2011
Pr-condies O usurio deve possuir uma conta ativa e estar logado no
sistema
Dados de entrada Usurio: Andr Leal, Conta: 123456, valor para depsito
R$ 15.000,00
Procedimentos PA: O usurio informa que deseja depositar R$ 15.000 em
sua conta
PS: O sistema exibe uma mensagem de confirmao
PA: O usurio confirma a operao
PS: O sistema atualiza o saldo da conta, sendo esse = saldo
inicial + R$ 15.000,00, e envia um e-mail para o endereo
cadastrado do usurio

Dados de sada Saldo = saldo inicial + R$ 15.000,00
Ps- Condies 1 - O saldo da conta atualizado
2 -Um e-mail foi enviado para o endereo especificado no
cadastro do usurio, informando a operao realizada e o
novo saldo
Ambiente Sem restries especficas
Tipo de Execuo
(ex:Automtica, Manual)
Manual
Rastreabilidade RN025
Observaes Gerais N/A
Figura 8 Exemplo de um caso de teste

O exemplo acima apresenta um caso de teste para o requisito RN025. Outros casos de
testes deveriam ser elaborados para o mesmo requisito, como depsito para conta
inativa, depsito de valor negativo, dentre outros. Supondo-se que o mesmo requisito
especificasse que depsitos acima de R$ 30.000,00 gerassem pontuao extra no
programa de fidelidade. Para realizar um teste com depsito de R$ 29.999,99 um novo
caso de teste teria que ser elaborado.
O caso de teste acima foi apresentado dessa forma, propositalmente, para mostrar que
para generalizar e reaproveitar o caso de teste; importante que os valores possam ser
variveis. Para generalizar, o nome do caso de teste deveria ser mudado, passando para
algo do tipo "Realizar depsito de valores que enviam e-mail, mas no geram pontuao
extra" e nos procedimentos e dados de sada, ao invs de colocar o valor fixo R$


54
15.000,00, o texto descreveria que seria um valor informado pelo usurio, de forma que
ficasse genrico o suficiente para permitir que os valores variassem nos "dados de
entrada". Esse conceito chama-se DDT (Data Driven Test, ou em portugus, Testes
Orientados a Dados) que sero abordados mais adiante.

Caractersticas e Potenciais Problemas
A referncia para certificao CBTS apresenta algumas caractersticas, problemas e
recomendaes interessantes a respeito dos casos de teste, que so apresentados a
seguir.
As caractersticas de qualidade de um caso de teste so:
Efetivo: deve testar o que foi planejado
Econmico: no deve possuir passos desnecessrios
Reutilizvel: deve ser possvel re-executar (muito importante para os testes de
regresso)
Rastrevel: identifique o requisito que est sendo testado
Autoexplicativo: qualquer testador deve ser capaz de executar
A referncia do CBTS apresenta tambm problemas que precisam ser controlados pelo
gerenciamento de testes durante todo o projeto.
Mudana de Requisitos: importante tentar identificar quais os requisitos que
apresentam os maiores riscos de mudana, e escrever primeiro os requisitos que
no sero impactados pela mudana. A reviso dos casos de testes produzidos
implica em tempo e custo. O gerente de projeto deve ter conhecimento desses
itens e definir a prioridade do que deve ser refeito, dando prioridade aos requisitos
de maior risco.
Mudana de cronograma: Se o prazo para elaborao dos casos de teste for
reduzido por alguma razo, o gerente do projeto deve participar na escolha da
prioridade, de forma que os cenrios de maior risco sejam elaborados antes. S se


55
deve considerar aumentar a equipe se houver tempo suficiente para treinamento e
adaptao dos integrantes novos
Rotatividade da equipe: Todo participante novo deve entender os objetivos,
cronograma e organizao do projeto. Eles devem ter acesso documentao do
software para conhecer primeiro as regras de negcios e s ento elaborar os
casos de teste. importante que um profissional mais experiente revise os
artefatos produzidos pelos novos integrantes.

Existem tcnicas e critrios de testes que permitem otimizar a definio dos casos de
testes.
Acesse sua sala de aula para ler um trecho do artigo "Introduo a Teste de Software", de
Arilo Neto, publicado na primeira edio da Revista Engenharia de Software. O trecho
selecionado e disponibilizado aborda os critrios: "Particionamento em Classes de
Equivalncia","Anlise do Valor Limite" e "Grafo de Causa-Efeito"


56
UNIDADE 12
Objetivo: Conhecer os aspectos da execuo dos testes, utilizao de testes orientados
dados (DDT) e quando os testes devem ser automatizados.
Execuo dos Testes

As informaes a respeito da execuo dos testes devem ser armazenadas por serem
preciosas para acompanhamento e tomada de deciso. A partir desse registro possvel
saber quantos testes foram realizados, quantos foram bem sucedidos, quantos falharam e
quantos no foram executados. Assim, consegue-se cruzar informaes sobre os testes,
riscos e prioridades, obtendo informaes do tipo "quantos testes de partes de alto risco
falharam". Uma boa ferramenta de gesto de testes deve permitir o cadastro dessas
informaes, bem como emitir relatrios com esses indicadores citados.
Na execuo, outra informao valiosa que deve ser registrada a respeito dos defeitos
encontrados. Essa informao dever ser salva em uma ferramenta de "Gesto de
Defeitos", que ser tratada adiante.
Durante a execuo, de acordo com os tipos de defeitos encontrados, possvel
identificar se o desenvolvedor liberou o cdigo para teste antes do momento adequado.
Se muitos defeitos e/ou defeitos primrios forem encontrados durante o teste (defeitos do
tipo que deveriam ser identificados nos testes unitrios e de integrao do desenvolvedor)
significa que o cdigo foi liberado para o teste antes do tempo. Esse fato representa um
custo adicional, j que o testador vai testar funcionalidades que no esto
adequadamente finalizadas. Vai gastar tempo registrando esses defeitos que poderiam
ser identificados pelo desenvolvedor, e depois ter que realizar os mesmos testes,
novamente, para saber se foram corrigidos. Portanto, o cronograma para realizao dos
testes poder ser prejudicado, portanto o gerente de testes e de projeto devem tomar as
devidas providncias.


57
Ainda durante a execuo, o testador pode verificar que o resultado esperado do caso de
teste e o resultado obtido so diferentes. Se ele perceber que o software aparenta estar
correto, e achar que o erro est na especificao do caso de teste, ele deve reportar para
o analista de teste avaliar. Se o analista confirmar que o caso de teste est errado, ele o
corrigir. Caso contrrio, o testador dever reportar ao defeito encontrado na ferramenta
de gesto de defeitos.

Testes Orientados a Dados (DDT - Data Driven Test)
O conceito de "Testes Orientados a Dados" (do ingls Data Driven Test - DDT) se refere a
executar (e tambm descrever) o mesmo teste, apenas variando os dados, permitindo
realizar vrios testes sem ter que alterar o cdigo (ou caso de teste). Para atingir esse
resultado, muitas vezes arquivos externos em csv, xml, dentre outros formatos, so
utilizados. Algumas ferramentas j oferecem suporte utilizao do DDT, mas em alguns
casos preciso codificar.
A tabela abaixo demonstra um exemplo que poderia ser utilizado para testar se a
mensagem de boas vindas est sendo exibida corretamente para os usurios
cadastrados, de acordo com seu cargo.

Login Senha Mensagem Esperada
joao joao Usurio no cadastrado
jose jose Bem vindo desenvolvedor Jos
carlos carlos Bem vindo administrador Carlos
... ... ...
... ... ...
... ... ...
marta marta Bem vinda analista Marta
Tabela 3 Exemplo de utilizao de dados para DDT

Dessa forma, a ferramenta utilizaria os dados do login e senha como dados de entrada e
verificaria se a mensagem apresentada corresponde ao que era esperado. Se for preciso
testar para outros usurios, basta adicionar/alterar linhas na tabela e executar o teste
novamente.


58
Automatizao dos Testes
A automatizao dos testes permite execut-los novamente de forma muito mais fcil,
contribuindo para a realizao dos testes de regresso, dando uma confiana muito maior
para a qualidade do software. Sendo assim, a automatizao dos testes parece uma ideia
fantstica, mas ser que sempre a melhor opo? A resposta : No, existem casos
que os testes manuais sero mais adequados. Existem casos tambm, que o prazo
apertado no fornece tempo para automatizar, sendo o teste manual a nica alternativa.
preciso lembrar que os testes automatizados precisam ser programados nas
ferramentas, o que requer tempo e tambm manuteno dos mesmos. Portanto, se a
parte do software que est sendo testada de forma automatizada for mudar muito, em
curto prazo, o custo para reprogramar o teste automatizado pode ser alto. Dessa forma, a
deciso de automatizar ou no a execuo de um teste, deve avaliar alguns fatores, como
por exemplo: Qual o esforo necessrio para automatiz-lo? Existe expectativa de
alterar muito o software testado? O teste dever ser executado muitas vezes? Qual o grau
de risco da parte a ser testada?
Esses quesitos devem ser avaliados, visto que alm do tempo para automatizar o teste
preciso dar manuteno nos scripts. E a manuteno pode ser dificultada por alguns
fatores. A primeira j foi dita: Que mudana no software pode implicar na alterao do
teste automatizado. Outro fator se refere prpria ferramenta de testes, que ao passar
por uma atualizao pode no ser compatvel com o script de teste criado. Nesse caso,
para executar o teste automatizado seria necessrio baixar a verso anterior da
ferramenta, ou ento adaptar o script.
A programao dos scripts de teste passa pelos mesmos desafios do que o
desenvolvimento de um software. As boas prticas de programar, de forma que seja
reutilizvel e de fcil manuteno, se aplicam a programao dos scripts de teste.
possvel perceber que possuir testes automatizados pode ser muito til para garantir a
qualidade do software, mas preciso conhecer os desafios envolvidos para avaliar o
custo x benefcios de cada automatizao.


59
UNIDADE 13
Objetivo: Conhecer as funcionalidades de uma ferramenta para gesto de testes
Gesto de Testes - Ferramenta TestLink
O TestLink (http://www.teamst.org/) uma aplicao web gratuita para realizar a gesto
dos testes de software. Pode ser implantado em qualquer ambiente que oferea suporte a
PHP, MySQL e Apache.
Permite gerenciar todo o ciclo de vida do processo de software. Portanto, possui
funcionalidades para cadastrar os requisitos e os casos de testes; permite associ-los de
forma a manter a rastreabilidade; controla o plano de testes, os papis da equipe
(testador, analista, etc.); possui estatsticas e mtricas para acompanhar o progresso dos
testes; permite a priorizao dos testes; definio de marcos e agrupamento dos testes
para testar determinada verso; dentre outras facilidades.

Figura 9 Principais Funcionalidades do TestLink


60
O TestLink trabalha com quatro principais conceitos: "Projeto de Teste", "Plano de Teste",
"Sute de Teste" e "Casos de Teste". O "Projeto de Teste" o projeto que est sendo
gerenciado. O "Plano de Teste" representa a base para execuo do teste, contendo o
subconjunto de casos de teste selecionado, a prioridade, os resultados, responsveis e
marcos. O "Sute de Teste" representa a organizao dos casos de teste para permitir o
agrupamento em unidades lgicas. como se fosse um "diretrio" que contm casos de
testes para determinada funcionalidade. Por exemplo, possvel criar uma Sute para um
determinado mdulo e associar todos os Casos de Testes desse mdulo. O "Caso de
Teste" o documento estudado anteriormente.
Para entender melhor os conceitos, a figura abaixo apresenta um exemplo fictcio criado
no TestLink para demonstrao. O Projeto a "Loja Magnun". Tem o "Plano de Teste 1"
que possui seis casos de testes atribudos. Os casos de testes esto comeando com a
sigla "LM", uma configurao realizada pelo gerente de teste cadastrado na ferramenta.
Para organizar melhor os casos de testes, tem 3 "Sutes": a sute "Mdulo Frente de
Loja", a sute "Pagamento" e a "Venda".

Figura 10 Exemplo de Projeto de Teste no TestLink

A figura representa uma facilidade do TestLink de visualizao dos testes que passaram
(verde), falharam(vermelho),no foram executados (cinza) e esto bloqueados (roxo/azul).
O TestLink apresenta diferentes relatrios com estatsticas e mtricas para servir como
base de informao para o gerente de teste acompanhar o progresso e avaliar o risco de
liberar o software. O relatrio abaixo exemplifica algumas dessas mtricas, como o


61
resultado do teste por prioridade, indicando, por exemplo, quantos testes de alta
prioridade falharam ou ainda no foram executados.

Figura 11 Mtricas do Plano de Teste

O TestLink permite exportar relatrios e documentos (requisitos, casos de teste, planos de
teste) para HTML, Word e Excel.
Em relao ao Caso de Teste, ele segue o modelo apresentado na Unidade 11, com
exceo dos campos "ps-condies", "dados de entrada" e "dados de sada". Alguns
usurios colocam a informao dos dados de entrada em "aes do passo", e as ps-
condies e dados de sada, em "resultados esperados". Tambm possvel colocar os
dados de entrada e sada em um arquivo e anex-los ao caso de teste, tornando o teste


62
orientado a dados (DDT). Adicionalmente, caso prefira ter esses campos explcitos, o
TestLink permite criar campos personalizados.
A figura a seguir apresenta um exemplo de caso de teste no TestLink.

Figura 12 Exemplo de Caso de Teste no TestLink

Outra facilidade oferecida pelo TestLink atribuio de palavras-chave, facilitando a
categorizao e busca dos casos de teste.


63

possvel acessar um demonstrativo on-line do TestLink em
http://testlink.sourceforge.net/demo/login.php.


64
UNIDADE 14
Objetivo: Apresentar os conceitos e as boas prticas sobre a Gesto e Registro dos
Defeitos
Gesto de Defeitos

Conceito de Erro, Defeito e Falha.
Antes de estudar Gesto de Defeitos, importante analisar os conceitos de erro, defeito e
falha, segundo o ISTQB:
Erro (ou engano): ao humana que produz um resultado incorreto, como por
exemplo, uma ao incorreta realizada por um programador.
Defeito (ou bug): o erro produz um defeito no cdigo, em um software ou em um
documento.
Falha: Se um defeito no cdigo for executado, causar uma falha.
Portanto, de acordo com os conceitos do ISTQB, o defeito o problema, e a falha a
manifestao do problema. A falha tambm pode ser causada por condies externas:
como por exemplo, uma falha na memria RAM (radiao e magnetismo) pode impactar
no funcionamento do software por causa de problemas no hardware.
De acordo com esses conceitos, possvel que um defeito no ocasione uma falha? A
resposta sim. Se a parte do cdigo que contm o defeito nunca for executada, a falha
no ocorrer. O cdigo abaixo exemplifica esse fato.
switch(medida){
case CELSIUS;
return temperatura;
case FAHRENHEIT;
return temperatura * 2; //defeito
}


65
No cdigo acima, o defeito converter Celsius para Fahrenheit multiplicando por 2. Se o
cdigo nunca for executado com medida = FAHRENHEIT, o defeito no ocasionar uma
falha.

Gesto de Defeitos
Os defeitos (por uma questo de Didtica, aqui, ser tratado defeito com o significado
mais amplo, abrangendo tambm o conceito de falha) devem ser registrados no momento
de sua descoberta. Esse registro pode ser manual ou automtico. Os desenvolvedores
tomaro conhecimento sobre a existncia do defeito a partir do canal de comunicao
estabelecido pela equipe. importante que a comunicao seja eficiente para tentar
reduzir o tempo de correo (Rios et al., 2007).
A referncia do CBTS apresenta um conjunto de boas prticas interessantes para relatar
os defeitos:
Resumo: O defeito deve ser relatado de maneira clara e resumido.
Preciso: Antes de reportar o defeito, certificar-se que o que foi identificado
realmente um defeito, e no uma falha no entendimento ou erro do usurio ou
testador.
Neutralidade: Ao reportar o defeito, apresente apenas o problema sem ser
sarcstico ou colocar qualquer tipo de emoo ou humor no relato.
Isolamento: Isolar o defeito, e report-lo.
Generalizao: Avaliar se o problema pode ocorrer em outras situaes, avaliando
o defeito de uma forma genrica.
Reproduo: Antes de relatar um defeito, tentar reproduzir a falha, no mnimo duas
vezes. Caso no seja possvel, por se tratar de uma falha intermitente, tentar
colocar uma prova ou evidncia da ocorrncia, como por exemplo, um printscreen
da tela.
Impacto: Identificar o impacto e grau de severidade do defeito para o cliente e/ou
negcio.


66
As boas prticas apresentadas visam evitar a perda de tempo dos desenvolvedores ao
identificar a origem do defeito, bem como evitar o desgaste entre a equipe de
desenvolvimento e a equipe de teste.
Os defeitos podem ser encontrados e relatados pelos testadores, usurios, clientes, help
desk, equipe de desenvolvimento, dentre outros. Porm, o desenvolvedor responsvel
dever avaliar para ver se legtimo. A demora em reconhecer o defeito pode ser muito
prejudicial.
Aps o desenvolvedor saber da existncia de um possvel defeito, a demora em
reconhec-lo pode ser porque ele no conseguiu reproduzir a falha. Em alguns casos, o
desenvolvedor acaba definindo que o defeito no existe, ou posterga a sua identificao.
Uma das abordagens que pode ser tomada, para tentar acelerar o reconhecimento do
defeito, a gerao de logs pelo cdigo para registrar o ponto em que ocorreu a falha e
se possvel outras condies.
Caso haja discordncia a respeito da existncia do defeito, por parte dos
testadores/usurios e desenvolvedores, preciso definir uma forma para decidir. Se o
sistema apresenta uma falha ntida e reproduzvel, ou ento suas funcionalidades so
diferentes do que foi especificado na documentao, ento o defeito existe.

Resoluo do Defeito
Como podem existir vrios defeitos a serem corrigidos, bem como novos
desenvolvimentos de cdigo a serem realizados, necessrio classificar a prioridade para
definir a ordem de correo. A priorizao est relacionada com o impacto que o defeito
pode causar, avaliando se critico; grave ou menos relevante.
Enquanto o defeito no corrigido, importante avaliar as medidas que podem ser
tomadas para reduzir o risco e minimizar o impacto que a falha pode provocar.
Aps a correo, a parte corrigida deve ser testada novamente pela equipe de testes.
Alm do teste da correo em si, testes de regresso na maioria das vezes so


67
necessrios para garantir que nenhum efeito colateral foi introduzido com a alterao do
cdigo.
importante comunicar s partes interessadas a respeito da resoluo do problema, bem
como sobre os aspectos da liberao do cdigo corrigido.


68
UNIDADE 15
Objetivo: Conhecer uma ferramenta gratuita para Gesto de Defeitos, bem como seus
benefcios.
Gesto de Defeitos - Ferramenta Mantis
Os defeitos quando encontrados precisam ser reportados aos desenvolvedores. Existem
diversas formas de realizar a gesto do defeito, desde processo manual, processadores
de texto, planilhas e at ferramentas especficas para esse fim. A utilizao de uma
ferramenta apresenta benefcios como centralizao dos dados, facilidade de
acompanhamento, atribuio de tarefas, dentre outros.
O Mantis uma ferramenta gratuita para realizar a gesto
dos defeitos, disponvel em http://www.mantisbt.org/. Ela foi
desenvolvida em PHP e roda nos bancos de dados MySql,
MS SQL e PostgreSQL.
O Mantis fcil de instalar e tambm fcil de usar. possvel configur-lo para ser
apresentado em portugus. Alm de permitir fazer a gesto dos "bugs", permite gerenciar
o desenvolvimento de novas funcionalidades tambm, contribuindo para a gesto do que
ser desenvolvido. possvel designar o responsvel pelo desenvolvimento de cada item,
bem como configurar as situaes que devem enviar e-mail. Assim, um e-mail pode ser
enviado aos responsveis quando o defeito for corrigido.
O Mantis gerencia todo o ciclo de vida do defeito, desde a sua criao at sua concluso,
passando por fases como confirmao, correo e reviso. Cada defeito recebe um
identificador numrico sequencial para facilitar o acompanhamento.
Ao logar no Mantis, o desenvolvedor visualiza uma tela com os defeitos atribudos a ele,
os defeitos reportados por ele, bem como os defeitos do projeto, que no possuem
responsveis, os que foram alterados e os concludos recentemente. A figura a seguir
apresenta o painel geral dos defeitos.


69

Figura 13 Viso geral dos Defeitos

Como possvel observar na imagem, ao final da pgina "Minha Viso" existe a legenda
com as respectivas cores dos "status" de cada defeito. Os status indicam:
Novo: um novo defeito ou funcionalidade registrada que ainda no foi confirmado,
admitido, atribudo, etc.
Retorno ("Feedback"): indica que o defeito precisa de alguma informao adicional
ou algum "feedback".
Admitido: geralmente utilizado pela equipe de desenvolvimento para informar que
est ciente e concorda com o defeito relatado, mas ainda no teve tempo ou
condies de reproduzir o defeito.
Confirmado: ao contrrio do defeito "admitido", no confirmado o desenvolvedor
alm de estar ciente e concordar, j conseguiu reproduzir.


70
Atribudo: o defeito j foi designado para um desenvolvedor, que passa a ser
responsvel pela sua correo.
Resolvido: defeito resolvido pelo desenvolvedor. Um defeito passa a ter o status
resolvido quando o responsvel, ao edit-lo, informa que a resoluo foi:
"corrigido", "no o caso (no se aplica)", e "no ser corrigido". Quando ele
corrigido, precisa ser testado novamente.
Fechado: defeito j corrigido e (re)testado, no sendo necessria nenhuma
informao adicional.
As duas figuras seguintes apresentam a tela para registrar um defeito. Devido ao seu
tamanho, ela foi dividida em duas imagens, e ser explicada por partes.

Figura 14 Tela de Registrar Defeito no Mantis - parte 1

A tela de registro de defeito apresenta todas as informaes relevantes, estudadas na
Unidade anterior. O primeiro campo "categoria" indica em qual categoria em relao ao
projeto o defeito se encontra. As opes so cadastradas pelo usurio administrador e
normalmente contemplam os mdulos de um sistema, ou outra categoria que o
administrador julgue relevante.
As opes para "frequncia" da ocorrncia do defeito so: sempre, s vezes, aleatrio,
no se tentou, incapaz de reproduzir.


71
A "gravidade" se refere severidade do defeito encontrado. As opes para esse campo
so: trivial, mnimo, pequeno, grande, travamento ("crash"), obstculo ("block"), recurso
(funcionalidade nova - "feature").
A "prioridade" tem as opes: nenhuma, baixa, normal, alta, urgente e imediato.
possvel informar dados a respeito da "plataforma" e sistema operacional, caso essas
informaes sejam relevantes para o defeito.
A "verso do produto" indica em qual verso o defeito foi encontrado. As possveis
verses so cadastras pelo administrador. "Atribuir a" permite designar para o
desenvolvedor responsvel. J o "previsto para a verso" indica em qual verso o defeito
est previsto de ser corrigido.
A figura a seguir apresenta o restante da tela.

Figura 15 Tela de Registrar Defeito no Mantis - parte 2


72
Os campos "resumo, "descrio", "passos para reproduzir", "informaes adicionais",
"horas estimadas" e horas gastas" so autoexplicativos. O "carregar arquivo" permite que
o responsvel anexe arquivos. Essa funcionalidade til para anexar, dentre outras
coisas, o print da tela de erro. A "visibilidade" indica se o defeito vai ficar visvel para todos
que tm acesso ao projeto ou se vai ser restrito. "Continuar relatando" serve para o
responsvel relatar outro defeito na sequncia.

Acesse o demonstrativo on-line do Mantis, disponvel em
http://www.mantisbt.org/demo/my_view_page.php, para interagir com a ferramenta.


73
UNIDADE 16
Objetivo: Conhecer uma ferramenta gratuita para Gesto de Defeitos, bem como seus
benefcios
Gesto de Defeitos - Ferramenta Mantis (Continuao)

Um recurso importante do Mantis a organizao das informaes, permitindo ter
acesso, de forma facilitada, a resumos e relatrios que auxiliam na gesto e tomada de
deciso.
O Roadmap (na verso em Portugus est traduzido como "planejamento") apresenta os
defeitos por verso do projeto, indicando a porcentagem que j foi resolvida por verso e
o quanto ainda falta.

Figura 16 Roadmap do Mantis


74
J o "Resumo", apresenta estatsticas importantes a respeito dos defeitos, que so
importantes para o gerenciamento do processo de testes. Como apresenta a figura a
seguir, possvel saber a quantidade de defeitos em todos os status (aberto, resolvido,
etc), gravidade, dia, categoria, os mais ativos, os abertos h mais tempo, etc.

Figura 17 Resumo com estatsticas do Mantis

Outras estatsticas apresentadas pelo Mantis so: status x prioridade, status x resoluo,
estatsticas de relatores, eficincia dos relatores (quantos % no foram considerados
"bug"), relator por resoluo e desenvolvedor por resoluo.


75
Vale ressaltar que o Mantis permite gerenciar um nmero ilimitado de projetos, sendo que
o usurio pode escolher se deseja visualizar as informaes de todos os projetos ou de
um projeto especfico.

Figura 18 Seleo do Projeto no Mantis

Outra informao interessante apresentada pelo Mantis o histrico de mudanas por
verso. Dessa forma, se algum cliente entrar em contato relatando um defeito que j foi
corrigido, possvel identificar se a verso que ele est usando j contempla a correo.

Figura 19 Histrico de Mudana no Mantis


76
Essas foram algumas das facilidades oferecidas pela ferramenta de gesto de defeitos
Mantis. Acesse o demonstrativo da ferramenta para conhec-la melhor!

Uma forma facilitada para instalar o Mantis utilizando o Xampp, uma distribuio do
Apache contendo MySQL e PHP: http://www.apachefriends.org/en/xampp.html.

O Xampp tambm permite instalar facilmente o TestLink.


77
UNIDADE 17
Objetivo: Aprender os conceitos de ferramentas para cobertura de cdigo, a partir do
exemplo da ferramenta EclEmma
Cobertura de Cdigo - Ferramenta EclEMMA
A Cobertura de Cdigo se refere a um conceito de teste de caixa-branca para avaliar a
porcentagem de uma classe, mtodo, linha, etc., que foram exercitados ao se executar
um conjunto de testes. Para facilitar essa identificao, existem ferramentas que
automaticamente apontam a porcentagem exercitada por determinado, em todas as
classes do projeto. Essas ferramentas "pintam" as linhas de acordo com cores, que
normalmente so: vermelho para linha que no foi exercitada, amarelo para uma linha
parcialmente exercitada, e verde para linha que foi exercitada por completo ao menos
uma vez. Uma delas a Emma (http://emma.sourceforge.net).
Emma uma ferramenta gratuita para identificar a cobertura de cdigo para Java.
Existem outras ferramentas para outras linguagens de programao, como o NCover para
.Net, por exemplo.
O interessante do Emma que para utiliz-la no vai ser necessrio mudar uma linha
sequer do seu cdigo fonte. O Emma vai obter as estatsticas atravs da Java Virtual
Machine (JVM) adicionando um pequeno overhead de performance (processamento
adicional), agindo de forma silenciosa durante a execuo dos testes. Os resultados
obtidos so imediatamente sumarizados e destacados ("pintados") no editor do cdigo
fonte. O Emma produz os seus relatrios em HTML, XML ou texto e no formato HTML,
possvel relacionar os resultados ao cdigo fonte.
Visando facilitar ainda mais essa atividade, existem adaptaes para as IDEs (Integrated
Development Environment - Ambiente Integrado de Desenvolvimento). O EclEMMA
(http://www.eclemma.org/) integrao do EMMA ao ambiente de desenvolvimento
Eclipse. Portanto, representa a utilizao da filosofia do EMMA no Eclipse, apresentando
os indicadores de forma interativa.


78
Ao instalar o EclEmma, o boto aparecer. Ao executar um teste do JUnit, por
exemplo, com essa opo o cdigo fonte testado ser pintado de acordo com as cores
vermelho, amarelo e verde, conforme apresenta a figura abaixo.

Figura 20 Cdigo fonte "pintado" de acordo com a cobertura do cdigo no Eclipse

Como pode ser observado na figura, a utilizao do EclEMMA torna fcil a identificao
das partes do cdigo que no foram testadas. Essa informao bem til visto que por
mais experiente que o programador seja, ela pode esquecer-se de criar um teste que
execute um comando importante parcialmente ou completamente, diminuindo a
probabilidade de encontrar defeitos.
Para ter uma viso geral do projeto, existe um relatrio que apresenta a porcentagem de
cobertura geral, por projeto, pacotes, classes e mtodos facilitando visualizar em um s
lugar o andamento dos testes nesse aspecto. Esse relatrio apresentado na figura a
seguir. Assim o gerente de projetos pode acompanhar se determinada porcentagem,
definida como mnima, para qualidade foi alcanada. Portanto, o gerente pode determinar


79
como indicador adicional que o software s pode ser liberado se tiver atingido no mnimo
85% de cobertura, por exemplo.

Figura 21 Estatsticas de Cobertura de Pacote, Classes, Mtodos,etc

Segundo as referncias do EMMA, a prtica diz que percentuais abaixo de 60% - 70%
representam software testado de maneira pobre, aumentando muito a probabilidade dos
defeitos serem encontrados pelos usurios. A referncia afirma tambm que atingir 100%
no economicamente vivel. Existem muitos mtodos simples que inclusive so
gerados automaticamente pela IDE (ex: os que apenas retornam o valor de um atributo)
que no justificam escrever testes apenas para exercit-los, se eles no tiverem sido
exercitados em um teste naturalmente. A referncia diz que cobertura entre 80%-90% o
suficiente para a maioria dos casos.
importante observar que mesmo que a classe tenha 100% do cdigo coberto no
significa que ela esteja livre de erros e no d para garantir que o teste foi bem elaborado.
Um software normalmente tem vrias combinaes de caminhos possveis, e apenas
testar todas as linhas de um caminho no garante que os outros caminhos esto corretos.
Portanto, a cobertura de cdigo torna-se uma ferramenta til para indicar facilmente se
partes importantes do cdigo no foram testadas, mas no para garantir por si s a
qualidade dos testes. Como essa ferramenta no requer nenhuma alterao no cdigo
fonte; gratuita e rpida. Ela muito til para o programador verificar a cobertura dos
seus testes desde o incio do desenvolvimento e, frequentemente, a cada execuo dos
mesmos.


80
UNIDADE 18
Objetivo: Visualizar os benefcios proporcionados por ferramentas para testes de unidade,
a partir da explicao do JUnit
Testes de Unidade e Integrao - Ferramenta JUnit

Os desenvolvedores devem testar o seu prprio cdigo na medida em que desenvolvem e
para isso realizam testes unitrios e alguns tipos de testes de integrao. Para facilitar
essa atividade, existem ferramentas disponveis com esse objetivo. O nome genrico para
ferramentas de teste de unidade xUnit.
Nesta Unidade ser apresentada a ferramenta para Java chamada JUnit. Uma grande
quantidade de linguagens de programao possuem ferramentas de teste de unidade,
como o caso do nUnit (.Net), CppUnit (C++), dUnit (Delphi), PHPUnit (PHP), etc.
O JUnit uma ferramenta gratuita. Foi originalmente criada por Kent Beck e Erich
Gamma, dois grandes nomes da cincia da computao. Kent Beck o criador do XP
(Extreme Programming) e Erich Gama ficou famoso com o GoF (Gang of Four - Gangue
dos Quatro) referenciando os quatro autores do livro sobre padres de projeto (Design
Patterns).
O conceito do xUnit foi criado por Kent Beck, um grande entusiasta de testes
automatizados. Para facilitar a organizao e execuo de testes de unidade, Kent Beck
desenvolveu uma ferramenta xUnit para a linguagem de programao Smalltlk. Segundo
Martin Fowler, Kent Beck e Erich Gama comearam o JUnit em um voo entre a Sua e os
Estados Unidos em 1997, aproveitando o tempo no ar para fazer programao em par e
realizando os testes antes de desenvolver (conceitos defendidos por Kent Beck no XP).
Sem a utilizao de uma ferramenta de apoio, a forma padro de testar cdigo unitrio e
alguns casos de integrao era atravs de debbugers ou mandando imprimir na tela o
resultado dos mtodos. Essas formas so dependentes da anlise humana para averiguar


81
se o resultado corresponde ao esperado, impedindo a execuo automtica e
desestimulando a repetio dos testes.
Ferramentas para esse objetivo facilitam essa atividade atravs de uma estrutura pronta.
O JUnit utiliza o conceito de asseres (asserts) para verificar se o resultado do teste
equivale ao que era esperado. Assim, o assertTrue(<condio>) verifica se a condio
verdadeira, o assertFalse(<condio>) verifica se falsa e o
assertEquals(Objeto1,Objeto2) verifica se dois objetos so iguais. Para informar que um
mtodo um teste, basta colocar a anotao @Test (importando o pacote import
org.junit.Test") antes de sua declarao.
Caso seja preciso preparar algumas condies (ex: inicializao de variveis) antes de o
teste ser executado possvel criar um mtodo com a anotao @Before. Essa anotao
til visto que normalmente ser necessrio configurar determinadas caractersticas para
serem utilizado por vrios testes. J anotao @After indica que o mtodo ser chamado
aps a execuo do teste.
Um exemplo simples de funcionamento do JUnit: Supondo-se um mtodo para realizar o
depsito bancrio para valores maiores ou iguais R$ 10,00. Quando o valor menor do
que R$ 10,00 o depsito no deve ser realizado e a respectiva mensagem exibida.
O cdigo fonte, abaixo, exibe as mensagens de retorno e o mtodo de realizar o depsito
em conta.

static String MSG_VALOR_MENOR_10 = "o valor de depsito deve ser
maior do que R$ 9,99";
static String MSG_DEPOSITO_SUCESSO = "Depsito realizado com
sucesso";

public String realizarDepositoEmConta(double
valorDepositado,String numConta){

if(valorDepositado <= 10 ){
return MSG_VALOR_MENOR_10;
}
else{
saldo = saldo + valorDepositado;
return MSG_DEPOSITO_SUCESSO;
}


82
Criando os testes referentes a esse mtodo. Antes de comear os testes, ser criada uma
conta de nmero "12345-0" com saldo inicial = R$ 100,00. O cdigo abaixo apresenta a
declarao da conta e do saldo inicial, bem como o mtodo com a anotao @Before que
cria a conta com o saldo inicial. Esse mtodo ser chamado antes da execuo de cada
teste.

Nessa mesma classe, adicionam-se os mtodos dos testes. importante testar primeiro a
tentativa de depsito com valor menor do que R$ 10,00. Nesse caso, o resultado
esperado a mensagem de aviso que o valor deve ser maior do que R$ 9,99 e o saldo da
conta permanece inalterado.

Portanto o mtodo realizarDepositoContaValorMenor10 foi criado com a anotao @Test
indicando que um teste. Primeiro est sendo verificado se a mensagem correta est
sendo retornada ao chamar o mtodo realizarDepositoEmConta com valor de R$ 9,99.
Utilizou-se o assertEquals para compara dois objetos do tipo "String" (texto). Em seguida,
est sendo verificado se o saldo da conta permanece inalterado, ou seja, igual ao seu
valor inicial. Para esse caso, utilizou-se o assertTrue visto que est sendo verificada uma
condio lgica (verdadeiro ou falso).

@Test
public void realizarDepositoContaValorMenor10(){
assertEquals(conta.realizarDepositoEmConta(9.99, "12345-0")
,ContaBancaria.MSG_VALOR_MENOR_10);
assertTrue(conta.getSaldo()==(saldoInicial));

}
ContaBancaria conta;
double saldoInicial = 100.00;

@Before
public void setUp(){
conta = new ContaBancaria(saldoInicial, "12345-0");
}


83
Ao executar o teste, o resultado apresentado
na imagem ao lado exibido, indicando que
1 teste rodou com sucesso, sendo o seu
resultado a barra verde.
A seguir, necessrio rodar esse mesmo
teste com a execuo do EclEmma, para ver como foi a cobertura de cdigo obtida no
mtodo que est sendo testado. A figura a seguir apresenta o resultado.

Como foi testado somente para valores menores do que R$ 10,00, o EclEmma
apresentou que a parte do else no foi testada.
Agora, um teste para completar a cobertura do cdigo. O teste vai depositar R$ 10.000,00
na conta, e o resultado esperado ser a mensagem de depsito realizado com sucesso e
o saldo da conta ser R$ 10.100,00, ou seja, o saldo inicial + R$ 10.000,00. Apenas para
ver o comportamento do JUnit, propositalmente, declara-se que o saldo da conta deveria
ser igual ao saldo inicial.

@Test
public void realizarDepositoContaValorIgual10_MIL(){
assertEquals(conta.realizarDepositoEmConta(10000.00, "12345-
0")
,ContaBancaria.MSG_DEPOSITO_SUCESSO);
}


84
O cdigo acima apresenta o teste realizarDepositoContaValorIgual10_MIL()
comparando se a mensagem de retorno a de depsito bem sucedido, e verificando se o
saldo da conta igual ao saldo inicial, ou seja, verificando uma condio errada.
Como o teste possui um erro, o JUnit
indica que dois testes foram
executados, e um falhou,
apresentando a barra vermelha. Ele
indica atravs de cones que o teste
que causou o erro foi o
realizarDepositoContaValorIgual10_MIL(),sendo que o primeiro teste foi bem sucedido
realizarDepositoContaValorMenor10().
Para consertar o segundo teste, deve-se substituir a segunda verificao para comparar
se o saldo final igual ao saldo inicial + R$ 10.000,00.

Ao executar esse teste, o JUnit
apresenta o resultado que os dois
testes executados foram bem
sucedidos.
Por sua vez, o EclEMMA apresenta que o mtodo foi completamente coberto pelos testes.

Esse foi apenas um exemplo simples para demonstrar o JUnit e o EclEmma.
@Test
assertEquals(conta.realizarDepositoEmConta(10000.00, "12345-
0"),
ContaBancaria.MSG_DEPOSITO_SUCESSO);
assertTrue(conta.getSaldo()==(saldoInicial + 10000.00));
}


85
As IDEs mais utilizadas no mercado j trazem o JUnit integrado, pronto para uso,
bastando adicionar a biblioteca ao seu projeto.

Localizao das Classes de Teste
uma boa prtica separar o pacote, com os arquivos de testes, do pacote com os
arquivos de desenvolvimento. O isolamento permite que apenas o cdigo da aplicao
seja preparado para ir para produo, desconsiderando os testes.
A figura ao lado exemplifica essa separao, em
que o cdigo fonte est no "src" e o cdigo de
teste no pacote "test".


86
UNIDADE 19
Objetivo: Aprender os conceitos dos objetos Mock (objetos substitutos ou "falsificados"),
visualizando como funciona a ferramenta Mockito
Testes com Objetos Substitutos ou "Falsificados" (Mock Objects) - Ferramenta
Mockito

Metodologias geis e as boas prticas incentivam que os desenvolvedores testem a todo
o momento o seu cdigo. Na Unidade anterior foi visto como ferramentas no padro xUnit
ajudam a atingir esse objetivo.
Para isolar os mtodos ou classes durante os testes possvel utilizar os objetos "mocks",
ou seja, objetos "falsificados" ou substitutos. Os objetos mocks simulam ou imitam o
comportamento de outro objeto, permitindo definir o que o mtodo substituto vai retornar,
de acordo com os parmetros de entrada.
Os mocks oferecem diversos benefcios aos testes. Primeiramente, permitem isolar a
classe que est sendo testada. Tambm permite simular estados dos objetos que podem
ser difceis de reproduzir, realizando os testes em um ambiente controlado. Permitem
substituir inclusive objetos que no foram implementados. Outro benefcio substituir
objetos que podem demorar mais a serem executados, como aqueles que precisam
acessar banco de dados, agilizando assim a execuo dos testes.
Para entender o seu funcionamento, segue um exemplo.
Antes que um depsito possa ser realizado, preciso verificar se a conta bancria est
ativa. Assim, o mtodo realizarDepositoEmConta chama o mtodo
verificarSeContaAtiva(numConta)da classe ContaDAO (padro DAO de Data
Acess Object, ou Objeto de Acesso a Dados) que realiza uma consulta ao banco de
dados para verificar se a conta est ativa. Utilizando o mock possvel isolar o mtodo


87
realizarDepositoEmConta , fazendo com que no seja preciso realizar a consulta ao
banco. Ou seja, determinar durante o teste com o mock:
Quando verificarSeContaAtiva for chamado para a conta de nmero
"12345", para retornar que est ativa.
Quando verificarSeContaAtiva for chamado para a conta de nmero
"67891", retornando que est inativa
Dessa forma quando realizarDepositoEmConta chamar o mtodo
verificarSeContaAtiva o objeto "falsificado" entrar em ao e retornar a resposta
determinada, sem executar de fato esse ltimo mtodo e, consequentemente, sem
realizar a consulta ao banco de dados.

Figura 22 Utilizao de Objeto Mock

Ferramenta Mockito
Conhecido o conceito de objetos mock, a seguir uma ferramenta que facilita a sua
criao. Sem a utilizao de uma ferramenta, seria preciso alterar (ou at mesmo criar) o
cdigo da classe original a ser substituda para verificar o parmetro de entrada e retornar


88
um resultado esperado, poluindo o cdigo original e adicionando trabalho extra para
depois voltar o cdigo ao normal.
A vantagem da ferramenta justamente essa, ela permite criar o comportamento
desejado sem ter que alterar uma linha sequer do cdigo original.
A ferramenta apresentada tambm gratuita para JAVA, chamada Mockito. O conceito se
repete para outras linguagens orientadas a objeto, que tambm possuem ferramentas
para esse objetivo.

O Mockito est disponvel em http://mockito.org/. Para
utiliz-lo, basta realizar o download e colocar o jar no
classpath do projeto.
O Mockito muito simples de usar. Primeiro, criea-se o objeto mockado:

Depois, determina-se que o mtodo deve retornar quando for chamado. Exemplos:

when(mockDao.verificarSeContaAtiva("12345")).thenRetur
n(true);
when(mockDao.verificarSeContaAtiva("67891")).thenRetur
n(false);
ContaDao mockDao = mock(ContaDao.class);


89
Para ver na prtica, repetiu-se o exemplo da unidade anterior adicionando a verificao se
a conta est ativa antes de realizar o depsito.

A seguir, a classe de testes. Percebe-se, no cdigo abaixo, que poucas modificaes
foram feitas para a utilizao do Mockito. As alteraes esto sublinhadas.

static String MSG_VALOR_MENOR_10 = "o valor de depsito deve
ser maior do que R$
9,99";
static String MSG_DEPOSITO_SUCESSO = "Depsito realizado com
sucesso";
static String MSG_CONTA_INATIVA = "Conta Inativa ";

public String realizarDepositoEmConta(double
valorDepositado,String
numConta){

if(valorDepositado <= 10 ){
return MSG_VALOR_MENOR_10;
}
else{

if(contaDao.verificarSeContaAtiva(numConta)){

saldo = saldo + valorDepositado;
return MSG_DEPOSITO_SUCESSO;
}
else{
return MSG_CONTA_INATIVA;
}
}
}


90
O mtodo realizarDepositoContaValorMenor10()no foi alterado porque quando o valor
menor do que R$ 10,00 o cdigo no chega a verificar se a conta est ativa.

J no mtodo realizarDepositoContaValorIgual10_MIL foi adicionada a linha
when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true); indicando que
quando o mtodo verificarSeContaAtiva for chamado para a conta de nmero "12345",
a resposta deve ser que a conta est ativa e o mtodo original no ser executado.
Assim, na linha imediatamente abaixo, ao chamar
conta.realizarDepositoEmConta(10000.00, "12345") o realizarDepositoEmConta
utilizar o objeto "falsificado" na hora de verificar se a conta est ativa.
Executando os testes obtm-se a barra verde
indicando que os dois testes foram realizados com
sucesso.

Conta conta;
double saldoInicial = 100.00;
ContaDao mockDao;

@Before
public void setUp(){
mockDao = mock(ContaDao.class);
conta = new Conta(saldoInicial, "12345", mockDao);
}

@Test
public void realizarDepositoContaValorMenor10(){
assertEquals(conta.realizarDepositoEmConta(9.99, "12345")
,Conta.MSG_VALOR_MENOR_10);
}

@Test
when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true
);
assertEquals(conta.realizarDepositoEmConta(10000.00,
"12345")
,Conta.MSG_DEPOSITO_SUCESSO);
assertTrue(conta.getSaldo()==(saldoInicial + 10000.00));
}


91
Visualizando a cobertura do cdigo, verifica-se que no foi criado um teste que passe pela
situao de uma conta inativa, conforme apresenta a figura a seguir.

Criando um teste para resolver essa situao.

O cdigo acima apresenta o teste de uma conta inativa realizarDepositoContaInativa().
Primeiro foi indicado que ao verificar se a conta "67891" est ativa, deve ser retornado
"falso". Em seguida, verificado se ao chamar realizarDepositoEmConta para uma conta
inativa, a mensagem correta retornada.
Executando o teste, a barra verde do JUnit
indica que os trs testes foram realizados
com sucesso. No ser exibido aqui, mas o
EclEMMA indica que a cobertura para esse mtodo foi 100%. Pronto!
O Mockito oferece ainda outros mtodos para verificar, a quantidade de vezes que o
mtodo foi chamado, se os mtodos foram chamados em uma determinada ordem, dentre
outras facilidades.
@Test
public void realizarDepositoContaInativa(){
when(mockDao.verificarSeContaAtiva("67891")).thenReturn(fals
e);
assertEquals(conta.realizarDepositoEmConta(50.00, "67891")
,Conta.MSG_CONTA_INATIVA);
}


92
UNIDADE 20
Objetivo: Conhecer os conceitos do Desenvolvimento Orientado a Testes (TDD)
Desenvolvimento Orientado a Testes (TDD - Test Driven Devlopment)

O Desenvolvimento Orientado a Testes mundialmente conhecido como TDD (Test Driven
Devlopment) consiste em um paradigma para criar o teste antes de implementar o cdigo
do programa. O TDD foi popularizado por Kent Beck (o mesmo Kent Beck que criou o
JUnit) na metodologia gil XP (eXtreme Programming) em 1999. Mesmo tendo sido
difundido junto com o XP, o TDD pode ser aplicado em qualquer metodologia de
desenvolvimento.
Segundo o prprio Kent Beck: uma forma previsvel de desenvolvimento. O usurio
saber quando terminou, sem ter que se preocupar com um longo rastro de bugs.
O TDD prega que cdigo novo s escrito quando um teste automatizado falhar. E, na
medida em que o cdigo vai evoluindo, as duplicaes so eliminadas. Adiante, um
exemplo prtico.
Em seu livro "Test Driven Devlopment by Example" (no Brasil o ttulo foi: TDD -
Desenvolvimento Guiado por Testes) Kent Beck afirma que o TDD no uma ideia nova
(esta Unidade foi baseada nesse livro). Segundo ele: "Desde os primrdios da
computao programadores especificam os inputs e outputs antes de precisamente
programar. TDD, pega essa ideia antiga e mistura com linguagens e ambientes de
programao modernos, e cozinha um ensopado saboroso garantido para satisfazer seu
apetite para cdigo limpo que funcione agora. No livro, ele agradece ao autor do livro que
leu aos 12 anos, que sugeria que se escrevesse o output esperado a partir de um input
real, e ento codificasse at que os resultados atuais batessem com o resultado
esperado.


93
O mantra do TDD "Vermelho -> Verde -> Refatorao".
1. Vermelho: Escreva um teste que falhe, e que talvez nem compile na primeira vez.
2. Verde: Faa o teste funcionar rapidamente, fazendo o que for necessrio para
atingir esse objetivo.
3. Refatorar Elimine todas as duplicaes criadas e que foram inseridas ao fazer o
teste funcionar.

Os passos recomendados por Kent Beck para o TDD so:
Rapidamente, adicione um teste;
Rode todos os testes e veja o novo teste falhar;
Realize uma pequena mudana;
Rode todos os testes e veja todos eles serem bem sucedidos;
Refatore para remover duplicidades;
Boas prticas no tempo certo. Primeiro faa rodar, posteriormente faa certo.

Assim, a ideia que primeiro escreva o teste. Em seguida, faa o teste ser bem sucedido.
No conceito TDD, fazer com que a barra (estilo JUnit) fique verde, prevalece sobre
qualquer outro ponto. Segundo Kent Beck, essa mudana "esttica" difcil para
desenvolvedores e engenheiros de software experientes, que s conseguem escrever o
cdigo correto para passar em um teste. Ainda de acordo com ele, tornar verde rpido
perdoa todos os pecados, mas apenas por um momento. Aps fazer o teste "passar", faa
corretamente. Em relao ao "faa corretamente" Kent afirma que no momento em que o
cdigo est se comportando corretamente, elimine os "pecados" do passado recente,
voltando ao caminho estreito e reto da integridade do software. Nesse momento, remova
a duplicao que introduziu e faa a barra ficar verde rapidamente. Esse conceito prega
que primeiro seja resolvido parte do problema que funcione. Ento, resolva a parte
cdigo limpo.


94
Seguindo esses passos, normalmente ser percebido:
Como cada teste pode cobrir um pequeno incremento da funcionalidade
Quo pequena e "feia" a mudana pode ser para fazer o novo teste rodar
A frequncia com que os testes so executados
Quantos passos pequenos compem uma refatorao

Ao realizar TDD, recomenda-se que se tenha uma lista de tarefas para lembrar o que
deve ser feito e, ao mesmo tempo, manter o foco. Um item finalizado deve ser riscado da
lista. Ao pensar em um novo teste para escrever, adicione lista.
Segundo o livro do Kent Beck, se uma soluo simples e limpa for bvia, ento a escreva.
Se a soluo for simples e limpa, mas for tomar mais do que um minuto para ser
executada, deve-se escrever na lista e voltar para o problema principal, que fazer a
barra ficar verde em segundos.
Para atingir rapidamente o "verde", duas estratgias so utilizadas.
1. "Fingir/Falsificar": consiste em forar o resultado, como por exemplo, retornar uma
constante e gradualmente substituindo por variveis at chegar ao cdigo real
(Ser mais exemplificado da prxima Unidade)
2. Utilizar a implementao bvia, j digitando a soluo real.

Kent Beck varia entre as duas estratgias quando est utilizando o TDD na prtica.
Quando tudo est fluindo tranquilamente e ele sabe o que digitar, ele vai pela
implementao bvia, sempre rodando os testes. Assim que ele obtm um vermelho
inesperado, ele recua, volta para a implementao falsa, e refatora o cdigo correto.
Segundo Erich Gamma, a maioria das pessoas que aprende TDD identifica que suas
prticas de programao mudaram para melhor. Ele cunhou o termo Test Infected
(Contagiado pelos Testes) para esse tipo de situao. Por outro lado, alguns engenheiros


95
de software aprendem TDD e continuam com sua forma padro de desenvolvimento,
deixando o TDD para ocasies especiais em que no sente que est tendo progresso.
"Voc pode se encontrar escrevendo mais testes antecipadamente e trabalhando em
passos menores do que voc poderia imaginar que seria possvel" - Kent Beck.


96
UNIDADE 21
Objetivo: Ver aplicao dos conceitos do TDD, com um exemplo na prtica
Exemplo de TDD na Prtica

Aps ter estudado os principais conceitos do TDD, ser apresentado um exemplo prtico
do TDD, baseado no livro "Test Driven Devlopment by Example" do Kent Beck.
O exemplo apresentado refere-se sequncia de Fibonacci. A srie de Fibonacci
(representado abaixo por F()=) tem a seguinte formao:
F(0) = 0
F(1) = 1
F(2) = 1
F(n-1) + F(n-2), para qualquer outro nmero maior do que 2
Assim, tendo n = 3, F(3) = F (3 - 1) + F (3 - 2) = F (2) + (1) = 1 + 1 = 2. J para n=4, F(4) =
F(3) + F(2) = 2 + 1 = 3. Portanto a sequncia : 0,1,1,2,3,5,8,13, ... .
Agora que a srie de Fibonacci foi apresentada, segue resoluo com o TDD.
O primeiro teste apresenta que Fib(0) = 0. Seguindo os conceitos do TDD, antes de
desenvolver o cdigo, importante desenvolver o teste para ele.

@Test
public void testFibonacci() {
assertEquals(0, fibonacci.fib(0));
}


97
O cdigo acima representa esse teste escrito com o JUnit, que j foi estudado neste
Mdulo. Portanto, verifica (assertEquals) se o resultado de fibonacci.fib(0) 0. Esse
teste no vai nem compilar, viso que a classe Fibonacci ainda nem foi criada. O objetivo
esse mesmo, lembrando o mantra TDD: Passo 1: "Vermelho deve-se fazer um teste que
falhe, e que talvez nem compile na primeira vez".
Passo 2: "Verde - Fazer o teste funcionar rapidamente, fazendo o que for necessrio para
atingir esse objetivo". Portanto, deve-se criar a implementao de Fibonacci mais simples
possvel para passar no teste criado.

Executando o teste, atinge-se o objetivo de
conseguir a barra verde o mais rpido
possvel. Para isso, cria-se um cdigo que
independente do nmero de entrada, sempre
retornar o nmero zero.
Escrevendo o segundo teste, para Fib(1)= 1.

O teste vai falhar, visto que de acordo
com o cdigo implementado Fib(1) =0
ao invs de 1. Esse comportamento
@Test
}

public int fib(int n) {
return 0;
}


98
est de acordo com o que prega o TDD. Agora, acerta-se o cdigo, desenvolvendo uma
implementao mais simples para obter a barra verde.

O cdigo bem simples, que retorna 0 quando n = 0, e 1 para todos os demais nmeros de
entrada foi criado, e o teste passou.
O prximo teste Fib (2) =1.

Esse teste vai passar, visto que o cdigo est sempre retornando 1, para nmeros
diferentes de 0. Se reparar, o teste, cada linha cpia da linha anterior alterando apenas
dois nmeros. Seguindo a recomendao do TDD, refatore para eliminar a duplicidade (se
aplica ao teste tambm).

@Test
int casos[][]= {{0,0},{1,1},{2,1}};

for (int i= 0; i < casos.length; i++){
assertEquals(casos[i][1], fibonacci.fib(casos[i][0]));
}
}

@Test
}

if(n==0)return 0;

return 1;
}


99
Portanto, o teste foi refatorado de forma que para inserir novos testes, basta colocar na
matriz "casos" o par "{n, resultado esperado}".
O prximo teste Fib (3) = 2. Adicionando no teste {3,2} e rodando, obtm-se o seguinte
resultado:
A barra vermelha apresentada com
a mensagem de erro do JUnit: era
esperado o resultado 2 mas foi
obtido 1. A mensagem de erro do
JUnit acompanha todos os testes
vermelhos, ela foi omitida nos outros
exemplos, mas foi inserida aqui para conhecimento de mais esse recurso.
Alterando o cdigo para o teste passar:

Para fazer o teste Fib(3) passar o nmero 2 est sendo retornado para nmeros de
entrada > 2. Mas utilizando o conhecimento sobre Fibonacci, sabe-se que F(3) = 2 porque
F(3) = F(3 -1) + F(3-2) = 1 + 1 = 2. Portanto, vamos aplicar essas substituies passo a
passo no cdigo, antes de ir para o prximo teste. Cada alterao no cdigo, o JUnit deve
ser rodado novamente para ver se os testes anteriores continuam funcionando. A primeira
mudana substituir o 2 por 1 + 1.


if(n==0)return 0;

if(n<=2)return 1;

return 1 + 1;
}

if(n==0)return 0;

if(n<=2)return 1;

return 2;
}


100
Como se sabe que o primeiro 1 = F(n-1), se faz essa alterao.

A seguir, substituir o segundo 1 = F(n -2).

Pronto, agora todos os demais testes vo passar. Rodando cada um deles por vez: Fib(4)
= 3, Fib(5)=5, Fib(6)=8, etc., obtm-se a barra verde em todos.
Chega-se ento resoluo do problema, utilizando-se os conceitos do TDD:
1. Vermelho: Escreva um teste que falhe, e que talvez nem compile na primeira vez
2. Verde: Faa o teste funcionar rapidamente, fazendo o que for necessrio para
atingir esse objetivo.
3. Refatorar Elimine todas as duplicaes criadas, que foram inseridas ao fazer o
teste funcionar.
O prximo passo realizar o teste para valores ilegais, adicionando a proteo ao cdigo
para tratar os nmeros negativos.


if(n==0)return 0;

if(n<=2)return 1;

return fib(n-1) + fib(n-2);
}

if(n==0)return 0;

if(n<=2)return 1;

return fib(n-1) + 1;
}


101
Tamanho dos passos
Algumas pessoas podem ter achado os 3 ltimos passos muito pequenos: substituir 2 por
1 + 1; substituir 1 + 1 por fib(n -1) + 1; e por fim substituir fib(n-1) +1 por fib(n-1) + fib(n-2).
Se os passos parecerem muito pequenos, lembre-se que TDD no prega que se realizem
passos pequenos, mas que se tenha a habilidade de realizar os passos pequenos.
Segundo Kent Beck, ele no codifica no dia a dia com passos to pequenos. Mas quando
as coisas comeam a complicar o mnimo possvel, ele se diz contente por poder realizar
os passos pequenos. Ele recomenda que se tentem passos pequenos com um exemplo.
Se conseguir fazer os passos muito pequenos, certamente conseguir faz-los do
tamanho correto. Se apenas fizer passos grandes, nunca saber quando passos menores
so apropriados.
Aps ter visto o exemplo prtico, pode ser uma boa pedida estudar novamente a Unidade
anterior, visto que os conceitos esto mais claros e o aprendizado de um paradigma novo
ser reforado.


102
UNIDADE 22
Objetivo: Conhecer a ferramenta Selenium para automatizar testes de aplicaes Web
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers. I

O Selenium uma ferramenta gratuita muito boa para automatizar
os testes de aplicaes WEB. Com o Selenium possvel gravar
todos os passos (cliques, insero de dados, etc.) realizados pelo
usurio em um site, para depois reproduzir os mesmos.
Ela suporta diferentes linguagens de programao como Java,
Javascript, Ruby, PHP, Python, Perl e C#, e a quase todos os browsers como Firefox,
Google Chrome, Internet Explorer, etc.
O Selenium foi criado em 2004 por Jason Huggins da ThoughtWorks, quando ele estava
realizando testes de uma aplicao web. Ao perceber que existia uma forma melhor de
executar os testes, sem ter que execut-los manualmente a cada mudana, ele
desenvolveu uma biblioteca Javascript para realizar interaes com a pgina, sendo que
era possvel rodar os testes em diferentes browsers. Essa biblioteca se tornou o ncleo do
Selenium, uma ferramenta inovadora visto que na poca no existia nenhum outro
produto que permitia controlar o browser de uma linguagem de programao escolhida
pelo programador (Hunt et al., 2011).
Em 2006, Simon Stewart engenheiro do Google iniciou um projeto chamado de WebDriver
para contornar algumas limitaes do Selenium, j que o Google era um usurio assduo
dessa ferramenta. Em 2008 o WebDriver e Selenium foram unificados. Assim surgiu o
Selenium 2 (Selenium WebDriver), enquanto o anterior era o Selenium 1 (Selenium
Remote Control - RC). O mais atual possui uma API mais coesa e orientada para objetos
com funcionalidades que derrubam algumas limitaes da implementao antiga. O
Selenium 2 tambm roda a interface do primeiro Selenium, para prover compatibilidade.


103
Mesmo com a existncia da verso 2, o Selenium 1 ainda recebe suporte porque,
segundo o prprio manual, existem funcionalidades que podem no ser inseridas no
Selenium 2 por um bom tempo (Hunt et al., 2011).
O Selenium IDE (Integrated Development Environment - Ambiente Integrado de
Desenvolvimento) um plugin para Firefox para facilitar a criao dos scripts de teste,
pois grava todas as aes dos usurios, na medida em que ele "navega" pelo site ou
aplicao web. Aps salvar, possvel exportar o cdigo para as vrias linguagens de
programao que so suportadas pelo Selenium, de forma a permitir a execuo futura.
Mesmo o IDE sendo somente para Firefox, os testes criados podem ser executados em
qualquer browser compatvel atravs da linha de comando do Selenium RC. Ou seja, para
gravar os passos de forma facilitada vai ser necessrio utilizar o Firefox, mas para
execut-los possvel utilizar qualquer browser.
O Selenium IDE no fornece iteraes (while, for, etc), nem condicionais (if, else,etc) para
os scripts, e no existe planejamento at o momento para adicionar essas
funcionalidades. Isso porque o IDE tem o objetivo de ser uma ferramenta para prototipar
os testes rapidamente e mesmo sem essas funcionalidades, uma das formas mais
eficientes de se desenvolver os scripts de teste para aplicaes web. Caso deseje utilizar
as iteraes e condicionais para realizar testes mais complexos, possvel exportar o
script criado no IDE para uma das linguagens de programao e em seguida alterar o
cdigo, funcionando tanto para o Selenium 1 e 2.
Outra alternativa para utilizar iteraes e condicionais, mas do prprio browser, atravs
da instalao de uma extenso, chamada "goto_sel_ide.js" (disponvel em:
https://addons.mozilla.org/pt-BR/firefox/addon/flow-control/).
Para instalar o Selenium, v at a pgina http://seleniumhq.org/download/. Para instalar o
Selenium IDE, utilize o FireFox, clique no link e confirme - assim os dois j so integrados.
Realize tambm o download do Selenium RC. Para rodar o Selenium IDE, utilize uma das
duas formas apresentadas na imagem abaixo.


104

Figura 23 Formas de rodar o Selenium IDE

Ao executar, a tela do Selenium ser exibida. Por padro o boto vermelho j vem
marcado, indicando que o modo de gravao est ativado.

Figura 24 Selenium IDE

Com o boto de gravao ativado, tudo que o usurio fizer na pgina ser gravado.


105
UNIDADE 23
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers II.

Repare na prxima figura que o Selenium IDE gravou a navegao do usurio, que
consistiu em abrir a pgina do Mantis e em seguida digitar o nome "pedro" no campo
"username". A figura destaca em vermelho o comando gerado pelo Selenium ao digitar o
username.

Figura 25 Gravao dos passos do usurio com o Selenium IDE


106
A figura mostra apenas at o momento que foi digitado o username, mas continuando o
processo para fazer o login, ao informar a senha e clicar no boto "Login" o Selenium
salvar todos esses passos. Interrompendo a gravao e clicando no boto do Selenium
"play", todos os passos gravados sero executados, fazendo o login automaticamente no
exemplo, casos os dados informados sejam vlidos. Simples e genial!
Portanto, durante a gravao o Selenium IDE automaticamente adicionar os comandos
no script de acordo com as aes do usurio, como por exemplo: clicar em um boto, em
um link, checkbox, etc; preencher campos da pgina (ex: login, senha, nome, idade, etc);
e selecionar uma opo de uma caixa de seleo ("drop down").
importante perceber que normalmente ao preencher os campos da pgina, preciso
sair do campo para que o comando "type" seja gravado, ou seja, na figura anterior, aps
informar o "username", foi preciso ir para o prximo campo (ou clicar em outro ponto da
pgina) para o comando ser gravado.
Ao clicar em um boto, link, etc., o comando "click" ou "clickAndWait" ser gravado. O
"clickAndWait" deve ser utilizado quando for preciso aguardar alguma situao, como por
exemplo, a prxima pgina ser carregada. Caso contrrio, o teste vai continuar
executando, antes da pgina ter carregado todos os elementos, o que pode provocar
falhas no teste. Isso acontece porque a velocidade de execuo do Selenium (rodando na
mquina local) mais rpida do que o tempo de resposta do servidor.
A IDE oferece algumas opes para executar os casos de
teste. possvel rodar o script gerado por completo,
interromper e continuar, alterar a velocidade da execuo, executar uma linha por vez e
rodar todos os scripts do "Test Suite". possvel executar tambm um nico comando,
sendo essa funcionalidade til para verificar se o comando que se est desenvolvendo
est correto, sem ter que executar o teste inteiro novamente. Ao clicar com o boto direito
nos comandos possvel incluir opes que permitem "debugar" o script, como inserir um
"breakpoint" para forar uma interrupo em um comando particular, e definir um ponto de
incio no meio do teste.
Os comandos do Selenium, frequentemente, so chamados de "Selenese" e, ao serem
colocados em sequncia, formam o script de teste. O Selenium oferece uma boa


107
quantidade de comandos que permitem verificar: se determinado texto est presente na
pgina, o tamanho da janela, mensagens, a existncia de um elemento na pgina, dentre
inmeras outras funes. Ao clicar em um elemento da pgina com o boto direito do
mouse, a lista de comandos e parmetros do Selenium referentes ao mesmo so
exibidos, conforme apresenta a figura a seguir. Essa facilidade economiza tempo e uma
excelente forma de aprender a sintaxe do Selenium.

Figura 26 Exibio dos comandos disponveis para determinado elemento

A sintaxe dos comandos simples, consistindo de 3 parmetros: o comando em si, o alvo
da ao e o valor. Os parmetros no so sempre obrigatrios, variam de acordo com o
comando selecionado. O comando abaixo, extrado da Figura 25 informa que ser
digitado (type) o valor "pedro" no campo "username".
Comando Alvo Valor
type Name=username pedro
Figura 27 Estrutura de um comando "Selenese"


108
Existem trs tipos de comandos: as aes - como digitar (type), clicar (click), etc.; os
acessors que salvam valores em variveis, como o comando "store"; e os assertions
(verificadores) que verifica se algo est conforme o esperado, como por exemplo,
"garanta que a palavra 'Administrador' est presente na pgina aps o login".
Os assertions, por sua vez podem ser de trs formas: comando "assert", que aborta o
teste em caso de alguma falha; comando "verify" que registra a falha no log, mas
prossegue com o teste; e o "waitFor" que espera at a condio ser verdadeira (espera
durante um timeout configurado). O "waitFor" importante para testar aplicaes Ajax.
Quanto diferena do "assert" e "verify", cada um tem sua utilidade. Por exemplo, se o
teste verificar que foi direcionado para uma pgina diferente da esperada, geralmente no
vai fazer muito sentido continuar com o teste, e nesse caso usaria o "assert" para abortar
em caso de falha. Por outro lado, pode ser desejado testar vrios elementos de uma
mesma pgina de uma vez, mesmo que um deles apresente erro, utilizando assim o
"verify".
Segue abaixo alguns dos comandos mais utilizados para testar as pginas com o
Selenium:
open: utiliza a URL para abrir a pgina
click/clickAndWait: clica no elemento especificado no parmetro "alvo"
verifyTitle/assertTitle: verifica se o ttulo da pgina contm determinado texto
verifyTextPresent: verifica se o texto especificado est em algum lugar na pgina
verifyText: verifica se o texto especificado est em um determinado elemento
HTML
verifyElementPresent: verifica se um elemento como link, pargrafo, etc., est
presente na pgina
waitForElementPresent: aguarda at o elemento HTML estar presente na pgina


109
UNIDADE 24
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers III

Conforme foi possvel observar, muitos comandos precisam identificar um elemento
HTML (alvo) para realizar determinada ao. Mas como fazer essa identificao? A
seguir, algumas formas, tomando como exemplo a figura abaixo.

Figura 28 Exemplo de uma pgina HTML simples para Login (Hunt et al., 2011)

Localizar por identificador: localizar o primeiro elemento HTML correspondente ao "id". Se
o "id" no estiver presente, retornar o primeiro elemento correspondente ao "name".
Portanto se no "alvo" estivesse identifier=loginForm, o comando seria realizado sobre o
elemento da linha 3. Se estivesse identifier=username, o comando seria realizado sobre o
elemento da linha 4.
Localizar por id: localizar o primeiro elemento correspondente ao "id", sendo que no se
verifica no "name". Portanto, se no "alvo" estiver id=loginForm, o comando ser realizado
sobre o elemento da linha 3.


110
Localizar por nome: localizar o primeiro elemento correspondente ao "name". Voltando ao
exemplo da Figura 25, percebe-se que essa estratgia foi utilizada visto que o "alvo" est
name=username. Portanto, o comando especifica para digitar (type) o valor "pedro" no
alvo que name=username. Se dois elementos tiverem o mesmo nome, possvel utilizar
outro atributo, em conjunto, para identificao. Assim, um alvo que especifique
"name=continue value=Clear" indica para o comando ser realizado no elemento da linha
7.
Localizar por Xpath: uma maneira verstil de localizar um elemento, facilitando
identificaes do tipo: "localizar a quinta linha de uma tabela". possvel localizar atravs
do caminho absoluto (que no recomendado visto que o teste fica propenso a falhar
com uma mudana pequena da aplicao) ou caminho relativo. Portanto, nesse exemplo,
se o "alvo" for xpath=/html/body/form[1], o comando ser aplicado ao elemento da linha 3,
visto que o primeiro "form". Esse um exemplo de caminho absoluto. Se no "alvo"
estiver //form[@id=loginForm]/input[4], o comando ser realizado sobre o elemento da
linha 7, visto que esse caminho relativo primeiro identificou o "form de id=loginForm", para
depois localizar o quarto input desse form. Vale observar que comear com "xpath" ou "//"
produz o mesmo resultado.
Para saber mais sobre Xpath, acesse o tutorial disponvel em:
http://www.w3schools.com/Xpath/.
Existem formas de localizar os elementos HTML tambm pelo texto do link, por DOM
(Document Object Model), utilizando Javascript ou por CSS (Cascading Style Sheets).
Em relao comparao de determinado texto da pgina, o Selenium oferece a
possibilidade de verificar por padro de texto, sendo essa uma forma flexvel j que no
vai ser necessrio utilizar o texto exato. Uma das formas de padro de texto atravs da
expresso regular. Assim, "verifyTextPresent regexp:.*Administrador.*Bem.*Vindo",
verifica se existe texto contendo as palavras "Administrador", "Bem" e "Vindo", mesmo se
estiver com outras palavras ou caracteres entre elas.
Agora, que j se conhece um pouco mais sobre os comandos do Selenium, o prximo
passo gravar um teste para depois execut-lo automaticamente. O teste gravado ser: ir


111
pgina de demonstrao do Mantis para ver se o texto de erro aparece na pgina ao
tentarmos efetuar login com usurio e senha invlidos.
O teste consiste em abrir a pgina de demonstrao do Mantis, digitar o nome "pedro" no
campo "username", digitar "pedro" no campo "password", clicar no boto, e verificar se
aparece alguma mensagem contendo as palavras "disabled","blocked"ou"incorrect",
indicando usurio e senha invlidos. A tabela abaixo apresenta os comandos gerados ao
gravar o teste com o Selenium.

Comando Alvo Valor
open /demo/login_page.php?return=%2Fdemo%2Fmy_view_page.php%3F
type name=username pedro
type name=password pedro
clickAndWait css=input.button
verifyText css=font *disabled*blocked*incorrect*

Figura 29 Teste de Login errado com Selenium

A figura a seguir apresenta a execuo automtica de todos os passos gravados (figura
anterior), com destaque para indicao da execuo com sucesso do teste no Selenium e
a mensagem informando do login sem sucesso. Portanto, automaticamente o Selenium
informou o usurio "pedro", senha "pedro", clicou no boto para login e verificou se a
mensagem de erro foi apresentada.


112

Figura 30 Resultado da execuo do Selenium

possvel salvar o teste e execut-lo posteriormente. A ferramenta permite carregar
vrios testes salvos, e executar todos. O conjunto de testes chamado de "Test Suite". O
painel em destaque, na figura anterior, mostrar quantos dos testes executados falharam.
Aps criar o teste, possvel export-lo para uma das linguagens de programao
suportadas, conforme mostra a figura a seguir. No exemplo, o arquivo est sendo
exportado para a linguagem de programao Java (opo JUnit).


113

Figura 31 Exportando os comandos gravados para uma linguagem de programao

Uma vez exportado para linguagem de programao desejada, possvel continuar
programando normalmente.
Para executar o teste a partir do Java, basta colocar o "jar" (ex: selenium-java-2.0b2.jar)
do Selenium no classpath do projeto (para demais linguagens, consulte o manual de
referncia). O servidor (Selenium 1 ou 2) deve estar rodando quando for executar o
arquivo ".java" que foi salvo, bastando para isso digitar na linha de comando "java jar
selenium-server-standalone-2.0b2.jar". Ou ento colocar como atividade.


114
UNIDADE 25
Objetivo: Visualizar o funcionamento de uma ferramenta para realizao de testes de
performance e estresse, atravs da demonstrao do JMeter
Teste de Performance e Estresse - Ferramenta JMeter

Para saber como o sistema se comporta com utilizao dos recursos padro, no limite, e
acima do limite importante realizar os testes de performance e os de estresse.
Antes de iniciar os testes de performance e estresse, importante responder algumas
perguntas: Qual o nmero mdio (conhecido ou esperado) de usurios em uma carga
normal? Qual o pico de usurios esperado? O servidor em que os testes sero
realizados pode ser interrompido? Qual momento adequado (ex: madrugada, final de
semana, etc.) para realizar os testes de performance e estresse nesse servidor? Quais
so os resultados esperados (ex: tempo de resposta por quantidade de usurios)?
O JMeter (http://jakarta.apache.org/jmeter/) uma ferramenta
gratuita da Apache pare realizar testes de performance e
estresse em Aplicaes Web, Banco de Dados, Servidores
FTP, dentre outros. Para realizar os testes em aplicaes Web, o JMeter permite que
voc salve a navegao pelo site, para posteriormente durante a execuo do teste
reproduzir os mesmos passos.
A seguir, os passos necessrios para gravar os testes e em seguida execut-los. Aps
efetuar o download do JMeter, basta acessar a pasta 'bin" e clicar 2 vezes em "jmeter.bat"
(para usurios Windows). O JMeter abrir contendo "Test Plan"(plano de teste) e
"WorkBench" (rea de trabalho). O WorkBench a parte em que ser realizada a
configurao para gravar o teste, e o Test Plan o local onde o teste ser salvo para
poder ser executado.


115
Clique com o boto direito em Test Plan, e em seguida selecione Add>Threads
(Users)>Thread Group. Dessa forma o Thread Group ser adicionado ao seu plano de
teste. O Thread Group representa o nmero de threads (processos, ou nesse caso
tambm pode ser usurios) que acessaro o site em paralelo.
Clique com o boto direito em
Thread Group, e em Add>Config
Element> HTTP Request Defaults
(conforme imagem ao lado), para
adicionar as configuraes da
requisio Http.

No elemento HTTP Request
adicionado, informe a URL ou IP da
aplicao Web que deseja testar. Para
no sobrecarregar nenhum site, vou
realizar a demonstrao com um
Mantis que instalei localmente. Deixe
os outros campos vazios.

Vamos agora para o WorkBench,
configurar a parte responsvel pela
gravao do teste. Clique com o
boto direito no WorkBench,
Add>Non-Test Elements>HTTP Proxy Server. Esse elemento serve para gravar as
requisies que sero enviadas para o servidor. Vale ressaltar que essa parte no ser
salva no plano de teste, ou seja, ao fechar o teste no JMeter e abrir novamente, ser
preciso configurar um novo HTTP Proxy Server, visto que esse elemento utilizado
apenas no momento de gravar o teste, e no durante a sua execuo. Para aplicaes
que precisam de cookie, adicione um HTTP Cookie Manager


116

Quando o JMeter grava uma execuo, ele grava todas
as requests das pginas, incluindo requests de imagem,
stylesheets, arquivos javascript, etc. Portanto no HTTP
Proxy Server importante filtrar os arquivos que no
devem ser salvos no plano de teste. A imagem ao lado
apresenta a configurao para excluir os arquivos do tipo css, gif, png e ico (padro:
".*\nome").

Para poder gravar, ser preciso
configurar o proxy do navegador. Vamos
demonstrar como fazer no Firexox: clique
em Ferramentas>Opes>
Avanado>Rede> Configurar conexo.

Na janela de "Configurar conexo", selecione a
opo "Configurao manual de proxy:", coloque
HTTP: localhost e a porta 8080. Marque a opo
"Usar este proxy para todos os protocolos". Repare
se "Sem proxy para" no contm "localhost". Se
tiver, apague. importante lembrar-se de voltar ao
modo padro ("Sem proxy") aps salvar os testes,
caso contrrio no conseguir acessar pginas
nesse navegador quando o JMeter estiver desligado.


117
Volte na tela HTTP Proxy Server do
JMeter e clique em "Start" para comear
a gravar o teste (conforme imagem ao
lado).
Em seguida v ao navegador com o
proxy configurado e digite o endereo
da aplicao web/site que deseja testar.
No caso desta demonstrao:
http://localhost/mantis/. A partir de agora, toda a navegao ser salva no JMeter,
incluindo os dados informados para login e senha, as pginas clicadas, etc.
Teste as suas configuraes e verifique se est gravando o que interessa, e exclua o
restante. Aps realizar a navegao desejada, volte no JMeter e clique no boto "Stop"
para encerrar a gravao.


118
UNIDADE 26
Objetivo: Objetivo: Visualizar o funcionamento de uma ferramenta para realizao de
testes de performance e estresse, atravs da demonstrao do JMeter
Teste de Performance e Estresse - Ferramenta JMeter IV

A figura abaixo apresenta o resultado da gravao do teste. possvel perceber que
todas as pginas navegadas foram salvas no Thread Group, em conjunto com os dados
pertinentes. Por exemplo, na pgina de login, foram salvos os dados de username e
senha para o JMeter poder realizar o login automaticamente.

Figura 32 Pginas salva e Dados da Pgina de Login

O JMeter oferece diferentes estatsticas para permitir acompanhar o resultado dos testes.
Antes de executar o teste, vamos adicionar duas opes de visualizao. Clique com o
boto direito em Thread Group, e em Add>Listener>View Results Tree, e em


119
Add>Listener>View Results in Table. Vamos agora configurar os dados para executar o
teste, como informaes do nmero de usurios simultneos e de quanto em quanto
tempo novos usurios devem ser iniciados. Para isso, clique em Thread Group e
configure os dados a seguir.
Informe o nmero de usurios (nesse caso os
threads) que devem acessar a aplicao durante o
teste. O "Ramp-Up Period" serve para informar ao
JMeter em quanto tempo ele deve iniciar todos os
usurios. Assim, se for configurado 10 usurios com
um Ramp-Up de 20 segundos, o JMeter comear
um novo usurio a cada 2 segundos (20/10) visto que tem 20 segundos para iniciar os 10
usurios. No caso da figura, os 10 usurios vo ser iniciados em 1 segundo. O "Loop
Count" serve para informar quantas vezes o teste deve ser repetido.
Uma vez definido esses parmetros, clique em Run>Start. O quadro verde e os nmeros
no canto superior direito indicam que o teste est rodando. Acesse o View Results Tree e
o View Results in Table (ou algum outro que tenha adicionado) para visualizar
informaes e estatsticas a respeito da execuo.

Figura 33 Informaes apresentadas em 'View Results in Table" do JMeter


120
No "View Results in Tables" possvel visualizar o tempo de incio, o nome do thread, a
pgina acessada, o tempo de execuo, status e nmero de bytes. No View Results in
Tree possvel ver mais detalhes de cada item testado, como o resultado, a requisio e
resposta de uma tentativa de acesso. A figura abaixo apresenta a visualizao da
resposta em HTML a uma requisio para a pgina login.php.

Figura 34 Informaes apresentadas em 'View Results Tree" do JMeter

A quantidade de threads executando no JMeter vai ser limitada pela capacidade do
hardware. Outro ponto que influencia, a velocidade do servidor. Um servidor rpido
responde s requisies mais rapidamente e assim, o JMeter trabalhar mais, de forma
que cada thread tenha que esperar para acessar o CPU, por isso a informao sobre o
tempo pode ficar menos precisa. Portanto para realizar testes de performance/estresse
em larga escala, pode ser necessrio executar paralelamente vrias instncias do JMeter
sem interface grfica em diferentes mquinas.
Alm dos testes da aplicao web, possvel monitorar a utilizao dos recursos e
performance do servidor. Diferentemente do teste da aplicao que pode ser realizado em


121
sistemas desenvolvidos em qualquer linguagem de programao, o monitoramento do
servidor s pode ser realizado em "Servlets Container" com suporte para o JMX (Java
Management Extension, ou em portugus, Extenso de Gerenciamento Java).
A figura abaixo apresenta um grfico de performance monitorado em um servidor.

Figura 35 Monitoramento do Servidor com JMeter (Apache,2011)

Note que as informaes disponveis nesta Unidade so para fins de estudo e
no devem ser utilizadas para realizar ataques a servidores, ficando o aluno
responsvel pela autorizao de utilizar ferramentas para testes de
estresse/performance nos servidores que precisam ser testados. Aja sempre
de forma tica e no se torne um "criminoso", evitando inclusive problemas
judiciais.


122
UNIDADE 27
Objetivo: Aprender os conceitos da prtica de Integrao Contnua que visa aumentar a
qualidade do cdigo
Integrao Contnua

A Integrao Contnua um termo originado do processo de desenvolvimento gil do XP
(eXtreme Programming). Entretanto, qualquer metodologia pode se beneficiar da
Integrao Contnua.
A Integrao Contnua consiste em uma prtica dos desenvolvedores integrarem o cdigo
alterado/desenvolvido ao projeto principal em uma frequncia alta, muitas vezes
diariamente, com intuito de descobrir o mais cedo possvel se as alteraes no
introduziram novos defeitos ao projeto. Essa prtica pode ser realizada manualmente,
mas prefervel contar com ferramentas que reduzem bastante o esforo.

Controle de Verso de Cdigo
Um ponto chave para realizao da integrao contnua contar com uma boa
ferramenta de controle de verso do cdigo fonte. Existem excelentes ferramentas
gratuitas para esse fim, e uma das mais populares o Subversion
(http://subversion.apache.org/) que considerado por muitos o substituto do CVS.
Os benefcios de utilizar um sistema para controle de verso so inmeros, como: permitir
restaurar verses antigas, comparar um cdigo novo com um antigo que funcionava;
gerenciar as alteraes do cdigo em um nico repositrio, dentre outros. Independente
de utilizar integrao contnua muito importante que todo projeto de software utilize um
sistema de controle de verso.


123
De forma geral, mantida no sistema de controle de verso uma linha de
desenvolvimento principal do projeto, contendo documentao, cdigo fonte, scripts de
teste, arquivos de propriedades, bibliotecas e todos os demais recursos necessrios para
rodar o projeto. possvel criar linhas alternativas de desenvolvimento (normalmente
chamadas de "branches") de forma que essas no atrapalhem o desenvolvimento atual
do projeto. Um exemplo de utilidade restaurar uma verso antiga para corrigir um
determinado bug, sem que essa alterao atrapalhe o desenvolvimento da verso atual
sendo realizada pelos outros desenvolvedores.
Antes de iniciar o desenvolvimento, o desenvolvedor baixa o cdigo do repositrio central
para sua mquina e comea a trabalhar localmente. Ao concluir o desenvolvimento, ele
deve integrar o seu cdigo com o da linha principal do repositrio. Mas antes, ele deve dar
build (compilar, preparar um executvel, rodar testes automatizados, etc.) em sua
mquina para ver se suas alteraes funcionam e passam nos testes. Caso esteja tudo
correto, o desenvolvedor deve se preparar para integrar ao repositrio central. Isso inclui
integrar em sua mquina o cdigo atual que est no repositrio para verificar se tem
algum conflito causando erro de compilao ou nos testes. Esse passo importante visto
que, em paralelo, outros desenvolvedores podem ter submetido suas alteraes para o
repositrio central.
Aps realizar os ajustes necessrios para a integrao funcionar, o desenvolvedor
sincroniza o seu cdigo no repositrio central.
Na Integrao Contnua, esse processo deve ser feito frequentemente, sendo
sincronizado sempre que possvel com o repositrio central. O desenvolvedor s deve
considerar o seu trabalho sincronizado quando realizar um build na mquina de
integrao com a linha principal do cdigo, e todos os testes sejam executados com
sucesso.
Assim, os problemas so encontrados mais rapidamente, visto que a alterao
relativamente pequena, sendo mais fcil de identificar a fonte do problema realizando
debug ou comparao das diferenas. Sem contar que as alteraes esto mais recentes
na memria, facilitando tambm retomar a linha de raciocnio para realizar as devidas
correes. Um ambiente de Integrao Contnua no deve permanecer com uma verso
falha por muito tempo.


124
O processo de realizar o build em uma mquina de integrao e verificar o resultado dos
testes automatizados pode ser realizado manualmente, mas sem dvida uma ferramenta
mais eficiente e eficaz.
Apenas compilar o cdigo no suficiente. importante que os testes automatizados
sejam executados para identificar um nmero maior de defeitos. Um build deve falhar
caso algum teste executado automaticamente falhe.
Muitas equipes agendam o build para executado em um determinado horrio, como por
exemplo, de madrugada. Segundo Martin Fowler, essa abordagem no suficiente para
ser considerada Integrao Contnua, visto que o objetivo encontrar os problemas o
quanto antes, e dessa forma os problemas so descobertos aps 24 horas.
Para ser frequente, a realizao de um build deve ser executada rapidamente. Martin
Fowler argumenta que 10 minutos um tempo suficiente, e apresenta uma estratgia
para atingir esse objetivo, j que alguns builds podem demorar mais por ter que testar
dados acessando o banco de dados, etc. Ele sugere a utilizao de builds em estgios. O
primeiro estgio o build executado automaticamente quando o desenvolvedor submete
o seu cdigo para a linha principal do projeto no repositrio. Esse build tem que prover
feedback rapidamente, portanto ele possui adaptaes para atingir esse objetivo, como
por exemplo, realizar mais os testes unitrios e deixar os testes mais demorados para o
outro build. Portanto, esse build vai detectar uma quantidade menor de bugs, mas o ponto
equilibrar de forma que o build seja rpido e confivel o suficiente. O segundo estgio
pode ser realizado em mquinas adicionais, e esse sim realizar todos os testes,
demorando mais tempo para executar, podendo levar algumas horas. Martin Fowler
argumenta que no segundo estgio os problemas podem ser resolvidos nos dias
seguintes. Para realizar os dois estgios vrias vezes ao dia, transferindo executveis
entre mquinas (fsicas ou virtuais) importante que essa tarefa seja feita
automaticamente.
Sempre que possvel, importante que a mquina que executa os builds se localize, o
mais prximo possvel do ambiente de produo. Incluindo recursos de hardware,
sistemas operacionais, dentre outros.


125
Para implantar a Integrao Contnua, importante conhecer as recomendaes de
Martin Fowler. O primeiro passo construir um build automtico. Mesmo no
considerando um build por dia, Fowler indica que essa pode ser uma boa forma de
comear. Adicionar testes automatizados ao build, se o projeto ainda no os tiver,
comear construindo os testes para as reas que costumam ser problemticas.
O ponto principal de realizar a Integrao Contnua reduzir os riscos, sabendo a todo o
momento o que est funcionando. Vale lembrar que os testes no so perfeitos, e
apontam a presena do defeito, e no a sua ausncia. Apenas executar a Integrao
Contnua, com testes mal elaborados, no vai garantir a qualidade adequada. Entretanto,
a realizao dos testes com uma frequncia alta tende a apontar os defeitos de forma que
sejam mais fceis de descobrir. A maior qualidade est relacionada qualidade dos
testes criados.

Conhea Martin Fowler:

Martin Fowler um renomado palestrante e autor de artigos e
livros, relacionados ao desenvolvimento e testes de software.
Trabalhou com Kent Beck no C3 (projeto que Kent gerenciava e
onde utilizou os mtodos geis que culminaram na escrita do livro
do XP). Desde 2000 trabalha na ThoughWorks empresa
desenvolvedora de ferramentas open-source como o Selenium e o
CruiseControl (para Integrao Contnua).
Possui ampla experincia e bons artigos sobre Integrao Contnua,
e por isso foi utilizado como referncia para esta unidade. Maiores informaes e
artigos disponveis em: http://martinfowler.com. Foto de: Adewale Oshineye.


126
UNIDADE 28
Objetivo: Conhecer algumas funcionalidades de ferramenta para Integrao Contnua,
visualizando o funcionamento da ferramenta Jenkins
Integrao Contnua - Ferramenta Jenkins I

Como explicado na Unidade anterior, a Integrao Contnua pode ser realizada
manualmente ou atravs de ferramentas. A realizao manual consiste no desenvolvedor
realizar o build em sua mquina e em seguida, se tudo estiver certo, no repositrio
central, executar os testes e acompanhar os resultados. A realizao atravs de
ferramenta automatiza todos esses passos: quando o desenvolvedor sincroniza o seu
projeto com o repositrio, a ferramenta gera o build, realiza os devidos testes e
checagens, e informa atravs de e-mail ou outra forma de comunicao configurada, se o
resultado foi positivo ou negativo. Lembrando que o trabalho do desenvolvedor s
considerado terminado quando a integrao apresenta resultado positivo.
O prprio build pode e deve ser automatizado atravs de scripts, utilizando ferramentas
como Ant(Java), Maven (Java), Nant (.Net), MSBuild(.Net), etc. Diferentes builds podem
ser necessrios (ex: builds em estgios), portanto os scripts devem contemplar cada
caso.

O Jekins (http://jenkins-ci.org/) uma ferramenta gratuita para
realizao de Integrao Contnua. fcil de usar e de instalar. O
arquivo jenkins.war pode ser disponibiliizado de duas formas: em um container Java EE
(ex: Tomcat), ou atravs da execuo direta "java -jar jenkins.war", no sendo necessrio
a instalao de um servidor web visto que o Jenkins inicializa um servidor web embutido
(servidor bem pequeno, contm 320 kb), bastando acessar http://localhost:8080/. A
primeira forma recomendada para o uso real, sendo a segunda para demonstrao e
testes da ferramenta. Caso prefira, ao invs do jenkins.war, possvel baixar um


127
instalador nativo para diferentes sistemas operacionais. Para configurar o sistema, clique
em "Gerenciar Jenkins", em seguida em "Configurar Sistema".

Figura 36 Configurar Jenkins

Ao clicar, exibida uma tela com diversas configuraes. Por exemplo, possvel
configurar em qual JDK(Java Development Kit) o projeto deve rodar. Essa configurao
opcional, sendo apenas necessria quando o projeto precisa de uma verso especfica do
JDK para poder ser compilado e/ou realizar testes. possvel configurar tambm o Ant ou
Maven para realizao dos scripts automticos, o Subversion ou CVS (ferramenta para
controle de verso), os dados do e-mail, caso deseje receber notificaes por e-mail,
dentre outros.


128
A figura a seguir apresenta algumas dessas configuraes.

Figura 37 Tela de Configurao do Jenkins


129
O interessante que o Jenkins possui integrao com diversas ferramentas. Atualmente
so mais de 400 plugins disponveis para integrao, sendo bem fcil de instalar,
bastando clicar no plugin desejado e em "instalar".

Figura 38 Instalando Plugins

Alguns dos plugins disponveis so para as ferramentas: JUnit, Emma, Selenium,
Findbugs, Testlink, Checkstyle, etc, ou seja, possvel integrar com algumas ferramentas
gratuitas que foram apresentadas neste mdulo.
Assim, quando um desenvolvedor sincroniza o seu cdigo atravs do CVS ou Subversion,
o Jenkins pode dar o build, gerar e instalar os pacotes, rodar os testes do JUnit,
Selenium,etc em diferentes ambientes, verificar o padro do cdigo, verificar a cobertura
dos testes, enviar os resultados por e-mail ou RSS, dentre outras atividades pertinentes.
E o melhor, tudo isso de forma automtica.


130
O build pode ser configurado para ser realizado sempre em um horrio especfico, ou
ento a cada nova verso sincronizada com o CVS/Subversion.

At Janeiro de 2011 o nome do Jenkins era Hudson. Portanto, muitas das
referncias em artigos, revistas, sites, blogs e fruns estaro com o nome Hudson.
Lembre disso quando for realizar uma pesquisa na Web sobre essa incrvel
ferramenta para Integrao Contnua.


131
UNIDADE 29
Objetivo: Conhecer algumas funcionalidades de ferramenta para Integrao Contnua,
visualizando o funcionamento da ferramenta Jenkins
Integrao Contnua - Ferramenta Jenkins II

Utilizando os plugins, possvel utilizar o Jenkins para controlar projetos em Phyton, PHP,
Net, Android, dentre outros, sem mencionar Java que o padro da ferramenta.
O Jenkins permite criar builds e testes para serem realizados em diferentes
computadores. Essa facilidade permite acelerar o tempo para execuo do build e testes,
uma vez que permite realizar atividades em paralelo. possvel monitorar, atravs do
Jenkins, informaes a respeito dos computadores, como a diferena do relgio, espao
livre em disco, o sistema operacional utilizado, dentre outros.

Figura 39 Acompanhando os Computadores (Kawaguchi, 2009)

O painel de controle apresenta o resumo com informaes visuais para facilitar a rpida
interpretao, em conjunto com dados sobre o perodo e tempo da ltima execuo.


132

Figura 40 Painel de Controle dos Projetos

Na figura anterior, o status azul indica que a ltima execuo foi bem sucedida, enquanto
o amarelo indica instabilidade e o vermelho falha. O cone com sol indica a estabilidade
do projeto de acordo com as ltimas execues. Quanto mais "ensolarado", mas estvel o
projeto. Assim, quando uma das ltimas cinco tiver falhado, o cone parcialmente nublado
apresentado, quando trs das ltimas cinco, o cone totalmente nublado apresentado,
e assim sucessivamente.
Outro exemplo de informao visual o grfico demonstrando o tempo necessrio para
realizar cada build, bem como o respectivo status.

Figura 41 Grfico com a Tendncia dos Builds


133
Ao integrar com ferramentas de cobertura de cdigo como o Emma, possvel visualizar
a porcentagem de cobertura de cada build por blocos, classes, linhas e mtodos.

Figura 42 Grfico com a Tendncia da Cobertura de Cdigo (Austvi,2009)

Outra informao disponibilizada a tendncia
de utilizao de espao em disco. O grfico
apresenta a quantidade de megabytes
utilizada por cada build e pelo cdigo fonte do
projeto. No grfico ao lado, no ltimo build, o
consumo foi de 13 MB pelo cdigo e de 806
KB pelo build.


134
possvel visualizar a sada no console contendo o log do erro.

Figura 43 Log do Console

A prxima figura apresenta a quantidade e informaes dos testes executados por
mdulo.

Figura 44 Resultado dos testes


135
A apresentao do Jenkins ser finalizada visualizando o grfico de tendncia com o
resultado dos testes sucesso/falha por build.

Figura 45 Grfico de Tendncia do Resultado dos testes

Os plugins do Jenkins utilizam o prprio Jenkins na Web para Integrao
Contnua. possvel navegar por esses projetos, e assim conhecer melhor o
Jenkins em: . http://ci.jenkins-ci.org/view/All/


136
UNIDADE 30
Objetivo: Relembrar alguns conceitos estudados e apresentar consideraes sobre
ferramentas
Consideraes Finais

Parabns por completar o estudo do Mdulo de Teste de Software!
Vale relembrar alguns conceitos estudados neste Mdulo. Foram analisados os nveis de
testes existentes. Apresentado tambm os custos referentes ao teste de software, o
custo de testar, da falha e o da correo. O custo provocado por uma falha pode ser
intangvel, podendo custar milhes de reais, processos judiciais, e at mesmo vidas
humanas. Estudou-se ainda, como a realizao dos testes pode proporcionar um retorno
do investimento.
Para poder aumentar a qualidade do software importante que o teste seja abordado
com um processo prprio, e no mais como uma atividade dentro do processo de
desenvolvimento. Mesmo tendo um processo prprio, o de teste est fortemente
relacionado ao de desenvolvimento.
Ter um processo prprio implica em planejar corretamente o projeto de testes. Um dos
grandes desafios definir o quanto de teste adequado e o momento correto de
interromper os testes para liberar o software para produo, de forma a no acontecer:
testes de menos (interrupo muito antes de atingir a cobertura adequada) ou testes em
excesso (custo adicional com os testes no compensa o custo que seria provocado pela
falha). Essa deciso est relacionada anlise de risco do software e avaliao de
mtricas, como por exemplo, quantos testes de alto e mdio risco faltam serem
executados, quantos falharam, quantos faltam ser corrigidos, dentre outros.


137
O ambiente de teste engloba a utilizao de ferramentas adequadas, a
obteno/produo da massa de dados necessria para cada tipo de teste e a utilizao
de configuraes que reproduzam o ambiente de produo.
Quando as condies (exemplo: financeiras) no permitirem alocar uma equipe
independente para realizar os testes, a soluo utilizar a prpria equipe de
desenvolvimento para esse fim. Lembrando que o desenvolvedor no deve ser o
responsvel por testar o prprio cdigo (com exceo dos testes unitrios e alguns testes
de integrao).
A fim de evitar desgastes e prejuzos, o planejamento do projeto deve contemplar os
testes de aceitao em todas as etapas e no somente ao final do projeto, submetendo
sempre que possvel s telas (mesmo que prottipos) e funcionalidades para aprovao
do cliente.
importante realizar as revises e inspees em documentos e diagramas da anlise de
sistemas. Essas revises devem ser feitas o mais cedo possvel e no somente ao final
de cada etapa.
No fechamento do contrato fundamental negociar prazos e custos adequados que
contemplem a realizao dos testes, visto que com as presses por prazos os testes
tendem a ser a primeira parte a ser reduzida.
Desenvolver testes automatizados pode ser muito til para garantir a qualidade do
software e facilitar a realizao dos testes de regresso, mas preciso conhecer os
desafios envolvidos, para desenvolv-los e mant-los atualizados, para avaliar o custo x
benefcios de cada automatizao.

Ferramentas
Foram apresentadas 8 ferramentas gratuitas para: cobertura de cdigo, teste unitrio,
objetos "substitutos" (mock objects), gesto de defeitos, gesto do processo de teste,
teste de estresse e de performance, testes de aplicaes web e integrao contnua.


138
Assim, foi possvel perceber os benefcios oferecidos por cada tipo de ferramenta, e como
elas podem ajudar em diferentes etapas e atividades dos testes. Assim como, perceber
tambm a maturidade de ferramentas gratuitas, eliminando o custo de aquisio, caso
opte por utilizar uma delas.
Vale relembrar algumas consideraes feitas pelo Syllabus da certificao ISTQB em
relao aos riscos de utilizar ferramentas: criar expectativas falsas sobre a ferramenta,
subestimar o tempo necessrio para iniciar o uso da ferramenta, subestimar o esforo
necessrio para manter atualizados os artefatos gerados pelas ferramentas, tentar utilizar
a ferramenta para tudo, mesmo quando a realizao manual for mais adequada.
Algumas ferramentas demonstradas; so especficas para linguagem da programao
Java. Uma vez entendido os benefcios oferecidos por determinado tipo de ferramenta
(independente da linguagem de programao) basta pesquisar na internet por uma
ferramenta similar para a sua linguagem de programao preferida. O site
http://www.opensourcetesting.org um ponto de partida (e no o nico), visto que
apresenta diversas ferramentas para diferentes linguagens.
Muitas das ferramentas, se integram com outras, para otimizar ainda mais a gesto e
execuo do processo de teste. Abaixo seguem alguns links para demonstrar e servir
como pontap inicial para quem desejar realizar integraes, mas outras integraes
podem ser pesquisadas na Internet:
TestLink + Mantis: http://sembugs.blogspot.com/2008/06/integrao-do-testlink-com-
o.html
TestLink + Selenium: http://sembugs.blogspot.com/2010/10/integracao-selenium-e-
testlink.html
Selenium + Mantis: http://sembugs.blogspot.com/2010/10/integracao-selenium-
mantis.html
Selenium+Mantis+Testlink: http://sembugs.blogspot.com/2010/10/projeto-
integracao-selenium-mantis.html
TestLink + Eclipse: http://www.jailtonalkiminlouzada.com/2010/11/integracao-
testlink-e-eclipse/


139

Aps estudar este Mdulo, quais mudanas voc pretende propor em relao
aos testes de software na organizao em que trabalha (seja ela
desenvolvedora de software ou cliente)?

Teste de Software - Pos-graduação-ESAB

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Teste de Software - Pos-graduação-ESAB

Diunggah oleh

Hak Cipta:

Format Tersedia

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Anda mungkin juga menyukai