em busca de software correto arndt von staa roberta de souza coelho...
TRANSCRIPT
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.
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.
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!!
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.
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
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
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.
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
Conceito chave: Processo de testes
Laboratório de Engenharia de Software – PUC-Rio
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
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
2.2 Detecção automatizada
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
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 ) return TST_CondRetErro ; } else { return TST_NotificarFalha( "Nó pertence a árvore vazia." ) ; } /* if */ . . .
3. Automação de Testes
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”
Laboratório de Engenharia de Software – PUC-Rio
Exemplo de arcabouço (framework)
M óduloa testar
M óduloa testar
A rtefatos aceitos
Contro legenérico
Contro leespecíficoInstrum entação
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
Ferramentas de Planejamento e Projeto de Testes
Ferramentas de Planejamento e Projeto de Testes
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
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
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
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
Laboratório de Engenharia de Software – PUC-Rio
Processo x Ferramentas de Teste
Ferramentas para Implementação de Componentes de
Teste
Ferramentas para Implementação de Componentes de
Teste
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
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
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
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
Ferramentas de Teste Gratuitas
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
JUnit
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
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
TestCase
assertEquals()assertNotNull()assertNull()fail()setUp()tearDown()run()
ContaTest
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
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
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
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
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
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
...
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
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());
}
...
}
JMeter
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: 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
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: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
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
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
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
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.
HttpUnit
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 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"));
Canoo Web Test
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
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
Ant
Script de Teste em XML
executado pelo
Canoo Web Test
HttpUnit
Relatórios de Teste
gerausa
usa
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; • 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>
....
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>
...
Definição dos passos do caso
de teste
Configuração do caso de teste
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;
<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>
Laboratório de Engenharia de Software – PUC-Rio
<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
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