QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes.

QST112

06/2001

IC-UNICAMP Eliane Martins

INF321

Fases de Testes

QST112

06/2001


Tópicos

• Testes de unidades• Noção de driver e stubs

• Testes de integração• Estratégias• Ordem de integração

• Testes de sistemas• Requisitos de qualidade

• Testes de aceitação• Testes de regressão

QST112

06/2001


Testes no Processo de Desenvolvimento

QST112

06/2001


Testes de Unidades e de Integração

Testes de unidade

Código do componente

Espec. do componente

Testes de unidade



Testes de integração

Especificação daarquitetura

componente testado

componente testado

subsistemasintegrados.

.

.

QST112

06/2001


Testes de Unidades

• Visam exercitar detalhadamente uma unidade do sistema.

• Uma unidade é uma entidade executável independente.– Pode representar:

• Uma função.• Uma classe ou um tipo abstrato de dados.• Um grupo pequeno de classes.• Um componente.• Um framework.• Um serviço

QST112

06/2001


Modelos de falhas

• Os Testes de Unidade visam revelar a presença de falhas em:– interfaces: parâmetros de entrada e saída– estruturas de dados: integridade dos dados

armazenados– condições de limite: a unidade opera adequadamente

nos limites estabelecidos?– tratamento de erros: a descrição do erro é

inteligível? A descrição corresponde ao erro encontrado? O tratamento de exceção é adequado?

QST112

06/2001


Componentes de teste

• Driver– Programa ou classe que aplica os casos de teste ao

componente em teste Faz o papel de cliente do componente em teste (CeT).

• Stub– Implementação temporária, mínima, de um componente

usado pelo CeT, com o objetivo de melhorar a controlabilidade e observabilidade do CeT durante os testes.

Faz o papel de servidor do CeT.

• Ambiente de teste (Test Harness)– Sistema que compreende os drivers, stubs, CeT e outras

ferramentas de apoio aos testes.

QST112

06/2001


A unidade e suas colaborações

Cliente

Unidadeem

Teste

Servidor 1 Servidor 2 Servidor 3

QST112

06/2001


A unidade e os componentes de teste

Casos de teste

Driver

Unidadeem

Teste

Stub 1 Stub 2

resultados

Stub 3

QST112

06/2001


Exemplo – componente em teste

Tabela

CriarTabela( )LerItem( )InserirItem( )RemoverItem( )MostrarTabela( )

QST112

06/2001


Exemplo - Driver

type TabInt = array [ 1 .. N, 1 .. M ] of integer;

...

var Tabela: TabInt,

x: integer;

...

criaTab ;

leItem ( x );

insereItem (x );

mostraTab ;

....

Tabela

CriarTabela( )LerItem( )InserirItem( )RemoverItem( )MostrarTabela( )

Driver

QST112

06/2001


Exemplo Driver OO

CasoTeste001

CasoTeste002

CasoTeste003

...

CeT

• Contém instâncias dos casos de teste;• Contém instância da classe em teste (CeT);• Pode herdar de uma classe abstrata

CasoTeste

Driver

QST112

06/2001


Exemplo - Fitnessepackage fixtures;

import br.unicamp.ic.inf321.funcoes.Operacao;import fit.ColumnFixture;

public class StringFeatures extends ColumnFixture {public String entrada;public String outraEntrada;

public boolean confirmaPalindromo() {return Operacao.isPalindrome(entrada);

}

public boolean comecaComDigitoOuMaiuscula() {boolean result;result = Operacao.startsWithDigitOrUpper(entrada);return result;

}

public String eliminaLixo() {return Operacao.stripGarbage(outraEntrada);

}

}

!2 Casos de teste para função "Palindromo"

| -!fixtures.Palindromo!- || entrada | isPalindrome() || bruno | | false || arara | | true || ana anana ana | | true || null | | false || Ã© | | false || omo ada "oro" ada omo | |true |

QST112

06/2001


Exemplo: stub

Tabela

Stub

type VetorInt = array [1 .. N] of integer;

...procedure Ordena_Vetor (a :

VetorInt);...begin write (“Valores fornecidos”);

for i := 1 to N do write (a [ i ] );write (“Forneça os valores ordenados”);for i := 1 to N do read (a [ i ] );

