Módulo VI - Teste de Software

MDULO DE:
TESTE DE SOFTWARE
AUTORIA:
Me. PEDRO HENRIQUE MANNATO COUTINHO
Copyright 2011, ESAB Escola Superior Aberta do Brasil
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 Copyright 2011, ESAB Escola Superior Aberta do Brasil
presentao
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.
O
Para
bjetivo
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. 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.
menta
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,
Copyright 2011, ESAB Escola Superior Aberta do Brasil 3
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.
S
2004).
obre o Autor
Mestre em Informtica (UFES -2007), Graduado em Cincia da Computao (UFES-
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.
UMRIO
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
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
NIDADE
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
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
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.
NIDADE
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."
10
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 (xy). Para testar todas as entradas possveis todos os nmeros inteiros de x e y combinados devem ser testados, gerando uma cardinalidade de 2n * 2n, sendo "n" o nmero de bits usados para representar um inteiro. Em uma arquitetura de 32 bits, a cardinalidade seria 264 (232*232). 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 xy 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.
11
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

NIDADE
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
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
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
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.
16
NIDADE
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.
17
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.
18
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).
19
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.
20
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)

Sem Processo Formal
$0 $0 $0 $0 Desenvolvimento 250 2500 Testes Defeitos Encontrados Custo da Correo 0 0 Suporte ao usurio 750 750.000 Custo da Qualidade $0 $ 752.500 $ 752.500 350 35.000 500 50.000
TESTES
Equipe Infraestrutura Ferramentas e Automatizao Total
Processo Manual
$ 60.000 $10.000 $0 $ 70.000
Teste Automatizado
$ 60.000 $10.000 $12.500 $ 82.500
Defeitos Encontrados Custo da Correo
250 2500
250 2500
Defeitos Encontrados Custo da Correo
400 400.000
250 250.000
Investimento Custo da Correo Total
$ 70.000 $ 437.500 $ 507.500
$ 82.500 $ 302.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%.
21
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.
22
NIDADE
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 sobre Terra o
(http://noticias.terra.com.br/brasil/noticias/0,,OI4602632-EI306,00Gol+diz+a+Anac+que+falha+em+software+causou+erro+em+escala.html) transtorno provocado por uma falha de software:

"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
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
25
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?
26
NIDADE
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.
27
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).
28
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?
29
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
30
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?
31
NIDADE
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
32
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
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).
34
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
Realizar Depsito em Conta Encerrar Conta Cadastrar Fornecedor
Probabilidade
15 5 1
Severidade Prioridade (Impacto) (P.x S.)

