testes de sistemas concorrentes: uma abordagem formal paulo eduardo e silva barbosa março de 2004...

Testes de Sistemas Concorrentes:

Uma abordagem formal

Paulo Eduardo e Silva BarbosaMarço de 2004

Testing Concurrent Systems: A Formal Approach

Jan Tretmans – University of Twente

IntroduçãoUltimamente muita pesquisa foi dedicada à área

de métodos formaisA prática corrente de checagem de corretude é

baseada em uma abordagem mais informalA combinação de testes e métodos formais nem

sempre é feita

IntroduçãoPouca gente imagina como uma mão lava a

outraAs mãos sujas dos testesA mão limpa e matemática dos métodos de

verificação formal

IntroduçãoAs visões estão mudandoPesquisas acadêmicas com testes estão

evoluindo e mesmo o verificador mais formal admite que um sistema verificado formalmente ainda deve ser testado

Métodos formais são cada vez mais usados, uma especificação formal pode ser benéfica durante um teste, dando-lhe maior suporte

PropósitosDiscutir como testes podem ser executados

baseados em especificações formaisComo obter vantagens em termos de precisão,

claridade e consistência do processo de testes pela adoção de uma abordagem formal

Tópicos da discussãoCasamento entre métodos formais e testesA necessidade de ambosUma especificação formal verificada é um bom ponto

de partida para testesTestes formais são um bom ponto de partida para

introduzir métodos formais no desenvolvimento de software

Estrutura da apresentaçãoDiscussão informal sobre testes de software clássicosApresentação de um framework geral e formal para testes

utilizando métodos formaisFaz uma discussão mais específica desse framework com o

formalismo dos sistemas de transições rotuladosDiscutimos o suporte ferramental e apresentamos um

exemplo de aplicaçãoDiscussão de fontes e perspectivas

Discussão informal sobre testes de software

clássicos

Testes de softwareApresentação da abordagem clássicaA especificação é a base do testeOrdens dos testesTestes podem ser aplicados em diferentes níveis

de abstraçãoTeste black-box ou funcionalTeste white-boxTeste grey-box

Fases do processo de testes

Geração dos testesExecução dos testes

Outras atividades importantes:GerenciamentoManutenção

Automação dos testesTeste é um candidato ideal para automaçãoFerramentas record and playbackFerramentas de cobertura de código

Critérios:Todos os caminhosTodos os statementsTodas as combinações de uso

Framework para testes formais

Framework para testes formais

É apresentado um framework para uso de métodos formais em testes de conformidade

Testa com relação à sua especificação formal do seu comportamento funcional

O mais importante é que liga o mundo informal das implementações, testes e experimentações com o mundo formal das especificações e modelos

Conceitos abordados no framework

ConformidadeObservações e testesTestes de conformidadeSuas extensões

ConformidadeNecessitamos de implementações e especificaçõesAs especificações são formais. Universo de especificações é

denotado por SPECSImplementações são os sistemas que iremos testar. Denotamos

por IUT pertencentes a IMPSIUT conforms-to s expressa que IUT é uma correta

implementação da especificação s.Formalmente sobre implementações, uma implementação IUT

IMPS pode ser modelado por um objeto formal Iiut MODS

Isso é chamado como hipóteses de teste

Hipóteses de testeExpressam conformidade por uma relação formal entre

modelos de implementações e especificaçõesIUT IMPS é dita correta com relação a

s SPECS, IUT conforms-to s, sss Iiut MODS de IUT é imp-relacionado com s: Iiut imp s.

Uma relação de implementação imp MODS X SPECS

Observações e TestesO comportamento de uma IUT é investigado

fazendo experimentos na implementação e observando as suas reações

casos de testes e execução de testes

Casos de testes e execução de testes

Considere casos de testes formalmente pertencentes a um domínio TESTS

Requer um procedimento para executar um caso de teste t a uma IUTDenotada por EXEC(t,IUT)O que acontece durante a execuçãoA execução de um teste irá levar em um conjunto de observações,

subconjunto de OBSFunção de observação:

Obs: TESTS X MODS P(OBS) obs(t,Iiut) formalmente modela a execução do teste real EXEC(t,IUT)

