info.info-se info.info-es info.info-cr info.info-hc info.info-ar info.info-mo
J C Silva 
email: jcsilva@ipca.pt
  
J L Silva 
email: silva@irit.fr
  
J C Campos 
email: jose.campos@di.uminho.pt
  
J A Saraiva Haslab 
  
  
  
  
  
  
  
de Casos de Teste Baseada em Modelos A Model-based Approach for Test Cases Generation

Resumo -Os métodos analíticos baseados em modelos de avaliação de sistemas interativos foram propostos como alternativa aos testes com o utilizador nas últimas fases de desenvolvimento de software devido aos custos destes últimos. No entanto, a utilização isolada de modelos do comportamento do sistema limita os resultados fornecidos pelos métodos analíticos. Um exemplo dessas limitações relaciona-se com o facto destes serem incapazes de identificar problemas de implementação que terão impacto na usabilidade. Com a introdução de testes baseados em modelos é possível contornar o problema e testar se o software implementado vai de encontro ao modelo especificado. Este artigo apresenta uma abordagem para a geração de casos de testes baseados em modelos a partir da análise estática do código fonte.

Usabilidade, Sistemas Interativos, Teste baseado em Modelos

Abstract -The analytical methods based on evaluation models of interactive systems were proposed as an alternative to user testing in the last stages of the software development due to its costs. However, the use of isolated behavioral models of the system limits the results of the analytical methods. An example of these limitations relates to the fact that they are unable to identify implementation issues that will impact on usability. With the introduction of model-based testing we are enable to test if the implemented software meets the specified model. This paper presents an model-based approach for test cases generation from the static analysis of source code.

Usability, Interactive Systems, Model-based testing

I. INTRODUÇÃO

Os sistemas de software fornecem habitualmente interfaces gráficas ao utilizador. Estas representam o meio comum de interacção com o software. Nos últimos anos deparamo-nos com uma explosão das possibilidades de interacção com estes sistemas, sendo o teste de interfaces com o utilizador essencial para avaliar a sua qualidade [START_REF] Mori | Design and development of multidevice user interfaces through multiple logical descriptions[END_REF]. Numa tentativa de abordar esse problema foram desenvolvidas várias técnicas de teste de interfaces gráficas. Por exemplo os testes do utilizador fornecem um elevado nível de fidelidade para avaliar a resposta do utilizador ao sistema. No entanto, esta técnica não é exaustiva em termos de cobertura de todos os potenciais problemas da interface e, além disso, os testes do utilizador são caros. Os métodos analíticos foram propostos como alternativa aos testes do utilizador. Usando protótipos ou modelos do sistema, potenciais erros de usabilidade são identificados e alvo de atenção durante o processo de desenvolvimento. Os protótipos/modelos permitem capturar os aspectos chaves da interacção dos utilizadores com as interfaces assim como os seus relacionamentos [START_REF] Paterno | Model-Based Design and Evaluation of Interactive Applications[END_REF]. Os modelos de comportamento, em particular, podem ser obtidos através da implementação de um processo de engenharia reversa da interacção com o utilizador a partir do código fonte. Explorar a adopção da engenharia reversa de forma a extrair modelos da interface que esse código implementa representa um salto de abstracção maior que o necessário para obter um modelo do código. A engenharia reversa de sistemas interactivos pretende deduzir por análise do código, não quais os objectos presentes na interface (campos de texto, botões, etc.) e como estão organizados, mas antes que informação está presente na interface (o número, o nome, etc.) e as acções disponíveis na mesma (adicionar, consultar, etc.). O processo de engenharia reversa assenta num certo número de assunções e heurísticas que torna o processo viável. Estas abordam basicamente aspectos relacionados com a arquitectura da aplicação a reverter e aspectos relacionados com o nível de abstracção a utilizar. Vários autores investigaram a análise da usabilidade dos sistemas interactivos utilizando técnicas envolvendo o uso de engenharia reversa. Uma abordagem típica consiste em executar o sistema interactivo e automaticamente armazenar os seus estados e acções. Por exemplo, Memon [START_REF] Atif | Automated test oracles for UIs[END_REF] descreve uma ferramenta que extrai automaticamente dados relacionados com os componentes gráficos, as suas propriedades e valores. Uma alternativa que surge no âmbito da engenharia reversa de sistemas interactivos é a análise estática [START_REF] Bruno D'ausbourg | Deriving a formal model of an interactive system from its UIL description in order to verify and to test its behaviour[END_REF]. O processo baseia-se na análise do código de uma aplicação em vez da sua execução, tal como acontece no caso anterior. O teste de implementações baseado em modelos testa se a aplicação vai de encontro ao modelo especificado. Este teste é relevante no contexto da engenharia de software, já que se está interessado em ter a certeza que a implementação não introduz problemas adicionais ao proposto na fase de design [START_REF] Lewis | Testing a walkthrough methodology for theory-based design of walk-upand-use interfaces[END_REF][START_REF] Nielsen | Heuristic evaluation of user interfaces[END_REF].

