Willame Pereira de Oliveira

Imaginarium: Um prottipo para aux o lio ` a automao de testes funcionais para ca aplicaes WEB co

Teresina Fevereiro, 2009

Willame Pereira de Oliveira

Imaginarium: Um prottipo para aux o lio ` a automao de testes funcionais para ca aplicaes WEB co
Monograa apresentada ao curso de Anlise a e Desenvolvimento de Sistemas como pre requisito para a obtenao do t c tulo de Tecnlogo em Anlise e Desenvolvimento de o a Sistemas sob a orientao do professor Thica ago Alves Elias da Silva e co-orientao do ca professor Pedro de Alcntara dos Santos a Neto.

Centro Federal de Educacao Tecnologica do Piau - CEFET Curso de Analise e Desenvolvimento de Sistemas

Teresina Fevereiro, 2009

A presente monograa, apresentada pelo(a) aluno(a) poder ser submetida a exposio e defesa perante a banca examinadora designada pela a ` ca coordenaao do curso de Anlise e Desenvolvimento de Sistemas do CEFET-PI. c a

Teresina,

de

de 2009.

Nome do(a) professor(a) orientador(a)

Assinatura do(a) professor(a) orientador(a)

O(A) autor(a) deste trabalho autoriza a coordenaao do curso de Anlise e Desenvolc a vimento de Sistemas do CEFET-PI a divulg-lo, no todo ou em parte, resguardados os a direitos autorais conforme legislao vigente. ca Teresina, de de 2006.

Assinatura do(a) aluno(a)

Agradecimentos
Agradeo primeiramente a Deus pelo dom da vida. Seu maior ensinamento, o Amor, c tem me conduzido na criaao da minha prpria histria. c o o Agradeo a todos os meus familiares, em especial ` minha Me. Ela esteve mais c ` a a preocupada com a realizaao deste trabalho do que eu. c Agradeo ` todos os meus amigos da INFOWAY - Consultoria e Solues em Gesto c a co a de Sistemas de Sade LTDA, por entenderem minhas faltas. Agradeo em especial ao u c Diogo Vin cius, Thalisson Alves, Airton Pereira e Danilo Medeiros. No sei o que seria a deste trabalho sem a ajuda deles. Serei eternamente grato. Agradeo ao co-orientador Pedro de Alcantra por toda ateno dedicada e por suas c a ca idias que foram vitais para a concretizaao deste trabalho. Agradeo ao orientador Thie c c ago Elias por toda sua amizade em momentos de diculdades na minha vida acadmica. e Agradeo a todos os demais amigos que contribuiram dando orientaoes e motivaao c c c para que este trabalho fsse concluido. o

Resumo
Praticamente tudo o que utilizamos, ou controlado por software ou possui algum e necessrio se ter mecanismos para garantir a qualidade desses software embutido. E a sistemas, evitando erros durante o seu uso. O teste uma dessas atividades relacionadas e a garantia da qualidade no desenvolvimento de software. Existem diversas ferramentas que ` oferecem suporte `s atividades de teste, visando reduzir os grandes custos da introduo a ca desta prtica no desenvolvimento. O Selenium uma ferramenta voltada especicamente a e para a automao de testes em aplicaoes WEB, permitindo a criao de testes funcionais. ca c ca Nesse trabalho proposto um prottipo de uma API em Java, chamada Imaginarium, e o para oferecer aux a automao de testes com o Selenium, possibilitando que se tenha lio ` ca maior produtividade no uso dessa ferramenta. Palavras-chave: Testes de software, Ferramentas de teste, Testes funcionais, Aplicaes WEB, Selenium, API Java, Imaginarium. co

Abstract
Almost everything that we manipulate is controled by software or has some embedded software. Its important to have mechanisms aiming at ensureing the quality of these systems, avoiding problems during their usage. The use of the test is one of these activities related to quality assurance in the software development stage. There are several tools that are used in test applications, aiming to reduce the immense cost of introducing this practice in the development. Selenium is a tool built specically for testing automation in Web applications, allowing the use of functional tests. In this work its proposed a prototype of an API in Java, called Imaginarium, to help automated tests using Selenium, enabling increaseing productivity in the use of this tool. Keywords: Software testing, test tools, functional testing, Web applications, Selenium, Java API, Imaginarium.

Sumrio a

Lista de Figuras Lista de Siglas 1 Introduo ca 1.1 1.2 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.3 Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Espec cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12 p. 13 p. 14 p. 14 p. 14 p. 15 p. 16 p. 18 p. 18 p. 21 p. 22 p. 22 p. 24 p. 24 p. 25 p. 28

Organizao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . ca

2 Testes de Software 2.1 Tipos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 Testes de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . Testes de Integraao . . . . . . . . . . . . . . . . . . . . . . . . c Testes de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3.1 Testes Funcionais . . . . . . . . . . . . . . . . . . . . .

3 Ferramentas de Teste 3.1 Tipos de ferramentas de teste . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 Ferramentas de teste de unidade . . . . . . . . . . . . . . . . . . Ferramentas de teste funcional . . . . . . . . . . . . . . . . . . .

4 Selenium: Uma ferramenta para criao de testes funcionais para ca aplicaoes WEB c p. 29

4.1 4.2 4.3 4.4

Sobre a aplicao utilizada nos exemplos . . . . . . . . . . . . . . . . . ca Selenium Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selenium IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selenium RC (Remote Control ) . . . . . . . . . . . . . . . . . . . . . .

p. 29 p. 31 p. 34 p. 36

5 Desenvolvendo testes com o Selenium utilizando o padro de Proa cedimentos e Casos de teste 5.1 5.2 5.3 Criando um Procedimento e Casos de teste para o Login da aplicaao . c Capturando as aes para o Cadastro de Clientes da aplicao . . . . . co ca Criando um Procedimento e Casos de teste para o Cadastro de Clientes da aplicaao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c 5.4 Concluses a respeito do padro de Procedimentos e Casos de teste . . o a p. 50 p. 50 p. 52 p. 52 p. 54 p. 56 p. 56 p. 57 p. 43 p. 44 p. 46

6 A API Imaginarium 6.1 6.2 6.3 Principais tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . Documentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ca Desenvolvendo testes funcionais com a Imaginarium . . . . . . . . . . . 6.3.1 6.3.2 6.3.3 Congurando a API . . . . . . . . . . . . . . . . . . . . . . . . Gerando os Procedimentos e Casos de teste para o Login . . . . Gerando os Procedimentos e Casos de teste para o Cadastro de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Anlise de produtividade . . . . . . . . . . . . . . . . . . . . . . . . . . a 6.4.1 6.4.2 6.4.3 6.4.4 6.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 60 p. 63 p. 64 p. 64 p. 64 p. 64 p. 65 p. 68

Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anlise dos resultados . . . . . . . . . . . . . . . . . . . . . . . a

Concluses sobre o uso da Imaginarium . . . . . . . . . . . . . . . . . . o

7 Concluso a

Referncias e Anexo A -- Classe para Gerao dos Procedimentos de Teste dos Caca dastros

p. 70

p. 73

Lista de Figuras
1 2 3 4 5 6 7 8 9 10 11 12 Procedimento de teste de login . . . . . . . . . . . . . . . . . . . . . . . Caso de teste para login invlido a . . . . . . . . . . . . . . . . . . . . . p. 17 p. 17 p. 26 p. 26 p. 28 p. 30 p. 30 p. 31 p. 33 p. 34 p. 35

Classe Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe TesteProduto . . . . . . . . . . . . . . . . . . . . . . . . . . . . Execuo da classe TesteProduto como Teste JUnit . . . . . . . . . . . ca Tela inicial da aplicao. . . . . . . . . . . . . . . . . . . . . . . . . . . ca Menu com as opoes de cadastro. . . . . . . . . . . . . . . . . . . . . . c TestRunner.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teste escrito em Selnes. . . . . . . . . . . . . . . . . . . . . . . . . . . e Cdigo HTML do Test Suite. . . . . . . . . . . . . . . . . . . . . . . . o Selenium IDE com aoes gravadas. . . . . . . . . . . . . . . . . . . . . c Utilizando o comando AssertText para vericar a mensagem exibida na tela. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 36 p. 38 p. 39 p. 39 p. 40 p. 41 p. 41 p. 41 p. 42 p. 44

13 14 15 16 17 18 19 20 21

Diagrama de funcionamento do Selenium Remote Control. . . . . . . . Servidor do Selenium iniciado . . . . . . . . . . . . . . . . . . . . . . . Servidor do Selenium em modo interativo . . . . . . . . . . . . . . . . . Exportando caso de teste para uma linguagem de programaao. . . . . c Caso de teste exportado para Java. . . . . . . . . . . . . . . . . . . . . Execuao do teste escrito em Java. . . . . . . . . . . . . . . . . . . . . c Resultado da execuo no servidor do Selenium RC. . . . . . . . . . . . ca Teste sendo executado no Selenium Core por chamada do servidor. . .

Procedimento de Login criado a partir do teste escrito em Java . . . . .

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Classe de teste do Procedimento de Login . . . . . . . . . . . . . . . . Pgina de Cadastro de Clientes . . . . . . . . . . . . . . . . . . . . . . a Campo Munic pio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incluso de Dependente a . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 45 p. 47 p. 47 p. 47 p. 48 p. 49 p. 51 p. 53 p. 54 p. 55 p. 57 p. 57 p. 59 p. 59 p. 60 p. 61 p. 61 p. 62 p. 63 p. 63 p. 65 p. 65 p. 66 p. 73

Teste de Cadastro de Cliente exportado para Java . . . . . . . . . . . . Classe de Procedimento de Cadastro de Cliente . . . . . . . . . . . . . Classe de teste para o cadastro de clientes . . . . . . . . . . . . . . . . Funcionamento da Imaginarium . . . . . . . . . . . . . . . . . . . . . . Diagrama de Classes da API . . . . . . . . . . . . . . . . . . . . . . . . Trecho de cdigo da classe Imaginarium: mtodos clickButton . . . . . o e Imaginarium.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilizando a classe ProcedureGenerator . . . . . . . . . . . . . . . . . . Classe ProcedureLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe TestLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilizando ProcedureGenerator para o Cadastro de Clientes . . . . . . HTML do Link Cadastros . . . . . . . . . . . . . . . . . . . . . . . . . Implementao do mtodo clickSectionAndWait . . . . . . . . . . . . . ca e Classe ProcedureCliente . . . . . . . . . . . . . . . . . . . . . . . . . . Classe TestCliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alteraao na classe ProcedureCliente para vericaao de campos AJAX c c Tabela com os resultados obtidos . . . . . . . . . . . . . . . . . . . . . Grco Ferramenta x Tempo gasto . . . . . . . . . . . . . . . . . . . . a Procedimentos de Login . . . . . . . . . . . . . . . . . . . . . . . . . . Classe para Gerao dos Procedimentos de Teste dos Cadastros . . . . ca

Lista de Siglas
API - Application Programming Interface, p. 13 AJAX - Asynchronous JavaScript and XML, p. 15 IEEE - Institute of Electrical and Electronics Engineers, p. 16 CASE - Computer Aided Software Engineering, p. 24 CAST - Computer Aided Software Testing, p. 24 DHTML - Dynamic HiperText Markup Language, p. 29 XML - Extensible Markup Language, p. 29 HTML - HyperText Markup Language, p. 31 IDE - Integrated Development Environment, p. 33 HTTP - HyperText Transfer Protocol, p. 37 UI - User Interface, p. 52

12

Introduo ca

Sistemas de software esto cada vez mais presentes no nosso dia a dia. Praticamente a tudo o que utilizamos ou controlado por software ou possui algum software embutido e (SPILLNER; LINZ; SCHAEFER, 2007). Temos celulares, automveis, avies e satlites, todos o o e incorporam mais e mais funoes controladas por software. Da mesma maneira, as orgac nizaoes dependem de software para executarem suas atividades de forma rpida, segura c a e ecaz. Assim, o software crucial para o crescimento e sucesso de qualquer organizao. e ca Mas, para que os softwares funcionem corretamente e produzam os resultados esperados, necessrio se ter mecanismos que garantam a qualidade desses sistemas, evitando, assim, e a erros durante sua utilizao. ca As tcnicas para Vericaao e Validao (V & V) so algumas das atividades relae c ca a cionadas a garantia da qualidade de software. Essas atividades de V & V destinam-se ` a mostrar que um sistema est de acordo com suas especicaoes e que ele atende as a c ` expectativas do cliente comprador do sistema (SOMMERVILLE, 2003). Existem diversas tcnicas de V & V, mas, basicamente, podemos divid e -las em dois grupos: as que no exigem a execuo do software e as que exigem. As que no exigem, a ca a tentam determinar propriedades que devem ser vlidas independentemente da execuo. a ca Como exemplo dessas tcnicas, podemos citar: a vericaao de modelos, a anlise esttica, e c a a as revises e as inspees. As demais tcnicas tentam encontrar falhas atravs da anlise o co e e a do produto durante sua execuao, como por exemplo, a simulaao, a execuao simblica c c c o e o teste (IEEE, 1990). O teste consiste em comparar o comportamento de um programa com o comportamento esperado de acordo com seus requisitos. Se h diferena nesses comportamentos, a c ento isso signica que h problemas no produto e que ele deve ser corrigido. Assim, a a o teste de software uma tarefa muito importante e dif no processo de desenvolvie cil mento. Ele contribui para reduzir o risco no uso do software, uma vez que erros podem ser encontrados pelo teste (SPILLNER; LINZ; SCHAEFER, 2007).

13

Diversos tipos de ferramentas existem para oferecer suporte `s atividades de teste. H a a tanto ferramentas que auxiliam nas atividades de planejamento e acompanhamento dos testes, como tambm ferramentas que automatizam a execuo dos testes. Dentre essas e ca ultimas, tm-se ferramentas que se baseiam na gravao das aoes realizadas nas telas e ca c da aplicaao testada. Essas aes podem ser re-executadas, automatizando-se, assim, o c co processo de teste. Dentre essas ferramentas, tem-se o Selenium. O Selenium (SELENIUM, 2009) uma ferramenta Open Source voltada especicamente e para a automao de testes em aplicaes WEB. Os testes criados com essa ferramenta ca co so capazes de simular o uso da aplicaao pelo usurio nal. Essa ferramenta permite, a c a assim, a criaao de testes funcionais, ou seja, testes que vericam se as funcionalidades c do software atendem aos requisitos, sem que haja uma vericao da estrutura interna do ca produto. Nesse trabalho, proposta a Imaginarium, um prottipo de uma API escrita na e o linguagem Java para oferecer aux ` automaao de testes utilizando-se o Selenium. lio a c

1.1

Justicativa

O teste , como j dito anteriormente, uma atividade de grande importncia para e a a se ter qualidade de software. No entanto, mesmo tendo esse conhecimento, muitas organizaoes no executam essa atividade devido aos grandes custos relacionados a sua c a ` execuao. De acordo com Ian Sommerville (SOMMERVILLE, 2003), a atividade de teste c pode representar, dependendo do tipo de sistema, cerca de 50 por cento dos custos totais de desenvolvimento. Isso acontece porque necessria a introduao de atividades adicioe a c nais no desenvolvimento. Alm dos custos, a restriao de cronograma e a falta de cultura e c nessa disciplina so outros fatores que fazem com que muitas organizaoes no utilizem a c a testes durante seu processo de desenvolvimento. Isso d margem para que surjam muitas falhas, e esses custos com falhas so gerala a mente bem superiores aos custos adicionados pelas atividades de teste. Dados publicados pelo NIST, citados por Pedro de Alcntara (NETO, 2005), a armaram que U$ 59.500.000.000,00 o valor relativo ao custo de falhas em softwares desenvolvidos e nos Estados Unidos, apenas em 2002. Esse mesmo relatrio estimou que mais de 37% o desse custo (U$ 22.200.000.000,00) poderia ter sido eliminado se a infraestrutura para testes fosse melhorada. Alm disso, de acordo com Pressman (PRESSMAN, 2006), quanto mais cedo um dee

