Automação de testes funcionais com o Selenium

Capítulo 2 Automação de testes funcionais com o Selenium Ismayle de Sousa Santos, Pedro de Alcântara dos Santos Neto Abstract The software testing is fundamental in software quality assurance. The testing can be split according with its objective. An important testing objective is the check of the product behavior. This kind of test is known as functional testing. However, the systematic execution of testing requires time and effort. Many times this activity is ignored. It is important the use os testing tools in order to automate this activity. Selenium is an example of this. It is free of charge and it can export the generated tests for a great variety of technologies, like PHP, Java and Ruby. This work presents the basic concept related to functional testing and describes how to use Selenium integrated to Java. The work also presents good practices related to software testing that can increase productivity and reusability. Resumo O teste de software é um elemento fundamental na garantia da qualidade. Os testes podem ser divididos de acordo com seu objetivo. O teste funcional, por exemplo, tem por objetivo verificar o comportamento do produto desenvolvido. Contudo, a realização do teste, de forma sistemática, exige tempo e recursos, sendo por muitas vezes desconsiderado. Assim, é importante que os testadores utilizem ferramentas que automatizem de alguma forma essa atividade. O Selenium é um exemplo de ferramenta que auxilia essa atividade. Ela tem se destacado atualmente por ser gratuita e pela possibilidade de exportação dos testes criados a partir do seu uso para as mais variadas tecnologias, como PHP, Ruby ou Java. Este trabalho apresenta conceitos básicos do teste funcional, além de descrever como utilizar o Selenium integrado à linguagem Java. A partir dessa integração serão apresentados boas práticas que podem ser aplicadas ao desenvolvimento de testes funcionais, favorecendo produtividade e reusabilidade dos testes. 2.1. Introdução No cenário atual, em que softwares estão presentes nas diversas atividades do cotidiano e no qual os sistemas estão cada vez mais voltados para web, a qualidade exigida pelos

clientes sobre os softwares desenvolvidos se torna cada vez maior. Uma das formas mais utilizadas e recomendadas para se garantir a qualidade de software se dá a partir da realização de testes, visto que testes podem ser usados para revelar a presença de defeitos [Myers 2004]. O teste de software pode ser definido como a verificação dinâmica do funcionamento de um programa, utilizando um conjunto finito de casos de teste, adequadamente escolhido dentro de um domínio de execução, em geral infinito, contra seu comportamento esperado [Abran et al. 2004]. Assim, um teste, de maneira geral, envolve a execução de um programa com a aplicação de certos dados de entrada, examinando suas saídas, verificando se elas combinam com o esperado e estabelecido nas suas especificações. É importante ressaltar que os testes não garantem que o software não contém erros, pois para isso seria necessário testar todas as entradas válidas, o que geralmente é impossível. Ao realizarmos testes durante o desenvolvimento de software adicionamos valor ao produto, uma vez que o teste corretamente executado tende a descobrir defeitos, que devem ser corrigidos, aumentando assim a qualidade e confiabilidade de um sistema [Pressman 2006]. A falta de testes pode fazer com que o software desenvolvido seja entregue com defeitos, o que pode trazer muitos problemas, como por exemplo, prejuízos financeiros, danos físicos e até perda de vidas humanas, além de prejudicar a imagem da equipe desenvolvedora perante a empresa e desta para com o cliente. Além disso, o custo de não testar é muito maior, já que a identificação de erros se torna mais difícil e onerosa nos estágios finais do projeto e os custos para reparação crescem em uma escala elevada com o passar do tempo [Patton 2006]. Existem vários tipos de testes, cada um voltado para um determinado objetivo. Testes podem ser criados para verificar se as especificações funcionais estão corretamente implementadas (teste funcional), podendo ser executados diretamente pelos usuários finais para decidir sobre a aceitação do produto desenvolvido (teste de aceitação); podem verificar se o desempenho do software está dentro do aceitável (teste de desempenho); se ele funciona sob condições anormais de demanda (teste de estresse); se o software é adequado ao uso (teste de usabilidade); testes podem ter como objetivo mostrar que o software continua funcionando após alguma alteração (teste de regressão); se os procedimentos de instalação são corretos e bem documentados (teste de instalação); para verificar o seu nível de segurança (teste de segurança); ou para verificar seu funcionamento, a partir da liberação do produto para pequenos grupos de usuários trabalhando em um ambiente controlado (teste alfa) ou em um ambiente não controlado (teste beta) [Neto et al. 2007]. Os testes, entretanto, requerem tempo, conhecimento, planejamento, infraestrutura e pessoal especializado, sendo, portanto, uma atividade onerosa [Myers 2004]. Dependendo do tipo de sistema a ser desenvolvido, ela pode ser responsável por mais de 50% dos custos [Pressman 2006]. Para se ter uma idéia dos custos envolvidos, de acordo com um relatório publicado pelo NIST [NIST 2002], U$59.500.000.000,00 é o valor relativo ao custo de falhas em softwares desenvolvidos nos Estados Unidos, apenas em 2002. Esse mesmo relatório estima que mais de 37% desse custo (U$22.200.000.000,00) poderia ter sido eliminado se a infraestrutura para teste fosse melhorada. Uma forma de reduzir os custos da atividade de testes é a partir da automação dos testes usando alguma ferramenta apropriada. No caso dos testes funcionais, a maioria

