A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho Simpósio de Desenvolvimento e Manutenção de Software.

Apresentações semelhantes


Apresentação em tema: "Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho Simpósio de Desenvolvimento e Manutenção de Software."— Transcrição da apresentação:

1 Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho Simpósio de Desenvolvimento e Manutenção de Software da Marinha (SDMS 2004)

2 Laboratório de Engenharia de Software – PUC-Rio Objetivo Apresentar um conjunto de técnicas muito eficazes embora pouco usuais voltadas ao desenvolvimento de software correto por construção e ao apoio ao teste de programas.

3 Laboratório de Engenharia de Software – PUC-Rio Agenda 1.Motivação 2.Prevenção e Detecção de Falhas –possíveis formas de prevenir a inserção de faltas no software ao longo do ciclo de desenvolvimento; –técnicas para identificação de faltas já contidas no software. 3.Automação de Testes –resumo das principais ferramentas freeware para automação de testes.

4 Laboratório de Engenharia de Software – PUC-Rio Motivação Existe grande possibilidade de inclusão de faltas durante o ciclo de desenvolvimento de software. Planejamento Inicial Definição dos Requisitos Design Lógico Design Físico Codificação Testes Manutenção Cerca de 40 a 50% dos programas disponibilizados contém faltas graves!!

5 Laboratório de Engenharia de Software – PUC-Rio Motivação –Como reduzir este percentual? –Como reduzir os possíveis prejuízos? –Como evitar a propagação de danos? Temos duas abordagens: –Detectar as faltas já incluídas durante o ciclo de desenvolvimento; –Prevenir a inclusão de faltas ao longo do ciclo de desenvolvimento.

6 Detecção e Prevenção de Falhas

7 2.1 Detecção de Falhas por Intermédio de Testes

8 Laboratório de Engenharia de Software – PUC-Rio 8 As falhas podem ser detectadas: –através de inspeções e outras atividades off-line –através de processos de teste cuidadosos e bem planejados. O processo de teste faz parte da garantia de qualidade; Os custos decorrentes de falhas de software justificam um processo de teste cuidadoso e bem planejado –através de instrumentação inserida no código As faltas podem ser prevenidas: –através de especificações mais rigorosas –através da adoção de padrões de codificação e de técnicas de instrumentação –através da definição dos testes antes de desenvolver 2. Detecção e Prevenção de Falhas

9 Laboratório de Engenharia de Software – PUC-Rio 9 Objetivo dos testes –Verificar se todos os requisitos do sistema foram corretamente implementados –Assegurar, na medida do possível, a qualidade e a corretude do software produzido –Contribuir para a redução do retrabalho através de testes abrangentes –Reduzir custos de manutenção corretiva –Assegurar a satisfação do cliente com o produto desenvolvido

10 Laboratório de Engenharia de Software – PUC-Rio Problemas básicos Teste somente sinaliza a presença de faltas, nunca a sua ausência. E.W. Dijkstra Realistic test planning is dominated by the need to select a few test cases from a huge set of possibilities. No matter how hard you try, you will miss important tests. No matter how careful and thorough a job you do, you will never find the last bug in a program, or if you do, you will not know it. Kaner, C.; Falk, J.; Nguyen, H.Q.;

11 Laboratório de Engenharia de Software – PUC-Rio O que é um teste? –O teste é realizado através de uma série de casos de teste a massa de teste –A confiabilidade do teste depende do critério de seleção dos casos de teste –Existem diversos critérios de seleção de casos de teste cada um tem um domínio de efetividade tendem a gerar um número grande de pequenos casos de teste

12 Laboratório de Engenharia de Software – PUC-Rio Conceito chave: caso de teste Texto associado a um requisito a ser testado, que descreve: –pré-condições de execução –passos específicos do teste a ser executado –resultados esperados e/ou pós-condições de execução IDENTIFICADOR DO CASO DE TESTE: RF012 DESCRIÇÃO: Para fazer o Upload do Resumo o usuário deve clicar... PRE-CONDICOES: Usuário está cadas- trado no sistema e usuário fez login no sistema POS-CONDICOES: Um link para o Resumo submetido é mostrado na tela de Upload. CRITÉRIO DE SUCESSO: Sistema realiza upload em menos de 30 seg.