14

feito for descoberto dentro do processo de desenvolvimento, menores sero os custos para a corrigir os erros associados. Assim, mesmo que a atividade de testes introduza custos adicionais, em contrapartida ela propicia a descoberta de erros mais cedo, o que normalmente gera uma diminuiao geral de custos. c A atividade de teste, portanto, est associada a grandes custos, mas no utiliz-la a a a implica em custos mais elevados. O uso de ferramentas para apoiar essa atividade algo e que se torna fator vital, pois elas ajudam, de forma geral, a minimizar os gastos envolvidos. No escopo de ferramentas de teste para aplicaoes WEB, o Selenium uma ferramenta que c e se destaca por ser simples de usar e possuir suporte a diferentes navegadores e linguagens de programaao. c Porm, os testes criados pelo Selenium apresentam muito cdigo repetido, o que deixa e o o teste mal leg e dif de manter. Muito tempo deve-se gastar para manter testes vel cil criados de uma forma organizada, leg e facilmente manuten vel vel. Assim, necessrio se e a ter algum mecanismo que auxilie a criaao de testes utilizando-se o Selenium, trazendo, c como consequncia, uma maior produtividade. e Essa necessidade justica o desenvolvimento da API proposta nesse trabalho. Ela tem por objetivo facilitar a criao de testes mais leg ca veis, reusveis e manuten a veis, oferecendo maior produtividade para o desenvolvimento de testes com o Selenium.

1.2
1.2.1

Objetivos
Geral

Oferecer uma contribuio para a area de testes por meio da criao da Imaginarium, ca ca um prottipo de uma API em Java que auxilie a criaao de testes funcionais em aplicaes o c co WEB utilizando o Selenium, trazendo, como consequncia, uma maior produtividade no e uso dessa ferramenta. Por meio disso, tem-se uma reduao de custos e maior incentivo c para a introduao de atividades de testes funcionais em equipes de desenvolvimento, c contribuindo para uma melhoria geral na qualidade de softwares desenvolvidos.

1.2.2

Espec cos

Apresentar uma viso bsica da area de testes, explicando principais conceitos uteis a a para este trabalho; Descrever as diversas categorias de ferramentas de testes;

15

Apresentar um estudo sobre a ferramenta de teste de aplicaoes WEB, o Selenium; c Propor um padro para a criaao de testes funcionais utilizando o Selenium; a c Demonstrar como se constri testes robustos com o Selenium utilizando o padro o a proposto; Apresentar como fazer testes em aplicaoes baseadas em AJAX utilizando o Selec nium; Explicar as desvantagens do uso do Selenium para a criaao de testes funcionais em c equipes de desenvolvimento; Propor uma API prottipo em Java que auxilie a automao de testes utilizando o ca o Selenium, facilitando a criao de testes leg ca veis, simples de manter e de reusar, encapsulando o uso do padro proposto, trazendo, como consequncia, maior a e produtividade na criao de testes funcionais para aplicaoes WEB; ca c

1.3

Organizao do Trabalho ca

O presente trabalho est dividido em seis cap a tulos. O primeiro consiste nesta introduao. No segundo, so apresentados conceitos relativos a area de teste que possuem c a ` grande importncia para o entendimento dos cap a tulos posteriores do trabalho. No terceiro cap tulo, so descritas as diversas categorias de ferramentas de teste, demonstrando-se a a categoria em que a ferramenta Selenium se enquadra. No quarto cap tulo, apresentado e um estudo a respeito da ferramenta Selenium, explicando-se como ela funciona e como utiliz-la. No quinto cap a tulo, proposto um padro para a criao de testes com o Selee a ca nium ao mesmo tempo em que demonstrado como se criar testes voltados para aplicaes e co WEB baseadas em AJAX. Ainda no quinto cap tulo so discutidos os problemas surgidos a durante o desenvolvimento de testes com o Selenium. No sexto cap tulo, apresentado e a Imaginarium, um prottipo de uma API Java desenvolvida para resolver os problemas o surgidos com o uso do Selenium. Por m, aps o sexto cap o tulo, tem-se a concluso e, em a seguida, as referncias utilizadas neste trabalho. e

16

Testes de Software

De uma forma detalhada, podemos dizer que o teste de software a vericao e ca dinmica do funcionamento de um programa, utilizando um conjunto nito de casos a de teste, adequadamente escolhido dentro de um dom nio de execuao innito, contra c seu comportamento esperado (IEEE, 2004). Nesse conceito, algumas palavras merecem destaque: Dinmica: o teste exige a execuo do produto, embora algumas de suas atividades a ca possam ser realizadas antes do produto estar nalizado; Conjunto nito: testar todas as poss veis entradas de um software geralmente e imposs vel, mesmo para produtos simples; Escolhido: necessrio selecionar testes com alta probabilidade de encontrar defeie a tos, preferencialmente com o m nimo de esforo; c Comportamento esperado: para que um teste possa ser executado necessrio saber e a o comportamento esperado, para que ele possa ser comparado com o obtido; Existem alguns conceitos bsicos relacionados a rea de teste que so de grande ima `a a portncia para esse trabalho. So eles: Caso de teste, Procedimento de teste, Su de a a te teste, orculo, critrios de teste e mtodos de criaao de teste. Algumas descrioes desses a e e c c conceitos foram baseadas no Glossrio de Terminologia de Engenharia de Software da a IEEE (IEEE, 1990) e no Guia de Corpo de Conhecimento em Engenharia de Software (IEEE, 2004). Um caso de teste especica como deve ser testada uma parte do software. Essa especicaao inclui as entradas, sa c das esperadas e condies sob as quais os testes devem co ocorrer. Um procedimento de teste detalha as aes a serem executadas em um determico nado caso de teste. As Figuras 1 e 2 exibem um exemplo de procedimento de teste para login num sistema e um caso de teste para um login invlido. O padro utilizado para a a

17

a especicaao desse procedimento e desse caso de teste foi extra do livro Engenharia c do de Software: Fundamentos, mtodos e padres de Wilson de Pdua Paula Filho (PDUA, e o a a 2003).

Figura 1: Procedimento de teste de login

Figura 2: Caso de teste para login invlido a E importante observar que um caso de teste s faz sentido se for especicado o (s) o procedimento (s) de teste associado (s). Sem essa associaao no poss determinar c a e vel o que deve ser feito com as entradas especicadas no caso de teste. Por outro lado, o procedimento de teste independente dos dados utilizados nos casos de teste. e Su de teste um conjunto de vrios casos de teste para um componente ou siste e a tema sendo testado, no qual a ps-condiao de um teste frequentemente utilizada como o c e precondiao para o prximo (ISTQB, 2009). c o Um orculo qualquer agente (humano ou no) que decide se um software funcionou a e a corretamente em um determinado teste. A geraao do orculo provavelmente a parte c a e mais dif e cara da automaao de testes. cil c

18

Um critrio de teste dene quais propriedades de um programa devem ser exercitadas e para constituir um teste completo (NETO, 2005). Critrios podem ser utilizados para e selecionar os casos de teste dentre todos os casos de teste poss veis. Podem tambm ser e utilizados para decidir se o teste pode ou no ser considerado completo e, por consequncia, a e nalizado. Existem basicamente dois mtodos de criaao de testes (PDUA, 2003): e c a Mtodo da caixa branca: tem por objetivo determinar defeitos na estrutura interna e do produto, atravs do desenho de testes que exercitem sucientemente os poss e veis caminhos de execuo; ca Mtodo da caixa preta: tem por objetivo determinar se os requisitos foram total ou e parcialmente satisfeitos pelo produto. Os testes de caixa preta no vericam como a ocorre o processamento, mas apenas os resultados produzidos.

2.1

Tipos de teste

O teste de software geralmente executado em diferentes n e veis ao longo do processo de desenvolvimento e de manuteno de software (IEEE, 2004). Isso quer dizer que o alvo ca do teste pode variar. O alvo do teste pode ser: um mdulo unico, um agrupamento de o mdulos ou o sistema por completo. De acordo com o alvo do teste, podemos classicar o os testes em trs grupos distintos: Testes de Unidade, Testes de Integraao e Testes de e c Sistema.

2.1.1

Testes de Unidade

O Teste de Unidade, ou Teste de Componente, um teste de Caixa Branca. Os e Testes de Unidade tm por objetivo vericar um elemento que possa ser logicamente e considerado uma unidade de implementaao. Dependendo da linguagem de programaao c c utilizada, uma unidade de software pode se referir a coisas diferentes, como mdulos ou o funoes. No caso de sistemas orientados a objetos, uma unidade pode ser uma classe ou c um grupo de classes fortemente acopladas (PDUA, 2003). a Um teste de unidade se resume, basicamente, a escrever um pedao de cdigo para c o exercitar outro pedao de cdigo, com o objetivo de determinar se este outro pedao est c o c a se comportando conforme o esperado. E normal que os testes de uma unidade sejam escritos durante a implementaao daquela unidade. Assim, muitas vezes necessrio que c e a

19

o prprio desenvolvedor crie o teste de unidade, porque para se testar um trecho de cdigo, o o necessrio conhecer a linguagem de programaao utilizada e saber detalhadamente o que e a c aquele trecho de cdigo faz. o De uma maneira geral, todos os desenvolvedores realizam testes durante o desenvolvimento. Geralmente se codica algo e se verica, atravs da execuao do que foi e c implementado, se seu comportamento ocorre conforme o esperado. O grande problema que esses testes so feitos de forma manual. Assim, mesmo que certa condio tenha e a ca sido vericada durante sua implementaao, nada garante que no futuro ela estar funcic a onando, uma vez que parte do cdigo pode ser alterada sem a posterior vericao do o ca funcionamento (NETO, 2005). Para resolver esse problema, os testes de unidade devem ser criados e sua execuo ca deve ser automatizada, de forma que possam ser executados periodicamente. Assim, caso haja uma mudana incorreta em alguma parte do cdigo que possua testes de unidade, essa c o mudana ser revelada quando esses testes forem executados. A execuao dos testes de c a c unidade de forma sistematizada conhecida como Integraao Cont e c nua (DUVALL; MATYAS;
GLOVER,

2007). No prximo cap o tulo, conheceremos um pouco sobre ferramentas de

Integraao Cont c nua e de criaao de testes unitrios. c a Dessa forma, os testes de unidade podem auxiliar bastante o desenvolvimento de software com qualidade. Porm, existem algumas caracter e sticas que esses testes precisam ter para que o seu papel seja cumprido de forma eciente. So elas (MARICK, 1995): a Automticos. Como j dito anteriormente, os testes de unidade devem ser executaa a dos automaticamente e de forma peridica; o Completos. Os testes de unidade devem testar todos os caminhos poss veis de serem executados em um objeto de teste. Independentes. Um teste de unidade no deve depender de outro, podendo ser a executado individualmente, a qualquer hora e em qualquer ordem. Reproduz veis. Os testes de unidade devem ser independentes do ambiente sobre o qual executam, devendo produzir os mesmos resultados em cada execuo. ca Criados de forma prossional. Os testes de unidade devem ser criados de forma prossional, seguindo os mesmos critrios de qualidade utilizados para o cdigo e o fonte do projeto.

20

