As ferramentas analisadas neste capítulo são na sua grande maioria, aplicações que funcionam com recurso à técnica de Captura e Repetição. Embora nem todas ofereçam uma interface gráfica para Captura das acções do utilizador, todas são capazes de ler um ficheiro de teste e simular um conjunto de acções, utilizando e manipulando um Web Browser.
Destas ferramentas, pretendia-se escolher uma para integrar a Plataforma a desenvolver. Da seleccionada esperava-se o cumprimento de alguns requisitos. Estes advêm simultaneamente dos enunciados no documento que deu origem a este projecto e dos encontrados durante a realização do estudo. Os requisitos são:
Utilitário de captura das acções do utilizador: isto é, um Integrated Development
Environment (IDE), para permitir que o ficheiro seja gerado automaticamente sempre
que possível através da interacção de um utilizador, podendo ainda ser manipulado por interface durante a sua criação;
Ficheiro de teste gerado numa linguagem convencional: embora este não seja um requisito obrigatório, seria preferível que assim fosse, para que se possam usar APIs conhecidas e também, para que a sua curva de aprendizagem seja menos acentuada;
Metodologias e Ferramentas de Teste Aplicações Web
24
Suporte a múltiplos Browsers: os ficheiros devem poder ser executáveis, pelo menos, nos seguintes Web Browsers: Microsoft Internet Explorer, Mozzila Firefox, Opera,
Safari e Google Chrome;
Capacidade de interagir directamente com um servidor proxy: como praticamente todas as ferramentas utilizadas funcionam como um servidor proxy, apenas cumprindo este requisito, a ferramenta a utilizar permite simultaneamente que se efectuem os testes num Browser, que já estaria a utilizar um servidor proxy. Um Browser para cada protocolo pode apenas ter definido um e um só servidor proxy. Assim, evitar-se-iam configurações adicionais ao nível da rede, embora estas possam existir, mas o que se pretende é retirar esta necessidade. O cumprimento deste requisito, facilita uma das operações propostas no capítulo 3, Concepção da Solução;
Ser executável em batch mode: isto é, após a criação de um ou vários ficheiros de teste, estes devem poder ser executados pela ferramenta, sem intervenção humana. Esta apenas tem de ser invocada, preferencialmente numa linha de comandos sem recurso a uma interface gráfica. Na invocação devem ser indicando apenas os caminhos (paths) para os ficheiros, efectuando a ferramenta todos os testes, colhendo os resultados, reportando-os no final;
Deverá ser escrita em código aberto e ser gratuita: para que possa ser modificadacaso necessário e para que não traga custos adicionais. Para este ponto, foi tido em conta, o número de utilizadores, os fóruns e a documentação de apoio ao desenvolvedor.
A tabela 1 mostra uma comparação das várias ferramentas relativamente aos requisitos enunciados. De notar, que foi analisado também o suporte a execução em multi thread. Caso exista esse suporte, a ferramenta poderá ser usada para testes de Desempenho, Carga e Stress (embora não seja de todo o objectivo principal destas ferramentas) ou realizar vários testes em simultâneo, diminuindo o tempo de execução. Convém também referir que, a linguagem em que os ficheiros de teste são gerados, e as potencialidades de manipulação que oferecem, foram tidas em conta porque disponibilizam a possibilidade de realizar alguns testes do tipo Fuzz, com maior abrangência e personalização.
Observemos a tabela 1, para análise das ferramentas. Existem algumas informações que não foram possíveis de apurar. Quer isto dizer que, os respectivos dados não estavam presentes na página Web ou na documentação disponibilizada ou ainda, que não se conseguiu descobrir essa funcionalidade dentro do intervalo de tempo estipulado para análise da respectiva
Metodologias e Ferramentas de Teste Aplicações Web
25
ferramenta. Dadas as restrições de tempo e a quantidade de ferramentas disponíveis era absolutamente necessário definir um tempo máximo de experimentação por ferramenta.
A ferramenta RadView foi imediatamente eliminada dado não ser gratuita. A BadBoy, impõe restrições ao nível de compra de uma licença, se for utilizada em organizações com fins lucrativos, pelo que foi também eliminada. A Doit, seguiu o mesmo caminho, visto a sua página oficial não oferecer informação sobre o seu funcionamento, e apesar de ser referida em fóruns de utilizadores, não se conseguiu efectuar a instalação. Pela experiência de utilização e a dificuldade a configurar o modo batch, levou à eliminação da WebTest.
Pela análise do quadro verifica-se que as ferramentas que correspondem suficientemente aos requisitos são o Sahi, o Selenium, o Watir e o Windmill.
No entanto, cada uma destas ferramentas possui uma desvantagem. O Watir e o
Windmill não possuem suporte a servidor proxy, logo, são candidatas mais propícias a serem
imediatamente descartadas, visto que, esse incumprimento compromete a automatização da mistura de Captura e Repetição com teste Fuzz (na forma descrita pela figura 2).
O Selenium possibilita executar os testes em todos os Browsers mas permite apenas que se criem usando o Mozzila Firefox. Isto advém do facto de o IDE do Selenium ser um pluggin desse Browser e não uma aplicação Javascript genérica, como acontece nos seus concorrentes.
O Sahi não apresenta falhas, no entanto gera os ficheiros numa linguagem parecida com
Python, que é no entanto, uma linguagem desenvolvida pelos criadores do Sahi. Isto pode levar
a problemas na escrita e manipulação de ficheiros. Neste ponto, o Selenium é extremamente versátil uma vez que, a geração é feita numa multiplicidade de linguagens.
Pesando as duas desvantagens, o Selenium fica à frente uma vez que, o objectivo do projecto é a execução dos testes em vários Browsers e neste ponto, a ferramenta não apresenta qualquer limitação [11, 12, 13, 14, 15, 16, 17,18].
Metodologias e Ferramentas de Teste Aplicações Web
26
Tabela 1 - Comparativo de ferramentas Captura e Repetição
Browsers (execução de teste) Browsers (criação de teste) Sistemas Operativos Automático Ficheiros de teste Fonte Proxy Externa Código aberto Gratuito Multi Thread Windmill Internet Explorer; Firefox; Opera; Safari;
Chrome
Internet Explorer; Firefox; Opera; Safari; Chrome
Windows; Linux; MacOS
Sim Python,
Javascript Python
Não (tem de ser
codificado) Sim Sim Não
Sahi Internet Explorer;
Firefox Internet Explorer; Firefox
Windows; Linux;
MacOS Sim
Linguagem
própria Java Sim Sim Sim Sim
Watir Internet Explorer;
Firefox; Safari; Chrome Existem IDEs compatíveis
Windows; Linux;
MacOS Sim Ruby BSD * Sim Sim *
Selenium
Internet Explorer; Firefox; Opera; Safari;
Chrome
Firefox (código gerado é
independente do Browser) Windows; Linux; MacOS Sim Javascript, Ruby, Python, C#, Java
Várias Sim Sim Sim Sim
Webtest Executou em Internet
Explorer; Firefox;* Firefox
Windows; Linux;
MacOS Sim Groovy, XML Java Sim Sim Sim Não
Badboy Independente do
Browser Independente do Browser
Trial disponível:
Windows Sim Javascript * Sim Não Não Sim
Doit * * * * * * * Sim Sim *
RadView
Internet Explorer; Firefox; Opera; Safari;
Chrome
Internet Explorer; Firefox; Opera; Safari; Chrome
Windows; Linux;
Solaris Sim * * * Não Não Sim
27
Por questões de espaço e tempo não é possível apresentar em detalhe todas as ferramentas. Assim, apresenta-se agora uma descrição detalhada da ferramenta seleccionada. Notar que, a descrição do Selenium é mais extensiva do que a das restantes ferramentas (ferramenta seleccionada de Fuzz e ferramenta seccionada para teste não funcional), não só pelas suas características mas também, dado o especial interesse da Auditmark no controlo dos
Web Browsers
O Selenium divide-se em três elementos: Selenium IDE, Selenium Remote Control e
Client Libarires.
Selenium IDE
O Selenium Integrated Development Environment (ou simplesmente Selenium IDE) é uma interface para captura de acções do utilizador. Utilizando a funcionalidade de gravação à medida que o utilizador faz uso do Browser, todas as suas acções são capturadas e gravadas num ficheiro. A função play permite que se execute um ficheiro de teste simulando assim um utilizador.
Os ficheiros gerados podem ser exportados em qualquer uma das linguagens suportadas pelo Selenium (ver descrição mais abaixo) e podem ser alterados programaticamente antes de serem lidos e executados. A interface do IDE também permite inserção, modificação e remoção de asserções e outros elementos constituintes de um teste (como condições ou acções que requeiram algum comportamento algorítmico).
Finalmente, o IDE permite que o conjunto definido de operações seja exportado com o formato esperado pelo TestNG, a ferramenta de geração de relatórios escolhida.
Arquitectura Selenium Remote Control (RC)
O Selenium Remote Control (comummente referido como Selenium RC) é o elemento desta ferramenta que permite executar um teste. Está dividido em duas partes principais: o par
Selenium Server e Selenium Core; bibliotecas de cliente (ou Client Libraries).
Selenium Core e Selenium Server
É uma Framework DHTML (Dynamic HTML). DHMTL é definido não como sendo uma linguagem, mas sim, como a combinação de HTML, Javascript, HTML DOM e CSS e é uma forma de controlar as páginas Web de forma dinâmica e interactiva após o seu descarregamento. O Selenium Core é injectado no Browser quando este é lançado em execução e é capaz de receber comandos enviados pelo Selenium Server.
Metodologias e Ferramentas de Teste Aplicações Web
28
Este módulo é responsável por iniciar a execução do Web Browser e por realizar as funções de servidor proxy, actuando sobre os pedidos e respostas HTTP. Recebe as instruções do programa executor do teste (denominado Client Driver e implementado com base nas Client
Libraries) via um protocolo denominado Selenese. Estas informações são então enviadas ao Selenium Core para que actue sobre o Browser.
Client libraries
São na verdade um conjunto de APIs (uma por cada linguagem suportada) que disponibilizam funções com vista a executar as diversas acções do Browser, como por exemplo, preencher um campo com um determinado texto ou efectuar um clique do rato numa qualquer hiperligação. A forma como estas são implementadas, tornam o ficheiro de teste independente do Browser onde será executado.
O Selenium permite que os testes sejam definidos nas seguintes linguagens: Ruby, C#,
Java, Perl, Python e PHP.
De todas estas, será utilizado apenas o Java. Esta decisão é tomada essencialmente porque se trata de uma linguagem extremamente utilizada, para a qual existem inúmeras APIs sendo ainda amplamente documentada. Além disso, permite a utilização do Ant (descrição e justificação de escolha presente mais a frente neste capítulo) que desempenhará um papel importante na automatização do processo de teste.
Uma vez apresentados os componentes do Selenium RC, será apresentado agora, o modo de funcionamento de um teste. Antes de se prosseguir para essa descrição, será necessário introduzir dois conceitos: "The same origin policy" e "Proxy injection".
The same origin policy
É uma estratégia de segurança que define que um código Javascript qualquer, descarregado de uma aplicação Web, alojada, por exemplo, em www.exemplo_um.com, não pode efectuar pedidos (ou acções sobre conteúdo) a outra aplicação Web com domínio diferente, por exemplo, www.exemplo_dois.com. Se tal fosse possível, tendo um utilizador, vários separadores (ou várias instâncias de um mesmo Browser) em execução, seria possível que uma aplicação Javascript (a executar num determinado separador) fizesse a captura de dados privados (por exemplo, de uma conta bancária) de uma outra página a executar numa separador diferente e os enviasse para terceiros com intenções maliciosas. Chama-se a esta acção Cross-
Metodologias e Ferramentas de Teste Aplicações Web
29 Proxy injection
Para evitar os problemas derivados da questão anteriormente descrita, o Selenium usa a seguinte técnica: um servidor proxy situa-se entre o Browser que envia os pedidos e a aplicação em teste. O proxy mascara o URL da aplicação embutindo ainda o Selenium Core, entregando a resposta ao Browser como se ambos tivessem a mesma origem.
A figura 3 apresenta a estrutura da execução de um teste.
Selenium Core + Browser
Client Driver Selenium RC
Aplicação Web em teste 1 2 3 5 6 7 4
Figura 3- Arquitectura de um teste com Selenium
Na figura 3, é possível ver que existem quatro elementos envolvidos no teste: A - Client Driver (processo condutor do teste);
B - Selenium RC:
C - Selenium Core e o Browser que este comanda (n instâncias); D - Aplicação Web destinatária do teste.
O teste processa-se então nos seguintes passos:
1. O Client Driver estabelece uma ligação ao Selenium RC;
2. O Selenium RC lança um Browser em execução embutindo-lhe o Selenium Core e descarregando num outro separador, ou num novo Browser, a página inicial da aplicação a testar (podem ser lançados n Browsers em simultâneo, sendo as limitações impostas por questões de configuração da máquina e largura de banda disponível); 3. Via o protocolo Selenese, o Client Driver envia um comando ao Selenium Server que
despoleta uma acção no Selenium Core (usando XSS, o Core manipula a página da aplicação a testar);
Metodologias e Ferramentas de Teste Aplicações Web
30
4. O passo anterior resulta num pedido HTTP do Browser, a um outro domínio, que o faz na verdade ao Selenium Server, que actua como proxy (esta técnica permite a utilização de XSS, uma vez que para o Browser, todas as páginas pertencem ao mesmo domínio); 5. O Selenium Server pede uma página à aplicação Web em teste;
6. A aplicação Web responde ao Selenium Server; 7. O Server entrega a página ao Browser.
Recolha dos resultados do teste
O Selenium RC não dispõe de um mecanismo específico de recolha e apresentação dos resultados dos testes. Aquilo que é pressuposto é que seja o próprio utilizador a definir a forma de apresentação dos resultados. Esta situação facilitou no entanto, a recolha de resultados de teste com erros de execução em teste de Fuzz. Para este projecto foi seleccionado o TestNG, cuja justificação se encontra um pouco mais à frente neste mesmo capítulo.
O anexo A (secção A.2) apresenta uma descrição de algumas das potencialidades mais relevantes [16].
Finalmente o Selenium apresenta ainda outra característica útil para este projecto. Além de suportar todos os Browsers requisitados em diferentes ambientes, possui um modo de invocação de drivers standard que permite controlar outros Browsers. O anexo A (secção A.1) mostra os resultados de uma série de experiências feitas ao Selenium. A conclusão: é possível controlar todos os Browsers especificados nos requisitos em pelo menos uma configuração possível (Sistema Operativo – versão do Browser). É ainda possível controlar outros Browsers (por exemplo, o Konqueror) além dos especificados. Finalmente, no mesmo anexo (secção A.3), está presente uma análise que permite perceber que o Selenium é uma solução que irá manter-se actualizada a longo prazo[16, 19].