Uma Ferramenta para Geração Automática de Testes Funcionais e Protótipos de Interface a partir de Casos de Uso Ernesto C. Brasil 1, Thiago C. de Sousa 2 1 Centro de Ensino Unificado de Teresina (CEUT) Teresina PI 2 Universidade de São Paulo (USP) São Paulo SP ernestocid@ceut.com.br, thiago@ime.usp.br Abstract. In this paper we will present a tool that is capable of generating functional tests and user interface prototypes to a Web application based on requirements specified on a controlled natural language. Resumo. Neste artigo apresentaremos uma ferramenta capaz de gerar testes funcionais e protótipos de interfaces de uma aplicação Web a partir de requisitos especificados em uma linguagem natural controlada. 1. Introdução Quando falamos de Engenharia de Software, e mais especificamente em Engenharia de Requisitos, os casos de uso [Jacobson 1992] podem ser considerados um padrão no que diz respeito a especificação de requisitos de software. A partir deles, as funcionalidades da aplicação podem ser descritas em cenários que demonstram a interação do usuário com a aplicação em questão. Testes funcionais [Myers 1972] têm como objetivo simular a interação do usuário com a aplicação, desta forma, eles tentam validar se esta atende a requisitos especificados previamente, geralmente em algum tipo de documentação, como por exemplo, especificações de casos de uso. Outra técnica bastante conhecida em ambientes de desenvolvimento de software é a utilização de protótipos da aplicação, que podem ser utilizados para validação de requisitos, permitindo ao cliente ter uma visão de como o software irá se comportar ainda em estágios iniciais do desenvolvimento, o que possibilita correções de erros de maneira rápida e sem grandes impactos. Visto que casos de uso fornecem informações preciosas para o desenvolvimento de testes funcionais, e também descrições de interfaces da aplicação, por que não gerá-los automaticamente a partir destes casos de uso? Neste artigo apresentaremos uma ferramenta que, a partir de artefatos utilizados para descrição de requisitos (casos de uso, glossário e especificações de interface) escritos em uma linguagem natural controlada, trata de convertê-los em protótipos de interface em HTML e em testes funcionais para uma ferramenta de testes para aplicações Web. O artigo está organizado da seguinte maneira: na Seção 2 apresentamos alguns trabalhos relacionados e mostramos vantagens da nossa abordagem sobre estes, na Seção 3 mostramos a arquitetura da ferramenta e discutimos sobre cada um dos itens que a compõem, na Seção 4 fazemos algumas conclusões e listamos alguns trabalhos futuros.
2. Trabalhos Relacionados Existem alguns trabalhos na área e acreditamos que alguns deles podem ser melhorados em certos aspectos. Nesta seção apresentaremos alguns destes trabalhos, explicando suas abordagens e as vantagens de nossa abordagem em relação aos mesmos. Alguns destes trabalhos também focam na geração automática de testes a partir de requisitos, mas utilizam outras técnicas para a elicitação destes. Em [Xiaochun et al. 2008] e [Huang and Chen 2008], os autores utilizam, respectivamente, tabelas para a especificação de cenários de utilização do software e extensões de diagramas de atividades da UML (Unified Modeling Language) e, a partir destes artefatos geram testes. Acreditamos que a utilização deste tipo de técnica pode dificultar o entendimento da especificação de requisitos por parte do cliente, prejudicando sua colaboração com o projeto, o que é um dos princípios básicos do Manifesto Ágil 1. Outro fator que acreditamos desencorajar a utilização do trabalho de [Xiaochun et al. 2008], é a utilização de uma ferramenta proprietária para a execução dos testes como o Rational Functional Tester. Existem também trabalhos como o de [Li and Miao 2008] onde o foco está na geração de casos de testes, mas que não implementam os testes propriamente ditos. A utilização de abordagens como as dos trabalhos anteriores, pode causar impactos em um processo de desenvolvimento de software real, por forçar a equipe responsável pelo projeto a aprender métodos incomuns. Em nosso trabalho tentamos manter a utilização de casos de uso, um dos padrões mais comuns para especificação de requisitos funcionais, adicionando apenas uma linguagem controlada em seu escopo. Por ser semelhante a uma linguagem natural, a linguagem controlada utilizada pela nossa ferramenta oferece simplicidade, permitindo que até mesmo clientes possam colaborar na elicitação de requisitos e consequentemente na elaboração dos testes para a aplicação. Outra melhora que nosso trabalho apresenta em relação aos demais é a utilização de uma ferramenta mais moderna para execução aplicação dos testes funcionais: o Selenium 2. Existem também trabalhos relacionados a geração de protótipos de interface. Em [Elkoutbi et al. 2006] os autores aplicam uma combinação de diagramas de colaboração, casos de uso e atividade da UML, suportados por especificações formais, para a geração de protótipos de interface da aplicação. Essa abordagem utiliza muitas e distintas fontes para a especificação, o que não consideramos amigável ao usuário. Em [Olek et al. 2007] os autores desenvolveram uma ferramenta chamada UC Workbench, utilizada para a especificação de casos de uso em conjunto com rascunhos de interface, para assim gerar um modelo de documentação. Esta ferramenta possui ótima usabilidade, mas poderia ser bem melhor se utilizasse protótipos funcionais ao invés de rascunhos. Nossa ferramenta tenta unir uma forma simples de especificação à praticidade de protótipos reais. 3. A Ferramenta Proposta O objetivo principal deste trabalho é desenvolver uma ferramenta que seja capaz de receber como entrada cenários de casos de uso, um glossário com o mapeamento das entidades da aplicação e especificações da interface com o usuário, e a partir destes artefatos gerar testes funcionais para o Selenium e protótipos de páginas HTML. Por ser uma prova de 1 http://www.agilemanifesto.org/ 2 http://www.seleniumhq.org
conceito, inicialmente focaremos apenas em casos de uso simples que seguem o padrão CRUD, ou seja, casos de criação (create), leitura (read), atualização (update) e remoção (delete) de registros em uma aplicação Web. Todos os artefatos são escritos em uma linguagem natural controlada especificada para a ferramenta. 3.1. Arquitetura Nesta seção apresentaremos a arquitetura da ferramenta, explicando cada uma de suas partes. Uma visão geral de seus componentes pode ser vista na Figura 1. Figura 1. Visão geral da arquitetura da ferramenta Para fazer a geração automática, criamos um interpretador para a linguagem controlada que definimos. Ele será responsável por ler toda a especificação e traduzi-la em arquivos XML que conterão todas as informações relevantes necessárias para a geração de código. Os arquivos XML gerados serão então passados ao gerador da ferramenta, juntamente com um arquivo de configuração, que irá ler estes arquivos e gerar como saída testes funcionais e protótipos de interface. Nas próximas sub-seções discutiremos cada item da arquitetura, utilizando como exemplo um cenário Alterar Senha. Neste cenário o usuário da aplicação deverá estar previamente autenticado, preencher um formulário com os campos Senha atual, Nova senha e Repetir nova senha, e logo após deve clicar no botão Alterar. 3.1.1. Cenário A ferramenta utiliza uma linguagem natural controlada, ou seja, uma linguagem semelhante a natural mas com algunas restrições para formalizá-la. Trabalhos realizados anteriormente [Schwitter 2002] provam que esta abordagem pode ser bastante útil pela facilidade de compreensão, o que favorece a utilização da ferramenta por usuários comuns, não necessariamente experts em termos da computação. A linguagem que criamos define a especificação de um cenário como uma sequência de passos, onde cada passo é formado por um ator, uma ação exercida por ele
e um objeto que sofre a ação. O ator representa o usuário que esta utilizando a aplicação ou a própria aplicação. A ação é um verbo que representa ações como clicar, preencher, selecionar etc. Cada um desses verbos integrados a linguagem foi mapeado para representar uma chamada de método da API do Selenium, desta forma, ao declararmos uma ação estamos na verdade especificando um método Selenium que será executado. Na Listagem 1 apresentamos um exemplo de como o cenário Alterar Senha seria especificado utilizando a linguagem definida pela ferramenta. A estrutura do cenário possui um título que tem como objetivo identificar o cenário, uma pré-condição que define alguns passos que deverão ser executados antes que o cenário propriamente dito possa ser executado, e um conjunto de passos que descrevem as ações que serão executadas no cenários. Utilizamos a abordagem de cenários por estes descreverem bem como o usuário deverá utilizar o sistema e por ser de fácil entendimento tanto por parte dos desenvolvedores como por parte dos usuários. Em [Carrol 1999] o autor enumera outras vantagens da utilização de cenários. C e n a r i o 1 A l t e r a r Senha : Pre c o n d i c a o : E x e c u t a r Login ; 1. A a p l i c a ç ã o e x i b e a s e g u i t e t e l a : A l t e r a r Senha 2. U s u a r i o p r e e n c h e r campo Senha A t u a l 3. U s u a r i o p r e e n c h e r campo Nova Senha 4. U s u a r i o p r e e n c h e r campo R e p e t i r Nova Senha 5. U s u a r i o c l i c a r b o t a o A l t e r a r Listagem 1. Exemplo de Especificação de Cenário 3.1.2. Glossário O glossário possui informações sobre as entidades presentes na aplicação e seus respectivos atributos. Dentre estas informações podemos citar: tamanhos de atributos, atributos obrigatórios, tipos de dados etc. Ele será utilizado sempre que a ferramenta necessitar de alguma dessas informações, como por exemplo, ao gerar os protótipos de interface, o gerador necessita saber a quantidade de caracteres máximo de um determinado campo. 3.1.3. Especificações de UI Praticamente todo caso de uso possui uma interface na qual o usuário irá interagir com a aplicação. Pensando nisso, nós também desenvolvemos uma linguagem controlada simples para especificações de interfaces com o usuário. Um exemplo de interface da aplicação especificada utilizando esta linguagem é mostrada na Listagem 2. Uma interface é composta por um conjunto de componentes de uma página HTML como: inputs, checkboxes, botões etc. No caso de uso Alterar Senha, a aplicação deverá exibir uma página contendo os campos Senha atual, Nova senha, Repetir nova senha e um botão Alterar. Todos estes compontes se encontram em um escopo de escrita, o que significa que todos eles podem receber valores. A ferramenta também suporta escopos de leitura, onde todos componentes presentes neste, seriam do tipo read-only.
Cada componente pode ser anotado com uma referência a um item do glossário. No exemplo apresentado, todos os 3 campos da página fazem referência ao atributo Senha de um usuário. A partir destas, a ferramenta pode conseguir mais informações sobre o campo, como por exemplo, o número máximo de caracteres que ele deve permitir. Nome p a g i n a : A l t e r a r Senha E s c r i t a : Senha Senha a t u a l { U s u a r i o. Senha } Senha Nova senha { U s u a r i o. Senha } Senha R e p e t i r nova senha { U s u a r i o. Senha } Botao A l t e r a r Fim Listagem 2. Exemplo de especificação de UI 3.1.4. Parser e Arquivos XML O parser é a parte da ferramenta responsável por receber cenários, especificações de UI e glossários, e convertê-los em um formato mais estruturado e legível ao gerador, no caso, XML. Este arquivo organiza todas as informações relevantes do cenário em nós, existem nós como name para identificar o cenário, precondition para definir pré-condições, step para definir os passos de um cenário, actor para reprentar um ator, action para uma ação, entre outros. A utilização de um formato intermediário como XML também permite que estes arquivos possam ser utilizados por outras ferramentas. A mesma metodologia também se aplica as especificações de UI e ao glossário, ambos possuem representações XML que serão passadas ao gerador. 3.1.5. Arquivo de Configuração O arquivo de configuração possui algumas propriedades extras, necessárias para o funcionamento da ferramenta. Algumas dessas propriedades incluem, diretório onde os artefatos se encontram, arquivos CSS (Cascading Style Sheets) utilizados etc. 3.1.6. Gerador O componente da ferramenta responsável por ler os arquivos XML e traduzí-los em código real é chamado gerador. Ele é divido em dois geradores específicos, um é responsável pela geração dos protótipos de interface, o outro cuida da geração de testes funcionais para o Selenium. Para criar os protótipos de interface, o gerador de protótipos lê o arquivo XML correspondente a uma interface da aplicação, que contém em seus nós os componentes HTML presentes na página, e a partir daí gera a página HTML propriamente dita. Da mesma forma, o gerador de testes funcionais extrai do arquivo XML os nós step e os traduz em chamadas de métodos da Selenium Remote Control API. Cada método é definido por um verbo mapeado previamente, por exemplo, o verbo clicar corresponde a uma chamada do método click no Selenium. Os componentes nos quais as ações serão
aplicadas são definidos no conteúdo do nó que representa a ação. O identificador para o componente deve ser idêntico ao informado nas especificações de interface. Os valores que serão informados em um campo são, em alguns casos, gerados aleatoriamente, e em outros, são valores padrões pré-definidos. 4. Conclusões e Trabalhos Futuros Esperamos que com este trabalho possamos iniciar uma plataforma para especificação de requisitos, que seja simples e traga agilidade a ambientes de desenvolvimento, a partir da automação da geração de código para testes funcionais e protótipos de interface com o usuário. Acreditamos também que com a geração direta destes testes e interfaces a partir dos requisitos, possa prover testes e interfaces mais fiéis às especificações iniciais, proporcionando assim o desenvolvimento de softwares que atendam as reais necessidades do cliente. Outra melhoria que a ferramenta pode trazer diz respeito a colaboração do usuário. Visto que a linguagem controlada utilizada para a especificação dos artefatos é simples e de fácil compreensão, ela pode favorecer a colaboração do clientes no projeto, permintindo que estes ajudem a escrever tais artefatos. A ferramenta desenvolvida trata-se de uma prova de conceito e até o momento aborda apenas os padrões CRUD. Como trabalhos futuros pretendemos expandir o seu escopo para que ela possa tratar de cenários mais complexos, que fogem esse padrão. Dentre outras melhorias poderiamos também citar: a integração da ferramenta a uma IDE como o Eclipse, o que acreditamos que pode prover mais recursos e melhorar a aceitação e a geração de mútiplos casos de testes, para melhorar a cobertura dos mesmos. Referências Carrol, J. M. (1999). Five reasons for scenario-based design. 32nd Hawaii International Conference on System Sciences. Elkoutbi, M., Khriss, I., and Keller, R. K. (2006). Automated prototyping of user interfaces based on uml scenarios. Automated Software Engineering. Huang, C. and Chen, H. (2008). A tool to support automated testing for web application scenario. The IEEE International Conference on Systems, Man and Cybernetics. Jacobson, I. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1st edition. Li, L. and Miao, H. (2008). An approach to modeling and testing web applications based on use cases. 2008 International Symposium on Information Science and Engineering. Myers, G. J. (1972). The Art of Software Testing. Wiley, 1st edition. Olek, L., Michalik, B., Nawrocki, J., and Ochodek, M. (2007). Quick prototyping of web applications. Balancing Agility and Formalism in Software Engineering. Schwitter, R. (2002). English as a formal specification language. 13th International Workshop on Database and Expert System Applications. Xiaochun, Z., Bo, Z., Juefeng, L., and Qui, G. (2008). A test automation solution on gui functional test. The IEEE International Conference on Industrial Informatics.