end;

QST112

06/2001


Fases da execução de um caso de teste

• Preparação (set up):– Cria o que for necessário, configurando os stubs de acordo

para que o caso de teste execute conforme o esperado.

• Execução:– Interage com o CeT, aplicando os testes gerados e

observando os resultados obtidos.

• Verificação:– Compara os resultados obtidos com os esperados.

• Término (clean up ou tear down):– Termina a execução do CeT e deixa o ambiente de execução

de testes no mesmo estado em que estava antes da realização do caso de teste.

QST112

06/2001


Estrutura de testes (xUnit)

Prepara (set up)ExecutaVerificaTermina(clean up)

CeT

Servi-dores

Stubs(ou mocks)

cria

configura

instala

caso de teste

QST112

06/2001


Mock Objects

• Criados pela comunidade XP (em 2000)

– Tim Mackinnon, Steve Freeman, Philip Craig. “Endo-Testing:

Unit Testing with Mock Objects”

(www.cs.ualberta.ca/~hoover/cmput401/XP-Notes/xp-conf/Paper

s/4_4_MacKinnon.pdf), apresentada no evento XP2000.

(disponível emt www.mockobjects.com).• Objetivo:

– Sistematizar a geração de stubs– Desenvolver uma infra-estrutura para criação de

mocks e incorporação dos mesmos aos Testes de Unidade.

QST112

06/2001


Bibliotecas

• Mock Objects (ou mocks) servem para emular ou instrumentar o contexto (serviços requeridos) de objetos da CeT.

• Devem ser simples de implementar e não duplicar a implementação do código real.

• Bibliotecas de mocks podem ser usadas para criar stubs: existem várias APIs para esse fim:– MockObjects (www.mockobjects.com)– EasyMock (www.easymock.com)– MockMaker (www.mockmaker.org )– djUnit (http://works.dgic.co.jp/djunit/)– ...

QST112

06/2001


Mocks x stubs

• Mocks são voltados para testes classes. Stubs, em princípio, podem ser usados em qqr linguagem (OO ou não).

• Segundo Martin Fowler, mocks e stubs não são sinônimos:– Mocks podem servir para colocar o objeto da CeT no estado

desejado para os testes.– Um stub é uma implementação alternativa da interface do objeto

substituído.– Um stub é mais passivo, geralmente retornando dados pré-

estabelecidos pelos casos de teste para a CeT. – Mocks podem verificar se o servidor foi chamado adequadamente

contêm verificação embutida (assertivas)

QST112

06/2001


Exemplo: classe em teste e uma servidora

classe ClasseEmTeste Servidora serv; metodo( ) // chama servidora serv.executa( ) endend

classe Servidora executa( ) # código complexoend

http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs

QST112

06/2001


Exemplo de stub: pseudo-código

classe ClasseDeTeste implementa Test::Unit::TestCase classe ServidoraStub executa( ) retorna X endend// exemplo_uso_Stub ServidoraStub servidora classeTeste = ClasseEmTeste.new(servidora) assert_equal X, classeTeste.metodoendend


QST112

06/2001


Exemplo de mock: pseudo-código


classe ClasseDeTeste implementa Test::Unit::TestCase classe ServidoraMock atributo: call_count ...

call_count = 0 // métodos execute( )

call_count +=1 // conta nº de chamadas ao método end get_call_count ( ) ... end // exemplo_uso_Mock servidora = ServidoraMock.new classeTeste = ClasseEmTeste.new(servidora) // verifica nº de chamadas ao método servidor assert_equal 1, servidora.get_call_count endend

QST112

06/2001


Outro exemplo : o mock

// Usado no teste do método: canUserLogin( User, String ) , para substituir// o método validatePassword, chamado pelo método em teste.public class MockUser implements User { ... // Prepara o que retornar quando validatePassword for chamado public void setValidatePasswordResult( boolean result ) { expectedCalls++; this.returnResult = result; }

// Implementação do mock de validatePasswordpublic boolean validatePassword( String password ) { actualCalls++; return returnResult; }

public boolean verify() { return expectedCalls == actualCalls; } ... }

Interface da classe substituída

