Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho {arndt,roberta}@les.inf.puc-rio.br Simpósio de Desenvolvimento e Manutenção de Software da Marinha (SDMS 2004)

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

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

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

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

Detecção e Prevenção de Falhas

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

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

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

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

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

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

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

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

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

Conceito chave: Processo de testes 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 Laboratório de Engenharia de Software – PUC-Rio

2.2 Detecção automatizada

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

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

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

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

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

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

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

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

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

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

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

3. Automação de Testes

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

Exemplo de arcabouço (framework) 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? Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

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

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

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

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

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

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

Ferramentas de Teste Gratuitas

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

JUnit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JMeter

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: http://jakarta.apache.org/jmeter 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

JMeter – Tela inicial JMeter Cria automaticamente um Plano de Testes – Test Plan 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). Vamos simular o acesso concorrente de 10 usuários e gerar relatórios com os resultados; 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. Laboratório de Engenharia de Software – PUC-Rio

JMeter Primeiro Passo: Inicializar o JMeter: /bin/jmeter.bat 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: http://localhost:8080/examples/jsp/cal/login.html, http://localhost:8080/examples/jsp/cal/cal1.jsp?name=teste&email=testes@com.br&action=Submit http://localhost:8080/examples/jsp/cal/cal2.jsp?time=8am http://localhost:8080/examples/jsp/cal/cal1.jsp Laboratório de Engenharia de Software – PUC-Rio

JMeter Segundo Passo: 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; Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

JMeter Configurar as requisições HTTP - Como? (cont.) Adicionar um HTTP Request: Adiciona Novo Compromisso. 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; Laboratório de Engenharia de Software – PUC-Rio

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

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

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

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

HttpUnit

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

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

Canoo Web Test

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

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

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

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

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

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

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

Exemplo – passo de teste <clickbutton> <FORM method=“GET" action=“cal1.jsp">    <BR/>Text:    <INPUT type="text" name=“name" value="" />    <INPUT type="text" name=“email" 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=“email"    value=“teste@com.br" /> <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

Referências [1] Meyer, B., Applying Design by Contract. In IEEE Computer 25 (10), 1992, p. 40-51. [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

Referências [8] Ant: http://jakarta.apache.org/ant/ [9] JUnit:http://www.junit.org [10] Extensões JUnit:http://www.junit.org/news/extension/index.htm [11] Canoo Web Test: http://webtest.canoo.com/ [12] JMeter: http://jakarta.apache.org/jmeter/ [13] HTTPUnit: http://httpunit.sourceforge.net Laboratório de Engenharia de Software – PUC-Rio