Existem muitos mitos associados ao teste de unidade que precisam ser eliminados. Alguns desses mitos contribuem para que muitos desenvolvedores deixem de utilizar os testes de unidade durante o desenvolvimento. Dentre esses mitos, destacamos dois principais(NETO, 2005): Escrever testes de unidade atrasa o desenvolvimento. Muitas vezes, por causa de prazos curtos, os testes no so criados no desenvolvimento. Assim, os desenvolvea a dores preferem fazer os testes de forma manual, mas o custo adicional para tornar um teste manual em um teste automtico pequeno e o benef associado muito a e cio e grande. Alm disso, o cdigo gerado sem apoio dos testes de unidade normalmente e o apresenta mais falhas e, quanto mais tarde se descobre uma falha, mais caro sua e correao, atrasando ainda mais os prazos denidos. c E melhor e mais fcil desenvolver testes de unidade depois do cdigo pronto. O ideal a o fazer os testes de unidade durante o desenvolvimento, visto que, nesse momento, e todas as regras associadas ` parte do produto sendo desenvolvido devem estar bem a assimiliadas. Algumas tcnicas, como o Desenvolvimento Dirigido por Testes (BECK, e 2002), prescrevem at que os testes devem ser criados antes mesmo do cdigo. e o Dessa forma, os testes de unidade representam uma importante ferramenta para o aux ao desenvolvimento de software com qualidade. De forma resumida, podemos lio destacar como principais vantagens relacionadas ao seu uso (GAZOLA; DAVID, 2007): Testes de unidade auxiliam a descoberta de falhas mais cedo no ciclo de desenvolvimento, reduzindo os custos relacionados ` correao dessas falhas. a c Testes de unidade de qualidade validam o cdigo ao longo do tempo, uma vez que, ao o escrever um teste para parte de um cdigo, essa parte estar sempre sendo validada, o a garantindo assim sua corretude. Testes de unidade facilitam a refatoraao do cdigo. O teste ajuda a garantir que o c o cdigo continuar funcionando mesmo aps grandes alteraoes. o a o c O conjunto de testes de unidade pode ser considerado uma documentao executvel ca a do cdigo, uma vez que eles descrevem como o desenvolvedor espera que o cdigo o o funcione. Testes de unidade aumentam a conana dos desenvolvedores e facilitam o trabalho c em equipe, pois sabendo que existem testes para as diversas unidades desenvolvidas,

21

os desenvolvedores cam mais seguros ao alterar trechos de cdigos escritos por o outras pessoas. Isso favorece o trabalho em equipe.

2.1.2

Testes de Integrao ca

Os Testes de Integraao, por terem como alvo um grupo de unidades, partem do c princ pio que, cada unidade sujeita a ele, tenha sido previamente testada. Se poss vel, os defeitos de cada uma j devem estar corrigidos (SPILLNER; LINZ; SCHAEFER, 2007). a Unidades so compostas para formar unidades e subsistemas de estrutura maior. Esta a conexo de unidades chamada integrao e feita por desenvolvedores, testadores, ou a e ca e equipes especiais de integraao. c Depois de integradas as unidades, deve ser garantido, atravs do teste de integraao, e c se todas as unidades colaboram corretamente. Portanto, o objetivo do teste de integrao ca encontrar falhas nas interfaces e na interaao entre as unidades integradas. e c Para a realizaao do teste de integraao, necessrio denir uma estratgia de inc c e a e tegraao (NETO, 2005). De forma geral, a estratgia de integraao determina como os c e c diversos componentes do sistema sero agrupados e como a vericaao do funcionamento, a c depois da integrao, ser realizada. ca a Alguns desenvolvedores utilizam uma estratgiadenominada big-bang, que cone siste basicamente em no utilizar estratgia alguma. Ou seja, as unidades so integradas a e a em qualquer ordem, seguindo a seguinte prescriao: Vamos juntar tudo para ver se c funciona!. O mais indicado para o desenvolvimento prossional de software utilizar uma ese tratgia de Integraao Incremental, em que o programa seja constru e testado em e c do pequenos segmentos. Dessa forma, a correo de erros torna-se mais fcil e as interfaces ca a entre as unidades tm maior probabilidade de serem testadas completamente. e Existem diversas estratgias incrementais de integrao que podem ser consideradas e ca em um projeto. No existe um consenso sobre qual a melhor tcnica. Na maioria dos a e casos, cada organizaao determina o que melhor para seus projetos. Descreveremos aqui, c e resumidamente, duas importantes estratgias: A Integraao Top-down e a Integraao e c c Bottom-Up. A Integrao Top-down uma estratgia incremental em que os mdulos so inteca e e o a grados de cima para baixo. Num t pico Sistema de Cadastro de Clientes de uma loja

22

criado usando-se orientaao a objetos, por exemplo, iniciar c amos a integraao a partir c da tela inicial do sistema, vericando seu funcionamento integrado com cada uma das telas de acesso a funes do sistema, como a Tela de Usurios e a Tela de Clientes. Em co a seguida, vericar amos a integraao dessas telas `s unidades responsveis pelas regras de c a a negcio, como a classe Usurio e a classe Cliente, e assim sucessivamente. J na Inteo a a graao Bottom-Up, utilizamos o caminho inverso. Iniciamos pelas unidades localizadas c inferiormente na hierarquia de unidades. As ferramentas para o teste de integrao so as mesmas utilizadas para o teste de ca a unidade. No prximo cap o tulo, veremos um pouco sobre essas ferramentas.

2.1.3

Testes de Sistema

Os Testes de Sistema so testes de Caixa Preta. Eles tm por objetivo validar o proa e duto nal, ou seja, vericar se ele atende aos requisitos especicados sob o ponto de vista de seu usurio nal. Os testes de sistema podem ser divididos em testes funcionais e noa a funcionais (PDUA, 2003). Os testes funcionais devem vericar se o produto implementado a atende aos seus respectivos requisitos funcionais. J os testes no-funcionais, devem vea a ricar a conformidade do produto com os requisitos no-funcionais, como desempenho, a segurana e usabilidade. c 2.1.3.1 Testes Funcionais

Ao contrrio dos requisitos no-funcionais, os requisitos funcionais so requisitos que a a a esto relacionados `s funcionalidades espec a a cas do sistema. Eles descrevem o que o sistema deve estar apto a fazer (IEEE, 2004). Os testes funcionais tm o objetivo de e vericar a consistncia entre produto implementado e seus requisitos funcionais. e Esses testes geralmente so executados por uma equipe independente de testes, agindo a como se fossem os usurios nais do produto e tentando encontrar inconsistncias entre a e o que foi solicitado e o que foi desenvolvido. Diferentemente de testes de unidade, a automatizaao de testes funcionais demanda c muito esforo e, conseqentemente, mais custos. Geralmente, para se automatizar esses c u tipos de testes, temos que dedicar um bom tempo ` criaao de scripts que simulem o a c uso da aplicaao pelo usurio nal, para ento, s depois, comearmos a criar os testes de c a a o c fato. Ou seja, automatizar testes funcionais demanda bem mais esforo do que execut-los c a manualmente.

23

Porm, fazer testes funcionais de forma manual, muitas vezes, no a melhor soluao. e a e c Depois de executado um conjunto de testes funcionais manualmente, por exemplo, pode ser necessria a refatoraao de um trecho do sistema que j foi testado. Assim, para se a c a continuar garantindo que, aps a refatoraao, o trecho do sistema no apresentar falhas, o c a a os testes funcionais tero de ser re-executados de forma manual. Se os testes tivessem a sido automatizados, a sua re-execuo se resumiria a executar apenas um script j criado ca a ou a clicar em alguns botes. o Assim, mesmo que a automaao de um conjunto de testes funcionais normalmente c demande bem mais esforo que sua execuao manual, automatizar testes funcionais , na c c e maioria das vezes, um bom investimento (NETO, 2005).

24

Ferramentas de Teste

3.1

Tipos de ferramentas de teste

Existe uma variedade de ferramentas de teste para oferecer suporte e automatizar atividades de teste (SPILLNER; LINZ; SCHAEFER, 2007). Analogicamente ao termo ferramentas CASE (Computer Aided Software Engineering), o termo ferramentas CAST (Computer Aided Software Testing) tambm utilizado. Diversas categorias de ferramene e tas existem para dar suporte `s diferentes atividades e fases do processo de teste. Elas a so classicadas de acordo com as fases ou atividades as quais elas do suporte. Numa a ` a classe de ferramentas, h, geralmente, verses voltadas para plataformas espec a o cas ou para uma determinada rea de aplicao, como, por exemplo, ferramentas de teste de dea ca sempenho voltadas para aplicaoes WEB. Raramente, todas as categorias de ferramentas c dispon veis so aplicadas num projeto. No entanto, importante conhecer todos esses a e tipos de ferramentas para que se decida quando e onde aplic-las ecientemente num a projeto. As funoes oferecidas por diferentes classes de ferramentas so descritas abaixo (SPILLc a
NER; LINZ; SCHAEFER,

2007):

Ferramentas para Gerenciamento e Controle dos Testes: Permitem a administraao c dos casos de testes para, por exemplo, documentar e avaliar com que freqncia e ue com que resultado (Sucesso ou falha) os testes tm sido executados. Com o uso e dessas ferramentas fcil determinar quantos casos de teste tm sido executados e e a e quantos obtiveram sucesso, ou a freqncia com que os testes tm encontrado falhas ue e num determinado componente. Enquadram-se nessa categoria, as ferramentas de Integraao Cont c nua. Essas ferramentas aceitam seqncias de teste manualmente ue criadas, automaticamente geradas e ou pr-gravadas e as executam sem superviso e a humana, durante intervalos de tempo pr-denidos. Como exemplo dessas ferrae mentas, tem-se o Ant (ANT, 2009), Cruise Control (CRUISE, 2009) e o Continuum (CONNTINUUM, 2009).

25

Ferramentas para Especicaao de Teste: Para tornar os testes reproduz c veis, as pr- e ps-condies bem como os dados de entrada e os resultados esperados devem e o co ser especicados. Essas ferramentas especicam os dados de entrada de um teste. Elas geram os dados de testes atravs de modelos que representam o formato das e entradas permitidas. Apenas as entradas dos testes so geradas, a geraao dos a c resultados esperados exige a presena de um orculo. c a Ferramentas para Teste Esttico: Permitem a anlise esttica do cdigo fonte ou a a a o das especicaes do produto, antes dele estar executvel. Essas ferramentas podem co a ajudar a encontrar falhas nas fases iniciais do ciclo de desenvolvimento. As falhas podem, assim, ser detectadas e corrigidas logo que so criadas. Isso diminui os a custos e o tempo geral de desenvolvimento. Ferramentas para Teste Dinmico: Essa a principal categoria de ferramentas, a e pois, de maneira geral, quando falamos em ferramentas de teste para automatizar a execuao do teste, geralmente estamos falando de ferramentas para automatizar c testes dinmicos. Essas ferramentas automatizam a vericao do produto por meio a ca de casos de teste que exigem a execuo do produto. Nessa categoria, enquadram-se ca as ferramentas de testes de unidade, de testes de integrao e de testes funcionais. ca Essas ferramentas sero descritas nos tpicos a seguir. a o Ferramentas para Testes No-Funcionais: Permitem a automatizao dos testes noa ca a funcionais. Destacam-se nessa categoria, ferramentas de teste de desempenho e de estresse. As ferramentas de testes de desempenho consistem em testar se o sistema atende aos requisitos de desempenho, como, por exemplo, o tempo de resposta de uma requisio, o nmero de operaoes que o sistema capaz de completar num dado ca u c e intervalo de tempo, o uso de recursos de mquina, como memria e processamento, a o dentre outros. As ferramentas de teste de estresse consistem em submeter o sistema a situaes anormais de uso, que vo alm do exigido pelos requisitos de desempenho. co a e

3.1.1

Ferramentas de teste de unidade

A fam xUnit (MESZAROS, 2007) o arcabouo mais utilizado atualmente para lia e c criaao de testes de unidade (NETO, 2005). Para a Linguagem Java existe o JUnit (HUSc
TED; MASSOL,

2003), que foi desenvolvido por Kent Beck e Erich Gamma. A maioria das

ferramentas de desenvolvimento Java existentes no mercado, como o JBuilder, Eclipse, NetBeans, incorporam o JUnit dentro de seu ambiente, facilitando assim seu uso.

26

As Figuras 3 e 4 exibem um exemplo simples de teste de uma classe representando um produto de uma loja. No exemplo foi utilizado o JUnit 4. A Figura 3 corresponde a ` classe Produto e a Figura 4 corresponde a sua respectiva classe de teste. `

Figura 3: Classe Produto

Figura 4: Classe TesteProduto Essa verso do JUnit utilizada difere da verso anterior, JUnit 3, devido o uso de a a anotaoes. A seguir, uma pequena descrio das anotaes mais importantes: c ca co @Test - E a principal anotao. Sua presena num mtodo de uma classe indica ca c e que essa classe uma classe de teste. Os mtodos da classe com essa anotao e e ca correspondem aos casos de teste. Um exemplo do uso dessa anotao pode ser visto ca na Figura 4. @Before - Durante a execuao da classe de teste, um mtodo com essa anotao c e ca e sempre chamado antes da execuo de cada caso de teste. ca

27

@After - Durante a execuao da classe de teste, um mtodo com essa anotao c e ca e sempre chamado depois da execuo de cada caso de teste. Ou seja, essa anotaao ca c possui efeito simtrico ao da anotaao @Before. e c @BeforeClass - Um mtodo com essa anotaao chamado uma vez antes da e c e execuao dos demais mtodos da classe. Um mtodo com essa anotaao deve ser c e e c esttico. a @AfterClass - Um mtodo com essa anotao chamado uma vez depois da e ca e execuao de todos os mtodos da classe. Um mtodo com essa anotaao tambm c e e c e deve ser esttico. Essa anotaao possui efeito simtrico ao da anotaao @Beforea c e c Class. Como pode ser visto nas Figuras 3 e 4, e como j mencionado no cap a tulo anterior, testar um pedao de cdigo escrever outro pedao de cdigo que o utilize, vericando c o e c o se os resultados obtidos so os esperados. No mtodo testaValorEstoque da classe de a e teste, um objeto produto instanciado atribuindo-se 5.4fpara seu valor e 10para sua e quantidade em estoque. Em seguida, utilizado o mtodo assertEquals, que responsvel e e e a por vericar se um determinado valor igual a outro. No exemplo, est sendo vericado e a se 54.0f o resultado obtido quando se invoca o mtodo getValorEstoque. Caso os valores e e comparados sejam iguais, ento dito que o teste passou, em caso contrrio, que o teste a e a falhou. Depois de criada a classe de teste, necessrio execut-la. Em praticamente todos e a a os ambientes de desenvolvimento Java, a execuao pode ser feita clicando-se com o boto c a direito do mouse em cima da classe de teste e selecionando, no menu, a opo de executar ca a classe como teste JUnit. A Figura 5 mostra a tela do JUnit com o resultado da execuo ca da classe de teste. Como se pode ver, uma barra verde foi sinalizada indicando que o teste ocorreu com sucesso, ou seja, nenhuma falha foi encontrada. Caso alguma falha tivesse sido encontrada, uma barra vermelha seria sinalizada e na area Failure Trace apareceriam os detalhes da falha. Os detalhes da falha, nesse caso, exibiriam o resultado esperado, o resultado obtido e a informao sobre onde a falha se manifestou no teste. Com essas informaes, seria ca co poss realizar a depuraao do cdigo para se descobrir exatamente o trecho associado vel c o a falha. `

