Post on 08-Jul-2020
Aula 04Introdução a Teste Automatizado
Alessandro Garcia
LES/DI/PUC-Rio
Setembro 2013
Ago 2008 2 / 27Arndt von Staa © LES/DI/PUC-Rio
Especificação
• Objetivo dessa aula
– Apresentar os uma técnica para a criação testes automatizados
e mostrar como desenvolver dirigido por testes.
• Slides adaptados de: Staa, A.v. Notas de Aula em
Programacao Modular; 2008.
• Referência básica:
– Monografia: Arcabouço para a Automação de Testes de
Programas Redigidos em C; contido no arquivo
TesteAutomatizado.zip acessível para download através do
site da disciplina, aba: Software
• Referência adicional:
– Beck, K.; Test-Driven Development by Example; Reading,
Massachusetts: Addison-Wesley; 2003
Ago 2008 3 / 27Arndt von Staa © LES/DI/PUC-Rio
Sumário
• Automação simplória
• Arcabouço de apoio ao teste automatizado
• Linguagem de diretivas de teste
• Interpretador de diretivas
• Exemplo de uso do arcabouço
• Arquitetura do arcabouço
• Vantagens e desvantagens
4 / 30 LES/DI/PUC-Rio
Custo e qualidade do Teste
• É uma atividade cara, porém essencial
– 30 – 50% do custo de desenvolvimento
• Causas
– Falta de planejamento
– Tempo escasso
– Falta de metodologia
– Inserção de novos defeitos
– Especificação incompleta
• Seleção de dados
– Dados óbvios, randômicos, viciados
– Casos de teste rigorosamente selecionados
5 / 30 LES/DI/PUC-Rio
Exemplo: criando casos de teste
• Um bom conjunto de casos de teste é aquele que possui alta
probabilidade em revelar defeitos na função ou no módulo
que a contém
int verificaTriangulo (int segmentoAB, int segmentoAC, int segmentoBC);
6 / 30 LES/DI/PUC-Rio
Criando casos de teste com a especificação
A função recebe como entrada três valores inteiros. Cada valor
corresponde ao segmento de um lado do triângulo. Assim, o primeiro valor
corresponde ao segmento do lado AB, o segundo valor ao segmento do
lado AC e o terceiro valor correspondem ao segmento do lado BC. Esses
três segmentos correspondem aos três lados que formam o triângulo ABC.
A função recebe os três valores como entrada e verifica que tipo de
triângulo é formado com base nos três segmentos. Por fim, a função
retorna a quantidade de lados que possuem o mesmo tamanho. Assim, se
o triângulo for equilátero, ou seja, os três lados possuem o mesmo
tamanho, então a função retorna 3. Se o triângulo for isósceles (dois lados
com o mesmo tamanho), então a função retorna 2. Se o triângulo for
escaleno (os três lados possuem tamanhos diferentes), então a função
retorna 0. Caso os três valores não correspondam a um triângulo, a função
retorna o código -1.
int verificaTriangulo (int segmentoAB, int segmentoAC, int segmentoBC);
7 / 30 LES/DI/PUC-Rio
Casos de teste
• Um dos problemas comuns ao testar software e determinar
quando os módulos foram suficientemente testados
• Mesmo usando a especificação, é difícil produzir bons casos de
teste que sejam capazes de revelar a existência de defeitos
• Por exemplo, para o problema do triângulo, é necessário apenas
quatro casos de testes para se testar a função em termos dos três
tipos de triângulo
– 1 caso válido para triângulo equilátero (retorna 3)
– 1 casos válidos para triângulo isósceles (retorna 2)
– 1 caso válido para triângulo escaleno (retorna 0)
– 1 caso válido para valores que não correspondem a um triângulo
(retorno -1)
8 / 30 LES/DI/PUC-Rio
Criando casos de teste com a especificação
int verificaTriangulo(int segAB, int segAC, int segBC){
if ((segAB == segAC) && (segAC == segBC)){
return 3; //equilatero
}
if (((segAB == segAC) && (segAC != segBC)) ||
((segAC == segBC) && (segAB != segAC)) ||
((segAB == segBC) && (segBC != segAB))){
return 2; //isosceles
}
if ( (segAB != segAC) && (segAC != segBC)) {
return 0; //escaleno
}
return -1;
}
9 / 30 LES/DI/PUC-Rio
Criando casos de teste com a especificação
• Qual é a saída para o caso de teste (2, 1, 1)?
• Esses valores não correspondem a um triângulo.
• Para se ter um triângulo, é necessário que ele tenha em cada um
dos seus lados, uma medida menor que a soma das medidas dos
outros dois lados.
AB < AC + BC
AC < AB + BC
BC < AB + AC
–Observação: Se AB for o maior lado, para existir um triângulo,
basta que AB < AC + BC.
10 / 30 LES/DI/PUC-Rio
Função verificaTriangulo
int verificaTriangulo(int segAB, int segAC, int segBC){
if ( (segAB < segAC+ segBC) && (segAC< segAB + segBC) && (segBC< segAB +
segAC)){
if ((segAB == segAC) && (segAC == segBC)){
return 3; //equilatero
}
if (((segAB == segAC) && (segAC != segBC)) ||
((segAC == segBC) && (segAB != segAC)) ||
((segAB == segBC) && (segBC != segAC))){
return 2; //isosceles
}
if ( (segAB != segAC) && (segAC != segBC)) {
return 0; //escaleno
}
}
return -1;
}
11 / 30 LES/DI/PUC-Rio
Completude dos casos de teste
• Um bom conjunto de casos de teste seria aquele que cobrisse os
seguintes casos:
– 1 caso válido para triângulo equilátero (retorna 3)
– 1 caso válido para triângulo escaleno (retorna 0)
– 3 casos válidos para triângulo isósceles (retorna 2)
– 3 casos para testar Lk > Li + Lj (retorna -1)
– 3 casos para testar Lk = Li + Lj (retorna -1)
– 3 casos para testar um dos lados igual a 0 (retorna -1)
– 3 casos para testar um dos lados menor do que 0 (retorna -1)
• Testes somente sao capazes de mostrar a presenc a de
faltas, mas nao a ause ncia delas.
12 / 30 LES/DI/PUC-Rio
O que é um módulo controlador do teste?
deve ser facilmente removível;
instrumentação: discutido em aulas futuras
13 / 30 LES/DI/PUC-Rio
Como testar um módulo?
• Uso de um módulo controlador do teste
desenvolvido que auxilia a execução de casos de
teste para testar um módulo sob teste
• Três formas:
– Teste manual: controlador exibe um menu e
comparação é feita pelo próprio testador à olho nu
– Teste de comparação automatizado:
• Casos de teste são implementados em C
• Casos de teste são redigidos em scripts em uma linguagem
com uma sintaxe própria
Exemplo de Módulo em C
14 /26Alessandro Garcia © LES - DI/PUC-Rio
Discutindo
Estrutura do arquivo ARVORE.h
Estrutura do arquivo ARVORE.c
Mar 2009 15 /32Alessandro Garcia © LES/DI/PUC-Rio
Condições de retorno/***********************************************************************
*$TC Tipo de dados: ARV Condicoes de retorno
************************************************************************/
typedef enum {
ARV_CondRetOK = 0 ,
/* Executou correto */
ARV_CondRetNaoCriouRaiz = 1 ,
/* Não criou nó raiz */
ARV_CondRetErroEstrutura = 2 ,
/* Estrutura da árvore está errada */
ARV_CondRetNaoEhFolha = 3 ,
/* Não é folha relativa à direção de inserção desejada */
ARV_CondRetArvoreNaoExiste = 4 ,
/* Árvore não existe */
ARV_CondRetArvoreVazia = 5 ,
/* Árvore está vazia */
ARV_CondRetNohEhRaiz = 6 ,
/* Nó corrente é raiz */
ARV_CondRetNaoPossuiFilho = 7 ,
/* Nó corrente não possui filho na direção desejada */
ARV_CondRetFaltouMemoria = 8
/* Faltou memória ao alocar dados */
} ARV_tpCondRet ;
Evento normal
Eventos excepcionais
16 / 30 LES/DI/PUC-Rio
Teste Manual
• Controlador exibe um menu e comparação é feita pelo
próprio testador à olho nu
1 Inserir nó à esquerda
2 Inserir nó à direita
3 Ir para nó filho à esquerda
4 Ir para nó filho à direita
5 Obter valor do nó corrente
6 Exibir a árvore em formato parentetizado
99 Terminar
Escolha a opção:
17 / 30 LES/DI/PUC-Rio
Vantagens e desvantagens do teste manual
• Vantagens
– É relativamente simples de programar.
– É mais fácil verificar a corretude caso esta se baseie em valores
aproximados
• evidentemente, isto requer que o testador saiba determinar quais as
aproximações aceitáveis
• Desvantagens
– O usuário não sabe quando testou tudo que deveria ser testado
• teste incompleto pode deixar defeitos remanescentes
– O usuário imagina o resultado esperado
– O usuário realiza testes que repetem condições já testadas
• teste redundante adiciona custo sem contribuir para descobrir novos defeitos
– O usuário corrige imediatamente ao encontrar uma falha
• após eliminar o defeito que provocou a falha, o módulo precisa ser retestado
• correção imediata aumenta o número de retestes
18 / 30 LES/DI/PUC-Rio
Como testar um módulo?
• Uso de um módulo controlador do teste
desenvolvido que auxilia a execução de casos de
teste para testar um módulo sob teste
• Três formas:
– Teste manual: controlador exibe um menu e
comparação é feita pelo próprio testador à olho nu
– Teste de comparação automatizado:
• Casos de teste são implementados em C
• Casos de teste são redigidos em scripts em uma linguagem
com uma sintaxe própria
Ago 2008 19 / 27Arndt von Staa © LES/DI/PUC-Rio
Como reduzir o custo do reteste?
• Automatizar a execução dos testes
– estabelecer a seqüência de comandos de teste em uma espécie
de programa
– obter os dados para os testes de cada comando
– efetuar a operação correspondente ao comando
– comparar o resultado esperado com o obtido
• sem essa comparação jamais teremos um teste
– continuar com o próximo comando
– emitir um relatório da execução do teste (laudo)
Ago 2008 20 / 27Arndt von Staa © LES/DI/PUC-Rio
Exemplo simplório
. . .
ContaCaso ++ ;
if ( CriarArvore( ) != ARV_CondRetOK )
{
printf( "\nErro ao criar árvore" ) ;
ContaFalhas ++ ;
}
ContaCaso ++ ;
if ( InserirEsquerda('a' ) != ARV_CondRetOK )
{
printf( "\nErro ao inserir nó raiz da árvore" ) ;
ContaFalhas ++ ;
}
ContaCaso ++ ;
if ( IrPai( ) != ARV_CondRetEhRaiz )
{
printf( "\nErro ao ir para pai de nó raiz" ) ;
ContaFalhas ++ ;
}
. . .
Ago 2008 21 / 27Arndt von Staa © LES/DI/PUC-Rio
Por que é simplório?
• O código é muito repetitivo
– viola a regra de evitar duplicações de código
• As mensagens impressas não explicitam o porquê da falha
– quais foram os valores que causaram a mensagem?
• Não identifica com precisão o objetivo de cada caso de teste
– o leitor do código precisa inferir o objetivo a partir da leitura
• O módulo controlador do teste pode tornar-se muito
extenso
– dificulta verificar se o teste é um bom teste
• O código não produz um laudo do teste
Ago 2008 22 / 27Arndt von Staa © LES/DI/PUC-Rio
Como reduzir o volume de repetição?
• Criar um arcabouço (framework) com as funções de
comparação.
Framework
Pontos deextensão
Aplicação
Serviço do
arcabouço
Ago 2008 23 / 27Arndt von Staa © LES/DI/PUC-Rio
Exemplo de uma função de comparação
TST_tpCondRet TST_CompararInt( long ValorEsperado ,
long ValorObtido ,
char * pMensagem )
{
if ( ValorObtido != ValorEsperado )
{
ContaFalhas ++ ;
fprintf( pArqLog , "\nErro >>> %s" , pMensagem ) ;
fprintf( pArqLog , "Deveria ser: %ld É: %ld" ,
ValorEsperado , ValorObtido ) ;
return TST_CondRetErro ;
} /* if */
return TST_CondRetOK ;
} /* Fim função: TSTG &Comparar inteiro */
Ago 2008 24 / 27Arndt von Staa © LES/DI/PUC-Rio
Como fica o código agora?
. . .
if ( TST_CompararInt( ARV_CondRetOK , CriarArvore( ) ,
"Erro ao criar árvore" ) != TST_CondRetOK )
{
return ;
}
if ( TST_CompararInt( ARV_CondRetOK , InserirEsquerda('a' ) ,
"Erro ao inserir nó raiz da árvore" ) != TST_CondRetOK )
{
return ;
}
if ( TST_CompararInt( ARV_CondRetEhRaiz , IrPai( ) ,
"Erro ao ir para pai na raiz" ) != TST_CondRetOK )
{
return ;
}
. . .
Ago 2008 25 / 27Arndt von Staa © LES/DI/PUC-Rio
Melhorou?
• Sim, pode-se adicionar mais funcionalidades ao arcabouço
– outros comparadores
– funções de auxílio
– . . .
• Sim, ganhou-se uniformidade
• Não, o código continua extenso
• Não, pára na primeira falha encontrada
Ago 2008 26 / 27Arndt von Staa © LES/DI/PUC-Rio
Nossa solução
• Para quem programa Java, C++, C# e outros, existem
diversos arcabouços: JUnit, CppUnit, CSUnit, ...
• A solução que adotamos é um interpretador inspirado no
JUnit
Ago 2008 27 / 27Arndt von Staa © LES/DI/PUC-Rio
O roteiro de teste pode ser interpretado?
. . .
== Criar árvore
=criar OK
=irdir ArvoreVazia
== Inserir à direita
=insdir CharA OK
== Obter o valor inserido
=obter CharA OK
== Ir para no pai, não tem
=irpai EhRaiz
== Inserir à esquerda
=insesq CharB OK
=obter CharB OK
== Ir para no pai, tem
=irpai OK
=obter CharA OK
. . .
Ago 2008 28 / 27Arndt von Staa © LES/DI/PUC-Rio
O roteiro de teste pode ser interpretado?
• Declaração dos valores simbólicos
– formato
• =declararparm <nome simbólico> <tipo> <valor>
• tipos conhecidos: int , char , double , string , nome
– exemplos
== Declarar as condições de retorno
=declararparm OK int 0
=declararparm NaoArvore int 4
=declararparm ArvoreVazia int 5
== Declarar os valores contidos nos nós
=declararparm CharErro char '!'
=declararparm CharA char 'a'
Ago 2008 29 / 27Arndt von Staa © LES/DI/PUC-Rio
Exemplo de fragmento do interpretador
/* Testar ARV Adicionar filho à direita */
else if ( strcmp( ComandoTeste , INS_DIR_CMD ) == 0 )
{
NumLidos = LER_LerParametros( "ci" ,
&ValorDado , &CondRetEsperada ) ;
if ( NumLidos != 2 )
{
return TST_CondRetParm ;
} /* if */
return TST_CompararInt( CondRetEsperada ,
ARV_InserirDireita( ValorDado ) ,
"Retorno errado inserir àa direita." );
} /* fim: Testar ARV Adicionar filho à direita */
Ago 2008 30 / 27Arndt von Staa © LES/DI/PUC-Rio
Arquitetura simplificada da nossa abordagem
Programaprincipal
Móduloem teste
Teste deitem deinterface
Funçãode controleespecífica
Módulo de controlegenérico
Diretivasde teste
Logdo teste
Módulo deleitura
31 / 30 LES/DI/PUC-Rio
Arquitetura simplificada da nossa abordagem
Programaprincipal
Móduloem teste
Teste deitem deinterface
Funçãode controleespecífica
Módulo de controlegenérico
Diretivasde teste
Logdo teste
Módulo deleitura
LERPARM.h
GENERICO.h
PRINCIP.h
coordena a realização
dos testes; disponibiliza
funções genéricas de
comparação
TST_ESPC.h
interpreta os comandos
genéricos e específicos
*.script
Ago 2008 32 / 27Arndt von Staa © LES/DI/PUC-Rio
Arquitetura completa
Programaprincipal
Móduloem teste
Teste deitem deinterface
Funçãode controleespecífica
Módulo de controlegenérico
Diretivasde teste
Logdo teste
Módulocontador
Interpretadorcontador
Móduloacesso
Interpretadoracesso
Arcabouço de apoioao teste automatizado
Módulo deleitura dasdiretivas
Ago 2008 33 / 27Arndt von Staa © LES/DI/PUC-Rio
Como usar?
• Forma “big bang”
1. Especificar a interface do módulo
• arquivo .h
2. Especificar a linguagem de diretivas de teste, sintaxe
• =<nome da função> <lista parâmetros> <condição retorno>
3. Redigir a massa de teste nesta linguagem
• serve como uma especificação executável!
4. Redigir o módulo de teste específico
5. Redigir o módulo a ser testado
6. Rever cuidadosamente os cinco artefatos
7. Compilar
• usar a biblioteca: ArcaboucoTeste.lib
8. Executar o teste
9. Corrigir até zero falhas observadas pelo teste
Ago 2008 34 / 27Arndt von Staa © LES/DI/PUC-Rio
Como usar?
• Forma iterativa
– preparação inicial
1. Especificar parcialmente a interface do módulo a desenvolver
2. Especificar a linguagem de diretivas de teste
3. Redigir parte da massa de teste nesta linguagem
4. Redigir a versão inicial do módulo de teste específico
– todos os comandos retornam TST_CondRetNaoImplementado
5. Redigir o enchimento (stub) do módulo a ser testado
– todas as funções fazem nada, se necessário retornam um valor neutro
6. Rever cuidadosamente os cinco artefatos
7. Compilar
– usar a biblioteca: ArcaboucoTeste.lib
8. Executar o teste
9. Corrigir até que sejam gerados somente erros de comando não
implementado
Ago 2008 35 / 27Arndt von Staa © LES/DI/PUC-Rio
Como usar?
• Forma iterativa
– iteração
1. Escolher as funções a serem implementadas
2. Rever ou completar a interface do módulo
3. Rever a linguagem de diretivas de teste
4. Redigir a massa de teste nesta linguagem
5. Redigir a parte do módulo de teste específico visando as funções
6. Redigir as funções do módulo a ser testado
7. Rever cuidadosamente os cinco artefatos
8. Compilar
– usar a biblioteca: ArcaboucoTeste.lib
9. Executar o teste
10.Corrigir até que
– esteja tudo correto
– sejam gerados somente erros de comando não implementado
Instalando arcabouço
• Criar uma pasta (ex: arcaboucoLegal)
• Descompactar o Arquivo de instalação da versão 2.02 na
pasta criada
• Copiar para a raiz da pasta (arcaboucolegal) o bat vsvars32
– C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\vsvars32
• Executar o vsvars32
• Executar bats, scripts, testes, ...
Ago 2008 36 / 27Arndt von Staa © LES/DI/PUC-Rio
Visual Studio
• Visual Studio 2008 – Editor - Demonstração
– Criar Projeto > Aplicação de Console – Win32
– Importar Arquivos
• ArcabouçoTeste.lib
• CESPDIN.H
• CONTA.H
• GENERICO.H
• LERPARM.H
• TST_ESPC.H
• MODULO - .H, .C e TST.C
– Build da Aplicação
– \debug\.exe
• GMake – Compilação via prompt (sugestão)
Ago 2008 37 / 29Arndt von Staa © LES/DI/PUC-Rio
Ago 2008 38 / 27Arndt von Staa © LES/DI/PUC-Rio
Exemplo prático
• Exemplo \arcabouc\simples
• Adicionando nova funçõa
– adicionar prototipo de função no ARVORE.h
– adicionar definição da função no ARVORE.c
– no TestArv.C
• declarar constante de teste a ser chamada no script
• adicionar tratamento de comando no bloco
– no script
• adicionar constantes
• adicionar comando
• adicionar parâmetros e retorno esperado
Ago 2008 39 / 27Arndt von Staa © LES/DI/PUC-Rio
Quais seriam as vantagens?
• Teste automatizado exige rigor ao escrever
– as especificações das interfaces
– o script de teste
– embora alguns não acreditem, rigor é sempre vantagem!
• Facilita o desenvolvimento incremental do módulo
– a cada incremento pode-se retestar integralmente o que já foi
feito (teste de regressão)
• o que não foi alterado ou acrescido deveria continuar operando tal
como esperado
• o que foi alterado e acrescido tem o teste ajustado
• A função de teste específico serve como exemplo de uso do
módulo
Ago 2008 40 / 27Arndt von Staa © LES/DI/PUC-Rio
Quais seriam as vantagens?
• O script de teste serve como especificação executável do
módulo
– apesar de ser uma especificação incompleta e baseada em
exemplos, freqüentemente é mais precisa do que
especificações textuais
• Os problemas encontrados são repetíveis, facilitando a
depuração
– reduz significativamente o esforço de teste quando se leva em
conta a necessidade de reteste após corrigir ou evoluir o
módulo
• Caso a realização do teste gere um arquivo de log
– documenta os laudos dos testes realizados
– assegura a existência da história da evolução durante o teste.
– passa a ser um atestado da qualidade do módulo
Ago 2008 41 / 27Arndt von Staa © LES/DI/PUC-Rio
Quais seriam as vantagens?
• O esforço de redação do módulo de teste específico é pouco
maior do que o esforço de redação de um controlador de
teste manual.
• Através da linguagem de diretivas de teste pode-se realizar
testes tão complexos e detalhados quanto se queira.
– casos de teste selecionados segundo critérios de seleção bem
definidos
– redigir as diretivas de teste requer monos esforço do que
redigir um controlador de teste contendo o roteiro
• Permite documentar os casos de teste
– os títulos ( “==” ) informam a intenção do caso de teste
– necessário para que outros possam mantê-los
Ago 2008 42 / 27Arndt von Staa © LES/DI/PUC-Rio
Quais seriam as vantagens?
• Reduz o estresse do desenvolvedor
– é possível particionar o desenvolvimento em etapas –
desenvolvimento incremental
– cada qual culminando com um módulo parcial porém
corretamente implementado
Ago 2008 43 / 27Arndt von Staa © LES/DI/PUC-Rio
E quais seriam as desvantagens?
• O arquivo de diretivas é na realidade um programa
– pode conter defeitos
– se não tomar cuidado, a linguagem e/ou o script de teste
tornam-se extensos e complicados
• Ao encontrar uma falha é necessário determinar se é
– defeito no módulo em teste
– defeito no módulo de teste específico
– defeito no script de teste
– defeito na especificação do módulo
Ago 2008 44 / 27Arndt von Staa © LES/DI/PUC-Rio
E quais seriam as desvantagens?
• Custo inicial maior
– ganha-se ao retestar, ou seja, sempre
• Ao alterar um módulo, obriga a evoluir coevolução
– obviamente o módulo sob teste
– o módulo de teste específico
– o script de teste, isso pode tornar-se um problema
• se os casos de teste forem mal documentados
• se o script de teste for mal organizado
• se o script de teste não utilizar parâmetros simbólicos
• Nem sempre é possível utilizar teste automatizado
– exibição (rendering) de figuras, gráficos
– interfaces com os sistemas GUI (ex. windows)
– leiaute de janelas
– . . .
45 / 30 LES/DI/PUC-Rio
O Trabalho: Testando a Lista (diretório Lista)
Programaprincipal
Móduloem teste
Teste deitem deinterface
Funçãode controleespecífica
Módulo de controlegenérico
Diretivasde teste
Logdo teste
Módulo deleitura
LERPARM.h
GENERICO.h
PRINCIP.h
TST_ESPC.h
LISTA.c
LISTA.h
TESTELIS.c
fixo
TESTELISTA.script
46 / 30 LES/DI/PUC-Rio
O Trabalho: Testando a Lista (diretório Lista)
Programaprincipal
Móduloem teste
Teste deitem deinterface
Funçãode controleespecífica
Módulo de controlegenérico
Diretivasde teste
Logdo teste
Módulo deleitura
LERPARM.h
GENERICO.h
PRINCIP.h
TST_ESPC.h
LISTA.c
LISTA.h
TESTELIS.c
TESTELISTA.script
Modificações
não esqueçam de satisfazer
os princípios de modularidade
47 / 30 LES/DI/PUC-Rio
PARA CASA: exemplos práticos de uso do arcabouço
• Teste manual:
– Exemplo \arcabouc\manual: mostrado como construir um
módulo e o respectivo controlador de teste manual
• Teste automatizado:
– Exemplo \arcabouc\simples: mostrado como construir um
módulo e o respectivo módulo de teste específico utilizando a
biblioteca do arcabouço de teste
• Comparar o módulo de teste específico com o controlador
de teste manual
– os exemplos tratam de um módulo editor de árvores binárias
• Teste automatizado da Lista (Trabalho)
– Exemplo \arcabouc\simples
48 / 30 LES/DI/PUC-Rio
Dicas para o Trabalho
• Já instalou, compilou e executou o arcabouço de testes?
– Seção 2 da monografia dá todos os passos de instalação
– A biblioteca do arcabouço precisa ser compatível com a versão
da plataforma de desenvolvimento utilizada
• portanto, antes de utilizá-la, ela precisa ser recompilada
• “Recomenda-se fortemente...” = leia-se “DEVE LER”
• É parte da tarefa, mesmo antes da aula de teste
automatizado, conforme descrito no enunciado:
– ler a monografia “AutoTest...”
– ler o arquivo “...readme” para verificar como instalar
– ler a documentação do GMake
• útil para gerar scripts de compilação e ligação
• arquivos .comp devem ser re-executados na sua máquina
– começar a utilizar os exemplos e arcabouço de testes...
49 / 30 LES/DI/PUC-Rio
Dicas para o Trabalho
• Executar o exemplo TesteLista em linha de comando (CMD)
1. Regere a biblioteca do arcabouço: ArcaboucoTeste.lib
– Vide “Leia.me”
2. Recompilar os arquivos do exemplo: lista\CompilaTudo.bat
3. Executando lista\TesteLista.exe, detalhes são dados
– Não clique duas vezes sobre tal programa, não é uma aplicação
windows e deve ser executa no console!
4. Executando lista\TesteLista.exe /sTesteLista.script
• Quem está sem grupo?
50 / 30 LES/DI/PUC-Rio
Dicas para o Trabalho
• Não esqueça de rever cuidadosamente:
– critérios de avaliação
– procedimentos para entrega do trabalho
• Certifique-se que seu trabalho atende os seguintes pontos:
– estruturação: contém tanto o fonte dos módulos de
implementação quanto módulos definição (interface)
• siga princípios de modularidade: interfaces simples e documentadas,
alta coesão, baixo acoplamento, ...
– obediência a padrões de programação
– execução do código não apresenta falhas
– testes rodam e, idealmente, cobrem condições anormais de uso
– Arquivos LEIAME.TXT e RELATOR.TXT
Trabalho - Dúvidas
• É para fazer o teste de novas funções pelo script?
– SIM
• Será necessário modificar o arquivo TESTLIS.c para que eu
possa realizar o teste da minha implementação do módulo
Lista?
– SIM, pois certamente haverão modificações na interface do
Módulo Lista...
– ... Logo, deve-se modificar o módulo de teste
51 / 30 LES/DI/PUC-Rio
Jun 2009 52 / 35LES/DI/PUC-Rio
Qual o nível de rigor dos testes?
0 iterações
1 iteração
2 iterações
Árvore inexistente
Árvore vazia
Modelo de árvore binária ancorada
pEsq pDirValor
pRaiz pCorrenteEstas configurações devem
ser usadas para testar a inserção,
exclusão, manipulação...
53 / 30 LES/DI/PUC-Rio
Não esquecer...
• Preencher tabela de atividades ao longo do processo.
• NÃO DEIXE PARA ÚLTIMA HORA, POIS VOCÊ NÃO SE
LEMBRARÁ DO QUE FEZ TAL DIA, TAL HORA.
• Com relatórios similares a esse você aprende a planejar o
seu trabalho.
• O relatório é INDIVIDUAL
Ago 2008 54 / 27Arndt von Staa © LES/DI/PUC-Rio
Fim