Determina nº esperado de chamadas ao método substituído

Conta chamadas ao método substituído

Verifica se chamadas de acordo com o esperado

QST112

06/2001


Uso do mock: o caso de teste

// Caso de teste usando o MockUser criado anteriormentepublic void testCanUserLogin() { MockUser user = new MockUser(); user.setValidatePasswordResult( true );

// usa objeto em teste já criado: ot boolean result = ot.canUserLogin( user, "foobar" );

assertTrue("Expected to validate user " + "password \"foobar\"", result );

assertTrue("MockUser not used as expected", user.verify());

}

preparação

execução

verificação

QST112

06/2001


Testes de unidade e de integração

Testes de unidade



Testes de unidade




Especificação daarquitetura

componente testado

componente testado

subsistemasintegrados.

.

.

QST112

06/2001



• Integram unidades já testadas

• Objetivo: exercitar interações entre unidades

QST112

06/2001


Modelo de falhas de integração

• Falhas de interpretação: ocorrem quando a funcionalidade implementada por uma unidade difere do que é esperado.

– B implementa incorretamente um serviço requerido por A.– B não implementa um serviço requerido por A.– B implementa um serviço não requerido por A e que interfere com seu

funcionamento.

• Falhas devido a chamadas incorretas:– B é chamado por A quando não deveria (chamada extra).– B é chamado em momento da execução indevido (chamada incorreta).– B não é chamado por A quando deveria (chamada ausente).

• Falhas de interface: ocorrem quando o padrão de interação (protocolo) entre duas unidades é violado.

– violação da integridade de arquivos e estruturas de dados globais– tratamento de erros (exceções) incorreto– problema de configuração / versões– falta de recursos para atender a demanda das unidades– objeto incorreto é associado a mensagem (polimorfismo)

[Leung e White; Binder99]

QST112

06/2001


Abordagens de integração

• Não incremental (“big-bang”):– todas as unidades são integradas de uma só vez esforço de preparação menor esforço para diagnóstico e correção de falhas é maior

• Incremental– As unidades são integradas gradualmente– Existem inúmeras estratégias

• Descendente (“top-down”)• Ascendente (“bottom-up”)• Por colaboração• Mista• Por camadas• ...

QST112

06/2001


Abordagem incremental

A

B

T1T2T3

A

B

T1T2T3T4

C

A

BT1

T2

T3

T4

T5C

D

QST112

06/2001


Integração descendente (“top-down”)

• Começa com a unidade principal e vai aos poucos integrando as unidades subordinadas

• Em OO: classes de controle primeiro• Utiliza stubs em lugar das unidades subordinadas

QST112

06/2001


Integração ascendente (“bottom-up”)• Começa a integração pelas unidades subordinadas• Em OO: começar pelas classes independentes ou

que usam poucas servidoras • Utiliza drivers em lugar das unidades de controle• As unidades de mais baixo nível são testadas

primeiro e mais vezes

QST112

06/2001


Integração sanduíche

• Combina estratégia ascendente e descendente• O sistema pode ser visto como uma arquitetura com 3

camadas:– Camada-alvo, no meio– Camada superior, acima da camada alvo– Camada inferior, abaixo da camada alvo

• Os testes convergem para a camada-alvo• Como escolher a camada-alvo?

– Objetivo: reduzir nº de stubs e drivers

QST112

06/2001


Ordem de integração

• Ao integrar vários componentes, é importante determinar a ordem para integrá-los

• Componentes podem depender de outros por várias razões:– Classes dependem de outras de diferentes formas:

Composição e agregação, herança, uso de métodos ou atributos definidos em outras classes

– Chamadas a interfaces (API)

• Dependência necessidade de stubs Análise de dependências:

Objetivo: determinar uma ordem de integração que reduza o número de stubs

QST112

06/2001


Exemplo: Diagrama de Classes

Cliente

ServiçoFinanceiro Transação

Taxas

Dinheiro

Conta

Possui

Possui 1 ..*

0 ..*

Realizado através de 0 ..*

Aplicada a

2 ..*

Usa

Contém

Usa

1 ..1

[inspirado em Binder00, 13.1.3]

QST112

06/2001


Exemplo de dependência: X usa Y

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

