Minimizao de Conjuntos de Casos deTeste para Mquinas de Estados Finitos

Lcio Felippe de Mello Neto

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: 19 de maro de 2008

Assinatura:

Minimizao de Conjuntos de Casos de Teste para Mquinas deEstados Finitos

Lcio Felippe de Mello Neto

Orientador: Prof. Dr. Adenilso da Silva Simo

Dissertao apresentada ao Instituto de Cincias Matem-ticas e de Computao ICMC/USP, como parte dos re-quisitos para obteno do ttulo de Mestre em Cincias Cincias de Computao e Matemtica Computacional.

USP - So CarlosMaro/2008

Aos meus pais, Lcio e Marlia.

i

Agradecimentos

ADeus, por me proporcionar uma oportunidade nica e me confortar em todos os momentosda vida.

Aos meus queridos pais, Lcio e Marlia, por me incentivarem e acreditarem em mim emtodos os momentos. Gostaria de agradecer os bons princpios que vocs me ensinaram edizer que sem vocs eu no seria capaz de percorrer essa importante etapa da minha vida.Eu amo vocs.

Ao meu irmo e melhor amigo, Andr, pela amizade e pela ajuda que sempre recebo. Gabriela, pelo amor, compreenso e amizade. muito importante ter a pessoa que amosempre ao meu lado.

Aos meus avs, lvaro e Jorgina, Lcio e Dirce, pelas lies de vida que aprendo a cada dia. A todos os meus familiares, pelo incentivo recebido. Agradeo as oraes por mim e pelaGabriela, pois nos fortaleceram muito diante das dificuldades encontradas.

Ao meu orientador Prof. Dr. Adenilso da Silva Simo, pela confiana demonstrada e pelaorientao deste trabalho. Agradeo os ensinamentos que aprendi com um grande amigo.

Aos amigos do LABES, de So Carlos e de Marlia, pelo apoio e grande amizade: Abe,Alessandra, Andr Endo, Andr Freire, Andr Domingues, Camila, Carlo, Dalcimar, Da-nilo, Edson, Eduardo, Erika, Falco, Felipe, Gambi, caro, Ivan, Jarbas, Ja, Kika, Marco,Marcela, Marcelo Eller, Marcelo Morais, Marlia, Marllos, Matrix, Maycon, Merley, Nardo,Nelson, Otvio, Paula, Paula Herculano, Pedra, Resina, Taty, Tott, Vanessa, Vnia, Valdecir,Vasco, Wladimir e Yamand.

Aos professores do mestrado e da graduao, em especial, Ftima, Maria Istela, Dino,Maldonado, Guilherme, Masiero e Rosely Sanches pela ajuda, confiana e amizade.

Aos funcionrios do ICMC, pelo constante auxlio. A todas as pessoas que contriburam de alguma forma para a realizao deste trabalho. CAPES, pelo apoio financeiro.

iii

Resumo

OTESTE baseado em modelos visa a possibilitar a derivao de con-juntos de casos de teste a partir de especificaes formais, taiscomo Mquinas de Estados Finitos. Os conjuntos de teste po-dem ser obtidos tanto pelos mtodos clssicos de gerao quanto por algumaabordagem ad hoc. Procura-se obter um conjunto de teste que consiga de-tectar todos os possveis defeitos de uma implementao e possua tamanhoreduzido para que a sua aplicao seja factvel. Por questes de ordem pr-tica, pode no ser possvel a aplicao de todo o conjunto de teste gerado.Desse modo, um subconjunto de casos de teste deve ser selecionado, ouseja, uma minimizao do conjunto de teste deve ser realizada. No entanto, fundamental que a minimizao reduza o custo de aplicao dos testes,mas mantenha a efetividade em revelar defeitos. Neste trabalho, prope-seum algoritmo de minimizao de conjuntos de teste para Mquinas de Esta-dos Finitos. O algoritmo baseia-se em condies de suficincia para que acompletude em relao deteco de defeitos seja mantida. O algoritmo foiutilizado em dois diferentes contextos. Utilizou-se o algoritmo com conjun-tos de teste gerados de forma aleatria para verificar a minimizao obtida.O algoritmo tambm foi utilizado para reduzir o esforo em se obter umconjunto completo em relao deteco de defeitos.

v

Abstract

THE Model-based testing aims at generating test suites from formalspecifications, such as Finite State Machines. Test suites can be ob-tained either from classical test derivation methods or from somead-hoc approach. It is desirable to produce a test suite which detects allpossible faults of an implementation and has small size, so that its applica-tion can be feasible. For practical reasons, the application of the generatedtest suite may not be possible. Therefore, a subset of test cases should beselected, i.e., a test suite minimization should be performed. However, it isimportant that the minimization reduces the test application cost, but keepsthe effectiveness in revealing faults. In this work, an algorithm is propo-sed for the minimization of test suites generated from Finite State Machines.The algorithm is based on sufficient conditions, so that test suite complete-ness can be maintained. The algorithm was used in two different contexts.It was used with randomly generated test suites to verify the minimizationobtained. The algorithm was also used to reduce the effort of obtaining atest suite with full fault coverage.

vii

Sumrio

Resumo v

Abstract vii

1 Introduo 11.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Organizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Teste de Software 52.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Tcnicas de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Gerao de Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Minimizao de Conjuntos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Ferramentas de Apoio ao Teste de Programas . . . . . . . . . . . . . . . . . . . . 162.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Teste Baseado em Modelos 193.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Teste Baseado em Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Mquinas de Estados Finitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Teste Baseado em Mquinas de Estados Finitos . . . . . . . . . . . . . . . . . . . 253.5 Mtodos de Gerao de Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.1 Cobertura de Estados e Transies . . . . . . . . . . . . . . . . . . . . . . 263.5.2 Mtodo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.3 Mtodo W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.4 Mtodo Wp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.5 Mtodo HSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5.6 Mtodo State Counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.7 Mtodo HIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.8 Mtodo UIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5.9 Mtodo UIOv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5.10 Mtodo H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

ix

3.6 Comparao entre os Mtodos de Gerao . . . . . . . . . . . . . . . . . . . . . . 363.7 Comparao Emprica entre os Mtodos de Gerao . . . . . . . . . . . . . . . . . 373.8 Completude de Conjuntos de Casos de Teste . . . . . . . . . . . . . . . . . . . . . 383.9 Ferramentas de Apoio ao Teste de Modelos . . . . . . . . . . . . . . . . . . . . . 40

3.9.1 Ferramenta TAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.9.2 Ferramenta Plavis/FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.9.3 Ferramenta MGASet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.9.4 Ferramenta Proteum/FSM . . . . . . . . . . . . . . . . . . . . . . . . . . 423.9.5 Ferramenta ConData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.9.6 Ambiente ATIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.10 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Algoritmo de Minimizao 454.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Condies de Suficincia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Algoritmo de Minimizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1 Seleo do State Cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.2 Verificao dos Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.3 Verificao das Transies . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4 Exemplo de Minimizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5 Reduo ao Problema do Clique . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Limitaes do Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.7 Aspectos de Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.8 Complexidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.9 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Experimentos 615.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Experimento 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3 Experimento 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.1 Nmero de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3.2 Nmero de Sadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.3 Nmero de Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.4 Tamanho de Tadhoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4 Experimento 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5 Experimento 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Concluses 736.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Limitaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.4 Publicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A Detalhes do Cdigo 85A.1 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85A.2 Formatao dos Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

x

Lista de Figuras

2.1 Grafo de Fluxo de Controle do programa Identifier.c. . . . . . . . . . . . . . . . . 102.2 Programa Identifier.c (Maldonado et al., 2004). . . . . . . . . . . . . . . . . . . . 112.3 Grafo Def-Uso do programa Identifier.c. . . . . . . . . . . . . . . . . . . . . . . . 122.4 Exemplo de ordenao de casos de teste (Adaptado de Offutt et al. (1995)). . . . . 15

3.1 MEF para um extrator de comentrios (Chow, 1978). . . . . . . . . . . . . . . . . 213.2 Exemplo de MEF extrado de Dorofeeva et al. (2005a). . . . . . . . . . . . . . . . 273.3 Grafo-Xd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Grafo- e Grafo- reduzido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Defeito de Inicializao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2 Representao de pref(T ) com o grafo 4-partido. . . . . . . . . . . . . . . . . . 564.3 Representao do conjunto de teste por meio de uma rvore. . . . . . . . . . . . . 57

5.1 Conjuntos de Teste T e T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2 Conjuntos de Teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3 Variao de n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.4 Variao de l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.5 Variao de k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.6 Variao de w(Tadhoc). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.7 Representaes da MEF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.1 Campos do n da rvore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86A.2 Representao da MEF no arquivo de entrada. . . . . . . . . . . . . . . . . . . . . 86A.3 Representaes dos conjuntos de teste T e T . . . . . . . . . . . . . . . . . . . . . 87

xi

Lista de Tabelas

3.1 Tabela representativa da MEF do extrator de comentrios. . . . . . . . . . . . . . 223.2 Comparao entre os mtodos de gerao. . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Sumrio dos resultados obtidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2 Exemplos de MEFs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 Sumrio dos resultados obtidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

xiii

xiv

CAPTULO

1Introduo

1.1 Contextualizao

Atualmente, os sistemas de computadores so intensamente utilizados nas atividades da so-ciedade. Como resultado dessa utilizao, encontra-se uma crescente demanda por produtos desoftware. Considerando tambm a grande competitividade existente nos dias atuais, torna-se es-sencial a busca por produtos de software de boa qualidade. Com a utilizao de processos, tcnicase ferramentas, um dos objetivos da Engenharia de Software buscar o aumento da qualidade dessesprodutos de software.

Segundo Pressman (2005), existem diversas categorias de produto de software, tais como soft-ware bsico, sistemas de informao, sistemas cientficos, sistemas embutidos, sistemas pessoais,sistemas de inteligncia artificial e sistemas reativos. Um sistema reativo caracteriza-se por man-ter uma interao permanente com seu ambiente externo, seja esse um usurio, um dispositivo deentrada, uma outra parte do sistema, ou mesmo um outro sistema (Furbach, 1993). Seu compor-tamento baseado na relao entre eventos de entrada e de sada que ocorrem discretamente notempo. Como exemplos desses sistemas, podem-se citar o controle de trfego areo, o controlemetrovirio e o controle de monitoramento hospitalar (Leveson e Stolzy, 1987; Liu e McDermid,1996). Deve-se ressaltar que, mesmo com o uso de mtodos, tcnicas e ferramentas, defeitos po-dem ser introduzidos no produto durante o processo de desenvolvimento de software (Maldonadoet al., 2004). Dessa forma, para que o produto de software, e, em especial, um sistema reativo,atinja um grau aceitvel de qualidade, necessrio que atividades de garantia de qualidade sejamaplicadas durante todo o processo de desenvolvimento de software.

1

2 1.2. MOTIVAO