28

Figura 5: Execuo da classe TesteProduto como Teste JUnit ca

3.1.2

Ferramentas de teste funcional

Existem diversas ferramentas de teste funcional. A maioria delas se baseia na gravaao c das aoes executadas nas telas da aplicaao, gerando um script dos passos executados. As c c aoes gravadas podem ser re-executadas, o que permite a automao do teste. O script c ca gerado pode ser alterado, permitindo modicaes nos testes gravados sem a necessidade co da re-execuao do software e nova captura. Dentre recursos importantes nesse tipo de c ferramenta, tem-se a possibilidade de acessar o valor dos diversos elementos existentes nas telas do software, com o intuito de vericar os dados existentes. A partir disso que e os testes so criados. a Existem ferramentas, Open Source ou no, voltadas tanto para aplicaes desktop a co quanto para aplicaes WEB. Como ferramentas Open Source para o teste de aplicaoes co c desktop, podem-se citar o Abbot (ABBOT, 2009) e o Marathon (MARATHON, 2009). Dentre ferramentas Open Source para o teste de aplicaes WEB, as mais populares so co a (FUNCIONAL TEST, 2009): Canoo WebTest (CANOO, 2009), WatiN (WATIN, 2009), Watir (WTR, 2009) e Selenium (SELENIUM, 2009). O Selenium a ferramenta escolhida como base para esse trabalho. Quanto a platae formas e linguagens suportadas, ela a mais avanada em relao as demais ferramentas. e c ca ` Alm disso, possui um ambiente de desenvolvimento integrado que facilita a criao dos e ca testes, tornando-a mais simples para iniciantes em testes funcionais. Uma explicaao mais c detalhada sobre essa ferramenta ser vista nos cap a tulos posteriores.

29

Selenium: Uma ferramenta para criao de testes ca funcionais para aplicaes co WEB

O Selenium um conjunto de ferramentas Open Source criadas por prossionais da e ThoughtWorks para automatizar testes em aplicaoes WEB. Pelo fato de ser escrito em c puro JavaScript (W3SCHOOLS, 2009) e DHTML (Dynamic HiperText Markup Language), o Selenium pode ser executado em qualquer navegador, bastando somente que esse possua suporte a JavaScript (Internet Explorer, Firefox, Opera, Safari, Konqueror, dentre outros) (CAETANO, 2007). Sendo assim, essa ferramenta pode ser utilizada tanto para a criaao de testes funcionais como testes de compatibilidade de navegador, vericando se a c aplicaao funciona corretamente em diferentes navegadores. Neste trabalho, utilizaremos c essa ferramenta para a criaao de testes funcionais. c

4.1

Sobre a aplicao utilizada nos exemplos ca

No decorrer deste trabalho, utilizada uma aplicaao WEB criada especialmente para e c demonstrar o uso do Selenium e da API proposta neste trabalho. Essa aplicao foi desenca volvida utilizando-se o JHeat, um framework Open Source para criaao agil de aplicaes c co WEB em Java. Esse framework mantido pela Infoway - Consultoria e Solues em e co Gesto de Sistemas de Sade LTDA1 e ainda no se encontra dispon para download, a u a vel pois est em fases de aperfeioamento. a c O JHeat foi utilizado por ser Open Source e por permitir a criao fcil e rpida ca a a de aplicaoes WEB em Java. Com esse framework, por meio de pouco mapeamento c XML(eXtensible Markup Language) (XML, 2009) poss e vel gerar, por exemplo, todas as pginas da aplicaao responsveis por inserir, pesquisar, alterar e remover objetos de a c a
1

http://www.infoway-pi.com.br

30

determinada classe do modelo. A aplicaao desenvolvida para este trabalho consiste num pequeno sistema para cadasc tro de clientes de uma locadora de DVD. Um cliente possui vrios atributos como nome, a CPF, endereo e pode possuir vrios dependentes. H tambm o cadastro de usurios c a a e a que acessam o sistema e o de munic pios aos quais pertencem os clientes da locadora. As Figuras 6 e 7 exibem, respectivamente, a tela de Login e o Menu de cadastros da aplicaao. c

Figura 6: Tela inicial da aplicao. ca

Figura 7: Menu com as opoes de cadastro. c

31

Nos tpicos a seguir so descritos os componentes2 do Selenium e como eles atuam o a conjuntamente para se ter uma maior facilidade na criaao dos testes funcionais. c

4.2

Selenium Core

Os testes do Selenium so escritos, basicamente, em tabelas HTML. Essas tabelas a descrevem os comandos a serem executados no decorrer do teste. O Selenium Core o e responsvel por interpretar os comandos das tabelas HTML e executar as aes, simulando a co o uso da aplicaao WEB pelo usurio nal (CAETANO, 2007). c a Para se utilizar o Selenium Core, deve ser feito o download a partir do site do Selenium e, depois, descompact-lo no diretrio da aplicaao WEB a ser testada. Em seguida, a o c deve-se execut-lo por meio da pgina TestRunner.html como demonstra a Figura 8. O a a TestRunner a pgina que gerencia a execuao dos testes e exibe o relatrio de progresso e a c o da execuao. c

Figura 8: TestRunner.html
Todos os componentes utilizados possuem a verso 1.0 beta 2 e podem ser adquiridos acessando a http://seleniumhq.org/download/
2

32

A pgina do TestRunner dividida em quatro diferentes areas (CAETANO, 2007): a e Test Suite: Nesta area deve-se escolher a Test Suite que ser executada pelo Sele a nium, assim como selecionar um teste da lista de testes dispon veis. Current Test: Nesta area visualiza-se o teste selecionado ou o teste que estiver sendo executado. Control Panel: Nesta area gerencia-se a execuo dos testes. E poss rodar apenas ca vel os testes selecionados ou rodar todos do su diminuir a velocidade de execuao te, c dos testes, executar os testes passo a passo, ver o log de execuao e o resultado da c execuao dos testes. c AUT: Nesta rea localizada na parte inferior da pgina, visualiza-se a aplicaao em a a c teste durante a execuao dos testes. Pode-se tambm congurar o Selenium para c e exibir a aplicaao em teste em uma janela separada por meio da opao AUT in c c separate window. E importante lembrar que devem ser desabilitados os bloqueadores de pop-up, gerenciadores de senhas e recursos semelhantes do navegador antes da execuo dos testes ca automatizados, para garantir que os testes no falhem ou travem em virtude de algum a desses recursos oferecidos pela maioria dos navegadores. Depois de congurado o Selenium Core, preciso criar os casos de teste a serem e executados durante o teste da aplicaao WEB. Como j citado anteriormente, esses casos c a de teste so escritos em tabelas HTML. Cada registro dessa tabela corresponde a um a comando a ser executado, que pode ser um clique num boto ou num link da pgina, por a a exemplo. A sintaxe desses comandos do Selenium chamada de Selenese HTML (Em portugus e e seria HTML Selens). Um comando escrito em Selens constitu de uma tabela e e e do contendo trs colunas: a operaao a ser executada, o elemento alvo da operaao e o valor e c c atribu `quele elemento. Vale destacar que nem sempre a terceira coluna precisar ser do a a informada, pois existem comandos que no exigem esse terceiro argumento. A Figura 9 a mostra um exemplo de um teste escrito em Selens, onde /exemploSelenium a URL e e da aplicaao testada. c De um modo geral, as operaoes suportadas pelo Selens so classicadas em trs c e a e grupos distintos (SELENIUM, 2009):

33

Figura 9: Teste escrito em Selnes. e Actions: Representam as aoes executadas pelo usurio durante a utilizao da c a ca aplicaao WEB. So aoes como clicar em links ou botes, selecionar opoes e dic a c o c gitar em caixas de texto. Como exemplo desses comandos, temos o type e o open mostrados na Figura 9. Assertions: Executam uma asserao, comparando o estado ou a propriedade de c um objeto da pgina contra um valor esperado. Como exemplo, temos o comando a assertText da Figura 9, que verica se a mensagem Entrada no sistema efetuada com sucesso.foi exibida em determinada rea da pgina. a a Accessors: Comparam o estado ou a propriedade de um objeto da pgina contra a um valor esperado, mas armazenam o resultado numa varivel. a No objetivo deste trabalho mostrar todas as poss a e veis operaes do Selenium. Caso co haja interesse do leitor, pode-se visitar o site do Selenium e acessar o Reference Guide3 das operaes suportadas. co Cada caso de teste deve estar associado a um link, cujo atributo targetdeve referenciar o frame testFramepara que os testes sejam exibidos corretamente na area TestSuite do TestRunner. Um exemplo de Test Suite mostrado na Figura 10. e Depois de criado o Test Suite, preciso somente inform-lo no TestRunner.html e, e a depois, dar in a execuao dos testes na aplicaao. Porm, no necessrio congurar cio ` c c e a e a e utilizar o Selenium Core diretamente como foi mostrado at agora e nem ter a tarefa e dispendiosa de criar os casos de teste em Selens. Com o Selenium IDE, um ambiente de e desenvolvimento integrado, poss gravar, editar e reproduzir as aoes que so execue vel c a tadas na aplicaao WEB sem a preocupaao de se utilizar o Selenium Core diretamente c c
3

http://seleniumhq.org/projects/core/reference.html

34

Figura 10: Cdigo HTML do Test Suite. o e sem a necessidade de aprender Selens. Em seguida, apresentado um estudo mais e e detalhado sobre o Selenium IDE.

4.3

Selenium IDE

O Selenium IDE (Integrated Development Environment) um ambiente de desenvole vimento integrado para testes com o Selenium. Ele uma extenso do Firefox e permite e a gravar, editar e re-executar aoes que realizamos nas pginas do navegador (SELENIUM, c a 2009). O Selenium IDE encapsula o Selenium Core e a cada ao executada no Firefox, ca ele registra automaticamente o comando Selens correspondente, permitindo que os casos e de teste sejam criados e executados de uma forma intuitiva. Depois de feito o download e instalado, pode-se executar o Selenium IDE acessando o menu Ferramentas > Selenium IDEdo Firefox. Uma vez aberta a janela da IDE, o boto Record, que d in ` gravaao, j est ativado, ento, ao serem executadas aoes a a cio a c a a a c na aplicaao, elas vo sendo automaticamente registradas na aba Tabela. A Figura 11 c a mostra o Selenium IDE com algumas aoes gravadas. c Na aba Tabela, conforme foi dito anteriormente, so mostrados todos os comandos a executados na pgina. Por meio da aba Cdigo Fonte, pode-se visualizar o HTML Selens a o e dos comandos. Porm, o Selenium IDE no se limita apenas a reproduzir os cliques ou e a preenchimento dos campos realizados durante a navegao. Pode-se tambm selecionar ca e qualquer uma das operaes suportadas pelo Selens por meio do campo Comando. Vale co e a pena destacar que, conforme o comando selecionado, uma descriao completa da sua c utilizaao e argumentos requeridos apresentada na parte inferior da janela do Selenium c e IDE. Quando a janela do Selenium IDE est aberta e o boto Record, para gravar as aoes, a a c

35

Figura 11: Selenium IDE com aoes gravadas. c est ativado, novos menus de contexto so adicionados ao Firefox. Assim, pode-se associar a a qualquer elemento da pgina a comandos do Selenium. A Figura 12 mostra um exemplo a do uso de um comando de assero para vericar se determinada mensagem exibida ca e numa rea da pgina. a a Na opao Exibir todos os comandos dispon c veis, muitos outros comandos, que podem ser uteis, so exibidos. a E importante ressaltar que no Selenium tambm existem comandos para se criar testes e para aplicaes WEB baseadas em AJAX. De uma forma resumida, uma pgina AJAX co a capaz de ter seu contedo atualizado sem a necessidade de buscar ou trocar muitas e u informaoes com o servidor WEB. No cap c tulo 5 ser demonstrado o uso de alguns desses a comandos do Selenium. Depois de gravadas todas as aoes e, assim, criado o caso de teste, pode-se salvar este c em HTML para uma posterior execuao. E poss executar um caso de teste por meio c vel de um Su de testes ou executar um por vez. Pode-se tambm execut-lo utilizando o te e a

36

