plataforma de teste a aplicações web suportando múltiplos ... · teste de software que pudessem...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Plataforma de teste a aplicações Web

suportando múltiplos Web-Browsers

Paulo Luciano Simões de Carvalho

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Professora Ana Paiva Pimenta (Professora Auxiliar)

Julho de 2010

Paulo Luciano Simões de Carvalho, 2010

Plataforma de teste a aplicações Web suportando

múltiplos Web-Browsers


Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: Raul Fernando de Almeida Moreira Vidal (Professor Associado)

Vogal Externo: José Francisco Creissac Freitas Campos (Professor Auxiliar)

Orientador: Ana Cristina Ramada Paiva Pimenta (Professora Auxiliar)

____________________________________________________

22 de Julho de 2010

i

Resumo

Este documento é referente a um projecto de Dissertação em que a fase de investigação

ocorreu em ambiente académico e a fase de implementação foi desenvolvida em ambiente

empresarial. Ao nível académico, trata-se da Faculdade de Engenharia da Universidade do

Porto, e em termos empresariais, a instituição de acolhimento foi a Auditmark, uma empresa de

serviços de auditoria a aplicações Web na área de negócio da publicidade.

O objectivo deste trabalho consistiu no desenvolvimento de uma Plataforma de teste a

aplicações Web, que sendo genérica, deve permitir automatizar o processo inerente ao teste,

tanto quanto possível.

A metodologia de desenvolvimento consistiu num levantamento inicial de técnicas de

teste de software que pudessem ser aplicadas a sistemas Web, seguido de um estudo teórico e

experimental de um conjunto de ferramentas cujas funcionalidades permitissem a aplicação das

técnicas estudadas. Seguiu-se uma fase de implementação, onde todas as ferramentas foram

integradas de modo a possibilitar que todo o processo de teste e armazenamento de resultados

ficasse totalmente automatizado. Este módulo pode ser instalado em diversas máquinas. As

várias instâncias podem ser controladas remotamente por uma única interface Web.

Foram realizadas várias experiências, onde foi utilizado como sistema em teste, o Front

End do Auditservice, o sistema da Auditmark. Os resultados obtidos foram validados numa

primeira fase, de acordo com dados já conhecidos pela empresa e numa segunda fase, por uma

análise comparativa entre o valor obtido e o valor esperado, atendendo aos princípios teóricos

da área da Informática e Computação.

O projecto terminou com o cumprimento de todos os objectivos iniciais, tendo sido

ainda possível definir e cumprir requisitos adicionais.

iii

Abstract

We live in times where the demand for software quality is in a high level of exigency.

Most projects of relevant size require a testing phase, in which, automated procedures arise as a

crucial method to perform all the needed testing activities within defined project time.

With the current migration of many systems to the Web, quality issues, especially in

terms of performance and security, must be considered in a much more careful way.

The objective of this project is to go one step further in answering these questions, by

the conception of an automated Web Application Testing Framework.

This project started with a theoretical study about software testing techniques and

methodologies. In the second phase, a large group of testing tools was analyzed in order to find

those that could be of use, to integrate the Framework. Three groups where established: Capture

and Replay tools; Fuzz Testing Tools; Performance, Load and Stress testing tools;

The work progressed to the implementation of an application that was able to integrate

and control, in a fully automated way, the previously selected tools. Also, a Web interface was

built, in order to control many instances of the testing Framework remotely.

In this document, a small case study it is also present, where it is explained and

exemplified how the Framework can be used to test Web applications.

v

Agradecimentos

A secção de agradecimentos deste documento não poderia em caso algum começar sem

ser pelos agradecimentos à família, Avós, Mãe e Pai, pela força e apoio, pela confiança no

sucesso, mesmo em tempos de adversidade.

No mesmo plano, coloco a Mestre Maria de Fátima Dias, minha namorada, que me

acompanhou desde o início da minha formação até este final e que sempre prestou ajuda e

apoio. No mesmo plano ainda, um agradecimento muito especial ao Professor Rui Moreira, um

Matemático, um Professor, um amigo, um exemplo a seguir.

Agradecimentos à Professora Ana Cristina Ramada Paiva Pimenta pela forma como

orientou este projecto, e ao Mestre Pedro Fortuna, pela possibilidade de entrar no mundo

empresarial através da sua empresa e pelo apoio prestado a este projecto.

Ao amigo Pedro Miguel Antunes Silva, uma referência muito especial, pela sua ajuda e

ensinamentos no âmbito das tecnologias de programação.

Aos restantes amigos, aos colegas de curso, aos colegas de estágio, uma menção devida,

pelo vosso apoio para o sucesso deste projecto.


vii

Índice

1.Introdução 1

1.1 Enquadramento e Motivação ............................................................................................... 1

1.2 Especificação do Problema ............................................................................................... 10

1.3 Objectivos .......................................................................................................................... 11

1.4 Estrutura do Documento .................................................................................................... 14

2.Metodologias e Ferramentas de Teste a Aplicações Web 15

2.1 Tipos de teste de software ................................................................................................. 15

2.1.1 Testes funcionais ......................................................................................................... 15

2.1.2 Testes não funcionais .................................................................................................. 20

2.2 Ferramentas de simulação do comportamento de um Browser ......................................... 23

2.3 Ferramentas de Intercepção de Tráfego HTTP e Teste Fuzz ............................................. 30

2.4 Ferramentas de teste de Desempenho, Carga e Stress ....................................................... 33

2.5 Tecnologias adicionais ...................................................................................................... 35

2.5.1Integração na Plataforma.............................................................................................. 35

2.5.2 Desenvolvimento Web ................................................................................................ 36

3.Concepção da Solução 41

3.1 Arquitectura e funcionamento do Módulo de Execução de Testes ................................... 41

3.2 Operações de teste suportadas ........................................................................................... 44

3.3 Arquitectura e funcionamento do Centro de Controlo Remoto ......................................... 47

3.4 Rede de Execução de Testes ............................................................................................. 55

Conteúdo

viii

3.5 Porquê utilizar esta Plataforma……………………………………………….…………….56

4.Caso de Estudo 59

4.1 Sistema em teste ................................................................................................................ 59

4.1.1 Auditservice ................................................................................................................. 59

4.1.2 Javascript Interaction Code ........................................................................................ 61

4.2 Plano de testes ................................................................................................................... 63

4.3 Resultados e Discussão ..................................................................................................... 67

4.4 Conclusão………………………………………………………………………………...82

5.Conclusão e Trabalho Futuro 83

5.1 Contribuições do trabalho…………………………………………………………………85

5.2 Trabalho futuro……………………………………………………………………………86

Referências 87

A Informação adicional sobre o Selenium 91

A.1 Análise do suporte a múltiplos Browsers ......................................................................... 91

A.2 Operações de teste suportadas .......................................................................................... 96

A.3 Selenium e WebDriver ...................................................................................................... 99

B Informação adicional sobre o Webscarab 101

B.1 – Operações definíveis em BeanShell no Webscarab ..................................................... 101

C Resultados das Sessões de Teste 103

C.1 – Valores de cada amostra das sessões de teste .............................................................. 103

ix

Lista de Figuras

Figura 1 – Funcionamento em alto nível do Protocolo HTTP. ..................................................... 3

Figura 2 - Arquitectura de um teste do tipo Fuzz ........................................................................ 19

Figura 3- Arquitectura de um teste com Selenium ...................................................................... 29

Figura 4 - Modelo MVC .............................................................................................................. 37

Figura 5 - Diagrama UML de classes do Centro de Comando Local. ......................................... 42

Figura 6- Componentes de um teste de Captura e Repetição ...................................................... 45

Figura 7 - Componentes de um teste de Fuzz .............................................................................. 45

Figura 8 - Componentes de um teste de Fuzz com fonte genérica de pedidos HTTP. ................ 46

Figura 9 - Componentes envolvidos num teste Desempenho, Carga ou Stress........................... 47

Figura 10 - Arquitectura física do Centro de Controlo Remoto .................................................. 48

Figura 11 - Interface gráfica para Browser Testing. .................................................................... 49

Figura 12 - Interface gráfica para pesquisa de resultados de Browser Testing. .......................... 50

Figura 13 - Resultados de sessões de teste de Desempenho, Carga e Stress. .............................. 53

Figura 14 - Resultados detalhados de uma sessão de teste de Desempenho, Carga e Stress. ..... 54

Figura 15 - Rede de execução de testes ....................................................................................... 55

Figura 16 - Junção entre o MET e o CCR ................................................................................... 55

Figura 17 - Execução de teste e armazenamento de resultados de forma automática. ................ 57

Figura 18 - Execução de teste e armazenamento de resultados de forma manual. ...................... 58

Figura 19- Arquitectura do AuditService. .................................................................................... 60

Figura 20 – Funcionamento de um JIC ....................................................................................... 62

Figura 21 - Ficheiro de resultados XML gerado pelo TestNG. ................................................... 68

Figura 22 - Detalhes de um teste de Fuzz. ................................................................................... 68

Figura 23- Tráfego HTTP original. ............................................................................................. 70

Figura 24 - Tráfego HTTP modificado no Webscarab................................................................ 70

Figura 25- Comparação do tempo de execução do JIC entre o Safari e o Mozzila Firefox. ....... 71

Figura 26 - Comparação da evolução do tempo de resposta do JIC executado pelo Safari. ....... 73

Figura 27 - Comparação da evolução do tempo médio de resposta do JIC executado pelo Safari.

..................................................................................................................................................... 74

Lista de Figuras

x

Figura 28 - Relação entre o número de pedidos a processar e o tempo médio de resposta ......... 78

Figura 29 - Disposição dos resultados na interface gráfica para análise. .................................... 79

xi

Lista de Tabelas

Tabela 1 - Comparativo de ferramentas Captura e Repetição ..................................................... 26

Tabela 2 - Comparativo de ferramentas de intercepção de tráfego HTTP .................................. 31

Tabela 3 - Comparação das ferramentas de testes de Desempenho, Carga e Stress ................... 34

Tabela 4 - Valores para o teste de Fuzz ....................................................................................... 65

Tabela 5 – Casos de teste e resultados para Captura e Repetição. .............................................. 67

Tabela 6 – Ficheiro de configuração exemplo para teste de Fuzz. .............................................. 69

Tabela 7 - Comparação do desempenho de execução de Javascript entre Safari e Mozzila

Firefox. ........................................................................................................................................ 72

Tabela 8 - Resultados de uma sessão de testes de Carga. ........................................................... 75

Tabela 9 - Sessões de teste de Carga. .......................................................................................... 77

Tabela 10 - Resultados de uma sessão de testes de Carga. ......................................................... 78

Tabela 11 – Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 1). ........ 92

Tabela 12 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 2). ......... 92




Tabela 16 -Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 6). .......... 94




Tabela 20 – Comparação do tempo de execução do JIC entre Safari e Mozzila Firefox (servidor

livre de carga). ........................................................................................................................... 104

Tabela 21 – Tempos de execução do JIC no Safari com servidor em carga. ............................ 105

Tabela 22 – Resultados descriminados de quatro sessões de teste de Carga com de igual

configuração. ............................................................................................................................. 106

Tabela 23 - Resultados discriminados de várias sessões de teste de Carga. ............................. 107

Lista de Tabelas

xii

xiii

Abreviaturas e Símbolos

Ajax Asynchronous Javascript and XML

API Application Programming Interface

CCL Centro de Comando Local

CCR Centro de Controlo Remoto

CSS Cascade Style Sheets

DHTML Dynamic Hyper Text Markup Language

DOM Document Object Model

HTML Hyper Text Markup Language

HTTP Hypertext Transfer Protocol

IDE Integrated Development Environment

JIC Javascript Interaction Code

MET Módulo de Execução de Teste

MVC Model-View-Controller

PHP PHP: Hypertext Preprocessor

RAM Randon Access Memory

XML Extensible Markup Language

XSS Cross-site scripting

Abreviaturas e Símbolos

xiv

1

Capítulo 1

Introdução

Este capítulo visa introduzir a temática à volta da área de teste e qualidade de software.

É exposta a problemática relativamente à fase de testes de um projecto, às dificuldades

envolvidas e às consequências da ausência da mesma. É ainda explorado, o porquê da

necessidade de automatismo na execução de testes a sistemas de software.

É introduzido o conceito de aplicação Web, sendo descrito o seu funcionamento e em

que medida podem as suas características aumentar a necessidade de um correcto plano de

testes.

São ainda descritas metodologias de teste de software existentes, para responder às

questões enunciadas. Segue-se uma descrição do problema a que este projecto visa dar resposta,

sendo apresentados, em detalhe, os requisitos.

O capítulo encerra com uma descrição de toda a estrutura deste documento.

1.1 Enquadramento e Motivação

Este documento diz respeito à unidade curricular Dissertação do Mestrado Integrado em

Engenharia Informática e Computação da Faculdade de Engenharia da Universidade do Porto.

Trata-se de um projecto realizado simultaneamente em ambiente académico e empresarial,

sendo que neste último caso, a instituição de acolhimento é a Auditmark. Uma empresa situada

no Parque da Ciência e Tecnologia da Universidade do Porto, tendo como área de negócio a

prestação de serviços de auditoria a aplicações Web relacionadas com Marketing e publicidade.

Actualmente, vive-se um momento de grande desenvolvimento tecnológico, enorme

utilização e consequente dependência dos sistemas de software. Este tipo de sistema está

presente em todo o lado, como nas nossas casas nos nossos computadores de trabalho ou lazer e

Introdução

2

também no sector empresarial, onde desempenha uma série de funções de apoio, às diversas

actividades.

Verifica-se a existência de software em todas as áreas de conhecimento e

desenvolvimento, como a economia, os sistemas de saúde, os sistemas de educação, a indústria

produtora de automóveis, entre muitas outras. Os sistemas de software são hoje actores

principais até mesmo na área da medicina, nomeadamente em sistemas de suporte à vida

humana.

Em suma, o ser humano delega hoje em dia uma grande carga de tarefas e

responsabilidades nos sistemas de software que, em caso de falha ou mau funcionamento,

originam consequências catastróficas, quer ao nível económico como ético e social. Vendo

alguns exemplos mais concretos, a maioria dos automóveis de hoje, requerem um sistema

electrónico (com algum nível de código informático a especificar o seu comportamento) para

dar início ao funcionamento do motor ou ao sistema de travagem; intervenções cirúrgicas, sem

as quais vidas humanas estariam condenadas a terminar antes de um tempo considerado natural,

são realizadas com recurso a sistemas informáticos sem os quais, tais procedimentos seriam

impraticáveis; os sistemas bancários requerem um enorme suporte por parte dos seus sistemas

informáticos para aceder e gerir toda a informação em tempo útil [1]

.

Actualmente verifica-se uma enorme migração dos sistemas de software para a Web.

Existe uma grande exigência para que os sistemas estejam disponíveis em qualquer momento a

partir de qualquer ponto do globo. Isto leva a que, aplicações anteriormente do tipo local, se

transformem em aplicações do tipo distribuído e que vejam o seu número de utilizadores crescer

de forma exponencial [2]

.

Uma aplicação Web, pode ser definida como sendo um sistema a executar num servidor,

que recebe pedidos de um ou mais utilizadores, com vista a processá-los e enviar uma resposta

ao respectivo requerente. Neste contexto, vamos utilizar o termo utilizador para nos referirmos à

pessoa que utiliza uma qualquer aplicação capaz de efectuar estes pedidos e cliente, à aplicação

que efectivamente efectua o pedido. Utilizaremos esta nomenclatura, dado que a própria

designação deste tipo de arquitectura é: Cliente-Servidor.

Dentro dos vários exemplos destas arquitecturas, vamos restringir a nossa atenção sobre

as que comummente se usam para acesso à Internet, para visualização de páginas Web. Nesta

arquitectura, uma aplicação cliente, nomeadamente um Web Browser (de que são exemplos o

Microsoft Internet Explorer e o Mozzila Firefox), efectua uma ligação a um servidor enviando-

lhe um pedido, com recurso ao protocolo Hypertext Transfer Protocol (HTTP). Iremos referir-

nos a estes pedidos como: pedidos HTTP.

Um pedido HTTP, é então uma ligação que um Web Browser estabelece com um

servidor com o objectivo de trazer uma página Web para apresentar ao utilizador.

https://trac.auditmark.com/pcarvalho/changeset/6

Introdução

3

Um pedido HTTP é composto por uma série de informações, contidas nos cabeçalhos

do protocolo, necessárias ao processamento do pedido (como por exemplo, a identificação do

Browser, da máquina cliente, ente outras). O pedido é então processado e imediatamente é

enviada uma resposta para o cliente com uma série de cabeçalhos (estes são necessários à

interpretação da resposta dado que pode ser a página pedida ou um erro como: de mudança de

endereço, indisponibilidade da maquina servidora, entre outros). Juntamente com os cabeçalhos

de resposta, é enviado código e outros elementos (HTML, Javascript, CSS, aplicações em

Flash, imagens, etc.) responsáveis por mostrar a página pedida pelo cliente ou realizar alguma

alteração sobre a página actual.

Figura 1 – Funcionamento em alto nível do Protocolo HTTP.

A figura 1 representa um esquema de como se processa esta acção. Neste documento

(porque o tema deste projecto assim o exige) iremos abstrair-nos da actividade que acontece ao

longo da rede (Internet) desde que o pedido é enviado até que é recebido.

Além desta informação, basta apenas referir que é nos cabeçalhos do protocolo HTTP,

que vai toda a informação que um utilizador quer fazer chegar ao servidor, como por exemplo,

os dados que introduziu em algum formulário.

Não mais se aprofundará o funcionamento do protocolo HTTP dado que mais não é

necessário que se conheça, para ser possível entender o funcionamento dos testes a realizar no

decorrer deste projecto. No entanto, para uma melhor percepção do funcionamento deste

protocolo e das questões de rede e comunicação associadas, pode ser efectuada uma leitura

sobre Redes e Comunicações [3]

.

Introdução

4

Os pedidos resultam normalmente da escrita de um endereço Web no campo de procura

do Browser ou das acções realizadas pelo utilizador na interface da página Web (cliques do rato

em hiperligações, submissões de formulários, etc.).

Os servidores HTTP podem atender inúmeros pedidos em simultâneo servindo assim

centenas (por vezes milhares ou mesmo milhões) de aplicações cliente ao mesmo tempo. Uma

das grandes vantagens deste sistema é precisamente estar disponível para vários utilizadores em

simultâneo. Desta forma, é possível que qualquer utilizador, a partir de qualquer ponto do globo

possa aceder aos serviços disponibilizados pelo sistema.

Levantam-se imediatamente uma série de questões, dado que estes sistemas requerem

ser executados com recurso a Hardware de elevado desempenho, que os algoritmos

responsáveis por executar os serviços sejam cuidadosamente desenhados com o objectivo de

executarem o mais rapidamente possível, existindo ainda a questão da segurança, na qual, se

colocam as preocupações de acessos indevidos ou com fins maliciosos, algo muito comum hoje

em dia e de difícil prevenção.

Dadas as características dos sistemas Web, são agravadas as questões relativas à

qualidade. O que antes era um erro com uma probabilidade mínima de ocorrer, agora revela-se

algo que carece de uma maior minuciosidade e cuidado. São levantadas ainda questões maiores

relativamente ao desempenho do sistema, uma vez que irá funcionar, por vezes, em condições

de sobrecarga (um servidor poderá em vários momentos ter de responder aos pedidos de

milhões de clientes), mas também ao nível da segurança, dado que existirão utilizadores com

atitudes menos éticas que tentarão realizar acções no sistema que não lhes são devidas ou

simplesmente irão atacar o sistema com vista a criar um mau funcionamento, tornando-o

indisponível a outros utilizadores.

Uma aplicação Web está bastante vulnerável a ser imitada e copiada. Assim, quando

uma empresa cria um produto novo e o coloca na Web, não se revela difícil, usar a ideia por

base e criar um produto concorrente. Para dois produtos que ofereçam funcionalidades

semelhantes (entre muitas outras questões a não abordar neste documento, tais como o nível de

usabilidade ou a existência de uma interface gráfica aprazível), estudos revelam que o utilizador

escolherá muito rapidamente aquele com menor tempo de resposta. Mais ainda, estes estudos

revelam que, se um serviço oferece tudo o que um utilizador pretende mas mostra-se moroso na

sua capacidade de resposta, muito rapidamente este produto torna-se não competitivo no

mercado. E não se considere em tempo algum (quer por questões intrínsecas à natureza humana

quer pela quantidade de oferta existente) que os utilizadores são tolerantes nesta questão.

Tomemos um pequeno exemplo: consideremos um cenário futurista em que uma página

Web se apresenta a cada utilizador totalmente de acordo com as preferências, totalmente

personalizada, oferecendo toda a usabilidade e funcionalidades esperadas. Consideremos

também, que esta página nos permite realizar algum tipo de transacção económica. Se agora

Introdução

5

pensarmos que este serviço demoraria (hipoteticamente) 10 segundos a responder a um pedido

de encomenda, será pensamento imediato de um utilizador assíduo, que preferiria o tipo de

interfaces de que dispomos hoje em dia, mas com uma resposta em menos de um segundo. Este

é claro um cenário apenas ilustrativo, mas que ilustra bem a relevância do desempenho de uma

aplicação Web [2]

.

As questões relativas ao tempo de resposta de um sistema, não se prendem só com a

minimização do mesmo. Existe também o conhecimento que um sistema em processamento de

vários pedidos tenderá a ser mais lento (para uma melhor compreensão desta temática pode ser

realizado algum estudo sobre Arquitectura de Computadores e sobre teoria de Sistemas

Operativos), havendo então a necessidade de criar um sistema que perante muitos pedidos,

muita carga, usando um vocabulário mais técnico, seja capaz de manter o seu tempo de resposta

ou pelo menos, um tempo de resposta aceitável [2, 4, 5]

.

Esta questão assume particular relevância não só em aplicações Web de acesso directo a

utilizadores de Web Browsers, mas também para aplicações de empresas que ofereçam serviços

a outras empresas.

Vejamos o seguinte caso: uma empresa oferece serviços de armazenamento de dados

em tempo real a outras empresas. Até que ponto pode esta empresa expandir o seu número de