13 Laboratório de Engenharia de Software – PUC-Rio 13 Conceito chave: estágios de teste Teste de unidade –componentes individuais (ex: classes, métodos) são testados para assegurar que operam de forma correta Teste de integração –a interface entre as unidades integradas é testada Teste de sistema –os elementos de software integrados com o ambiente operacional (hardware, pessoas, etc.) são testados como um todo Teste de aceitação (homologação) –o software é testado pelo usuário final

14 Laboratório de Engenharia de Software – PUC-Rio 14 Conceito chave: Tipos de Teste Teste de desempenho –tempo de resposta e processamento –uso de recursos Teste de volume (carga) –verifica se o sistema suporta altos volumes de dados Teste de estresse –verifica a funcionalidade do sistema em situações limite Teste de instalação e desinstalação Teste de recuperação de falhas Teste de segurança e controle de acesso

15 Laboratório de Engenharia de Software – PUC-Rio Conceito chave: Processo de testes

16 Laboratório de Engenharia de Software – PUC-Rio Conceito chave: Processo de testes

17 Laboratório de Engenharia de Software – PUC-Rio Motivação para automação dos testes Diagnose cara, imprecisa e demorada Desenvolvimento incremental com teste manual: –muito caro –muito sujeito a panes –inviável ao considerar integração evolução –elimina virtualmente as vantagens do desenvolvimento incremental

18 2.2 Detecção automatizada

19 Laboratório de Engenharia de Software – PUC-Rio Automação da detecção O diagnóstico das causas dos problemas identificados durante os testes: –Requer muito esforço (tempo) –É sujeito a muitos erros humanos –Tende a ser impreciso –Pode ser decorrente de condições adversas acidentes agressões

20 Laboratório de Engenharia de Software – PUC-Rio Automação da detecção O diagnóstico das causas dos problemas (cont.) –Possível existência de causas externas ao código em teste ponteiros loucos overflow esgotamento de recursos –Inconsistência entre o imaginado pelo desenvolvedor e o mundo real comportamento inesperado do hardware comportamento inesperado do código gerado comportamento inesperado das bibliotecas

21 Laboratório de Engenharia de Software – PUC-Rio Auto-controle Programas podem controlar se estão operando corretamente: –automatizando assertivas de entrada e assertivas de saída (pré e pós condições): assertivas são expressões lógicas que indicam o que deve ser verdade em determinado ponto do programa

22 Laboratório de Engenharia de Software – PUC-Rio Exemplos de assertivas y : 1 - < y 2 /x < 1 +, é a precisão esperada, e.g. 10**-5 pElem : *pElem Lista, se pElem->pAnt != NULL => pElem->pAnt->pProx == pElem registros i e j : i, j arquivo-A, se i é antecessor de j => i.Chave < j.Chave Um aluno a está matriculado se e somente se: a AlunosRegistrados e d : d DisciplinasOferecidasSemestre => matriculado( a, d)

23 Laboratório de Engenharia de Software – PUC-Rio Instrumentação, objetivos –Detectar falhas de funcionamento no programa o mais cedo possível de forma automática (sem necessitar da intervenção humana) –Impedir que falhas provoquem danos expressivos propaguem danos para outras partes do programa ou de outros sistemas –Medir propriedades dinâmicas do programa cobertura dos testes onde são consumidos recursos computacionais tempos de processamento número de transações número de erros de uso...

24 Laboratório de Engenharia de Software – PUC-Rio Instrumentação, o que é A instrumentação –estabelece e explora redundâncias –verifica e registra propriedades dos dados manipulados –verifica e registra propriedades da execução

25 Laboratório de Engenharia de Software – PUC-Rio Instrumentação, o que é A instrumentação –é formada por fragmentos de código inseridos no código –não contribui para a realização do serviço a que se destina o programa monitora a execução pode ser retirada sem alterar o serviço do componente instrumentado –exceto o desempenho observado –custa para ser desenvolvida –precisa ter sua qualidade assegurada

26 Laboratório de Engenharia de Software – PUC-Rio Assertivas executáveis –É possível traduzir uma parcela considerável das assertivas (especificações, contratos, laws) para código executável –Assertivas executáveis reduzem o esforço de diagnose evidenciam a existência de uma falha quase imediatamente após ter sido gerada –Assertivas executáveis viabilizam o uso de componentes quase corretos no caso de falha interceptam a execução tornam robustos os programas viabilizam o teste através do uso