Figura 12: Utilizando o comando AssertText para vericar a mensagem exibida na tela. TestRunner.html. E importante observar que, utilizando o Selenium IDE, no necessrio a e a fazer nenhuma conguraao do Selenium Core para que os testes possam ser executados. c Gravar os testes do Selenium IDE em HTML pode no ser suciente quando precisama se criar testes mais complexos, que fazem acesso a banco de dados ou a informaoes c externas. Alm disso, manter os casos de teste escritos em HTML dicultar a manuteno e a ca dos testes, uma vez que se algum elemento da pgina sofrer alterao, ento ser necessrio a ca a a a alterar todos os casos de testes onde aquele elemento referenciado. A m legibilidade e a do HTML outro fator que justica que seu uso no a melhor soluao. e a e c O Melhor, portanto, seria se fosse poss salvar os casos de teste em uma linguagem vel de programaao desejada ao invs de utilizar HTML e, assim, permitir que os testes c e criados tenham boa manutenibilidade e legibilidade, alm de outras vantagens. Isso e e poss por meio do Selenium RC. A seguir, apresentada uma melhor descrio dessa vel e ca ferramenta.

4.4

Selenium RC (Remote Control )

O Selenium RC uma ferramenta que permite executar os testes numa aplicao e ca WEB a partir de uma determinada linguagem de programao. Ele constitu por ca e do duas partes: um servidor e as bibliotecas cliente. O servidor do Selenium RC responsvel, basicamente, por abrir e fechar o navegae a dor e possibilitar a comunicao entre os testes escritos, numa determinada linguagem ca de programao, e o navegador. O servidor se comunica diretamente com o navegador ca

37

utilizando AJAX. Podem-se executar comandos do Selenium atravs do servidor por meio e de requisies HTTP. O servidor interpreta a requisiao e executa o respectivo comando co c no navegador. Assim, para que seja poss vel a automaao dos testes a partir de uma c linguagem de programaao, basta somente que a linguagem possa fazer requisies HTTP c co ao servidor (SELENIUM, 2009). Essa a funao das bibliotecas cliente. e c As bibliotecas cliente esto dispon a veis nas principais linguagens de programaao do c mercado: Java, Perl, Python, PHP, Ruby e C#. Neste trabalho, ser utilizada a biblioteca a cliente Java. Isso se deve ao fato de a linguagem Java ser a mais utilizada dentre os acadmicos do CEFET-PI. e Uma biblioteca cliente possui interfaces para todos os comandos do Selenium. Quando executamos um comando, o que feito, na verdade, uma requisio HTTP para o e e ca servidor do Selenium que se encarrega de abrir o navegador usando AJAX, carregar a pgina do Selenium Core e permitir que os comandos requisitados sejam executados. Ou a seja, o Selenium RC, assim como o Selenium IDE, tambm empacota o Selenium Core. e De uma forma resumida, o servidor do Selenium atua como um Proxy HTTP, possibilitando a comunicaao entre o navegador e a biblioteca cliente. A Figura 13, extra c da do site do Selenium (SELENIUM, 2009), demonstra o funcionamento do Selenium RC por meio de um diagrama. Os passos da Figura 13 so descritos a seguir (SELENIUM, 2009): a 1. A biblioteca cliente lana uma requisio para o servidor do Selenium. c ca 2. O servidor do Selenium inicia o navegador com uma URL que carregar a pgina a a do Selenium Core. 3. O Selenium Core obtm o primeiro comando da biblioteca cliente por meio do Proxy e HTTP embutido no servidor do Selenium. 4. O Selenium Core executa esse primeiro comando solicitando a abertura da pgina a inicial da aplicao a ser testada. ca 5. O servidor WEB, ao receber essa solicitao, abre a pgina inicial da aplicaao no ca a c espao reservado do Selenium Core. c Para se utilizar o Selenium RC, deve-se, primeiramente, iniciar o servidor do Selenium executando java -jar selenium-server.jarno prompt de comando ou no terminal dentro do diretrio onde se encontra o pacote selenium-server.jar. Quando iniciado, o servidor o

38

Figura 13: Diagrama de funcionamento do Selenium Remote Control. ca escutando localmente4 na porta 4444 por padro, aguardando que sejam iniciadas as a requisioes HTTP da biblioteca cliente. A Figura 14 demonstra o servidor do Selenium c iniciado. Alm desse modo de execuo convencional, o servidor do Selenium oferece tambm e ca e um modo interativo. Neste modo, poss interagir diretamente com o servidor, fazendo e vel requisioes HTTP, solicitando a execuo de comandos Selens. c ca e Para inicializar o servidor do Selenium em modo interativo, executa-se java -jar selenium-server.jar -interactive. A Figura 15 mostra o servidor do Selenium iniciado em modo interativo. Na Figura 15, o comando cmd=getNewBrowserSession...da ultima linha, ao ser exe cutado, criar uma nova instncia do navegador Firefox e carregar a pgina do Selenium a a a a Core, preparando para sejam iniciados os testes na aplicaao exemploSelenium. c
4 No necessariamente o servidor precisa estar localizado na mesma mquina onde os testes sero a a a executados. Assim, poss distribuir a execuo dos testes por vrias mquinas, economizando tempo e vel ca a a por meio da utilizao de execuo paralela dos testes. Essa funcionalidade faz parte do Selenium Grid. ca ca Esse assunto no ser tratado nesse trabalho, por no fazer parte do escopo. a a a

39

Figura 14: Servidor do Selenium iniciado

Figura 15: Servidor do Selenium em modo interativo Depois de iniciado o servidor do Selenium no modo normal, os testes escritos numa linguagem de programaao desejada podem ser criados. Para realizar essa tarefa, pode-se c utilizar o Selenium IDE. E poss exportar os casos de teste criados no Selenium IDE vel para qualquer uma das linguagens de programaao suportadas pelo Selenium RC, como c pode ser observado na Figura 16. E importante destacar que devemos fazer uma pequena congurao no Selenium IDE ca antes da exportao do cdigo, alterando, no menu Opes, a codicao dos arquivos ca o co ca de UTF-8 para ISO-8859-1, que a codicaao de caracteres do alfabeto latino. Isso e c e necessrio para no se ter problemas de caracteres desconhecidos no cdigo Java gerado a a o a partir da IDE. Na Figura 17, exibido o cdigo fonte resultado da exportaao do caso de teste para e o c a linguagem Java. Depois de congurada a biblioteca, o teste em Java pode ser executado. As Figuras

40

Figura 16: Exportando caso de teste para uma linguagem de programao. ca 18, 19 e 20 mostram respectivamente o resultado da execuao. c No prximo cap o tulo, so apresentados outros exemplos mais robustos de criaao a c de casos de teste utilizando a biblioteca cliente Java do Selenium RC e, tambm, so e a estudados com mais atenao, os mtodos dessa biblioteca. Alm disso, ser mostrado c e e a o que necessrio fazer para que os testes escritos em uma linguagem de programao e a ca sejam mais fceis de manter e de reusar. a

41

Figura 17: Caso de teste exportado para Java.

Figura 18: Execuao do teste escrito em Java. c

Figura 19: Resultado da execuao no servidor do Selenium RC. c

42

Figura 20: Teste sendo executado no Selenium Core por chamada do servidor.

43

Desenvolvendo testes com o Selenium utilizando o padro a de Procedimentos e Casos de teste

At agora, foi estudado o funcionamento do Selenium e viu-se, basicamente, como criar e testes funcionais em aplicaoes WEB utilizando-se essa ferramenta. Porm, esse conhecic e mento ainda no necessrio para que se possa criar testes com boa manutenibilidade e a e a reusabilidade utilizando uma linguagem de programaao. c Ao serem criadas vrias classes de testes utilizando o Selenium RC, muito cdigo a o repetido comea a surgir e, diante de alguma mudana numa pgina da aplicaao, ser c c a c a necessrio fazer alteraao em todas as classes criadas. Sendo assim, manter testes escritos a c numa linguagem de programaao seria praticamente to trabalhoso quanto manter testes c a escritos em HTML Selens, conforme j dito no cap e a tulo anterior. O cdigo gerado pelo Selenium RC deve, ento, ser refatorado. Refatoraao a o a c e reestruturaao de um cdigo existente, alterando sua estrutura interna sem provocar muc o danas no seu comportamento externo (FOWLER, 2004). De acordo com os Princ c pios de Refatoraao, cdigos repetidos devem ser agrupados num unico lugar e, apenas reusados c o onde for necessrio. Isso facilita a manuteno do cdigo, uma vez que, diante de uma a ca o mudana, necessrio alterar somente num unico lugar. c e a Visando criar classes com cdigo refatorado, neste trabalho prope-se o padro de o o a Procedimentos e Casos de teste para a criaao de testes funcionais utilizando o Selenium c RC. Esse padro de Procedimentos e Casos de teste similar ao padro PageObjects a e a (PAGE OBJECTS, 2009) e consiste basicamente em associar, para cada funcionalidade da aplicaao, uma classe para representar os procedimentos de teste e outra para representar c os casos de teste. Assim, o cdigo duplicado reduzido, uma vez que se uma funcionalidade o e tiver relaao com outra, a classe que a representa pode apenas ser reusada. E, alm disso, c e

44

diante de alguma mudana numa pgina da aplicaao, ser necessrio alterar somente c a c a a numa unica classe de procedimento. Outra vantagem adquirida por se utilizar esse padro, a est no fato de possibilitar melhor comunicaao entre os testadores de uma equipe de a c desenvolvimento, pois h uma linguagem comum para a criaao dos testes com o Selenium. a c No decorrer deste cap tulo, demonstrado como desenvolver testes com Selenium e utilizando o padro de Procedimentos e Casos de teste. Juntamente com isso, ser aprea a sentado como criar testes para aplicaoes WEB baseadas em AJAX. c

5.1

Criando um Procedimento e Casos de teste para o Login da aplicao ca

Como j foi criado o teste em Java para o Login da aplicao no cap a ca tulo anterior, ele ser reutilizado nesta seo para exemplicao do uso do padro de Procedimento e a ca ca a Casos de teste. A Figura 21 abaixo mostra o Procedimento de teste criado a partir do cdigo da Figura 17. o

Figura 21: Procedimento de Login criado a partir do teste escrito em Java Na Figura 21, merece destaque o mtodo waitForPageToLoad na linha 20. Esse e mtodo responsvel por fazer a execuao dos testes esperar durante um intervalo de e e a c tempo mximo at que uma nova pgina da aplicao carregue. O tempo mximo de a e a ca a espera (timeout) para que uma nova pgina carregue , por padro, 30000 milissegundos a e a (30s). Aps esse tempo, um erro ser retornado. O timeout padro pode ser alterado por o a a

45

meio do menu Opesdo Selenium IDE. co Poderia-se ter criado, para completar o Procedimento de Login, o mtodo sair, que e realiza o logout do sistema. Isso no foi feito, pois no ser totalmente necessrio neste a a a a exemplo. Depois de nalizada a criaao do procedimento, deve-se criar a classe de teste corresc pondente utilizando-se o JUnit 4 ao invs do JUnit 3, que o utilizado por padro no e e a teste gerado pelo Selenium IDE. A Figura 22 mostra o teste criado.

Figura 22: Classe de teste do Procedimento de Login O comando executado na linha 17 responsvel por iniciar o servidor do Selenium e a em tempo de execuo do teste. Isso foi poss devido a adiao do pacote seleniumca vel c server.jarno caminho de classes do projeto da aplicaao. A desvantagem de se iniciar o c servidor dessa maneira que no poss visualizar o log das aes como quando ele e a e vel co e iniciado pelo terminal. A classe DefaultSelenium, utilizada na linha 18, consiste na classe concreta da biblioteca cliente e deve ser instanciada com as conguraes bsicas para que haja comunicaao co a c com o servidor do Selenium e para que, assim, os testes possam ser executados. A seguir, uma pequena descrio de cada um dos parmetros do construtor dessa classe: ca a localhost - Informa o endereo do servidor, pois no necessariamente ele precisa esc a tar na mesma mquina onde os testes esto sendo executados. Assim, poss disa a e vel

46

tribuir a execuo dos testes por vrias mquinas, economizando tempo utilizandoca a a se execuo paralela dos testes. Esse assunto chama-se Selenium Grid e no ser ca a a detalhado neste trabalho por no fazer parte do escopo; a 4444 - E a porta padro utilizada pelo servidor do Selenium para estabelecer a a comunicao com a API cliente, como j dito no cap ca a tulo anterior; *refox - Corresponde ao navegador onde sero executados os testes. Para se a fazer essa conguraao num sistema operacional Linux, deve-se informar o caminho c completo do Bin do Firefox, assim, esse parmetro caria *refox /usr/refox/bin, a por exemplo; http://localhost:8080/exemploSelenium/ - Essa a URL da aplicaao a ser e c testada. Na classe TesteLogin.java da Figura 22, podem ser criados vrios outros casos de a teste, vericando se ao informar uma senha errada, por exemplo, a mensagem de erro e exibida corretamente. Quando se executa a classe TesteLogin.java como teste JUnit, o navegador ser aberto a automaticamente e o caso de teste testeLoginCorreto ser executado na aplicaao testada. a c Aps o trmino da execuao do teste, o navegador ser fechado e o JUnit dever sinalizar o e c a a a barra verde indicando que nenhum erro ocorreu.

5.2

Capturando as aoes para o Cadastro de Clientes c da aplicao ca

