Upload
vudieu
View
220
Download
0
Embed Size (px)
Citation preview
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
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
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.
ii
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.
iv
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.
Paulo Luciano Simões de Carvalho
vi
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 13 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 3). ......... 93
Tabela 14 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 4). ......... 93
Tabela 15 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 5). ......... 94
Tabela 16 -Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 6). .......... 94
Tabela 17 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 7). ......... 95
Tabela 18 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 8). ......... 95
Tabela 19 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 9). ......... 95
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.
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.
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.
Figura 2 - Arquitectura de um teste do tipo Fuzz
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]
.
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
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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;
Metodologias e Ferramentas de Teste Aplicações Web
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;
Metodologias e Ferramentas de Teste Aplicações Web
24
Suporte a múltiplos Browsers: os ficheiros devem poder ser executáveis, pelo menos,
nos seguintes Web Browsers: Microsoft Internet Explorer, Mozzila Firefox, Opera,
Safari e Google Chrome;
Capacidade de interagir directamente com um servidor proxy: como praticamente
todas as ferramentas utilizadas funcionam como um servidor proxy, apenas cumprindo
este requisito, a ferramenta a utilizar permite simultaneamente que se efectuem os testes
num Browser, que já estaria a utilizar um servidor proxy. Um Browser para cada
protocolo pode apenas ter definido um e um só servidor proxy. Assim, evitar-se-iam
configurações adicionais ao nível da rede, embora estas possam existir, mas o que se
pretende é retirar esta necessidade. O cumprimento deste requisito, facilita uma das
operações propostas no capítulo 3, Concepção da Solução;
Ser executável em batch mode: isto é, após a criação de um ou vários ficheiros de
teste, estes devem poder ser executados pela ferramenta, sem intervenção humana. Esta
apenas tem de ser invocada, preferencialmente numa linha de comandos sem recurso a
uma interface gráfica. Na invocação devem ser indicando apenas os caminhos (paths)
para os ficheiros, efectuando a ferramenta todos os testes, colhendo os resultados,
reportando-os no final;
Deverá ser escrita em código aberto e ser gratuita: para que possa ser 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
Metodologias e Ferramentas de Teste Aplicações Web
25
ferramenta. Dadas as restrições de tempo e a quantidade de ferramentas disponíveis era
absolutamente necessário definir um tempo máximo de experimentação por ferramenta.
A ferramenta RadView foi imediatamente eliminada dado não ser gratuita. A BadBoy,
impõe restrições ao nível de compra de uma licença, se for utilizada em organizações com fins
lucrativos, pelo que foi também eliminada. A Doit, seguiu o mesmo caminho, visto a sua página
oficial não oferecer informação sobre o seu funcionamento, e apesar de ser referida em fóruns
de utilizadores, não se conseguiu efectuar a instalação. Pela experiência de utilização e a
dificuldade a configurar o modo batch, levou à eliminação da WebTest.
Pela análise do quadro verifica-se que as ferramentas que correspondem suficientemente
aos requisitos são o Sahi, o Selenium, o Watir e o Windmill.
No entanto, cada uma destas ferramentas possui uma desvantagem. O Watir e o
Windmill não possuem suporte a servidor proxy, logo, são candidatas mais propícias a serem
imediatamente descartadas, visto que, esse incumprimento compromete a automatização da
mistura de Captura e Repetição com teste Fuzz (na forma descrita pela figura 2).
O Selenium possibilita executar os testes em todos os Browsers mas permite apenas que
se criem usando o Mozzila Firefox. Isto advém do facto de o IDE do Selenium ser um pluggin
desse Browser e não uma aplicação Javascript genérica, como acontece nos seus concorrentes.
O Sahi não apresenta falhas, no entanto gera os ficheiros numa linguagem parecida com
Python, que é no entanto, uma linguagem desenvolvida pelos criadores do Sahi. Isto pode levar
a problemas na escrita e manipulação de ficheiros. Neste ponto, o Selenium é extremamente
versátil uma vez que, a geração é feita numa multiplicidade de linguagens.
Pesando as duas desvantagens, o Selenium fica à frente uma vez que, o objectivo do
projecto é a execução dos testes em vários Browsers e neste ponto, a ferramenta não apresenta
qualquer limitação [11, 12, 13, 14, 15, 16, 17,18]
.
Metodologias e Ferramentas de Teste Aplicações Web
26
Tabela 1 - Comparativo de ferramentas Captura e Repetição
Browsers
(execução de teste)
Browsers
(criação de teste)
Sistemas
Operativos
Automático
Ficheiros de
teste
Fonte
Proxy
Externa
Código
aberto
Gratuito
Multi
Thread
Windmill
Internet Explorer;
Firefox; Opera; Safari;
Chrome
Internet Explorer; Firefox;
Opera; Safari; Chrome
Windows; Linux;
MacOS
Sim
Python,
Javascript Python
Não (tem de ser
codificado) Sim Sim Não
Sahi Internet Explorer;
Firefox Internet Explorer; Firefox
Windows; Linux;
MacOS Sim
Linguagem
própria Java Sim Sim Sim Sim
Watir Internet Explorer;
Firefox; Safari; Chrome Existem IDEs compatíveis
Windows; Linux;
MacOS Sim Ruby BSD * Sim Sim *
Selenium
Internet Explorer;
Firefox; Opera; Safari;
Chrome
Firefox (código gerado é
independente do Browser)
Windows; Linux;
MacOS Sim
Javascript,
Ruby, Python,
C#, Java
Várias Sim Sim Sim Sim
Webtest Executou em Internet
Explorer; Firefox;* Firefox
Windows; Linux;
MacOS Sim Groovy, XML Java Sim Sim Sim Não
Badboy Independente do
Browser Independente do Browser
Trial disponível:
Windows Sim Javascript * Sim Não Não Sim
Doit * * * * * * * Sim Sim *
RadView
Internet Explorer;
Firefox; Opera; Safari;
Chrome
Internet Explorer; Firefox;
Opera; Safari; Chrome
Windows; Linux;
Solaris Sim * * * Não Não Sim
* 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.
Metodologias e Ferramentas de Teste Aplicações Web
28
Este módulo é responsável por iniciar a execução do Web Browser e por realizar as
funções de servidor proxy, actuando sobre os pedidos e respostas HTTP. Recebe as instruções
do programa executor do teste (denominado Client Driver e implementado com base nas Client
Libraries) via um protocolo denominado Selenese. Estas informações são então enviadas ao
Selenium Core para que actue sobre o Browser.
Client libraries
São na verdade um conjunto de APIs (uma por cada linguagem suportada) que
disponibilizam funções com vista a executar as diversas acções do Browser, como por exemplo,
preencher um campo com um determinado texto ou efectuar um clique do rato numa qualquer
hiperligação. A forma como estas são implementadas, tornam o ficheiro de teste independente
do Browser onde será executado.
O Selenium permite que os testes sejam definidos nas seguintes linguagens: Ruby, C#,
Java, Perl, Python e PHP.
De todas estas, será utilizado apenas o Java. Esta decisão é tomada essencialmente
porque se trata de uma linguagem extremamente utilizada, para a qual existem inúmeras APIs
sendo ainda amplamente documentada. Além disso, permite a utilização do Ant (descrição e
justificação de escolha presente mais a frente neste capítulo) que desempenhará um papel
importante na automatização do processo de teste.
Uma vez apresentados os componentes do Selenium RC, será apresentado agora, o
modo de funcionamento de um teste. Antes de se prosseguir para essa descrição, será necessário
introduzir dois conceitos: "The same origin policy" e "Proxy injection".
The same origin policy
É uma estratégia de segurança que define que um código Javascript qualquer,
descarregado de uma aplicação Web, alojada, por exemplo, em www.exemplo_um.com, não
pode efectuar pedidos (ou acções sobre conteúdo) a outra aplicação Web com domínio diferente,
por exemplo, www.exemplo_dois.com. Se tal fosse possível, tendo um utilizador, vários
separadores (ou várias instâncias de um mesmo Browser) em execução, seria possível que uma
aplicação Javascript (a executar num determinado separador) fizesse a captura de dados
privados (por exemplo, de uma conta bancária) de uma outra página a executar numa separador
diferente e os enviasse para terceiros com intenções maliciosas. Chama-se a esta acção Cross-
site scripting (XSS).
Metodologias e Ferramentas de Teste Aplicações Web
29
Proxy injection
Para evitar os problemas derivados da questão anteriormente descrita, o Selenium usa a
seguinte técnica: um servidor proxy situa-se entre o Browser que envia os pedidos e a aplicação
em teste. O proxy mascara o URL da aplicação embutindo ainda o Selenium Core, entregando a
resposta ao Browser como se ambos tivessem a mesma origem.
A figura 3 apresenta a estrutura da execução de um teste.
Selenium Core+
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);
Metodologias e Ferramentas de Teste Aplicações Web
30
4. O passo anterior resulta num pedido HTTP do Browser, a um outro domínio, que o faz
na verdade ao Selenium Server, que actua como proxy (esta técnica permite a utilização
de XSS, uma vez que para o Browser, todas as páginas pertencem ao mesmo domínio);
5. O Selenium Server pede uma página à aplicação Web em teste;
6. A aplicação Web responde ao Selenium Server;
7. O Server entrega a página ao Browser.
Recolha dos resultados do teste
O Selenium RC não dispõe de um mecanismo específico de recolha e apresentação dos
resultados dos testes. Aquilo que é pressuposto é que seja o próprio utilizador a definir a forma
de apresentação dos resultados. Esta situação facilitou no entanto, a recolha de resultados de
teste com erros de execução em teste de Fuzz. Para este projecto foi seleccionado o TestNG,
cuja justificação se encontra um pouco mais à frente neste mesmo capítulo.
O anexo A (secção A.2) apresenta uma descrição de algumas das potencialidades mais
relevantes [16]
.
Finalmente o Selenium apresenta ainda outra característica útil para este projecto. Além
de suportar todos os Browsers requisitados em diferentes ambientes, possui um modo de
invocação de drivers standard que permite controlar outros Browsers. O anexo A (secção A.1)
mostra os resultados de uma série de experiências feitas ao Selenium. A conclusão: é possível
controlar todos os Browsers especificados nos requisitos em pelo menos uma configuração
possível (Sistema Operativo – versão do Browser). É ainda possível controlar outros Browsers
(por exemplo, o Konqueror) além dos especificados. Finalmente, no mesmo anexo (secção A.3),
está presente uma análise que permite perceber que o Selenium é uma solução que irá manter-se
actualizada a longo prazo [16, 19]
.
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.
Metodologias e Ferramentas de Teste Aplicações Web
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.
Metodologias e Ferramentas de Teste Aplicações Web
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.
Metodologias e Ferramentas de Teste Aplicações Web
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.
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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
Metodologias e Ferramentas de Teste Aplicações Web
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]
.
Metodologias e Ferramentas de Teste Aplicações Web
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
Concepção da Solução
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:
Concepção da Solução
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.
Concepção da Solução
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.
Concepção da Solução
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.
Concepção da Soluçã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.
Concepção da Solução
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
Concepção da Solução
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.
Concepção da Soluçã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.
Concepção da Solução
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.
Concepção da Solução
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.
Concepção da Solução
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).
Concepção da Solução
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.
Concepção da Solução
54
Fig
Figura 14 - Resultados detalhados de uma sessão de teste de Performance, Carga e Stress.
Concepção da Solução
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
Concepção da Solução
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?
Concepção da Solução
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.
Concepção da Solução
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).
Testes de Captura e Repetição
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.
Testes de Desempenho, Carga e Stress
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.
Testes de Captura e Repetiçã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.
Testes de Desempenho, Carga e Stress
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
Mínimo Máximo Médio Número Percentagem
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
Conclusão e Trabalho Futuro
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).
Conclusão e Trabalho Futuro
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
Conclusão e Trabalho Futuro
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/,
último acesso em Janeiro de 2010.
[21] WIRESHARK em http://www.wireshark.org, último acesso em Janeiro de 2010.
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,
último acesso em Janeiro de 2010.
[24] Chinotec Technologies Company, Parosproxy – Web Application Security em
http://www.parosproxy.org, último acesso em Janeiro de 2010.
[25] OWASP, WebScarab Project em
http://www.owasp.org/index.php/Scripting_in_WebScarab, último acesso em Junho de 2010.
[26] OWASP, WebScarab Project em
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.
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.
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.
Informação adicional sobre o Selenium
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.
Opera 9.5 Não Selenium Core injectado correctamente. Não
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).
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.
Opera 9.5 Não Selenium Core injectado correctamente. Não
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.
Informação adicional sobre o Selenium
93
Sessão de teste 3
Selenium RC: v1.0.3
Sistema Operativo: Windows 7 (64 bits)
Tabela 13 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 3).
Browser Versão Execução Comentário
Internet Explorer 8.0 Sim Funciona usando os drivers para proxy.
Mozilla Firefox 3.6 Sim -
Safari 4.0.4 Sim -
Opera 9.6 Não Selenium Core injectado correctamente. Não
executa teste.
Opera 9.5 Não Selenium Core injectado correctamente. Não
executa teste.
Google Chrome 4.0.249 Sim -
Sessão de teste 4
Selenium RC: v1.0.3
Sistema Operativo: Windows Vista (32 bits)
Tabela 14 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 4).
Browser Versão Execução Comentário
Internet Explorer 7 Sim -
Internet Explorer 8 Sim Funciona usando os drivers para proxy.
Mozilla Firefox 3.6 Sim -
Safari 4.0.4 Sim É necessário desactivar o bloqueador de pop ups
na primeira execução.
Opera 9.6 Não Selenium Core injectado correctamente. Não
executa teste.
Opera 9.5 Não Selenium Core injectado correctamente. Não
executa teste.
Google Chrome 4.0.249 Sim -
Informação adicional sobre o Selenium
94
Sessão de teste 5
Selenium RC: v1.0.3
Sistema Operativo: Mac OS (64 bits)
Tabela 15 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 5).
Browser Versão Execução Comentário
Mozilla Firefox 3.6 Sim -
Safari 4.0.4 Sim É necessário desactivar o bloqueador de pop ups
na primeira execução.
Opera 9.6 Não Selenium Core injectado correctamente. Não
executa teste.
Opera 9.5 Não Selenium Core injectado correctamente. Não
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).
Browser Versão Execução Comentário
Internet Explorer 6 Sim -
Mozilla Firefox 3.6 Sim -
Safari 4.0.4 Sim É necessário desactivar o bloqueador de pop ups
na primeira execução.
Opera 9.6 Não Selenium Core injectado correctamente. Não
executa teste.
Opera 9.5 Não Selenium Core injectado correctamente. Não
executa teste.
Google Chrome 4.0.249 Sim -
Informação adicional sobre o Selenium
95
Sessão de teste 7
Selenium RC: v0.9.2
Sistema Operativo: Mac OS (32 bits)
Tabela 17 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 7).
Browser Versão Execução Comentário
Opera 8.54 Não Selenium Core não é injectado.
Opera 9.52 Não Selenium Core não é injectado.
Opera 9.6 Não Selenium Core não é injectado.
Sessão de teste 8
Selenium RC: v0.9.2
Sistema Operativo: Ubuntu 9.10 (32 bits)
Tabela 18 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 8).
Browser Versão Execução Comentário
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)
Tabela 19 - Validação do suporte do Selenium a múltiplos Browsers (Sessão de teste 9).
Browser Versão Execução Comentário
Opera 9.52 Sim Deve ser utilizado o modo Single Window.
Informação adicional sobre o Selenium
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
Informação adicional sobre o Selenium
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?
Informação adicional sobre o Selenium
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;
Informação adicional sobre o Selenium
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
Informação adicional sobre o Selenium
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
Resultados 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
Resultados das Sessões de Teste
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
Resultados das Sessões de Teste
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
Mínimo Máximo Médio Número Percentagem
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
Resultados das Sessões de Teste
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
Mínimo Máximo Médio Número Percentagem
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