27 Laboratório de Engenharia de Software – PUC-Rio Exemplo, assertiva executável void PG_CPage :: BuildPage( const int idSegParm ) { #ifdef _DEBUG EXC_ASSERT( idPag == TAL_NullIdPag ) ; EXC_ASSERT( idSeg == TAL_NullIdSeg ) ; EXC_ASSERT( pFrame == NULL ) ; EXC_ASSERT( idSegParm != TAL_NullIdSeg ) ; EXC_ASSERT( idSegParm >= 0 ) ; #endif...

28 Laboratório de Engenharia de Software – PUC-Rio Assertivas executáveis –Para serem úteis assertivas executáveis devem estar corretas ser completas não interferir no processamento –exceto no que diz respeito a consumo de recursos computacionais ser confiáveis –falhas de determinada categoria certamente serão observadas

29 Laboratório de Engenharia de Software – PUC-Rio Assertiva estrutural executável TST_tpCondRet ARV_VerificarNo( void * pNoParm ) { tpNoArvore * pNo = NULL ; tpArvore * pArvore = NULL ; /* Verificar se é nó estrutural */ if ( pNoParm == NULL ) return TST_NotificarFalha( "Tentou verificar nó inexistente." ) ; if ( TST_CompararInt( ARV_TipoEspacoNo, CED_ObterTipoEspaco( pNoParm ), "Tipo do espaço de dados não é nó de árvore." ) != TST_CondRetOK ) return TST_CondRetErro ; pNo = ( tpNoArvore * )( pNoParm ) ; pArvore = pNo->pCabeca ; /* Verificar cabeça */ if ( pArvore->pNoRaiz != NULL ) { if ( TST_CompararPonteiro( pArvore, pArvore->pNoRaiz->pCabeca, "Nó não pertence à árvore." ) != TST_CondRetOK ) return TST_CondRetErro ; } else { return TST_NotificarFalha( "Nó pertence a árvore vazia." ) ; } /* if */...

30 3. Automação de Testes

31 Laboratório de Engenharia de Software – PUC-Rio Automação de Testes Ferramentas de Teste automatizam atividades do processo de testes –Muito úteis para testes de regressão Tipos de ferramentas: –Planejamento e Projeto de Testes apoio ao planejamento e elaboração dos artefatos de teste bug-tracking – gerência de mudanças –Implementação de Componentes de Teste geração de massa de dados teste de interface de unidades e verificação de assertivas teste de cobertura inspeção de código teste de GUI (capture/replay) teste de carga e estresse teste de desempenho/detecção de gargalos análise de memory leaks

32 Laboratório de Engenharia de Software – PUC-Rio Exemplo de arcabouço (framework)

33 Laboratório de Engenharia de Software – PUC-Rio Processo x Ferramentas de Teste Em que momento as ferramentas de teste podem nos auxiliar no processo de teste? Quais ferramentas utilizar em cada atividade do processo?

34 Laboratório de Engenharia de Software – PUC-Rio Processo x Ferramentas de Teste Ferramentas de Planejamento e Projeto de Testes

35 Laboratório de Engenharia de Software – PUC-Rio Atividade: Elaborar plano de testes –Podem ser usadas para elaboração do documento plano de testes (requisitos a testar, prioridade, estratégias, cronograma, recursos) Exemplos: Ferramenta de edição de texto (Word, StarOffice); Ferramenta para elaboração de cronogramas (Project); Ferramenta de planejamento e projeto de Testes (TestManager, TestDirector, QADirector) Ferramentas de planejamento e projeto de testes

36 Laboratório de Engenharia de Software – PUC-Rio Atividade: Projetar testes –Podem ser usadas para elaboração do projeto de testes (casos e procedimentos de teste, planilhas de dados) Exemplos: Ferramenta de edição de texto (Word, StarOffice); Ferramenta para manipulação de planilhas eletrônicas (StarOffice, Excel); Ferramenta de planejamento e projeto de Testes (TestManager, TestDirector, QADirector) Ferramentas de planejamento e projeto de testes

37 Laboratório de Engenharia de Software – PUC-Rio Atividade: Executar Testes –Podem ser usadas para registro dos testes manuais realizados Exemplos: –Ferramenta de edição de texto ou manipulação de planilhas (Word ou Excel); –Ferramenta de planejamento e projeto de Testes (TestManager); –Podem ser usadas para registro de erros encontrados e solicitação de mudanças/correções ao software Exemplos: –Ferramenta de gerência de mudanças (Bugzilla); –Ferramenta para manipulação de planilhas (Excel); Ferramentas de planejamento e projeto de testes

38 Laboratório de Engenharia de Software – PUC-Rio Atividade: Avaliar Testes –Podem ser usadas para elaboração do documento de avaliação de testes (resultado sumarizado dos testes, cobertura dos casos de teste) Exemplos: –Ferramenta de edição de texto ou manipulação de planilhas (Word ou Excel); –Ferramenta de planejamento e projeto de Testes (TestManager); –Podem ser usadas para solicitação de mudanças ao processo de testes Exemplos: –Ferramenta de gerência de mudanças (Bugzilla); Ferramentas de planejamento e projeto de testes

39 Laboratório de Engenharia de Software – PUC-Rio Processo x Ferramentas de Teste Ferramentas para Implementação de Componentes de Teste

40 Laboratório de Engenharia de Software – PUC-Rio Atividade: Implementar Testes –Podem ser usadas para implementação dos componentes de teste –Cada tipo de teste pode ser automatizado por um conjunto de ferramentas específicas Atividade: Executar Testes –Podem ser usadas para execução automatizada dos testes Ferramentas para Implementação dos componentes de testes

41 Laboratório de Engenharia de Software – PUC-Rio Atividade: Implementar Testes (continuação) –Exemplos: teste de API de unidades e verificação de assertivas (JUnit, HttpUnit,JContractor); teste de cobertura (Clover, NoUnit ); inspeção/análise estática de código, refactoring (Jtest) teste de GUI (Canoo Web Test, WinRunner – capture replay) teste de carga e estresse (JMeter) teste de desempenho/detecção de gargalos (JProbe, Pruify) análise de memory leaks (JProbe, Pruify) Ferramentas para Implementação dos componentes de testes

42 Laboratório de Engenharia de Software – PUC-Rio Quando e por que automatizar os testes? –Processo Iterativo e Incremental permite reuso de casos de testes automatizados em diversas iterações; –Alguns tipos de teste são inviáveis e/ou custosos para serem feitos de forma manual: Testes de Performance, Carga/Estresse, Memory Leaks, Testes de Cobertura Ferramentas para Implementação dos componentes de testes

43 Laboratório de Engenharia de Software – PUC-Rio Quando e por que automatizar os testes? (cont.) –Sistema funcionará por longo período, o custo de automatização dos testes é amortizado ao longo do tempo; –Testes Automatizados Funcionais encorajam modificações no código; –Requisitos instáveis devem ter a automação de seus testes postergada; Ferramentas para Implementação dos componentes de testes

44 Ferramentas de Teste Gratuitas

45 Laboratório de Engenharia de Software – PUC-Rio Ferramentas de Teste Gratuitas Open Source –JUnit: Teste de Unidade/Integração NoUnit: Avaliação da cobertura dos Testes do Junit –JMeter: Teste de Performance/Carga –Canoo Web Test/HttpUnit: Teste de Sistema/Funcionalidade

46 JUnit

47 Laboratório de Engenharia de Software – PUC-Rio Testes de Unidade - JUnit Framework que auxilia na execução e na criação de testes de unidade na linguagem Java. –Aplicação standalone –Plug-in do Eclipse

48 Laboratório de Engenharia de Software – PUC-Rio Recursos do JUnit Permite criação de testes individuais para os métodos pertencentes a uma classe Permite a definição e execução de um conjunto de testes individuais – Suites de Teste Permite a execução de baterias de teste com relato de problemas ocorridos e onde especificamente ocorreram as falhas e erros

49 Laboratório de Engenharia de Software – PUC-Rio Usando o JUnit Passo 1: para cada classe a ser testada criar uma classe de Teste –Exemplo: classe Conta terá como classe de teste ContaTest A classe de Teste deve herdar da classe TestCase do framework JUnit

50 Laboratório de Engenharia de Software – PUC-Rio Exemplo - classe de teste import junit.framework.*; public class ContaTest extends TestCase { public ContaTest(String name) { super(name); }... } Importar classes do framework JUnit Herdar da classe TestCase Definir um construtor que recebe uma String

51 Laboratório de Engenharia de Software – PUC-Rio Usando o JUnit Passo 2: criar métodos de teste que se iniciam com a palavra test e possuem tipo de retorno void. Exemplo para a classe ContaTest: –public void testCredito() –public void testDebito() –public void testCreditoNegativo() –public void testDebitoNegativo() Passo 3: para cada método de teste definir seu comportamento: –invocação de métodos da classe do sistema a ser testada –avaliação do resultado dos métodos sendo testados usando os métodos assertEquals(), fail(), assertNull(), assertNotNull() do framework JUnit

52 Laboratório de Engenharia de Software – PUC-Rio Exemplo - classe de teste public class ContaTest extends TestCase {... public void testCreditar(){ Conta conta22_Saldo70 = new Conta(22, 70.0); Conta conta22_Saldo30 = new Conta(22, 30.0); conta22_Saldo30.creditar(40.0); this.assertEquals(conta22_Saldo30 conta22_Saldo70); } Declaração do método Definição do método

53 Laboratório de Engenharia de Software – PUC-Rio Métodos de Teste assertEquals (valorEsperado, valorTestado); assertTrue (expressaoBooleana); assertNull(objeto); assertNotNull(objeto); assertSame(objeto1, objeto2); fail (mensagem);

54 Laboratório de Engenharia de Software – PUC-Rio Exemplos - métodos do JUnit para teste public class ContaTest extends TestCase {... public void testDebitar(){ Conta conta22_Saldo70 = new Conta(22, 70.0); Conta conta22_Saldo30 = new Conta(22, 30.0); try { conta22_Saldo70.debitar(40.0); } catch(SaldoInsuficienteException saldo){ fail("Operacao de Debito falhou"); } this.assertEquals(conta22_Saldo30, conta22_Saldo70); }

55 Laboratório de Engenharia de Software – PUC-Rio Exemplos - métodos do JUnit para teste public class ContaTest extends TestCase {... public void testDebitoNegativo(){ Conta conta22_Saldo70 = new Conta(22, 70.0); try { conta22_Saldo70.debitar(73.0); fail("Deveria lançar SaldoInsuficienteException"); } catch(SaldoInsuficienteException saldo){ } Teste de Lançamento de Exceções

56 Laboratório de Engenharia de Software – PUC-Rio Métodos de configuração de testes Método setUp(): –Utilizado para definir configurações iniciais comuns aos métodos de teste ( inicialização de objetos, alocação de recursos - abertura de conexões de BD, sockets, etc) –É executado antes de cada método de teste; Método tearDown() –Utilizado para liberar recursos utilizados pelos métodos de teste; –Exemplos de recursos que podem ser liberados: streams, fechar conexões de banco de dados, apagar/mover arquivos de dados.

57 Laboratório de Engenharia de Software – PUC-Rio Exemplos - métodos do JUnit para configuração dos casos de teste public class ContaTest extends TestCase { Conta conta22_Saldo70; Conta conta22_Saldo30;... public void setUp(){ this.conta22_Saldo70 = new Conta(22, 70.0); this.conta22_Saldo30 = new Conta(22, 30.0); }... } Execução antes de cada método de teste

58 Laboratório de Engenharia de Software – PUC-Rio Suites de testes Quando falamos em teste automatizado é comum querermos executar um conjunto de testes de uma única vez; Suites de testes representam um conjunto de testes que serão executados seqüencialmente; JUnit define classe TestSuite que: –Permite incluir todos os métodos de teste de uma classe em um suite de teste; –Permite definir uma classe que inclui todos os suites de teste do sistema. TestSuite TestCase......

59 Laboratório de Engenharia de Software – PUC-Rio Exemplos – suites de testes Definindo o suite de testes de apenas uma classe de testes... public class ContaTest extends TestCase {... public static Test suite(){ return new TestSuite(ContaTest.class); } public static void main(String[] args){ junit.textui.TestRunner.run(suite()); }... } Definição do suite de teste da classe Método main() da classe invoca suite de teste

60 Laboratório de Engenharia de Software – PUC-Rio Exemplos – suites de testes Agregando um conjunto de suites de teste public class AllTest {... public static void main(String[] args){ junit.textui.TestRunner.run(suite()); } public static Test suite(){ TestSuite suite = new TestSuite("All JUnit Tests"); // suite.addTestSuite(new TestSuite( ContaTest.class )); ou suite.addTest(ContaTest.suite()); }... }

61 JMeter

62 Laboratório de Engenharia de Software – PUC-Rio JMeter Projeto do Grupo Apache Utilizado para criação e execução de testes de carga em aplicações Web. Para utilizar a ferramenta basta: 1.Fazer download: 2.Descompactar: bin:scripts para inicialização docs: manual HTML extras: arquivos relacionados com a integração com o Ant lib: biliotecas utilizadas printable_docs: manual pronto para impressão 3.inicializar: /bin/jmeter.bat

63 Laboratório de Engenharia de Software – PUC-Rio JMeter – Tela inicial JMeter Cria automaticamente um Plano de Testes – Test Plan

64 Laboratório de Engenharia de Software – PUC-Rio Criando um Plano de Testes Usaremos uma aplicação exemplo do Tomcat Calendar: (http://localhost:8080/examples/jsp/cal/login.html).http://localhost:8080/examples/jsp/cal/login.html Vamos simular o acesso concorrente de 10 usuários e gerar relatórios com os resultados;

65 Laboratório de Engenharia de Software – PUC-Rio Criando um Plano de Testes Vamos simular o acesso concorrente de 10 usuários e gerar relatórios com os resultados; Objetivo do Teste: Medir o tempo médio de resposta de todas as requisições, identificar a página que consome mais tempo.

66 Laboratório de Engenharia de Software – PUC-Rio JMeter Primeiro Passo: –Inicializar o JMeter: /bin/jmeter.bat

67 Laboratório de Engenharia de Software – PUC-Rio JMeter Segundo Passo: –Configurar valores comuns entre as URLs; Como? –Criar componentes Config Elements do tipo HTTP Request Defaults; As URLs a serem acessadas são muito semelhantes: 1.http://localhost:8080/examples/jsp/cal/login.html, 2.http://localhost:8080/examples/jsp/cal/cal1.jsp?name=teste&e 3.http://localhost:8080/examples/jsp/cal/cal2.jsp?time=8am 4.http://localhost:8080/examples/jsp/cal/cal1.jsp

68 Laboratório de Engenharia de Software – PUC-Rio JMeter Segundo Passo:

69 Laboratório de Engenharia de Software – PUC-Rio JMeter Terceiro Passo: –Configurar as requisições HTTP Como? –Adicionar um Thread Group (responsável pela criação de threads). Cada thread representará 1 usuário;

70 Laboratório de Engenharia de Software – PUC-Rio JMeter Permite agendar um horário para início e fim dos testes

71 Laboratório de Engenharia de Software – PUC-Rio JMeter Configurar as requisições HTTP - Como? (cont.) –Adicionar dois elementos do grupo Logic Controller: Once Only Controller: que irá conter requisições que só devem ocorrer 1 vez por usuário (ex: inicial, efetua, login) Simple Controller: que irá conter requisições que ocorrem mais de 1 vez por usuário (ex: seleciona horário,adiciona)

72 Laboratório de Engenharia de Software – PUC-Rio JMeter Configurar as requisições HTTP - Como? (cont.) –Adicionar o HTTP Request: Página inicial.

73 Laboratório de Engenharia de Software – PUC-Rio JMeter Configurar as requisições HTTP - Como? (cont.) –Adicionar o HTTP Request: submissão do dos dados de Login.

74 Laboratório de Engenharia de Software – PUC-Rio JMeter Configurar as requisições HTTP - Como? (cont.) –Adicionar um HTTP Request: Novo Compromisso

75 Laboratório de Engenharia de Software – PUC-Rio JMeter Configurar as requisições HTTP - Como? (cont.) –Adicionar um HTTP Request: Adiciona Novo Compromisso.

76 Laboratório de Engenharia de Software – PUC-Rio JMeter Quarto e Último Passo: –Definir a forma de apresentação dos resultados Como? –Adicionando os Listeners ao plano de testes;

77 Laboratório de Engenharia de Software – PUC-Rio Agregate Report

78 Laboratório de Engenharia de Software – PUC-Rio View Results Tree

79 Laboratório de Engenharia de Software – PUC-Rio Graph Results Cada ponto preto do gráfico representa uma requisição de teste enviada A altura vertical do ponto representa o tempo em milisegundos para atendimento do request; Gráfico gerado para p Loop Count = 1 Gráfico gerado para p Loop Count = 20

80 Laboratório de Engenharia de Software – PUC-Rio JMeter – Principais Elementos Thread Groups: São o ponto central dos planos de teste. Definem o número de usuários concorrentes, quantas vezes o teste deve ser repetido. Logic Controllers: São os elementos responsáveis pela lógica dos testes: (i) Once Only Controler, agrupa requisições fazendo com que sejam executadas apenas 1 vez; (ii) Simple Controler, apenas agrupa as requisições. Samplers: São os elementos responsáveis pelas requisições a serviços (HTTP, FTP, JDBC). Listeners: São os elementos que geram diversos relatórios de teste. Configuration Elements: São os elementos que armazenam configurações padrão para os Samplers e outros elementos de controle.

81 HttpUnit

82 Laboratório de Engenharia de Software – PUC-Rio HttpUnit O HttpUnit complementa as APIs do JUnit possibilitando o teste funcional de sistemas com interface WEB; O elemento central desta API é a classe WebConversationWebConversation Ela desempenha o papel de um browser, se comunicando com um site; È responsável por manter as informações da sessão (contexto) através de cookies retornados pelo servidor

83 Laboratório de Engenharia de Software – PUC-Rio Trecho de Uma Classe de Testes 1 WebConversation wc = new WebConversation(); 2 WebResponse resp =. wc.getResponse("http://www.httpunit.org/doc/cookbook.html"); 3 WebLink link = resp.getLinkWith( "response" ); 4 link.click(); 5 WebResponse jdoc = wc.getCurrentPage(); 6 WebForm form = resp.getForms()[0]; 7 assertEquals(informatica, form.getParameterValue(area"));

84 Canoo Web Test

85 Laboratório de Engenharia de Software – PUC-Rio Canoo Web Test Ferramenta de teste funcional de aplicações Web Open-Source e desenvolvida em Java Simula as ações do usuário Uso integrado com Ant e HttpUnit

86 Laboratório de Engenharia de Software – PUC-Rio Funcionamento Ant - ferramenta para construção automática de builds HttpUnit – framework que permite a definição de teste de aplicações Web, através de classes Java Canoo Web Test –permite a definição de scripts em XML para a construção de casos de teste sobre páginas HTML –usa a API do HttpUnit para execução dos testes contidos nos scripts –Scripts são processados pelo Ant

87 Laboratório de Engenharia de Software – PUC-Rio Estrutura de Funcionamento Ant Script de Teste em XML executado pelo Canoo Web Test HttpUnit Relatórios de Teste gera usa acessa

88 Laboratório de Engenharia de Software – PUC-Rio Exemplo de Script Ant de Teste... Definição da tarefa de teste para o Ant

89 Laboratório de Engenharia de Software – PUC-Rio Tarefa de Teste taskdef : tag de definição de tarefa para o Ant; Cada tarefa executa em sua própria sessão Web Contém os elementos: – - determina a configuração do teste – - determina os passos de teste....

90 Laboratório de Engenharia de Software – PUC-Rio Exemplo Tarefa de Teste... ... Definição dos passos do caso de teste Configuração do caso de teste

91 Laboratório de Engenharia de Software – PUC-Rio Principais Categorias de Steps invoke: –responsável pela emissão de pedidos HTTP e armazenamento do resultado; verify*: –responsável pela verificação da corretude do resultado do pedido HTTP;

92 Laboratório de Engenharia de Software – PUC-Rio Text: Exemplo – passo de teste... HTML Passos de Teste

93 Laboratório de Engenharia de Software – PUC-Rio Referências [1] Meyer, B., Applying Design by Contract. In IEEE Computer 25 (10), 1992, p [2] Beck, K., Extreme Programming Explained, Addison-Wesley, 2000 [3] Beck, K., Test Driven Development: By Example: Addison Wesley, 2003 [4] Williams, L.; Maximillien, M.; Vouk, M.; Test-Driven Development as a Defect-Reduction Practice, IEEE International Symposium on Software Reliability Engineering (ISSRE), November [5] Donat, M., Debugging in an Asynchronous World, ACM Queue 1(6), September [6] Fewster, M.; Graham, D.; Software Test Automation, Addison-Wesley, [7] Staa, A.v.; Programação Modular; Rio de Janeiro: Campus; 2000

94 Laboratório de Engenharia de Software – PUC-Rio Referências [8] Ant: [9] JUnit:http://www.junit.org [10] Extensões JUnit:http://www.junit.org/news/extension/index.htm [11] Canoo Web Test: [12] JMeter: [13] HTTPUnit:


Carregar ppt "Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho Simpósio de Desenvolvimento e Manutenção de Software."

Apresentações semelhantes


Anúncios Google