Dentre as vrias causas para o desenvolvimento de baixa qualidade esto as negligncias co-metidas durante a definio, projeto e codificao, que ocasionam a introduo de defeitos noproduto de software. A utilizao de mtodos mais precisos de desenvolvimento assegura que umaquantidade menor de defeitos seja includa, pois contribui para a reduo de inconsistncias e am-bigidades (Barroca e McDermid, 1992). Com o objetivo de facilitar a especificao do aspectocomportamental de sistemas reativos, vrias tcnicas formais de especificao foram propostas.Essas tcnicas tentam conciliar o poder de modelagem com a capacidade de anlise de proprie-dades do sistema. Dentre as diversas tcnicas utilizadas para a especificao de sistemas reativos,as Mquinas de Estados Finitos (MEFs) (Gill, 1962) se destacam pela simplicidade e poder derepresentao.

A especificao do sistema serve como um guia de desenvolvimento para que, a partir dela,implementaes possam ser construdas e, posteriormente, serem avaliadas quanto a sua corretude.Para realizar tal avaliao, as MEFs tambm so utilizadas para a gerao de conjuntos de casosde teste que possibilitam testar se a implementao est em conformidade com sua respectivaespecificao.

Nesse contexto, vrios mtodos foram propostos para a gerao de um conjunto de casos deteste que possa revelar os possveis erros existentes em uma implementao. Os mtodos para agerao de casos de teste em MEF vm sendo propostos h dcadas, como por exemplo, os mto-dos DS (Gnenc, 1970), W (Chow, 1978), UIO (Sabnani e Dahbura, 1988), UIOv (Vuong et al.,1989), Wp (Fujiwara et al., 1991), HIS (Petrenko et al., 1993) e o HSI (Luo et al., 1995). Maisrecentemente, destacam-se tambm os mtodos H (Dorofeeva et al., 2005b) e o State Counting(Petrenko e Yevtushenko, 2005). Para que cada mtodo seja aplicado, a MEF deve possuir certaspropriedades. Por exemplo, os mtodos W e Wp so aplicados somente s MEFs completas en-quanto os mtodos H e State Counting podem ser aplicados s MEFs parciais. Os mtodos tambmse diferenciam em relao ao custo de execuo do conjunto de casos de teste gerado. Por exem-plo, enquanto o mtodo W gera um nmero elevado de casos de teste que garantem a coberturacompleta de defeitos para MEFs, o mtodo UIO resulta um nmero menor de casos de teste, masque no garantem a cobertura completa de defeitos.

A aplicao dos mtodos torna-se improdutiva quando realizada manualmente e, por isso,existe a necessidade da criao de ferramentas de apoio para a utilizao de tais mtodos. Es-sas ferramentas, tais como a ConData (Martins et al., 1999), a Proteum/FSM (Fabbri et al., 1999),a MGASet (Candolo et al., 2001) e a PLAVIS/FSM (Simo et al., 2005), proporcionam a aplicaodos diferentes mtodos propostos e, conseqentemente, auxiliam a etapa de teste.

1.2 Motivao

Um problema identificado na tentativa de utilizar os mtodos em aplicaes reais a grandequantidade de seqncias de testes geradas que inviabilizam os testes devido ao tempo despen-

CAPTULO 1. INTRODUO 3

dido na aplicao de todos os casos de testes. Ainda pode haver situaes em que um conjuntode teste de alta cardinalidade seja obtido de alguma outra forma. Por exemplo, um conjunto decasos de teste pode ter sido criado com base em outros modelos disponveis, tais como a especifi-cao textual ou diagramas de anlise. Desse modo, questes pragmticas levam a selecionar umaporcentagem dos casos de teste, ou seja, minimizar o conjunto de teste. Contudo, para poder serrealizada de forma adequada, a seleo deve ser feita a partir de critrios bem definidos. Pode-seutilizar como parmetro o interesse em uma parte particular da MEF, selecionando-se, assim, oscasos de teste que passam por essa parte. Ao mesmo tempo em que diminui o custo da aplica-o do teste, a seleo de um subconjunto de casos de teste pode implicar em uma diminuio daefetividade da atividade. Desse modo, para que no haja prejuzos quanto eficincia dos testes,torna-se importante realizar a minimizao de forma a garantir que o conjunto resultante possua amesma capacidade na deteco de defeitos. Em outras palavras, se um conjunto de teste conseguedetectar todos os defeitos de uma implementao (dito ser completo) importante que o conjuntominimizado tambm possua tal caracterstica, ou seja, tambm seja completo.

Outro aspecto interessante seria quanto reduo do esforo para se completar um conjuntode teste, ou seja, tornar esse conjunto capaz de detectar todos os possveis defeitos. Para atingir talobjetivo, a adio de outros casos de teste necessria. Nesse cenrio, seria interessante que essaadio fosse minimizada, ou seja, que poucas seqncias fossem escolhidas para que o conjuntose tornasse completo.

1.3 Objetivos

O objetivo deste trabalho foi a investigao de uma estratgia para a reduo do custo da aplica-o de casos de teste gerados a partir de MEFs. Procurou-se uma forma de minimizar um conjuntode teste, mas garantindo a mesma efetividade na deteco de defeitos. Neste trabalho foi desen-volvido um algoritmo para a minimizao de conjuntos de teste para MEFs. A minimizao foibaseada em condies de suficincia propostas por Dorofeeva et al. (2005b) e por Simo e Petrenko(2007) de forma a manter a efetividade dos testes. Desse modo, o algoritmo de minimizao ob-tm um conjunto minimizado e ao mesmo tempo completo. Foram conduzidos experimentos paraverificar a minimizao obtida em conjuntos de teste e para verificar a reduo do esforo de secompletar conjuntos de teste. Os resultados apontam uma reduo significativa do tamanho dosconjuntos de teste que foram obtidos de forma aleatria. Com relao ao esforo utilizado parase completar um conjunto de teste, os resultados apontam que o algoritmo de minimizao podereduzi-lo em at 50%.

4 1.4. ORGANIZAO

1.4 Organizao

Este trabalho est organizado da seguinte forma. No Captulo 2 so apresentadas as definies,conceitos, tcnicas e ferramentas relacionadas ao teste de software. No Captulo 3 discutem-seas motivaes para o teste baseado em modelos. Apresentam-se tambm os principais conceitossobre MEFs e mtodos de gerao de casos de teste a partir de MEFs, destacando-se as diferen-as entre eles. Em seguida, no Captulo 4, apresentado o algoritmo de minimizao propostoneste trabalho. No Captulo 5 so apresentados os experimentos realizados com o algoritmo deminimizao. Por fim, no Captulo 6, as concluses so apresentadas.

CAPTULO

2Teste de Software

2.1 Consideraes Iniciais

Neste captulo so abordados os conceitos e definies fundamentais relacionadas ao teste desoftware. Na Seo 2.2 discutida a importncia da atividade de teste e os conceitos fundamentaisreferentes ao teste de software so apresentados. Tambm apresentada uma viso geral sobreas tcnicas funcional, estrutural, baseada em erros e baseada em estados. Nas Sees 2.3 e 2.4apresentam-se trabalhos relacionados gerao automtica de casos de teste e minimizao deconjuntos de teste, respectivamente. Em seguida, na Seo 2.5, ferramentas de apoio ao teste desoftware so apresentadas.

2.2 Teste de Software

Durante o desenvolvimento de software, mesmo com a utilizao de ferramentas, mtodose tcnicas, defeitos ainda podem ser inseridos no software. Dessa forma, torna-se importantea existncia de atividades de apoio que procurem minimizar a ocorrncia desses erros. Essasatividades devem ser introduzidas durante todo o processo de desenvolvimento de software, sendoagregadas sob o nome de Garantia de Qualidade de Software (GQS).

Dentre as atividades de GQS, encontram-se as atividades de Verificao, Validao e Teste(VV&T). Segundo Pressman (2005), verificao consiste em atividades que garantem que o soft-ware implementa corretamente uma funo especfica e validao refere-se s atividades que ga-rantem que o software construdo est de acordo com os requisitos do cliente. O teste um conjunto

5

6 2.2. TESTE DE SOFTWARE

de atividades que tem como objetivo encontrar os erros de um programa por meio de sua execuo(Myers, 2004). O teste uma atividade importante, pois permite que erros sejam identificados ecorrigidos antes que o software seja entregue ao usurio final. De acordo com Pressman (2005),no incomum que a atividade de teste corresponda entre 30% e 40% de todo o esforo gasto emum projeto durante o desenvolvimento do software.

A atividade de teste consiste basicamente nas etapas de: planejamento do teste, no qual soformulados quais os testes que sero realizados, ou seja, um plano de teste elaborado; projetodos casos de teste, que consiste na elaborao de um conjunto de casos de teste que atenda oscritrios estabelecidos; execuo do teste, em que o programa executado com os casos de testeanteriormente criados, e, por ltimo, a avaliao dos resultados, que consiste em avaliar as sa-das produzidas pelo teste para que aes posteriores possam ser tomadas. Os testes podem serrealizados em trs fases (Beizer, 1990; Pressman, 2005):

Teste de Unidade: uma unidade pode ser vista como a menor parte (mdulo) testvel de um soft-ware. Nessa fase, o teste realizado na unidade do software. Cada mdulo do software testado separadamente com o objetivo de identificar erros de lgica e de implementao. Porexistir dependncias entre os mdulos do software, torna-se necessria a criao de pseudo-controladores (drivers) e/ou pseudo-controlados (stubs). Os pseudo-controladores tm afuno de controlar o teste do mdulo, ativando-o e fornecendo os dados de teste definidospelo testador. Os pseudo-controlados tm a funo de simular os mdulos que so chamadospelo mdulo sob teste.

Teste de Integrao: a partir das unidades j testadas, o teste de integrao visa a testar as inter-faces entre as unidades, ou seja, tem como objetivo identificar os erros que possam surgir naetapa de integrao das unidades do software. uma etapa importante, pois os erros aindapodem existir mesmo se as unidades foram testadas independentemente. Por exemplo, doismdulos acoplados podem no produzir a funo principal desejada.

Teste de Sistema: com os testes de unidade e integrao j realizados, torna-se necessrio o testepor completo do sistema baseado em computador para assegurar que a funo global dese-jada seja obtida. Nessa fase, o objetivo garantir a funcionalidade correta da combinao dosoftware com os demais elementos do sistema (hardware e banco de dados, por exemplo).

Neste trabalho a atividade de teste ser considerada como uma atividade de anlise dinmica,em contraste a outras formas de se validar um produto sem a sua execuo como, por exemplo,as verificaes formais, tais como o model checking. Desse modo, o programa deve ser executadocom os casos de teste e os resultados so analisados posteriormente (Weyuker, 1986).