clientes para consequente aumento do volume de negócios, quota de mercado e lucro? Poderá

faze-lo indefinidamente? O seu sistema será capaz de responder a quantos clientes em tempo

útil? Mais tecnicamente, que carga aguentará esta aplicação e como se comportará em situações

de stress de sistema [2]

?

Neste ponto fará todo o sentido, que se comecem a colocar questões relativas às

consequências de falhas abruptas e não previstas de todos estes sistemas. É mesmo possível

chegar ao ponto de se colocar a pergunta “Será que podemos confiar nestes sistemas?”.

Como é notório existe uma grande exigência e expectativa relativamente à qualidade

dos produtos de software que actualmente se desenvolvem. Consequentemente, existe a

necessidade de que os profissionais de desenvolvimento de software sejam exímios no que diz

respeito ao seguimento de boas práticas, para que produzam sistemas de elevada fiabilidade,

confiança, usabilidade, de elevado desempenho, com a capacidade de prevenção e recuperação

de erros e que respondam às necessidades dos seus utilizadores da forma e no tempo esperados.

Infelizmente, o ser humano, quando comparado com o enorme poder de computação e

processamento de informação das máquinas, é extremamente limitado. E, pior, comete erros.

Estes erros, irão revelar-se no comportamento não esperado dos sistemas e trazer

consequências para os seus utilizadores. Os erros podem ter várias origens possíveis, como por

exemplo, má compreensão dos requisitos do utilizador (com consequente desenvolvimento de

um sistema com comportamento não esperado) ou erros na criação dos algoritmos responsáveis


Introdução

6

por executar o comportamento esperado. É imperativo que se recorram a formas para detectar e

corrigir estes erros.

Neste sentido, foi desenvolvida uma área, denominada Teste e Qualidade de Software. É

mais recente que o desenvolvimento de software e apesar de ter já alguns anos de existência, de

existirem exemplares na literatura que descrevem técnicas e metodologias de teste de software

(são exemplos os livros e artigos mencionados nas referências deste documento), ferramentas e

boas práticas de desenvolvimento e de teste, é ainda considerada por alguns autores, como

sendo uma arte e não uma ciência (no sentido metafórico, uma vez que há de facto estudos e

experiências de verificação) [1,2]

. Esta consideração vem do facto de ainda haver muita pesquisa

e trabalho a realizar, para conseguir perceber uma concreta relação entre o pensamento humano

e os erros cometidos no desenvolvimento de software. Um bom exemplo é o facto de, apesar de

existirem boas práticas e metodologias de teste, de se poderem treinar indivíduos na área do

teste, a verdadeira essência da qualidade do teste realizado vem da experiência, sentido crítico e

intuição do profissional de teste.

Sintetizando, teste de software, é uma área do desenvolvimento de software que pode

ser definida como sendo um método para garantir a qualidade [1,2]

.

Existem várias formas e classificações que podem ser aplicadas ao teste de software

conforme este é executado e quais os seus objectivos. Por motivos de simplificação e espaço, e

também porque é essencialmente dentro dessa forma que se processará o caso de estudo deste

projecto, iremos focar-nos nos testes de sistema. Estes, caracterizam-se por testar um sistema

como um todo, com todos os módulos a funcionar, de modo a verificar se este se comporta de

acordo com os requisitos sobre os quais foi projectado e implementado.

Em teste de sistema, são testadas características funcionais e não funcionais. Antes de

iniciarmos a sua descrição, é importante ter em conta que um teste tem apenas dois resultados

possíveis: passar, quando não são encontrados erros ou falhar, quando são encontrados erros.

Os testes funcionais incidem sobre as funcionalidades disponibilizadas pelo sistema.

Visam determinar se os requisitos funcionais são cumpridos, isto é, se durante a utilização do

sistema, o comportamento obtido é efectivamente o esperado pelos seus utilizadores.

Por sua vez, os testes não funcionais visam pôr à prova características comportamentais

do sistema, não directamente relacionadas com as funcionalidades. É por vezes referido, que os

testes não funcionais visam verificar se o sistema opera dentro dos limites e condições para os

quais foi projectado. Condições tais como: o desempenho; a capacidade de resposta em

condições de carga excessiva; a segurança oferecida pelo sistema; o ambiente no qual o sistema

se insere, que pode incluir elementos como a máquina física (ou virtual) onde o sistema é

executado; os recursos de memória (RAM, Virtual, Disco) utilizados; no caso de aplicações

dependentes de outras aplicações, como por exemplo, as aplicações Web, o próprio Browser


Introdução

7

responsável pela visualização da página; as restrições de utilização; a portabilidade; a

compatibilidade entre os vários Sistemas Operativos, entre outras.

Relativamente a cada um dos tipos de teste supra mencionados, existem várias técnicas,

várias metodologias e várias ferramentas de suporte. Existem vários tipos de teste: técnicas de

caixa branca, técnicas de caixa preta, teste baseado em modelos, testes de regressão, testes de

mutação, testes de aceitação, testes por Captura e Repetição (frequentemente referidos na

literatura como Capture-Replay), testes do tipo Fuzz, entre outros.

Dos mencionados, para o projecto ao qual se refere este documento, têm especial

interesse os seguintes dois tipos de teste:

Captura e Repetição: é uma técnica que se baseia em colocar um utilizador a usar o

sistema, capturando e gravando a suas acções para um ficheiro. Alternativamente este

ficheiro pode ser escrito directamente à mão. Posteriormente, uma ferramenta irá

executar essas acções, simulando um utilizador (ou vários em simultâneo) a interagir

com sistema. Este ficheiro pode inclusivamente ser modificado, criando assim

condições diferentes para a repetição, como por exemplo, testar várias vezes para uma

caixa de texto, uma entrada de dados com múltiplos valores. Uma das várias utilidades

desta técnica é a seguinte: à medida que o sistema vai sendo alterado, o ficheiro poderá

ser executado e permitir verificar se o comportamento do sistema é igual ao que tinha

antes das alterações.

Fuzz: é uma técnica que se baseia em criar no sistema em teste invocações de funções

(rotinas ou métodos que executam algum código) com valores, ou tipos de valores de

entrada, que não os esperados, pondo então à prova a assumpção muitas vezes feita

pelos programadores, de que uma função “correctamente codificada” executa e retorna

sempre correctamente. Esta actividade é conseguida, fazendo chegar ao sistema, valores

que não os esperados, num momento de entrada de dados, como por exemplo, a

introdução de texto por um utilizador ou uma leitura de ficheiro, em que este é dinâmico

ou variável. Tem particular utilidade nos sistemas do tipo Web, mas esta técnica é usada

também em aplicações do tipo local, tendo sido inclusivamente utilizada para encontrar

falhas no sistema de linha de comandos da plataforma Unix.

Descrições detalhadas destas técnicas, acompanhadas de alguns exemplos e formas de

aplicação, estão presentes no segundo capítulo deste documento [1,2, 6]

.

Para os testes não funcionais existem também várias técnicas e várias metodologias.

Neste projecto tem essencial importância três tipos (relacionados entre si, pois os seus

Introdução

8

princípios são semelhantes), todos eles essencialmente dirigidos para testes não funcionais sobre

aplicações do tipo Web. Estas técnicas são:

Testes de Desempenho: é uma técnica que visa avaliar o tempo em que um

determinado pedido HTTP é servido, com o servidor a funcionar em condições

normais;

Testes de Carga: é uma técnica que visa avaliar o tempo em que um determinado

pedido HTTP é servido com o servidor a funcionar em condições de alguma carga

de processamento, mas ainda assim, em condições normais;

Testes de Stress: é uma técnica que visa levar o servidor ao limite (ou mesmo para

além deste) da sua capacidade de processamento, avaliando os efeitos desta situação

no correcto funcionamento do sistema, na possível corrupção do estado do sistema e

avaliar ainda de que forma e em quanto tempo, recupera o sistema destas condições

de funcionamento.

Novamente como dito para os testes funcionais, descrições mais detalhadas juntamente

com alguns exemplos, estão presentes no segundo capítulo deste documento [7, 8]

.

Dada a nossa, já referida, dependência dos sistemas de software e a existência das

mencionadas técnicas de teste, podemos ser levados a pensar que todas as questões de controlo

de qualidade estão previstas e tidas em conta. No entanto, os projectos de software correm

dentro de limites de prazo e orçamento, sendo que muitas vezes a fase de teste ocorre no final

do projecto, já fora do prazo de entrega, dentro de uma enorme pressão e, por vezes, já em

excesso do orçamento.

Apesar de todas as técnicas supra mencionadas revelarem uma enorme capacidade de

detecção de erros e a sua consequente correcção, existe ainda a problemática associada ao facto

de se conseguir perceber se foram realizados casos de teste suficientes para detectar todos os

erros presentes. Muitas vezes, estas questões não são respondidas de forma satisfatória, dado

que, o tempo disponível para a fase de testes num projecto de software é reduzido. Pode

portanto chegar-se à conclusão de que não existem erros num determinado sistema, isto, não

porque estes não existem, mas porque a quantidade ou variedade de testes realizados não foi

suficiente [1]

.

É neste ponto que a atenção se vira para a automatização do teste de software, com vista

a tornar esta actividade mais rápida, mais abrangente e a possibilitar que em menos tempo se

efectue mais actividade de teste. No limite, seria extremamente benéfico que um sistema fosse

capaz de gerar todos os casos de teste possíveis, executá-los e apresentar um relatório detalhado


Introdução

9

de erros, ficando apenas ao cargo do ser humano a correcção dos mesmos. Num cenário

totalmente futurista, a correcção dos erros estaria também presente. Porém, o panorama actual

está ainda longe do cenário descrito, existindo já, no entanto, grandes avanços nesse sentido.

Dentro da automatização de teste, existe muito do que se poderia aqui apresentar.

Novamente, é necessário restringir a atenção sobre as aplicações Web.

Hoje em dia, com base na técnica de Captura e Repetição, onde é possível capturar uma

série de acções de um utilizador, criando um ficheiro que pode posteriormente ser manipulado,

alterado e executado várias vezes, simulando o comportamento do utilizador. Ou seja, é possível

automatizar o conjunto de acções que o Browser realiza numa sessão de teste. É também

possível usufruir de algum automatismo nas técnicas do tipo Fuzz, em que uma qualquer

aplicação Web é bombardeada por uma série de pedidos gerados automaticamente por uma

outra aplicação onde de forma automática também, se faz variar os valores de entrada. Existem

ainda ferramentas para os testes de Desempenho, de Carga e Stress que após uma configuração

inicial, executam este tipo de testes de forma autónoma, analisam os resultados, geram tabelas,

gráficos e outras formas que permitem ao ser humano compreender o resultado do teste.

No entanto, a actividade de teste a aplicações Web encontra-se ainda numa fase de

desenvolvimento. Particularmente, o teste automático leva a que os seus executantes encontrem

enormes dificuldades na utilização das ferramentas de suporte. Dificuldades estas tais como: O

uso de Browsers de forma limitada; a restrição ao uso de apenas um Sistema Operativo; o

conjunto de funcionalidades e métricas entre ferramentas não segue uma norma ou um padrão.

Há ainda o grande problema da distribuição de funcionalidades. Umas ferramentas realizam

todo o tipo de testes necessários (ou quase) mas estão apenas disponíveis para um Sistema

Operativo ou fazem uso de apenas um ou dois Browsers. Outras, com suporte a vários Browsers

e multi-plataforma, realizam um conjunto limitado de operações [1, 2, 9]

.

Apesar disto, existem já algumas abordagens a este problema. Algumas das quais

incidem sobre a temática da geração automática de casos de teste, através de modelos do

sistema, com recurso a uma ferramenta de repetição para execução dos testes. Estas abordagens

estão porém, apenas relacionadas com o teste funcional. O método a seguir neste projecto de

Dissertação é um pouco diferente não abordando a temática da geração automática do caso de

teste. Está mais direccionada para a execução automática dos testes, tentando abranger

simultaneamente o teste funcional e não funcional [7, 10]

.

O projecto descrito neste documento incide sobre a criação de uma Plataforma de testes

que possibilite o uso de múltiplos Web Browsers e unificando numa só ferramenta um conjunto

de funcionalidades. Pretende-se então, desenvolver uma ferramenta capaz de gerar pedidos

HTTP automaticamente e realizar alterações sobre estes pedidos de forma automática. Assim

permitirá o uso da técnica de captura e repetição que analisará o funcionamento do sistema do

ponto de vista funcional, permitindo ainda que se processe, teste do tipo Fuzz. A Plataforma


Introdução

10

deverá possibilitar ainda, a realização dos três tipos de testes não funcionais referidos

(Desempenho, Carga e Stress) de forma automática, com capacidade de geração de relatórios

com os resultados dos testes realizados.

1.2 Especificação do Problema

Qualquer aplicação Web requer que, ao seu processo de desenvolvimento, esteja

associada uma fase de teste, com vista a garantir a sua qualidade. As aplicações podem ser

testadas de um ponto de vista funcional ou não funcional, existindo para isso uma enorme

variedade de ferramentas. Cada uma destas ferramentas oferece funcionalidades independentes,

suporte limitado a Browsers e os resultados que disponibilizam são apresentados sem seguir um

padrão ou uma norma. Pior ainda, a grande maioria destas ferramentas funciona de forma

manual, isto é, requer um conjunto dinâmico de operações de configuração a cada sessão,

tornando a actividade de teste morosa.

Um executante de testes, que tenha à sua responsabilidade testar a qualidade de uma

qualquer aplicação Web, terá de utilizar uma série de ferramentas, com diferentes

funcionalidades, que apresentam diferentes métricas e diferentes estruturas de resultados.

Existem assim, dificuldades acrescidas no que diz respeito à correcta definição do plano de

testes e interpretação de resultados. Mais ainda, como se obriga à utilização de várias

ferramentas, a actividade será mais morosa.

A falta de automatismo da maioria das ferramentas traz dificuldades acrescidas quando

se pretende realizar dois tipos de teste em simultâneo. Por exemplo, para executar em

simultâneo um teste de replicação de acções na interface gráfica com um teste de Fuzz, será

necessário usar duas ferramentas e a cada pedido HTTP, seria necessário efectuar as

modificações de forma manual. A situação tornar-se-ia mais gravosa, num caso em que, um

único profissional se visse obrigado a gerir sozinho, testes de vários tipos (por exemplo Fuzz e

Carga), ocorrendo estes em simultâneo.

Em suma, o problema ao qual este trabalho pretende dar um contributo é a inexistência

de uma ferramenta automática de teste a aplicações Web que reúna os vários tipos de teste, cujos

resultados sejam apresentados ainda dentro do mesmo formato (resolvendo o problema do uso

de várias ferramentas com diferentes formas de apresentação), suportando uma multiplicidade

elevada de Web Browsers.

Introdução

11

1.3 Objectivos

O trabalho consiste na criação de uma Plataforma de teste automático para aplicações

Web, que funcione com múltiplos Browsers, nomeadamente os mais comuns: Microsoft Internet

Explorer, Mozilla Firefox, Opera, Google Chrome e Safari.

A Plataforma desenvolvida, deve ser tão genérica quanto possível, para que se possa

testar qualquer aplicação Web com um conjunto mínimo de alterações, isto é, todo o suporte e

funcionamento da Plataforma deverá ser independente do sistema a testar, sendo possível

aplicar a qualquer sistema Web apenas pela concepção de ficheiros de teste adaptados a esse

mesmo sistema (conjunto mínimo possível de alterações).

Constitui também um objectivo deste projecto, que a arquitectura definida resulte num

sistema extensível, de tal forma que, o suporte a novos Browsers seja simplificado.

Inicialmente, o projecto foi dividido em três fases:

1. Automatização da actividade de teste;

2. Centro de gestão e controlo (Front End);

3. Monitorização e recolha de registos.

O grande contributo deste trabalho foi a concepção de uma Plataforma que automatize o

processo de teste tanto quanto possível. Considerou-se que seria extremamente benéfico, que o

sistema ficasse tão próximo quanto possível de um estado final (pronto para utilização prática).

Optou-se então por diminuir o tempo previsto pelo planeamento para o grupo três de objectivos,

criando assim um quarto grupo com vista a enriquecer a Plataforma do ponto de vista das suas

funcionalidades.

Apresentam-se agora em detalhe os diversos grupos de objectivos.

1. Automatização da actividade de teste

Esta fase do projecto é relativa à construção de uma Plataforma de teste automático.

Pretende-se a integração de várias ferramentas com vista a automatizar a actividade de teste.

Introdução

12

Deverão estar disponíveis as seguintes funcionalidades:

Gerar pedidos em páginas Web usando múltiplos Web Browsers;

Alterar parâmetros das variáveis enviadas nos pedidos pelos métodos GET e POST;

Efectuar teste Fuzz (não sendo imposta a verificação do resultado produzido). A

alteração, modificação ou remoção de um qualquer campo dos cabeçalhos HTTP

deve ser possível;

Alterar o IP de origem (Source IP) dos pedidos HTTP;

Realizar testes não funcionais, como Desempenho, Carga e Stress.

2. Centro (Front End) de gestão e controlo

Tem como objectivo o comando remoto da Plataforma de teste automático.

Com este requisito, pretende-se que o automatismo seja elevado ao nível do comando

da Plataforma possibilitando que esta esteja a executar em várias máquinas, sendo as

várias instâncias controladas por apenas uma interface. Este centro de controlo deverá

responder aos seguintes requisitos:

Configurar uma sessão de teste:

o Definir as condições e tipo de teste;

o Definir a máquina de execução do teste.

Comandar a sessão:

o Iniciar;

o Parar;

o Terminar.

Ver detalhes do teste:

o Definições do teste;

o Tráfego HTTP associado;

o Erros encontrados.

Introdução

13

3. Monitorização e recolha de informação

Tem como objectivo ampliar os dados recolhidos durante os testes. Assim

pretende-se ainda, que seja possível:

Medir o tráfego HTTP que chega à interface de rede e ao servidor Web;

Medir a resposta do servidor:

o Analisar os códigos HTTP;

o Identificar a taxa de pedidos que não são servidos;

o Identificar o atraso a servir pedidos.

Desenvolvimento de módulos que reportam erros e problemas detectados a nível da

aplicação a testar. A infra-estrutura de teste recebe essa informação de forma

transparente, sem precisar de saber os detalhes da aplicação que está a gerar os

registos (logs/traces).

4. Objectivos adicionais

Testes Unitários: a especificação dos métodos de teste automático através das

interfaces gráficas. É possível obter os resultados da execução dos métodos que são

invocados através da interacção automática com a interface gráfica. Permite ainda

que a Plataforma fique habilitada a executar testes a componentes individuais

(unidades);

Forma de controlo local da Plataforma de testes sem recurso ao Front-End de

gestão;

Módulo de armazenamento e organização de resultados em Base de Dados para

consulta filtrada posterior;

Módulo de análise e comparação de resultados de testes não funcionais efectuados

em simultâneo em várias máquinas.

Introdução

14

1.4 Estrutura do Documento

Este documento é composto por cinco capítulos: Introdução; Metodologias e

Ferramentas de Teste a Aplicações Web; Concepção da Solução; Caso de Estudo; Conclusão e

Trabalho Futuro.

No capítulo 1, Introdução, é apresentada a motivação e o enquadramento, sendo ainda

feita uma exposição da temática relativamente à área de teste e qualidade de software. Neste

mesmo capítulo são ainda definidos os objectivos deste projecto e é feita uma descrição do

problema a resolver.

No capítulo 2, Metodologias e Ferramentas de Teste a Aplicações Web, são

apresentadas e explicadas uma série de metodologias de teste de software que são aplicáveis a

sistemas Web. É ainda feita uma análise a várias ferramentas de teste, as mais representativas de

todo o conjunto analisado (sendo estas agrupadas por funcionalidades e tipo de teste), com o

objectivo de seleccionar aquelas que iriam integrar a Plataforma.

Segue-se o capítulo 3, Concepção da Solução, onde é descrita a arquitectura e modo de

funcionamento dos diferentes módulos desenvolvidos.

O capítulo 4, Caso de Estudo, existe com o objectivo de exemplificar uma utilização da

Plataforma num caso real.

Este documento encerra com o capítulo 5, Conclusão e Trabalho Futuro, onde são

discutidas as conclusões que foram possíveis retirar no final, sendo ainda enunciadas uma série

de melhorias e funcionalidades adicionais que aumentariam o potencial da solução

desenvolvida.

15

Capítulo 2

Metodologias e Ferramentas de Teste a

Aplicações Web

Neste capítulo são apresentadas uma série de metodologias e ferramentas de teste de

software. A apresentação é feita no sentido das aplicações Web. Assim, como o objectivo deste

projecto de Dissertação é a concepção de uma Plataforma de teste automático para aplicações

Web, vão ser explicados os vários tipos de teste que serão disponibilizados. Serão expostos em

detalhe os seus objectivos e o que pretendem testar, sendo apresentando ainda o seu modo de

funcionamento e alguns exemplos de aplicação de cada tipo de teste.

Para a constituição da Plataforma, serão analisadas uma série de ferramentas de teste a

aplicações Web. Como existe uma grande diversidade de ferramentas, optou-se por analisar em

mais detalhe algumas delas por serem representativas do conjunto global de ferramentas. As

apresentadas neste documento, são aquelas, cujas condições simultaneamente permitiram

análise por experimentação prática ou aparente enquadramento nos objectivos da Plataforma.

2.1 Tipos de teste de software

2.1.1 Testes funcionais

Como o próprio nome indicia, este tipo de teste, também denominado teste de

utilizador, visa pôr o sistema à prova do ponto de vista das suas funcionalidades. Tem como

objectivo garantir que, as funcionalidades disponibilizadas ao utilizador estão todas presentes,

que se comportam de acordo com os requisitos iniciais e que seguem todos os pressupostos

definidos na fase de especificação de requisitos do projecto de software.

Metodologias e Ferramentas de Teste Aplicações Web

16

Existem vários tipos (ou técnicas) de teste funcional, tais como testes unitários, testes de

mutação, testes baseados em modelos, entre outros. Descrições pormenorizadas, exemplos de