[inspirado em Binder00, 13.1.3]

Array [Int]

usa

Classe de implementação

Não é usada por nenhuma outra classe

Não usa nenhuma outra classe

Por onde começar a integração para reduzir o número de stubs?

Por onde começar a integração para reduzir o número de drivers?

QST112

06/2001


Determinação da ordem de testes (1)

• Existem várias propostas com base no grafo de dependências:– Caso não existam ciclos:

• Integração ascendente: para reduzir nº de stubs, começar pelos componentes que não dependem de outros

• Integração descendente: para reduzir o nº de drivers, começar pelo componente do qual nenhum outro depende

QST112

06/2001


Exemplo – Integração Ascendente

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

Array [Int]

TestaDinheiro

TestaTaxas

TestaConta +Dinheiro

TestaTransação+Conta+

Dinheiro+Taxas

TestaCliente+ Conta+

Dinheiro Testa

ServiçoFinanc. +Transação +

Conta +Dinheiro +

Taxas

QST112

06/2001


Exemplo – Integração Sanduíche

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

Array [Int]

TestaDinheiro

TestaTaxas

TestaConta +Dinheiro

TestaTransação+Conta+

Dinheiro+Taxas

TestaCliente+ Conta+

Dinheiro

TestaServiçoFinanc. +

Transação +Conta +

Dinheiro +Taxas

Camada alvo

TestaServiçoFinac.

QST112

06/2001


Determinação da ordem de testes (2)

• Existem várias propostas com base no grafo de dependências:– Caso existam ciclos componentes fortemente

acoplados• Uma opção: refatore sua arquitetura, para evitar os ciclos, ou• “Quebre” os ciclos:

– As propostas variam de acordo com a forma de quebrar os ciclos

– Ex.: em OO remover uma associação (herança e agregação não são “quebráveis”)

Quebra da dependência construção de stubs

QST112

06/2001


Exemplo – quebra de ciclos

A

B C

D TestaD

TestaB+D

TestaC+D

TestaA+B+C+D

StubC

Integração ascendente:

QST112

06/2001


Análise de dependências

• Existem ferramentas, como por exemplo:– Class Dependency Analyzer (CDA)

• http://www.dependency-analyzer.org/

– Jdepend• http://clarkware.com/software/JDepend.html

– Metrics• http://metrics.sourceforge.net/

– ...

QST112

06/2001


Testes de Sistemas

Testes deSistemas

(funcionais)

Especificação deRequisitos Funcionais

funcionalidades testadas

subsistemasintegrados

Manual doUsuário

Testes deSistemas

(qualidade)

Especificação deRequisitos de Qualid.

Testes deAceitação

Requisitosdo usuário

sistema testado

sistema aceito

QST112

06/2001


Fontes de informação para os testes

• Especificação de requisitos.• Protótipo, layouts ou modelos da IU.• Políticas da organização

implementadas como objetos de negócio, “stored procedures” ou “triggers”.

• Características do produto descritas na literatura.

• Características e procedimentos descritos na documentação, telas de ajuda ou assistentes de operação (“wizards”).

• Manual do usuário.• Padrões.

Especificação deve ser:• completa• consistente• precisa testável

QST112

06/2001


Testes dos requisitos funcionais

• Visam verificar se as funcionalidades especificadas foram devidamente implementadas

• Uso de métodos de testes caixa-preta :

– partição de equivalência– valores-limite– tabela de decisão / grafo causa-efeito– modelos de estado– diagramas de casos de uso– cenários– ...

QST112

06/2001


Testes dos requisitos de qualidade

• Visam determinar se a implementação do sistema satisfaz aos requisitos de qualidade (não funcionais)

• Tipos de testes:– configuração e compatibilidade– desempenho– estresse– tolerância a falhas– segurança– ...

QST112

06/2001


Testes de desempenho

• Visam determinar se implementação satisfaz aos requisitos de desempenho especificados:– configuração de rede– tempo de CPU– limitação de memória– carga do sistema– taxa de chegada de entradas esses requisitos devem ser descritos de forma testável

ex.: nº de transações/seg ou tempo de resposta em seg, mseg

O sistema é testado em condições reais de operação.

QST112