das ferramentas disponíveis se baseia na gravação de todas as ações executadas por um usuário, gerando um script 1 com os passos realizados. Dessa forma, as ações gravadas podem ser facilmente re-executadas, permitindo assim a automação do teste. Além disso, o script gerado pode ser facilmente alterado, permitindo modificações nos testes gravados sem a necessidade de re-execução do software e nova captura [Neto et al. 2007]. Como exemplo desse tipo de ferramenta temos o Selenium-IDE [OpenQA b], que pode ser usado para automatizar testes funcionais em aplicações web. Neste capítulo serão apresentados alguns conceitos relacionados aos testes de softwares, em especial aos testes funcionais. Também serão apresentados os princípios gerais acerca dos testes e a utilização da ferramenta Selenium integrado com a linguagem de programação Java, a partir do uso do framework JUnit [Gamma and Beck ]. Além disso, será apresentada a ferramenta Bromine [OpenQA a], que foi criada para o gerenciamento de testes feitos com o Selenium. 2.2. Conceitos Básicos Antes de tudo, é preciso diferenciar três termos muito ligados aos testes de sofwtare: erro, defeito (bug) e falha. Um erro ocorre devido a uma ação humana que produz um resultado incorreto [IEEE 1990]; um defeito em um componente ou sistema pode fazer este falhar na execução na execução de alguma funcionalidade; e uma falha corresponde a uma discrepância entre o resultado ou comportamento atual (identificado durante a execução dos testes) e o comportamento ou resultado esperado (definido nas especificações ou requisitos)[spillner et al. 2006]. Ou seja, o ser humano está sujeito a cometer um erro (engano), que produz um defeito no código. Se um defeito no código for executado, o sistema falhará ao tentar fazer o que deveria (ou o que não deveria), causando possivelmente uma falha [Müller et al. 2007]. Também é importante diferenciar teste de depuração. Testes podem demonstrar falhas que são causadas por defeitos. Depuração é a tarefa de localizar e corrigir os defeitos [Spillner et al. 2006]. Assim, as responsabilidades de cada atividade são bem distintas: testadores testam e desenvolvedores depuram. Um caso de teste é uma especificação de como um software deve ser testado. Essa especificação inclui os dados de teste, ou seja, as entradas e as saídas esperadas, e as condições sob as quais o teste deve ocorrer. O projeto de casos de teste é um dos grandes desafios do processo de teste de software, e pode ser tão desafiador quanto o projeto do próprio software [Pressman 2006]. Como geralmente é impossível testar um programa exaustivamente, ou seja, testar todos os possíveis casos, o conjunto de casos de teste deve ser o mais abrangente possível levando em conta qual o sub-conjunto dos casos possíveis tem maior probabilidade de exibir falhas. Um procedimento de teste é uma especificação de uma seqüência de ações para execução de um determinado teste. Alguns exemplos são um conjunto de passos a serem seguidos em uma interface gráfica, um conjunto de funções a serem chamadas ou uma seqüência de requisições de página para um sistema web. Quanto a construção dos testes, existem basicamente dois métodos que podem ser 1 Conjunto de instruções para um programa.

utilizados [Filho 2003]: (i) método da caixa branca, que objetiva determinar defeitos na estrutura interna do produto, por meio do desenho de testes que exercitem suficientemente os possíveis caminhos de execução; e (ii) método da caixa preta, que tem por objetivo determinar se os requisitos foram total ou parcialmente satisfeitos pelo produto sem levar em conta como ocorre o processamento. 2.3. Princípios dos testes Burnstein [Burnstein 2003] define princípios, considerando o domínio da engenharia de sofwtare, como sendo leis, regras ou doutrinas relativas a softwares, a maneira como são construídos e como eles se comportam. Assim, sempre que for implementar testes, o testador deve ter em mente os princípios gerais dos testes [Spillner et al. 2006]: Princípio 1: Testes demonstram a presença de defeitos, não a ausência. O teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito. Princípio 2: Teste exaustivo é impossível. Testar todos os valores possíveis para todas as entradas, efetuando todas as formas de combinação e levando em conta diferentes precondições é geralmente impossível. Na prática, na maioria das vezes os softwares requerem números astronomicamente altos de casos de testes. Assim, em vez do teste exaustivo, o testador deve levar em conta os riscos e prioridades do sistema sob teste para focar os casos dos testes. Princípio 3: A atividade de teste deve começar o mais cedo possível. A atividade de teste deve começar o mais breve possível no ciclo de desenvolvimento do software e deve ser focado em objetivos definidos. Princípio 4: Defeitos tendem a estar agrupados. Geralmente a maioria dos defeitos são encontrados em algumas partes do software sob teste, ou seja, é muito pouco provável que os defeitos estejam uniformemente distribuídos pelo sofwtare. Princípio 5: O paradoxo do perticida. Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento. Para superar este paradoxo do pesticida, os casos de testes necessitam ser freqüentemente revisados e atualizados. Um conjunto de testes novo e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais falhas. Princípio 6: Testes dependem do contexto. Os testes devem ser adaptados aos riscos e ambientes inerentes da aplicação. Softwares de segurança crítica, como por exemplo o do computador de bordo de aeronaves, são testados diferentemente de softwares do comércio eletrônico Princípio 7: A ilusão da ausência de falhas. Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e necessidades dos usuários.