aplicação, formas de utilização de ferramentas para todas estas técnicas podem ser encontradas

em vários exemplares da literatura [1, 2, 8, 10]

.

Para este projecto iremos apenas abordar dois tipos de testes funcionais: teste do tipo

captura e repetição (comummente referidos na literatura como Capture-Replay) e testes do tipo

Fuzz.

Testes de Captura e Repetição

Como já referido, esta técnica baseia-se na captura de acções do utilizador, sendo estas

gravadas num ficheiro para posterior execução. Em alguns exemplares da literatura, esta técnica

chega a ser definida como a gravação de dados de entrada ou saída e acções do utilizador em

ficheiros sendo estes utilizados para posterior execução automática [1]

.

Alguns exemplos de acções (no caso de aplicações Web, uma vez que é dentro deste

contexto que estamos a analisar esta metodologia) que podem ser simuladas e repetidas pelas

aplicações que lêem estes ficheiros são:

Cliques do rato em botões ou hiperligações;

Inserções de valores em campos ou caixas de texto;

Escrita de hiperligações;

Submissão de formulários;

Cliques do rato em caixas de diálogo geradas por Javascript;

Interacções com aplicações escritas em Flash;

Qualquer combinação das acções anteriores.

Também já referido foi, que este ficheiro pode alternativamente ser escrito à mão.

Independentemente de como foi gerado, pode ser sempre manipulado (programaticamente).

Esta manipulação, permite que o executante do teste aumente o nível de automatismo, uma vez

que, é possível introduzir condições, verificações, criar ciclos de execução de uma parte (ou

todo), fazendo variar os dados de entrada. Programaticamente, fica ao critério e imaginação do

programador o tipo de automatismo que pode desenvolver.

Dentro das condições que se podem definir, tomam relevante importância as asserções.

Uma asserção é uma afirmação lógica do tipo booleana, aplicada sobre um determinado

elemento do teste. Dada a sua natureza, esta condição ao ser avaliada, retorna para o programa

de teste o valor verdadeiro ou falso.


17

As asserções têm várias utilidades. Apresentam-se agora dois exemplos (ambos no

contexto de uma aplicação Web) de como estas asserções podem ser utilizadas, contribuindo

assim para o automatismo do teste. Ambos, ocorrem num cenário em que o ficheiro de teste, já

foi criado e a ferramenta de teste está a executa-lo, manipulando um Browser para simular as

acções de um utilizador.

Exemplo 1: Suponhamos um ficheiro de teste que efectua uma autenticação sobre uma

página para visualização de correio electrónico. Verifica depois se existe correio por ler, lendo a

primeira mensagem caso exista. Após esta situação, é efectuada uma acção de terminar a sessão.

Aqui existem duas possibilidades: ou existe correio electrónico por ler, ou não existe.

Sem as asserções teríamos de ter dois testes. Caso tivéssemos apenas um teste, por exemplo,

assumindo que existe correio, no caso de não existir correio, o teste (que não tinha motivo para

falhar) iria falhar. Podemos automatizar, esta situação colocando uma asserção. Ou seja, o teste

efectuaria autenticação, e uma asserção verificaria se existe correio (por exemplo, se o valor da

caixa de entrada seria maior que zero). Somente se existir correio por ler, a parte do ficheiro

responsável por ler a mensagem é executada. Finalmente é executada a saída de sessão e o teste

retorna como tendo tido sucesso. Com base no valor da asserção, pode ser adicionada a

informação de que partes do ficheiro foram executadas e porquê.

Exemplo 2: Suponhamos agora um outro ficheiro de teste que pretende simular o

preenchimento de um formulário numa página Web e a sua submissão. Após esta submissão

pretende-se efectuar um redireccionamento.

Pode existir uma falha momentânea, do lado da aplicação servidora. Não faz sentido,

um ser humano submeter um formulário e caso este não seja submetido com sucesso, ou caso

não exista qualquer resposta acerca do sucesso da submissão, que este ignore a situação e

continue a sua utilização. Tipicamente iria tentar uma nova submissão. Sem as asserções, o teste

seria manual. Poderia então, ser definida uma asserção (e possivelmente uma variável

contadora), para estipular que o teste só deveria prosseguir em determinadas condições ou que,

o teste deveria ser repetido. No final, seria possível ao executante do teste, saber se o teste

passou ou não, mas tendo passado, que foi necessário repetir determinada acção N vezes.

A técnica de Captura e Repetição pode ser um suporte ao desenvolvimento com recurso

aos Testes de Regressão. Esta técnica funciona da seguinte forma: baseia-se na existência de

uma bateria de teste que foi utilizada para validar um sistema, depois de um determinado

desenvolvimento. Quando todos os erros são detectados (os alcançáveis pela bateria definida),

são corrigidos, o desenvolvimento deve prosseguir. Antes de serem executados novos testes, a

anterior bateria deve ser executada de forma a detectar se o novo desenvolvimento criou erros


18

em módulos que anteriormente funcionavam correctamente. Se forem encontrados erros,

considera-se que o sistema regrediu e portanto, estes devem ser corrigidos. Caso contrário,

considera-se que o sistema evolui e pode-se então prosseguir [1]

.

Os ficheiros de teste de Captura e Repetição podem constituir a referida bateria de

testes, uma vez que é possível especificar nestes o uso de todas as funcionalidades do sistema.

Como veremos no próximo subcapítulo, 2.2, na presença de uma interface gráfica orientada a

esta técnica, a geração destes ficheiros pode ser feita de forma automática e rápida.

Finalmente, é importante referir que os ficheiros, no caso de algumas ferramentas, são

gerados em linguagens próprias (como veremos mais adiante) mas o mais comum é serem

gerados em linguagens de programação conhecidas (Python, Java, Ruby, etc.), com recurso a

uma Application Programming Interface (API) que disponibiliza funções que actuam sobre a

respectiva aplicação em teste. Esta situação permite que o executante do teste, possa definir

código de modo a automatizar e criar condições de teste, conforme as necessidades específicas

do sistema em teste.

No entanto, esta é uma técnica que pode ser usada por pessoas, sem conhecimentos de

programação, uma vez que, as ferramentas de Captura e Repetição oferecem interfaces gráficas

que permitem definir uma série de parâmetros do teste, inclusivamente a inserção de asserções,

a modificação da ordem pela qual as acções são executadas e a criação de ciclos que executam

determinado teste, variando os dados de entrada a cada iteração desse mesmo ciclo [1]

.

Testes do tipo Fuzz

Como já referido no capítulo 1, a técnica de teste Fuzz, também denominada Fuzzing ou

Fuzzy testing, baseia-se em criar no sistema em teste invocações de funções (funções no sentido

de rotinas ou métodos que executam algum comportamento originado por código) com valores

ou tipos de valores de entrada, fora dos domínios válidos. Dentro desse contexto, pode dizer-se

que o grande objectivo desta técnica é pôr à prova a assumpção muitas vezes feita pelos

programadores, de que uma função “correctamente codificada” executa e retorna sempre

correctamente.

A forma de funcionamento desta metodologia é a seguinte: nos pontos da aplicação em

teste onde existe entrada de dados dinâmicos ou variáveis, feitos por parte de um utilizador (ou

mesmo uma outra aplicação), fazem-se chegar valores aleatórios, criando assim uma

multiplicidade de entradas de dados, dentro e fora do intervalo válido, para observação dos seus

efeitos na aplicação.

Validar dados de entrada antes da execução de uma função (evitando a sua execução no

caso de dados não válidos), como por exemplo, verificar se o valor é do tipo esperado (real,

inteiro, string, char, booleano, etc.) ou se, estando no tipo esperado, se encontra dentro da gama


19

esperada, são operações que do ponto de vista da progressão da execução, não trazem valor

acrescentado. No entanto, a ausência destas operações pode levar a que o programa falhe,

executando erradamente ou mesmo parando a sua execução. A técnica de teste Fuzz permite

então, verificar situações na qual a ausência ou a incorrecção deste tipo de validação origina um

mau funcionamento do sistema.

A forma de fazer chegar valores a uma aplicação Web é feita pelo envio de variáveis

pelos métodos GET e POST, duas formas sobre as quais os clientes HTTP enviam valores para

os servidores, para que sejam entregues às aplicações. Assim, uma forma de realizar este tipo de

teste é simular pedidos HTTP, fazendo alterar os valores enviados por estes métodos.

Para a sua execução, pode ser utilizada uma ferramenta que simule pedidos no Browser

e que gere um ficheiro de teste (como acontece na supra descrita técnica de Captura e

Repetição). Este ficheiro será então manipulado, para que as variáveis enviadas por GET ou

POST, por exemplo, no clique de uma hiperligação, na submissão de um formulário ou até

mesmo, na realização de um procedimento do tipo Asynchronous Javascript and XML (Ajax),

sejam sucessivamente alteradas para valores diferentes dos esperados. Esta alteração pode então

ser feita, de forma controlada ou aleatória. Finalmente, a estrutura desta actividade é semelhante

à de um pedido HTTP, exemplificada na figura 1, do primeiro capítulo deste documento.

Uma outra forma de realizar este teste é utilizar uma ferramenta de intercepção e

manipulação de tráfego HTTP, como um servidor proxy com o qual o Browser irá comunicar.

Assim, no momento em que um Browser realiza um pedido HTTP, este é interceptado no proxy

antes de ser entregue ao servidor de destino.

A figura 2 mostra um esquema exemplificativo da forma de processamento deste modo

de execução do teste Fuzz. Na intercepção realizada pela ferramenta, os cabeçalhos HTTP são

manipulados e as variáveis alteradas, conforme definido pelo executante do teste.

Figura 2 - Arquitectura de um teste do tipo Fuzz


20

Esta abordagem abre ainda três novas possibilidades:

Extensão do teste Fuzz, à inserção, modificação e remoção de variáveis não visíveis ao

utilizador (valores HTTP do tipo “HTML hidden”, entre outros);

Realização de modificações ao nível dos cabeçalhos do protocolo HTTP;

Uma vez que, esta ferramenta intercepta além dos pedidos, também as respostas,

permite que se crie um registo mais efectivo da actividade, podendo o efeito dos testes

ser analisado também do ponto de vista dos cabeçalhos HTTP de resposta.

Neste projecto, serão utilizadas ambas as formas de Fuzz descritas, aumentando assim, a

potência do teste e a cobertura de casos de teste [6]

.

2.1.2 Testes não funcionais

Tal como acontece com os testes funcionais, para testes não funcionais existem também

inúmeras técnicas. Vamos cingir a nossa atenção a três tipos de teste não funcional: testes de

Desempenho, testes de Carga e testes de Stress.

Os conceitos de desempenho e carga estão directamente relacionados com o tipo de

sistema ao qual nos referimos. Dito de outra forma, o modo como medimos o desempenho ou

estabelecemos a carga de um processamento, é feita consoante o tipo de sistema. Assim, é

essencial que sejam definidos correctamente alguns conceitos no âmbito de uma aplicação Web.

Apresenta-se então um conjunto de conceitos e a forma como estes devem ser

interpretados no contexto definido:

Desempenho: definido como a capacidade e velocidade com que um sistema recebe,

processa e responde a um pedido;

Carga: quantidade de tráfego e computação que é exigido que um servidor processe,

num determinado espaço de tempo;

Tempo de resposta: mais do que o tempo de processamento computacional (por parte

do servidor), define o tempo que passa desde que a aplicação cliente submete o pedido

até ao momento em que a respectiva resposta é apresentada no ecrã do utilizador;

Stress: condição na qual um sistema, já não é capaz de responder aos pedidos em tempo

útil ou mesmo, já não tem capacidade de resposta. Comummente, um sistema entra


21

neste estado por excesso de carga (a quantidade de actividade de processamento

computacional é superior àquela disponibilizada pelas condições de Hardware da

máquina, onde o sistema é executado).

Dadas estas definições, apresentam-se agora os tipos de testes supra referidos.

Testes de Desempenho

Têm como objectivo avaliar o desempenho de um sistema no que diz respeito à sua

capacidade de resposta e à sua disponibilidade. Trata-se então, da execução de um pedido por

parte de um cliente e avaliação do tempo de resposta. Para este tipo de teste ser realizado,

devem ser definidos alguns parâmetros, tais como, o número médio de utilizadores esperados

em simultâneo, o tempo entre pedidos distintos, o tempo máximo que é aceitável que o servidor

precise para responder a um pedido e o tempo durante o qual o teste deve ser executado. Não

faz sentido colocar uma aplicação privada que espera no máximo dez utilizadores numa situação

de atendimento de mil utilizadores, para avaliar o seu desempenho.

Em suma, os resultados devem ser mensuráveis e as condições de teste definidas dentro

de um intervalo de valores que esteja em conformidade com as condições de execução reais.

Para a execução deste tipo de teste deve ser utilizado um cliente fora da máquina em que

executa o sistema, para que a simulação das condições de utilização sejam ainda mais reais.

Para tal, existe uma grande quantidade de ferramentas, capazes de serem configuradas

(parâmetros a enviar por GET ou POST, tipo de pedido HTTP GET ou PUT, entre outras

configurações) e simularem um grande número de pedidos em simultâneo. Devem ser registadas

métricas relativas ao número de pedidos feitos, número de pedidos atendidos e não atendidos,

número de clientes em simultâneo, tempos de resposta aos pedidos e deve ser calculado o tempo

médio de resposta. É boa prática também, serem apresentados gráficos ilustrativos da evolução

do sistema ao longo do tempo, permitindo rapidamente e de forma visual estabelecer uma

relação com o número de clientes em simultâneo, o tipo de pedidos e os tempos de resposta.

Testes de Carga

Este tipo de teste é no fundo uma subcategoria do teste de Desempenho. Define no

entanto, que um sistema seja avaliado em condições de carga pré-definidas, ou seja, o sistema

será testado para uma quantidade de pedidos (pré-calculados consoante o sistema) que imponha

alguma carga significativa ao sistema. Visa avaliar o tempo necessário à execução de uma ou

mais tarefas em simultâneo. Porém, é importante definir, que a carga imposta, que devendo ser

elevada, não deve ser definida, para condições acima das quais se sabe que o sistema não tem


22

capacidade de processamento, ou nalguns casos, que não se espera que irá processar, uma vez

que, não se encontra em concordância com as condições de utilização esperadas. De resto, tudo

o que foi dito para o teste de Desempenho é também válido para o teste de Carga.

Testes de Stress

Um teste de Stress é em certa medida muito semelhante aos já descritos testes de

Desempenho e Carga. Funciona sensivelmente da mesma forma, mas o desempenho será

avaliado com o sistema a funcionar em situações de sobrecarga, muito para além do seu ponto

de ruptura, ou seja, o sistema será obrigado a responder a quantidades massivas de tráfego

HTTP e a suportar quantidades de carga muito para além das suas capacidades. Em testes de

Desempenho ou Carga, simulam-se condições de execução normais. Por sua vez, o teste de

Stress visa simular uma execução exaustiva do sistema para permitir encontrar falhas

relacionadas com o ambiente de execução (máquina executora do processo, sistema operativo,

outros exteriores ao sistema, mas que influenciam directamente o seu funcionamento). Este tipo

de testes, ao levar a máquina a bloquear, vai permitir também, avaliar a forma como o sistema

recupera, permitindo verificar se este é gracioso na forma como retorna ao funcionamento

normal (ou mesmo se o consegue fazer), ou se o sistema fica em condições vulneráveis, se

existe perda da integridade de dados ou outras condições que não permitam um correcto e

seguro funcionamento [7, 8]

.

Da descrição apresentada pode resultar alguma confusão no sentido de se pensar que,

estes testes são e fazem todos o mesmo. De certa forma sim, dado que o seu modo de execução

é semelhante. Para uma maior clarificação, pode dizer-se que os testes de Desempenho visam o

desenvolvimento de estratégias que permitam o desenvolvimento de sistemas que executem

com um nível de desempenho adequado e satisfatório. Testes de Carga, são orientados à análise

de um sistema em funcionamento normal, simulando a carga que será esperada com que o

sistema terá de lidar. Testes de Stress visam levar o sistema a parar a sua execução, por

esgotamento de recursos com vista a avaliar se a recuperação do normal funcionamento ocorre

de forma eficaz e em tempo útil, ou se, o sistema tem de ser repensado.

Para a realização deste tipo de testes, existem várias questões a considerar:

Número de utilizadores no total do sistema (quantidade total absoluta e em simultâneo);

Tempo entre acessos: instantâneos, com tempo de processamento associado a uma

máquina, ou com tempo de “pensamento”, associado à utilização de um ser humano;

Número de utilizadores por classe de funcionalidade;

Tempo entre pedidos por classe de funcionalidade;



23

A largura de banda a utilizar;

Condições gerais de Hardware do sistema que efectua o teste e do sistema a testar.

No fundo, o que se pretende enunciar com estas questões, é que estes testes exigem que

as condições de execução devem ser definidas conhecendo as características do sistema e as

condições esperadas de utilização [2]

.

Apresentados os tipos de teste que se pretende que a Plataforma seja capaz de realizar,

avança-se agora para uma análise de várias ferramentas cujas funcionalidades permitem a

execução deste tipo de testes.

Dados os tipos de operações e funcionalidades que se esperam que façam parte da

plataforma a desenvolver e também, dada a arquitectura proposta para o seu desenvolvimento

(ver capítulo Concepção da Solução), será necessária a utilização de três tipos de ferramentas

distintas. Por oposição a uma secção de comparação geral, optou-se por se agrupar as

ferramentas analisadas em três grupos distintos e efectuar as suas descrições, análise e selecção

entre as ferramentas de cada grupo.

2.2 Ferramentas de simulação do comportamento de um Browser

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;



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 modificada

caso 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


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]

.


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;


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;


Chrome

Internet Explorer; Firefox;

Opera; Safari; Chrome

Windows; Linux;

Solaris Sim * * * Não Não Sim

* Informação que não foi possível apurar

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.


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-

site scripting (XSS).


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+

BrowserClient Driver Selenium RC

Aplicação Web em teste

1 2

3

5 67

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);


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]

.

2.3 Ferramentas de Intercepção de Tráfego HTTP e Teste Fuzz

Uma vez que os requisitos do projecto definem que, seja efectuado o registo e a criação

de um histórico da actividade do Browser, foram também analisadas ferramentas de

Intercepção, Registo e Modificação do tráfego HTTP. Dado que, todo o tráfego HTTP passará

por estas ferramentas, este poderá ser manipulado. Esta característica permite que estas

ferramentas aumentem o nível e abrangência do teste Fuzz que será efectuado pelas ferramentas

de Captura e Repetição. É inclusivamente possível, que o teste de Fuzz seja efectuado sem

recurso a estas últimas.


31

Durante o estudo verificou-se que as ferramentas existentes são maioritariamente pagas

e em código fechado ou que não permitem automatismo. Optou-se por apresentar apenas as

gratuitas, aquelas que poderiam ser seleccionadas. Assim para a escolha desta ferramenta foi

dado um elevado nível de consideração ao apoio ao desenvolvedor, uma vez que a seleccionada

teria de passar por algumas modificações em termos de programação.

É também importante que a ferramenta seleccionada funcione como um servidor proxy,

garantindo assim que intercepta toda a actividade não deixando escapar, alguns pacotes, como

acontece em algumas ferramentas de análise de tráfego na rede.

Não poderia ser puramente uma ferramenta de teste Fuzz. Se assim fosse, o teste teria de

ser pré definido em relação ao sistema, e pretende-se que a ferramenta possa ser configurada

para actuar sobre todo o tráfego gerado por um determinado Web Browser.

A tabela 2 mostra então uma comparação entre as ferramentas analisadas.

Tabela 2 - Comparativo de ferramentas de intercepção de tráfego HTTP

Código

aberto Gratuito Proxy Suporte a teste Fuzz

Multi

Plataforma

Webscarab

Sim Sim Sim

Sim

(via pluggin ou ficheiro) Sim

Paros Proxy Sim Sim Sim Sim

(via aplicação auxiliar) Sim

JFuzz

Sim Sim Não Sim Sim

Wireshark

Sim Sim Não Não Sim

HTTP

Analyzer Sim Sim Não Não Sim

O HTTP Analyzer é uma ferramenta integrada no Browser para visualização do tráfego,

com funcionamento totalmente dependente do mesmo. O JFuzz revelou elevada dificuldade de

aprendizagem, pelo que, o tempo disponível para a sua análise foi gasto a perceber a

documentação, mais do que a usar a ferramenta.

O Wireshark (que é na verdade uma evolução do Etherreal) é um sniffer de rede, com

capacidade de ler todos os pacotes (TCP, UDP, DNS, etc.). Mostra a informação de forma

complexa e o seu objectivo não se enquadra com os do projecto.


32

O Paros Proxy e o Webscarab cumprem todos os requisitos. No entanto o Webscarab é

desenvolvido com base em pluggins pelo que, a sua alteração se torna simplificada. Este tipo de

abordagem permite ainda que, no momento do lançamento de uma nova versão, esta possa ser

imediatamente integrada na plataforma, instalando os pluggins responsáveis pelas alterações

feitas. Relativamente ao fuzzer que ambos disponibilizam, a documentação do Webscarab é

mais rica e mais simples de entender. Finalmente, é apresentado como sendo mais do que uma

ferramenta, como sendo uma Framework, sendo a sua alteração bem apoiada por documentação

e pelas palavras dos seus autores. Assim, o Webscarab foi a ferramenta a utilizar [20, 21, 22,23,24]

.

Este é essencialmente um servidor proxy, feito em Java, que permite interceptar tráfego

HTTP e realizar operações sobre este. Esta aplicação, possui um leque de funcionalidades

extensivo, como por exemplo, a funcionalidade de spider, efectuar sql injection, detecção de

XSS, a criação e submissão de pedidos HTTP pré configurados, entre outras. No âmbito deste

projecto assume importância, as funcionalidades que permitem realizar de forma automatizada,

modificação do tráfego HTTP com o intuito de realizar teste Fuzz e registo do tráfego

correspondente a cada pedido. O Webscarab, regista em memória todo o tráfego trocado

oferecendo de raiz, a possibilidade de gravar ficheiros com os cabeçalhos HTTP, elementos

trocados, cookies, relativamente a cada pedido interceptado.