Hipóteses de TestesSeu significado:

Para todas as implementações reais que estamos testando, assume-se que existe um modelo, tal que se colocássemos a IUT e o modelo em black boxes e fizéssemos todos os experimentos possíveis em TESTS, não conseguiríamos distinguir entre a real IUT e o modelo

Funções de veredito vtUsualmente interpretamos observações de testes em

termos de certo ou erradoVt: P(OBS) {fail, pass}

Isso é extendido como uma suíte de testes:

Uma implementação falha em uma suíte de testes se ela não passa:

Testes de conformidadeEnvolve saber se uma implementação está

conforme respeito a uma relação de implementação imp com sua especificação

Uma suíte de testes com essa propriedade é chamada completa

Pode distinguir entre as implementações conformes e não-conformes

É um requerimento muito forte para Testes práticos

Implicações soundImplicações exhaustiveness

Mostrar soundness

Se a propriedade de completude for provada no nível dos modelos, e se tivermos base que as hipóteses de testes valem, então a conformidade de uma implementação com respeito a sua especificação pode ser decidida por meio de um procedimento de testes

Derivação de testesEntão, uma atividade importante passa a ser

dividir os algoritmos no qual produzem suítes de testes sound e/ou completos de uma especificação dada uma relação de implementação

Deve produzir suítes de testes sound para alguma especificação s

ExtensõesArquitetura de testes: define o ambiente no qual

uma implementação é testadaIntrodução da técnica de cobertura: a cada

implementação errônea detectada por uma suíte de testes, é atribuido um valor e depois esses valores são integrados

Sistemas de transição rotulados

De que consisteSeu formalismo modela comportamento de processos

(especificações, implementações e testes)Serve como modelo semântico para várias linguagens

formais

Sistemas de transição rotulados

Os domínios formais SPECS, MODS e TESTS serão agora algum tipo de sistema de transição

Sua teoria de testes não serve para testes de conformidade

Em vez de começar com uma especificação e encontrar uma suíte de testes, define relações de implementação

ExemploDada uma classe de testes:Um sistema de transição p é equivalente a um q se algum

caso de teste em uma classe leva às mesmas observações com p e q

Uma vez que as relações de implementação tenham sido definidas, o teste de conformidade inclui encontrar o algoritmo de derivação de testes em que as suítes de testes possam ser derivadas de uma especificação que sejam sound e tentem ser mínimos

Teoria ioco-testingUsa os dois tipos de testesSua relação de implementação é definida como no slide

anteriorDerivação de testes a partir de especificações é feito do

resultado de um algoritmo de derivação de testes sound ou exaustivo

EspecificaçõesUtilizamos sistemas de transições rotulados ou alguma

linguagem formal com a semântica de sistemas de transições rotulados

Devemos conhecer as ações do sistema de transição e deve ser particionado em entradas e saídas (Li e Lu)

LTS(L) – sobre ação do alfabeto LSPECS := LTS(Li U Lu)

Implementações e seus modelos

Implementações são modeladas por uma classe especial de sistemas de transição chamados input-output transition systems (IOTS)

IOTS(Li, Lu) classe com entradas Li e saída LuMODS := IOTS(Li, Lu)IMPS são os programas que podem ser

modelados por IOTS

Relação de implementação

ioco ⊆ IOTS(Li,Lu) X LTS(Li U Lu)Observação de refutação ∉ LTESTS = LTS(L U {})Enquanto observando um processo, uma

transição rotulada com só pode ocorrer se nenhuma outra é possível

O observador sabe que o processo não pode executar nenhuma das ações que ele oferece

Operador paraleloÉ o tradicional operador paralelo de

sincronização extendido com a regra

É chamado refutação em pré-ordem

Relação de implementação mais fraca

(conf)É uma modificação do teste em pré-ordem

restringindo todas as observações para os traces que estão contidos na especificação s

Facilita os testes porque deixa de considerar o vasto conjunto complementar

Faz apenas o que deve fazerA teoria dos testes canônicos baseia-se nessa

abordagem

Teste em pré-ordem para autômatos entrada/saída

É requisitado que as entradas estejam sempre habilitadas