Nesta seao apresentado como gravar as aoes para testar o cadastro de clientes c e c utilizando o Selenium IDE. Essa gravaao deve ser iniciada a partir da pgina principal c a da aplicaao, aps a entrada no sistema, pois a classe de Procedimento do Login, j criada, c o a ser reutilizada no Procedimento de Cadastro de Clientes. a O processo de gravaao das aes para o cadastro de clientes praticamente o mesmo c co e utilizado na gravaao das aes para o Login, a diferena que existem alguns campos c co c e que so preenchidos com uso de AJAX. Nesse caso, devem ser utilizados alguns comandos a especiais do Selenium para a automaao da incluso de valores nesses campos. O uso c a desses comandos necessrio para que no haja erros no processo de automao. A Figura e a a ca 23 mostra a pgina do Cadastro de Clientes com alguns campos preenchidos durante o a processo de gravaao. c

47

Figura 23: Pgina de Cadastro de Clientes a O campo Munic pio, da Figura acima, um campo no qual, a cada letra digitada, e os munic pios cadastrados no sistema so buscados e mostrados via AJAX para serem a selecionados. A Figura 24 mostra como exibido um munic cadastrado a medida que e pio ` se digita o seu nome.

Figura 24: Campo Munic pio Nesse caso, para se automatizar a seleao do munic c pio, tem-se primeiro que utilizar um comando de asserao, chamado waitForText, sobre o valor Teresinasurgido. Esse c comando faz o teste esperar at que o valor AJAX em destaque aparea na tela. S depois e c o da assero, que se deve clicar no valor surgido, selecionando-se o munic ca e pio.

Figura 25: Incluso de Dependente a

48

A Figura 25 mostra como exibido um dependente depois de inserido na lista de dee pendentes de um cliente. A tabela da Figura onde so mostrados os dados do dependente a foi criada via AJAX. Para se automatizar a incluso nesse campo, necessrio, depois de inserido um dea e a pendente na tabela, fazer uma assero usando waitForText. Essa assero pode ser feita, ca ca por exemplo, sobre o nome do dependente para garantir que o dependente foi adicionado corretamente na lista de dependentes. Deve-se tambm fazer asseroes usando-se Asserte c Text sobre os demais valores da tabela, como o RGe o link Excluir, para garantir que eles apareceram corretamente.

Figura 26: Teste de Cadastro de Cliente exportado para Java

49

Figura 27: Classe de Procedimento de Cadastro de Cliente Depois de capturadas todas as aoes para cadastro de um cliente, o teste deve ser c exportado para Java. A Figura 26 exibe o resultado. As linhas 27 e 44 da Figura 26 mostram como feita a espera pelo valor AJAX ser e carregado na tela. H uma estrutura de repetiao que verica, de segundo a segundo, a c durante, no mximo, um minuto, se o valor AJAX apareceu na tela e, caso no tenha a a aparecido depois de um minuto, uma exceo (timeout) retornada. O comando Thca e read.sleep(1000) responsvel por fazer a execuo do teste dormirpor 1000ms (1s). e a ca E importante observar na linha 31, o mtodo selenium.getText(1). Ele retorna o e nome do munic que surgiu na tela. Esse nmero 1 o identicador do objeto munic pio u e pio Teresinano banco de dados da aplicaao. Assim, poss parametrizar esse valor no c e vel momento da criaao da classe de Procedimento, como ser demonstrado a seguir. c a

50

5.3

Criando um Procedimento e Casos de teste para o Cadastro de Clientes da aplicao ca

Nesta seao, o cdigo gerado pela IDE mostrado na Figura 26 refatorado e transc o e formado num procedimento de teste. A Figura 27 exibe a classe de procedimento criada. Na Figura 27, na linha 36, importante observar que o mtodo de aao type, chamado e e c para informar as iniciais de um munic pio, foi substitu pelo typeKeys. Isso foi feito do porque o type no funciona para campos que esto associados a algum evento AJAX. a a Utilizando o type, a busca AJAX no disparada, gerando erro de timeout no teste, a e uma vez que o comando waitForText car em espera pelo valor Teresinae ele no a a aparecer. J o typeKeys fora que algum evento associado ao campo seja disparado a a c (SELENIUM, 2009). Vale destacar ainda que, na mesma linha 36, o valor atribu para o campo Munic do pio no o nome completo do Munic a e pio, mas somente as quatro primeiras letras (Mtodo e substring(0,4)). Isso est implementado dessa forma porque, na aplicaao utilizada, um a c munic pio cadastrado somente buscado e mostrado por AJAX, a partir de quando se e digita a quarta letra do seu nome. Nas linhas 37 e 49, pode-se observar que a espera pelo valor AJAX foi encapsulada no mtodo TesteUtils.esperaPorValorAjax. Esse mtodo foi criado para evitar a repetio e e ca de cdigo e melhorar a legibilidade do teste. o Depois de nalizada a criaao do Procedimento de Cadastro de Clientes, a respectiva c classe de teste deve ser criada. A Figura 28 exibe a classe de teste. Ao executar a classe da Figura 28, o caso de teste inserirNovoCPFInvalido ser exea cutado na aplicao e, ao nal, o JUnit dever sinalizar a barra verde, indicando que o ca a teste ocorreu com sucesso.

5.4

Concluses a respeito do padro de Procedimeno a tos e Casos de teste

Por meio do uso do padro de Procedimentos e Casos de teste foi poss observar a vel que se passou a ter reusabilidade nos testes criados. Durante o teste do Cadastro de Clientes, por exemplo, foi reutilizado o Procedimento de Login. Assim, os testes tambm e cam mais fceis de manter, uma vez que, se houver alguma alterao na pgina de Login a ca a

51

Figura 28: Classe de teste para o cadastro de clientes da aplicaao, por exemplo, somente ser necessrio alterar na classe de Procedimento c a a correspondente. A utilizaao desse padro de grande importncia para que seja vivel a manutenao c a e a a c dos testes criados, porm todo esse processo algo dispendioso para ser seguido sempre e e que for necessria a criaao de testes funcionais. Muito tempo gasto para se moldar os a c e procedimentos de testes. Esse tempo exigido e os custos surgidos tendem, muitas vezes, a inviabilizar a criaao de testes funcionais em equipes de desenvolvimento. J sabemos que c a custos adicionais e restries de cronograma so fatores que impedem muitas empresas, co a mesmo sabendo a importncia dos testes, de utiliz-los de forma a garantir a qualidade a a dos softwares desenvolvidos. E necessrio, assim, extinguir ou reduzir o tempo de modelagem dos Procedimentos a de testes para que o desenvolvimento dos testes se volte para a criao dos Casos de testes. ca Isso contribui para reduzir o tempo necessrio para que se construam os testes funcionais. a No prximo cap o tulo, prope-se a Imaginarium, um prottipo de uma API feita em Java o o para encapsular a criao dos testes com Selenium utilizando o padro mostrado nesse ca a cap tulo. Essa API tem como um dos objetivos agilizar a criao dos Procedimentos de ca testes, tornando mais vivel o uso de testes funcionais em equipes de desenvolvimento. a

52

A API Imaginarium

A Imaginarium uma API feita em Java para encapsular o uso do Selenium e do e padro de Procedimentos e Casos de teste na criaao de testes funcionais para aplicaoes a c c WEB. Alm disso, a API traz mtodos que visam tornar o teste mais leg e fcil de e e vel a alterar ao permitir que determinado elemento UI (User Interface) de uma pgina HTML a seja identicado pelo seu respectivo nome exibido na pgina. Essa ultima caracter a stica da ferramenta se assemelha ao Tellurium (TELLURIUM, 2009), um framework para automao ca de testes que tambm utiliza o Selenium. e As principais funcionalidades da Imaginarium podem ser resumidas em duas: Geraao da classe de procedimento de teste a partir da anlise do HTML de uma c a pgina. A classe gerada contm os comandos para interagir com todos os elementos a e presentes naquela pgina. Isso faz com que o programador, com algumas pequenas a alteraoes, deixe o procedimento de teste da forma como deseja. Assim, o procedic mento de teste criado de uma forma mais rpida. E gerada tambm a respectiva e a e classe de teste pronta para serem criados os casos de teste. Fcil criao e alterao manual do teste gerado por meio do uso de mtodos caa ca ca e pazes de identicar alguns elementos UI por meio dos nomes exibidos na pgina. a Assim, no necessrio utilizar o Selenium IDE para saber como se referenciar a a e a determinado elemento; A Figura 29, demonstra, de uma forma geral, como o funcionamento da API. e

6.1

Principais tecnologias utilizadas

O Selenium RC a base da Imaginarium. Todos os comandos executados no navegador e so feitos mediante seu uso. H mtodos na biblioteca cliente Java do Selenium RC que a a e foram de grande importncia para o funcionamento da API. Dentre eles, pode-se citar a

53

Figura 29: Funcionamento da Imaginarium o eval. Esse mtodo capaz de executar um cdigo Javascript no navegador e trazer o e e o resultado para o cdigo Java. Essa funao do Selenium RC foi utilizada para se obter o o c corpo do HTML de uma pgina WEB em tempo de execuao. a c O HTML obtido em tempo de execuao transformado em XML usando as classes c e do pacote javax.xml.parsers (PARSER, 2009) da linguagem Java. A partir do tratamento do HTML como XML foi poss identicar quais elementos existem na pgina HTML vel a e, assim, criar classes de procedimento contendo comandos para interao com esses eleca mentos. Para identicar, dentre todos os elementos do HTML, quais correspondiam aos elementos de interaao com o usurio, como botes e links, foi utilizado XPath (XPATH, c a o 2009). O XPath uma linguagem utilizada para buscar informaoes em documentos e c XML. Utilizando-se essa linguagem, tambm foi poss criar mtodos na Imaginarium e vel e que identicassem os elementos UI da pgina HTML por meio de seus nomes. a

54

6.2

Documentao ca

Para um entendimento mais detalhado de como foi criada a Imaginarium, apree sentado na Figura 30 abaixo o Diagrama de Classes UML (Unied Modeling Language) contendo as principais classes e atributos.

Figura 30: Diagrama de Classes da API As principais classes do Diagrama so descritas a seguir: a Imaginarium: E a principal classe da API. Ela contm um atributo DefaultSelenium, e que, como j mencionado anteriormente, a classe concreta da biblioteca cliente do a e Selenium RC. A classe Imaginarium responsvel por: e a Criar uma instncia da classe DefaultSelenium, passando os valores de cona guraao contidos no arquivo de propriedades imaginarium.properties. c Iniciar o servidor do Selenium RC; Encapsular a chamada de alguns mtodos da DefaultSelenium tornando-os e mais fceis de entender e de usar. O mtodo clickButton, por exemplo, clica a e num boto da pgina cujo nome tem relaao com o nome informado ao mtodo. a a c e

55

Figura 31: Trecho de cdigo da classe Imaginarium: mtodos clickButton o e O segundo mtodo clickButton da Figura recebe o textContent, ou seja, o nome e do boto na pgina e chama o mtodo click da DefaultSelenium utilizando XPath. a a e A descriao do XPath passado ao mtodo click est dizendo que deve ser clicado c e a num boto, localizado em qualquer lugar da pgina, cujo texto da tag HTML Buta a toncontm o valor da varivel textContent. O parmetro position desse mtodo e a a e deve ser utilizado quando h mais de um boto com um mesmo nome numa pgina. a a a Ento, para distinguir os dois, informa-se a posio ou a ordem (de cima para baixo) a ca em que o boto aparece na pgina, se o primeiro ou o segundo, por exemplo. Os a a e mtodos da API para cliques em links seguem esse mesmo padro de identicaao e a c de elementos. ProcedureGenerator: E a segunda classe mais importante. Ela possui um atributo da classe Imaginarium. A classe ProcedureGenerator responsvel por gerar uma e a classe de procedimento e um modelo de classe de caso de teste a partir de determinada pgina HTML. No prximo tpico, onde ser demonstrado como utilizar a a o o a API, os mtodos dessa classe sero apresentados. e a UIElement: E uma interface que representa os elementos UI de uma pgina. Todas a as classes que implementam essa interface, como Button, Link e Parameterizable, devem ter um mtodo chamado getCommand que especica o comando da Imaginae rium a ser utilizado para interagir com esse elemento. Existem outros elementos UI em pginas HTML, como o Input radio e o Input check, que ainda no so represena a a tados pela API. Somente foram representados os elementos existentes na aplicaao c exemplo utilizada neste trabalho. Parameterizable: Representa todos os elementos UI que podem se tornar um parmetro a de um mtodo de uma classe de procedimento. Os Input text de uma pgina, por e a exemplo, que correspondem as caixas de texto, como os campos de login e senha, ` precisam ter seus valores passados por parmetro no mtodo do seu procedimento a e de teste. Isso foi demonstrado durante a criao da classe de Procedimento de Login ca no cap tulo 4. ProcedureMethod: Representa um mtodo pertencente a uma classe de procedie

56

mento a ser gerada. Um ProcedureMethod possui uma coleo de UIElement. O ca mtodo toString dessa classe responsvel por construir um mtodo de procedie e a e mento a partir dos atributos e de outros mtodos da classe. e UIElementsFactory: Representa a fbrica de todos os UIElement de um determinado a ProcedureMethod. Ela instancia os UIElement a partir dos elementos UI existentes numa determinada pgina HTML. E nessa classe que a pgina HTML carregada a a e em memria e lida como um arquivo XML. o TestProcedure: Representa uma classe de procedimento de teste que ser gerada a a partir de uma pgina HTML. Um TestProcedure possui uma coleo de Procedurea ca Method. O mtodo toString responsvel por construir uma classe de procedimento e e a a partir dos atributos e mtodos da classe. e TestCase: Representa uma classe de caso de teste a ser gerada juntamente com sua respectiva classe de procedimento. Uma classe de caso de teste gerada apenas um e modelo, devendo o usurio adicionar manualmente os casos de teste. a No prximo tpico, ser apresentado um guia de como desenvolver testes funcionais o o a com a Imaginarium.

6.3

Desenvolvendo testes funcionais com a Imaginarium