Tem ainda a capacidade de ler e executar ficheiros Java. Esta particularidade tem as

seguintes vantagens:

Permite que a operação de Fuzz seja definida de uma forma genérica, i.e., a operação é

definida como uma acção sobre uma determinada condição ou variável (por exemplo, a

todo pedido GET ou a todo user-agent) e não sobre um pedido em específico;

Pode ser abrangido um enorme conjunto de casos de teste, neste caso, um enorme

conjunto de ficheiros de Captura e Repetição;

O facto de se tratar de um ficheiro permite que este seja gravado e mais tarde carregado

na mesma ou noutras máquinas.

A utilização de ficheiros vem trazer solução a um problema. Isto é, um outro ficheiro de

Captura e Repetição pode ser composto por, por exemplo, três cliques do rato que geram três

pedidos HTTP. Porém, a estes pedidos podem estar associados n outros pedidos, como o

descarregamento de imagens, CSS, Javascript etc. O Webscarab irá interceptar e registar tudo.

No entanto, do ponto de vista do teste, poderá apenas ser vantajoso considerar, analisar e

registar os pedidos correspondentes aos cliques do rato.


33

O ficheiro permite esta situação tornando nesse caso a actividade ao nível do proxy mais

eficiente tanto ao nível do espaço físico em disco como ao nível da velocidade de

processamento de um determinado pedido.

O que se pretende então realizar sobre o Webscarab é utilizar as suas propriedades de

scripting. O plano incide sobre a modificação do código fonte desta ferramenta, para que este

possa ser arrancado directamente com um ficheiro de teste pré definido, sem necessidade de o

colocar manualmente sobre a interface gráfica. As modificações vão mais longe ainda. Na

versão original, um ficheiro escrito com erros, pode ser carregado e unicamente após o

processamento do primeiro pedido, por observação de um comportamento diferente do esperado

(a página Web carregada não é a pedida mas sim uma gerada automaticamente pelo Webscarab

com informação sobre o erro), o erro é detectado.

Após as modificações introduzidas a esta ferramenta, é possível a avaliação do

carregamento e caso existam erros, a ferramenta é encerrada e a informação sobre o erro é

apresentada ao utilizador [22, 25, 26]

.

Finalmente, o Anexo B, Informação adicional sobre o Webscarab, (secção B.1) apresenta

uma descrição do modo de funcionamento dos ficheiros de teste, sendo ainda exposta uma lista

com as funcionalidades mais relevantes, que podem ser utilizadas na manipulação do tráfego

HTTP (para teste Fuzz).

2.4 Ferramentas de teste de Desempenho, Carga e Stress

Consta também nos requisitos da proposta, que a Plataforma deve ser capaz de realizar

testes de Desempenho, Carga e Stress. Embora as ferramentas de Captura e Repetição,

possuindo suporte a multi thread, possam realizar estes testes, as métricas que devolvem não

são as mais indicadas (é retornado o tempo de execução do método de teste e não do tempo de

processamento). Não é de todo uma falha, mas sim uma característica. Estas ferramentas estão

vocacionadas ao teste de interfaces e simulação do comportamento de um ser humano.

Além disso, existem ferramentas capazes de gerar quantidades massivas de tráfego

HTTP para realizar este tipo de testes, devolvendo no final do teste, métricas como:

Número de pedidos HTTP realizados;

Tempo de resposta por pedido;

Tempo médio de resposta (em função do configurável tempo de execução do teste);

Gráficos ilustrativos da variação do número de pedidos servidos e não servidos;

Gráficos ilustrativos da variação do tempo de resposta.


34

Estas ferramentas oferecem ainda configurações como:

Número de clientes a simular (estando este limite, nalguns casos, associados ao limite

do sistema operativo e não ao da ferramenta);

O tempo de lançamento entre clientes;

Modo de funcionamento em configuração, i.e., uma vez definidas as condições de teste,

cópias da aplicação podem estar a ser executadas em outras máquinas, recebendo o

ficheiro de configuração e executando o mesmo teste que a aplicação principal. Isto

acontece de forma automática, após uma configuração inicial e permite o aumento da

capacidade de geração de tráfego HTTP.

Finalmente, estas ferramentas não requerem uso do Browser. Dado que são autónomas,

não gastam recursos a manipular um Browser, sendo a geração massiva de tráfego HTTP feita

com mais eficácia.

Visto que o modo de execução das ferramentas analisadas é semelhante, deu-se

particular importância ao formato e às métricas dos resultados.

Como exigência central, existiu o facto da ferramenta poder ser executada em segundo

plano sem recurso a uma interface gráfica, uma vez que, nos interessa apenas o seu motor (ou

no limite a sua API), dado que esta será integrada na plataforma a desenvolver.

Embora não fosse central, para possibilitar no futuro, a extensão dos tipos de teste que a

Plataforma deve disponibilizar, teve-se algum cuidado em analisar, que protocolos mais (além

do HTTP) são suportados pelas ferramentas em análise.

Tabela 3 - Comparação das ferramentas de testes de Desempenho, Carga e Stress

Multi

Plataforma Gratuito

Código

Aberto

Formato

Resultados

Outros

Protocolos

Batch

mode

Apache

Jmeter Sim Sim Sim Ficheiros Sim Sim

Pylot Sim Sim Sim Ficheiros e

gráficos HTML Não Sim

Load

Runner Não Não Não

Gráficos, tabelas

em HTML Sim Não

Grinder Sim Sim Sim Ficheiros Sim Sim


35

A tabela 3 mostra uma comparação destas ferramentas. É possível observar que o Load

Runner não cumpre todos os requisitos, pelo que foi retirado da lista de possibilidades. O Jmeter

apesar de cumprir os requisitos, também foi descartado, dada a sua complexidade e elevada

curva de aprendizagem. Esta ferramenta é bastante comentada como sendo complexa de

aprender, pelo que, atendendo às questões de tempo associadas a este projecto, é descartada.

O Pylot, escrito em Python tem como único contra suportar apenas HTTP e HTTPS

(HTTPS é o mesmo que HTTP mas representando uma ligação do tipo segura). Ao Python, está

associada uma API, que permite o desenvolvimento de funcionalidades relativas a pedidos

HTTP, logo, caso a ferramenta a seleccionar exija modificações, o Pylot tem mais este ponto a

seu favor. Os formatos nos quais os resultados são apresentados (em ficheiros HTML) e a baixa

curva de aprendizagem tornam o Pylot uma ferramenta bastante apta para integrar a Plataforma,

pois é simples e os resultados são produzidos num formato que directamente pode ser usado

para apresentar ao utilizador.

Apesar de todas as vantagens do Pylot, o Grinder cumpre todos os requisitos e fornece

suporte a outros protocolos o que potencia e facilita a extensão futura das funcionalidades da

Plataforma. Porém, o facto de necessitar do uso de uma consola Java e o formato dos seus

resultados não serem em HTML levam a que fique atrás do Pylot, uma vez que, a sua vantagem

(suportar outros protocolos) não é de todo uma prioridade do projecto.

Já durante a ocorrência da fase de implementação deste projecto, foi lançada uma

ferramenta pelo mesmo autor do Pylot. Esta denomina-se Multi-Mechanize. Em termos

funcionais, disponibiliza e comporta-se exactamente como o Pylot, porém os ficheiros de teste

são especificados numa linguagem de programação (Python) e não em XML (que apenas

permite definir um conjunto de regras).

Assim, é possível que os testes simulem comportamentos do utilizador (por exemplo,

tempo de espera variável entre transacções) ou acções sobre os pedidos (modificação dos

pedidos em Run time ou mesmo avaliação do código de resposta do servidor.)

Dados estes motivos, o Pylot inicialmente escolhido, foi substituído pelo Multi-

Mechanize [27, 29, 29, 30, 31, 32, 33]

.

Esta ferramenta só requer uma modificação no código fonte. A exportação de resultados

principais, para um ficheiro cujo formato permita o seu envio de forma eficiente pela rede.

2.5 Tecnologias adicionais

2.5.1Integração na Plataforma


36

Ant

Quando um ficheiro de teste é escrito, este tem de ser compilado antes de ser executado.

Como estes serão escritos em Java, este procedimento poderia ser realizado com recurso ao

Javac (compilador de Java). No entanto, de cada vez que surja um novo ficheiro de teste, será

necessário escrever e enviar para a linha de comandos, o comando respectivo. Caso existam

dependências, o referido comando sobe em complexidade. Na presença de uma bateria de testes,

composta por vários ficheiros, esta situação agrava-se ainda mais.

O Ant permite resolver todas estas questões. É na verdade, uma aplicação escrita em

Java, multi-plataforma que permite gerar instruções de forma automática para a linha de

comandos. A Plataforma desenvolvida, quando na presença de novos ficheiros, executa a sua

compilação com recurso a esta ferramenta, reportando o sucesso ou falha (presença de erros) de

forma totalmente automatizada e transparente para o utilizador [34]

.

TestNG

O TestNG é uma ferramenta de geração e apresentação dos resultados de teste. Para este

projecto foi seleccionado o TestNG, pois das duas opções sugeridas pelos desenvolvedores do

Selenium (JUnit e TestNG), este, apesar de ser mais complexo, é aquele que disponibiliza mais

funcionalidades, como por exemplo, a geração do relatório de teste em formato XML que será

extremamente útil quando a Plataforma for utilizada em modo remoto.

Além disso, o TestNG possui ainda suporte à escrita de testes unitários, pelo que a sua

utilização, permitiu de forma directa cumprir um dos objectivos adicionais [35]

.

2.5.2 Desenvolvimento Web

Desenvolvimento no lado do servidor

Uma vez que faz parte dos requisitos deste projecto, o desenvolvimento de um centro de

controlo e gestão do teste, (sendo este do tipo aplicação Web), para controlo de várias instâncias

da Plataforma de teste, para este desenvolvimento será utilizada a linguagem de programação

PHP: Hypertext Preprocessor (PHP). Não será um desenvolvimento de raiz, irá ser utilizada a

Zend Framework como base. A escolha recai sobre esta Framework, em detrimento de todas as

outras existentes, pelo motivo ser a utilizada na Auditmark.

A Auditmark não escolheu esta Framework de forma aleatória. De facto, para a

selecção de uma Framework, foi efectuada uma tese na Faculdade de Engenharia da


37

Universidade do Porto. Neste sentido vamos utilizar a definição de Framework utilizada nesse

mesmo documento:

“Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para

um domínio de um subsistema da aplicação.”

Existe nesse mesmo documento uma comparação entre várias Frameworks de PHP,

onde se conclui que apesar de a Zend apresentar uma curva de aprendizagem superior é a que

reúne maior agrupamento de funcionalidades necessárias ao tipo de desenvolvimento Web, a

que a empresa se dedica, nomeadamente o suporte a:

Templates;

Caching;

Validation;

AJAX;

Auth Module.

Finalmente, esta é uma Framework que implementa o padrão de desenho Model-View-

Controller (MVC), Modelos-Vistas-Controladores.

A figura 4 mostra a arquitectura deste padrão.

Figura 4 - Modelo MVC

De notar na figura 4, que o cliente interage somente com o controlador, não tendo nunca

contacto com os modelos, sendo estes os que realizam o processamento privado de acesso à

Base de Dados. As vistas representam o que será enviado para o cliente (HTML, CSS,

Javascript, etc.). Portanto, os pedidos HTTP são recebidos pelo controlador, que caso necessite

http://www.google.com/url?sa=t&source=web&ct=res&cd=7&ved=0CCAQFjAG&url=http%3A%2F%2Footips.org%2Fmvc-pattern.html&rct=j&q=mvc&ei=OtBhS8-KLNS5jAfyg9DBDA&usg=AFQjCNGdWqOG6K3bhiIf0GtSLVAiFoMgWQ

http://www.google.com/url?sa=t&source=web&ct=res&cd=7&ved=0CCAQFjAG&url=http%3A%2F%2Footips.org%2Fmvc-pattern.html&rct=j&q=mvc&ei=OtBhS8-KLNS5jAfyg9DBDA&usg=AFQjCNGdWqOG6K3bhiIf0GtSLVAiFoMgWQ


38

de aceder à Base de Dados ou realizar processamento privado, instancia um modelo para o

efeito, ficando o resto a cargo do controlador. Os dados dai resultantes, (ou caso não seja

necessário ir ao modelo, os dados resultantes do processamento somente do controlador), são

usados para criar uma vista, que por sua vez o controlador envia para o cliente. Uma das

grandes vantagens deste padrão, é que a ligação a Base de Dados só existe no Modelo, logo

apenas enquanto este está instanciado, não tendo nunca ligação directa com o cliente [36]

.

Desenvolvimento para o lado do cliente

O sistema de gestão e controlo a desenvolver terá de disponibilizar uma interface Web,

para interacção com o utilizador.

Serão utilizadas as seguintes tecnologias para seu desenvolvimento:

HTML;

Cascade Style Sheets (CSS);

Javascript;

Jquery.

As duas primeiras são as linguagens que tipicamente se utilizam para a estruturação da

página e para a formatação de estilos, respectivamente. O Javascript é uma linguagem de

programação, que permite o desenvolvimento de páginas dinâmicas, realizando acções do lado

do cliente, dispensando, quando possível, o acesso ao servidor (por exemplo, validação de dados

de formulários, aviso de erros de ligação, etc.). Torna assim, essas acções mais rápidas estando

estas disponíveis mais cedo para o utilizador libertando ainda, carga de processamento ao

servidor.

Finalmente, a Jquery é uma biblioteca de Javascript, que disponibiliza uma enormidade

de funcionalidades para criação de objectos (tabelas dinâmicas, calendários, animações,

apresentações interactivas) que farão parte da página a mostrar ao cliente. Pelos seus

desenvolvedores pode ser definida como:

“jQuery é uma rápida e concisa Biblioteca Javascript que simplifica a interacção com HTML,

a manipulação de eventos, animação e interacções de Ajax para desenvolvimento Web rápida.

jQuery é projectada para mudar a forma como se escreve Javascript.”

A própria definição diz tudo, é porém relevante acrescentar que, esta biblioteca é

independente do Browser, permitindo assim poupar o tempo de desenvolvimento necessário à

criação de várias páginas com exactamente o mesmo conteúdo, mas com constituições


39

diferentes, para que funcionem correctamente em todos os Browsers (não existe ainda uma

norma sobre a qual se guiem todos os desenvolvimentos dos diversos Browsers, pelo que

porções de código igual têm resultados de saída diferentes disponíveis) [37]

.


40

41

Capítulo 3

Concepção da Solução

Este capítulo tem como propósito demonstrar a solução concebida. É apresentada a

Plataforma, sendo expostos todos os seus componentes. Estes são explicados e descritos tanto

ao nível da sua arquitectura lógica como física, sendo ainda abordada a estrutura funcional.

A Plataforma desenvolvida é composta por dois módulos principais, um para a

execução de testes e um outro que constitui uma interface Web, para controlo remoto de uma ou

mais instâncias da Plataforma.

Este capítulo começa por abordar o Módulo de Execução de Testes (MET), sendo

descritas a sua estrutura e funcionalidades, sendo ainda demonstrado como foram integradas as

ferramentas descritas no capítulo anterior, de forma a ser possível executar as técnicas e

metodologias de teste enunciadas nesse mesmo capítulo. Seguidamente é feito o mesmo tipo de

descrição para a interface de controlo, o Centro de Controlo Remoto (CCR).

Ao nível da descrição, fecha este capítulo uma explicação de como pode ser utilizada a

solução desenvolvida para criar uma rede de execução de testes a aplicações Web.

Como conclusão, este capítulo é encerrado com uma análise, que pode ser interpretada,

como a resposta à pergunta que aqui se deixa em aberto: Porquê utilizar esta solução?

3.1 Arquitectura e funcionamento do Módulo de Execução de Testes

O Módulo de Execução de Testes é a junção entre as ferramentas previamente

seleccionadas, um sistema de ficheiros com vista ao armazenamento de resultados de teste e

uma aplicação a que se deu o nome de Centro de Comando Local (CCL).

O CCL é um programa escrito em linguagem Java, apoiado por alguns scripts escritos

em Shell script (para ambientes Unix) e um pequeno módulo escrito em C++ (para ambientes


42

Windows). O propósito desta aplicação, é permitir ao executante do teste, uma total abstracção e

consequente total automatismo, sobre todas as questões relacionadas com a configuração

(ficheiros dinâmicos necessários e parâmetros de lançamento em execução), activação,

desactivação e tratamento de erros sobre as ferramentas de execução de teste.

Esta aplicação permite assim, que a preocupação a ter seja apenas a de conceber os

ficheiros de teste e escrever um ficheiro de configuração, extremamente simples, cuja estrutura,

é uma sequência de linhas com o seguinte conteúdo:

Tipo de teste – ficheiro de teste – Fuzz <se aplicável>

No caso de utilização pela interface de controlo remoto, este ficheiro de configuração é

desnecessário.

O CCL realiza uma série de operações necessárias à execução do teste e ao

armazenamento de resultados. Para se perceber estas acções em detalhe, pode ser consultado, o

subcapítulo 3.5.

A figura 5 representa o diagrama de classes em Unified Modeling Language (UML).

Figura 5 - Diagrama UML de classes do Centro de Comando Local.

É importante destacar as seguintes classes, dado o comportamento que estas

implementam:


43

LocalCommandCenter: implementa todo o comando da Plataforma. Recebe todos os

comandos do utilizador (tanto de via local como remota), despoletando a seguir todas as

operações de configuração das ferramentas, geração automática de ficheiros adicionais de

configuração e linhas de invocação, início e monitorização da actividade de teste, encerramento

(retiro de execução) das ferramentas de teste e finalmente, despoleta a organização de resultados

e envio para o centro de controlo remoto (se aplicável).

CPTestExecution e PLSTestExecution: são um ponto intermédio entre as instruções

de formato genérico (ver figuras 16 e 17 e a sua descrição no subcapítulo Rede de Execução de

Testes) recebidas pela classe LocalCommandCenter e a sintaxe das ferramentas a ser

utilizadas. Despoleta também configurações das ferramentas.

ProcessLauncher: a grande importância desta classe é a sua capacidade de detectar o

ambiente de execução (Sistema Operativo) e gerar as configurações necessárias de acordo com

este último. É depois responsável pelas actividades de lançamento em execução, monitorização

e encerramento das ferramentas de teste e dos módulos auxiliares (Ant e TestNG). Estas

actividades são feitas com recurso a Shell script em Ambiente Unix e a um módulo em C++

(que por sua vez utiliza a API do Windows) em Ambiente Windows. Esta abordagem permite

que a monitorização e o retiro de execução sejam feitos da forma mais eficiente consoante o

Sistema Operativo em execução.

JavaToPhpComunication: Quando a Plataforma é executada em modo remoto, é

necessário enviar, via rede (ou Internet), os resultados dos testes para o Centro de Controlo

Remoto. Trata-se do envio de dados e ficheiros XML via protocolo HTTP, mas também,

ficheiros de imagem (gráficos de evolução de tempos de resposta, no caso dos testes não

funcionais) através de um tipo especial de comunicação por socket. Esta classe implementa e

controla todas as referidas funções.

Ao nível físico, a Plataforma é um conjunto de directórios, dos quais, existem quatro de

relevante importância. O seu conteúdo é agora descrito.

Executables: Contém todos os ficheiros necessários à execução do CCL. Como

subdirectório existem dois pontos onde são registados e armazenados, todos os dados de saída

de formato texto, quer do CCL, quer das ferramentas e módulos auxiliares.


44

Tools: a tradução do próprio nome é auto explicativo. Este directório contém as

ferramentas de execução de teste e todos os ficheiros, dependências e bibliotecas adicionais para

a execução das mesmas.

Testsuites: contém (devidamente organizado por tipo) todos os ficheiros de teste e

adicionais para os diferentes tipos de teste. Neste, foi criado ainda um subdirectório,

testsessions, onde podem ser armazenados (não sendo obrigatório), todos os ficheiros (do tipo

já descrito), correspondendo a execução de sessões de teste no modo local.

Results: é neste directório que todos os ficheiros (XML, pngs, hmtl, texto) com

resultados de teste são armazenados. Todos são organizados pelos seguintes pontos: tipo de

teste, nome do teste, date e hora de execução. Para os testes de Captura e Repetição e testes

Fuzz são ainda divididos por módulo de execução sequencial ou simultâneo. No caso remoto, é

acrescida a informação sobre o identificador remoto do teste.

3.2 Operações de teste suportadas

Uma vez que o MET é o único responsável pela execução do teste, podendo mesmo ser

usado sem recurso ao CCR, optou-se por descrever as operações suportadas antes da

apresentação deste último.

Neste subcapítulo, serão usados dois termos que, para que não haja ambiguidade, se

passam a explicar:

Sistema em teste: vem do termo técnico Inglês, System Under Test (SUT), como é

comummente designado. Designa o sistema que é alvo de um teste, isto é, o sistema que

está a ser avaliado;

Máquina de execução do teste: designa a máquina que possui as ferramentas utilizadas

para efectuar o teste ao SUT.


45

Figura 6- Componentes de um teste de Captura e Repetição

A figura 6 apresenta uma operação de Captura e Repetição. Nesta primeira fase, existem

apenas duas máquinas intervenientes e duas aplicações. A máquina de execução com a

ferramenta de Captura e Repetição e o Sistema em teste.

Figura 7 - Componentes de um teste de Fuzz

A figura 7 mostra como a Plataforma permitirá juntar simultaneamente um teste de

Captura e Repetição com um teste de Fuzz. Enquanto a primeira ferramenta manipula um

Browser, gerando assim sequências de acções de utilizador que resultam em pedidos HTTP, a

segunda ferramenta, intercepta e regista todos os pedidos e respostas HTTP. Ao fazer esta

intercepção, o tráfego pode ser manipulado e alterado, sendo acrescentados e modificados

valores e/ou tipos de valores. Também é possível fazer alterações ao nível dos cabeçalhos

HTTP. A actividade da segunda ferramenta resulta assim num teste Fuzz, podendo estar ou não,

na mesma máquina onde se encontra a ferramenta de Captura e Repetição.


46