2.4. Testes funcionais de software O teste funcional é um teste para avaliar o quanto o comportamento observado do software está em conformidade com as especificações [Abran et al. 2004]. Isso significa que esse teste é baseado na análise da especificação de funcionalidades do software testado [Spillner et al. 2006]. Assim, o teste funcional é feito para verificar, por exemplo, se o cadastro de um novo usuário em um sítio Web funciona conforme o esperado. Para implementar os testes de forma eficiente e evitar a construção de casos de testes desnecessários é necessário utilizar técnicas específicas para projetar os casos de testes. A seguir serão apresentadas as duas principais técnicas usadas para o desenho de testes funcionais: a particação de equivalência e a análise do valor limite. A partição de equivalência é um método que divide o domínio de entrada em categorias de dados. Cada categoria agrupa dados que possuem as memas características e revelam uma classe de erros, permitindo assim, que casos de teste na mesma categoria sejam eliminados sem que se prejudique a cobertura dos testes [Filho 2003]. Em um programa de cadastro de um usuário, por exemplo, o mês do nascimento do usuário deve estar entre 1 e 12. Com isso, as possíveis classes de equivalência para essa entrada são: i) todos os valores inteiros menores que 1; ii) valores inteiros entre 1 e 12; e iii) valores inteiros maiores que 12. Para cada uma dessas classes, qualquer valor tem, potencialmente, a mesma capacidade de detectar erros, sendo dispensável a execução de vários testes para valores pertencentes à mesma classe de equivalência. Não é necessário, portanto, testar vários números negativos para verificar como a aplicação se comporta. Assim, um bom conjunto de teste para esse caso seria termos um valor menor que 1, um valor entre 1 e 12, e um valor maior que 12. O uso de outros valores seria desnecessário, uma vez que todos os valores em uma classe de equivalência deveriam ter o mesmo comportamento. Na Análise de Valor-Limite os casos de teste são escolhidos próximo ou nas fronteiras dos domínios de entrada, uma vez que boa parte das falhas tendem a se concentrar próximo a esses valores. O emprego dessa técnica deve ser complementar ao uso da partição de equivalência. Assim, em vez de selecionar um elemento aleatório de cada classe de equivalência, selecionam-se os casos de teste nas extremidades de cada classe [Filho 2003]. Para utilizar a técnica do Valor-Limite no exemplo anterior, devemos selecionar como valores representantes das partições, os valores que estão no limite entre uma classe e outra. Assim, para representar a partição de valores abaixo de 1 (um) utilizaríamos 0 (zero); para representar valores entre 1 e 12 utilizaríamos os números 1 e 12; e o número 13 seria o escolhido para representar valores na partição acima de 12. 2.5. Testes manuais versus Testes automatizados Um teste manual é aquele em que o testador executa o software manualmente com base nas especificações dos testes, as quais detalham os casos e procedimentos de testes. Os testes realizados dessa forma, em geral, são cansativos e de difícil repetição. Já os testes automatizados, são aqueles feitos com auxilio de alguma ferramenta apropriada. Eles exigem mais tempo para implementar os testes, mas provêem mais segurança na manutenção e permitem que os testes sejam executados a qualquer instante.