15 10 1 225 50 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.
35
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.
36
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?").
37
NIDADE
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. Enganase 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
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 emails, na base de teste fundamental adotar uma poltica que tratem os mesmo,
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
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
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/.
42
NIDADE
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.
43
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.
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
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.
o Percentual de Acerto para aprovao: 60% 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 Percentual de Acerto para aprovao: 75% 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".
47
NIDADE
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
48
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
(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.
50
NIDADE
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, prcondies 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
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.
52
<CT0125 - Realizar depsito de R$ 15.000,00>

Autor Data Pr-condies Dados de entrada Procedimentos Joo Gomes Pereira 14/08/2011 O usurio deve possuir uma conta ativa e estar logado no sistema Usurio: Andr Leal, Conta: 123456, valor para depsito R$ 15.000,00 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 Saldo = saldo inicial + R$ 15.000,00 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 Sem restries especficas Manual RN025 N/A
Dados de sada Ps- Condies
Ambiente Tipo de Execuo (ex:Automtica, Manual) Rastreabilidade Observaes Gerais
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$
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
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"
55
NIDADE
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.
56
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 joao jose carlos ... ... ... marta
Senha joao jose carlos ... ... ... marta
Mensagem Esperada Usurio no cadastrado Bem vindo desenvolvedor Jos Bem vindo administrador Carlos ... ... ... 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.
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.
58
NIDADE
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

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
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 pscondies 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
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.
62
possvel
acessar
um
demonstrativo
on-line
do
TestLink
em
http://testlink.sourceforge.net/demo/login.php.
63
NIDADE
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 }
64
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.
65
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
66
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.
67
NIDADE
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.
68
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.
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.
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
71
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.
72
NIDADE
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

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.
74
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

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.
76
NIDADE
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.
77
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
78
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.
NIDADE
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
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; }
81
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.
ContaBancaria conta; double saldoInicial = 100.00; @Before public void setUp(){ conta = new ContaBancaria(saldoInicial, "12345-0"); }
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.
@Test public void realizarDepositoContaValorMenor10(){ assertEquals(conta.realizarDepositoEmConta(9.99, "12345-0") ,ContaBancaria.MSG_VALOR_MENOR_10); assertTrue(conta.getSaldo()==(saldoInicial)); }
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).
82
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, "123450") ,ContaBancaria.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial)); }
83
cdigo
acima
apresenta
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 e testes um foram falhou, executados,
apresentando a barra vermelha. Ele indica atravs de cones que o teste que
realizarDepositoContaValorIgual10_MIL(),sendo realizarDepositoContaValorMenor10().
causou
erro
foi
que o primeiro teste foi bem sucedido
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.
@Test public void realizarDepositoContaValorIgual10_MIL(){ assertEquals(conta.realizarDepositoEmConta(10000.00, "123450"), ContaBancaria.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial + 10000.00)); }
Ao
executar
esse
teste,
JUnit bem
apresenta o resultado que os dois testes sucedidos. Por sua vez, o EclEMMA apresenta que o mtodo foi completamente coberto pelos testes. executados foram
Esse foi apenas um exemplo simples para demonstrar o JUnit e o EclEmma.

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".
85
NIDADE
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
86
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
87
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:
ContaDao mockDao = mock(ContaDao.class);
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);
88
Para ver na prtica, repetiu-se o exemplo da unidade anterior adicionando a verificao se a conta est ativa antes de realizar o depsito.
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; } } }
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.
89
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.
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); assertTrue(conta.getSaldo()==(saldoInicial)); } @Test public void realizarDepositoContaValorIgual10_MIL(){ when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true ); assertEquals(conta.realizarDepositoEmConta(10000.00, "12345") ,Conta.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial + 10000.00)); }
no
mtodo
realizarDepositoContaValorIgual10_MIL
foi
adicionada
linha que
when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true);
indicando
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
"12345")
abaixo, o
ao
chamar
conta.realizarDepositoEmConta(10000.00,
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.
90
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.

@Test public void realizarDepositoContaInativa(){ when(mockDao.verificarSeContaAtiva("67891")).thenReturn(fals e); assertEquals(conta.realizarDepositoEmConta(50.00, "67891") ,Conta.MSG_CONTA_INATIVA); }
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.
91
NIDADE
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.
92
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.
93
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
94
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.
95
NIDADE
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)); }
96
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.
public int fib(int n) { return 0; }
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.
@Test public void testFibonacci() { assertEquals(0, fibonacci.fib(0)); assertEquals(1, fibonacci.fib(1)); }
O teste vai falhar, visto que de acordo com o cdigo implementado Fib(1) =0 ao invs de 1. Esse comportamento
97
est de acordo com o que prega o TDD. Agora, acerta-se o cdigo, desenvolvendo uma implementao mais simples para obter a barra verde.
public int fib(int n) { if(n==0)return 0; return 1; }
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.
@Test public void testFibonacci() { assertEquals(0, fibonacci.fib(0)); assertEquals(1, fibonacci.fib(1)); assertEquals(1, fibonacci.fib(2)); }
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 public void testFibonacci() { 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])); } }
98
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:
public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return 2; }
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.
public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return 1 + 1; }
99
Como se sabe que o primeiro 1 = F(n-1), se faz essa alterao.

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return fib(n-1) + 1; }
A seguir, substituir o segundo 1 = F(n -2).

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return fib(n-1) + fib(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.
100
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.
101
NIDADE
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.
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.
103
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.
104
NIDADE
23
Objetivo: Conhecer a ferramenta Selenium para automatizar testes de aplicaes Web 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
105
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
106
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 type Alvo Name=username Valor pedro
Figura 27 Estrutura de um comando "Selenese"
107
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
108
NIDADE
24
Objetivo: Conhecer a ferramenta Selenium para automatizar testes de aplicaes Web 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.
109
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
110
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 open type type clickAndWait verifyText
Alvo Valor /demo/login_page.php?return=%2Fdemo%2Fmy_view_page.php%3F name=username pedro name=password pedro css=input.button 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.
111
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).
112
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.
113
NIDADE
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.
114
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
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 Avanado>Rede> Configurar conexo. Ferramentas>Opes>
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.
116
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.
117
NIDADE
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
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
119
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
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.
121
NIDADE
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.
122
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.
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.
124
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.
125
NIDADE
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
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.
127
A figura a seguir apresenta algumas dessas configuraes.
Figura 37 Tela de Configurao do Jenkins
128
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.
129
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.
130
NIDADE
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.
131
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
132
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.
133
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
134
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/
135
NIDADE
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.
136
ambiente
de
teste
engloba
utilizao
de
ferramentas
adequadas,
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.
137
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-como.html TestLink + Selenium: http://sembugs.blogspot.com/2010/10/integracao-selenium-etestlink.html Selenium + Mantis: http://sembugs.blogspot.com/2010/10/integracao-seleniummantis.html Selenium+Mantis+Testlink: integracao-selenium-mantis.html TestLink + Eclipse: http://www.jailtonalkiminlouzada.com/2010/11/integracaotestlink-e-eclipse/ http://sembugs.blogspot.com/2010/10/projeto-
138
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)?
139