A aplicao WEB usada neste exemplo a mesma j utilizada nos cap ca e a tulos anteriores. Para demonstrar o uso da Imaginarium, ser criado o Procedimento e Caso de teste para a o Login e para o Cadastro de Clientes da aplicaao, os mesmos j criados no cap c a tulo anterior.

6.3.1

Congurando a API

Para utilizar a Imaginarium, preciso ter, alm dos pacotes selenium-server.jare e e o selenium-java-client-driver.jardo Selenium RC, o pacote imaginarium.jar. E necessrio, tambm, criar um arquivo chamado imaginarium.propertiesna pasta raiz do a e projeto onde sero criados os testes. Esse arquivo deve conter a informaao sobre onde a c sero gerados os procedimentos e os casos de teste e outras informaes necessrias para a co a que os testes sejam executados. A Figura 32 exibe um exemplo desse arquivo.

57

Figura 32: Imaginarium.properties As linhas 3 a 6 correspondem `s informaoes necessrias para se criar uma instncia a c a a da classe DefaultSelenium, conforme mostrado no cap tulo anterior. As linhas 7 e 8 dizem respeito aos diretrios onde sero geradas as classes de procedimento e de casos de teste o a respectivamente.

6.3.2

Gerando os Procedimentos e Casos de teste para o Login

Depois de congurado a Imaginarium, necessrio criar uma classe executvel na e a a qual sero utilizados os mtodos da classe ProcedureGenerator. A classe ProcedureGea e nerator, conforme mencionado, a classe da Imaginarium responsvel por gerar a classe e a de procedimento de teste e um modelo de classe de casos de teste. A Figura 33 abaixo demonstra como deve ser o uso dessa classe.

Figura 33: Utilizando a classe ProcedureGenerator A descriao de cada um dos mtodos de ProcedureGenerator utilizados na classe da c e Figura feita logo abaixo: e openApplication: Instancia a classe Imaginarium, carregando as conguraoes do c arquivo imaginarium.properties e iniciando o servidor do Selenium RC. Em seguida, o navegador aberto na pgina inicial da aplicaao testada. e a c

58

prepareNewTestProcedure: Inicia a criaao de um novo procedimento de teste, recec bendo o seu nome por parmetro. Aqui so instanciadas as classes TestProcedure a a e TestCase mencionadas no Diagrama de Classes. includeMethod : Cria um mtodo na classe de procedimento contendo comandos para e interagir com todos os elementos da pgina atual. Nesse exemplo, a pgina atual a a e a pgina inicial da aplicaao, ou seja, a pgina de Login, pois o mtodo chamado a c a e e assim que a aplicao carregada. O primeiro parmetro (entrar) do mtodo ca e a e includeMethod corresponde ao nome do mtodo a ser criado. O segundo parmetro e a (UIElement.LINK ) informa que tipos de elementos no devem ser considerados a na geraao dos comandos. Nesse caso no se deseja que sejam considerados links, c a pois se sabe que esses elementos no so necessrios para fazer Login na aplicaao. a a a c Apenas so necessrios elementos Input Text (Caixa de texto) e Button (Boto). a a a Se esse parmetro no fosse informado, ento todos os tipos de elementos seriam a a a considerados na geraao. O terceiro (true), e ultimo parmetro, informa se deve c a ser gerado um parmetro para uma mensagem no mtodo a ser criado. Nesse caso, a e informamos true, porque ser necessrio vericar a mensagem que surge na pgina a a a aps o Login. E importante ressaltar que pode ser criado mais de um mtodo o e dentro de uma mesma classe de procedimento de teste. Para isso, bastaria realizar novamente a chamada ao mtodo includeMethod sobre uma nova pgina, antes da e a geraao da classe de procedimento. Ento, esse novo mtodo conteria os comandos c a e relativos aos elementos dessa pgina. a generateClass: Gera a classe de procedimento e um modelo de classe de caso de teste nos diretrios informados no arquivo de congurao. A classe de Procedio ca mento gerada ter o nome seguindo o padroProcedure+ Nome informado. Nesse a a exemplo, o nome da classe de procedimento ProcedureLogin. A classe de caso e de teste ter o nome TestLogin. a closeApplication: Para o servidor do Selenium, fechando o navegador. Ao executar a classe GeradorProcedimentosTeste da Figura 33, o navegador ser a aberto na pgina principal, ento ser feita a leitura do HTML da pgina. Em seguida, a a a a os objetos da API sero criados e as classes sero geradas. Por ultimo, o navegador ser a a a fechado. As Figuras 34 e 35 exibem as classes geradas nos respectivos diretrios informados no o arquivo imaginarium.properties.

59

Figura 34: Classe ProcedureLogin

Figura 35: Classe TestLogin Pode-se observar, por meio da Figura 34, que a classe de Procedimento de Login foi gerada e dentro dela foi criado o mtodo entrarque tem como parmetros, o login e a do usurio, a senha e uma mensagem para vericar o resultado obtido. A chamada a Imaginarium.getInstance feita na linha 9, responsvel por trazer a atual instncia da e a a Imaginarium em memria. Caso ainda no haja nenhuma instncia, ento uma nova o a a a e retornada. Assim, utilizada somente uma instncia dessa classe durante a execuao de e a c um conjunto de casos de teste. Essa implementaao segue o padro Singleton(FREEMAN; c a
FREEMAN,

2005).

Vale a pena destacar o mtodo clickButtonAndWait na linha 12 da Figura 34. Ele e encapsula a chamada ao waitForPageToLoad do Selenium e recebe por parmetro o nome a do boto na pgina, que no caso Conrmar. a a e Na Figura 35 poss ver o modelo da classe de teste para o procedimento de Login e vel gerado. O usurio da API dever apenas incluir os casos de teste fazendo as chamadas a a ao mtodo entrarda classe de Procedimento. Poderiam ser criados vrios casos de teste e a

60

vericando que mensagens so exibidas para determinados valores de login e senha. a E importante observar que no foi necessria nenhuma alteraao na classe de Procea a c dimento de Login gerada pela API. Porm, isso nem sempre vai acontecer. No tpico a e o seguir, por exemplo, necessrio que o usurio da API tenha que fazer algumas pequenas e a a modicaoes na classe gerada para nalizar a construao do procedimento de teste. c c

6.3.3

Gerando os Procedimentos e Casos de teste para o Cadastro de Clientes

Figura 36: Utilizando ProcedureGenerator para o Cadastro de Clientes Na criaao da classe ProcedureLogin no foi necessrio fazer nenhuma navegao na c a a ca aplicaao para se chegar ` tela de Login, pois ela era a primeira pgina. No caso da criaao c a a c do Procedimento e Caso de teste para o Cadastro de Clientes, isso diferente.Como se e pode ver na Figura 36, preciso primeiro navegar at a pgina de incluso de clientes para, e e a a s ento, gerar o procedimento a partir dessa pgina. Para se chegar ` pgina de incluso o a a a a a de um cliente, necessrio passar pelo Login da aplicaao, clicar na Aba Cadastros, e a c depois no link Clientes, e, por ultimo, no boto Inserir Novo. Os mtodos utilizados a e da linha 14 a linha 18 so responsveis por executar essas aoes. Como se pode observar, ` a a c e poss utilizar esses mtodos sem necessidade de captura pelo Selenium IDE. O usurio vel e a da API precisa apenas conhecer os nomes dos elementos nas telas da aplicaao para fazer c chamada a esses mtodos. e Um desses mtodos, o insertDependenceOfTestProcedure, chamado na linha 14, ine forma que o procedimento que est sendo criado depende de outro para ser gerado. Esse a mtodo recebe o nome da classe de Procedimento, que no caso ProcedureLogin, o nome e e do mtodo a ser acessado e os parmetros passados para esse mtodo. Utilizando Reece a e

61

tion [30] do Java, o mtodo entrarda classe ProcedureLogin executado, posicionando, e e assim, a aplicao na pgina principal. ca a Em seguida, os mtodos e clickSectionAndWait, clickLinkAndWait e

clickButtonAndWait, conforme mencionado, executam as aes para se chegar at a pgina co e a de incluso de um novo cliente. E importante observar que o mtodo clickSectionAndWait a e est recebendo, por parmetro, o valor Cadastros. Sendo assim, o mtodo correto que a a e deveria estar sendo utilizado aqui seria o clickLinkAndWait, uma vez que o valor Cadastroscorresponde a um link da pgina. Esse mtodo clickSectionAndWait foi necessrio a e a devido a um problema encontrado no momento de identicar o link Cadastros. A forma como ele est representado na pgina HTML difere dos demais links. A Figura 37 exibe a a o trecho do HTML da pgina mostrando o link Cadastros. a

Figura 37: HTML do Link Cadastros Como se pode ver, h uma tag spandentro da tag ae, s depois, que se tem o a o e nome do link. Isso faz com que no seja poss identicar esse link da mesma forma a vel como so identicados os botes e os demais links da aplicaao. Ento, para que fosse a o c a poss demonstrar o uso da API neste trabalho, criou-se o mtodo provisrio5 clickSecvel e o tionAndWait compat com esse link, mas incompat com outras aplicaes WEB. vel vel co Foi necessrio modicar o XPath padro da API para que esse mtodo considerasse a a a e presena da tag span. A Figura 38 mostra como foi implementado o mtodo clickSecc e tionAndWait.

Figura 38: Implementaao do mtodo clickSectionAndWait c e Na linha 19 da Figura 36 gerado o mtodo inserirNovosobre a pgina de incluso e e a a de clientes. As Figuras 39 e 40 exibem as classes geradas a partir da execuo da classe ca GeradorProcedimentosTeste. E importante destacar as linhas 10 a 12 da Figura 396 . Elas referem-se aos comandos que foram utilizados para se chegar ` pgina de incluso de clientes durante a geraao do a a a c
E importante lembrar que a API proposta neste trabalho ainda somente um prottipo. A criao e o ca desse mtodo provisrio, mesmo apresentando incompatibilidade com outras aplicaes, importante e o co e para que se possam demonstrar alguns objetivos da Imaginarium: mtodos fceis de entender e de usar. e a 6 Para uma melhor visualizao, a Figura 39 est incompleta devido a grande quantidade de parmetros ca a a do mtodo inserirNovo. e
5

62

Figura 39: Classe ProcedureCliente procedimento. Ou seja, a API considera como comandos de um mtodo de procedimento, e no s os comandos referentes aos elementos da pgina, mas tambm os comandos de a o a e aao utilizados para a gerao desse mtodo de procedimento. c ca e Outra linha que merece destaque a linha 21 da Figura 39. Essa linha refere-se ` aao e a c de digitar no campo munic pio. Foi visto no cap tulo anterior que esse campo um campo e AJAX. Portanto, a forma como foi gerada a interao com ele na classe ProcedureCliente ca no est correta. No se sabe ainda uma maneira de reconhecer campos AJAX de forma a a a automtica. Assim, essa linha gerada pela API dever ser alterada manualmente pelo a a usurio para que a automao seja feita da forma correta conforme ensinado no cap a ca tulo anterior. A Imaginarium fornece, nesses casos, apenas mtodos mais simples para serem utilie zados. Um exemplo desses mtodos o waitForValue. Esse mtodo encapsula a espera e e e por um valor AJAX da mesma forma como o mtodo esperaPorValor criado no exemplo e do cap tulo anterior. Alm desse mtodo, tem-se tambm o mtodo getTextTable, utilie e e e zado para vericar os valores exibidos numa tabela HTML. A Figura 41 exibe o trecho da classe ProcedureCliente onde foi necessria a utilizao desses mtodos. a ca e Para nalizar a criaao do procedimento da Figura 39 ainda necessrio excluir c e a comandos gerados que no so necessrios para a automao da incluso de clientes. a a a ca a Pode-se observar, na linha 29, que foi gerado o comando clickButton(Cancelar), pois na pgina havia esse boto. E preciso ento, remover essa linha, uma vez que ela no a a a a e

63

Figura 40: Classe TestCliente