Antes de decidir em automatizar ou não os testes, é preciso analisar a aplicação testada e quais testes serão contruídos. A principal razão para automação dos testes é a necessidade de re-execução dos mesmos. Supondo, por exemplo, que um testador projetou centenas de testes e optou por executá-los manualmente. Se em algum momento da execução da bateria de testes 2 for descoberto uma falha, então os desenvolvedores deverão ser avisados. Além disso, dependendo da falha, a execução dos testes restantes deverá ser suspensa até que a mesma seja corrigida. Após a correção, como existem grandes chances de que outras partes do software sejam afetadas, o testador terá que executar todos os testes novamente e novas falhas podem ser encontradas repedindo o ciclo. Em um caso típico, existe a necessidade de se executar testes centenas e até milhares de vezes. Isso normalmente justifica a automação dos testes. A automação de um conjunto de testes geralmente demanda bem mais esforço que sua execução manual, mas quando automatizado, sua execução é bastante simples, se atendo a execução de um script ou o clique de alguns botões [Neto et al. 2007]. Assim, em situações como a descrita, automatizar os testes é a melhor maneira de economizar tempo e dinheiro. Contudo, nem sempre é vantajoso automatizar os testes. Existem situações em que realizar os testes manualmente é mais adequado. Se a interface de usuário da aplicação for mudar consideravelmente em um futuro próximo, por exemplo, então qualquer automação que for feita vai precisar ser refeita. Além disso, quando o software for simples e não houver tempo suficiente, ou se for improvável o reuso dos testes, então o teste manual continua sendo uma opção a ser considerada. 2.6. A ferramenta Selenium O Selenium é um conjunto de ferramentas OpenSource 3 que pode ser usada para criação de testes funcionais automatizados para aplicações Web. Uma das suas vantagens é a possibilidade de executar os testes em qualquer navegador com suporte a JavaScript 4. Além disso, as ferramentas que compõem o Selenium provêem um rico conjunto de funções específicas para a implementação de testes, tais como: open: abre uma página usando uma URL 5 que é fornecida como parâmetro; click/clickandwait: executa o clique em um botão, link ou imagem; verifytextpresent/asserttextpresent: verifica a presença de um texto em qualquer lugar da página; verifytext/asserttext: verifica se um texto aparece em um determinado local; waitforpagetoload : pausa uma execução do teste até que uma nova página seja carregada. Esse comando é chamado automaticamente pelos comandos com terminação AndWait ; 2 Conjunto de testes. 3 Software de código aberto. 4 Linguagem de criação de scripts desenvolvida pela Netscape em 1995. 5 Acrônimo para Uniform Resource Locator.

type: entra com um valor em um determinado campo da página; select: seleciona um elemento dentre uma lista de opções. Atualmente as principais ferramentas que compõem o Selenium são: Selenium- IDE, Selenium-RC e Selenium-GRID. O Selenium-IDE é um ambiente de desenvolvimento integrado para construção de casos de testes. Ele opera como plug-in do FireFox e provê interfaces amigáveis para o desenvolvimento e execução de suites de testes (conjunto de testes). O Selenium-IDE é uma ferramenta do tipo record-and-playback, ou seja, ela captura as ações executadas pelo testador e gera um script que permite a re-execução das ações feitas, automatizando assim, o teste. Sua instalação é simples: basta abrir o arquivo de instalação pelo Firefox. Apesar da facilidade de automação dos testes com o Selenium-IDE, algumas tarefas ainda não são simples para se executar com essa ferramenta. Ele não oferece, por exemplo, suporte para testes com interação ou que devem ser executados com base em uma determinadas condições. Para esses casos deve-se utilizar o Selenium RC (Remote- Control). Este possiblita uma maior flexibilidade ao testador, permitindo a construção de lógicas de teste mais complexas, a partir do uso de uma linguagem de programação. Para isso, ele provê uma API (Application Programming Interface) 6 e bibliotecas para cada uma das linguagens suportadas: HTML, Java, C#, Perl, PHP, Python, e Ruby. O Selenium-Grid permite distribuir os testes em múltiplas máquinas, reduzindo assim o tempo gasto na execução de uma suite de testes. Ele é ideal para escalonar grandes suites de testes ou suites de testes que devem ser executadas em múltiplos ambientes. O Selenium-Grid atua executando múltiplas instâncias do Selenium-RC em paralelo de forma transparente, fazendo com que os testes não precisem se preocupar com a infraestrutura utilizada. Como mencionado anteriormente, o conjunto de comandos do Selenium permite realizar uma série de ações necessárias para execução de testes em páginas web, tais como, entrar com valores em campos da página, selecionar itens de uma lista de opções, clicar em botões, clicar em links e realizar asserções com base nos resultados exibidos da página. Os comandos que realizam essas ações são divididas em três grupos: Actions: são comandos que geralmente causam uma mudança no estado da aplicação. Eles representam operações realizadas pelo usuário durante a execução de um sistema web, tais como o comando click que indica um clique em um determinado botão ou link. A maioria desses comandos pode conter o sufixo AndWait, o que indica que a ação fez uma chamada ao servidor e que o Selenium deve esperar a página carregar para executar o próximo passo. Accessors: examinam o estado da aplicação e armazenam o resultado em variáveis, como o comando storetitle que armazena o titulo da página em uma variável determinada por parâmetro. Vale notar que as variáveis criadas no Selenium podem ser acessadas de duas formas: ${nomedavariável} ou javascriptstored- Vars[ nomedavariável ]. 6 Um conjunto de rotinas e padrões estabelecidos para a utilização das suas funcionalidades.