Módulo VI - Teste de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Módulo VI - Teste de Software

Uploaded by

Copyright:

Available Formats

MDULO DE:

Me. PEDRO HENRIQUE MANNATO COUTINHO

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Mestre em Informtica (UFES -2007), Graduado em Cincia da Computao (UFES-

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Objetivo: Realizar uma apresentao inicial do contedo do Mdulo de Teste de Software

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Figura 2 Teste Caixa-preta e Teste Caixa-branca

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Custos de Testar; da Correo e o Retorno de Investimento em Testes.

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Figura 3 Economia proporcionada ao investir em testes de software

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

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

Defeitos Encontrados Custo da Correo

Defeitos Encontrados Custo da Correo

Investimento Custo da Correo Total

$ 70.000 $ 437.500 $ 507.500

$ 82.500 $ 302.500 $ 385.000

Tabela 1 Retorno de Investimento em Testes adaptado de (Black, 2010)

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Custos das Falhas

(http://noticias.terra.com.br/brasil/noticias/0,,OI4602632-EI306,00Gol+diz+a+Anac+que+falha+em+software+causou+erro+em+escala.html) transtorno provocado por uma falha de software:

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

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

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Figura 5 Abordagem de Testes com um Processo Prprio

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Figura 6 Forma usual de representar o Modelo V

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Objetivo: Apresentar os fatores envolvidos em um bom planejamento de testes

Planejamento dos Testes

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Severidade Prioridade (Impacto) (P.x S.)

Tabela 2 Exemplo simples de clculo de prioridade de funcionalidade a ser testada

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Objetivo: Entender os aspectos envolvidos com a preparao do ambiente de teste

Copyright 2011, ESAB Escola Superior Aberta do Brasil

A Equipe e os Papis nos Testes

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Tcnicas Estticas - Reviso e Inspeo

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Copyright 2011, ESAB Escola Superior Aberta do Brasil

Objetivo: Conhecer os conceitos e contedo dos casos de Teste

Copyright 2011, ESAB Escola Superior Aberta do Brasil

<CT0125 - Realizar depsito de R$ 15.000,00>

Dados de sada Ps- Condies

Ambiente Tipo de Execuo (ex:Automtica, Manual) Rastreabilidade Observaes Gerais

Figura 8 Exemplo de um caso de teste