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.

Metodologias e Ferramentas de Teste Aplicações Web

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

Metodologias e Ferramentas de Teste Aplicações Web

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

Metodologias e Ferramentas de Teste Aplicações Web

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.

Metodologias e Ferramentas de Teste Aplicações Web

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