Assertions: são como os Accessors, mas verificam se o estado da aplicação está conforme o esperado. Todas as asserções do Selenium podem ser usadas de três modos: assert, verify e waitfor. Para verificar a presença de um certo texto em um determinado local, por exemplo, pode-se usar o comando asserttext, verifytext ou waitfortext. Com o assert, se a verificação falhar o teste pára, enquanto que com o verify a ferramenta acusa a falha mas o teste continua executando. Já no modo waitfor, que é muito útil para testar aplicações com Ajax 7, o Selenium espera o texto aparecer para prosseguir a execução. Quanto aos parâmetros utilizados pelos comandos do Selenium, eles tipicamente são: i) uma identificação para algum elemento da página; ii) um texto para verificar se ele aparece na página ou para colocá-lo em algum campo da página. O número de parâmetros usados varia de acordo com o comando. Alguns exigem dois parâmetros, outros exigem somente um, e existem aqueles que não utilizam parâmetros. A Figura 2.1 ilustra um script de teste no formato HTML 8 feito com o Selenium- IDE. Nele pode-se perceber que no formato HTML cada comando é representado como uma linha de uma tabela. Cada linha é por sua vez dividida em três células representando o comando, o alvo e o valor, nessa ordem. O script ilustrado nesta figura, por exemplo, é formado por três comandos: o comando open com apenas um parâmetro, que representa a URL a ser acessada (alvo); o comando type, com dois parâmetros, o primeiro representando o nome do campo a ter uma informação digitada (alvo) e o segundo contendo o texto que será entrado no campo (valor); e o comando asserttextpresent, com um parâmetro, indicando o texto (alvo) a ser procurado na página. Figura 2.1. Script de teste do Selenium em HTML. Nas próximas sub-seções serão apresentados o Selenium-IDE e a criação de testes automatizados com o Selenium-RC usando a linguagem Java e o framework JUnit. A Figura 2.2 ilustra a página web que será utilizada como base para a maior parte dos scripts 7 Acrônimo de Asynchronous Javascript And XML. 8 Acrônimo para HyperText Markup Language.

de testes que serão apresentados no decorrer do capítulo. Essa página é responsável pelo cadastro de usuários e faz parte de um sistema de administração de um sítio que segue um modelo específico da UFPI. Figura 2.2. Página Web que servirá de base para os scripts de testes apresentados neste capítulo. 2.6.1. Uma breve introdução ao Selenium-IDE O Selenium-IDE, ilustrado na Figura 2.3, é um plug-in do FireFox que permite ao testador desenvolver e executar casos de testes sem a necessidade de conhecimentos em programação. Ele possui uma interface amigável e exibe o script de teste como uma tabela, se tornando assim, ideal para aprender a sintaxe e o funcionamento do Selenium. Figura 2.3. A ferramenta Selenium-IDE.

O menu Arquivo permite ao usuário criar, abrir ou salvar testes e suites de testes. O menu Editar contém as operações para editar os casos de testes e o menu Opções permite mudar as configurações da ferramenta, como por exemplo, o testador pode especificar o timeout (tempo limite que a ferramenta deve esperar por uma resposta) e qual linguagem (Html, Java, Ruby, etc.) será usada para salvar os casos de testes. Logo abaixo do menu principal, pode ser especificada a UrlBase, que será compartilhada por todos os testes, e também existem opções para controlar a execução dos casos de testes, como por exemplo, a velocidade e a forma de execução. A ferramenta contém um menu que é exibido após o clique ou seleção de um algum elemento da página atual. A Figura 2.4 exibe o resultado de um clique com o botão direito do mouse, sobre o texto Inserir Usuário, da página ilustrada na Figura 2.2. Nesse caso é exibido um menu mostrando alguns comandos do Selenium, a maioria com o parâmetro alvo pré-definido de acordo com o elemento selecionado (clicado). Figura 2.4. Menu exibido ao clicar em algum elemento da página. Começar a construir testes com o Selenium-IDE é muito simples: basta abrir a ferramenta por meio da aba Ferramentas do FireFox e o Selenium-IDE já começa a gravar as ações que forem feitas. A Figura 2.5 ilustra o funcionamento da ferramenta, que monta o script de teste à medida que ações vão sendo feitas pelo testador. Para encerrar a gravação basta clicar no botão situado nas proximidades no canto superior direito. O Selenium-IDE também provê flexibilidade ao construir os testes. Conforme exibido na Figura 2.6 o testador pode modificar o comando (digitando ou selecionando algum dentre os exibidos por meio do drop-down destacado na figura), o alvo, o valor, e