No contexto deste trabalho, importante definir a terminologia utilizada para os termos de-feito, erro e falha. O padro IEEE 610.12-1990 (IEEE, 1990) diferencia os termos: defeito(fault): passo, processo ou definio de dados incorretos; erro (error): diferena entre o valor

CAPTULO 2. TESTE DE SOFTWARE 7

obtido e o valor esperado, ou seja, qualquer estado interno que diverge do estado esperado; e falha(failure): produo de uma sada incorreta com relao especificao. Os termos erro e de-feito sero utilizados como sinnimos para indicar uma causa. O termo falha utilizado paraindicar uma manifestao externa de um erro, ou seja, uma conseqncia.

Pela observao do resultado obtido a partir da execuo de um programa com um caso deteste, possvel verificar se houve falhas e, conseqentemente, se o programa possui um defeito.Desse modo, a atividade de teste tem como objetivo revelar o defeito, enquanto que a atividade dedepurao responsvel por rastrear e encontrar tal defeito.

Para os testes serem realizados, casos de teste devem ser projetados. Os casos de teste so oselementos do domnio de entrada D de um programa P . Seja S a especificao do programa P ex D um elemento do domnio de entrada. S(x) representa o resultado da especificao S com aentrada x. Um caso de teste um par ordenado (d, S(d)), tal que d um elemento do domnio deentrada D e S(d) a sada esperada de acordo com a especificao, utilizando o elemento d comoentrada. Para verificar se a sada produzida por uma implementao est em conformidade coma sada esperada (especificao), um orculo deve existir. Segundo Howden (1978), um orculopode ser uma tabela de valores, um algoritmo ou simplesmente o conhecimento do programadorem reconhecer a sada correta de um programa.

O cenrio ideal para verificar se o programa est de acordo com a sua especificao, seriaaquele em que todos os elementos do domnio de entrada D de um programa P fossem utilizadosna atividade de teste. Contudo, isso geralmente impraticvel, pois o domnio de entrada podeser extremamente grande, ou mesmo infinito (Rapps e Weyuker, 1985). Dessa forma, torna-seimportante e necessrio realizar a seleo de um subconjunto finito dos casos de teste.

Para se obter subconjuntos dos casos de teste, critrios de teste so definidos. Os critrios deteste estabelecem requisitos de teste a serem cumpridos e so diretrizes que auxiliam o testadora estabelecer um subconjunto (relativamente pequeno) T do domnio de entrada D. Um critriode teste um mtodo utilizado tanto para a avaliao de um conjunto de casos de teste quantopara a construo dos mesmos (Frankl e Weyuker, 2000). Nota-se a importncia da definio doscritrios de teste para realizar uma seleo de casos de teste que aumentem as chances em revelardefeitos para estabelecer-se um bom nvel de confiana na correo do programa.

Os critrios de teste podem ser divididos basicamente em quatro tcnicas: funcional, estrutural,baseada em erros e baseada em estados. De acordo com Simo (2004), alguns critrios no seenquadram adequadamente em nenhum dos quatro grupos citados, como o caso dos critrios deteste exaustivo e de teste aleatrio. O teste exaustivo consiste na execuo do programa com todoo domnio de entrada, ou seja, o conjunto dos casos de teste T o prprio domnio de entrada D(T = D). Geralmente, o teste exaustivo impraticvel, pois, mesmo para programas pequenos, odomnio de entrada pode ser infinito. O teste exaustivo deve ser considerado, quando possvel, seo custo de sua execuo for menor que o custo resultante da ocorrncia de uma falha. J o testealeatrio consiste na seleo aleatria de um conjunto T (T D). O teste aleatrio realizado deforma sistemtica considerando-se as caractersticas do domnio e a probabilidade de cada entrada.

8 2.2. TESTE DE SOFTWARE

2.2.1 Tcnicas de Teste

Como citado anteriormente, os critrios podem ser agrupados em quatro tcnicas: funcional,estrutural, baseada em erros e baseada em estados. A diferena existente entre essas tcnicasrefere-se origem da informao utilizada na construo e na avaliao dos conjuntos de casos deteste (Maldonado, 1991). Essas tcnicas se complementam e devem ser utilizadas em conjunto,pois provavelmente revelam classes diferentes de erros (Pressman, 2005).

Teste Funcional

O teste funcional, tambm conhecido como teste caixa-preta, consiste no teste de um programaconsiderando-o como uma caixa em que apenas os dados de entrada e as sadas produzidas podemser visualizados. Os casos de teste so derivados a partir da especificao do software com o intuitode que as suas funcionalidades sejam verificadas, sem considerar os aspectos de implementao.Para identificar as funcionalidades que o programa deve realizar, casos de teste so criados.

A especificao do software muito importante, pois essencialmente o documento em queo teste funcional se baseia para a gerao dos casos de teste. Desse modo, importante que aespecificao seja consistente quanto aos requisitos do usurio final. Caso contrrio, os testessero improdutivos. Alguns exemplos de critrios da tcnica de teste funcional so apresentados aseguir.

Particionamento em Classe de Equivalncia: o critrio particionamento em classe de equiva-lncia divide o domnio de entrada de um programa em um nmero finito de classes dedados vlidas (entradas vlidas para o programa) e invlidas (demais entradas). A partirdessa diviso, os casos de teste so derivados com a suposio de que um teste realizadocom um caso de teste de uma classe seja equivalente ao teste realizado com qualquer outrocaso de teste da mesma classe, ou seja, um elemento de uma classe revela os mesmos errosque qualquer outro elemento dessa mesma classe revelaria. Desse modo, um nmero menorde casos de teste selecionado da seguinte forma: seleciona-se um caso de teste distintopara cada classe invlida e um conjunto mnimo de casos de teste representativos das classesvlidas.

Anlise do valor limite: o critrio de anlise do valor limite consiste em uma extenso ao parti-cionamento em classe de equivalncia, pois os elementos que se encontram nos limites dasclasses so selecionados. Em vez de selecionar os elementos do interior da classe, os ele-mentos que se concentram nas fronteiras das classes so escolhidos, pois os erros tendema ocorrer nesses pontos (Pressman, 2005). As sadas tambm so particionadas em classes ecasos de teste so selecionados para resultar em valores que esto nos limites dessas classes.

Grafo de causa-efeito: o critrio grafo de causa-efeito considera as condies dos dados de en-trada. As condies de entradas (causas) e as aes (efeitos) so identificadas para a cons-

CAPTULO 2. TESTE DE SOFTWARE 9

truo de um grafo. Uma tabela de deciso montada, a partir do grafo, para a posteriorderivao dos casos de teste.

Teste Estrutural

O teste estrutural, tambm conhecido como teste caixa-branca, utiliza a estrutura interna doprograma para a derivao dos casos de teste. Desse modo, as caractersticas de implementaodevem ser conhecidas. Devido natureza dos erros existentes em um programa, o teste estrutural visto como complementar ao teste funcional. Geralmente, os critrios de teste estrutural utilizamuma representao de programa conhecida como grafo de fluxo de controle (ou grafo de programa).Nesse grafo, o fluxo de controle lgico do programa ilustrado com a utilizao de uma notaosimples, composta de arcos e ns (Pressman, 2005).

O grafo de fluxo de controle construdo de forma que seus ns representem os blocos dosprogramas e seus arcos representem os possveis fluxos de controle entre esses blocos (Zhu et al.,1997). Um bloco um conjunto de comandos de um programa que sempre so executados deforma seqencial, ou seja, quando o primeiro comando do bloco executado, todos os comandosrestantes (do mesmo bloco) so tambm executados. Os arcos, que representam os possveis des-vios de controle, conectam os ns. Assim, a ligao entre os blocos ocorre no incio ou no fimde um bloco. Na Figura 2.1 ilustrado um grafo de fluxo de controle gerado a partir do cdigoda funo main do programa Identifier.c (Figura 2.2). O programa Identifier.c, extrado de (Mal-donado et al., 2004), realiza a validao de identificadores. Um identificador vlido deve comearcom uma letra e conter apenas letras ou dgitos. Alm disso, deve ter no mnimo um caractere e nomximo seis caracteres de comprimento.

O n correpondente ao bloco que possui o primeiro comando do programa denominado den inicial e o n correspondente ao bloco que possui o comando final do programa denominadon final. Um caminho corresponde a uma seqncia finita de ns (n1, n2, . . . , nk) onde k 2,tal que exista um arco de ni para ni+1 para i = 1, 2, . . . , k 1. Um caminho livre de laoquando todos os ns que o compem so distintos. Um caminho completo quando comea apartir do n inicial e vai at o n final do grafo. Um caminho no executvel um caminho noqual no existe nenhum elemento do domnio de entrada que o cubra. Com a construo do grafode fluxo de controle pode-se escolher os caminhos que sero executados a partir dos critrios deteste estrutural.