06/2001


Variações dos testes de desempenho

• Testes de carga– geralmente associados com sistemas transacionais– usam simuladores de carga para geração de múltiplas

transações/usuários simultaneamente

• Testes de volume– geralmente usados para sistemas “batch”– consistem na transmissão de um grande volume de

informações quando o sistema está com a carga normal ou– uso de arquivos grandes (maior tamanho possível) ou de

grande número de arquivos

QST112

06/2001


Teste de estresse

• Visa ir além dos limites do sistema: nº máximo de usuários simultâneos, nº máximo de processos ou de transações, …:– verificar se o sistema não apresenta um comportamento de

risco quando submetido a carga elevada e com um ou mais recursos saturados.

• Importância:– muitos sistemas apresentam comportamento de risco nessa

situação– falhas detectadas são sutis– correções desse tipo de falha podem requerer retrabalho

considerável (e.g., rever arquitetura)

QST112

06/2001


Robustez

• O que é [IEEE Std Glossary]:– O grau em que um sistema ou componente pode

funcionar corretamente em presença de entradas inválidas ou sob condições ambientais estressantes.

• Em suma, pode ser interpretado como a capacidade do sistema em:– Tratar exceções– Tolerar falhas

• Como medir robustez?– proposta de Robustness Benchmark

• Como determinar se um sistema é robusto?– Realização de testes de robustez

QST112

06/2001


Testes de robustez

• Objetivo:– Verificar se o comportamento do sistema é

adequado em presença de:• Entradas inválidas• Entradas inoportunas• Condições ambientais anormais

– Abordagens:• Formais• Baseadas em injeção de falhas

QST112

06/2001


Injeção de falhas

• O que é– Técnica de validação de software que consiste em

observar o funcionamento de um sistema em presença de falhas ou erros.

• Objetivos:– Verificação – remoção de falhas de software no

sistema em teste.– Avaliação – obtenção de medidas de atributos de

qualidade: confiabilidade, disponibilidade, entre outras.

QST112

06/2001


Esquema típico dos testes de robustez

Comportamento especificado

Espaço de entrada

Software emTeste

Espaço de saída

Entradas válidas

Entradas inválidas ou inoportunas

Normal

Não especificado

Deve retornar erro

Operação robusta

Falhas de interface

Defeito

[base: Koopman99]

QST112

06/2001


Falhas de interface: o modelo Ballista

Tipo do dado Valores

Inteiro 0, 1, -1, MaxInt, MinInt

Real 0., 1., -1., DblMin, DblMax

Boolean Inversão de estado (V F, F V)

String Null, string do tamanho da memória virtual, string com caracteres especiais (fim de arquivo, formatação, etc)

Descritor de arquivo (tipo inteiro)

0, 1, -1, MaxInt, MinIntdescritor de: arquivo aberto para leitura, arquivo aberto para escrita, arquivo vazio, arquivo apagado após o descritor ter sido atribuído

Fonte: Projeto Ballista - http://www.ece.cmu.edu/~koopman/ballista/

QST112

06/2001


Exemplo de falhas de interface – modelo Ballista

API: write(int filedesc, const void *buffer, size_t nbytes)

Tipos de descritor buffer de tamanhodados de arquivos memória

Valores de teste

FD_CLOSEDFD_OPEN_READFD_OPEN_WRITEFD_DELETEDFD_EMPTYFILE...

BUF_SMALL_1BUF_LARGE_512MBUF_HUGE_2GBUF_NULLBUF_16...

SIZE_1SIZE_ZEROSIZE_NEGSIZE_MININTSIZE_MAXINT...

Caso de teste write(FD_CLOSED, BUF_NULL, SIZE-NEG)

(inspirado em Koopman2008)

QST112

06/2001


Exemplos de resultados da aplicação de Ballista com Sistemas Operacionais

Fonte: Philip Koopman, Kobey DeVale, and John DeVale. INTERFACE ROBUSTNESS TESTING: EXPERIENCES AND LESSONS LEARNED FROM THE BALLISTA PROJECT. Relatório, 2008.

Sistema operacional Nº funções testadas

Nº de funções “system killers”

Exemplo de funções “system killer”

% de defeitos de robustez (normalizada)

