Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho...

Em Busca de Software Correto

Arndt von StaaRoberta de Souza Coelho{arndt,roberta}@les.inf.puc-rio.br

Simpósio de Desenvolvimento e Manutenção de Software da Marinha (SDMS 2004)

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.


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.


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!!


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.

Detecção e Prevenção de Falhas

2.1 Detecção de Falhas por Intermédio

de Testes

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


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


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


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


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.


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


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


Conceito chave: Processo de testes


Conceito chave: Processo de testes

EspecificaçãoR equisitos de qualidade

Solic itação dealteração

Produzirarte fa to

instrum entado

Selecionarcritérios

C orrig irarte fa to

P roduzircasos de teste

D iagnosticarfa lhas

R eduzirinstrum en-

tação

C orrig ircasos de teste

E fetuarteste

Falha doscasos de teste

Falha daespecificação

OK final

OKintermediário

Falha doartefato

fluxo de laudos

fluxo do processo

fluxo de in form ação

Artefa toace ito

M assas de testeace itas

Arm adura de teste ace ita

Especificaçãoaceita

Solic itação dealteração

Laudosfina is


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

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


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


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


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)


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


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


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


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


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

• ...


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


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 */ . . .

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”


Exemplo de arcabouço (framework)

M óduloa testar

M óduloa testar

A rtefatos aceitos

Contro legenérico

Contro leespecíficoInstrum entação


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?



Ferramentas de Planejamento e Projeto de Testes

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)

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)



• 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);



• 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 para Implementação de Componentes de

Teste

Ferramentas para Implementação de Componentes de

Teste


• 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


• 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)



• 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



• 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 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


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


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


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

TestCase

assertEquals()assertNotNull()assertNull()fail()setUp()tearDown()run()

ContaTest


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


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


Exemplo - classe de teste


...

public void testCreditar(){

Conta conta22_Saldo70 = new Conta(22, 70.0);


conta22_Saldo30.creditar(40.0);

this.assertEquals(conta22_Saldo30

conta22_Saldo70);

}

}

Declaração do método

Definição do método


Métodos de Teste

• assertEquals (valorEsperado, valorTestado);• assertTrue (expressaoBooleana);• assertNull(objeto);• assertNotNull(objeto);• assertSame(objeto1, objeto2);• fail (mensagem);


Exemplos - métodos do JUnit para teste


...

public void testDebitar(){



try {

conta22_Saldo70.debitar(40.0);

} catch(SaldoInsuficienteException saldo){

fail("Operacao de Debito falhou");

}

this.assertEquals(conta22_Saldo30, conta22_Saldo70);

}

}


Exemplos - métodos do JUnit para teste


...

public void testDebitoNegativo(){


try {

conta22_Saldo70.debitar(73.0);

fail("Deveria lançar SaldoInsuficienteException");

} catch(SaldoInsuficienteException saldo){

}

}

}

Teste de Lançamento de Exceções


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.


Exemplos - métodos do JUnit para configuração dos casos de teste


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


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

.

.

.


Exemplos – suites de testes

• Definindo o suite de testes de apenas uma classe de testes

...


...

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


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());

}

...

}

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:1. Fazer download: http://jakarta.apache.org/jmeter2. 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


JMeter – Tela inicial

• JMeter Cria automaticamente um Plano de Testes – Test Plan


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;


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.


JMeter

• Primeiro Passo: – Inicializar o JMeter: /bin/jmeter.bat


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&[email protected]&action=Submit3. http://localhost:8080/examples/jsp/cal/cal2.jsp?time=8am4. http://localhost:8080/examples/jsp/cal/cal1.jsp


JMeter

• Segundo Passo:


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;


JMeter

Permite agendar um horário para início e

fim dos testes


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)


JMeter

• Configurar as requisições HTTP - Como? (cont.)– Adicionar o HTTP Request: Página inicial.


JMeter

• Configurar as requisições HTTP - Como? (cont.)– Adicionar o HTTP Request: submissão do dos dados de

Login.


JMeter

• Configurar as requisições HTTP - Como? (cont.)– Adicionar um HTTP Request: Novo Compromisso


JMeter

• Configurar as requisições HTTP - Como? (cont.)– Adicionar um HTTP Request: Adiciona Novo

Compromisso.


JMeter

• Quarto e Último Passo:– Definir a forma de apresentação dos resultados

• Como?– Adicionando os Listeners ao plano de testes;


Agregate Report


View Results Tree


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


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.

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


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"));

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


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


Estrutura de Funcionamento

Ant

Script de Teste em XML

executado pelo

Canoo Web Test

HttpUnit

Relatórios de Teste

gerausa

usa

acessa


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


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:

– <config> - determina a configuração do teste– <steps> - determina os passos de teste

....

<taskdef name="testSpec“

classname="com.canoo.webtest.ant.TestSpecificationTask">

...

</taskdef>

....


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>

...

Definição dos passos do caso

de teste

Configuração do caso de teste


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;

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


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

Exemplo – passo de teste <clickbutton>

...<setinputfield stepid=“Configurar campo do Form" name=“name" value=“teste" /><setinputfield stepid=“Configurar campo do Form" name=“email" value=“[email protected]" />

<clickbutton stepid=“Submeter formulario de teste" name=“Ok" /> <verifytext stepid=“Verifica se a página contém o texto" text="Appointment" /> ...

HTML

Passos de Teste


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


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

Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho...

Documents

Transcript of Em Busca de Software Correto Arndt von Staa Roberta de Souza Coelho...