No contexto da manutenção e redesign pretende-se garantir que alterações ao sistema não criem efeitos inesperados. O teste de implementações baseado em modelos também é aplicada ao teste de interfaces com o utilizador (UI) de forma a testar se a interface desenvolvida vai de encontro ao modelo pretendido. Algumas abordagens foram efectuadas nesse sentido como é o caso do trabalho desenvolvido por Paiva [START_REF] Paiva | Automated Specification-Based Testing of Graphical User Interfaces[END_REF][START_REF] Cristina Paiva | A model-to-implementation mapping tool for automated model-based GUI testing[END_REF]. No seu trabalho métodos de teste baseados em especificações formais foram utilizados de forma a sistematizar e automatizar o processo de teste de interfaces gráficas com o utilizador. A abordagem descrita neste artigo incorpora modelos gerados a partir da análise do código fonte, servindo de base para uma ferramenta de teste de interfaces gráficas via modelos Spec# [START_REF] Barnett | The spec# programming system: Challenges and directions[END_REF] e usando a ferramenta Spec Explorer [START_REF] Campbell | Model-based testing of object-oriented reactive systems with Spec Explorer[END_REF].

II. TESTE DE SOFTWARE

A. Uso de Modelos O teste de software é uma técnica que visa aumentar a confiança na exactidão do software desenvolvido. O teste de software baseado em modelos aumenta a sistematização e automatização, comparando o estado e comportamento de um produto de software com o seu modelo. Nessa comparação, são realizados testes através dos quais é possível averiguar se a aplicação desenvolvida vai de encontro ao seu modelo. Os modelos utilizados podem variar em termos de formalidade: formais, semi-formais ou informais [START_REF] Pretschner | Model-based testing[END_REF]. Os modelos formais podem ser usados como oráculos de teste determinando-se se os resultados de casos de testes são correctos. Os casos de testes são sequências de possíveis acções com os respectivos e resultados esperados. Podem ser gerados automaticamente os casos de teste a partir de um modelo, sendo estes executados sobre a aplicação e sobre o seu modelo. Ambos os resultados são comparados e caso surgem disparidades entre eles os potenciais problemas são identificados. Existem diversos exemplos de ferramentas baseadas em modelos para teste de APIs (Application Programming Interface) [START_REF] Campbell | Model-based testing of object-oriented reactive systems with Spec Explorer[END_REF][START_REF] Hartman | The AGEDIS tools for model based testing[END_REF]. Estas têm de tratar dois problemas principais: controlar a explosão do número de estados e efectuar a ponte entre os modelos e as suas implementações. O problema da explosão do número de estados deve-se à enorme quantidade de estados que uma aplicação pode ter variando as entradas. A ordem de grandeza pode ser de tal ordem que se torna impraticável analisar todos os casos. Para solucionar tal situação são utilizados critérios de cobertura, com os quais se pretende identificar quais os testes adequados com um número de casos que torna o teste praticável.

B. O Sistema de Programação Spec#

O sistema de programação Spec# (Figura 1) é uma tentativa de desenvolver e manter de maneira eficaz software de alta qualidade [START_REF] Barnett | The Spec# programming system: An overview[END_REF] . Este foi desenvolvido pela Microsoft Research lab e é constituído por três partes, i.e. a linguagem de programação Spec#, o compilador e o verificador estático. A linguagem de programação Spec# é uma extensão à linguagem orientada aos objectos C#. Esta estende o C# introduzindo, tipos não nulos, excepções validadas e fornece ainda métodos na forma de pré-condições e pós-condições que funcionam como invariantes sobre os objectos. 

III. A ABORDAGEM IMPLEMENTADA

A. Extracção de Modelo de Diálogo

A abordagem seguida neste trabalho tem como ponto de partida código fonte de sistemas interactivos (e.g. Java ou Haskell). Tal como referido na secção I, existem dois objectivos essenciais a satisfazer: engenharia reversa do código para um nível adequado de abstracção, e modelação de interacção.