Figura 8 - Componentes de um teste Fuzz com fonte genérica de pedidos HTTP.

A figura 8 exemplifica praticamente o mesmo que a figura 7. A diferença reside na

fonte dos pedidos HTTP. Com esta figura, pretende-se demonstrar como a ferramenta de

intercepção, registo e manipulação de tráfego HTTP, pode ser usada sobre qualquer fonte, desde

uma utilização manual por um utilizador humano, ou sobre pedidos HTTP gerados por uma

qualquer aplicação a executar no Browser, como aplicações Javascript, pedidos do tipo Ajax, os

JIC (ver capítulo Caso de Estudo), etc.

Esta forma funciona apenas no modo de execução local, uma vez que pressupõe uma

utilização manual do Browser.

Sobre estes testes, resta referir ainda, que na presença de vários ficheiros de teste, cada

um corresponderá a uma instância de um Browser em execução. Estes podem ser executados de

forma sequencial ou em modo simultâneo. Pela interface (ou ficheiro de configuração), pode ser

indicado o número máximo de Threads em simultâneo, uma vez que este varia consoante as

características da máquina.


47

Figura 9 - Componentes envolvidos num teste Desempenho, Carga ou Stress

A figura 9 apresenta o esquema de funcionamento de um teste de Desempenho, Carga

ou Stress. Uma máquina gera quantidades massivas de tráfego HTTP, desta vez de forma

independente do Browser, e envia-o para o sistema em teste. Podem como já referido, ser

gerados pedidos em simultâneo, simulando assim vários clientes HTTP. Apesar de na figura

estar apenas uma máquina realizadora de teste, estes testes, como já descrito também, podem ser

realizados com várias máquinas em simultâneo.

3.3 Arquitectura e funcionamento do Centro de Controlo Remoto

O Centro de Controlo Remoto é composto por quatro módulos: interface gráfica,

acessível através de um qualquer Web Browser; aplicação desenvolvida em Zend PHP, capaz de

receber as definições de teste da interface gráfica e despoletar a execução num MET; Uma

estrutura de directórios (semelhante à do MET) para armazenamento de todos os ficheiros com

resultados de teste; Base de Dados (PostgreSQL) que armazena todos os dados relativos às

máquinas disponíveis para executar testes e todos os dados sobre todas as sessões de teste

efectuados (configurações e resultados).

Para a visualização da interface gráfica supra referida, sugere-se a utilização do Mozzila

Firefox. Como referido no capítulo 2, Metodologias e Ferramentas de Teste a Aplicações Web,

o IDE está apenas disponível para este Browser. Logo, somente assim é possível ter acesso em

simultâneo, à interface da Plataforma e ao IDE do Selenium.

A figura 10 apresenta a estrutura do CCR, acompanhada de uma utilização. Admita-se

neste exemplo que não existem erros, nem nos dados submetidos pelo utilizador, nem nos

ficheiros de teste e nem na comunicação com o MET (de realçar porém que todas estas e outras


48

situações de erro estão previstas). A figura 11 mostra a interface que poderia ser utilizada na

acção da figura 10.

Módulo de

Execução de Teste

PostgreSQL

Interface Gráfica Módulo Zend PHP

Ficheiros de resultados

1

6

2 3

4

5

Figura 10 - Arquitectura física do Centro de Controlo Remoto

Os pontos numerados da figura 10 têm os seguintes significados:

1. O utilizador configura a sessão de teste numa página e submete quais os ficheiros de

teste a incluir;

2. Após a validação de dados, o CCR envia os ficheiros de teste e as configurações

para o MET;

3. O MET inicia, executa e termina o teste. Estrutura os resultados. Envia-os para o

CCR;

4. O CCR recebe os dados, organiza-os na estrutura de ficheiros de resultados, efectua

as leituras e as operações de filtragem necessárias;

5. São inseridos na Base de Dados os dados actualizados de configuração da sessão e

os resultados dos testes envolventes;

6. O utilizador é informado na interface que todas as máquinas seleccionadas

terminaram todos os testes. É apresentada automaticamente uma hiperligação para a

página de resultados de cada sessão.


49

Figura 11 - Interface gráfica para Browser Testing.

O CCR disponibiliza também funcionalidades ao nível de monitorização e controlo do

estado das máquinas que albergam o MET. Se estas estão activas e em espera de instruções, se

estão em execução de teste, se foram desligadas ou se não estão a responder. Como

funcionalidade extra foi desenvolvido o controlo remoto do estado do MET. É possível

simplesmente parar um teste ou encerrar por completo o MET. A funcionalidade (também extra

não prevista nos requisitos) de início remoto do MET, está já preparada no CCR e a sua forma

de implementação está documentada no capítulo 5, Conclusões e Trabalho Futuro.


50

Estão ainda presentes funcionalidades de consulta, análise e comparação de resultados

de teste.

Armazenamento e apresentação de resultados

Como já referido, embora não fizesse parte dos objectivos do projecto, optou-se por

desenvolver um módulo de armazenamento e apresentação de resultados.

Assim, o CCR sempre que dá início ou é terminada uma sessão de teste, comunica com

uma Base de Dados, armazenando todas as configurações da sessão de teste, o estado final (se o

teste foi executado ou não) e caso o teste tenha sido executado, são armazenados ainda os dados

relativamente à passagem ou falha, tempos de execução e mensagens adicionais geradas pelo

programa executor de teste.

Além da Base de Dados, existe uma estrutura de directórios, tanto no CCR como em

cada MET, onde são armazenados todos os ficheiros com resultados de testes. Estes são

devidamente estruturados e armazenados por data e hora, todos os ficheiros contendo os

resultados da execução do teste.

A figura 12 representa uma das interfaces disponíveis para pesquisa de resultados.

Figura 12 - Interface gráfica para pesquisa de resultados de Browser Testing.


51

A figura 12 refere-se aos testes de Captura e Repetição e aos testes de Fuzz. Para a

Plataforma, estes testes são definidos como “Browser testing”. Isto para permitir uma maior

facilidade de utilização, e uma maior abstracção das operações de configuração das ferramentas

de teste.

Não faria sentido, apresentar e descrever a estrutura da Base de Dados. Em detrimento

desta situação apresenta-se a informação armazenada por sessão de teste. Entenda-se uma

sessão de teste como a execução de uma série de testes num ou mais ficheiros, cada um deles

com um ou mais testes, numa determinada máquina com um conjunto de configurações. É ainda

apresentada uma explicação de como são armazenados os resultados por cada um dos testes de

cada sessão.

Testes de Captura e Repetição e Testes de Fuzz

Por cada sessão são armazenados os seguintes parâmetros:

Ip da máquina que realizou o teste;

Sistema operativo que a máquina estava a executar quando realizou este teste;

Data em que se deu inicio a este teste;

Hora em que se deu início a este teste;

Descrição textual do teste;

Se é teste Fuzz e respectivo ficheiro;

Lista de ficheiros adicionais para o teste;

Estado final da sessão (executada ou não).

Para cada ficheiro de teste da sessão, são armazenados os seguintes dados:

Nome do ficheiro;

Browser a ser utilizado;

Nome de cada método do ficheiro;

Tempo de execução de cada método;

Mensagem gerada pela aplicação (por cada método);

Estado final: passagem ou falha.


52

Testes de Desempenho, Carga e Stress

Tal como no caso anterior, também neste tipo de testes existe o conceito de sessão de teste.

Assim para cada sessão são armazenados os seguintes dados:

Ip da máquina que realizou o teste;

Descrição textual do teste;

Data em que se deu início a este teste;

Hora em que se deu início a este teste;

Estado final (se executado ou não).

Para cada ficheiro de teste a informação armazenada correspondente é:

Número de clientes simulados neste teste;

Rampup definido (tempo máximo para colocar todos os clientes em execução);

Intervalo de tempo definido para análise de resultados;

Tempo definido para a execução do teste;

Gráfico de pontos representativo do tempo de resposta de todas as transacções;

Gráfico representativo da evolução do tempo médio de resposta;

Gráfico representativo do número de pedidos servidos com sucesso por segundo;

Ficheiro HTML gerado pelo Multi-Mechanize;

Número total de transacções que foram realizadas;

Número total de pedidos não respondidos ou com erro;

Tempo de resposta do pedido servido mais rapidamente;

Tempo de resposta do pedido servido mais lentamente;

Tempo médio de resposta.

A título de exemplo, apresenta-se aqui a figura 13, como forma de demonstrar um possível

resultado de pesquisa por sessões de teste. Já a figura 14, representa, os detalhes de uma sessão

de teste. Esta seria obtida por clique do rato na hiperligação correspondente a essa sessão (o

clique seria feito onde se localiza o cursor na figura 13).


53

A figura 13 permite ainda ver uma utilização das funcionalidades da Jquery. No caso de

uma pesquisa filtrada por datas, a aplicação DatePicker, serve como modo de selecção das

datas.

Como a figura também demonstra, foi desenvolvido um sistema de paginação, no qual,

são apresentados n resultados de cada vez, sendo possível pesquisar os restantes pelo clique em

more (presente no ecrã) ou less.

Para o caso dos testes do tipo “Browser testing”, a pesquisa contempla ainda os

seguintes filtros (opções visíveis na figura 12):

Apenas Fuzz; Apenas Não Fuzz; Todos;

Apenas Com Erros, Apenas Sem Erros; Todos.

Figura 13 - Resultados de sessões de teste de Performance, Carga e Stress.


54

Fig

Figura 14 - Resultados detalhados de uma sessão de teste de Performance, Carga e Stress.


55

3.4 Rede de Execução de Testes

A figura 15 representa a rede de execução de testes que é possível criar instalando a

Plataforma em diversas máquinas. Uma máquina central possui o CCR enquanto o MET será

instalado em n máquinas.

A figura 16 representa a junção entre os dois módulos constituintes da Plataforma. O

CCR comanda o MET por via remota. Nesta altura, reforçado pela observação da figura 16,

pode surgir uma questão: Porque não comunica o CCR directamente com as ferramentas de

teste?

Ferramentas de teste

Módulo de Execução de Teste

Centro de comando local

Captura e RepetiçãoInterceptor HTTP

FUZZERPerformance / Load / Stress

Centro de controlo remoto

Figura 16 - Junção entre o MET e o CCR

Figura 15 - Rede de execução de testes


56

Existem determinadas mensagens que serão trocadas entre o centro de controlo e as

ferramentas de teste, que são genéricas e independentes da ferramenta. Mensagens como por

exemplo (apresentadas em linguagem natural mas que devem ser interpretadas como a troca de

comandos informáticos), “iniciar teste”, “pausar teste”, “iniciar teste com o ficheiro

exemplo.java”, “executar teste de carga simulando 100 clientes”, etc. Assim, tendo uma

aplicação capaz de receber estas mensagens e traduzi-las para a linguagem da ferramenta em

questão, permite-nos que numa hipotética troca de ferramenta, esta possa ser feita sem

necessidade de alterar o CCR. Além disso, o CCR é apenas uma máquina, que pode comandar

várias máquinas de teste. Esta abordagem permite que a carga de processamento relativamente

ao comando das ferramentas e recolha dos seus resultados seja parcialmente distribuída pelos

vários MET.

Além disso, é pouco provável que esses tipos de mensagens genéricas variem a curto,

ou mesmo médio prazo, uma vez que muitas delas estão associadas, mais do que à ferramenta,

aos princípios de funcionamento dos testes que estas realizam. Por outro lado, completamente

oposto, é altamente provável que muito rapidamente se encontrem ferramentas que melhor

respondam aos requisitos (lançamento de novas versões das ferramentas ou lançamento de

novas ferramentas no mercado inexistentes à data de escrita deste documento) e que portanto,

seja necessário integrar uma nova ferramenta com uma nova forma de comunicação.

Resumidamente, esta abordagem permitiu desenvolver um centro de controlo e gestão,

estável que não necessite de modificações a médio prazo, permitindo alguma facilidade na

actualização ou mesmo troca das ferramentas.

Finalmente, existe ainda uma última vantagem. Caso se verifique a utilização da

Plataforma de teste em apenas uma máquina, não há necessidade de a controlar via Internet.

Haveria gastos de tempo e as vantagens trazidas pelas aplicações Web não se verificariam face

aos seus problemas associados (latência de rede ou indisponibilidade do serviço, por exemplo).

De qualquer forma, não faria sentido controlar remotamente uma aplicação local à

máquina onde o executante dos testes se encontre trabalhar. Assim, o MET poderá oferecer uma

interface gráfica de controlo local. Tal como referido no capítulo 1, Introdução, subcapítulo

Objectivos, esta questão, não pertencia aos requisitos deste projecto. Porém, como a arquitectura

proposta permite este desenvolvimento, tomou-se esta questão como objectivo. Por questões de

tempo e por não ser prioritário, a interface de controlo local desenvolvida opera apenas em

modo de texto.

3.5 Porquê utilizar esta Plataforma?

Poderão ser colocadas algumas questões. Porquê utilizar esta Plataforma? Qual o grande

contributo da sua utilização face ao uso singular das ferramentas que esta controla? Qual a

vantagem para a empresa que a utilize?


57

A resposta a estas questões encontra-se essencialmente em três pontos:

Automatização do processo inerente ao teste;

Abstracção de configurações referentes às ferramentas de teste;

Controlo de várias máquinas de teste em simultâneo de forma remota.

Para se perceber em detalhe o que os três anteriores tópicos enunciam, olhemos para os

fluxogramas das figuras 17 e 18.

Criar ficheiros de

teste

Carregar ficheiros

de teste

Seleccionar

máquinas

Seleccionar

ficheiros de teste

Seleccionar modo

de execução

(sequencial ou

simultâneo)

Clicar em iniciar

testeErros

Aguardar a

execução de teste

Ver resultados Corrigir errosCarregar ficheiros

de teste

N

S

Figura 17 - Execução de teste e armazenamento de resultados de forma automática.

Tanto a figura 17 como a figura 18 representam o processo associado ao uso das

ferramentas, para se conseguir realizar todas as operações de teste que estas possibilitam. O

exemplo é referente aos testes de Captura e Repetição e aos testes Fuzz. A figura 17 representa o

uso das ferramentas de forma integrada, automatizada e geridas pelo CCL. A figura 18

representa todos os passos necessários ao uso destas ferramentas de forma manual. Como é

visível, existe uma redução drástica em termos do número de passos a dar e obviamente da

morosidade associada ao processo de configuração do teste.

De notar ainda na figura 17, que as acções “carregar ficheiro de teste”, “seleccionar

máquinas”, “seleccionar ficheiros”, “seleccionar modo de execução” e “iniciar teste”,

correspondem a cliques do rato numa única página Web. De notar também, que ao serem

seleccionados ficheiros para teste Fuzz, o sistema reconhece automaticamente que se trata de um

teste deste tipo e encarrega-se automaticamente das configurações adicionais.

Finalmente, caso seja necessário a execução de vários testes em várias máquinas em

simultâneo, o processo da figura 18 teria de ser executado em cada máquina. A Plataforma é

responsável por receber as instruções do utilizador num único ponto (a interface) e despoletar

todas as acções necessárias nas várias máquinas.


58

Criar ficheiro de teste

Compilar

Erros

Activar Selenium Server

Aguardar execução de teste

Teste de Fuzz

Activar Selenium Server

Criar directório para armazenamento

Copiar conteúdo para directório criado

Teste de Fuzz

Desactivar Selenium Server

N

N

N

Activar Webscarab Carregar ficheiro para Fuzz

Erros

Corrigir erros de script Fuzz

N

S

S

Corrigir erros de ficheiro de captura e

repetição

S

Desactivar WebscarabS

Iniciar teste sequencial

(Client Libraries)

Activar Selenium server com

definições do proxy correspondente

Criar ficheiro XML TestNG

(configuração para todos os ficheiros

de teste)

Execução sequencial

Criar ficheiro XML TestNG

(configuração para um ficheiro de

teste)

Iniciar teste

(Client Libraries)

Todos em execução

N

N

N

S

S

Figura 18 - Execução de teste e armazenamento de resultados de forma manual.

59

Capítulo 4

Caso de Estudo

Este capítulo tem como objectivo demonstrar como pode ser utilizada a Plataforma,

para a realização de testes a aplicações Web.

O objectivo supra descrito divide-se em dois. Como as ferramentas utilizadas são de

código aberto e gratuitas, seguem portanto a filosofia deste tipo de produtos: são de livre

utilização e modificação mas são apresentados ao público sem qualquer garantia de

funcionamento. Neste sentido, o primeiro objectivo foi a verificação de que, os resultados

retornados pelas mesmas se encontram de acordo tanto com os dados esperados atendendo aos

princípios teóricos da computação, como com os dados previamente conhecidos da empresa.

Todas as funcionalidades da Plataforma foram utilizadas pelo menos uma vez.

O capítulo encontra-se dividido em quatro partes. No primeiro subcapítulo, Sistema em

teste, é explicado o Auditservice, o sistema da Auditmark, que representa a aplicação a ser

testada. Segue-se o subcapítulo Plano de testes, com o propósito de apresentar claramente para

cada tipo de teste suportado, o que pretende testar, quais as técnicas envolvidas e, no caso

particular da empresa, que conhecimento permite ter a cerca do sistema.

O terceiro subcapítulo serve para demonstrar os resultados obtidos. O capítulo encerra

com um pequena conclusão sobre a actividade de testes.

4.1 Sistema em teste

4.1.1 Auditservice

O Auditservice é um sistema complexo, distribuído, com vários módulos entre o seu

Front-End onde são atendidos os pedidos HTTP e o Back-End onde os dados resultantes do

Caso de Estudo

60

processamento são armazenados. A figura 19 representa o Auditservice visto de uma perspectiva

extremamente simplificada. E porquê? Os testes que serão feitos usando a Plataforma

desenvolvida requerem apenas que conheçamos e consideremos o Front-End.

Figura 19- Arquitectura do AuditService.

O Front-End é independente de todos os restantes módulos. Quando os dados são

recebidos neste, são armazenados em ficheiros especiais (denominados SDC files) sob a forma

de conteúdo binário. Só mais tarde os restantes módulos irão processar a informação contida

nestes ficheiros. Desta forma, o funcionamento dos restantes módulos do Auditservice torna-se

irrelevante e a sua consideração não é necessária.

No fundo, iremos considerar uma aplicação Web, que recebe pedidos HTTP e regista os

respectivos conteúdos de todos os pedidos recebidos em ficheiros.

Este Front-End foi concebido para receber os pedidos, vindo de uma aplicação cliente,

que é executada em determinadas máquinas, nas quais existe um Browser através do qual se

acedeu à página Web, que se encontra a ser auditada. Esta aplicação, ou ao conjunto de pedidos

que esta realiza, dá-se o nome de Javascript Interaction Code, ou simplesmente JIC (como

comummente esta tecnologia é referida em ambiente empresarial). Esta será a designação

adoptada neste documento.

Caso de Estudo

61

4.1.2 Javascript Interaction Code

O objectivo de um JIC é permitir ao sistema de auditoria da Auditmark, detectar se os

acessos à aplicação Web a ser auditada, são acessos fraudulentos ou genuínos e se são

efectuados por um utilizador humano ou se são simulados por uma máquina.

Um JIC funciona da seguinte forma: um qualquer utilizador realiza um qualquer acesso

a uma página na Web, na qual se encontra um banner publicitário. Neste pode ser efectuado um

clique com o rato, criando um redireccionamento para uma qualquer página Web de

publicidade. Esta página corresponde à aplicação que se encontra a ser auditada.

Com este redireccionamento, a aplicação cliente recebe algum código Javascript. Esse

código realiza algum tipo de processamento e envia dados para o servidor da Auditmark

recebendo como resposta (entre outros elementos de segurança) um novo código Javascript. É

efectuado um outro processamento, enviando novamente os resultados para o servidor da

Auditmark, recebendo como resposta um novo código Javascript. Esta acção ocorre n vezes,

consoante as configurações da máquina cliente.

A seguinte lista, mostra alguns dos testes que o Javascript efectua na máquina cliente,

cujos resultados são depois codificados e enviados para o servidor da Auditmark (O conjunto

total de testes ascende a trezentos. A cada ronda são enviados tantos resultados quantos os

permitidos pelo tamanho máximo do URL, cerca de 2000 caracteres na maioria dos Browsers):

IP da máquina cliente;

Tipos de letra suportados;

Tamanho do ecrã;

Resolução vertical do ecrã;

Resolução horizontal do ecrã;

Estado (activo ou desactivo) de cookies;

Pluggins ou addons instalados no Browser;

Sistema Operativo da máquina cliente;

Resultados de testes sobre o documento DOM;

Suporte a flash activo ou não;

Linguagem do Browser;

Browser onde se encontra o JIC a ser executado.

Caso de Estudo

62

A figura 20 representa o funcionamento de um JIC.

Figura 20 – Funcionamento de um JIC

Para que não haja redundância ao observar a figura 20, define-se um JIC, como o

conjunto das n rondas. Como é óbvio, para que esta tecnologia funcione, o Browser em questão

tem de suportar e ter activo (uma vez que é configurável) a tecnologia Javascript.

O JIC será o elemento principal de todos os testes a realizar. Os testes de Captura e

Repetição baseiam-se na execução de vários JIC de forma automática e os testes Fuzz, incidiram

essencialmente sobre o conteúdo do JIC. Já nos testes de Desempenho, Carga e Stress o que se

pretendia testar, era qual a evolução do tempo de resposta a um JIC para diferentes condições de

carga do sistema.

Caso de Estudo

63

4.2 Plano de testes

A Plataforma desenvolvida disponibiliza funcionalidades para a execução de testes de

Captura e Repetição, Fuzz, e testes de Desempenho, Carga e Stress. Assim sendo, o plano de

testes a apresentar envolverá todas estas possibilidades.

O plano de testes foi desenvolvido para que, os testes não sejam efectuados de forma ad

hoc, mas possibilitando aplicar técnicas e metodologias, descritas na literatura e já descritos

neste documento (ver capítulo 2, Metodologias e Ferramentas de Teste a Aplicações Web).


Dentro desta categoria, os testes incidiram sobre o lançamento automático de um

Browser, seguido de um clique do rato numa hiperligação que despoletará a execução de um

