SBMF 2008, Salvador-BA, Brasil Marcelo d'Amorim [email protected] Fundamentos do Teste de...

SBMF 2008, Salvador-BA, BrasilMarcelo d'Amorim

[email protected]

Fundamentos do Teste de Software

Motivação econômicaTeste e depuração é responsável por + de

50% do custo total de desenvolvimento [Myers-1979, NIST-report-2002]

Defeitos escapados podem ter consequências desastrosasExemplo: Mars Orbiter (1999), Ariane 5 (2001)

Verificação e Validação (V&V)Theorem provingStatic analysisTestingInspectionWalkthroughs

Definição: Testes (processo)Atividade(s) de encontrar erros no software

LimitaçõesNão prova corretude como theorem provingNão é automático como análise estáticaPorém...

É técnica de V&V dominante na indústriaDocumenta intenções e designsPode ser combinada com técnicas formais para

encontrar erros de forma mais sistemática. Por exemplo,Kernel do Linux [Cadar et al., 2006], Protocolos de

rede [d´Amorim et al., 2005], Escalonador de tempo real [Penix et al., 2000], etc.

Definição: Teste (artefato)“A set of test inputs, execution conditions,

and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement” [IEEE, do178b]

Exemplopublic class Customer { String getName() {…} }public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} }


Bank bank = Bank.createBank();String name = “customer1“;Customer cust = bank.createCustomer(name);Assert.assertEquals(name, cust.getName());


Bank bank = Bank.createBank();String name = “customer1“;Customer cust = bank.createCustomer(name);Assert.assertEquals(name, cust.getName());

Entrada e resultado esperado:

Exemplopublic class Customer { String getName() {…} }public class Bank{ static Bank createBank() {…} Customer createCustomer(String name) {…} Customer search(String name) {…}}

Bank bank = Bank.createBank();String name = “customer1“;Customer cust = bank.search(name);if (cust == null) { Customer cust = bank.createCustomer(name); Assert.assertEquals(name, cust.getName());}

Condições de execução:

Terminologia: Falta e FalhaIEEE STD. 982.2-1988 (

http://standards.ieee.org/)Fault (falta, bug ou defeito): problemaFailure (falha, ou erro): manifestação do

problemaMais detalhes…

Software Metrics and Reliability [Rosenberg et al., ISSRE’98]

http://standards.ieee.org/

Quiz: Localize falta e falha no pgm. abaixo

// pre condicao: v != nullpublic static void sort(int[] v) { for (int i = 0; i <= v.length; i++) { …v[i] … }}

Quiz: Localize falta e falha no pgm. abaixo

// pre condicao: v != nullpublic static void sort(int[] v) { for (int i = 0; i <= v.length; i++) { …v[i] … }}

CAUSA

EFEITO

Teste e DepuraçãoTeste é atividade de localizar falhas!Depuração é atividade de localizar faltas!

Teste e DepuraçãoTeste é atividade de localizar falhas!Depuração é atividade de localizar faltas!No exemplo anterior

Atividade de teste revela um erro no uso de v[i]. E.g., com sort(new int[]{});

Depuração localiza o defeito na condição de parada do loop: i <= v.length

Terminologia: suíte e regressãoSuíte de testes é o mesmo que conjunto de

testesRegressão é o evento de uma falha em um

teste que já passou

Suíte de regressão serve para capturar falhas com origem na modificação contínua do programa

Enquete: Voce já usou?JUnit3JUnit4NUnitAnt Make

Agenda do cursoDemo Junit (framework de testes)Testes no desenvolvimentoQualidade de suíte de testes

Demo EclEmma (cálculo de cobertura)Demo MuClipse (cálculo de score de

mutação)Automação da geração de testes

Demo TARGET (geração baseada em modelos)

Demo Randoop (geração aleatória)

Demo JUnit

Testes no desenvolvimento

Testes no desenvolvimentoGerência de bugs (E.g., bugzilla)Teste contínuo

programador testador

gerente cliente

alguns papéis


gerente

requisitos

atribuiçãoatribuição

cliente


gerente

Bug tracker

Sistema de bug trackingObjetivo: gerenciar ciclo de vida de bugsProgramadores e testadores modificam status

de reportGerentes tem acesso a informação valiosa

Exemplo: frequência de erro por móduloExemplo:

Bugzilla (open-source). http://www.bugzilla.org/

Máquina de estados de um bug no Bugzilla

Teste contínuoExecução ininterrupta de testesAlternativas

Unidade (localmente)ver http://groups.csail.mit.edu/pag/continuoustesting/

Sistema (no servidor)ver http://www.javaworld.com/javaworld/jw-11-2006/jw-

1101-ci.htmlProblemas (mais críticos quando usado

localmente)Pode impactar performancePode reportar falso alarmes (devido a modificações

incompletas)

ResumoFerramenta de gerência de erros

E.g., bugzilla, clearquest, etc.Ferramenta de integração contínua

E.g., cruisecontrol, continuum, etc.Controle de versão

E.g., cvs, svn, etc.Ferramenta de build

E.g., ant, make, maven, etc.

Qualidade de suíte de testes

ProblemaUsuário não sabe quão adequada é uma

suíte de testes para encontrar erro. Em resumo, como medir qualidade?

Duas soluçõesCoberturaScore de Mutação

Definição: coberturaValor que indica quanto uma suíte de

testes cobre um programa de acordo com um critério particular

ExemploCobertura de métodos indica o percentual de

métodos de uma aplicação que um conjunto de testes exercita

PrincípioMaior cobertura aumenta chances de

encontrar o erro

Simplificação didáticaTestar a estrutura de um programa equivale a

testar um grafo

Control-Flow Graph (CFG)

stmt0;while (condA){ if (condB){ stmt1; stmt2; } stmt3;}stmt4

Control-Flow Graph (CFG)

stmt0;while (condA){ if (condB){ stmt1; stmt2; } stmt3;}stmt4

stmt0

condA

stmt1;

stmt2;

stmt3

condB

stmt4

Control-Flow Graph (CFG)stmt0

condA

stmt1;

stmt2;

stmt3

condB

stmt4

b

c

a

f

d

e

t0

t1 t6

t2

t3

t4

t5

QuizO que é uma sequência de teste para um

grafo?

QuizO que é uma sequência de teste para um

grafo?Sequência de transições a partir do nó inicial que

termina em uma folha

Cobertura de GrafosExemplo de sequência

de testet0; t6

b

c

a

f

d

e

t0

t1 t6

t2

t3

t4

t5

Critérios de adequação de grafoNóTransiçãoCaminho

Critérios de adequação de grafoNó

Teste suíte TS é adequado a nó (i.e., cobre todos os nós) se para cada nó n em G existe t em TS que cobre n (i.e., origem ou destino de t é n)

Transição…

Caminho…

Critérios de adequação de grafoNó

Teste suíte TS é adequado a nó (i.e., cobre todos os nós) se para cada nó n em G existe t em TS que cobre n (i.e., origem ou destino de t é n)

Transição…

Caminho…

Em geral, número de caminhos de um grafo é infinito

ExercícioReporte suíte de teste adequada a nóReporte suíte de teste adequada a transiçãoExiste suíte de teste adequada a caminho de até

N transições?

Demo EclEmma

ProblemaUsuário não sabe quão adequada é uma

suíte de testes para encontrar erroDuas soluções

CoberturaScore de Mutação

Teste de MutaçãoVerifica se uma suíte de teste é capaz de

encontar uma falha no programa modificado com um bug (Fault seeding/injection)

PrincípioUma suíte capaz de encontrar vários erros

artificiais pode encontrar mais erros reais

Teste de Mutação

PT0T1

T2…Tn

Como saber se TS é adequada para encontrar erros?

TS =

Teste de Mutação

P’ é uma versão que contém um erro!O que se pode concluir sobre TS?

PT0T1

T2…Tn

P’T0T1

T2…Tn

TS =

Teste de Mutação

P’ é uma versão que contém um erro!O que se pode concluir sobre TS?

PT0T1

T2…Tn

P’T0T1

T2…Tn

TS =

Inadequado para encontrar erro introduzido em P’

Teste de Mutação

O que o programador deve fazer ao perceber isto?

PT0T1

T2…Tn

P’T0T1

T2…Tn

TS =

Teste de Mutação

O que o programador deve fazer ao perceber isto?

PT0T1

T2…Tn

P’T0T1

T2…Tn

TS =

Adicionar novo teste para capturar erro em P’

Teste de Mutação

Novo teste deve passar em P e falhar em P’Definição: TS distingue programas P e P’

PT0T1

T2…Tn

P’T0T1

T2…Tn

TS =

Tn+1 Tn+1

TerminologiaMutanteOperador de MutaçãoMutante morto Mutante sobreviventeMutante equivalente

TerminologiaMutante: Programa original modificadoOperador de Mutação: Definição de uma

transformação (de original para mutante)Mutante morto: Quando a suíte de teste

consegue distinguir mutante do originalMutante sobrevivente: Não morto (acima)Mutante equivalente: Semântica do

mutante é equivalente ao original

Mutantes sobreviventesDuas razões para P’ sobreviver ao teste de

distinção de P em relação a TSSuíte TS não consegue distinguir P e P’P e P’ são equivalentes => problema

indecidível!

Metodologia (Parte 1)

Input: P: Pgm, OPS: set of OpOutput: set of Pgm Pseudo-code: gerarMutantes /******************************************************* * gera vários novos programas derivados de P. * Para cada um, identifica um operador de * mutação em OPS e uma posicão para aplicá-lo * em P. Em geral, cada mutante inclui apenas * uma modificação. *******************************************************/


Input: P: Pgm, TS: set of Pgm, {P1, P2, …, Pn}: set of PgmOutput: (survivors: set of Pgm, killed: set of Pgm) Pseudo-code: encontreSobreviventesfor each Pm in {P1,P2, …,Pn} do // distinguir mutante if (exists some T in TS s.t. RUN(T,Pm) == FAIL) killed = killed U {Pm} else survivors = survivors U {Pm}donereturn (survivors, killed)


P

TS

Set of Mutants

OPsgerarMutantes encontreSobreviventes

sobreviventesnovos testes

Score de MutaçãoEstá para o teste de falhas assim como

cobertura está para o teste estruturalScore: #mortos / (#mutantes -

#equivalentes)Ex. 10 mutantes, 5 mortos, 2 equivalentes.

Score = 5/8 = 0.625 (62.5%)

LimitaçõesNão se sabe se o erro introduzido por um

operador de mutação é relevante para encontrar erros reais

Identificação de mutantes equivalentes é manualConsome tempo do testador e é passível a

erro

Demo MuClipse

Automação da geração de testes

Automação da geração de testesDuas preocupações

Entrada (sequência + dados)Classificador

Várias técnicasModel-Based Testing (e.g., TARGET), Random

Testing (e.g., RANDOOP), Symbolic Testing (e.g., Symstra), Concolic Testing (e.g., DART), etc.

Model-Based Testing (MBT)Modelo orienta o teste de programas

Modelo representa comportamento esperado (spec)

Testes são gerados a partir do modeloViolação indica que o sistema não está em

conformidade com o modeloPrincipais limitações

Incompletude do modeloDificuldade na construção do modelo

TARGETEntrada são requisitos e parâmetros de

geraçãoDocumentos Word estruturados descrevem os

requisitosCada arquivo descreve uma feature com vários

casos de uso. Um caso de uso possui diversos fluxos (principal, alternativos, e excepcionais).

Saída é uma suíte de testePlanilhas no Excel descrevem os casos de

teste

Demo TARGET

Random TestingGeração de entradas

Seleção de sequência e dados randômica e incremental

Principal limitaçãoDegrada com o aumento no tamanho do

espaço de estados

RandoopEntrada é um conjunto de classes e

parâmetros de configuraçãoSaída é uma suíte de testesGeração do classificador

Derivado de conjunto de testes [Pacheco & Ernst, 2005]

Específicos da linguagem [Pacheco et al., 2007]

Informados pelo usuário

Feedback-directed random test generation. Carlos Pacheco et al., ICSE 2007

Demo RANDOOP

DesafiosMelhorar automação

Geração de classificadores (oracles)Geração de dadosGeração de sequências

Melhorar escalabilidadeEscalar técnicas além do teste de unidade

SBMF 2008, Salvador-BA, Brasil Marcelo d'Amorim [email protected] Fundamentos do Teste de...

Documents

Transcript of SBMF 2008, Salvador-BA, Brasil Marcelo d'Amorim [email protected] Fundamentos do Teste de...