Figura 41: Alteraao na classe ProcedureCliente para vericao de campos AJAX c ca necessria para o procedimento. a Em relaao ` classe de teste gerada, na Figura 40, pode-se observar que foi feita c a uma chamada para o Login da aplicaao no mtodo @BeforeClass. Isso permite que o c e login no sistema seja realizado sempre antes do inicio da execuao dos casos de teste c da classe TestCliente. A gerao desse mtodo foi feita porque, durante a gerao, foi ca e ca informado que o Procedimento de Cliente depende do Procedimento de Login (mtodo e insertDependenceOfTestProcedure de ProcedureGenerator ). Assim, o usurio da API pode a criar os seus casos de teste utilizando apenas a classe ProcedureCliente.

6.4

Anlise de produtividade a

Nesta seo, apresentado um relatrio com o objetivo de demonstrar a tendncia ca e o e de se obter maior produtividade na criao de testes funcionais para aplicaoes WEB ca c utilizando-se a Imaginarium.

64

6.4.1

Metodologia

Utilizou-se uma metodologia informal para avaliaao da API. Assim, os resultados a c serem obtidos nessa anlise no possuem total preciso cient a a a ca. Para uma real medio, ca deve ser feita uma avaliaao utilizando-se os mtodos da Engenharia de Software Experic e mental. A Engenharia de Software Experimental destina-se a melhorar a Engenharia de Software atravs da aplicaao da experimentaao (mtodo cient e c c e co) para a construo e ca avaliaao de tecnologias de software (processos, mtodos, tcnicas e ferramentas) (GRUPO c e e
DE ENGENHARIA DE SOFTWARE EXPERIMENTAL,

2009).

6.4.2

Procedimentos

Criaram-se as classes de procedimento e de casos de teste para o login e para o cadastro de clientes, munic pios e usurios da aplicaao WEB utilizada neste trabalho. Ao nal da a c criaao de cada classe de procedimento, criou-se um respectivo caso de teste para vericar c se o teste foi automatizado corretamente. Para realizar essas tarefas, utilizou-se, numa primeira etapa, o Selenium e, numa segunda, a Imaginarium. ramentas. Para cada uma dessas etapas, mediu-se o tempo gasto e observaram-se quais os obstculos surgidos com a utilizao de cada uma dessas fera ca

6.4.3

Resultados

Os Resultados obtidos so exibidos nas Figuras 42 e 43 abaixo: a

6.4.4

Anlise dos resultados a

De acordo com os resultados, pode-se concluir que o uso da Imaginarium, para criaao c dos testes funcionais, tende a trazer maior produtividade do que o uso do Selenium. Utilizando-se a Imaginarium, gastou-se, praticamente, metade do tempo necessrio para a a criaao dos testes com o Selenium. c Vale destacar ainda que, quanto mais procedimentos se tm para criar, maior tende a e ser a diferena entre os tempos obtidos. Conforme mencionado nas observaes da Figura c co 42, a cada nova classe de procedimento criada para uma determinada funcionalidade,

65

Figura 42: Tabela com os resultados obtidos

Figura 43: Grco Ferramenta x Tempo gasto a menos tempo se gastava para criar outro procedimento para uma funcionalidade similar. Por exemplo, uma vez criada a rotina de gerao das classes de procedimento para o ca Cadastro de Clientes, pde-se reus-la para criar os procedimentos dos demais cadastros, o a como o de Munic pios e o de Usurios. Isso foi poss porque os cadastros da aplicaao a vel c utilizada seguem um mesmo padro de telas, o que comum em muitas outras aplicaoes. a e c A classe utilizada para a gerao dos procedimentos dos cadastros da aplicao segue ca ca anexa a este trabalho.

6.5

Concluses sobre o uso da Imaginarium o

O uso da Imaginarium trouxe uma srie de melhorias para a criao dos testes fune ca cionais. A classe ProcedureLogin, por exemplo, gerada com a Imaginarium, executa as

66

mesmas aoes que a classe de Procedimento de Login que foi criada no cap c tulo anterior, mas o seu cdigo est bem mais simples. Alm disso, a possibilidade de identicar alguns o a e elementos pelos seus nomes na pgina torna o teste mais leg e fcil de modicar. Na a vel a Figura 44 so demonstradas as duas classes de Procedimento de Login, uma criada no a cap tulo anterior e a outra que foi criada pela Imaginarium.

Figura 44: Procedimentos de Login De uma forma geral, podemos enumerar uma srie de vantagens obtidas com o uso e da Imaginarium: 1. Menor curva de aprendizado necessria para criar testes com o Selenium. No a a e necessrio utilizar o Selenium IDE e nem aprender Selenium RC. At a execuo do a e ca servidor do Selenium RC encapsulada pela API. e 2. Gerao automtica de classes utilizando o padro de Procedimentos e Casos de ca a a teste. O usurio, alm de no precisar saber adequar os testes a esse padro, pode a e a a deixar um procedimento de teste gerado da forma como deseja com nenhuma ou pouca modicaao. Alm disso, na classe de teste necessrio somente incluir os c e e a casos de teste, fazendo chamadas aos mtodos da classe de procedimento. Como e j foi visto, os testes criados utilizando esse padro so mais fceis de reusar e de a a a a manter. 3. Mtodos fceis de entender e de usar. Alguns mtodos permitem a identicaao de e a e c elementos HTML por meio dos nomes desses nas pginas da aplicao testada. a ca 4. Uma vez criada uma rotina para geraao de determinado procedimento de teste, c a criaao da rotina de geraao de outro procedimento de teste com funcionalidade c c semelhante, tende a ser mais rpida. Uma rotina de geraao pode ser facilmente a c reusvel. a

67

5. O cdigo gerado pela API fcil de ler e no repetitivo. Lembrando que poss o e a a e e vel determinar, antes da gerao, que tipos de elementos UI devem ser desconsideraca dos. Isso evita a geraao da classe de procedimento contendo muitos comandos c desnecessrios. a a 6. E fcil no s criar classes de procedimento para funcionalidades de uma aplicao, a o ca como tambm reusar classes de procedimento j criadas. O Procedimento de Login, e a por exemplo, foi facilmente reusado para a gerao do Procedimento de Cadastro ca de Clientes. 7. Como conseqncia de seu uso, tende-se a ter uma maior produtividade na criaao ue c dos testes funcionais, destinando-se mais tempo para a criao dos casos de teste. ca Dentre desvantagens da Imaginarium, podemos destacar: 1. O prottipo ainda no compat com todas as aplicaoes WEB. A API apreo a e vel c senta mtodos que esto amarrados ` aplicao utilizada neste trabalho. O mtodo e a a ca e clickSectionAndWait da Figura 38, por exemplo. 2. E preciso informar os comandos para interaao com campos AJAX manualmente. c A API no gera isso de forma automtica. a a

68

Concluso a

A atividade de teste de software de grande importncia para a criaao de softwares e a c de qualidade, mas sua introduao no ciclo de desenvolvimento demanda grandes custos. c Devido a esse fato, muitas organizaoes no utilizam a atividade de teste de modo a c a diminuir o risco no uso de seus softwares. Para diminuir os custos nessa atividade, existem, dentro do escopo de aplicaoes WEB, ferramentas de teste como o Selenium. Porm, criar c e testes com essa ferramenta de forma organizada e fcil de manter uma tarefa muito a e dispendiosa, o que pode, muitas vezes, inviabilizar seu uso por equipes de desenvolvimento. A Imaginarium, API proposta neste trabalho, mostrou-se uma soluo para esses ca problemas surgidos com a criao de testes funcionais com o Selenium. Embora a API ca tenha apresentado desvantagens, com seu uso foi poss a criaao de testes mais leg vel c veis, fceis de manter e de reusar, encapsulando o uso do padro de Procedimentos e Casos de a a teste. Alm disso, viu-se tambm que a Imaginarium tende a trazer maior produtividade e e para o desenvolvimento dos testes funcionais. Dessa forma, o uso da Imaginarium tende a trazer, como contribuiao para a rea c a de testes, uma diminuio nos custos envolvidos em atividades de testes funcionais em ca aplicaoes WEB. Isso atua como um incentivo para que organizaoes possam utilizar esses c c tipos de testes durante seu processo de desenvolvimento, obtendo melhoria na qualidade dos softwares desenvolvidos. A Imaginarium contribui, tambm, para que sejam realizados e outros estudos com o intuito de automatizar cada vez mais o processo de criaao de testes c funcionais. Como trabalhos futuros, pretende-se realizar inmeras melhorias na API com o objeu tivo de eliminar suas atuais desvantagens e de automatizar cada vez mais o processo de criaao de testes funcionais com o Selenium. Dentre essas melhorias, destacam-se: c 1. Tornar a API compat com qualquer aplicaao WEB, criando mecanismos mais vel c ex veis para localizaao dos elementos de uma pgina HTML. c a 2. Estudar maneiras de se reconhecer campos AJAX em tempo de execuao da aplicaao, c c

69

visando gerar classes de procedimento com menor necessidade de alterao. ca Alm dessas melhorias, pretende-se fazer um trabalho para avaliar a Imaginarium utie lizando os rigores da Engenharia de Software Experimental. Lembrando que a avaliaao c feita neste trabalho foi apenas para demonstrar a tendncia de se obter maior produtivie dade com o uso da API.

70

Referncias e
ABBOT. Abbot framework for automated testing of Java GUI components and programs. 2009. Dispon em: <http://abbot.sourceforge.net/doc/overview.shtml>. Acesso em: vel 03 de Fevereiro de 2009. ANT. The Apache Ant Project. 2009. Dispon em: <http://ant.apache.org/>. Acesso vel em: 06 de Fevereiro de 2009. BECK, K. Test Driven Development: By Example. [S.l.]: Editora Addison Wesley Professional, 2002. Addison-Wesley Signature Series. CAETANO, C. Automao e Gerenciamento de Testes: Aumentando ca a Produtividade Com As Principais Solues Open Source e Gratuico tas. [S.l.]: http://www.linhadecodigo.com.br, 2007. E-Book vendido em: http://www.linhadecodigo.com.br/EBook.aspx?id=2951. CANOO. Canoo WebTest. 2009. Dispon vel em: <http://webtest.canoo.com/webtest/manual/WebTestHome.html.>. Acesso em: 03 de Fevereiro de 2009. CONNTINUUM. Conntinuum. 2009. Dispon em: <http://continuum.apache.org/>. vel Acesso em: 02 de Agosto de 2008. CRUISE. Cuise Control. 2009. Dispon em: <http://cruisecontrol.sourceforge.net/>. vel Acesso em: 06 de Fevereiro de 2009. DUVALL, P.; MATYAS, S.; GLOVER, A. Continuous Integration: Improving Software Quality and Reducing Risk. [S.l.]: Editora Addison Wesley Professional, 2007. Addison-Wesley Signature Series. FOWLER, M. Refatorao: Aperfeioando o Projeto de Cdigo Existente. 1a . ed. [S.l.]: ca c o Editora Bookman, 2004. FREEMAN, E.; FREEMAN, E. Use a cabea! Padres de Projeto (Design Patterns). c o a 1 . ed. Rio de Janeiro: Editora Alta Books, 2005. Pg. 150-166. FUNCIONAL TEST. Open source functional testing tools. 2009. Dispon vel em: <http://www.opensourcetesting.org/functional.php>. Acesso em: 26 de Dezembro de 2008. GAZOLA, A.; DAVID, E. Testes unitrios para camadas de negcios no mundo real. a o Mundo Java, v. 23, p. 5461, 2007. GRUPO DE ENGENHARIA DE SOFTWARE EXPERIMENTAL. Grupo de Engenharia de Software Experimental. 2009. Dispon em: <http://lens-ese.cos.ufrj.br/ese/>. vel Acesso em: 17 de Fevereiro de 2009.

71

HUSTED, T.; MASSOL, V. JUnit in Action. [S.l.]: Editora Addison Wesley Professional, 2003. Manning Publications. IEEE. IEEE Standard Glossary of Software Engineering Terminology. 1990. Std. 610.12-1990. Dispon vel em: <http://standards.ieee.org/reading/ieee/std public/description/se/610.121990 desc.html>. Acesso em: 01 de Fevereiro de 2009. IEEE. Guide to the Software Engineering Body of Knowledge. 2004. IEEE Computer Society. Dispon em: <http://standards.ieee.org/>. Acesso em: 01 de Fevereiro de vel 2009. ISTQB. International Software Testing Qualications Board. 2009. Glossario de Termos de Teste-Versao-1.3. Dispon em: <http://www.bstqb.org.br/>. Acesso em: 01 de vel Fevereiro de 2009. MARATHON. Marathon. 2009. Dispon vel em: <http://www.marathontesting.com/Marathon.html>. Acesso em: 06 de Agosto de 2008. MARICK, B. The Craft of Software Testing: Subsystem Testing Including Object-Based and Object-Oriented Testing. [S.l.]: Prentice Hall, 1995. MESZAROS, G. xUnit Test Patterns: Refactoring Test Code. [S.l.]: Editora Addison Wesley Professional, 2007. Addison-Wesley Signature Series. NETO, P. de Alcntara dos S. Apostila de Teste de Software. [S.l.], 2005. Curso de curta a duraao ministrado/Extenso. c a PAGE OBJECTS. The Page Object pattern. 2009. Dispon vel em: <http://code.google.com/p/webdriver/wiki/PageObjects>. Acesso em: 20 de Janeiro de 2009. PARSER. Parser. 2009. Dispon vel em: <http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/package-summary.html>. Acesso em: 12 de Fevereiro de 2009. PDUA, W. de. Engenharia de Software: Fundamentos, mtodos e padres. 2a . ed. [S.l.]: a e o Editora LTC, 2003. PRESSMAN, R. S. Engenharia de Software. 6a . ed. [S.l.]: Editora McGraw-Hill, 2006. SELENIUM. Selenium Web Application Testing System. 2009. Dispon vel em: <http://seleniumhq.org/>. Acesso em: 02 de Agosto de 2008. SOMMERVILLE, I. Engenharia de Software. 6a . ed. [S.l.]: Editora Addison Wesley Pearson, 2003. SPILLNER, A.; LINZ, T.; SCHAEFER, H. Software Testing Foundations. 2a . ed. [S.l.]: Editora Rocky Nook, 2007. TELLURIUM. Tellurium Automated Testing Framework. 2009. Dispon vel em: <http://code.google.com/p/aost/>. Acesso em: 26 de Fevereiro de 2009.

72

W3SCHOOLS. JavaScript Tutorial. 2009. Dispon vel em: <http://www.w3schools.com/JS/default.asp>. Acesso em: 17 de Fevereiro de 2009. WATIN. Web Application Testing In .Net. 2009. Dispon vel em: <http://watin.sourceforge.net/>. Acesso em: 03 de Fevereiro de 2009. WTR. Web App Testing in Ruby. 2009. Dispon em: <http://wtr.rubyforge.org/>. vel Acesso em: 03 de Fevereiro de 2009. XML. Extensible Markup Language (XML). 2009. Dispon vel em: <http://www.w3.org/XML/>. Acesso em: 12 de Fevereiro de 2009. XPATH. xPath Tutorial. 2009. Dispon vel em: <http://www.w3schools.com/Xpath/default.asp>. Acesso em: 12 de Fevereiro de 2009.

73

ANEXO A -- Classe para Gerao dos ca Procedimentos de Teste dos Cadastros

Figura 45: Classe para Geraao dos Procedimentos de Teste dos Cadastros c