A extracção do modelo de uma interface a partir do código fonte foi implementada através da execução de travessias da árvore abstracta de sintaxe (AST) do programa em análise, obtendo como resultado uma sub-árvore com as instruções da interface. Esta abordagem permite ter em conta os aspectos de interesse, permitindo assim considerar unicamente as partes relevantes relacionadas com a camada de interacção com o utilizador [START_REF] João | The GUISurfer tool: towards a language independent approach to reverse engineering GUI code[END_REF]. O protótipo implementado, designado GUIsurfer, permite extrair e manipular todos os componentes gráficos da aplicação, por exemplo em Java, objectos das classes JButton, Jlabel, JTextField, JProgressBar, JComboBox, JSlider, etc. Após extracção dos dados dos objectos gráficos assim como todos os dados dos métodos sobre estes executados, é possível gerar representações abstractas do comportamento das interfaces através de máquinas de estados [22]. Uma máquina de estados permite abstrair o comportamento dos sistemas interactivos. Com esta representação pretende-se abstrair todos os estados gráficos de um sistema interactivo bem como as acções que interligam esses estados. Assim, a cada estado gráfico deduzido da árvore corresponde um estado na máquina de estados e cada acção sobre a aplicação dá origem a uma transição entre dois estados. Acrescentam-se também na máquina outros dados específicos do código fonte como por exemplo a inicialização de valores, as condições associadas às acções, etc. A primeira fase desta abordagem permite assim extrair modelos de diálogo.

B. Especificação do Modelo de Tarefas

Numa segunda fase, para efectuar os testes de Graphical User Interfaces (GUIs) é necessário codificar um oráculo num nível de abstracção baixo [START_REF] José | Modelbased User Interface Testing With Spec Explorer and ConcurTaskTrees[END_REF]. Sendo o processo moroso e caro, a abordagem definida efectua a geração automática desse oráculo com base num modelo de tarefas a definir manualmente com o apoio dos modelos de diálogo gerados pelo GUIsurfer. Usou-se a notação de modelação de tarefas ConcurTaskTrees (CTT) [START_REF] Paternó | ConcurTaskTrees: An engineered notation for task models[END_REF][START_REF] Warren | The task oriented modelling (TOM) approach to the development of real-time safety-critical systems[END_REF]. Esta fornece duas principais vantagens, i.e. os modelos estão ao mesmo nível de abstracção que os usados no design de interfaces, e o custo do desenvolvimento do oráculo é consideravelmente menor.

C. Construção Automática do Oráculo

A partir do modelo de tarefas CTT é possível definir uma especificação formal que represente uma aplicação interactiva. Uma ferramenta foi desenvolvida, designada TOM (task to oracle mapping) para a geração automática de oráculos a partir de modelos de tarefas [START_REF] José | Modelbased User Interface Testing With Spec Explorer and ConcurTaskTrees[END_REF]. Os oráculos descrevem as acções que o utilizador pode executar (carregar num botão, preencher um campo, etc.) e efeitos que tais acções podem desencadear no sistema em termos de estado da aplicação. Os efeitos de acções do utilizador não dependem exclusivamente do actual estado da aplicação mas também de condições de ambiente [START_REF] José | Modelbased User Interface Testing With Spec Explorer and ConcurTaskTrees[END_REF]. Os modelos são construídos seguindo as linhas de construção delineadas por Paiva [START_REF] Cristina Paiva | Modeling and testing hierarchical guis[END_REF] com as quais é possível construir-se um oráculo em Spec# para modelar sistemas interactivos. Sendo o nível de abstracção utilizado bastante baixo, a geração automática destes oráculos a partir de modelos de tarefas representa uma vantagem significativa [START_REF] José | Modelbased User Interface Testing With Spec Explorer and ConcurTaskTrees[END_REF].

D. Usando o Oráculo

Uma vez o oráculo completo, o Spec Explorer permite gerar uma máquina de estados finita a partir do modelo Spec# e gerar casos de testes. Três critérios de cobertura podem ser aplicados, i.e. Full Transition Coverage onde os casos de teste gerados cobrem todas as transições da máquina de estados finita, Shortest Path onde a sequência de casos de teste corresponde a uma sequência de transições para atingir determinado estado, e Random Walk com uma sequência de casos de teste obtida de forma aleatória. A Figura 2 ilustra a abordagem seguida neste trabalho. O processo, tendo como ponto de partida o código fonte da aplicação em análise, envolve vários modelos, nomeadamente modelos de diálogo e de tarefas. Por fim é feito uso do Spec Explorer para geração e execução dos casos de teste. Após a geração dos casos de testes, os mesmos são executados com o Spec Explorer para determinação das inconsistências e/ou conformidades entre a especificação e a aplicação em análise [START_REF] Cristina Paiva | Modeling and testing hierarchical guis[END_REF].

