Em Busca de Software Correto

Apresentação em tema: "Em Busca de Software Correto"— 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 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. Laboratório de Engenharia de Software – PUC-Rio

3 Agenda Motivação Prevenção e Detecção de Falhas Automação de Testes
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. Automação de Testes resumo das principais ferramentas freeware para automação de testes. Laboratório de Engenharia de Software – PUC-Rio

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

5 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. - Colocar uma transparência listando diversos processos e tecnologias. Laboratório de Engenharia de Software – PUC-Rio

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

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

8 2. Detecção e Prevenção de Falhas
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 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 Laboratório de Engenharia de Software – PUC-Rio

10 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.; Laboratório de Engenharia de Software – PUC-Rio

11 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 Laboratório de Engenharia de Software – PUC-Rio

12 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. entradas - são descritas nas planilhas de teste FOI INTRODUZIDO OS PASSOS ESPECÍFICOS DO TESTE A SER EXECUTADO 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 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 Laboratório de Engenharia de Software – PUC-Rio

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

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

17 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 Laboratório de Engenharia de Software – PUC-Rio

18 2.2 Detecção automatizada

19 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 Laboratório de Engenharia de Software – PUC-Rio

20 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 Laboratório de Engenharia de Software – PUC-Rio

21 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 Laboratório de Engenharia de Software – PUC-Rio

22 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) Laboratório de Engenharia de Software – PUC-Rio

23 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 ... Laboratório de Engenharia de Software – PUC-Rio

24 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 Laboratório de Engenharia de Software – PUC-Rio

25 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 Laboratório de Engenharia de Software – PUC-Rio

26 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 Laboratório de Engenharia de Software – PUC-Rio

27 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 ... Laboratório de Engenharia de Software – PUC-Rio

28 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 Laboratório de Engenharia de Software – PUC-Rio

29 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 ) } else return TST_NotificarFalha( "Nó pertence a árvore vazia." ) ; } /* if */ . . . Laboratório de Engenharia de Software – PUC-Rio

30 3. Automação de Testes

31 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” ENTENDER MELHOR OS TIPOS DE FERRAMENTAS DISPONÍVEIS Laboratório de Engenharia de Software – PUC-Rio

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

33 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? Laboratório de Engenharia de Software – PUC-Rio

34 Processo x Ferramentas de Teste
Necessário colocar desenho com o fluxo “amarelo” da EMPREL Ferramentas de Planejamento e Projeto de Testes Laboratório de Engenharia de Software – PUC-Rio

35 Ferramentas de planejamento e projeto de testes
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) Laboratório de Engenharia de Software – PUC-Rio

36 Ferramentas de planejamento e projeto de testes
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) Laboratório de Engenharia de Software – PUC-Rio

37 Ferramentas de planejamento e projeto de testes
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 Ferramenta de gerência de mudanças (Bugzilla); Ferramenta para manipulação de planilhas (Excel); Laboratório de Engenharia de Software – PUC-Rio

38 Ferramentas de planejamento e projeto de testes
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 Ferramenta de gerência de mudanças (Bugzilla); Laboratório de Engenharia de Software – PUC-Rio

39 Processo x Ferramentas de Teste
Necessário colocar desenho com o fluxo “amarelo” da EMPREL Ferramentas para Implementação de Componentes de Teste Laboratório de Engenharia de Software – PUC-Rio

40 Ferramentas para Implementação dos componentes de testes
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 Laboratório de Engenharia de Software – PUC-Rio

41 Ferramentas para Implementação dos componentes de testes
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) Laboratório de Engenharia de Software – PUC-Rio

42 Ferramentas para Implementação dos componentes de testes
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 Laboratório de Engenharia de Software – PUC-Rio

43 Ferramentas para Implementação dos componentes de testes
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; Laboratório de Engenharia de Software – PUC-Rio

44 Ferramentas de Teste Gratuitas

45 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 Laboratório de Engenharia de Software – PUC-Rio

46 JUnit

47 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 Laboratório de Engenharia de Software – PUC-Rio

48 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 Laboratório de Engenharia de Software – PUC-Rio

49 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 Laboratório de Engenharia de Software – PUC-Rio

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

51 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 Laboratório de Engenharia de Software – PUC-Rio

52 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 Laboratório de Engenharia de Software – PUC-Rio

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

54 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); Laboratório de Engenharia de Software – PUC-Rio

55 Exemplos - métodos do JUnit para teste
Teste de Lançamento de Exceções 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){ } Laboratório de Engenharia de Software – PUC-Rio

56 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. Laboratório de Engenharia de Software – PUC-Rio

57 Exemplos - métodos do JUnit para configuração dos casos de teste
Execução antes de cada método 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); } Laboratório de Engenharia de Software – PUC-Rio

58 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 TestSuite . TestCase Laboratório de Engenharia de Software – PUC-Rio

