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.
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.
Concepção da Solução 54 Fig
Concepção da Solução
55