JIC. A seguir serão utilizadas asserções de modo a que, o teste termine unicamente quando o

JIC terminar, sendo o Browser encerrado automaticamente, imediatamente a seguir à

terminação do JIC.

A técnica é a de teste automático de interfaces gráficas. No exemplo supracitado, toda a

actividade de teste (e configurações) é feita de forma totalmente automática sem necessidade de

intervenção humana. Para este efeito foram concebidos ficheiros de teste (e templates

genéricas). Esta abordagem permitiu que a empresa ficasse munida de elementos que lhe

permitissem aplicar a técnica dos Testes de Regressão. Caso seja necessário modificar a lógica

do Auditservice ou do JIC, estes ficheiros poderão constituir uma bateria de testes. A cada

iteração do desenvolvimento, esta bateria poderá ser executada para avaliar a presença de erros

não presentes na iteração anterior. Será assim possível, a avaliação da evolução ou regressão do

sistema a cada passo do desenvolvimento.

Testes Fuzz

Estes testes visam avaliar o impacto da recepção de dados erróneos, não esperados no

Front-End do Auditservice. Como um JIC, seja ele completo ou incompleto, válido ou inválido

é sempre recebido com sucesso, não foi (tal como apresentando no capítulo 1, Introdução, na

subsecção de Objectivos) definido como objectivo, a verificação do resultado do teste Fuzz.

Esta verificação será feita por outro módulo do sistema, que não foi considerado para

este projecto. O que se pretendia (e também aquilo que se realizou) foi munir a empresa de uma

forma automática da realização de testes Fuzz.

Caso de Estudo

64

Assim os ficheiros concebidos nesta fase, apenas necessitam de um ficheiro adicional de

configuração, em que cada linha terá sensivelmente a seguinte forma:

Operação – campo do JIC ou parâmetro HTTP - <novo valor (excepto em remoção)>

A concepção destes ficheiros de teste permite que, através de um ficheiro adicional de

configuração, no qual existe total abstracção da complexidade e funcionamento quer do código

de teste quer da Plataforma, se efectue de forma automática, testes Fuzz incidindo sobre

qualquer parâmetro do JIC ou cabeçalho do protocolo HTTP. Obviamente, seria possível definir

um ficheiro de teste que fizesse ele próprio a alteração sobre o tráfego interceptado. Esta

abordagem porém, traz a vantagem da abstracção sobre as questões de programação, permitindo

que, por exemplo, qualquer executante de teste possa definir os casos de teste sem necessidade

de conhecer o código envolvido.

Finalmente, sempre que se dá uma operação de Fuzz, os tráfegos HTTP original e

modificado são registados em ficheiro para posterior consulta. Podem também ser registadas as

respostas, sendo possível analisar o tráfego (conteúdo ou código HTTP) de resposta a um

determinado pedido HTTP.

Como já referido, independentemente do seu estado, um JIC é sempre recebido e

registado. Existem inclusivamente situações em que sintacticamente os valores fazem sentido

mas em termos semânticos isto não se verifica. Por exemplo, uma resolução de -500 x 1000000

é um valor impossível na realidade, mas aceite como entrada pelo sistema (tratam-se de dois

inteiros). O impacto de uma entrada deste tipo terá de ser analisado ao nível do resultado da

auditoria destes dados (novamente aqui se justifica o porquê de não se verificar o resultado de

um teste Fuzz).

Neste sentido, agruparam-se os dados que o JIC envia consoante o tipo de dado

esperado. A tabela 4 especifica as relações: tipo de dado - classes de equivalência válidas -

classes de equivalência inválidas. Como é visível na tabela 4, no caso dos inteiros, as classes são

definidas tendo em consideração os valores fronteira (o caso dos booleanos e dos inteiros), uma

técnica que se baseia em definir um intervalo de valores válidos como dados de entrada,

efectuando depois casos de teste, nos quais são utilizados os valores limite, os valores

imediatamente abaixo e acima e os valores bastante abaixo e acima deste limite.

Caso de Estudo

65

Tabela 4 - Valores para o teste Fuzz.

Tipo de variável

Classes

Equivalentes

Válidas

Classes Equivalentes

Inválidas

Valores

Válidos

Valores

Inválidos

String String válidas String inválidas Consoante o teste

do JIC

Null; cadeias

inválidas

Inteiro Inteiros válidos Inteiros inválidos [0;3000] {-1, 3001, -10000,

10000000, Null}

Booleano Valores do conjunto

{-1,0,1}

Valores fora do conjunto

válido {-1,0,1}

{-1000, -

2,2,1000}

Lista Lista válida Lista inválida Consoante o teste

do JIC

Null, cadeias

inválidas

Além das técnicas das classes de equivalência e das condições fronteira, poderá ainda

ser utilizada a metodologia de Teste Aleatório. É possível de forma totalmente automática, gerar

operações de Fuzz sobre o JIC ou sobre o protocolo HTTP de forma aleatória possibilitando

descobrir erros, não cobertos pelas baterias de teste definidas.


Vamos agora incidir sobre os testes não funcionais. Como a empresa não possui ainda

qualquer previsão, heurística ou medição do Desempenho médio do sistema, da quantidade de

carga suportada, ou mesmo das consequências de levar o serviço ao seu ponto de ruptura, o

grande objectivo deste tipo de testes é essencialmente determinar estes dados e munir a empresa

de uma forma automática de execução destes testes. De uma forma mais detalhada, podemos

definir os seguintes objectivos:

Conhecer o tempo médio de resposta aos pedidos de um JIC;

Determinar a forma de evolução do tempo de resposta a um JIC com o aumento da

carga do sistema;

Determinar o número máximo de pedidos que é possível servir em simultâneo,

mantendo o tempo de resposta num valor compatível com a execução do serviço;

Apurar as consequências de levar o serviço a um ponto de ruptura.

Caso de Estudo

66

Fornecer dados que permitam à empresa determinar:

O número máximo de clientes que podem servir com as configurações actuais;

Consoante a carga que uma aplicação Web espera, determinar imediatamente se é

exequível às configurações actuais prestar o serviço de auditoria.

As medições dos diversos tempos serão efectuadas de diversas formas:

Numa primeira abordagem, o TestNG usado para lançar os testes do Selenium, regista o

tempo total de execução de um teste, e caso o teste ocorra em várias fases (por

exemplo) cada tempo parcial é também registado;

Uma outra possível abordagem (esta mais longe da realidade de utilização), o Multi-

Mechanize efectuará uma série de pedidos (aos ficheiros “.php” com que o JIC

comunica) efectuando o registo da evolução do tempo de resposta, pedidos não

servidos, e gerando os gráficos representativos destas situações. Esta abordagem,

embora seja menos real, permite a geração de quantidades de carga muito superiores,

levando o sistema a uma possível exaustão de recursos, permitindo determinar os

bottlenecks com mais facilidade.

A geração da carga pode também ser feita de duas formas:

O modo de execução multi thread permite o controlo de vários Browsers em

simultâneo. Os ficheiros podem ser configurados para lançarem um determinado

Browser e efectuarem um definido número de JIC. Pelo centro de comando Web bastará

seleccionar as várias máquinas disponíveis (e os respectivos ficheiros) e estas

executarão todo o trabalho;

Podem ser também definidos ficheiros com a especificação de um determinado pedido

HTTP, e o Multi-Mechanize encarregar-se-á de simular tantos clientes quanto possível

pela potência de processamento da máquina e a largura de banda disponível, efectuando

cada um deles, tantos pedidos quanto possível.

Caso de Estudo

67

4.3 Resultados e Discussão

As primeiras validações efectuadas foram feitas no sentido de verificar se o número de

pedidos reportados como realizados pelas ferramentas, estavam de acordo com o número de

pedidos registados como recebidos pelo Auditservice. Os testes realizados somente com este

propósito e as verificações efectuadas a cada sessão de teste, apontaram sempre para uma

relação de 100%. Isto é, tanto o número de rondas geradas por um JIC num Browser, como o

número total de transacções geradas pelo Multi-Mechanize, apresentaram sempre igual valor ao

número correspondente de pedidos processados no Auditservice. Por este motivo, omitem-se

tabelas e verificações neste sentido a cada sessão.


Tabela 5 – Casos de teste e resultados para Captura e Repetição.

Caso de Teste Resultado esperado Resultado obtido

Ficheiro de teste com erros Identificação de erros. Não execução

do teste.

Identificação de erros. Não execução

do teste.

Geração de um JIC. Procura por um

“HTML id” inexistente

Teste falhado. Mensagem “ HMTL

name not found”

Teste falhado. Mensagem“ HMTL

name not found”

Geração de um JIC. Bloqueio até

HTML name = “JIC Done” presente. Teste passado Teste passado

Repetir teste anterior 10 vezes Teste passado Teste passado

Browser inválido (Internet Explorer

em Unix)

Teste falhado. Mensagem de

Browser não disponível.

Teste falhado. Mensagem de

Browser não disponível.

Os casos apresentados demonstram as quatro possibilidades. Os ficheiros de teste ou são

válidos, e existe execução, ou são inválidos, e o teste não é executado. Para o primeiro caso

existem três possibilidades, o teste é efectuado podendo falhar ou passar ou alternativamente, a

falha de uma ferramenta ou de um qualquer elemento do teste, origina uma não execução. Neste

caso o TestNG gera uma mensagem de erro e esta é apresentada no ecrã.

Caso de Estudo

68

O sistema é sempre o mesmo. A aplicação segue automaticamente todos os passos

apresentados no fluxograma da figura 18 do capítulo 3, Concepção da Solução, gerando no final

um ficheiro XML (com excepção da presença de erros nos ficheiros de teste).

A figura 21 representa um ficheiro XML exemplo, neste caso, o gerado pelo último caso

de teste da tabela 5.

Figura 21 - Ficheiro de resultados XML gerado pelo TestNG.

Figura 22 - Detalhes de um teste de Fuzz.

Caso de Estudo

69

Na figura 22 é possível ver como a informação é apresentada ao executante de teste,

após envio do ficheiro XML do MET para o CCR, onde este realiza automaticamente a

filtragem, a formatação e o armazenamento na Base de Dados. Como é visível na figura 22, se a

mensagem de erro (ou outra qualquer) gerada for de dimensão superior aos limites da tabela da

interface gráfica, esta é apenas parcialmente apresentada. Um clique do rato por cima da mesma

despoleta o aparecimento de um pop up com a totalidade da mensagem (funcionalidade

desenvolvida com recurso a Javascript standard e Jquery).

Testes Fuzz

O objectivo deste tipo de teste consistia na remoção, inserção e modificação de

elementos enviados pelo JIC para o Auditservice. Os ficheiros de teste concebidos possuem a

capacidade de, dado um ficheiro de configuração, identificar um elemento do protocolo HTTP

ou do JIC, e caso este exista efectuar a respectiva alteração.

O tráfego HTTP ao ser interceptado é registado, e após as operações de modificação é

novamente registado antes de ser enviado para o Auditservice.

A tabela 6 representa a estrutura de um possível ficheiro de configuração para um teste

Fuzz sobre os cabeçalhos do protocolo HTTP.

Tabela 6 – Ficheiro de configuração exemplo para teste Fuzz.

Operação Elemento alvo Parâmetro

rem (remove - remoção) “Content-Type” Null

chg (change - alterar) “Host” 111.111.111.111

Ins (insert - inserir) “MyField” fuzzed stuff

A figura 23 representa um exemplo, de um grupo de cabeçalhos após a intercepção no

Webscarab.

Caso de Estudo

70

Figura 23- Tráfego HTTP original.

A figura 24 representa o mesmo tráfego, após as alterações produzidas pelo Webscarab.

Figura 24 - Tráfego HTTP modificado no Webscarab.

Como é visível, todas as operações foram realizadas.


A medição de tempos efectuada nestes testes foi feita de duas formas:

A duração da execução do método de teste, no caso da geração automática de vários JIC

a partir de um Browser;

Leitura dos dados retornados pelo Multi-Mechanize.

Como já referido, o retorno do tempo de execução de um método de teste permite

apenas ter uma noção aproximada do tempo de execução de um JIC. No entanto, os dados

Caso de Estudo

71

retornados, para serem válidos têm de estar de acordo com dados já conhecidos (verificados e

testados pela empresa).

Foram efectuados vinte ensaios, dez com o Mozilla Firefox e dez com o Safari. Os

dados relativos a cada amostra encontram-se na tabela 20 do anexo C. Como se pode verificar

na referida tabela, em todos os casos, a execução no Safari é sempre mais rápida que no Mozzila

Firefox. As conclusões daqui retiradas vão de encontro com os dados conhecidos pela empresa.

O gráfico da figura 25 ilustra o tempo médio calculado para cada Browser no final dos

10 ensaios.

Figura 25- Comparação do tempo de execução do JIC entre o Safari e o Mozzila Firefox.

Dado que a rede e o servidor são os mesmos, assim como a máquina onde se testou o

JIC, porquê a diferença dos tempos de execução representados no gráfico da figura 25? A

resposta encontra-se na velocidade de processamento do Javascript por parte do Browser.

A tabela 7 mostra uma comparação sobre o desempenho de execução de Javascript

entre o Safari e o Mozzila Firefox. Este estudo foi efectuado com recurso a uma aplicação de

benchmarking gratuita e de código aberto. Esta aplicação executa uma série de métodos como,

conversões de dados, algoritmos recursivos, algoritmos de encriptação, cálculos, pesquisas em

árvores e listas entre outros, registando o tempo total de execução da sequência [38]

.

Para os dois Browsers em estudo foram efectuados quatro testes.

0 200 400 600 800 1000 1200 1400

Safari (v4.0.4)

Mozzila Firefox (v3.6.3)

Safari (v4.0.4) Mozzila Firefox (v3.6.3)

t médio (ms) 664 1163

Comparação do tempo de execução do JIC entre o Safari e o Mozzila Firefox

Caso de Estudo

72

Tabela 7 - Comparação do desempenho de execução de Javascript entre Safari e Mozzila Firefox.

Sessões

Tempo de execução (ms)

Safari Mozzila Firefox

1 649,8 1133,8

2 652,4 1115,2

3 680,0 1142,2

4 636,2 1122,2

t médio 654,6 1128,4

Pela tabela 7, verificamos que o tempo de execução do Mozilla Firefox é 1.723 vezes

superior ao do Safari. Usando os valores recolhidos para o JIC, o tempo medido para o Mozilla

Firefox de 1163 ms é 1.751 vezes superior ao medido para o Safari, 664ms.

O ensaio descrito pela figura 25 funcionou como um teste de Desempenho porque

permitiu determinar um tempo médio de resposta de um JIC. Por questões de tempo,

seleccionou-se um Browser para a próxima sessão. Sem um critério definido pelos requisitos (e

como todos os Browsers já foram validados em termos do seu suporte por parte do Selenium,

ver Anexo A, secção A.1) seleccionou-se o mais rápido.

A interface gráfica foi então utilizada para lançar em execução, três máquinas com o

MET. As condições de teste foram:

Duração: 15 minutos;

Número de clientes simulados: 500.

O ficheiro de teste consistia na simulação de 9 rondas, que compunham um JIC (tráfego

gerado pela Plataforma usando o Selenium e registado no Webscarab).

A partir do minuto 10 (para garantir que todos os clientes já estavam activos),

aproximadamente a cada minuto, usando um novo separador, a Plataforma foi utilizada para

lançar um caso de teste, correspondendo à execução de um JIC pelo Safari. Esta actividade foi

Caso de Estudo

73

desenvolvida ao longo de cerca de uma hora (três repetições de 15 minutos espaçadas por 5

minutos de intervalo, para garantir que as máquinas se encontravam livres de processamento).

O gráfico de dispersão da figura 26 permite observar a evolução do tempo de resposta

ao JIC ao longo dos 10 testes realizados. Os ensaios 1 e 2 revelam resultados totalmente de

acordo com o esperado pelos princípios teóricos da Informática e Computação. A carga gerada

no servidor leva a uma maior utilização do processador e da memória, tornando a execução mais

lenta. Outra possibilidade para a explicação do aumento do tempo de resposta é a quantidade de

tráfego a circular na rede que, sendo elevada, pode levar a um congestionamento, baixando a

velocidade de transferência de dados.

No caso do ensaio 3, os tempos medidos são sempre próximos dos tempos detectados

para a execução do JIC sem presença de carga no servidor, embora ligeiramente superiores. Há,

no entanto, a presença de um pico no tempo de resposta. De um ponto de vista teórico, é

possível que as diversas máquinas tenham produzido um momento, em que, a taxa de envio de

pedidos tenha tido ela também um pico criando assim, um congestionamento superior e/ou

exaustão de recursos. De um ponto de vista prático, fica como trabalho futuro, a realização de

mais ensaios com vista a verificar se se trata de um fenómeno isolado, ou se é causado em

determinadas condições.

Figura 26 - Comparação da evolução do tempo de resposta do JIC executado pelo Safari.

500

750

1000

1250

1500

1 2 3 4 5 6 7 8 9 10

´Te

mp

o S

afar

i (m

s)

Testes ao JIC

Comparação da evolução do tempo de resposta do JIC

executado pelo Safari

Servidor sem carga Servidor com carga (ensaio 1)

Servidor com carga (ensaio 2) Servidor com carga (ensaio 3)

Caso de Estudo

74

Figura 27 - Comparação da evolução do tempo médio de resposta do JIC executado pelo Safari.

O gráfico de barras da figura 27, permite identificar que o tempo médio de resposta

aumentou em todos os casos, tal como esperado. O aumento mínimo é de 90 ms e o aumento

máximo é de 209 ms. Finalmente, de referir que, no anexo C, Resultados das sessões de teste,

secção C.1, a tabela 21, contém, todos os dados relativos aos tempos medidos no total dos 30

ensaios realizados.

De notar ainda, que este ensaio foi repetido várias vezes até poder ser executado com

sucesso. A múltipla execução permitiu detectar erros no envio de ficheiros de resultados com

tamanho considerável, através da rede. Após a correcção, este ensaio foi repetido as referidas

três vezes, de onde foram colhidos os dados apresentados.

Os ficheiros de teste utilizados pelo Multi-Mechanize no caso anterior não estavam

escritos de forma a recolher correctamente os tempos de resposta. É um cuidado necessário no

caso de ficheiros com várias instruções ou múltiplas transacções HTTP. Esta actividade gasta

tempo de processamento e diminui o tempo disponível para execução de transacções, pelo que,

os ficheiros foram escritos de forma a gerar o máximo de tráfego possível.

Para a medição dos tempos de execução poder ser feita no Multi-Mechanize, os

ficheiros de teste têm de ser concebidos de forma a registarem o tempo explícito de cada

transacção HTTP (e não o tempo de execução de uma execução de uma instância da classe

Transaction do Multi-Mechanize). Esta característica não é uma falha. Como referido no

capítulo 2, o Multi-Mechanize foi seleccionado em detrimento do Pylot, por permitir a

concepção de ficheiros de teste que simulem comportamentos de utilizadores. Por exemplo, é

possível simular o conjunto de acções:

1. Pedir uma página;

2. Preencher um formulário;

3. Submeter o formulário.

Servidor sem

carga

Servidor com

carga

(ensaio 1)

Servidor com

carga

(ensaio 2)

Servidor com

carga

(ensaio 3)

Tempo médio (ms) 664 780 873 754

0

250

500

750

1000

Tem

po

(ms)

Comparação da evolução do tempo médio de resposta do JIC

executado pelo Safari

Caso de Estudo

75

Este comportamento pode ser definido por uma série de instruções na classe

Transaction. Pode interessar contabilizar todo o tempo ou desprezar o tempo de preenchimento

do formulário.

Como o tempo disponível não permitiu que fosse de outra forma, foram então

concebidos ficheiros de teste capazes de simular uma ronda do JIC, fincado para trabalho futuro

a concepção de ficheiros de teste que simulem rondas completas do JIC.

Com esta fase de testes pretendia-se essencialmente verificar se a Plataforma está apta à

realização de testes de Desempenho, Carga ou Stress. Com este objectivo, foi definido um

ensaio inicial, composto por quatro repetições de uma sessão de teste, com as seguintes

configurações (exactamente as mesmas por cada sessão):

Duração: 60 segundos;

Número de clientes em simultâneo: 10;

Número de máquinas: 2.

No anexo C, Resultados das sessões de teste, secção C.1, a tabela 22, apresenta os dados

discriminados de cada máquina por cada sessão de teste. Na tabela 8, é possível ver os dados

obtidos no conjunto das duas máquinas, ao longo das quatro sessões.

Tabela 8 - Resultados de uma sessão de testes de Carga.

Sessão de

teste

Número

total de

pedidos

realizados

Tempo (s) Desvio

Padrão do

Tempo Médio

(s)

Total de Erros

Mínimo Máximo Médio Número Percentagem

1 18 808 0,009 3,105 0,067 0,015 0 0

2 19 757 0,009 3,115 0,064 0,016 0 0

3 18 899 0,008 4,304 0,066 0,015 0 0

4 19 046 0,008 3,108 0,066 0,015 0 0

Os dados recolhidos apontam no sentido da validade das experiências realizadas. Por

um lado, todos os dados, como, número total de transacções, tempo mínimo, tempo máximo,

tempo médio de transacções são extremamente próximos, mostrando assim que, a realização da

mesma experiência em momentos diferentes, resulta sempre nas mesmas conclusões. Pela tabela

22 é possível observar que a mesma máquina retornou sempre resultados muito próximos nos

Caso de Estudo

76

diversos ensaios. A diferença registada entre as duas máquinas por cada sessão explica-se, pela

diferença de potência de processamento das duas máquinas (com impacto no número total de

transacções que a máquina consegue gerar e consequente número de respostas que o servidor

terá que dar a essa mesma máquina). Esta questão explica os valores calculados para o desvio

padrão.

Este ensaio permitiu ainda uma outra verificação. Verificar a consistência entre o tempo

determinado para a execução de um JIC pelo Selenim e pelo Multi-Mechanize.

No anterior ensaio com os Browsers, tinha-se determinado o tempo médio de um JIC

em três ensaios. Por questões de simplificação calculou-se a média das médias:

(780 + 853 + 754) / 3 = 795 (ms)