59 Exemplos – suites de testes
Definindo o suite de testes de apenas uma classe de testes Definição do suite de teste da classe ... 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()); Método main() da classe invoca suite de teste Laboratório de Engenharia de Software – PUC-Rio

60 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()); Laboratório de Engenharia de Software – PUC-Rio

61 JMeter

62 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: Fazer download: 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 inicializar: /bin/jmeter.bat Laboratório de Engenharia de Software – PUC-Rio

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

64 Criando um Plano de Testes
Usaremos uma aplicação exemplo do Tomcat Calendar: ( Vamos simular o acesso concorrente de 10 usuários e gerar relatórios com os resultados; Laboratório de Engenharia de Software – PUC-Rio

65 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. Laboratório de Engenharia de Software – PUC-Rio

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

67 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: Laboratório de Engenharia de Software – PUC-Rio

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

69 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; Laboratório de Engenharia de Software – PUC-Rio

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

71 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) Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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

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

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

79 Graph Results Gráfico gerado para p Loop Count = 20
 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; Laboratório de Engenharia de Software – PUC-Rio

80 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. Laboratório de Engenharia de Software – PUC-Rio

81 HttpUnit

82 HttpUnit O HttpUnit complementa as APIs do JUnit possibilitando o teste funcional de sistemas com interface WEB; O elemento central desta API é a classe WebConversation 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 Laboratório de Engenharia de Software – PUC-Rio

83 Trecho de Uma Classe de Testes
1 WebConversation wc = new WebConversation(); 2 WebResponse resp = wc.getResponse(" 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")); Laboratório de Engenharia de Software – PUC-Rio

84 Canoo Web Test

85 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 Laboratório de Engenharia de Software – PUC-Rio

86 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 Laboratório de Engenharia de Software – PUC-Rio

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

88 Exemplo de Script Ant de Teste
<project name=“CasoTeste1" basedir="." default=“casoTeste1"> <property name="base.dir" value="${basedir}"/> <target name=“casoTeste1"> <testSpec name=“verificacao de titulo de arquivo"> ... </testSpec> </target> <taskdef name="testSpec“ classname="com.canoo.webtest.ant.TestSpecificationTask"> <classpath> <fileset dir=“.“ includes="**/lib/*.jar"/> </classpath > </taskdef> </project> Definição da tarefa de teste para o Ant Laboratório de Engenharia de Software – PUC-Rio

89 Tarefa de Teste taskdef: tag de definição de tarefa para o Ant;
.... <taskdef name="testSpec“ classname="com.canoo.webtest.ant.TestSpecificationTask"> ... </taskdef> taskdef: tag de definição de tarefa para o Ant; Cada tarefa executa em sua própria sessão Web Contém os elementos: <config> - determina a configuração do teste <steps> - determina os passos de teste Laboratório de Engenharia de Software – PUC-Rio

90 Exemplo Tarefa de Teste
... <testSpec name=“Verificacao de titulo de arquivo"> <config host=“localhost“ port=“8080" protocol=“http" basepath="${base.dir}“/> <steps> <invoke stepid=“Pagina Inicial" url= “/examples/jsp/cal/login.html" /> <verifytitle stepid=“Verificando que o titulo está correto“ text=“Login page for the calendar.“ /> </steps> </testSpec> Configuração do caso de teste Definição dos passos do caso de teste Laboratório de Engenharia de Software – PUC-Rio

91 Principais Categorias de Steps
<invoke stepid=“Pagina Inicial" url= “/examples/jsp/cal/login.html" /> <verifytitle stepid=“Verificando que o titulo está correto“ text=“Login page for the calendar.“ /> </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; Laboratório de Engenharia de Software – PUC-Rio

92 Exemplo – passo de teste <clickbutton>
<FORM method=“GET" action=“cal1.jsp">    <BR/>Text:    <INPUT type="text" name=“name" value="" />    <INPUT type="text" name=“ " value="" />    <INPUT type="submit"             value=“Ok" /> </FORM> HTML ... <setinputfield stepid=“Configurar campo do Form"    name=“name"    value=“teste" /> <setinputfield stepid=“Configurar campo do Form"    name=“ "    <clickbutton stepid=“Submeter formulario de teste"    name=“Ok" /> <verifytext stepid=“Verifica se a página contém o texto"          text="Appointment"   /> ... Passos de Teste Laboratório de Engenharia de Software – PUC-Rio

93 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 2003. [5] Donat, M., Debugging in an Asynchronous World, ACM Queue 1(6), September 2003. [6] Fewster, M.; Graham, D.; Software Test Automation, Addison-Wesley, 1999. [7] Staa, A.v.; Programação Modular; Rio de Janeiro: Campus; 2000 Laboratório de Engenharia de Software – PUC-Rio

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