Figura 2.5. Gravando testes com o Selenium-IDE. no caso de dúvidas ele pode consultar a API do Selenium na aba Reference, na qual a sintaxe do comando selecionado é descrito. Além disso, a ferramenta permite inserir comentários, copiar/excluir/remover comandos, executar um único comando por vez, definir onde deve começar e parar a execução. Figura 2.6. A) Visualização da descrição dos comandos. B) Opções disponíveis para alterar o script de teste. A localização dos elementos na página web, necessária para utilizar muitos dos comandos do Selenium (como o type ), pode ser feita a partir de algum identificador,

do XPath 9 do elemento, ou a partir do DOM 10. No caso de um campo ou formulário, o elemento pode ser identificado por meio do seu nome ou identificador (id). Quando não há o atributo name ou id para o elemento desejado, este pode ser localizado usando-se xpath que inicia com //. A expressão //form[1], por exemplo, refere-se ao segundo formulário da página (pois a identificação inicia do zero). Por fim, os elementos da página também podem ser localizados a partir de expressões do tipo document.forms[0].elements[3], a qual se refere ao quarto elemento presente no primeiro formulário da página. O Selenium-IDE também fornece meios para tornar os testes mais fáceis de entender e manter. Supondo, por exemplo, que foram implementados 100 casos de testes, e que em todos eles é necessário fazer o login para acessar o sistema, então, se para logar for preciso preencher os campos login e senha, todos os casos de testes irão se referir a esses dois elementos (identificados na página por login e senha ). Agora, supondo que por algum motivo, como o uso de algum framework, o nome dos campos tenha que ser alterado para form:login e form:senha. Nesse caso, todas as referências aos campos login e senha devem ser alterados para form:login e form:senha, respectivamente. Fazer essa alteração manualmente certamente exigiria muito tempo e toda vez que a referência a um elemento da página fosse alterada todos os testes deveriam ser atualizados. Agora supondo que um testador que não tenha implementado os 100 testes, mencionados acima, tenha que entendê-los para saber quais funcionalidade foram testadas, então, dependendo de como for feita a referência aos elementos da página, ele poderia perder muito tempo tentanto identificá-los. É bom lembrar que nem sempre será possível se referir a um elemento usando algum termo que permita a sua fácil identificação. Algumas vezes (e não são poucas) os elementos da página testada deverão ser localizados pelo Selenium a partir de expressões XPath do tipo //table[@width=100]//tr[3]/td[2]//a, o que dificulta a leitura do teste. Assim, para tornar os testes mais legíveis e fáceis de atualizar, o testador pode usar mapeamentos utilizando JSON 11 entre nomes e os elementos da página sob teste. Isso é possível a partir do UI-Element que é um recurso suportado tanto pelo Selenium- IDE quanto pelo Selenium-RC. A Figura 2.7 ilustra à esquerda um teste feito para a página de cadastro de usuários (ilustrado na Figura 2.2) feito no Selenium-IDE sem utilizar UI-Element e à direita o mesmo teste utilizando o UI-Element. Com base nela, podemos observar que utilizando o mapeamento o teste fica muito mais legível e fácil de entender. Com o script da parte B da figura é fácil perceber que o teste é feito sobre a página de cadastro de usuário, que após a preenchimento dos campos foi pressionado o botão Cadastrar e que o resultado esperado é uma mensagem com o texto Usuário Cadastrado. Outra vantagem da utilização do UI-Element é a fácil visualização da descrição dos elementos. Esta é especificada a partir do mapeamento e é visível na aba Reference após clicar em algum comando que utilize um elemento previamente mapeado. 9 Acrônimo de XML Path Language. 10 Acrônimo de Document Object Model. 11 Acrônimo de JavaScript Object Notation

