Testes OO Aspectos Avançados em Engenharia de Software Aula 6 Fernanda Campos DCC/UFJF

Download Testes OO Aspectos Avançados em Engenharia de Software Aula 6 Fernanda Campos DCC/UFJF

Post on 17-Apr-2015

104 views

Category:

Documents

2 download

Embed Size (px)

TRANSCRIPT

<ul><li> Slide 1 </li> <li> Testes OO Aspectos Avanados em Engenharia de Software Aula 6 Fernanda Campos DCC/UFJF </li> <li> Slide 2 </li> <li> Teste de software A fase de teste, no processo de desenvolvimento de software, tem papel crtico na garantia da qualidade. Essa fase fornece subsdios para identificar problemas e mensurar a qualidade dos produtos. A atividade de teste deve resultar em parmetros que nos permitam avaliar o grau de confiana de um sistema. </li> <li> Slide 3 </li> <li> Teste de software necessrio testar um sistema OO em uma variedade de nveis diferentes para descobrir erros que podem ocorrer medida que classes colaboram umas com as outras e subsistemas se comunicam entre si. Teste OO estrategicamente similar ao teste de sistemas convencionais, mas taticamente diferente. </li> <li> Slide 4 </li> <li> Teste de software O teste OO pode comear pela reviso dos modelos da anlise e do projeto. Uma vez gerado o cdigo, comea uma srie de testes para exercitar operaes de classes e verificar se existem erros quando uma classe colabora com outra. medida que as classes so integradas para formar um subsistema, o teste baseado em uso aplicado. Finalmente, casos de uso so usados para descobrir erros em nvel de validao do software. Teste OO enfoca a seqncia de operaes para exercitar os estados de uma classe. </li> <li> Slide 5 </li> <li> Para que testar? Qualidade: Cdigo testado mais confivel Como saber se o recurso funciona sem testar? Coragem para mudar: De que adianta a OO isolar a interface da implementao se o programador tem medo de mudar a implementao? Como saber se ainda funciona aps refatoramento? Saber quando o projeto est pronto. Testes so requisitos executveis. Escreva-os antes. Quando todos rodarem 100%, o projeto est concludo! </li> <li> Slide 6 </li> <li> Todos sabem: testes devem ser escritos; Poucos o fazem, e por qu no ? Sndrome da pressa Isto cria um crculo vicioso Como quebrar este ciclo: criando um ambiente simples de testes. Depois de fazer os primeiros testes, o hbito vem para ficar. Problema com testes (e a soluo) menos testes menos produtividade menos estabilidade mais presso </li> <li> Slide 7 </li> <li> Testar Depurar Simplificando Depurar - o que se faz quando se sabe que o programa no funciona; Testar - tentativas sistemticas de encontrar erros em programa que voc acha que est funcionando. Testes podem mostrar a presena de erros, no a sua ausncia (Dijkstra) </li> <li> Slide 8 </li> <li> Teste de software Duas tcnicas podem ser utilizadas para realizar teste de software: teste funcional e teste estrutural. O teste funcional, tambm chamado teste de "caixa- preta", testa o sistema do ponto de vista do usurio, isto , no considera a estrutura interna ou a forma de implementao do sistema. Este o nico tipo de teste possvel quando no se dispe do cdigo-fonte. O teste estrutural, tambm chamado de teste de "caixa- branca", procura exercitar todas as partes do cdigo- fonte de um sistema. Dessa forma, necessrio ter o cdigo-fonte disponvel, para controlar o que foi e o que no foi testado. </li> <li> Slide 9 </li> <li> Teste enquanto voc escreve cdigo Se possvel escreva os testes antes mesmo de escrever o cdigo uma das tcnicas de XP quanto antes for encontrado o erro melhor !! </li> <li> Slide 10 </li> <li> Tcnicas bsicas Teste o cdigo em seus limites; Teste de pr e ps condies; Uso de premissas (assert); Programe defensivamente; Use os cdigos de erro. </li> <li> Slide 11 </li> <li> Teste o cdigo em seus limites Para cada pequeno trecho de cdigo (um lao, ou if por exemplo) verifique o seu bom funcionamento; Tente uma entrada vazia, um nico item, um vetor cheio, etc. </li> <li> Slide 12 </li> <li> Testes sistemticos Teste incrementalmente durante a construo do sistema aps testar dois pacotes independentemente teste se eles funcionam juntos Teste primeiro partes simples tenha certeza que partes bsicas funcionam antes de prosseguir testes simples encontram erros simples teste as funes/mtodos individualmente </li> <li> Slide 13 </li> <li> Testes Sistemticos Conhea as sadas esperadas conhea a resposta certa para programas mais complexos valide a sada com exemplos conhecidos compiladores - arquivos de teste; numricos - exemplos conhecidos, caractersticas; grficos - exemplos, no confie apenas nos seus olhos. </li> <li> Slide 14 </li> <li> Testes Sistemticos Verifique as propriedades invariantes alguns programas mantm propriedades da entrada nmero de linhas tamanho da entrada freqncia de caracteres </li> <li> Slide 15 </li> <li> Testes Sistemticos Compare implementaes independentes os resultados devem ser os mesmos se forem diferentes pelo menos uma das implementaes est incorreta Cobertura dos testes cada comando do programa deve ser executado por algum teste </li> <li> Slide 16 </li> <li> Automao de testes Testes manuais tediosos, no confiveis Testes automatizados devem ser facilmente executveis </li> <li> Slide 17 </li> <li> Automao de testes Teste de regresso automticos comparar a nova verso com a antiga verificar se os erros da verso antiga foram corrigidos verificar se novos erros no foram criados </li> <li> Slide 18 </li> <li> Automao de testes Crie testes autocontidos testes que contm suas prprias entradas e respectivas sadas esperadas O que fazer quando um erro encontrado? se no foi encontrado por um teste faa um teste que o provoque </li> <li> Slide 19 </li> <li> Arcabouo de testes As vezes para se testar um componente isoladamente necessrios criar um ambiente com caractersticas de onde este componente ser executado </li> <li> Slide 20 </li> <li> Testes de estresse Testar com grandes quantidades de dados gerados automaticamente erros comuns: overflow nos buffers de entrada, vetores e contadores Exemplo: ataques de segurana </li> <li> Slide 21 </li> <li> Tipos de teste white box testes feitos por quem conhece (escreveu) o cdigo black box testes sem conhecer o cdigo usurios encontram novos erros pois usam o programa de formas que no foram previstas </li> <li> Slide 22 </li> <li> Teste OO O processo de teste de software OO apresenta algumas vantagens em relao ao procedural, entre as quais cita-se: Mtodos e interfaces de classes so explicitamente definidos; Menos casos de testes para cobertura do software; Reutilizao de casos de teste devido presena da caracterstica de herana. </li> <li> Slide 23 </li> <li> Teste OO Existem desvantagens como: A avaliao da corretude da classe dificultada pela presena do encapsulamento de informaes; O gerenciamento do teste dificultado pelos mltiplos pontos de entrada (mtodos) de uma classe; As interaes entre os objetos so expandidas pelo polimorfismo e pela ligao dinmica. </li> <li> Slide 24 </li> <li> Tipos de testes em software OO testes das classes testes de interaes testes de regresso teste do sistema e sub-sistemas teste de aceitao testes de implantao </li> <li> Slide 25 </li> <li> Anlise de Riscos Anlise de Riscos ajuda a planejar quais testes devem ser feitos Um risco - ameaa ao sucesso de um projeto riscos do gerenciamento do projeto testes no ajudam muito riscos do negcio testes da funcionalidade riscos tcnicos testes de unidades, das classes, componentes, etc. </li> <li> Slide 26 </li> <li> Dimenses do Processo de Testes Quem cria os testes? Os desenvolvedores? Uma equipe especializada em testes? Ambos? Quais partes so testadas? Todas? Nenhuma? Ou s as de alto risco? Quando os testes sero realizados? Sempre? Rotineiramente? No final do projeto? </li> <li> Slide 27 </li> <li> Dimenses do Processo de Testes Como ser feito? Baseado no que o software faz ou em como o software faz? Os testadores conhecem a implementao ou s a interface? Quanto de testes o adequado? </li> <li> Slide 28 </li> <li> Papis no Processo de Testes Testador de classes Testador da Integrao testa as interaes entre objetos Testador do sistema conhece o domnio e capaz de verificar a aplicao como um todo ponto de vista do usurio do sistema Gerente do Processo de Testes coordena e escalona os testes e as pessoas </li> <li> Slide 29 </li> <li> Planejamento de Testes Muitas vezes esquecido ou no considerado pelos gerentes de projeto Atividades de planejamento: Escalonamento das atividades de testes Estimativas de custo, tempo e pessoal necessrio para realizar os testes Equipamento necessrio </li> <li> Slide 30 </li> <li> Planejamento de Testes Atividades de planejamento: Definio do nvel de cobertura: quanto maior, mais cdigo ser exigido. mtricas para avaliar eficcia de um conjunto de testes cobertura do cdigo cobertura das ps-condies cobertura dos elementos do modelo </li> <li> Slide 31 </li> <li> Testes das Classes (unidades) Uma maneira o peer-review Errar humano Testes automatizados so melhores Testes automatizados devem cobrir alguns casos normais o maior nmero possvel de casos limtrofes </li> <li> Slide 32 </li> <li> Testes das Interaes Objetos podem interagir de 4 formas diferentes: um objeto passado como parmetro para outro objeto numa chamada de mtodo um objeto devolve uma referncia para outro objeto numa chamada de mtodo um mtodo cria uma instncia de outro objeto um mtodo usa uma instncia global de outra classe (normalmente evitado) </li> <li> Slide 33 </li> <li> Casos: Teste das interaes Chamadas de mtodos 2 abordagens: Programao defensiva O receptor verifica os parmetros Programao por contrato A mensagem verificada antes do envio </li> <li> Slide 34 </li> <li> Casos: Teste das interaes Subclasses/superclasses Use o diagrama de classes para identificar quais testes de regresso devem ser realizados quando uma classe alterada ou uma nova classe criada. Execute os testes escritos para a superclasse mas agora usando a nova subclasse Para testar classes abstratas, somos obrigados a criar classes concretas s para test-las </li> <li> Slide 35 </li> <li> O que so ferramentas para testes automticos? So programas que avaliam se outro programa funciona como esperado e retornam resposta do tipo "sim" ou "no. Ex: um main() que cria um objeto de uma classe testada, chama seus mtodos e avalia os resultados Validam os requisitos de um sistema </li> <li> Slide 36 </li> <li> Testes Automticos (self-checking) Os testes devem verificar a si mesmos. A sada deve ser OK ou lista precisa das coisas que deram errado. Quando os testes funcionam, sua sada deve ser apenas uma lista enxuta de Oks. Ou um boto e uma luz verde e outra vermelha. </li> <li> Slide 37 </li> <li> O Testador Ideal executar Teste ver Detalhes OK Erro </li> <li> Slide 38 </li> <li> JUnit: O que ? JUnit um framework que facilita o desenvolvimento e execuo de testes de unidade em cdigo Java Uma API para construir os testes Classes Test, TestCase, TestSuite, etc. oferecem a infraestrutura necessria para criar os testes. Mtodos assertTrue( ), assertEquals( ), fail( ), etc. so usados para testar os resultados. Aplicaes para executar testes (os TestRunner s ) Rodam testes individuais e suites (conjuntos de testes). </li> <li> Slide 39 </li> <li> JUnit: Para que serve? Padro para testes de unidade em Java Desenvolvido por Kent Beck (o guru do XP) e Erich Gamma (do GoF "Design Patterns") Facilita: A criao e execuo automtica de testes A apresentao dos resultados JUnit pode verificar se cada mtodo de uma classe funciona da forma esperada Permite agrupar e rodar vrios testes ao mesmo tempo Na falha, mostra a causa em cada teste Serve de base para extenses </li> <li> Slide 40 </li> <li> CppUnit CppUnit a verso para C++ do JUnit (mas no idntico) http://cppunit.sourceforge.net A sada dos testes pode ser em XML ou em formato de texto para testes automticos, e com interface visual para testes supervisionados </li> <li> Slide 41 </li> <li> JUnit: Como funciona O TestRunner recebe uma subclasse de junit.framework.TestCase Usa reflection para descobrir seus mtodos Para cada mtodo testXXX(), executa: 1. o mtodo setUp() 2. o prprio mtodo testXXX() 3. o mtodo tearDown() O test case instanciado para executar um mtodo testXXX() de cada vez. As alteraes que ele fizer ao estado do objeto no afetaro os demais testes Mtodo pode terminar, falhar ou provocar exceo TestCase MyTestCase setUp() tearDown() setUp() testXXX( ) testYYY( ) tearDown() </li> <li> Slide 42 </li> <li> JMeter: Testes de Stress Uma tima ferramenta open-source para testar os limites de uma aplicao Simula carga pesada em servidor, rede ou objeto Testa performance sob diferentes tipos de carga em aplicaes Web, servidores de FTP, objetos Java, bancos de dados, servlets, scripts em Perl, sistemas de arquivos, e outras aplicaes (Java ou no) Gera grficos com resultados para anlise JMeter pode ser usado para simular carga que cause falha em testes decorados com JUnitPerf http://jakarta.apache.org/jmeter </li> <li> Slide 43 </li> <li> Dependncia de cdigo-fonte Problema: Como testar componente que depende do cdigo de outros componentes? Classe-alvo no oferece o que testar: Se houver tinta e se houver papel mtodo void imprime( ) deve funcionar Como saber se h ou no tinta e papel? public void testImprime( ) { Impressora imp = new Impressora(); imp.imprime( ); // void! assert???(???); } temTinta() Impressora Bandeja Cartucho testImprime()imprime() temPapel() ImpressoraTest </li> <li> Slide 44 </li> <li> Stubs: objetos "impostores" possvel remover dependncias de cdigo-fonte refatorando o cdigo para usar interfaces Agora B pode ser substituda por um stub BStub est sob controle total de ATest (1) Em alguns casos, ATest pode implementar InterB (2) </li> <li> Slide 45 </li> <li> Dependncia: soluo usando stubs Quando usar stubs Dependncia ainda no est pronta Dependncias tm estado mutante, imprevisvel ou esto indisponveis durante o desenvolvimento BDs, servidores de aplicao, servidores Web, hardware </li> <li> Slide 46 </li> <li> Dependncias de servidores Usar stubs para simular servios preciso implementar classes que devolvam as respostas esperadas para diversas situaes Complexidade pode no compensar investir no desenvolvimento Use solues open-source prontas! DBUnit: extenso do JUnit para testar aplicaes JDBC http://dbunit.sourceforge.net JUnitEE: extenso do JUnit para testar aplicaes J2EE http://junitee.sourceforge.net Usar proxies para servios reais Testa a integrao real do componente com seu ambiente Soluo open-source: Cactus: testa integrao da aplicao com servlet containers </li> <li> Slide 47 </li> <li> Cactus: Testes de aplicaes J2EE Cactus um framework open-source do projeto Jakarta para testar aplicaes que utilizam componentes J2EE Componentes Web (Camada de Controle) Camada EJB (Model) e cliente (View): indiretamente Cactus estende o JUnit Execuo dos testes realizada de forma idntica TestCases so construdos herdando de uma subclasse de junit.framework.TestCase (Exemplo: ServletTestCase) </li> <li> Slide 48 </li> <li> Cactus: Testes de aplicaes J2EE Cactus testa a integrao dos componentes Web com seus containers Usa o prprio container como servidor e JUnit como cliente Uma cpia do Test Case instanciada pelo container Outra cpia instanciada pelo JUnit Comunicao intermediada por um proxy (ServletRedirector, JSPRedirector ou Filter...</li></ul>