Análise de cobertura de critérios de teste estruturais a partir
de conjuntos derivados de especificações formais: um estudo
comparativo
Paula Fernanda R. Herculano1, Márcio Eduardo Delamaro2
1Instituto de Ciências Matemáticas e de Computação – Universidade de São Paulo
Caixa Postal 668 – São Carlos – SP – Brasil
2Centro Universitário Eurípides de Marília
Marília – SP – Brasil
paulah@icmc.usp.br, delamaro@univem.edu.br
Abstract. Testing techniques can be divided in code-based and specification ba-sed and using them together can increase the application confidence level. So, is important to investigate their relationship analysing, how they complete each other and how they can be used together, aiming at composing a testing strategy. This paper aims at performing comparative studies focused on reactive systems, which are specified using formal methods. The test cases are derived from for-mal specifications and then compared with controlflow and dataflow structural criteria.
Resumo. As técnicas de teste podem ser divididas em baseadas no código e ba-seadas na especificação e usá-las em conjunto tenta garantir maior qualidade à atividade de teste, pois cada uma tem suas particularidades. Assim, surge a necessidade realizar estudos que investiguem o relacionamento dessas téc-nicas, analisando como podem ser usadas em conjunto a fim de compor uma estratégia de teste. O objetivo deste trabalho é realizar tais estudos comparati-vos, com foco no teste de sistemas reaticomparati-vos, os quais são especificados por meio de métodos formais. Com base nesses métodos, derivam-se os casos de teste e comparam-nos com os critérios estruturais de fluxo de controle e de fluxo de dados.
1. Introdução
Os sistemas reativos possuem como característica fundamental a interação contínua com o ambiente, reagindo a eventos internos e externos, o que faz com que seu aspecto com-portamental seja de fundamental importância para definir os requisitos do sistema. Fazem parte dessa classe, por exemplo, aplicações espaciais, sistemas de controle de tráfego aéreo e de telefonia. Tais sistemas são críticos com relação à segurança pois podem co-locar em risco vidas humanas ou grandes valores financeiros requerendo, dessa forma, a utilização de métodos formais, que possuem um rigor matemático, de forma a eliminar ambigüidades e facilitar sua validação.Como exemplo podem ser citadas várias técnicas: Máquinas de Estados Finitos (MEF), Redes de Petri, Statecharts, Estelle, SDL, entre ou-tras.
O processo de desenvolvimento de software envolve uma série de atividades nas quais, apesar das técnicas, métodos e ferramentas empregados, erros no produto ainda
podem ocorrer. Mesmo a utilização de métodos formais, não garante a correção e com-pletude das especificações e, para tentar aumentar a confiança de tais especificações, é necessário que atividades de teste sejam conduzidas. Para isso existem vários mé-todos propostos para o teste e a validação de especificações. Como exemplo pode-se citar o Método W [Chow 1978], State-Counting [Petrenko and Yevtushenko 2005], entre outros. Estudos teóricos e empíricos visando à comparação de critérios de teste bem como o estabelecimento de estratégias para sua aplicação, têm sido condu-zidos [Ntafos 1988, Rapps and Weyuker 1985, Mathur and Wong 1993, Harrold 2000]. Tais estudos permitem que se entenda melhor o relacionamento existente entre diferentes técnicas de teste e que sua utilização seja feita de forma mais eficiente.
Este trabalho está inserido no contexto do projeto PLAVIS (Plataforma para Vali-dação e Integração de Software em Aplicações Espaciais) patrocinado pelo CNPq. O pro-jeto (http://www.labes.icmc.usp.br/plavis) reúne cientistas das seguintes universidades e centros de pesquisas: USP, UNICAMP, UFSCar, INPE e UNIVEM. Há também uma cooperação com a França, por meio do projeto Capes-Cofecub. O objetivo global do projeto PLAVIS é verificar a aplicabilidade dos métodos, técnicas e ferramentas desenvolvidos no âmbito acadêmico para Testes de Software (geração, seleção, execução e análise automatizada de testes) em aplicações espaciais fornecidas pelo INPE. É enfo-cada também a qualidade dos testes, tanto do ponto de vista da cobertura (seja do código, seja da especificação), quanto do ponto de vista da eficácia para encontrar falhas.
O objetivo deste trabalho é realizar um estudo comparativo entre as técnicas de geração de casos de teste baseados nas especificações formais e os critérios es-truturais de fluxo de dados e de fluxo de controle a fim de analisar qual o relaci-onamento entre essas técnicas e como podem ser utilizadas em conjunto. É anali-sado o custo e a eficácia (em termos de cobertura estrutural) de se aplicar um con-junto de teste derivado de uma especificação formal em uma implementação. As téc-nicas de especificação formal utilizadas neste trabalho são: Máquina de Estado Finito e Rede de Petri Colorida (RPC). Os métodos de geração de casos de teste analisados são: Método W [Chow 1978], State-Counting [Petrenko and Yevtushenko 2005] e Uni-que Input-Output – UIO [Sabnari and Dahbura 1988], e o critério Análise de Mutantes [DeMillo 1978], sendo os três primeiros baseados em Máquina de Estado Finito e o último sendo aplicado tanto a Máquinas de Estados Finitos quanto a Redes de Petri Coloridas.
Este artigo está estruturado da seguinte maneira: na Seção 2 são mostrados os dois estudos de caso desenvolvidos. Na Seção 3 são apresentadas as conclusões e os trabalhos futuros. Devido a restrições de espaço, e considerando a platéia a que se destina esse artigo, foram omitidos conceitos básicos pernitentes ao trabalho, principalmente relacio-nados a técnicas de teste, e que podem ser encontrados na literatura como por exemplo em Delamaro et al. [Delamaro et al. 2007].
2. Estudos de Caso
Para compor este trabalho foram realizados dois estudos de caso, que foram descritos e caracterizados de acordo com o modelo proposto por Wohlin et al. [Wohlin et al. 2000]. Os objetos de estudos usados são protocolos de comunicação. O primeiro é um protocolo de conferência, denominado ConfCase, que foi usado e desenvolvido no projeto Côte de Resyste – COnformance TEsting OF REactive SYSTEms (mais informações podem ser
obtidas em http://fmt.cs.utwente.nl/ConfCase). O segundo é um protocolo de comunicação, desenvolvido e utilizado no Instituto Nacional de Pesquisas Espaciais (INPE), denominado OBDH-EXP. Os estudos de caso são compostos da especificação e implementação dos problemas.
Os conjuntos de casos de teste são derivados a partir das especificações e dos requisitos estruturais e, posteriormente, aplicados nas implementações para análise e ava-liação com o objetivo de verificar qual o custo e a eficiência, em termos de cobertura estrutural, em aplicar conjuntos de teste derivados de especificações formais em imple-mentações Java.
2.1. Estudo de Caso 1 – Protocolo de Conferência
Neste estudo de caso, as técnicas de especificação formal utilizadas são: Máquina de Es-tado Finito (MEF) e Rede de Petri Colorida (RPC). Os métodos de geração de seqüências de teste empregados são: W , State-Counting (SC), Unique Input-Output (UIO) e Aná-lise de Mutantes [Fabbri et al. 1994], aplicados a MEF e o critério AnáAná-lise de Mutantes, aplicado a RPC [Simão 2004].
Para a geração das seqüências de teste derivadas da MEF foi utilizada a ferra-menta Plavis/FSM [Simão et al. 2005], que auto-completa a MEF, pois os critérios exi-gem que está seja completamente especificada. A RPC foi utilizada apenas neste es-tudo de caso e serviu de base para a geração do conjunto de teste adequado ao cri-tério Análise de Mutates. Esse conjunto de teste foi gerado com o auxílio da ferra-menta Proteum CPN [Simão 2004]. Os critérios de teste estrutural utilizados são os critérios de fluxo de controle nós e todas-arestas) e de fluxo de dados (todos-usos) [Rapps and Weyuker 1985]. São utilizadas duas implementações distintas do pro-tocolo de conferência, uma baseada na especificação informal e a outra baseada na espe-cificação formal em Máquina de Estado Finito. Este estudo de caso foi selecionado pela equipe do projeto PLAVIS por tratar-se de um protocolo simples, para o qual já existia um modelo MEF e que serviria como um primeiro estudo para o aprendizado e utilização das técnicas e das ferramentas utilizadas no projeto.
O Protocolo de Conferência fornece um serviço semelhante a um chat, no qual os usuários podem participar de uma conferência, trocar mensagem e sair da conferência. Uma conferência é formada por um grupo de usuários, podendo existir várias conferên-cias ao mesmo tempo mas cada usuário pode participar de apenas uma por vez. Caso o usuário queira participar de outra conferência, é necessário que ele saia da atual para conectar-se à desejada. A troca de mensagens é feita entre todos os participantes de uma mesma conferência, ou seja, cada usuário pode enviar mensagens e todos os outros parti-cipantes daquela conferência a recebem. A Figura 1 mostra a MEF utilizada neste estudo de caso. As transições são rotuladas na forma entrada/saída. Quando a saída não é explí-cita, considera-se que seja nula. O rótulo das transições representa uma combinação entre as primitivas, o nome do usuário e o nome da conferência.
Cada um dos conjuntos de teste, derivados das especificações formais foi aplicado em cada uma das implementações e, com a ajuda da ferramenta Ja-BUTi [Vincenzi et al. 2003] foi verificada a cobertura estrutural obtida com a aplicação dos conjuntos de teste e o número de casos de teste que influenciaram na cobertura dos requisitos estruturais.
Figura 1. Máquina de Estado Finito do Protocolo de Conferência
2.1.1. Análise dos Resultados
Para ambas implementações, o método W obtém a maior cobertura estrutural, para os 3 critérios, como pode ser observado nas Tabelas 1 e 2. Isso significa que qualquer elemento requerido por um dos critérios estruturais que é coberto por algum conjunto de teste, também é coberto pelo conjunto de teste derivado do método W . Há dois requisitos que ambas implementações contêm e que não são cobertos por nenhum dos conjuntos de teste: • Um usuário diferente daqueles pré-definidos (ou seja, aqueles que fazem parte da lista de potenciais parceiros) tentar interagir com o usuário sob o ponto de vista do qual a máquina é modelada (usuário A);
• Troca de eventos entre usuários participando de conferências diferentes. Tabela 1. Cobertura em % referente aos critérios estruturais – implementação baseada na especifi-cação informal
Critério de teste W SC UIO AM(MEF) AM(RPC) Estruturais
todos-nós 98 92 92 96 90 100
todas-arestas 94 88 88 90 84 100
todos-usos 89 82 82 81 73 100
Tabela 2. Cobertura em % referente aos critérios estruturais – implementação baseada na especifi-cação formal
Critério de teste W SC UIO AM(MEF) AM(RPC) Estruturais
todos-nós 100 100 97 96 65 100
todas-arestas 90 87 83 85 47 100
todos-usos 82 79 66 70 32 100
A implementação derivada da MEF ainda exige uma seqüência em que há uma ação partindo de um estado diferente daqueles existentes na implementação e, conseqüen-temente, na máquina.
Constata-se que esses requisitos não fazem parte do comportamento “normal” do protocolo, e não são cobertos devido à maneira que os modelos formais foram criados. Em nenhum deles há um estado de erro ou um usuário diferente de A, B e C. A máquina é desenvolvida sob o ponto de vista de um único usuário, que está sempre em uma única conferência. Dessa forma, nenhum dos conjuntos de teste que são derivados dos modelos possui uma seqüência em que a conferência seja diferente daquela em que o usuário se encontra. Como conseqüência disso, também, não há nenhuma seqüência em que o usuá-rio A receba um evento de um usuáusuá-rio que não esteja na mesma conferência que ele, bem como que não esteja na lista dos seus potenciais parceiros.
Com relação ao custo de aplicação dos conjuntos de teste, o número de casos de teste efetivos utilizados em cada uma das implementações é significativamente diferente, conforme apresentado na Tabelas 3. O mesmo acontece para os casos de teste gerados a partir dos critérios estruturais. Para a implementação baseada apenas na descrição in-formal, 8 casos de teste foram suficientes para obter-se a cobertura de todos os requisito. Para a implementação baseada na MEF, foram necessários 16.
Tabela 3. Custo de aplicação baseado no número de casos de teste
Influenciaram na cobertura
Conjunto de teste Tamanho Total Impl. informal Impl. MEF
W 1455 11 155
SC 320 7 115
UIO 28 8 22
AM(MEF) 20 6 16
AM(RPC) 9 7 8
2.2. Estudo de Caso 2: Protocolo OBDH-EXP
Este estudo de caso, assim como o anterior, consiste na avaliação de conjuntos de casos de teste derivados de uma especificação formal com respeito à cobertura de critérios estrutu-rais. Neste estudo de caso foi utilizada apenas uma especificação em Máquina de Estado Finito e uma implementação Java. Com o auxilio da ferramenta Plavis/FSM são geradas seqüências de teste adequada aos critéirios W , UIO e o critério Análise de Mutantes apli-cados em MEF. Os critérios de teste estrutural utilizados são os todos-nós, todas-arestas e todos-usos. Por falta de espaço, não é apresentada aqui a MEF deste estudo de caso, que pode ser vista em Herculano (2007) [Herculano 2007].
O protocolo OBDH-EXP [INPE 2005], desenvolvido no INPE, provê a comuni-cação entre dois equipamentos a bordo de um satélite científico, o computador principal, que é um computador de manipulação de dados a bordo (OBDH) e um equipamento de carga útil científica (EXP). O EXP envia dados e respostas ao OBDH somente sob de-manda. Ao reconhecer o comando enviado pelo OBDH, o EXP executa-o e responde ao OBDH. Os comandos que podem ser reconhecidos e executados pelo EXP são: reinicia-lização (reset), reconfiguração, transmissão de dados, carga (load) de memória, descarga (dump) de memória, obtenção do tempo (clock), inicialização e interrupção de aquisição de dados, carga de parâmetros. Sempre que um comando não é reconhecido, toda a men-sagem é descartada. Se um byte do comando não chega dentro de 500 milisegundos toda
a mensagem é descartada e o EXP volta a aguardar novo comando. O OBDH envia uma mensagem ao EXP que trata cada um dos campos.
A máquina utilizada nesse estudo de caso foi elaborada e revisada pelos membros do projeto Plavis. A execução deste estudo de caso é semelhante à do primeiro, sendo os detalhes omitidos por limitações de tamanho deste texto. A diferença, em relação ao primeiro estudo de caso é que, por tratar-se de um protocolo mais complexo que o primeiro, somente uma implementação foi realizada, apenas a especificação MEF foi construída e, por limitação das ferramentas de geração de seqüências de teste, não se utilizou o método State-Counting. Pelo mesmo motivo, a MEF precisou ser particionada para que os conjuntos de teste pudessem ser gerados. Dessa forma, foram obtidas nove máquinas – uma para cada comando do OBDH – sobre as quais foi realizada a geração dos conjuntos de teste. Tal divisão pode colocar em risco a validade do estudo pois a execução dos métodos requer que a máquina seja completada artificialmente, gerando assim casos de teste repetidos.
Depois de geradas automaticamente, as seqüências de teste foram inseridas ma-nualmente no emulador do OBDH que executa em um PC e que se comunica com o emulador EXP em outro PC por meio de um uma linha serial, conectada por um cabo RS-232. A execução das seqüências foi monitorada pela ferramenta JaBUTi.
2.2.1. Análise dos Resultados
Por meio da análise da Tabela 4 observa-se que o comportamento obtido pelos três conjun-tos de teste é muito semelhante. Analisando a especificação e a implementação entende-se o porquê dessa semelhança. A especificação trata da troca de mensagens entre o compu-tador de bordo e o experimento científico e na implementação é possível observar, clara-mente, a declaração de cada um dos comandos em seus comportamentos normais e em uma situação de erro qualquer. Assim, qualquer um dos conjuntos de teste gera um con-junto de seqüências que representa o comportamento normal e uma seqüência, qualquer, que leva a uma combinação de entradas resultando em um comando inválido.
Tabela 4. Cobertura em % referente aos critérios estruturais
Critério de teste W AM(MEF) UIO Estruturais
todos-nós 80 74 59 85
todas-arestas 80 74 59 78
todos-usos 78 73 56 64
A especificação trata apenas da troca de mensagens, não definindo como essas mensagens serão enviadas ou recebidas. Já na implementação é necessário que tal defini-ção seja concretizada. Para efeitos de avaliadefini-ção e estudo essa diferença é desconsiderada, tratando todos os elementos requeridos referentes à comunicação serial como elementos não executáveis. Também não é possível simular o timeout (transição presente em todos os estados) em todas as situações, pois o emulador não permite tal entrada. A repre-sentação de erros no comando (também presente em todas as transições da MEF) não é possível no emulador; entretanto, esses erros estão representados na implementação de maneira pré-definida, sendo reconhecidos e/ou tratados em poucas situações, como por
exemplo: erro de tipo de experimento ou erro de checksum apenas. Um erro no comando de sincronização, por exemplo, é simplesmente ignorado, não prosseguindo no recebi-mento do comando mas também não informando tal erro. Devido a isso, não é possível cobrir, nem mesmo por meio do conjunto de teste derivado dos requisitos estruturais, 100% dos elementos requeridos.
Assim como foi feito no primeiro estudo de caso, o custo de se aplicar um conjunto de teste é medido pelo tamanho total do conjunto e o número de casos de teste efetivos. Alguns casos de teste que compõe os conjuntos não são aplicáveis. Esses casos de teste referem-se a combinações dos comandos de entrada que não podem ser produzidas no emulador do OBDH. Dos 1752 casos de teste do conjunto W , apenas 28 foram efetivos, ou seja, cobriram algum requisito estrutural. Esse número reflete as diferenças entre a especificação e a implementação. Percebe-se que esses dois artefatos estão representados em níveis de abstração muito diferentes. Da maneira que se apresenta a especificação, ela não seria adequada para a geração de código e nem para o teste de conformidade, pois expressa o comportamento do protocolo em um nível de abstração muito alto.
Tabela 5. Custo de aplicação, em número de casos de teste efetivos
Conjunto de teste Tamanho Total Aplicáveis Influenciaram na cobertura
W 2431 1752 28
AM(MEF) 702 470 34
UIO 147 121 25
Estruturais 4 4 4
3. Considerações Finais e Trabalhos Futuros
Pelos números apresentados nas tabelas dos dois estudos de casos, pode-se perceber que o número de casos de teste requeridos pelos critérios estruturais é bastante inferior ao número de casos de teste gerados pelos métodos baseados nos modelos.
Pelo menos do ponto de vista de cobertura estrutural, existem muitos casos de teste gerados pelas técnicas baseadas em modelos que são inúteis, no sentido que cobrem sempre requisitos cobertos por outras seqüências de teste geradas. Assim, seria possí-vel se pensar em formas de otimização das seqüencias geradas, de modo a diminuir sua cardinalidade, sem que se perca efetividade.
Além do fator custo, pôde-se constatar que a utilização das duas técnicas de teste se complementam. No primeiro estudo de caso, um defeito na implementação foi locali-zado através da aplicação das seqüências de teste geradas a partir da especificação. Por outro lado, ao se analisar os requisitos estruturais da implementação que não são cobertos por essas seqüências percebeu-se que existem detalhes do protocolo que não são com-pletamente especificados pelo modelo MEF. O modelo apresenta o comportamento do sistema em um nível de abstração que não trata de detalhes, que precisam ser tratados na implementação. Assim, a aplicação do teste estrutural serviu, também, como forma de apontar defeitos na própria especificação. Ressalta-se que os modelos desenvolvidos para os dois estudos de caso foram desenvolvidos e revisados pelos membros do projeto Plavis antes de serem utilizados como objetos de estudo.
apre-sentados são úteis para indicar caminhos a serem seguidos na definição e utilização de técnicas de modelagem formais e de técnicas de teste baseadas em modelos.
Agradecimentos
Este trabalho está inserido no contexto do projeto Plavis (Plataforma de Validação e Inte-gração de Software em Sistemas Espaciais), financiado pelo CNPq. Paula Herculano foi bolsista CAPES entre 2004 e 2006.
Referências
Chow, T. S. (1978). Testing software design modeled by finite-state machine. IEEE Transactions on Software Engine-ering, 4(3):178–187.
DeMillo, R. A. (1978). Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34–43. Delamaro, M. E., Maldonado, J. C., Jino, M. (2007) Introdução ao teste de software. Elsevier – Rio de Janeiro – RJ Fabbri, S. C. P. F., Maldonado, J. C., Masiero, P. C., and Delamaro, M. E. (1994). Mutation analysis for finite state
machines. In Anais do 5thInternational Symposium on Software Reliability Engineering (ISSRE’94), p. 220–229, Monterey – CA – EUA.
Frankl, P. G. and Weyuker, E. J. (1993). A formal analysis of the fault-detecting ability of testing methods. IEEE Transactions on Software Engineering, 19(3):202–213.
Harrold, M. J. (2000). Testing: A roadmap. In 22th International Conference on Software Engineering - Future of SE Track, p. 61–72. ACM Press.
Herculano, P. F. R. (2007). Análise de cobertura de critérios de teste estruturais a partir de conjuntos derivados de especificações formais: um estudo comparativo no contexto de aplicações espaciais. Dissertação de mestrado, ICMC/USP, São Carlos – SP.
INPE (2005). EXP-OBDH communication protocol definition – a case study for plavis. Relatório Técnico M13-IF-009, Instituto Nacional de Pesquisas Espaciais (INPE), São José dos Campos – SP.
Mathur, A. P. and Wong, W. E. (1993). Evaluation of the cost of alternative mutation strategies. In VII Simpósio Brasileiro de Engenharia de Software, p. 320–335, Rio de Janeiro – RJ.
Ntafos, S. C. (1988). A comparison of some structural testing strategies. IEEE Transactions on Software Engineering, 14(6):868–874.
Petrenko, A. and Yevtushenko, N. (2000). On test derivation from partial specifications. In Anais do FIP TC6 WG6.1 Joint International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols (FORTE XIII) and Protocol Specification, Testing and Verification (PSTV XX), p. 85–102, Deventer, Holanda.
Petrenko, A. and Yevtushenko, N. (2005). Testing from partial deterministic fsm specifications. IEEE Transactions on Computers, 54:1154–1165.
Rapps, S. and Weyuker, E. J. (1985). Selectiong software testing data using data flow information. IEEE Transactions os Software Engineering, 11(4):367–375.
Sabnari, K. K. and Dahbura, A. (1988). Sa protocol test generation procedure. Computer Network and ISDN Systemsg, 15(4):285–297.
Simão, A. S. (2004). Aplicação de Análise de Mutantes no Contexto do Teste e Validação de Redes de Petri Coloridas. Tese de doutorado, ICMC/USP, São Carlos – SP.
Simão, A. S. and Ambrósio, A. M. and Fabbri, S. C. P. F. and Amaral, A. S. M. S. and Martins, E. and Maldonado, J. C. (2005), Plavis/FSM: an Environment to Integrate FSM-based Testing Tools, Sessão de Ferramentas do 19o Simpósio Brasileiro de Engenharia de Software (SBES’2005), Uberlândia/MG - Brasil
Vincenzi, A. M. R., Wong, W. E., Delamaro, M. E., and Maldonado, J. C. (2003). Jabuti: A coverage analysis tool for java programs. In Anais do 17oSimpósio Brasileiro de Engenharia de Software (SBES’2003), Sessão de Ferramen-tas, p. 79–84, Manaus – AM.
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2000). Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers.
