introdução aos testes de software -...
TRANSCRIPT
Acidente: Therac 25*
Equipamento para tratamento de câncer utilizando RADIOTERAPIA e RAIO-X6 casos de overdose (1985 a 1987)
2 mortes imediatas2 mortes por câncer desenvolvido devido à overdose2 casos com ferimentos permanentes
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente: Therac 25*
Software assumiu um padrão de temporização da entrada de dados mesmo tendo sido agilizada esta entrada baseada na experiência dos operadoresSoftware foi considerado livre de defeitosSoftware não passou por uma análise de segurançaQualidade de software não era gerenciada
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente: Therac 25*
Alguns módulos de software eram reusados mas sem passar por uma análise de segurançaComplexidade desnecessária do softwareEquipe de desenvolvimento não conhecia técnicas de concorrência de processos -> Equipe sem qualificação
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente: Therac 25*
Análise de segurança aplicada em outros componentes também deve ser aplicada no projeto e na implementação do softwareTestar usos não previstosQualificar a equipe de desenvolvimentoAnálise permanente de incidentes
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente com Airbus*
Aterrisagem numa pista molhada e com fortes ventosReversão da turbina somente após o toque do trem esquerdo
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente com Ariane 5*
Mesmo em condições favoráveis, o foguete desvia da trajetória e explodePrejuízo de US$400 milhõesÂngulo de ataque maior de 20o
Comando recebido pelo Computador de Bordo e foi calculado pelo computador de referência que estava em paneErro de conversão de ponto flutuante de 64 bits para inteiro de 16 bits
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente com Ariane 5*
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Testes simulando com dados reaisTratamento de exceçõesProteger contra exceções no código
Acidente com Titan IV*
Missões comerciais com possibilidade de lançar 2 missões independentesProjeto com 2 conjuntos de interfaces de comunicação: frontal e traseiraResponsável por uma missão usou porta traseiraOutro responsável por uma outra missão projetou utilizando porta frontal
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente com Titan IV*
A troca não foi comunicada a equipe do softwareTestes realizados com software genérico para comandos com as duas portasCarga útil não se separaPrejuízo de US$300 milhões
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente com Titan IVB*
Satélite que foi levado ficou na órbita elípticaPrejuízo de US$1.3 Bilhões-0.199765 ao invés de -1.99765Faltou verificar dados críticos
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente de Boeing 757 em Colombia*
Choque contra montanha perto de aeroporto de CaliAs séries 757 e 767 tem muita automatização e requer pouco esforço do pilotoA aterrisagem estava prevista numa pista mas o controle indica uma outra
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Acidente de Boeing 757 em Colombia*
Para realizar esta mudança, a tripulação deve executar várias operaçõesPor falta de conhecimento do aeroporto por parte dos pilotos, houve uma entrada errônea dos dados“ Speedbrake” acionado para descida não pôde ser desligado ao tentar desviar da montanha
*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade
Verificação e Validação(IEEE Definition)
VERIFICAÇÃOConfirmar por testes e com provas objetivas que requisitos especificados foram cumpridos.Garante que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase ou seja o produto foi o produto foi construído corretamente (the product construído corretamente (the product was built right)was built right)
Verificação e Validação (cont.)
VALIDAÇÃOConfirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridosProva que o software implementa cada um dos requisitos corretamente e completamente ou seja, o produto correto o produto correto foi construído (the right product was foi construído (the right product was built)built)
Produtividade e Qualidade em Software
Peça produzida em massa numa fábricaCusto do projeto (qualquer que seja) é pequeno quando amortizado sobre produção em grande escalaControle de qualidade e testes desde componentes até produto final antes de despachar
Produtividade e Qualidade em Software (cont.)
Falhas? descarta ou retrabalho
Produtividade numa linha de montagem:Custo dos materiaisRetrabalhoComponentes descartadosCusto de garantia de qualidadeTestes
Produtividade e Qualidade em Software (cont.)
MENOR esforço em garantia de qualidade implica em ALTA taxa de rejeição e conseqüentemente MAIOR o custo líquidoBOA inspeção implica em descobrir falhas e domínio de custos de inspeção e conseqüentemente MAIOR o custo líquidoCompromisso entre Custos de Garantia de Qualidade x Custos de Fabricação
Produtividade e Qualidade em Software (cont.)
Estabelecem-se níveis de Testes e Garantia de Qualidade que MINIMIZEM o custo líquido mantendo um certo padrão de qualidadeCustos de Testes e Garantia de Qualidade variam desde 2% (produtos de consumo) a 80% (foguetes, reatores nucleares, aviões...)
Produtividade e Qualidade em Software (cont.)
Relação entre PRODUTIVIDADE e QUALIDADE para Software é bem diferenteCusto de “ Manufatura” de Software: fita ou disco, tempo do uso do computadorGarantia de Qualidade da “ Manufatura” do Software: check sums ou outros métodos de detecção
Produtividade e Qualidade em Software (cont.)
Custos do Software são dominados por seu DESENVOLVIMENTOManutenção do Software é diferente da manutenção do HardwareNão é propriamente uma manutençãoExtensão do desenvolvimento: melhorias são projetadas, implementadas e são corrigidas as deficiências
Produtividade e Qualidade em Software (cont.)
A fatia maior do custo do Software está nos custos dos ERROS (bugs)
Custo de DETECTÁ-LOSCusto de CORRIGÍ-LOSCusto de PROJETAR TESTESTESTES para ACHÁ-LOSCusto de EXECUTAR estes TESTESTESTES
Produtividade e Qualidade em Software (cont.)
Diferença principal entre produtividade de uma peça e produtividade de um Software
Para Hardware, qualidade é APENAS uma das várias determinantes de produtividadeNo caso de Software QUALIDADE e PRODUTIVIDADE são INDISTINTAS
Produtividade e Qualidade em Software (cont.)
Concentração na prevenção de errosAchar sintomas causados pelos errosDiagnóstico claro para facilitar a correção dos errosPrevenir erro é melhor que detectar o erro e corrigí-lo
Não há código para corrigirNão há código para corrigir
Produtividade e Qualidade em Software (cont.)
“ Teste e depois codifique” (D. Gelperin & W. Hetzel)O ideal é suceder na prevenção para que a atividade de testes não seja necessáriaIMPOSSÍVEL. Então, concentrar em descobrir os errosERRO é um desvio do comportamento esperado
Produtividade e Qualidade em Software (cont.)
Saber que o programa está errado não implica em conhecer o erroDiferentes erros podem se manifestar de uma maneira semelhanteUm erro pode ter vários sintomasSintomas e causas podem ser conhecidos somente com testes detalhados
Teste e Depuração
Objetivo de Teste é mostrar que um programa tem errosObjetivo de Depuração é descobrir o tal erro e projetar e implementar as mudanças no programa para corrigir aquele erroTeste: prova uma falha do programadorDepuração: “ vingança” d o programador
Função x Estrutura
Teste FuncionalPrograma é visto como CAIXA PRETAEntradas são submetidas e as Saídas são verificadas se estão de acordo com a especificação – CONFORMANCE TESTINGPreocupação é com a funcionalidade e não com os detalhes da programaçãoPonto de vista de um USUÁRIO
Função x Estrutura (cont.)
Teste EstruturalDetalhes da implementação (estilo, controle, linguagem, banco de dados, código). Programa é visto como CAIXA BRANCA
Bons sistemas são construídos em camadasUsuário vê apenas a última camada
Função x Estrutura (cont.)
Camadas mais internas são menos relacionadas com as funcionalidades do sistema e mais com a estruturaESTRUTURA para uma camada significa que é FUNÇÃO para outraExemplo: num sistema online, o usuário não tem menor idéia que no sistema há uma rotina de alocação de memória
Teste de Unidade
UnidadeO menor pedaço testável de um software, e que pode ser compilado e ligadoEm geral é um trabalho de um programador
Teste de UnidadeMostrar que a unidade NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto
Teste de Componente
ComponenteIntegração de uma ou mais unidadesPode ser uma unidade ou um sistema
Teste de ComponenteMostrar que o componente NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto
Teste de Integração
IntegraçãoProcesso onde os componentes são agregados em componentes maiores
Teste de IntegraçãoTeste de Componente pode ter sido satisfatório. Mesmo assim, a combinação destes componentes não está correta
Teste de Integração (cont.)
ExemplosChamadas ou retornos incorretosCritérios de validação de dadosManipulação errônea de objetos
Teste de Integração (cont.)
Exemplos (cont.)Considere rotina A que chama a si próprio
Teste inicial de componente NÃO INCLUI a chamada a sub-componentes a chamada recursiva a A não é testadaTeste de Integração é testar a chamada a A e o retornoTem-se agora um “ novo componente” integrado pois trabalha com o mecanismo de pilha; então teria que passar por um teste adicional
Teste completo é possível?
Qual é o objetivo de teste?Se fosse para PROVAR PROVAR que um programa não tem erros
Em Teoria, isto é impossívelNa Prática, isto também é impossível
Teste completo é possível? (cont.)
Abordagens demonstrando que o programa está correto
Teste FuncionalTeste EstruturalProvas de Correção (Correctness Proofs)
Teste Funcional
Qualquer programa trabalha com um número FINITO de entradasIndependente do significado destas entradas, será que não dá para considerá-las como um stream de bits?Então, um teste completo seria colocar o programa rodando para todas as possíveis combinações destas streams
Teste Funcional (cont.)
Para cada entradaAceita e produz uma saída corretaAceita e produz uma saída erradaNão aceita e informa deste fato
Considere um string de entrada de 10 caracteres 228080 combinações possíveis de entradas e suas saídas correspondentes
Teste Funcional (cont.)
É impraticávelSupondo que cada teste demore 1 micro-segundoDUAS VEZES A IDADE ESTIMADA DO UNIVERSO
Teste Funcional (cont.)
Quem garante que o hardware e o software usados para:
Gerar as entradasComparar a saída resultante com a saída esperadaDocumentar estes fatos
São livres de erros?????????????????????
Teste Funcional (cont.)
O problema é que Testes Funcionais são condicionados na SUPOSIÇÃO que as ferramentas de testes e ferramentas que preparam os testes são corretasSomente a rotina em teste está ERRADANo mundo real, isto seria um ABSURDO
Teste Estrutural
Testes tem que ser projetados de tal forma que eles seriam suficientes para garantir que TODO O CAMINHO dentro da rotina seja executadaO que fazer quando se encontra loops infinitos?E se dentro de cada destes loops houverem vários caminhos?
Teste Estrutural (cont.)
Mesmo uma rotina pequena poderá ter milhões (ou bilhões) de caminhosIsto faz com que teste completo seja impraticávelAqui também devem haver garantias que entradas preparadas são livres de erros, etc.
Prova de Correção
Provas formais dependem de uma combinaçao de conceitos funcionais e estruturaisA especificação tem que ser descrita formalmente (linguagem matemática)Prova indutiva é usada nos comandos para verificar se há saída correta para a combinação de todas as entradas
Prova de Correção (cont.)
Na prática, isto é muito caroTem sido usado muito em rotinas numéricas ou em software crucial como kernel de segurança ou pedaços de um compiladorHá outros problemas também
Prova de Correção (cont.)
Quem garante que a especificação é possível de se obter?Quem garante que dá para provar a consistência e completude desta especificação?É provado que isto é um problema não solúvel
Barreiras para Teste Completo
Manna, Z. & Waldinger, R. The logic of computer programming. IEEE Transactions on Software Engineering 4:199-229, 1978
Não se pode ter certeza que as especifcações estão corretasNenhum sistema de verificação pode verificar se todos os programas estão corretosNão se pode ter certeza que um sistema de verificação está correto.
Qual a solução?
Mudar a abordagem de PROVA ABSOLUTA para DEMONSTRAÇÃO CONVINCENTERealizar testes suficientessuficientes para garantir que a probabilidade de falha devido aos erros que hibernam é baixa o suficiente para aceitarO que é suficiente?
Qual a solução? (cont.)
SuficienteSuficiente depende da aplicaçãoO que é suficientesuficiente para um jogo não é suficientesuficiente para um reator nuclearTécnicas de testes e modelos de confiabilidade estão em constante evolução e será possível, baseado em resultados de testes, fazer uma medida quantitativa da confiabilidade do sistema
Teste de Conformidade
Foco maior será dado a testes funcionais ou seja teste tipo CAIXA PRETA (Black box testing)Este caso é considerado como Teste de Conformidade (Conformance Testing), i.e., a implementação está ou não está de acordo com a especificação
Teste de Conformidade (cont.)
Exemplos:Protocolos de comunicaçãoSistemas concorrentesFalhas e recuperação de sistemasConfiguração de sistemasBanco de dados distribuídos
Teste de Conformidade (cont.)
Não se pode testar algo sem primeiro entendê-loOu seja, teria que entender o que a Implementação Sob Teste (IUT) deve fazerTeste pode ser considerado um problema de busca: combinações de entradas e estados
Teste de Conformidade (cont.)
Se houver uma especificação e se for possível modelá-la por alguma técnica, pode-se então gerar os casos de testeExecutaria a implementação sob teste (IUT) baseado nos casos obtidos acimaPoderia confrontar com a especificação para dar um veredito se a IUT está ou não de acordo com a especificação
Teste de Conformidade (cont.)
Força bruta – está fora de questão!!!Testes “ aleatórios” não leva ao objetivoEntão, esta busca deve ser
SistemáticaFocadaAutomatizada
Teste de Conformidade (cont.)
SistemáticaPara garantir que toda a combinação seja testada
FocadaAproveitar as vantagens de se ter informações disponíveis sobre onde existiriam possíveis erros
Teste de Conformidade (cont.)
AutomatizadaPara produzir e executar o maior número de testes consistentes e repetitivos
Para atingir estes três objetivos, o ideal é utilizar MODELOS
Testes baseados em Modelos (Model-Model-Based TestingBased Testing)
ModelagemModelagem é utilizada para representarum sistema real onde se pode captar relações essenciaisA vantagem é que modelos são mais fáceis de serem desenvolvidos e analisados do que sistemas físicose.g., modelos são usados para explorar vários tópicos através de simulação
Modelagem (cont.)
No caso de testes, modelagem deve facilitar a representação da especificação para gerar os casos de testesQual técnica a ser utilizada para modelar a especificação?
Grafo (Máquina de Estados)
a/1
S1
S2 S3
a/0
b/1 b/0
b/1
a/0
Modelagem (cont.)
Estado inicial S1Seqüência abbS1, S2 e S3Saída:
011
[Lee & Yannakakis, 1996]
Métodos para Geração de Seqüências de Testes
Método T (Transition Tour)Método U (UIO – Unique Input/Output)Método DMétodo W
Exemplo Método TB/0
[Sidhu & Leung, 1989]
B A B A B A A A A A A A B B0 0 3 3 4 0 3 4 2 1 4 2 1 2
A/0
B/0B/1
A/1
B/1
A/1
A/0
B/1
3
1
2
4
0
A/0
Switch Cover Method (cont.)Step 1
Dual Graphcreation
Step 2
Arc creation,considering allnodes in the original graph
Step 3
Transformationinto a “ Eulerized”Graph by balancingthe polarity of thenodes
Step 4
Nodes aretraversed
Result:abf, abrbf,cf, crbf
PerformCharts em TestesGeração de casos de testes
Vários métodos desde que o software esteja especificado em Diagramas de Estado
Usar PerformCharts para especificar um software complexo em Statecharts para gerar automaticamente o diagrama de estadosAssociar um método (geração de casos de teste – transition tour, switch cover, W) à especificação
PerformCharts em Testes (cont.)
Mapping the Methodology Step a: PcML Specification <States> <Root Name="ReceivingCommand" Type="AND"> <State Name="A" Type="XOR" Default="Idle"> <State Name="Idle" Type="BASIC"/> <State Name="CountingTime" Type="BASIC"/> </State> <State Name="B" Type="XOR" Default="WaitingSync"> <State Name="WaitingSync" Type="BASIC"/> <State Name="CheckingField" Type="XOR" Default=“ WaitingExpId” > <State Name="WaitingExpId" Type="BASIC"/> <State Name="WaitingType" Type="BASIC"/> <State Name="WaitingSize" Type="BASIC"/> <State Name="Aborting" Type="BASIC"/> <State Name="WaitingChecksum" Type="BASIC"/> <State Name="WaitingData" Type="BASIC"/> </State> </State> </Root> </States>
PerformCharts em Testes (cont.)
M a p p i n g t h e M e t h o d o l o g y – S t e p b : C + + P r o g r a m ( o u t p u t ) S t a t e c h a r t R e c e i v i n g C o m m a n d ;
/ / S t a t e s R e c e i v i n g C o m m a n d . c r e a t e R o o t ( " R e c e i v i n g C o m m a n d " , A N D ) ; / / S t a t e A R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " A " , O R , " R e c e i v i n g C o m m a n d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " I d l e " , B A S I C , " A " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " C o u n t i n g T i m e " , B A S I C , " A " ) ;
/ / S t a t e B R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " B " , O R , " R e c e i v i n g C o m m a n d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g S y n c " , B A S I C , " B " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " C h e c k i n g F i e l d " , O R , " B " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g E x p I d " , B A S I C , " C h e c k i n g F i e l d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g T y p e " , B A S I C , " C h e c k i n g F i e l d " ) ;
… R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " A " , " I d l e " ) ; R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " B " , " W a i t i n g S y n c " ) ; R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " C h e c k i n g F i e l d " , " W a i t i n g E x p i d " ) ; / / E v e n t s R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( " E B 9 " , 1 . 0 ) ;
R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ e i d r c " , 1 . 0 ) ; … R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ c o m m a n d r e c e i v e d " ) ; R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ s t a r t i n g t i m i n g c o u n t i n g " ) ; …
PerformCharts em Testes (cont.)
M a p p i n g t h e M e t h o d o l o g y – S t e p c : F l a t F S M ( o u t p u t ) N O D E L A B E L = R e c e i v i n g C o m m a n d . . . . . L e v e l = 0 . . . . . T y p e = A N D . . . . . * * * R O O T N O D E * * * . . . . . S o n s = A - > B * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * N O D E L A B E L = A . . . . . L e v e l = 1 . . . . . T y p e = O R . . . . . F a t h e r = R e c e i v i n g C o m m a n d . . . . . D e f a u l t = I d l e . . . . . S o n s = I d l e - > C o u n t i n g T i m e * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * N O D E L A B E L = I d l e . . . . . L e v e l = 2 . . . . . T y p e = B A S I C . . . . . F a t h e r = A . . . . . S o n s = * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * *
PerformCharts em Testes (cont.)
M a p p i n g t h e M e t h o d o l o g y – S t e p d : B a s e o f f a c t s ( o u t p u t )
i n i t i a l ( i d l e _ w a i t i n g s y n c ) .
t r a n s ( i d l e _ w a i t i n g s y n c , t r a n s i t i o n 0 , c o u n t i n g t i m e _ w a i t i n g e x p i d , L 0 , L n ) : - r e c e i v e l ( ' E B 9 ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) . … t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d , t r a n s i t i o n 2 , e n d , L 0 , L n ) : - r e c e i v e l ( ' w a i t i n g t i m e e x p i r e d ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) . … t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d , t r a n s i t i o n 3 , c o u n t i n g t i m e _ w a i t i n g t y p e , L 0 , L n ) : - r e c e i v e l ( ‘ e i d r c ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) .
PerformCharts em Testes (cont.)
M a p p i n g t h e M e t h o d o l o g y – S t e p e : T e s t C a s e s ( o u t p u t ) s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )
s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )
s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )
s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , s i z e r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( ) … s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , s i z e r c ) r e c d a t a ( ) s e n d d a t a ( L , d a t a r c ) r e c d a t a ( ) s e n d d a t a ( L , c k s u m r c ) r e c d a t a ( )
P e r f o r mC h a r t sX
ML
S t a t e C h a r t s( H a r e l )
E n t r a d a d aP e r f o r m C h a r t s M E F R e s u l t a d o
I n s t â n c i a P c M L
A p l i c a ç ã o P e r l
A p l i c a ç ã o J a v a
S o u r c ec o d e
S c h e m aP c M L
M o d e l o d os i s t e m a e m
P c M L
p r o g r a m ae m C + +
A v a l i a ç ã od e
D e s e m p e n h o
C a s o sd e
T e s t e
C o n d a d o
M o d e s t o
P e r f o r mC h a r t sX
ML
XML
S t a t e C h a r t s( H a r e l )
E n t r a d a d aP e r f o r m C h a r t s M E F R e s u l t a d o
I n s t â n c i a P c M L
A p l i c a ç ã o P e r l
A p l i c a ç ã o J a v a
S o u r c ec o d e
S c h e m aP c M L
M o d e l o d os i s t e m a e m
P c M L
p r o g r a m ae m C + +
A v a l i a ç ã od e
D e s e m p e n h o
C a s o sd e
T e s t e
C o n d a d o
M o d e s t o
PerformCharts em Testes (cont.)
P c M L S p e c i f i c a t i o n
P e r l S c r i p t C + + P r o g r a m
P e r f o r m C h a r t s
X S L T P a r s e r
F S M ( X M L f o r m a t )
B a s e o f F a c t sC o n d a d oT e s t C a s e s
BibliografiaLee, D.; Yannakakis, M. Testing FiniteState Machines: State Identification and Verification, IEEE Transactions on Computers, 43(3), 1994
Lee, D.; Yannakakis, M. Principles and Methods of Testing Finite State Machines – A Survey. In: Proceedings of the IEEE, 84(8), 1996, pp. 10901123
Martins, E.; Sabião, S.B.; Ambrósio, A.M. ConData: a tool for automating Specificationbased Test Case Generation for Communicating Systems. Software Quality Journal, 8(4), 303319, 1999
Sidhu, D.P.; Leung, T. Formal Methods for Protocol Testing: A Detailed Study, IEEE Transactions on Software Engineering, 15(4), 1989, pp. 413426
Bibliografia (cont.)Beizer, B. Software Testing Techniques. International Thomson Computer Press, 1990.
Binder, R. V. Testing Object-Oriented Systems: Models, Patterns and Tools. Addison Wesley. 1999