Plataforma de teste a aplicações web suportando múltiplos web-browsers

(1)

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)

(2)

(3)

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

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

(4)

(5)

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.

(6)

(7)

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.

(8)

(9)

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.

(10)

(11)

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

(12)

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

(13)

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

(14)

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

(15)

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

(16)

Lista de Tabelas

(17)

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}

(18)

Abreviaturas e Símbolos

(19)

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

(20)

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.

(21)

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].

(22)

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

(23)

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

(24)

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

(25)

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

(26)

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

(27)

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

(28)

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.

(29)

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.

(30)

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.

(31)

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.

(32)

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.

(33)

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.

(34)

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.

(35)

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

(36)

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

(37)

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.

(38)

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

(39)

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

(40)

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;