Na Figura 2.1, o n inicial corresponde ao n de nmero 1 e o n final corresponde ao nde nmero 11. O bloco referente ao n de nmero 8 possui apenas a expresso if(valid_id&& (length >=1) && (length

10 2.2. TESTE DE SOFTWARE

1

3

4

5

7

8

11109

6

2

Figura 2.1: Grafo de Fluxo de Controle do programa Identifier.c.

Os critrios de teste estrutural so agrupados em duas categorias: critrios baseados em fluxode controle e critrios baseados em fluxo de dados.

Critrios Baseados em Fluxo de Controle Os critrios de teste baseados em fluxo decontrole utilizam os aspectos do controle da execuo do programa (pelo grafo do programa) paraderivar os casos de teste. Os critrios mais conhecidos so:

Critrio Todos-Ns: exige que cada n do grafo do programa seja executado ao menos uma vez.

Critrio Todos-Arcos: exige que cada arco seja exercitado (percorrido) ao menos uma vez.

Critrio Todos-Caminhos: exige que cada possvel caminho do grafo seja exercitado. Geral-mente impraticvel, pois o grafo pode conter laos, fazendo com que a quantidade decaminhos existente seja infinita.

Critrios Baseados em Fluxo de Dados Nos critrios de teste baseados em fluxo de da-dos, os dados tambm so considerados. Dessa forma, consideram-se as definies e os usos dasvariveis durante a execuo do programa. Para isso, adiciona-se ao grafo de fluxo de controleinformaes referentes aos dados do programa. Esse grafo chamado de grafo Def-Uso (Rapps eWeyuker, 1982). Uma definio de varivel acontece quando atribui-se um valor a uma varivel.Um uso ocorre quando o seu valor referenciado em uma computao (uso computacional) ouem uma condio de desvio (uso predicativo). Na Figura 2.3 ilustrado um grafo Def-Uso doprograma Identifier.c (Figura 2.2). Por exemplo, os ns 1 e 2 possuem uma definio da varivel

CAPTULO 2. TESTE DE SOFTWARE 11

/****************************************************************************************Identifier.cESPECIFICAO: O programa deve determinar se um identificador ou no vlido em SillyPascal (uma estranha variante do Pascal). Um identificador vlido deve comear com umaletra e conter apenas letras ou dgitos. Alm disso, deve ter no mnimo 1 caractere e nomximo 6 caracteres de comprimento

****************************************************************************************/

#include main ()

/* 1 */ {/* 1 */ char achar;/* 1 */ int length, valid_id;/* 1 */ length = 0;/* 1 */ valid_id = 1;/* 1 */ printf ("Identificador: ");/* 1 */ achar = fgetc (stdin);/* 1 */ valid_id = valid_s(achar);/* 1 */ if(valid_id)/* 2 */ {/* 2 */ length = 1;/* 2 */ }/* 3 */ achar = fgetc (stdin);/* 4 */ while(achar != \n)/* 5 */ {/* 5 */ if(!(valid_f(achar)))/* 6 */ {/* 6 */ valid_id = 0;/* 6 */ }/* 7 */ length++;/* 7 */ achar = fgetc (stdin);/* 7 */ }/* 8 */ if(valid_id && (length >=1) &&

(length = A) &&

(ch = a) &&(ch = A) &&

(ch = a) &&(ch = 0) &&(ch

12 2.2. TESTE DE SOFTWARE

1

3

4

5

7

8

11109

6

2

d = {length, valid_id, achar}uc = {achar}up = {valid_id}

d = {achar}d = definioup = uso predicativouc = uso computacional

up = {valid_id}d = {length}

up = {achar}

up = {achar}

up = {achar}

up = {achar}

up = {achar}

d = {valid_id}

up = {valid_id,length}up = {valid_id,length}

uc = {length}d = {length,achar}

Figura 2.3: Grafo Def-Uso do programa Identifier.c.

Teste Baseado em Erros

O teste baseado em erros consiste na utilizao de informaes sobre os erros que podemexistir em um programa para a derivao dos casos de teste. Essas informaes geralmente variamdevido s caractersticas da linguagem de programao, mtodo ou tcnica utilizada ao longo dodesenvolvimento do software. A seguir, alguns critrios baseados em erros so apresentados.

Teste Algbrico de Defeitos O teste algbrico de defeitos, apresentado por Morell (1990),consiste em verificar quais programas no podem estar corretos a partir de um caso de teste jexecutado. Dessa forma, aps a execuo de um caso de teste, verificam-se quais programasalternativos poderiam estar corretos em relao ao programa original.

Semeadura de Erros A Semeadura de Erros (Error Seeding) foi proposta originalmente paraestimar o nmero de erros remanescentes em um software. Por esse critrio, realiza-se a introduode uma quantidade conhecida de erros artificiais no software, sob teste, de forma aleatria e semo conhecimento do testador. Em seguida, o software testado e os erros artificiais e naturaisrevelados so contabilizados separadamente. Uma indicao dos erros naturais ainda existentes noprograma estaticamente prevista com probabilidade mxima de ser f/r, onde f a quantidadede erros naturais encontrados no teste e r a taxa de erros artificiais encontrados em relao aototal de erros artificiais introduzidos. Segundo Zhu et al. (1997), um dos problemas da semeadurade erros que, geralmente, os erros artificiais so mais fceis de serem encontrados em relao aoserros naturais e portanto, a validade estatstica do mtodo questionvel.

CAPTULO 2. TESTE DE SOFTWARE 13

Anlise de Mutantes No teste de um programa P , o critrio Anlise de Mutantes (MutationAnalysis) consiste na gerao de programas semelhantes (mutantes) a partir de P . Um erro introduzido em cada programa mutante e os casos de teste so gerados para serem executados comP e com os seus mutantes. Os resultados da execuo dos programas mutantes so comparadoscom os resultados obtidos pelo programa P . O objetivo encontrar um conjunto de casos de testeque seja capaz de revelar os defeitos, ou seja, as diferenas entre o programa P e seus mutantes.

Teste Baseado em Estados

No teste baseado em estados, uma representao baseada em mquina de estados utilizadapara modelar o aspecto comportamental do sistema ou unidade que ser testada. Uma mquinade estados um modelo que representa o comportamento do sistema na forma de estados que elepossui durante a sua existncia e as possveis transies entre esses estados. A partir desse modelo,mtodos de gerao de seqncias de teste (descritos na Seo 3.5) podem ser utilizados para veri-ficar se o comportamento do sistema est de acordo com o comportamento do modelo. No contextode orientao a objetos, o teste baseado em estados utilizado devido prpria caracterstica dosobjetos que possuem estados e comportamento. A classe modelada como uma mquina de esta-dos e as chamadas aos mtodos resultam em transies de estados. O modelo define as transiespermitidas e os casos de teste so derivados para exercitar cada transio. Segundo Binder (1999),o teste baseado em estados adequado para o teste de sistemas orientados a objeto, pois uma m-quina de estados pode fornecer uma forma compacta e previsvel do comportamento da classe. Asmquinas de estados podem modelar o sistema em diferentes nveis, tais como: classe, subsistemae sistema, o que permite a realizao do teste nesses diferentes nveis. O teste baseado em estadosno detecta todos os tipos de erros sendo importante que outros critrios sejam incorporados, taiscomo o critrio de fluxo de dados e controle, para a obteno de um teste de melhor qualidade(Binder, 1999).

No Captulo 3 ser apresentado o teste baseado em modelos, no qual se insere o teste baseadoem estados.

2.3 Gerao de Casos de Teste

Durante a atividade de teste, os casos de teste so utilizados para revelar os erros de um pro-grama. Desse modo, a gerao dos casos de teste uma etapa importante e essencial para a prpriarealizao da atividade de teste e tem como objetivo identificar um conjunto de dados de entrada deum programa que satisfaa um determinado critrio de teste (Korel, 1990). importante que essaetapa seja automatizada de forma a auxiliar o testador e agilizar a atividade de teste. No entanto,existem limitaes inerentes prpria atividade de teste que dificultam a gerao de casos de teste(Harrold, 2000). Por exemplo, no possvel decidir se dois programas so equivalentes ou se um

14 2.3. GERAO DE CASOS DE TESTE

determinado caminho de um programa executvel. Trabalhos relacionados gerao automticade casos de teste procuram, por meio de heursticas, contornar essas limitaes.

Um mtodo dinmico de gerao de dados de teste proposto por Korel (1990). Esse mtodo baseado na execuo do programa sob teste, anlise dinmica de fluxo de dados e mtodos defuno de minimizao. O fluxo de execuo do programa monitorado durante sua execuocom alguns dados de entrada.

No trabalho de DeMillo e Offutt (1991), apresentada uma tcnica baseada na anlise demutantes que utiliza restries para gerar casos de teste que so projetados especificamente paramatar os mutantes do programa. Um conjunto de restries gerado para cada mutante e um casode teste selecionado se satisfizer esse conjunto.

No trabalho de Bueno e Jino (2001), a gerao de casos de teste feita com a utilizao dealgoritmos genticos para identificar uma entrada que execute um caminho do programa. Por meiode uma funo de fitness, ocorre a combinao, eliminao ou favorecimento de elementos deentrada para que exista maior probabilidade de execuo de um determinado caminho.

No trabalho de Simo (2004), a gerao de casos de teste realizada com base na anlisede mutantes. Foi proposto um algoritmo para a gerao automtica de casos de teste e para aidentificao automtica de mutantes equivalentes no contexto das Redes de Petri. Os mutantesso executados com um conjunto de teste. verificado se os mutantes vivos so equivalentes aoproduto original. Os mutantes equivalentes so descartados. Os mutantes no equivalentes soanalisados e novos casos de teste so gerados para matar tais mutantes. Esses casos de teste devemser adicionados ao conjunto de teste. Segundo Simo (2004), houve uma reduo significativa donmero de mutantes a serem analisados manualmente, reduzindo a necessidade de interao dotestador.

O mtodo proposto no trabalho de Fraser e Wotawa (2006) utiliza o model-checking para au-tomatizar a gerao e anlise dos casos de teste baseado em mutao. A partir do modelo com-portamental do sistema e da especificao dos requisitos, mutantes so utilizados para a criaodos casos de teste com o objetivo de checar os possveis erros da implementao que violam aespecificao. Mutaes geradas a partir do modelo introduzem um comportamento errneo. Seesse comportamento inconsistente com o comportamento definido pela especificao, ele podeser detectado pela execuo de um model-checker com o modelo mutante e a especificao. Nessafase, casos de teste so gerados. A mutao gerada a partir da especificao permite que algumasde suas partes sejam alteradas ou removidas, fazendo com que o seu comportamento no seja cum-prido pelo modelo, o que permite a gerao de casos de teste. Casos de teste gerados a partir demutaes do modelo checam os possveis erros da implementao que no esto de acordo coma especificao. J os casos de teste gerados a partir de mutaes da especificao mostram se ocomportamento correto tem sido implementado.

CAPTULO 2. TESTE DE SOFTWARE 15

2.4 Minimizao de Conjuntos de Teste

Casos de teste so utilizados para revelar os erros de um programa. Um conjunto de casos deteste deve ser aplicado em um programa sob teste para verificar a conformidade entre implemen-tao e especificao. A aplicao de todos os casos de teste de um conjunto pode ser inviveldevido a sua alta cardinalidade. Dessa forma, torna-se importante a investigao de critrios paraminimizar o conjunto de teste e, conseqentemente, viabilizar a etapa de teste. importante sali-entar que a minimizao do conjunto de teste deve ser realizada sem que a efetividade na detecode defeitos seja afetada. Desse modo, a minimizao no afeta a qualidade dos testes. A seguir,apresentam-se trabalhos que procuram minimizar conjuntos de casos de teste.

No trabalho de Offutt et al. (1995) so propostas estratgias para a seleo de ummenor nmerode casos de teste pela reordenao dos conjuntos de teste no contexto de teste de mutao. Foiobservado que para os conjuntos de teste baseados em mutao a ordem de aplicao dos casos deteste teve impacto no tamanho do conjunto de teste obtido. Por exemplo, considere a Figura 2.4.Se os casos de teste so aplicados na ordem dada < 1, 2, 3 >, ento os trs casos de teste sonecessrios para cobrir os quatro trechos de cdigo. Porm, se os casos de teste so aplicadosna ordem < 3, 2, 1 >, ento apenas os casos de teste 3 e 2 so necessrios para cobrir os quatrotrechos de cdigo. Os autores utilizaram algumas heursticas para a ordenao dos conjuntos deteste.

if (x > 0) thenTrecho_1;

elseTrecho_2;

end if;if (y > 0) then

Trecho_3;else

Trecho_4;end if;

Caso de Teste 1: x = -1 e y = 5 (Executa Trecho_2 e Trecho_3)Caso de Teste 2: x = 5 e y = 5 (Executa Trecho_1 e Trecho_3)Caso de Teste 3: x = -1 e y = -1 (Executa Trecho_2 e Trecho_4)

Figura 2.4: Exemplo de ordenao de casos de teste (Adaptado de Offutt et al. (1995)).

No trabalho de Yevtushenko et al. (1998), os autores propuseram um mtodo de minimizaode conjuntos de teste para MEFs em relao ao teste de contexto. No teste de contexto apenasuma parte do sistema precisa ser testada. Assim, a especificao do sistema representada pelacombinao de duas MEFs. Enquanto uma MEF, chamada de componente, representa a parte quenecessita ser testada, a outra MEF, chamada de contexto, representa a parte que est correta. Osautores relatam que os mtodos clssicos de gerao de casos de teste (Seo 3.5), quando apli-cados nessa combinao de MEFs, produzem um conjunto com vrios casos de teste redundantes.Isso ocorre, pois os mtodos de gerao assumem o sistema sob teste como uma caixa pretae geram casos de teste para testar tanto o componente quanto o contexto (desnecessariamente).Dessa forma, os autores definiram um mtodo para retirar os casos de teste que checam apenas astransies que no afetam o componente. Assim, considerando que o contexto seja livre de defei-

16 2.5. FERRAMENTAS DE APOIO AO TESTE DE PROGRAMAS

tos, a minimizao do conjunto de teste realizada sem que a efetividade na deteco de defeitosseja afetada. Uma extenso da minimizao de conjuntos de teste para MEFs proposta no tra-balho de Yevtushenko et al. (1999). Os autores estenderam o mtodo de minimizao para MEFsno-determinsticas.

2.5 Ferramentas de Apoio ao Teste de Programas

A utilizao de ferramentas de apoio torna-se essencial para que a atividade de teste seja auto-matizada. Nessa atividade, critrios devem ser aplicados e a aplicao realizada de forma manualtorna-se propensa a erros e limitada a produtos simples (Horgan e Mathur, 1992). Nesse contexto,a criao e utilizao de ferramentas de teste tornam-se importantes para viabilizar a atividade deteste e aumentar sua produtividade. As ferramentas de teste permitem a aplicao de tcnicas ecritrios de teste, o apoio a estudos empricos e a transferncia de tecnologia para a indstria. Noentanto, h algumas dificuldades na utilizao concorrente de mais de uma ferramenta de apoiodevido s diferenas existentes entre elas (Horgan e Mathur, 1992). Por exemplo, uma dificul-dade est na diferena existente no formato do arquivo dos casos de teste, sendo que um mesmoconjunto de casos de teste deve ser codificado de diferentes formas para funcionar em diferentesferramentas.

Diversas ferramentas de teste tm sido elaboradas. Dentre as ferramentas existentes podem-secitar: a Proteum (Delamaro, 1993) e a Mothra (DeMillo, 1991) que fornecem apoio ao teste demutao; a PokeTool (Chaim, 1991; Maldonado et al., 1989) e a Asset (Frankl e Weyuker, 1985)para apoio ao teste estrutural; a JaBUTi (Vincenzi et al., 2003; Vincenzi, 2004) que apoia o testeestrutural de programas e componentes Java; e a SPACES (Barbosa et al., 2004) que apoia o testefuncional de componentes. A seguir so apresentadas algumas ferramentas relacionadas ao testede programas.

A ferramenta Proteum (Delamaro, 1993) foi desenvolvida no ICMC/USP e apia o teste demutao para programas escritos na linguagem C. Pela aplicao do critrio Anlise de Mutantes,a ferramenta oferece recursos tanto para avaliar a adequao de um conjunto de casos de testequanto para a sua seleo. Esses recursos permitem que as seguintes operaes sejam realizadas:definio de casos de teste, execuo do programa em teste, seleo dos operadores de mutao(utilizados para gerar os mutantes), gerao dos mutantes, execuo dos mutantes com os casos deteste definidos, anlise dos mutantes vivos e clculo do escore de mutao.

A ferramenta PokeTool (Potential Uses Criteria Tool for Program Testing) (Chaim, 1991) cri-ada no DCA/FEEC/UNICAMP com a colaborao do ICMC/USP, apia a aplicao dos critriosPotenciais-Usos bem como a aplicao de critrios estruturais como Todos-Ns e Todos-Arcos.Essa ferramenta apia o teste de programas escritos na linguagem C e, posteriormente, foi in-crementada para atender programas escritos em COBOL (Leito, 1992) e FORTRAN (Fonseca,1993).

CAPTULO 2. TESTE DE SOFTWARE 17

A ferramenta Asset (A System to Select and Evaluate Tests) foi desenvolvida por Frankl eWeyu-ker (1985) na New York University. Ela uma ferramenta que permite a aplicao dos critrios deteste baseados em fluxo de dados para programas escritos na linguagem Pascal.

A ferramentaMothra (DeMillo, 1991), desenvolvida na Purdue University e no Georgia Insti-tute of Technology apia o teste de programas escritos na linguagem FORTRAN-77. Ela forneceapoio ao critrio Anlise de Mutantes para o teste de programas permitindo ao usurio criar e alte-rar os casos de teste, monitorar o andamento do teste, localizar e remover os erros e extrair dadosestatsticos.

No contexto de orientao a objetos, a ferramenta JaBUTi (Java Bytecode Understanding andTesting) (Vincenzi et al., 2003; Vincenzi, 2004) criada no ICMC/USP, apia o teste de programase componentes escritos em Java. Tem como objetivo ser um ambiente completo para o teste deprogramas Java. A ferramenta permite a aplicao de quatro critrios de fluxo de dados e quatrocritrios de fluxo de controle. Uma das vantagens dessa ferramenta consiste na realizao do testea partir do bytecode Java, ou seja, do arquivo .class do programa. Dessa forma, o cdigo-fonteno necessrio para a conduo do teste, sendo que componentes de terceiros podem ser testadossem a necessidade de ter o cdigo-fonte em mos. A ferramenta completamente implementadaem Java e possibilita a interao por meio de scripts ou pela interface grfica.

A ferramenta SPACES (Barbosa et al., 2004) foi desenvolvida para apoiar o teste funcional decomponentes, realizando a gerao, execuo e anlise dos resultados do teste. Ela possui cincomdulos: Seletor de Casos de Teste, que permite a seleo dos casos de teste a serem executados;Gerador de Orculos, que consiste na gerao de orculos para cada caso de teste; Seletor deDados de Teste, que determina os valores de entrada para os casos de teste; Gerador de Cdigo deTeste, que consiste na criao de classes de teste JUnit; e Empacotador que agrupa todas as classesde teste geradas formando um outro componente que torna-se responsvel pela execuo e anlisedos casos de teste.

2.6 Consideraes Finais

Neste captulo foram apresentados os conceitos, as tcnicas e ferramentas sobre o teste desoftware e uma viso geral sobre sua importncia no processo de desenvolvimento de software.

Foi observado que, apesar de diversos mtodos que auxiliam o processo de desenvolvimentodo software, erros ainda podem existir no software final. Desse modo, a atividade de teste de fundamental importncia para auxiliar no aumento da qualidade do software. Verificou-se aimportncia dos critrios de teste para a seleo de um subconjunto de casos de teste, pois, decerta forma, auxiliam o testador permitindo que a atividade de teste seja factvel.

A atividade de teste pode ser apoiada por ferramentas de teste para que seja realizada commaioragilidade. Foram apresentadas algumas ferramentas tanto para o teste de programas quanto parao teste de especificaes. No contexto de automatizao da atividade de teste, foram apresentados

18 2.6. CONSIDERAES FINAIS

alguns trabalhos sobre a gerao de casos de teste. A minimizao de conjuntos de casos de testetambm foi abordada. Observou-se que a minimizao deve ser conduzida de forma a manter aefetividade do conjunto de casos de teste em relao deteco de defeitos.

O teste baseado em modelos assunto do captulo a seguir. Maior nfase ser dada em relaos caractersticas referente ao teste baseado em MEFs, contexto no qual este trabalho se insere.

CAPTULO

3Teste Baseado em Modelos

3.1 Consideraes Iniciais

Neste captulo so abordados os conceitos, definies e mtodos de gerao de casos de testerelacionados ao teste baseado em modelos. Inicialmente, na Seo 3.2 discutida a importnciada modelagem no contexto do teste baseado em modelos. Apresenta-se tambm a importncia dautilizao dos mtodos formais para a especificao do aspecto comportamental de um sistema,bem como algumas tcnicas de especificao de sistemas. Em seguida, por estar diretamente rela-cionada com este trabalho, a tcnica de Mquina de Estados Finitos apresentada de forma maisdetalhada e formal na Seo 3.3. Na Seo 3.4 so apresentadas as caractersticas relacionadas aoteste baseado em Mquinas de Estados Finitos. Na Seo 3.5, os mtodos para a gerao de casosde teste para Mquinas de Estados Finitos so descritos. So apresentadas as caractersticas decada mtodo para a gerao de casos de teste. Na Seo 3.6 realizada uma comparao entre osmtodos de gerao. Na Seo 3.7, uma comparao emprica entre alguns mtodos ilustrada e,na Seo 3.8, a completude de conjuntos de casos de teste abordada. Por fim, na Seo 3.9 soapresentadas as ferramentas de apoio relacionadas ao teste de modelos.

3.2 Teste Baseado em Modelos

O teste de software uma etapa importante do processo de desenvolvimento de software quevisa a encontrar os possveis erros de uma implementao obtida a partir de uma especificao,seja ela formal ou no. Durante a realizao dos testes, um grande obstculo determinar exata-mente qual o objetivo do teste. Em geral, especificaes no rigorosas deixam grande margem a

19

20 3.2. TESTE BASEADO EM MODELOS

opinies e especulaes. A forma da especificao pode variar de um grafo de fluxos de chamadasinter-mdulos a um guia de usurio. Uma especificao clara importante para definir o escopodo trabalho de desenvolvimento e, de forma especial, o de teste. Se a nica definio precisa doque o sistema deve fazer o prprio sistema, os testes podem ser improdutivos.

Desse modo, a correta modelagem do sistema torna-se importante, permitindo que o conhe-cimento do sistema seja reutilizado durante diversas fases de desenvolvimento. No teste baseadoem modelos, o modelo permite que casos de teste sejam derivados para serem utilizados no testede uma implementao. A correta modelagem de um sistema torna-se mais crtica quando essesistema opera em situaes de risco vida ou ao patrimnio, que pode ser o caso dos SistemasReativos.

Os Sistemas Reativos so sistemas que possuem a caracterstica de interao contnua com oambiente, em resposta a eventos externos. Geralmente, esses sistemas controlam atividades crti-cas, sendo fundamental que a atividade de teste seja realizada de forma adequada para asseguraro comportamento esperado do sistema. O comportamento de um Sistema Reativo um conjuntode seqncias permitidas de eventos de entrada e sada, condies e aes, bem como algumasinformaes adicionais (restries de tempo, por exemplo). Existem diversas tcnicas que forne-cem apoio para a especificao do comportamento de Sistemas Reativos. O comportamento de umsistema, por exemplo, pode ser modelado por meio da linguagem natural durante a etapa de especi-ficao de requisitos. No entanto, a documentao resultante tende a ser ambgua e inconsistente,devido ambigidade existente na linguagem natural (Wing, 1990).

Tratando-se de Sistemas Reativos, essencial uma maior preciso e rigor na especificao dosistema. Nesse cenrio, a utilizao de mtodos formais para a especificao do comportamentode sistemas torna-se importante, pois auxilia na reduo de possveis erros (Barroca e McDermid,1992). Segundo Wing (1990), os mtodos formais so utilizados para a especificao do aspectocomportamental do sistema, entretanto, podem ser utilizados em qualquer estgio do desenvolvi-mento.

H diversas tcnicas para a especificao de sistemas que so utilizadas para agregar maiorrigor ao teste baseado em modelos, tais como Mquinas de Estados Finitos (MEFs), MEFs esten-didas, Statecharts e Redes de Petri. O modelo mais simples so as MEFs. Uma MEF compostapor estados e transies entre os estados. Suas configuraes e transies so representadas expli-citamente. A MEF estendida adiciona s MEFs tradicionais conceitos como variveis de contextoe transies parametrizadas. Uma configurao particular do sistema no mais explicitamente re-presentada no modelo. Em vez disso, uma configurao ser composta pelo estado atual da MEF eos valores das variveis de contexto. Os Statecharts, criados por Harel (1987), constituem uma ex-tenso das MEFs com a adio de caractersticas de decomposio, ortogonalidade e broadcasting.Desse modo, a especificao pode ser construda de forma modularizada, h uma independnciados subestados e a concorrncia pode ser modelada. As Redes de Petri (Peterson, 1977) so mo-delos formais do fluxo da informao e foram inicialmente desenvolvidas para a modelagem desistemas com interao de componentes concorrentes e paralelos (Peterson, 1977). As Redes de

CAPTULO 3. TESTE BASEADO EM MODELOS 21

Petri so representadas como um grafo que modela as propriedades estticas do sistema. Alm daspropriedades estticas, a Rede de Petri possui propriedades dinmicas que so representadas pelasimulao do grafo.

Em seguida, por estar diretamente relacionada com este trabalho, a tcnica de MEF apresen-tada mais detalhadamente.

3.3 Mquinas de Estados Finitos

Uma Mquina de Estados Finitos (MEF) (Gill, 1962) uma mquina hipottica composta porestados e transies. Cada transio liga um estado a a um estado b (a e b podem ser o mesmoestado). A cada instante, uma mquina pode estar em apenas um de seus estados. Em respostaa um evento de entrada, a mquina gera um evento de sada e muda de estado. Tanto o eventode sada gerado quanto o novo estado so definidos unicamente em funo do estado atual e doevento de entrada (Davis, 1988). Uma MEF pode ser representada tanto por um diagrama detransio de estados quanto por uma tabela de transio. Em um diagrama de transio de estados,os estados so representados por crculos e as transies so representadas por arcos direcionadosentre estados. Na Figura 3.1 tem-se a representao de uma MEF com quatro estados para umextrator de comentrios, extrada de Chow (1978). Cada arco rotulado com a entrada que gera atransio e a sada que produzida, usando o formato entrada:sada.

Figura 3.1: MEF para um extrator de comentrios (Chow, 1978).

Em uma tabela de transio, os estados so representados por linhas e as entradas, por colu-nas (Davis, 1988). Por exemplo, a tabela de transio da MEF da Figura 3.1 apresentada naTabela 3.1.

De acordo com Petrenko e Yevtushenko (2005), uma MEF A pode ser representada formal-mente por uma tupla (S, s0, X, Y,DM , , ), onde:

S um conjunto finito de estados, incluindo o estado inicial s0;

22 3.3. MQUINAS DE ESTADOS FINITOS

Tabela 3.1: Tabela representativa da MEF do extrator de comentrios.

Sada Prx. EstadoXXXXXXXXXXXXEstado

Entrada* / v * / v

1 ignore ignore ignore 1 2 12 empty-bf ignore ignore 3 2 13 acc-bf acc-bf acc-bf 4 3 34 acc-bf deacc-bf acc-bf 4 1 3

X um conjunto finito de entradas;

Y um conjunto finito de sadas;

DM S X um domnio da especificao;

uma funo de transio, : DM S, e

uma funo de sada, : DM Y ;

Uma MEF completamente especificada (ou completa) aquela em que existem transies de-finidas para todos os smbolos de entrada em cada estado da MEF. Caso contrrio, a MEF parci-almente especificada (ou parcial). Formalmente, uma MEF completa se DM = S X .

Uma MEF fortemente conexa se para cada par de estados si, sj S existe uma seqncia queleva a MEFM do estado si ao estado sj . Uma MEF dita ser inicialmente conexa quando todosos estados so alcanveis a partir do estado inicial s0. De uma forma geral, somente as MEFsinicialmente conexas so consideradas nos estudos realizados, pois, de acordo com Yannakakis eLee (1995), qualquer estado inatingvel a partir do estado inicial no afeta o comportamento daMEF.

UmaMEF determinstica se em cada estado, dada uma entrada, h somente uma nica transi-o definida para um prximo estado caso contrrio, a MEF no-determinstica. De acordo coma definio de MEF utilizada neste trabalho, apenas as MEFs determinsticas sero consideradas.

Como em Fujiwara et al. (1991), a notao six/y sj ser utilizada para indicar que a MEFM no estado si produz y como sada e realiza uma transio para o estado sj quando a entrada x aplicada. A notao si x sj ser utilizada quando a entrada x aplicada ao estado si sem seimportar com a respectiva sada. Os estados si e sj so chamados de estado inicial e estado finalde uma transio, respectivamente.

Sejam M = (S, s0, X, Y,DM , M , M) e I = (T, t0, X, Y,DT ,I ,I) que representamuma especificao e uma implementao, respectivamente. Uma seqncia de entrada =x1x2 . . . xk X chamada de seqncia de entrada definida (defined input sequence) para oestado si S se existem k estados si1 , si2 , . . . , sik S tal que haja uma seqncia de transies

CAPTULO 3. TESTE BASEADO EM MODELOS 23

si x1 si1 si(k1) xk sik na MEF M . A notao M(si) significa o conjunto detodas as seqncias de entrada definidas no estado si da MEF M . A notao M representa oconjunto de todas as seqncias de entrada definidas no estado inicial s0 da MEFM . A seqnciavazia denotada pelo smbolo .

A notao representa a concatenao da seqncia com a seqncia . Dados os con-juntos A e B, a notao AB representa a concatenao do conjunto A com o conjunto B, tal queAB = { | A, B}.

Uma seqncia prefixo de uma seqncia , denotado por , se = , para algum. A seqncia um prefixo prprio de , denotado por < , se = , para algum 6= .

As funes de transio e sada estendem-se para a seqncia de entrada definida. Assim,dada uma seqncia de entrada x M(si) ento (si, x) = ((si, ), x), (si, x) =(si, )((si, ), x), (si, ) = si e (si, ) = .

Um caso de teste de uma MEFM uma seqncia de entrada definida x M . Um conjuntode casos de teste T (ou conjunto de teste) para uma MEFM um conjunto finito de casos de testede M , tal que no existam dois casos de teste , T com < . Neste trabalho, os termosseqncia e caso de teste so usados como sinnimos.

Para um conjunto de teste T , a notao pref(T ) representa todos os prefixos dos casos de testecontidos em T , ou seja, pref(T ) = { | T, }. Seja w() o comprimento da seqncia, ou seja, w() = ||. A notao w(A) representa o tamanho de um conjunto A calculado pelasoma dos comprimentos das seqncias contidas em A que no so prefixos prprios de outrasseqncias.

Dois estados, sj de M e ti de I so compatveis se para todo M(sj) I(ti), tem-seque M(sj, ) = I(ti, ). Caso contrrio, os estados so distinguveis. Formalmente, os estadossj e ti so distinguveis se existe uma seqncia de entrada M(sj) I(ti), chamada deseqncia de separao (separating sequence), tal que M(sj, ) 6= I(ti, ).

Dois estados si, sj S so equivalentes em relao ao conjunto V M(si), representadopor si =V sj , se M(si, ) = M(sj, ) para todo V . O estado si quasi-equivalente aoestado sj , se M(si) M(sj) e M(si, ) = M(sj, ) para todo M(sj). Em outraspalavras, um estado si quasi-equivalente a um estado sj se para toda entrada definida em sj , siproduzir a mesma sada.

Uma MEF parcial reduzida se seus estados, tomados par-a-par, so distinguveis. Uma MEFcompleta minimal se no possui par de estados equivalentes. Neste trabalho os termos reduzidae minimal so utilizados como sinnimos.

Dados os estados si, sj S e uma seqncia M(si) tal que M(si, ) = sj diz-se que uma seqncia de transferncia (transfer sequence) de si para sj . Um conjunto state cover Qde uma MEFM com n estados definido como um conjunto com n seqncias de transferncia,incluindo a seqncia vazia , que levaM a partir de seu estado inicial s0 para cada um dos estados.

24 3.3. MQUINAS DE ESTADOS FINITOS

Um conjunto transition cover P um conjunto de seqncias de entrada em que para cadaestado s S e para cada entrada X , existe uma seqncia de entrada x P partindo doestado inicial s0 e terminando com a transio que aplica ao estado s. O conjunto P faz com quea mquina execute cada transio e que, em seguida, pare.

Uma seqncia de distino (distinguishing sequence) uma seqncia de entrada d em que aseqncia de sada produzida pela MEFM , em resposta entrada d, identifica o estado da mquinaM , ou seja, para todo si, sj S, i 6= j, M(si, d) 6= M(sj, d).

Uma seqncia UIO (unique input/output sequence) de um estado sj uma seqncia de en-trada/sada nica para esse estado. Em outras palavras, com a aplicao da seqncia UIO pode-sedistinguir o estado sj de qualquer outro estado, pois a sada produzida especfica (nica) do es-tado sj . Desse modo, a seqncia UIO pode determinar em qual estado a mquina se encontravaantes de sua aplicao.

Um conjunto de caracterizao (characterization set), freqentemente chamado de conjuntoW , um conjunto de seqncias de entrada tal que, para dois estados distintos quaisquer sj e si,existe W tal que M(sj, ) 6= M(si, ). Em outras palavras, o conjuntoW um conjunto deseqncias de entrada que possui uma seqncia que diferencia todo par de estados existentes emM . O conjunto de caracterizao sempre existe para MEFs reduzidas.

Um conjuntoWj M(sj) de seqncias de entrada definidas chamado de identificador deestado (state identifier) ou conjunto de separao (separating set) do estado sj se para qualqueroutro estado si existe Wj M(si) tal que M(sj, ) 6= M(si, ). Em outras palavras, oconjuntoWj um identificador do estado sj se possui uma seqncia de entrada que o diferenciade todos os demais estados.

Uma famlia de separao (separating family) ou identificadores harmonizados (harmonizedidentifiers) um conjunto de identificadores de estado Wj, sj S, que satisfaz a seguinte condi-o:

Para dois estados quaisquer sj, si S, i 6= j, existe Wj e Wi que tm um prefixocomum tal que M(sj) M(si) e M(sj, ) 6= M(si, ).

A operao reset (representada como r no incio das seqncias de entrada) uma operaoque reinicia corretamente a MEF, ou seja, leva a implementao ao seu estado inicial. Umamensagem de status uma entrada que produz como sada um valor que indica em qual estado aMEF se encontra e a MEF no muda de estado (Broy et al., 2005).

Um checking experiment da MEF M um conjunto de seqncias de entrada que diferenciaa classe de MEFs, equivalentes M , de todas as outras MEFs (Kohavi e Kohavi, 1968). Naetapa de teste de uma MEF, as seqncias de entrada so produzidas e aplicadas implementaocom o propsito de verificar-se a conformidade com sua especificao. A aplicao sucessivade cada seqncia de entrada do conjunto de teste T (assumindo a existncia do smbolo r noincio de cada seqncia) equivalente aplicao de apenas uma nica seqncia, formada pela

CAPTULO 3. TESTE BASEADO EM MODELOS 25

concatenao de todas as seqncias do conjunto de teste. Se essa nica seqncia forma umchecking experiment ento essa seqncia uma checking sequence.

SejaM uma especificao e m(M) o conjunto de todas as implementaes I = (T, t0, X, Y,DI , , ) com at m estados tal que I M e m n, onde n o nmero de estados de M .Um conjunto de teste TS m-completo para a especificaoM se para todo I m(M) tal queI 6 M , existe uma seqncia TS que distingue I deM . Para m = n, o conjunto dito sern-completo. Neste trabalho, o caso particularm = n considerado.

A implementao I est em conformidade com a especificaoM se e somente se t0 =M (s0)s0, sendo t0 e s0 estados iniciais de I eM , respectivamente. Isso significa que, para cada seqnciade entrada onde um comportamento deM seja definido, I comporta-se de maneira idntica.

3.4 Teste Baseado em Mquinas de Estados Finitos

O teste baseado em MEF consiste na gerao de um conjunto de casos de teste que consigaencontrar o mximo de defeitos possvel em uma implementao. Com isso, possvel verificar sea implementao da MEF est ou no de acordo com sua especificao.

Como visto anteriormente, em diferentes aplicaes, tais como protocolos de comunicao,sistemas de telecomunicaes e outros Sistemas Reativos, a especificao pode ser modelada comouma MEF. Dessa forma, o teste baseado em MEF considera que tanto a especificao quanto aimplementao sejam modeladas por uma MEF. Assim, a implementao contm um defeito nocaso em que possuir um comportamento diferente em relao especificao. Os defeitos podemser dos seguintes tipos:

Defeito de Inicializao: quando o estado inicial no o correto.

Defeito de Transferncia (transfer faults): quando o estado atingido por uma transio no o correto.

Defeito de Sada (output faults): quando a sada gerada por uma transio no a correta.

Estados Faltantes (missing states): quando os estados da implementao precisam ser au-mentados para torn-la equivalente especificao.

Estados Extras (extra states): quando os estados da implementao precisam ser reduzidospara torn-la equivalente especificao.

Para o teste baseado em MEF estima-se o nmero m de estados da implementao. Quantomais perto esse nmero chegar em relao ao nmero real de estados da implementao, melhor oresultado do mtodo de gerao de casos de teste.

Os mtodos de gerao consideram que a implementao modelada por uma MEF com nomximo m estados (tal que m seja igual ou maior que n, nmero de estados da especificao) e,

26 3.5. MTODOS DE GERAO DE CASOS DE TESTE

a partir dessa informao, a implementao estar de acordo com sua especificao se no possuirdefeitos de transferncia nem defeitos de sada.

Diversos mtodos de derivao de casos de teste tm sido propostos para testar-se a confor-midade de protocolos de comunicao (Chow, 1978; Fujiwara et al., 1991; Petrenko et al., 1993;Vuong et al., 1989). Esses mtodos objetivam verificar se uma implementao est correta emrelao especificao. De acordo com Fujiwara et al. (1991), um mtodo de gerao de casos deteste deve gerar um conjunto de casos de teste que possua as seguintes caractersticas:

a) ser relativamente pequeno para que se tenha baixo custo de execuo durante o teste da imple-mentao.

b) conseguir cobrir o mximo de defeitos possveis que uma implementao possa ter.

Dentre os mtodos existentes, alguns necessitam que a MEF possua certas propriedades, taiscomo completamente especificada, minimal, fortemente conexa e determinstica.

A seguir so apresentados alguns mtodos de gerao de casos de teste para MEFs.

3.5 Mtodos de Gerao de Casos de Teste

Embora os mtodos possuam um objetivo comum (de verificar se uma implementao est cor-reta com sua especificao), eles diferem com relao ao custo da gerao das seqncias de teste,tamanho do conjunto de teste e capacidade de deteco de defeitos (efetividade). Da mesma formaque as seqncias geradas precisam detectar o mximo de defeitos existentes em uma implemen-tao, elas devem ser relativamente pequenas para que seja possvel sua aplicao na prtica.

Nesta seo, so apresentados alguns mtodos de gerao de casos de teste, buscando ilustrar asdiferenas apresentadas em relao ao conjunto de propriedades requeridas. Uma MEF, ilustradana Figura 3.2, ser utilizada como exemplo para a gerao dos casos de teste. Essa MEF possuiquatro estados {S1, S2, S3, S4}, sendo S1 o estado inicial, as entradas X = {x, y} e as sadasY = {0, 1}. A MEF tambm admite o conjunto de seqncias {x, y, yy} como o conjunto W ,o conjunto state cover Q = {, y, x, yy}, os identificadores de estado W1 = {yy}, W2 = {y},W3 = {x} e W4 = {x, yy} e as famlias de separao H1 = {x, yy}, H2 = {x, y}, H3 = {x} eH4 = {x, yy}.

3.5.1 Cobertura de Estados e Transies

Em Holzmann (1991), um algoritmo proposto para o teste de conformidade. Dada uma im-plementao I e uma especificaoM , o algoritmo leva em considerao as seguintes suposies:

M reduzida;

CAPTULO 3. TESTE BASEADO EM MODELOS 27

S1

x/1 y/0

y/0

y/0

y/1

x/1

x/1

x/0

S2

S3 S4

Figura 3.2: Exemplo de MEF extrado de Dorofeeva et al. (2005a).

M completamente especificada;

M fortemente conexa;

I no se altera durante o teste;

I est em seu estado inicial antes do teste;

I eM possuem o mesmo nmero de estados;

Existem as mensagens de status, reset e set.

O algoritmo de teste de conformidade funciona com a aplicao das mensagens status, reset eset para todo estado s S, sendo x X da seguinte forma. Aplique uma mensagem de reset paratrazer I ao seu estado inicial. Aplique uma mensagem set(s) para levar I ao estado s. Apliquea entrada x. Verifique se a sada produzida est em conformidade com a especificao M , ouseja, se igual a M(s, x). Aplique a mensagem de status e verifique se o estado final est emconformidade com a especificaoM , ou seja, se igual a M(s, x).

A checking sequence produzida pelo algoritmo uma concatenao das seqncias reset,set(s), x e status repetida para cada estado s do conjunto de estados S e para cada smbolode entrada x do conjunto de smbolos de entrada X . Esse algoritmo capaz de revelar qualquerdefeito de sada e de transferncia. No entanto, o algoritmo baseia-se na mensagem set, que porsua vez, pode no existir.

Para evitar o uso de mensagens set, uma seqncia transition tour (TT) pode ser construda.Essa seqncia percorre a mquina visitando cada estado e cada transio ao menos uma vez semque ela precise ser reiniciada aps a execuo de cada teste. Pela aplicao do mtodo TT, junta-mente com uma mensagem de status (inserida aps cada entrada da seqncia TT), uma checkingsequence obtida. Essa seqncia de entrada consegue descobrir os defeitos de transferncia e desada. No entanto o mtodo TT, proposto originalmente por Naito e Tsunoyama (1981), no utiliza

28 3.5. MTODOS DE GERAO DE CASOS DE TESTE

a mensagem de status e obtm somente uma cobertura das transies. Dessa forma, o mtodoTT no garante a deteco de defeitos de transferncia.

Para a MEF da Figura 3.2, o conjunto de casos de teste, gerado pelo mtodo TT, compostopelas seqncias que realizam a cobertura das transies. O conjunto de teste obtido poderia serTSTT = {ryxyyxy, rxxxyxy} de tamanho 14.

3.5.2 Mtodo DS

O mtodo DS, proposto por Gnenc (1970), baseia-se na seqncia de distino, ou seja, paraa sua utilizao necessrio que a MEF possua essa seqncia. No entanto, segundo Gill (1962),tal seqncia pode no existir mesmo para MEFs minimais.

importante selecionar a menor seqncia de distino para que, conseqentemente, se obte-nha um conjunto menor de casos de teste. Seja Xd a seqncia de distino escolhida. O mtodoresulta na gerao de uma checking sequence pela composio de duas sub-seqncias:

Seqncias-: Verificam todos os estados da MEF.

Seqncias-: Verificam todas as transies.

Primeiramente, o mtodo consiste na gerao das seqncias-. Para isso, um grafo (grafo-Xd) construdo de modo que cada estado da MEF seja representado por um n. Para cada n, existeuma aresta que o liga a um outro n representando a aplicao deXd. As seqncias- so geradaspercorrendo-se o grafo sem repetir as arestas.

Em seguida, as seqncias- so produzidas de forma semelhante s seqncias-. Um outrografo produzido (grafo-), no entanto, as arestas representam seqncias da forma xi.Xd. Asseqncias- so geradas obtendo-se uma cobertura das arestas do grafo-.

Considerando a MEF da Figura 3.2 com a seqncia de distino Xd = yyy, o mtodo DS ilustrado a seguir. Para a gerao das seqncias- o grafo-Xd, ilustrado na Figura 3.3, constru-do. Para cada n, as transies referentes aplicao de Xd so representadas.

No incio, um estado que no destino de nenhuma aresta (estado origem) escolhido arbi-trariamente. Por exemplo, o estado S1 escolhido e marcado como reconhecido. Aplica-se aseqncia Xd atingindo o estado S4 que tambm marcado como reconhecido. Aplica-se Xdatingindo o estado S4 novamente. Assim, um novo estado origem deve ser selecionado, mas antesdisso, aplica-se novamente Xd para verificar se o estado atingido foi realmente o estado S4. Apartir de S4 aplica-se x que leva a MEF ao novo estado origem S3. Estando no estado S3, repete-seo procedimento anterior. A seqncia- obtida : {yyy yyy yyy x yyy yyy xx yyy yyy}.

Em seguida, para a construo das seqncias-, o grafo- (Figura 3.4(a)) criado. Conside-rando que as seqncias- j foram aplicadas e, dessa forma, todos os estados j foram verificados,duas redues podem ser realizadas no grafo-. A primeira refere-se ltima transio da apli-cao de Xd. Por exemplo, aplicando-se Xd ao estado S1 a MEF passa pelos estados S2, S4 e

CAPTULO 3. TESTE BASEADO EM MODELOS 29

S1

Xd

S2

S3 S4Xd

Xd

Xd

Figura 3.3: Grafo-Xd.

S4. O ltimo passo pode ser descartado, pois essa verificao j foi realizada na construo dasseqncias-. Desse modo, a transio de S4 com a entrada y pode ser retirada do grafo-. Demaneira semelhante, a transio de S2 com a entrada y pode ser retirada do grafo-.

A segunda reduo refere-se ltima transio da seqncia includa para ligar os estados deorigem. A seqncia x ligou o estado S4 ao estado S3, ento a transio de S4 com a entrada xpode ser retirada do grafo-. Do mesmo modo, a seqncia xx ligou o estado S4 ao estado S2,passando pelo estado S3. Dessa forma, a transio de S3 com a entrada x tambm pode ser retiradado grafo-. O grafo- reduzido ilustrado na Figura 3.4(b).

S1

x.Xd

S3

S2

S4 x.Xd

x.Xd

y.Xd y.Xd

y.Xd

y.Xdx.Xd

(a)

S1

x.Xd

S3

S2

S4

x.Xd

y.Xd y.Xd

(b)

Figura 3.4: Grafo- e Grafo- reduzido.

Percorre-se o grafo- reduzido para a obteno da seqncia-. A seqncia- obtida :{xyyy xy yyyy xx xyyy x yyyy}.

O conjunto de casos de teste resultante da aplicao do mtodo DS : TSDS = {yyyyyyyyyxyyyyyyxxyyyyyyxyyyxyyyyyxxxyyyxyyyy} de tamanho 45.

importante salientar que trabalhos vm sendo desenvolvidos em relao reduo de chec-king sequences. No trabalho de Ural et al. (1997), um mtodo para a construo de checkingsequences proposto e, da mesma forma que o mtodo DS, aplicvel somente para MEFs que

30 3.5. MTODOS DE GERAO DE CASOS DE TESTE

possuam uma seqncia de distino. No trabalho de Hierons e Ural (2002), uma melhoria pro-posta ao mtodo criado em Ural et al. (1997) para a construo de checking sequences de tamanhomnimo. A partir dessa melhoria, houve uma reduo no tamanho das checking sequences geradasa partir de MEFs determinsticas, minimais e completamente especificadas. A checking sequence produzida com base nos conjuntos A (conjunto de seqncias) e Ec (conjunto de transies). Notrabalho de Hierons e Ural (2006) investiga-se a escolha desses conjuntos. Os autores demons-tram como o conjunto A deve ser escolhido para minimizar a soma dos tamanhos das seqncias ecomo essa etapa deve ser adaptada para a gerao de um conjunto Ec timo. Os resultados obtidosapontam uma reduo de 25% a 40% das checking sequences.

No trabalho de Simo e Petrenko (2008), um mtodo para a gerao de checking sequences proposto. O mtodo aplicvel em MEFs completas ou parciais e que podem possuir a operaoreset. Os resultados obtidos apontam que, em mdia, houve uma reduo de 45% do tamanhodas checking sequences obtidas no trabalho de Hierons e Ural (2006) e uma reduo de 20% emrelao ao trabalho de Chen et al. (2005).

3.5.3 Mtodo W

Um dos mtodos mais conhecidos para a gerao de seqncias de teste o Mtodo W (Au-tomata Theoretic) proposto por Chow, em 1978. O mtodo W no aplicado a MEFs parciais,considerando apenas MEFs fortemente conexas, completamente especificadas, minimais e deter-minsticas. Esse mtodo consiste em gerar dois conjuntos de seqncias e concaten-las de formaa obter uma seqncia de entrada para teste de determinada MEF. Esses dois conjuntos so:

P : Conjunto de seqncias que percorre cada transio ao menos uma vez.

T : Conjunto de seqncias capaz de identificar qual o estado da mquina.

O conjunto T gerado a partir de um conjunto de caracterizao (conjunto W ). Em seguida, estimado o nmero m de estados da mquina a ser testada. Tem-se T =

mni=0 (X

iW ), ondeX0 = {} e X i = XX i1. Ao fim, as seqncias de teste so geradas pela concatenao de Pcom T . As seqncias desse conjunto so executadas uma a uma na mquina, gerando as sadasque so analisadas posteriormente.

Em suma, o mtodo W consiste em trs passos principais:

1. Estima-se um nmero mximo (m) de estados que a implementao possa conter.

2. Gerao das seqncias de teste que garantem que cada transio foi implementada correta-mente.

3. Verificao das respostas geradas pelas seqncias de teste produzidas na segunda etapa.

CAPTULO 3. TESTE BASEADO EM MODELOS 31

Se a implementao da MEF (a mquina em teste) gerar sadas corretas a partir das seqnciasde entrada geradas pelo mtodo W, essa mquina est correta, pois o mtodo confivel para testarestruturas de controle modeladas por uma MEF (Chow, 1978). Contudo, o mtodo W produzmuitas seqncias de entrada para serem testadas, o que pode promover um alto custo para arealizao da etapa de teste.

A aplicao do mtodo W na MEF da Figura 3.2 ilustrada a seguir. Considerando m = ntem-se o conjunto T = W = {x, y, yy}. Considera-se o conjunto transition cover P = {, x, y,xx, xy, yy, yx, yyy, yyx}. Pela concatenao de P com T obtm-se as seqncias {x, y, yy, xx,xy, xyy, yx, yy, yyy, xxx, xxy, xxyy, xyx, xyy, xyyy, yyx, yyy, yyyy, yxx, yxy, yxyy, yyyx,

yyyy, yyyyy, yyxx, yyxy, yyxyy}.Com a retirada das seqncias que so prefixos de outras, a aplicao do mtodo W na MEF

da Figura 3.2 resulta no conjunto TSW = {rxxx, rxxyy, rxyx, rxyyy, ryxx, ryxyy, ryyxx,ryyxyy, ryyyx, ryyyyy} de tamanho 49.

3.5.4 Mtodo Wp

Fujiwara et al. (1991) propuseram o mtodo Wp (partial W ) que um aprimoramento domtodoW . A principal vantagem do mtodoWp em relao aoW que ele utiliza um subconjuntodo conjuntoW para a criao das seqncias de teste, e, assim, obtm-se uma quantidade reduzidade casos de teste para serem utilizados.

O mtodo Wp, semelhante ao W , tambm opera em MEFs completas. Esse mtodo possui omesmo poder do mtodoW na deteco de defeitos, mas produz um menor conjunto de seqnciasde entradas (Fujiwara et al., 1991).

O mtodo basicamente consiste em duas fases:

Fase 1: verificado se todos os estados definidos na especificao tambm so encontrados naimplementao.

Fase 2: Todas as transies definidas na especificao e que no foram testadas na Fase 1 soverificadas.

Um conjunto P que cobre todas as transies da MEF determinado e identifica-se um subcon-juntoQ que cobre todos os estados da MEF. Para cada estado Si S da especificao determina-seum conjunto de identificaoWi, que distingue o estado Si de todos os demais. A unio de todosos conjuntosWi resulta no conjuntoW e diferentes casos de testes podem ser gerados dependendoda escolha dos conjuntos P , Q eWi.

Na primeira fase, os casos de teste resultam da concatenao dos conjuntos Q eW . Se o testeobtiver sucesso significa que o nmero de estados da implementao igual ao nmero de estadosda especificao.

32 3.5. MTODOS DE GERAO DE CASOS DE TESTE

Na segunda fase, os casos de teste so gerados a partir da concatenao das seqncias doconjunto P , menos as seqncias do conjunto Q, com o conjunto Wi correspondente ao estadoatingido aps a execuo de cada seqncia, ou seja, R = P Q e R W =

pR{p}Wi. A

operao R W resulta em um conjunto formado pela unio da concatenao das seqncias doconjunto R com o conjunto de identificaoWi, ou seja, RW = {Wi | R, (s0, ) = si}.Dessa forma, obtm-se um conjunto de casos de teste menor em relao ao conjunto gerado pelomtodoW , pois a concatenao ocorre com um subconjuntoWi ao invs de ocorrer com o conjuntoW .

Para a MEF da Figura 3.2, a aplicao do mtodo Wp ilustrado a seguir. Na primeira fase,considerando o conjunto state cover Q, as seqncias so geradas pela concatenao deQ comW .Dessa forma, como resultado da primeira fase tem-se as seqncias {x, y, yy, yx, yy, yyy, xx, xy,xyy, yyx, yyy, yyyy}.

Na segunda fase, considerando o conjunto transition cover P = {, x, y, xx, xy, yy, yx,yyy, yyx}, as seqncias so geradas pela concatenao do conjunto P , menos o conjunto Q,com o conjuntoWi de cada estado Si atingido. Tem-se R = P Q = {xx, xy, yyy, yyx, yx}.Realizando a operaoRW obtm-se as seqncias da forma: {xxW2, xyW1, yyyW4, yyxW3,yxW2}. Realizando as substituies necessrias, as seqncias obtidas so: {xxy, xyyy, yyyx,yyyyy, yyxx, yxy}.

Com a retirada das seqncias que so prefixos de outras, a aplicao do mtodo Wp na MEFda Figura 3.2 produz o conjunto TSWp = {rxxy, rxyyy, ryxy, ryyxx, ryyyx, ryyyyy} detamanho 29.

3.5.5 Mtodo HSI

Existem diferentes mtodos para gerao de casos de teste em MEF completas, mas na maio-ria das situaes prticas as MEFs no so completas (Petrenko e Yevtushenko, 2005). Por isso,existe a necessidade de mtodos para atender as MEFs parciais. Uma soluo para esse problemaseria completar artificialmente a MEF, adicionando arcos nulos nos estados no totalmente espe-cificados. Com isso, entretanto, tem-se o problema de um grande nmero de casos de teste e osarcos artificiais poderiam interferir no clculo dos casos de teste, gerando, na maioria dos casos,um conjunto de teste invivel.

Nesse contexto encontra-se o mtodo HSI (Harmonized State Identification) (Luo et al., 1995)que resolve o problema das MEFs parciais e ainda o problema das MEFs no-determinsticas. Essemtodo um dos mais versteis, pois pode ser aplicado maioria dos tipos de MEFs.

O Mtodo HSI similar ao mtodo W, entretanto, diferenci