Figura 2.7. A) Exemplo de teste sem UI-Element. B) Mesmo teste da esquerda com UI-Element. Essas descrições tornam o teste ainda mais claro, permitindo que o mesmo seja rapidamente compreendido. A Figura 2.8 ilustra a descrição associada ao elemento cadastrousuario::mensagemexibida, localizado no terceiro div da página (pois seu locator é //div[2] ). Para construir o mapeamento entre nomes e elementos basta usar um editor de textos e criar um arquivo no formato.js com mapeamento feito usando os comandos reconhecidos pelo UI-Element. Em seguida, esse arquivo deve ser submetido como extensão do Selenium Core 12 a partir do menu Opções do Selenium-IDE. Os comandos que podem ser utilizados para criar o mapeamento através do UI- Element são: addpageset: para adicionar uma página ou conjunto de páginas que contém os elementos que serão usados no teste. Para cada conjunto deve ser especificado o nome e a descrição. Também existem outros atributos que podem ser definidos, como por exemplo, pode-se especificar uma expressão regular para indicar o path das páginas que pertencem ao grupo em questão a partir do atributo pathregex. addelement: para adicionar os elementos (campos, botões, links, imagens, dentre outros) das páginas. Deve ser definido o nome, a descrição e a localização do elemento, a qual é definida no parâmetro locator. A primeira linha do mapeamento deve seguir a estrutura var nomedavariavel = new UIMap(). Mais comandos podem ser encontrados através do menu Ajuda do 12 Componente do Selenium responsável por executar os comandos do Selenium no browser

Figura 2.8. Visualização da descrição dos campos por meio do UI-Element. Selenium-IDE. A Figura 2.9 ilustra o mapeamento que foi utilizado no teste exibido na parte B da Figura 2.7. Observe que se a localização (ou forma de identificação) dos elementos for alterada, basta atualizar o atributo locator para que todos os testes estejam atualizados. Se o endereço da página de inserção de usuário for alterado, por exemplo, então basta atualizar o atributo pathregex do conjunto de página (Pageset) nomeado de cadastrousuario e o atributo locator do elemento linkusuario para que todos os testes da página de cadastro de usuário sejam atualizados. Por fim, muitas vezes existem sequências de comandos que são executadas mais de uma vez em um mesmo teste. Também existem sequências de comando que são executadas em mais de teste, usando os mesmos parâmetros ou não, que podem pertencer ou não a uma mesma suite de testes. Assim, é interessante usar algum meio para agrupar tais sequências, possibilitando a invocação de toda a sequência com um único comando. Com Selenium-RC, o agrupamento de comandos pode ser facilmente feito a partir de blocos. Já para o Selenium-IDE é preciso usar o Rollup. A partir da definição das regras de agrupamento (Rollup rules), o testador pode reunir comandos em grupos possibilitando que eles sejam invocados com o comando rollup. A parte A da Figura 2.10 ilustra a definição de regras de agrupamento para reunir uma sequência de comandos em grupo identificado por login, que efetua o login em uma página web. A parte B da Figura 2.10 ilustra um teste que utiliza o comando rollup para efetuar a sequência de comandos do grupo identificado por login.

Figura 2.9. Mapeamento feito para os elementos da página exibida na Figura 2.2. A criação dos arquivos com os Rollup rules é feita da mesma forma que a definição do mapeamento descrito acima, ou seja, a partir da criação de um arquivo no formato.js e da submissão desse arquivo como extensão do Selenium Core a partir do menu Opções do Selenium-IDE. Porém, nesse caso a primeira linha deve seguir a estrutura var nomedavariavel = new RollupManager() e o único comando disponível é comando addrollup, usado para adicionar uma nova regra. Existem vários atributos que podem ser definidos. No script ilustrado, o principal atributo é o getexpandedcommands o qual especifica quais serão os comandos a serem executados. 2.6.2. Escrevendo testes com o Selenium RC e a linguagem Java Como mencionado anteriormente, com o Selenium-RC o testador pode construir testes utilizando todo o poder fornecido pela linguagem de programação utilizada. Ele pode, por exemplo, trabalhar com iterações, expressões condicionais, ler e escrever em arquivos, além de poder tratar dinamicamente os resultados dos testes.

Figura 2.10. A) Definição das Rollup rules. B) Teste usando o comando rollup. O Selenium-RC é constituído de dois componentes principais: Selenium Server, ponte para o navegador, a partir do qual os comandos acionados são transmitidos e executados no navegador selecionado; Bibliotecas, conjunto de instruções que são acionadas e que causam uma comunicação com o Selenium Server. Assim, para executar testes feitos com o Selenium e alguma linguagem de programação é preciso iniciar o servidor ( selenim-server.jar ) e para que os comandos do Selenium sejam reconhecidos é necessário acrescentar a biblioteca referente a esta linguagem ao projeto que contém o teste. A maneira mais fácil de iniciar a criação de testes funcionais automatizados utilizando Selenium e Java é criando primeiro um script (com a estrutura geral do teste) utilizando o Selenium-IDE. A Figura 2.11 exibe um script de teste no formato HTML feito com o Selenium-IDE para o cadastro de usuários da página exibida na Figura 2.2. Observe que as cinco primeiras linhas do script exibido na figura - da abertura da página /modelo/admin/index.php até a verificação do texto Sair - estão associadas ao login no sistema. Isso porque para cadastrar um usuário é preciso fazer antes o login no sistema. Logo, as ações necessárias para efetuar o login também devem ser inseridas no script de teste para que ao executar a sequência de comandos do teste se tenha acesso a página de cadastro de usuário. É bom lembrar que o Selenium simula um usuário acessando a aplicação, e como o usuário deve logar para ter acesso as funções administrativas do sistema, o teste com o Selenium também deve realizar os procedimentos necessários para efetuar o login.

Figura 2.11. Script de teste feito com o Selenium-IDE. O próximo passo é converter script do formato HTML para Java, ou seja, converter os comandos do script nas funções disponíveis na API para a linguagem Java. Isso é feito a partir do menu Opções > Formato > Java (JUnit) SeleniumRC. Caso o testador queira executar os testes no TesteNG ele deve usar a opção Opções > Formato > Java (TestNG) SeleniumRC. O resultado da exportação, para o framework JUnit, do script ilustrado na Figura 2.11 é exibido na Figura 2.12. Figura 2.12. Script de teste da Figura 2.11 exportado para Java (JUnit). Após termos o arquivo Java, podemos utilizá-lo a partir do conjunto Eclipse+JUnit para concluir a automação dos testes. Como o teste utiliza a API do Selenium para o Java é preciso adicionar a biblioteca da API Java (selenium-java-client-driver.jar) ao projeto