Linux 2.0.18 190 0 N/a 12,5

Red Hat Linux 2.2.5 183 0 N/a 21,9

Windows 98 SE SP 1 237 7 CreateThread, DuplicateHandle, strncpy, ...

17,8

Windos CE 2.11 179 28 13,7

Sun JVM 1.3.1-04 (Red Hat Linux 2.4.18-3)

226 0 N/a 4,7

Nº de funções chamadas que foram a causa do defeito catastrófico

Funções chamadas que foram a causa do defeito catastrófico

QST112

06/2001


Testes de segurança

• Visam verificar a capacidade do sistema de impedir acesso não autorizado, sabotagem ou outros ataques intencionais

• Características básicas de segurança são testadas como as outras funcionalidades (logon/logoff, permissões)

• Testes são geralmente feitos por especialistas ou “hackers” contratados

• Testam a capacidade do sistema de resistir a ataques– Quem realiza os testes deve “pensar” como um atacante

QST112

06/2001


Recomendações para Testes de Segurança

• Critérios e metodologias para testes de segurança foram propostos por diferentes grupos:– NIST (National Institute of Standards and Technology)

• Manual descrevendo técnicas a serem usadas nos testes de segurança

– OSSTMM (Open Source Security Testing Methodology Manual)

• desenvolvido pela ISECOM (Institute for Security and Open Methodologies)

• Manual descreve a metodologia proposta para testes e análise de segurança

– OWASP (Open Web Application Security Project)• Guia descrevendo melhores práticas para a realização de testes

de penetração para aplicações e serviços Web

QST112

06/2001


Testes de Aceitação

Testes deSistemas

(funcionais)

Especificação deRequisitos Funcionais

funcionalidades testadas

subsistemasintegrados

Manual doUsuário

Testes deSistemas

(qualidade)

Especificação deRequisitos de Qualid.

Testes deAceitação

Requisitosdo usuário

sistema testado

sistema aceito

QST112

06/2001


Testes de Aceitação

• Têm os mesmos objetivos que os testes de sistemas, só que envolvem a participação do cliente ou usuário

• Escolha dos testes feita pelo cliente• Referências:

– Manual do Usuário

• Testes alfa:– realizados por um grupo de usuários no ambiente de

desenvolvimento– seu objetivo é determinar se o sistema pode ser liberado

• Testes beta– realizados por um grupo de usuários em ambiente de

operação

QST112

06/2001


Ferramentas

• Testes manuais: – não recomendável pois número de testes e nº de falhas

• Ferramentas que podem auxiliar:– capture/playback: permitem armazenar e re-aplicar conjuntos

de testes– controle de versões: controlar o sistema e seu histórico de

testes– comparação entre resultados do delta e da linha básica– embaralhador de casos de teste: permitem revelar falhas de

seqüência de entradas– testes embutidos: assertivas permitem revelar falhas de

contrato. Drivers embutidos permitem reduzir custos com manutenção dos testes.

QST112

06/2001


Referências

R.Binder. Testing OO Systems. Addison Wesley, 1999, c.16-19.M.Fowler. Mocks aren’t stubs. Postado na Internet em julho/2004.

http://www.theserverside.com/news/thread.tss?thread_id=27209G.Rothermel, M.J.Harrold. “A Framework for Evaluating Regression Test

Selection Techniques”, Proc. 16th. Int’l Conf on Sw Eng., Sorrento, Itália, maio/1994, pg. 201-210.

M.J.Harrold. “Testing Evolving Software”. The Journal of Systems and Sw, nº 47, 1999, pp173-181.

L.A Fondazzi Martimiano. “Estudo de Técnicas de Teste de Regressão Baseado em Mutação Seletiva”. Dissertação de mestrado. Instituto de Ciências Matemáticas e de Computação - USP/S.Carlos, 1999.

G. Meszaros. : A Pattern Language for Automated Testing of Indirect Inputs and Outputs using XUnit. PLOP 2004. Obtained in jan/2006 at: http://testautomationpatterns.com/TestingIndirectIO.html

QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes.

Documents

Transcript of QST112 06/2001 IC-UNICAMP Eliane Martins INF321 Fases de Testes.