Neste ponto, a escolha do Safari, para a realização dos testes anteriores revelou-se

extremamente útil. Seria benéfico para esta verificação que o tempo de processamento do

Javascript fosse o menor possível.

Calculando a média das médias, agora para os ensaios realizados com o Multi-

Mechanize:

(0.067 + 0.064 + 0.066 + 0.066) / 4 = 0.06575 (s) = 65.75 (ms)

Como o Multi-Mechanize não processa Javascript, e não existe processamento relevante

do servidor em qualquer uma das rondas, é possível extrapolar que, o tempo total de um JIC,

torna-se no tempo total da realização de 9 rondas (por comparação ao JIC usado como

exemplo).

Seguindo este raciocínio determina-se o tempo das 9 rondas:

65.75 * 9 = 591.75 (ms)

O tempo determinado no Browser foi de 795 ms, pelo que a diferença relativamente ao

calculado, segundo os dados do Multi-Mechanize é de 203.25 (ms). Um tempo perfeitamente

aceitável para que, de um ponto de vista teórico, possa ser explicado precisamente pelo tempo

de processamento do Javascript e pelo tempo adicional imposto pela ferramenta de teste (como

dito, o tempo corresponde ao processamento do método de teste e não ao tempo do JIC em si).

De um ponto de vista prático, esta hipótese pode ser verificada analisando o tempo de

execução do código do JIC, a cada ronda, no Safari. Como não existem dados que permitam

comprovar imediatamente esta hipótese, e as questões de tempo não permitem realizar este

trabalho adicional, esta questão terá de ser verificada em trabalho futuro.

Caso de Estudo

77

Há ainda outra questão a ter em conta ao testar esta hipótese. Um Browser usa a

propriedade Keep alive nas suas ligações. A ideia é usar a mesma ligação TCP para a troca de

múltiplos pedidos e respostas, aumentando assim o desempenho da ligação [39]

.

O Multi-Mechanize por cada pedido gera uma transacção. Logo, considerando apenas e

só o tempo total das transacções, em ambos os casos, o tempo registado no Multi-Mechanize

pode até ser superior.

Para terminar o plano de execução de testes, efectuaram-se uma série de sessões de

teste, com vista à análise da evolução do tempo de resposta, quando o servidor se encontra em

condições de alguma carga. Tentou-se também levar o sistema a uma condição de stress.

A tabela 9 mostra as diferentes configurações definidas para as sessões de teste. Além

dos efeitos no sistema em teste, a utilização de diferentes configurações permitiria a verificação

de como maximizar o número de transacções e consequente nível de carga no servidor. Também

seria possível determinar qual o número de threads, que maximiza o número de transacções

realizadas, num mesmo, ou diferentes espaços de tempo, por cada máquina.

Tabela 9 - Sessões de teste de Carga.

Sessão de teste Duração (minutos) Número de clientes

simulados (por máquina)

Número de máquinas em

simultâneo

1 2 1000 1

2 45 500 3

3 45 250 2

4 30 200 5

5 5 500 5

A tabela 10 representa os dados obtidos pelo conjunto das máquinas envolvidas por

cada sessão. No anexo C, Resultados das sessões de teste, secção C.1, a tabela 23 contém os

dados por cada máquina, por cada sessão. Por questões de tempo e indisponibilidade de recursos

não foi possível repetir os ensaios mais do que uma vez. A repetição destes ensaios n vezes para

verificação dos resultados obtidos fica definida como trabalho futuro.

Caso de Estudo

78

Tabela 10 - Resultados de uma sessão de testes de Carga.

Sessão de

teste

Número

total de

pedidos

realizados

Tempo (s) Desvio

Padrão do

Tempo Médio

(s)

Total de Erros


1 27 703 0,006 4,327 0,219 0 0 0

2 1 456 491 0,006 3,164 0,823 0,413 0 0

3 777 258 0,005 3,611 0,239 0,070 0 0

4 1 601 824 0,005 9,926 0,418 0,214 153 788 9,6

5 221 772 0,004 3,477 0,450 0,301 0 0

Como é visível no gráfico da figura 28, pode ser estabelecida uma relação entre o

aumento do tempo médio de resposta (barras do gráfico) e o número de transacções efectuadas

(pontos do gráfico). Esta relação é observada pela análise dos ensaios 1, 2 e 3.

Figura 28 - Relação entre o número de pedidos a processar e o tempo médio de resposta.

1 2 3 4 5

Tempo médio (ms) 0,219 0,823 0,2385 0,4176 0,4496

Número total de pedidos

realizados27703 1456491 777258 1601824 221772

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

Nú

mer

o t

ota

l d

e p

edid

os

rea

liza

do

s

Relação entre o número de pedidos a processar e o tempo médio de

resposta

Caso de Estudo

79

O quarto ensaio permite verificar que a relação identificada, pode nem sempre se existir.

No entanto, este ensaio gerou uma quantidade de pedidos que não foram servidos em tempo útil

ou não foram de todo servidos (estes não são considerados para contabilizações de tempo, um

pedido não servido não tem tempo de resposta associado). A coluna 5, também permite pôr em

casa a relação verificada pelos ensaios 1 a 3. Porém, este ensaio era composto pela simulação de

uma grande quantidade de tráfego (5 máquinas a simular 500 clientes cada uma).

Nos ensaios 4 e 5, foi utilizado um número de máquinas superior ao dos outros ensaios,

criando assim um aumento do tráfego trocado por unidade de tempo. Dados os erros produzidos

no ensaio 4 e o grande aumento do tempo de resposta no ensaio 5, pode colocar-se uma

hipótese. O número total de transacções não é tão significativo como o número de transacções

simultâneas, isto é, a quantidade de tráfego por unidade de tempo pode ter mais impacto que a

quantidade total em absoluto.

Finalmente, é importante referir que, as tabelas obtidas para análise dos resultados de

uma sessão de teste realizada em múltiplas máquinas, não foram feitas de forma manual. Os

cálculos e operações associadas são realizados automaticamente pela Plataforma. A figura 29

representa a forma como os dados da linha 5 da tabela 10 são apresentados pela interface

gráfica. Para se aceder a esta funcionalidade basta seleccionar as várias sessões sobre as quais se

pretende efectuar uma análise e clicar em Analyze (a figura 13 do capítulo 3, Concepção da

Solução, na secção 3.3, representa uma interface onde seria possível efectuar o conjunto de

acções descritas).

Figura 29 - Disposição dos resultados na interface gráfica para análise.

Caso de Estudo

80

Pegando neste próprio exemplo, esta experiência permite detectar um problema.

Aplicando o método anterior e utilizando os dados da figura 29:

0.4496 * 9 = 4.06 (s)

Ou seja, o tempo de um JIC, sem considerar o processamento de Javascript seria

aproximadamente 4 segundos. Um tempo de facto muito elevado para o processamento de um

JIC.

É possível identificar uma série de hipóteses que expliquem este fenómeno:

1. O servidor encontrava-se numa exaustão de recursos em termos de processador e/ou

memória, dada a quantidade de tráfego massiva a processar por unidade tempo;

2. A rede estava de tal forma congestionada (apesar do servidor se encontrar disponível),

causando que o tráfego fosse trocado muito lentamente. Neste caso, seria como

comparar tempos de resposta em redes de largura de banda muito diferentes (por

exemplo uma ligação banda larga de 512Kbps e uma rede ADSL de 100 Mbps);

3. Os buffers das placas de rede utilizadas estavam continuamente cheios, pelo que os

pedidos já processados eram recebidos muito lentamente. Caso esta hipótese se

verifique, pode existir ainda um atraso adicional. O excesso de carga de processamento

da máquina cliente, aliado à quantidade massiva de tráfego trocado, leva também a que

a transferência dos dados dos buffers da placa de rede para a memória RAM (Randon

Access Memory) sofra um atraso muito superior ao obtido em condições normais. Esta

situação leva a um atraso na leitura por parte do Multi-Mechanize com consequente

detecção de tempos de resposta elevados. Seria como usar uma máquina sobrecarregada

para efectuar leituras de tempos de resposta.

Caso as hipóteses dois e três representem as causas, a solução recai sobre a utilização de

equipamentos diferentes e/ou distribuição da carga a gerar por várias máquinas. Aqui se

identificou um possível problema para o qual a Rede de Execução de Testes (ver capítulo 3)

pode ser a solução.

Para responder a estas questões, além da já referida repetição dos ensaios, poder-se-ia

efectuar duas novas experiências:

Caso de Estudo

81

1. Simular a carga através de uma segunda rede (diminuir o congestionamento na rede

onde está presente o servidor);

2. Efectuar ensaios de verificação através de uma terceira rede (esta totalmente

descongestionada).

Em simultâneo, poderiam ser utilizados monitores de recursos. Estes estariam instalados

tanto nas máquinas cliente, simuladoras da carga, como no servidor. Duas possibilidades

identificadas para este efeito são:

RRDTool;

Nagios.

Estas duas ferramentas são de código aberto, tal como, as previamente seleccionadas

para a execução de teste. As suas funcionalidades (entre muitas outras) contemplam a criação de

registos de medidas sobre:

Taxa de CPU;

Carga do sistema;

Memória utilizada;

Estado da placa de rede;

Estado da rede.

Em suma, estas duas ferramentas, aliadas à repetição das sessões de teste permitiriam

conhecer o estado dos recursos de todas as máquinas e perceber o que está a originar tempos de

resposta tão elevados [40,41]

.

Dito de outra forma, a repetição de todos os testes aliado ao uso destas ferramentas

permitiria explicar os fenómenos detectados pelo conjunto das experiências realizadas e validar

de um ponto de vista prático, as hipóteses avançadas como possíveis causas.

Finalmente, o aumento da carga a gerar sobre o sistema deve ser feito de forma

progressiva. Neste caso, o aumento mínimo foi de 190 clientes por máquina. Idealmente, a carga

seria aumentada de modo gradual, os testes repetidos várias vezes e a referida monitorização de

recursos efectuada sempre a cada ensaio.

Caso de Estudo

82

4.4 Conclusão

Neste capítulo foi apresentado o caso de estudo deste projecto. Foi definido um plano de

testes, dividido em três partes consoante os tipos de teste a executar. Identificaram-se as

metodologias a aplicar em cada fase, e no caso concreto da empresa, e quais as características

do sistema que seriam possíveis de conhecer.

Realizaram-se uma série de experiências com vista a validar a Plataforma. Para os testes

de Captura e Repetição e para os testes Fuzz, efectuou-se uma comparação entre os resultados

esperados e os resultados obtidos, tendo-se verificado sucesso em todos os casos.

Foram também efectuados testes com vista à medição do tempo de execução do JIC. Foi

realizada uma comparação com os dois Browsers, tendo os resultados obtidos, revelando

concordância com os dados já conhecidos pela empresa. Identificou-se a causa e validou-se a

conclusão através de um Benchmarking.

Efectuou-se uma verificação do funcionamento do gerador de carga seleccionado. O seu

funcionamento foi validado pela repetição de uma experiência quatro vezes, nas mesmas

condições, cujos resultados retornados foram sempre os mesmos, tal como esperado.

Estabeleceu-se também uma relação entre os tempos medidos pela ferramenta de

Captura e Repetição e os tempos registados. Efectuando os cálculos e considerando os

princípios teóricos, foi possível demonstrar que os dados recolhidos pelas duas aplicações

demonstram concordância.

Finalmente foram realizados alguns testes de carga. A impossibilidade, por questões de

tempo, impediu a repetição dos mesmos para verificação de resultados. Estes foram, porém,

analisados de um ponto de vista teórico, sendo apontadas algumas explicações para os

resultados obtidos.

Ficam ainda documentadas, uma série de propostas para a execução de ensaios práticos

que permitam validar as hipóteses colocadas.

83

Capítulo 5

Conclusão e Trabalho Futuro

Este projecto foi iniciado pela realização de um levantamento de técnicas e

metodologias de teste de software, para que pudessem ser identificados quais seriam aplicáveis

num contexto de teste a aplicações Web.

Inicialmente estudaram-se técnicas de teste funcional. Dentro destas, foram

identificadas as técnicas de Captura e Repetição (uma técnica que se baseia em capturar as

acções de um utilizador para um ficheiro de teste para posterior repetição) e a técnica de teste

Fuzz, que se aplica, fazendo chegar ao sistema, dados de entrada fora do domínio válido, com

vista a avaliar se o sistema se comporta correctamente perante dados de entrada inválidos.

Estudaram-se igualmente técnicas de teste não funcional, nomeadamente teste de

Desempenho (medição do tempo de resposta a um pedido HTTP), teste de Carga (avaliação da

carga de processamento que o sistema pode suportar mantendo um tempo de resposta aceitável)

e teste de Stress (avaliação das consequências de levar o sistema ao ponto de ruptura).

Foi realizado ainda um estudo teórico experimental sobre ferramentas de teste a

aplicações Web. As ferramentas foram divididas em três grupos, ferramentas de Captura e

Repetição, ferramentas de teste Fuzz e ferramentas de testes de Desempenho, Carga e Stress. Do

estudo, resultou a selecção de uma ferramenta por grupo. Para os testes de Captura e Repetição

seleccionou-se o Selenium; Para intercepção e modificação de tráfego HTTP (teste Fuzz), foi

seleccionado o Webscarab; Para os testes não funcionais, foi escolhido o Pylot, tendo sido este

porém, substituído durante o projecto, pelo Multi-Mechanize.

A Plataforma implementada é constituída por dois módulos principais. Um Módulo de

Execução de Teste (MET) e o Centro de Controlo Remoto (CCR). O MET é composto pela

integração das ferramentas seleccionadas e uma aplicação capaz de executar todas as operações

de configuração e controlo de execução associadas. Está munido ainda de um sistema de

ficheiros que armazena todos os resultados. O MET funciona de forma totalmente automática


84

remetendo como única preocupação do executante de testes, a concepção dos ficheiros com os

casos de teste.

O MET pode ser instalado em várias máquinas. Usando o CCR, as várias instâncias

podem ser controladas remotamente através de uma única interface Web. Após a execução dos

testes, os MET enviam por rede todos os resultados para o CCR que os armazena tanto num

sistema de ficheiros como numa Base de Dados.

A última iteração do projecto consistiu na realização de um caso de estudo onde se

verificou o correcto funcionamento da Plataforma e a validade dos resultados retornados.

Consistiu numa série de testes ao Auditservice, o sistema da Auditmark. Os resultados obtidos

foram validados por comparação com dados previamente conhecidos pela empresa e também,

atendendo aos princípios teóricos da Informática e Computação. Foi estabelecida também uma

relação de concordância entre os dados retornados pelas diversas ferramentas.

5.1 Contribuições do trabalho

Após a finalização da fase de implementação da Plataforma e da concepção deste

documento, é pertinente analisar qual o contributo deste trabalho quer a nível científico quer ao

nível da empresa.

Em termos científicos, assume-se o grande contributo como a concepção de uma

Plataforma de teste a aplicações Web que automatiza por completo o processo inerente ao teste.

Todas as operações de configuração das ferramentas de execução, armazenamento e

estruturação de resultados funcionam de forma automática e transparente para o utilizador.

A solução reúne numa única aplicação funcionalidades para a execução de testes de

Captura e Repetição, testes Fuzz e testes de Desempenho, Carga e Stress, oferecendo ainda uma

unificação no formato de apresentação dos resultados.

Ao nível da empresa, mais do que a Plataforma, assume relevante importância o

fornecimento (em termos de conhecimento) de uma série de técnicas e metodologias de teste de

software (através deste e de outros documentos criados). Isto permitirá que uma empresa em

início de vida prossiga desde cedo, aplicando técnicas de teste devidamente documentadas na

literatura (ver capitulo 2, Metodologias e Ferramentas de teste a aplicações Web) em detrimento

de procedimentos meramente ad hoc. Estas incluem a especificação de casos de teste sobre a

forma de Testes Unitários, Teste Automático de Interfaces, Testes de Sistema e Testes de

Regressão. O automatismo permitido pela Plataforma, permite testar rapidamente os sistemas

Web desenvolvidos pela empresa, tendo como consequência directa, evitar que a empresa

menospreze a fase de teste em momentos de aperto orçamental ou de tempo (como é já referido

no capítulo 1, Introdução, é uma situação que se verifica várias vezes em ambiente empresarial).


85

5.2 Trabalho futuro

Todos os objectivos deste projecto foram cumpridos, tendo havido ainda o

desenvolvimento de funcionalidades extra não previstas. Foi criada a possibilidade de

especificar casos de teste sobre a forma de Testes Unitários, e foi ainda criado um módulo de

armazenamento, análise e apresentação de resultados.

Dado o cumprimento de todos os objectivos deste projecto, o trabalho futuro é definido

com base num conjunto de melhoramentos e funcionalidades extra. Estes surgiram da utilização

da Plataforma em situação real. A aplicação de um plano de testes que permita conhecer em

pleno as características do Auditservice constitui também um dos elementos a considerar para

trabalho futuro.

Ao nível dos melhoramentos, seria interessante, munir o centro de controlo Web de um

módulo de compilação e verificação dos ficheiros de teste. Assim, no caso de existirem erros,

evita-se o envio destes à Plataforma. Isto permitiria conhecer o estado dos ficheiros de teste

mais rapidamente e com um conjunto menor de comunicações HTTP (redução para apenas

duas). Também em caso de sucesso de compilação, os ficheiros podem ser enviados já

compilados para as diferentes máquinas, começando assim o teste a ser executado mais

rapidamente. Ainda relativamente a este tópico, seria útil fornecer também na interface Web, o

detalhe e linha sobre o erro encontrado. Esta melhoria poderia ser implementada, por exemplo,

pela leitura dos dados de saída do Ant, que já fornece estes dados.

Outro melhoramento possível, este em específico para o caso dos testes não funcionais,

seria efectuar a colheita não apenas dos tempos médios, máximo e mínimo e gráficos gerados,

mas sim, a colheita de todos os tempos medidos para todas as transacções. Estes passariam a

ficar armazenados não só na Plataforma de teste, mas também, no centro de controlo Web (na

Base de Dados e na estrutura de directórios reservadas para o armazenamento de resultados). As

possibilidades levantadas por esta melhoria incluem a possibilidade de cálculo (relativamente

aos tempos de transacções) de variância, moda e mediana, permitindo assim um nível mais

detalhado de análise de evolução dos tempos. De forma directa, seria possível gerar gráficos,

utilizando outras tecnologias, criando assim uma interface mais agradável e intuitiva (por

exemplo, com recurso a tecnologia Fusion Charts).

Seria de extremo interesse, levar a interface de um estado de protótipo a um estado final

quer a nível estético quer funcional, permitindo por exemplo, através de uma mesma página

(uma única interface) a definição de diferentes sessões de teste, contemplando diferentes

configurações. Desta melhoria, propõe-se uma outra funcionalidade, o armazenamento para


86

posterior utilização de sessões de teste, i.e., ser possível mais tarde repetir exactamente a mesma

sessão, com as mesmas definições sem necessidade de as carregar novamente de forma manual.

Este desenvolvimento adicional seria uma mais-valia clara na aplicação de Testes de

Regressão (facilitaria a aplicação da mesma sessão múltiplas vezes em tempos diferentes) e

também na aplicação de Teste Aleatório, neste caso mais especificamente para os testes Fuzz.

Ainda relativamente à interface de controlo, agora no módulo de execução de testes,

seria benéfico evoluir a interface em modo de texto para uma interface gráfica, utilizando por

exemplo, Java swing.

Finalmente, seria também benéfico criar um módulo de arranque da Plataforma nas

diversas máquinas (neste momento é apenas possível o seu encerramento), por exemplo via um

cliente SSH implementado em PHP, controlado pela interface gráfica permitindo também, neste

caso, uma abstracção completa do modo funcionamento deste módulo.

Para fechar as questões relativas a trabalho futuro, fica a referência à utilização da

Plataforma para a execução do plano de testes definido no capítulo 4, Caso de Estudo, deste

documento, utilizando os monitores de sistema aí mencionados e efectuando todas as repetições

das sessões de teste.

87

Referências

[1] BURNSTEIN, Illene. Practical Software Testing. United States of America: Springer, 2003.

[2] NGUYEN, Hung Q.; Testing Applications on the Web: Test Planning for Internet-Based

Systems. United States of America: John Wiley & Sons, Inc., 2001.

[3] TANENBAUM, Andrew S.; Computer Networks – 4th Edition. Upper Saddle River, NJ:

Pearson Education International, 2003.

[4] HENNESSEY, J. L.; PATTERSON, D. A.; Computer Architecture: A Quantitative

Approach – 4th Edition. Amsterdam: Elsevier, 2007.

[5] TANENBAUM, Andrew S.; Modern operating systems – 3rd

Edition. Upper Saddle River,

NJ: Prentice - Hall, 2009.

[6] HAMMERSLAND, Rune; SNEKKENES, Einar; Fuzz testing of web applications. Faculty

of Computer Science and Media Technology - Gjøvik University College, Norway.

[7] XU, Lei; XU, Baowvn; JIANG, Jixiang; Testing Web Applications Focusing on Their

Specialties. Department of Computer Science and Engineering, Southeast University: Nanjing,

China, 2005.

[8] DI LUCCA, Giusepp A.; FASOLINO, Anna Rita. Testing Web-based applications: The

state of the art and future trends, in Information and Software Technology: Vol. 48, Issue 12,

pp. 1172-1186, December 2006.

[9] RICCA, Filippo; TONELLA, Paolo. Analysis and Testing of Web Applications, in Proc. of

23rd