com o teste para que os comandos sejam reconhecidos, caso contrário, eles ficarão em destaque conforme exibido na Figura 2.13. Esse destaque indica que o comando não foi reconhecido, gerando assim erro de compilação no teste. Figura 2.13. Visualização do teste exportado no Eclipse. O passo seguinte consiste na construção dos procedimentos de testes parametrizados. Para isso basta criar funções específicas reunindo os comandos de acordo com as ações deles e substituir os valores utilizados por variáveis. Assim, para o script da Figura 2.13, podem ser criados duas funções: login (que efetua o login na página) e cadastrousuario (que cadastra um usuário no sistema). Vale lembrar que é preciso instanciar uma variável do tipo Selenium para ter acesso as suas funções. Para que a instanciação do Selenium seja feita somente na classe com os casos de testes, podemos passar a variável Selenium por parâmetro. Com isso, nossa classe com os procedimentos de teste fica como exibido na Figura 2.14. Em seguida, deve-se concluir a implementação dos procedimentos de testes, de forma que eles também sejam utilizados para verificar se as operações vão falhar quando deveriam. Se no login, por exemplo, os campos login e senha não forem corretamente preenchidos aparecerá na tela do sistema considerado uma mensagem de alerta (alert) indicando o erro. Assim, podemos concluir a implementação da função login acrescentando mais uma variável que armazenará o erro (mensagem do alerta) esperado. Considerando que a mesma situação ocorre durante o cadastro de um usuário, teremos os procedimentos escritos conforme a Figura 2.15. Por fim, resta implementar os casos de teste utilizando para isso os procedimentos de testes que foram implementados e as especificações de testes 13. Na Figura 2.16 apresentamos alguns casos de teste criados para verificar o login e o cadastro de usuários do sistema. 13 Documentos que descrevem os casos e procedimentos de testes.

Figura 2.14. Classe com o procedimento de teste parametrizado. Os testes criados com o Selenium são testes que utilizam o JUnit, de forma similar aos testes de unidade. Sua execução acontece da mesma forma que os testes de unidade, clicando com o botão direito do mouse em cima da classe e solicitando sua execução via JUnit. No entanto, existe uma diferença: para que o teste execute, é necessário que exista uma instância do Selenium Server executando na mesma máquina que contém os testes que serão executados. Assim, antes de executar os testes é preciso executar o arquivo selenium-server.jar 14. Sua execução pode ser feita via comando java -jar seleniumserver.jar". A Figura 2.17 exibe o resultado da execução dos testes apresentados neste capítulo. O lado A da figura apresenta a primeira execução dos testes, e no lado B a reexecução dos mesmos. Observe que no lado A da figura, a barra de execução ficou verde, indicando que nenhuma falha foi detectada, ou seja, o teste passou. Enquanto que no lado B, a barra de execução ficou vermelha pois o execução do último teste encontrou uma falha. Isso porque no último teste, no qual é feito o cadastro de um novo usuário, o resultado esperado é a mensagem Usuário Cadastrado. Na primeira execução da suite de testes, eles passaram porque não havia o usuário Usuário de teste 15 cadastrado no sistema. Contudo, com a re-execução da mesma suite de teste, sem restaurar o banco de dados para o estado original, o sistema não permitiu o cadastro do mesmo usuário, não resultando, portanto, no resultado esperado pelo teste. 14 Servidor do Selenium, que pode ser baixado no site do Selenium. 15 Nome do usuário contido no script de teste.

Figura 2.15. Classe com o procedimento de teste completo. Vale salientar que também é possível implementar e executar casos de teste escritos com o Selenium utilizando a linguagem Java a partir do framework TestNG. Este por sua vez ofecere características próprias que podem ser utilizadas para facilitar a implementação dos testes. A escolha do framework a ser utilizado deve ser baseado nos conhecimentos da equipe de teste e nos recursos que tais ferramentas oferecem. Assim como no Selenium-IDE, o mapeamento feito com o UI-Element também pode ser usado com o Selenium-RC, porém neste só é possível adicionar um arquivo de mapeamento e ele deve ser chamado de user-extensions.js e deve estar no mesmo diretório do selenium-server.jar. Com isso, basta executar o servidor com o comando java -jar selenium-server.jar -userextensions user-extensions.js para que o mapeamento seja reconhecido e dessa forma o procedimento de cadastro de usuário, por exemplo, pode ser escrito conforme exibido na Figura 2.18.