Relação iocoSegue os princípios dos testes em pré-ordem

com testes que possam refutar ações na refutação em pré-ordem

Entradas estão sempre habilitadasA distinção com o IOA é a restrição dos traces

apenas das especificações como em conf

Definição semi-formal da relação ioco

p after σ é o conjunto de estados onde o sistema de transições p pode após executar o trace σ

out(p after σ) é o conjunto de ações de saída após p after σ

Um estado p é quiescente se não pode ocorrer ação de saída

Uma ação δ, indicando quiescencia deve ocorrer apenas se existe um estado quiescente em p after σ

Straces(s) são traces de suspensão da especificação, onde δ vai ocorrer com entradas e saídas normais

A relação de implementação escolhida é a ioco: imp := ioco

Uma implementação é ioco-correta com respeito a especificação s se i nunca produz uma saída na qual não poderia ser produzida por s na mesma situação, após o mesmo trace de suspensão

Então i deve ser apenas quiescente, não produzir saídas se s for também

Exemplo 1

Exemplo 1Dois IOTS com Li = {?but} e Lu{!liq,!choc}not( r1 ioco r2) pois:out(r1 after ?but δ ?but) = {!liq, !choc},Enquanto out (r2 after ?but δ ?but) = {!choc}

TestesTESTS é instanciado também com sistemas de

transições, mas adicionamos um rótulo extra θ para detecção de refutação

Retringimos testes para sistemas determinísticos com comportamento finito

Os estados terminais são pass ou fail

TestesPara cada estado não-terminal s de um test case que

init(s) = {a} para algum a ∈ Li, ou init = Lu U {θ}init(t) é o conjunto de ações iniciais de tO comportamento de cada test case é descrito por uma

árvore finitaO rótulo especial θ ∉ L U {δ} será usado para

detectar estados quiescentes de uma implementaçãoNormalmente é um tipo de time-out

Exemplo 2

ObservaçõesSão logs de ações, traces sobre L U {θ}OBS := (L U {θ})*Função de observação: Composição

sincronizada paralela de t e i terminando em um estado final de t

Exemplo 3Para r1 temos três observações com t do

exemplo 2:

VereditosÉ atribuído a um conjunto de observações O

OBS é pass se todos os traces em O leva ao estado terminal pass do test case

Exemplo 4No exemplo 3, como o estado terminal de t para

a segunda vez é fail, o veredito de r1 é fail.O veredito de r2 é pass

Execução de testesEXEC(t, IUT) deve expressar a semântica

expressa por obs(t, Iiut) e estabelece as hipóteses de testes

Derivação de testesAlgoritmo que especifica a derivação dos test cases de

uma especificação de um sistema de transição rotulado para a relação de implementação ioco

“;” denota um prefixo de ação“+” denota escolha“” denota escolha generalizadaS after a denota o conjunto de estados que podem ser

alcançados de algum estado em S via uma ação a

Algoritmo derivação de testes ioco

Seja s uma especificação com estado inicial s0S é um conjunto não-vazio de estados com

inicialmente S = {s0}Um test case t é obtido de S por um número

finito de recursões de uma das três escolhas não-determinísticas

Algoritmo derivação de testes ioco

Sobre o algoritmoDada uma especificação s LTS(L1 U L2)É provado que este algoritmo produz apenas

casos de testes sound (que nunca produzem fail enquanto testando uma implementação ioco-conforming

Formalmente, seja der alguma função satisfazendo o algoritmo não-determinístico, então:

Alguma implementação não-conforme pode ser sempre detectada por caso de teste gerado por esse algoritmo

Seja Ts o conjunto de todos os casos de testes que podem ser gerados pelo algoritmo de s, então:

Exemplo 5Usando o algoritmo de derivação ioco-test, o caso de

teste t da figura 2 pode ser derivado da especificação r2 na figura 1

Isso é consistente com a figura 1 e exemplo 4:R1 not ioco r2, r2 ioco r2 (reflexiva) e vt(obs(t,r1)) =

fail e vt(obs(t,r2)) = passO caso de teste t foi usado para detectar que r1 não é

ioco-correct com respeito a r2