De forma a usar o oráculo gerado alguns ajustes devem ser feitos para adicionar mais alguma semântica que não tenha sido introduzida no modelo de tarefas. Quando o modelo CTT não descreve por completo o comportamento da GUI a ser testada, a pessoa que irá testar a aplicação tem neste passo a oportunidade de refinar manualmente o oráculo preliminar gerado. Por exemplo, o modelador pode optar por manter um modelo CTT com um baixo nível de detalhe e refinar mais tarde o modelo gerado em Spec#. Uma vez o oráculo pronto, casos de teste são gerados automaticamente e executados sobre a GUI a testar. Diversos autores trabalharam na geração de sistemas interactivos a partir dos modelos, por exemplo TERESA [START_REF] Mori | Design and development of multidevice user interfaces through multiple logical descriptions[END_REF] ou Mobi-D [START_REF] Puerta | Towards a general computational framework for model-based interface development systems[END_REF]. O trabalho desenvolvido concentra-se noutro sentido: testar os sistemas verificando se estes vão de encontro ao modelo gerado. Nesta abordagem o modelo gerado representa o comportamento do sistema implementado e não o comportamento previsto. Tendo em conta esta consideração esta abordagem permite executar testes de regressão já que permite comparar o comportamento do sistema, depois de alterado, com o modelo de como ele se comportava inicialmente. A execução de testes de regressão permite assim garantir que a alteração do sistema não afectou a sua estabilidade. Sendo assim, esta abordagem permite garantir que o sistema ainda contempla os requisitos iniciais. Relativamente ao desenvolvimento destes modelos tornou-se claro que teriam de suportar um nível de detalhe complexo para o contexto de GUI. Modelar diálogos envolvendo wizards e janelas modais cria problemas consideráveis. De facto, os modelos pretendem capturar como os utilizadores interagem com o sistema para atingir determinado objectivo, e não capturem o desenho do sistema em si. Os modelos de tarefas podem ser uma solução viável na geração de oráculos de teste. O que deve ser tido em consideração é que, estes oráculos testam somente um uso "normal" das aplicações. Por "normal" entende-se que os comportamentos esperados são resultado de utilizações de utilizadores típicos e que vão de encontro à aplicação que foi desenhada. Daí que estes oráculos são úteis numa primeira fase de teste onde o objectivo é testar se a aplicação cumpre as condições de utilização típica. Numa segunda fase, pretendese testar a capacidade da GUI em lidar com erros do utilizador e/ou comportamento inesperados. Para tal, uma possibilidade é introduzir alterações no modelo de tarefas para permitir que comportamentos alternativos estejam reflectidos no modelo de tarefas. Alternativamente, um oráculo baseado em controlo de diálogos deverá ser usado.

V. CONCLUSÕES E TRABALHO FUTURO

O teste baseado em modelos pode ter um papel importante na garantia da qualidade e usabilidade dos sistemas interactivos. Apesar de não permitir fornecer uma avaliação correcta das respostas dos utilizadores ao sistema, pode ajudar na identificação de problemas que não foram detectados com outras técnicas de teste de sistemas interactivos. Isto é realizado através de um processo maioritariamente automatizado e sem o custo de testes completos de usabilidade. A técnica será relevante no contexto da engenharia, especificamente na manutenção e redesign. O teste baseado em modelos funciona comparando a execução de uma aplicação executável com um modelo que representa como o sistema se deve comportar. A abordagem apresentada incide inicialmente na geração de modelos de diálogo a partir de código fonte, i.e. uso da ferramenta GUisurfer, sendo estes modelos utilizados como apoio na geração de modelos de tarefas. Finalmente o teste baseado em modelos é efectuado usando a ferramenta desenvolvida por Paiva [START_REF] Cristina Paiva | A model-to-implementation mapping tool for automated model-based GUI testing[END_REF] em conjunto com o Spec Explorer. A abordagem apresentada permite gerar e executar casos de teste de forma semi-automatizada, mas não dispõe de informações que possam contribuir na automatização da análise dos resultados. Neste contexto, seria interessante que a abordagem implementasse funções que desempenhassem o papel de oráculos, apresentando informações do teste relativas ao cumprimento ou não dos requisitos de teste especificados.

AGRADECIMENTOS

Este trabalho é financiado por Fundos FEDER através do Programa Operacional Factores de Competitividade -COMPETE e por Fundos Nacionais através da FCT -Fundação para a Ciência e a Tecnologia no âmbito do projecto FCOMP-01-0124-FEDER-020554.

REFERÊNCIAS BIBLIOGRÁFICAS

Figura 1 :

 1 Figura 1: O sistema de programação Spec#

Figura 2 :

 2 Figura 2: Geração de casos de teste baseado em modelos