IEEE International Conference on Software Engineering (ICSE'01), pp. 0025, 2001.

Referências

88

[10] SAMPATH, Sreedevi; MIHAYLOV, Valentin; SOUTER, Amie; POLLOK, Lori.

Composing a framework to automate testing of operational Web-based software, in Proc. of

20th IEEE International Conference on Software Maintenance, pp. 104-113, 11-14 Sept. 2004.

[11] Windmill Testing Framework em http://www.getwindmill.com/, último acesso em Janeiro

de 2010.

[12] Sahi – Open Source Automation Tool for Web Application Testing em http://sahi.co.in/w/,

último acesso em Janeiro de 2010.

[13] Badboy Software. Badboy em http://www.badboy.com.au/, último acesso em Janeiro de

2010.

[14] Radview Software Ltd. Radview em http://www.radview.com/, último acesso em Janeiro

de 2010.

[15] Watir.com, Web Application Testing in Ruby em http://watir.com/, último acesso em

Janeiro de 2010.

[16] SeleniumHQ, Web Application Testing System em http://seleniumhq.org/, último acesso em

Junho de 2010.

[17] Canoo Web Test em http://webtest.canoo.com/webtest/manual/WebTestHome.html, último

acesso em Janeiro de 2010.

[18] Doit: Simple Web Application Testing em http://doit.sourceforge.net/manual.html, último

acesso em Janeiro de 2010.

[19] W3Schools Online Web Tutorials. DHTML Tutorial em

http://www.w3schools.com/dhtml/default.asp, último acesso em Março de 2010.

[20] IEinspector, IEinspector http Analyser em http://www.ieinspector.com/httpanalyzer/,


[21] WIRESHARK em http://www.wireshark.org, último acesso em Janeiro de 2010.

http://www.getwindmill.com/

http://sahi.co.in/w/

http://www.badboy.com.au/

http://www.radview.com/

http://watir.com/

http://seleniumhq.org/

http://webtest.canoo.com/webtest/manual/WebTestHome.html

http://www.ieinspector.com/httpanalyzer/

http://www.wireshark.org/

Referências

89

[22] OWASP, WebScarab Project em

http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project, último acesso em

Junho de 2010.

[23] OWASP, JBroFuzz em http://www.owasp.org/index.php/Category:OWASP_JBroFuzz,


[24] Chinotec Technologies Company, Parosproxy – Web Application Security em

http://www.parosproxy.org, último acesso em Janeiro de 2010.


http://www.owasp.org/index.php/Scripting_in_WebScarab, último acesso em Junho de 2010.


http://www.owasp.org/index.php/Fuzzing_with_WebScarab, último acesso em Junho de 2010.

[27] LoadStorm Load Testing in the Cloud em http://loadstorm.com/, último acesso em Janeiro

de 2010.

[28] GOLDBERG, Corey. Pylot - Web Performance Tool em http://www.pylot.org/, último

acesso em Março de 2010.

[29] ASTON, Philip; FITZGERALD, Calum; GÓMEZ, Paco; ZADRONY, Peter et al. The

Grinder em http://grinder.sourceforge.net/, último acesso em Janeiro de 2010.

[30] Hewlett Packard. HP LoadRunner Software em

https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-126-

17^8_4000_100__, último acesso em Janeiro de 2010.

[31] Python v2.6.5 documentation em http://docs.python.org/library/httplib.html, último acesso

em Março de 2010.

[32] GOLDBERG, Corey. Multi-Mechanize - new open source performance testing tool em

http://coreygoldberg.blogspot.com/2010/02/multi-mechanize-new-open-source.html, último

acesso em Junho de 2010.

http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

http://www.owasp.org/index.php/Category:OWASP_JBroFuzz

http://www.parosproxy.org/

http://www.owasp.org/index.php/Scripting_in_WebScarab

http://www.owasp.org/index.php/Fuzzing_with_WebScarab

http://loadstorm.com/

http://grinder.sourceforge.net/

Referências

90

[33] GOLDBERG, Corey. Multi-Mechanize em http://groups.google.com/group/multi-

mechanize, último acesso em Junho de 2010.

[34] The Apache Software Foundation. The APACHE ANT PROJECT em http://ant.apache.org/,

último acesso em Junho de 2010.

[35] BEUST, Cédric. TestNG em http://testng.org/doc/documentation-main.html, último acesso

em Junho de 2010.

[36] SANTOS, Pedro Jorge. Sistema Integrado de Gestão de Plataforma de Auditoria Web.

Faculdade de Engenharia da Universidade do Porto, 2009.

[37] The jQuery Project. jQuery: The Write Less, Do More, Javascript Library em

http://jquery.com/, último acesso em Junho de 2010.

[38] SunSpider JavaScript Benchmark em http://www2.webkit.org/perf/sunspider-

0.9/sunspider.html, último acesso em Junho de 2010.

[39] Sun. Persistent HTTP Connections em http://java.sun.com/j2se/1.5.0/docs/guide/net/http-

keepalive.html, último acesso em Junho de 2010.

[40] OETIKER, Tobias. RRDtool logging & graphing em http://oss.oetiker.ch/rrdtool/, último

acesso em Junho de 2010.

[41] Nagios Enterprises. Nagios - The Industry Standard in IT Infrastructure Monitoring em

http://www.nagios.org/, último acesso em Junho de 2010.

[42] W3Schools Online Web Tutorials. Browser Statistics em,

http://www.w3schools.com/browsers/browsers_stats.asp, último acesso em Junho de 2010.

[43] Awio Web Services LLC. Global Web Stats May 2010

http://www.w3counter.com/globalstats.php, último acesso em Junho de 2010.

[44] BeanShell Lightweight Scripting for Java em http://www.beanshell.org, último acesso em

Junho de 2010.

http://groups.google.com/group/multi-mechanize

http://groups.google.com/group/multi-mechanize

http://ant.apache.org/

http://testng.org/doc/documentation-main.html

http://jquery.com/

http://oss.oetiker.ch/rrdtool/

http://www.beanshell.org/

91

Anexo A

Informação adicional sobre o Selenium

O objectivo deste Anexo é fornecer informação adicional sobre a ferramenta de captura

e repetição utilizada. É analisado o suporte a múltiplos Browsers, são explicadas as operações

mais relevantes que podem ser utilizadas durante um teste e finalmente descreve-se uma

integração do Selenium com uma nova tecnologia que possibilita o aumento da eficiência do

teste.

A.1 Análise do suporte a múltiplos Browsers

O propósito desta subsecção é a apresentar os resultados das sessões de ensaio que

foram efectuadas para determinar se a ferramenta cumpria os requisitos de suporte a múltiplos

Browsers. São apresentadas sob a forma tabular todos os dados recolhidos ao longo das várias

sessões.

No final do anexo é apresentada a conclusão obtida após a experimentação tendo em

conta simultaneamente, os requisitos do projecto e as estatísticas de utilização dos Browsers.


92

Sessão de teste 1

Selenium RC: v1.0.3

Sistema Operativo: Linux Ubuntu 9.10 (64 bits)

Tabela 11 – Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 1).

Browser Versão Execução Comentário

Mozilla Firefox 3.5.8 Sim -

Opera 9.6 Não Selenium Core injectado correctamente. Não

executa teste.


executa teste.

Konqueror 4.3.2 Sim -

Google Chrome 5.0 Não Só é lançado usando drivers padrão. Selenium

Core não é injectado.

Epiphany 2.28 Não Não existem drivers próprios. Selenium Core não

é injectado.

Sea Monkey - Não Não existem drivers próprios. Selenium Core não

é injectado.

Sessão de teste 2

Selenium RC: v1.0.3

Sistema Operativo: Linux Ubuntu 9.10 (32 bits)

Tabela 12 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 2).


Mozilla Firefox 3.5.8 Sim -


executa teste.


executa teste.

Konqueror 4.3.2 Sim -

Google Chrome 5.0 Não Só é lançado usando drivers padrão. Selenium

Core não é injectado.

Epiphany 2.28 Não Não existem drivers próprios. Selenium Core não

é injectado.

Sea Monkey - Não Não existem drivers próprios. Selenium Core não

é injectado.


93

Sessão de teste 3

Selenium RC: v1.0.3

Sistema Operativo: Windows 7 (64 bits)



Internet Explorer 8.0 Sim Funciona usando os drivers para proxy.

Mozilla Firefox 3.6 Sim -

Safari 4.0.4 Sim -


executa teste.


executa teste.

Google Chrome 4.0.249 Sim -

Sessão de teste 4

Selenium RC: v1.0.3

Sistema Operativo: Windows Vista (32 bits)



Internet Explorer 7 Sim -

Internet Explorer 8 Sim Funciona usando os drivers para proxy.


Safari 4.0.4 Sim É necessário desactivar o bloqueador de pop ups

na primeira execução.


executa teste.


executa teste.



94

Sessão de teste 5

Selenium RC: v1.0.3

Sistema Operativo: Mac OS (64 bits)







executa teste.


executa teste.

Google Chrome 4.0.249 Sim É necessário especificar o caminho completo para

o executável.

Sessão de teste 6

Selenium RC: v1.0.3

Sistema Operativo: Windows XP sp3 (32 bits)

Tabela 16 -Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 6).


Internet Explorer 6 Sim -





executa teste.


executa teste.



95

Sessão de teste 7

Selenium RC: v0.9.2

Sistema Operativo: Mac OS (32 bits)



Opera 8.54 Não Selenium Core não é injectado.



Sessão de teste 8

Selenium RC: v0.9.2

Sistema Operativo: Ubuntu 9.10 (32 bits)



Opera 9.52 Sim Deve ser utilizado o modo Single Window

Sessão de teste 9

Selenium RC: v0.9.2

Sistema Operativo: Windows xp sp3 (32 bits)



Opera 9.52 Sim Deve ser utilizado o modo Single Window.


96

Conclusão

Para qualquer Browser existe pelo menos uma configuração com a qual é possível

realizar testes de Interface, e consequentemente teste de Fuzz, utilizando o Selenium.

O Browser que se revelou mais problemático, o Opera, é aquele que, estatisticamente é

menos utilizado.

O Mozzila Firefox e o Microsoft Internet Explorer, que representam em conjunto mais

de 50 % da utilização, funcionam sem qualquer problema. Tanto o Google Chrome como o

Safari, embora com pouca projecção estatística a nível de utilização, podem também ser

utilizados pelo Selenium.

Esta experiência permitiu detectar, que é ainda possível controlar um Browser adicional

aos requisitos, o Konqueror [42,43]

.

A.2 Operações de teste suportadas

O que se pretende com esta subsecção não é especificar todas as funcionalidades do

Selenium, pois para isso deve ser consultada a documentação relativa á sua API. O objectivo

aqui é especificar de um ponto de vista mais alto nível, as operações que estão disponíveis para

a realização de testes.

Um ficheiro de teste é composto por um conjunto de instruções de programação

executadas de forma sequencial, exactamente como no modelo clássico de Von Neumann. Estas

instruções são denominadas no contexto do Selenium por comandos.

Estes são sempre constituídos por três elementos:

Comando - Destino - Valor


97

Os comandos podem ser de três tipos:

Actions (acções): são comandos que levam à realização de algum procedimento sobre a

aplicação em teste como por exemplo "seleccionar uma opção" ou "clicar numa

determinada hiperligação". Se uma acção falha (ou se possui) um erro, o teste para e um

erro é retornado. Às acções pode ser adicionado o sufixo "AndWait". Neste caso a acção

é executada, e o Selenium esperará que o pedido HTTP seja concluído antes de

prosseguir para a próxima acção.

Acessors: são no fundo, verificadores (sem realização de juízo de valor) sobre os

elementos ou estados da aplicação. O seu valor de retorno é guardado em variáveis que

devem ser previamente definidas para o efeito. Podem ser usados para gerar asserções.

Assertions (asserções): correspondem às asserções descritas de um ponto de vista

teórico, no capítulo 2 deste documento. Avaliam o estado do sistema, comparando-o

com o estado esperado. Na definição clássica de uma asserção, quando esta falha, o

teste deve ser abortado e deve ser dado como falhado. No entanto, o Selenium permite a

utilização de asserções em três formas distintas:

o assert: modo clássico. Quando falha o teste é abortado e dado como falhado;

o verify : Efectua apenas uma verificação. Quando a condição não é verificada, o teste

não é abortado, continua sendo o erro registado;

o waitFor : levam à suspensão do teste até uma determinada condição se verificar. A

esta forma deve estar associado um contador de tempo, após o qual o teste deve

continuar registando o erro ou o teste deve simplesmente falhar.

Para se perceber correctamente como funciona um teste com o Selenium é necessário

perceber-se essencialmente dois pontos:

1. Quais as acções que o Selenium pode executar?

2. Quais os elementos possíveis para efectuar uma asserção?


98

1. Acções que o Selenium pode executar

De uma forma muito sucinta, as acções disponíveis são aquelas que um utilizador

humano poderia efectuar sobre um Browser. Não se fará aqui uma descrição funcionalidade a

funcionalidade, porque isso seria descrever a API correspondente às Client Libraries e esta é

bastante extensiva estando inclusivamente devidamente documentada na página Web oficial.

Apresenta-se então as acções associadas por tipo:

Localização de elementos numa página:

o HTML id; HTML name; Xpath;

Inserção de conteúdo numa página:

o Injecção de um novo Javascript ou código HTML;

Acções sobre o rato:

o Pressionar sem libertar qualquer um dos botões do rato:

Numa posição específica (coordenadas x,y);

Num determinado elemento qualquer da página ou Browser.

o Libertar um botão do rato;

o Simulação de seleccionar, arrastar e largar;

o Efectuar clique, duplos cliques; etc.

Acções sobre o teclado

o Pressionar e libertar teclas.

Acções sobre a janela:

o Abrir, fechar; redimensionar; actualizar;

Acções sobre cookies:

o Verificar a existência de uma determinada cookie;

o Criar uma cookie e apagar uma determinada cookie;

o Apagar todas as cookies;


99

2. Quais os elementos possíveis para efectuar uma asserção

As asserções podem ser definidas sobre:

Qualquer comando, esperando a sua correcta ou incorrecta execução;

A existência (ou não) de uma cookie;

A existência (ou não) de um elemento;

O valor de um elemento;

O tempo de carregamento da página;

O tempo de execução de qualquer acção.

O Selenium possui ainda uma serie de funcionalidades de captura e gravação de elementos

da página Web, tendo a cada método do tipo store (gravação), associados todos os três tipos de

asserções.

É então possível guardar imagens, conteúdo HTML (como títulos, cabeçalhos, etc.),

resultados de execução de scripts, as posições de determinados elementos, entre outros

constituintes de páginas Web [16]

.

A.3 Selenium e WebDriver

A utilização do Selenium promete ser a uma solução com resultados positivos a longo

prazo. As últimas publicações de versões estáveis, com correcção de erros reportados pela

comunidade de utilizadores foram feitas dentro do intervalo de tempo no qual decorreu este

projecto de Dissertação. Nestas versões foram incluídas novas funcionalidades. O mesmo se

aplica relativamente à publicação de nova e mais detalhada documentação.

Está ainda em desenvolvimento, tendo sido já publicada uma versão Beta, uma versão

do Selenium que fará uso de uma nova tecnologia. Os autores do Selenium apresentam esta

nova versão como sendo uma fusão com um outro projecto, o WebDriver [16]

.

O WebDriver é um conjunto de APIs que permitem simular ou controlar o

comportamento do Browser.

A diferença fulcral entre a utilização do Selenium Core e do WebDriver para controlar o

Browser reside essencialmente na forma de funcionamento dos mesmos. O WebDriver não é

uma aplicação Javascript a executar no Browser, em vez disso, consoante a situação em

específico, é utilizado um mecanismo tão apropriado possível. Exemplificando, no caso do

Firefox o WebDriver funciona como uma extensão, já no caso do Internet Explorer, são


100

utilizadas as funcionalidades disponibilizados pelos seus controlos de automação. Isto é, em

cada caso, são utilizadas APIs específicas do próprio Browser.

Outra possibilidade que o WebDriver oferece, é a utilização de funções do próprio

Sistema Operativo. Por exemplo, é possível, usar funcionalidades do próprio Microsoft

Windows para realizar uma acção do topo "inserir texto por pressão de teclas", tornando a

simulação da utilização do teclado muito mais aproximada do real.

Para este efeito, são disponibilizadas actualmente quatro APIs distintas. Existe a

HtmlUnitDriver que não permite ver nenhuma acção do teste simulando apenas o

comportamento de um Browser. As restantes três, controlam efectivamente um Browser, sendo

os seus nomes auto explicativos: FirefoxDriver, InternetExplorerDriver e SafariDriver.

Esta tecnologia será integrada no Selenium mantendo assim de um modo geral a mesma

arquitectura e os mesmos princípios em termos de concepção, funcionamento e execução do

teste.

Esta integração visa trazer os seguintes melhoramentos:

Suporte Multi Browser incluindo funcionalidades para controlo de Browsers não

suportados;

Tratamento de múltiplas frames, múltiplos Browsers, eventos "popup" e alertas;

Simulação de seleccionar, arrastar e largar de forma mais eficiente;

Teste em condições onde a tecnologia Ajax é utilizada.

A versão do Selenium compatível com esta tecnologia, disponível à data de início da

implementação da Plataforma, é uma versão de desenvolvimento e em fase de experimentação.

Trata-se portanto de uma versão instável com o propósito de ser testada e experimentada para

obtenção de comentários por parte da comunidade de utilizadores.

Neste sentido, esta versão não será tida em consideração para a integração na Plataforma,

porém, fica aqui devidamente documentado tanto a existência desta tecnologia alternativa ao

Selenium como a previsão da sua integração no Selenium.

Finalmente, de referir que, esta situação não traz qualquer problema ao uso do Selenium,

uma vez que se trata de uma integração de novas funcionalidades e não da alteração do modo de

funcionamento do Selenium RC em termos de concepção e execução do teste [16]

.

101

Anexo B

Informação adicional sobre o Webscarab

Este anexo existe com o propósito de explicar qual o funcionamento associado ao uso

de ficheiros de teste no Webscarab. Como já referido no Anexo A, relativamente ao Selenium,

também neste caso o objectivo não é expor a API, mas sim descrever quais as principais

funcionalidades associadas.

As operações definidas nos ficheiros de teste são realizadas com recurso a BeanShell.

Este é um interpretador da linguagem Java, atribuindo um funcionamento similar ao de uma

linguagem de scripting, isto é, directamente interpretado e não compilado.

B.1 – Operações definíveis em BeanShell no Webscarab

De uma forma muito sintética, o Webscarab permite que um pedido HTTP interceptado,

seja convertido numa cadeia de caracteres. Esta pode ser manipulada programaticamente da

forma que as necessidades estipulem. Para isso, podem ser utilizados quaisquer métodos da API

do Java.

Seria muito trabalhoso e pouco eficiente se não houvesse funcionalidades de apoio, pelo que

o Webscarab fornece já um conjunto de métodos de apoio à manipulação dos pedidos.

A seguinte lista apresenta as funcionalidades mais relevantes de apoio à manipulação de

tráfego HTTP:

Retorno do tráfego somente em caso de ser pedido;

Retorno do tráfego somente em caso de ser resposta;

Registo de dados em ficheiro;

Informação adicional sobre o Webscarab

102

Identificação do tipo de pedido (GET, POST, PUT);

Retorno para uma cadeia de caracteres de um determinado elemento do protocolo

HTTP (Ip de destino, user-agent, etc.);

Reencaminhamento de tráfego HTTP.

Finalmente, para conhecimento das funções propriamente ditas, deverá ser consultada a

documentação da API, fornecida com o código fonte ou disponível na página Web da

ferramenta [25,44]

.

103

Anexo C

Resultados das Sessões de Teste

Neste anexo estão as tabelas relativas às sessões de teste descritas no capítulo 4, Caso de

Estudo. Os dados aí apresentados devem ser interpretados de uma forma global. Porém ficam

documentados neste anexo, todos os resultados individuais obtidos nos diversos ensaios.

C.1 – Valores de cada amostra das sessões de teste


104

Tabela 20 – Comparação do tempo de execução do JIC entre Safari e Mozzila Firefox (servidor livre de

carga).

Ensaio JIC

Tempo (ms)

Safari (v4.0.4) Mozzila Firefox (v3.6.3)

1 776 1140

2 651 1180

3 703 1150

4 643 1220

5 637 1120

6 743 1120

7 625 1090

8 641 1360

9 594 1110

10 626 1140

t médio 664 1163


105

Tabela 21 – Tempos de execução do JIC no Safari com servidor em carga.

Ensaio do

JIC

Tempo Safari (ms)

Servidor sem carga

(valores da tabela 12)

Servidor com carga

(ensaio 1)

Servidor com carga

(ensaio 2)

Servidor com carga

(ensaio 3)

1 776 671 731 742

2 651 677 1040 645

3 703 683 884 618

4 643 715 873 677

5 637 726 1170 644

6 743 731 966 1470

7 625 737 681 628

8 641 905 736 635

9 594 957 791 657

10 626 998 862 819

t médio 664 780 873 754


106

Tabela 22 – Resultados descriminados de quatro sessões de teste de carga com de igual configuração.

Sessão de

teste

Número total

de pedidos

realizados

Tempo (s) Total de Erros


1

11 472 0,009 3,083 0,052 0 0

7 336 0,012 3,105 0,081 0 0

2

12 382 0,009 0,184 0,048 0 0

7 375 0,009 3,153 0,008 0 0

3

7 323 0,010 3,046 0,080 0 0

11 576 0,008 4,303 0,051 0 0

4

11 697 0,008 3,108 0,051 0 0

7 349 0,010 3,095 0,080 0 0


107

Tabela 23 - Resultados discriminados de várias sessões de teste de carga.

Sessão de

teste

Número total

de pedidos

realizados

Tempo (s) Total de Erros


1 27 703 0,006 4,327 0,219 0 0

2

571 910 0,006 0,069 0,267 0 0

577 255 0,019 3,164 0,944 0 0

307 326 0,176 2,561 1,258 0 0

3

445 473 0,005 0,584 0,169 0 0

331 785 0,008 3,611 0,308 0 0

4

422 878 0,005 9,433 0,204 54 182 12,8

217 966 0,009 9,484 0,349 15 312 7,0

438 928 0,009 9,505 0,524 51 241 11,6

289 084 0,006 9,430 0,229 20 403 7,1

232 968 0,007 9,926 0,782 12 650 5,4

5

71 324 0,004 0,520 0,154 0 0

72 194 0,013 3,324 0,731 0 0

38 789 0,047 1,775 0,891 0 0

38 023 0,007 3,477 0,237 0 0

1 442 0,007 0,481 0,235 0 0

plataforma de teste a aplicações web suportando múltiplos ... · teste de software que pudessem...

Documents