Gerenciador de Rastreamento e Interface do Executor

Como visto no tópico 6.4, na execução dos casos de testes o Gerenciador de Rastreamento e a Interface do Executor devem trabalhar em conjunto com o sistema instrumentado para gerar os rastros segmentados por ações de caso de uso.

Na forma como o protótipo foi concebido, o Gerenciador de Rastreamento deve receber tanto o rastro do programa instrumentado como os registros das ações vindos da

Interface do Executor. Para viabilizar esta tarefa de correlacionar os dados oriundos do sistema e da Interface de Executor, o Gerenciador de Rastreamento foi implementado como um serviço capaz de receber chamadas remotas em tempo-real. Desta forma o Gerenciador de Rastreamento sabe, ao mesmo tempo, a ação de caso de teste que está sendo executada e as unidades computacionais que estão sendo acionadas no sistema alvo da localização.

A infra-estrutura tecnológica que permitiu esta arquitetura de comunicação inter- processos é a interface de programação Java™ Remote Method Invocation (RMI). Através dela o Gerenciador de Rastreamento pode se registrar como um serviço e o sistema instrumentado e a Interface de Usuário são capazes de localizá-lo e invocar seus métodos remotamente.

O Instrumentador, como foi visto no tópico anterior, se encarrega de fazer com que o sistema esteja preparado para registrar a execução dos métodos. As instruções que efetuam este registro são, na verdade, invocações remotas de métodos do Gerenciador de Rastreamento que assim é informado de cada método executado internamente pelo sistema instrumentado.

A Interface de Executor, por sua vez, é um programa com uma interface de usuário que, ao ser iniciado, consulta o caso de teste que será executado da Base de Rastros e vai apresentando as ações uma a uma para o usuário. Cada vez que o executor confirma que realizará uma nova ação do caso de teste, a Interface de Executor invoca remotamente um método do Gerenciador de Rastreamento para que ele se prepare então para receber o rastro da ação. Quando o executor procede, em seguida, a execução real da ação sobre o sistema instrumentado, este envia o rastro para o Gerenciador de Rastreamento. Em seguida, a Interface de Executor apresenta outra ação do caso de teste para o executor e o processo se repete até a última ação do caso de teste.

É importante observar que as ações dos casos de testes não são livremente enviadas para o Gerenciador de Rastro. Elas seguem a ordem pré-estabelecida e registrada no caso de testes, armazenado na Base de Rastros; cabe ao executor apenas a tarefa de confirmar o envio, no momento certo, de cada nova ação que começará a ser executada. A Figura 8 mostra a caixa de diálogo que a Interface do Executor apresenta ao usuário para cada passo do caso de teste.

Figura 8 – Caixa de Diálogo da Interface do Executor

Como se pode observar no diagrama de seqüência da Figura 9, o programa instrumentado informa para o Gerenciador de Rastreamento as unidades computacionais que estão sendo executadas. Ao mesmo tempo, o mantenedor que executa o caso de teste informa, através da Interface do Executor, em que ação prevista no caso de teste ele está. O Gerenciador de Rastreamento une estas informações originadas em tempo-real em um rastro segmentado nas ações e, ao final do processo, armazena este rastro na Base de Rastros.

Figura 9 – Diagrama de Seqüência de uma Execução de Caso de Teste

A tecnologia Java™ RMI é uma forma bem documentada de comunicação inter- processos e favoreceu a implementação do protótipo, mas isso não deve ser considerado como impedimento para a adoção da técnica em outras tecnologias. Atualmente, muitas linguagens também possuem formas de se comunicar através de redes de computadores com outros processos, em um ambiente distribuído.

7.1.4. Automação da Execução dos Casos de Teste

A automação da execução de testes vem sendo adotada largamente nas organizações para agilizar e baratear os testes de grandes sistemas. Como citado no tópico 6.6.1, a

localização de casos de uso pode se utilizar deste tipo de ferramenta para melhorar a execução dos casos de testes e a coleta dos rastros segmentados.

Uma vez que todos os componentes deste protótipo foram implementados em Java™ uma ferramenta interessante para efetuar esta automação é o IBM© Rational™ Functional Tester™ (RFT). Entre suas características esta ferramenta permite a programação de scripts em Java™, incluindo a reutilização de componentes já implementados. Assim, foi possível aproveitar os componentes da Interface do Executor para fazer com que os scripts de teste fossem modificados para enviar as mensagens das ações dos casos de teste para o Gerenciador de Rastreamento; enquanto executavam os casos de teste sobre o sistema instrumentado. Do ponto de vista do Gerenciador de Rastreamento não há nenhuma diferença se a execução do caso de teste está sendo realizada por uma pessoa, com o uso da Interface do Executor, ou através de um script automatizado.

A Figura 10 apresenta uma comparação entre um script de teste automatizado comum e o mesmo script preparado para enviar mensagens ao Gerenciador de Mensagens. Na versão comum do script existem apenas as chamadas aos métodos que executam as ações do caso de teste – “button_selectPackagesubmit().click()”, por exemplo. No script modificado é acrescentada primeiramente a criação do objeto que realiza o envio de mensagens – “TraceRFTScript trace = new TraceRFTScript(14)”. Neste comando o caso de teste implementado no script é informado – o número 14, neste exemplo. Além disso, as mensagens que enviam as mensagens ao Gerenciador de Mensagem – “trace.logNextAction();” – também são incluídas no script, nos pontos adequados.

Figura 10 – Comparação entre scripts de teste do RFT

Na prática, em um ambiente real de teste do sistema, a equipe de testes poderia manter apenas o script modificado, pois ambos os scripts têm o mesmo efeito sobre a aplicação testada. Quando houver interesse em realizar a coleta de rastros para realizar as análises, basta ativar o Gerenciador de Rastreamento e executar os scripts sobre uma versão instrumentada do sistema. Já no dia-a-dia da equipe de testes, o objeto que coordena o envio das mensagens de rastreamento simplesmente se desativa sozinho se não conseguir se conectar com um Gerenciador de Rastreamento ativo, na sua inicialização; com isso, as demais chamadas não teriam nenhum efeito.

7.1.5. Analisadores

Os analisadores criados são programas em Java™ que consultam a Base de Rastros através de consultas SQL e efetuam processamentos posteriores a fim de apresentar as

informações, aplicar filtros ou fazer outras análises quantitativas. Os quatro analisadores implementados foram:

a) Execução Post-Mortem; b) Rastros Consolidados;

c) Comparação entre Casos de Uso;

d) Comparação entre Ações de Casos de Uso.

A Execução Post-Mortem dos casos de uso (a) são apresentadas na forma de páginas HTML (Figura 11), o que permite a navegação rápida para os arquivos do código fonte onde os métodos rastreados estão implementados. A tela do navegador é divida na vertical em 2 áreas: no lado direito é apresentado o método que faz parte do rastro. Os números “1.6”, “1.1”, “1.2”, indicam os fluxos e passos (1.6: fluxo 1, passo 6). Cada método é representado por um hiperlink, e a indentação indica a hierarquia de chamadas, dando uma noção de método foram invocados, em que seqüência e de que forma eles invocaram uns aos outros. Clicando no hiperlink, o lado direito carrega e apresenta o arquivo do código fonte e navega imediatamente para a declaração do método.

Figura 11 – Apresentação da Execução Post-Mortem do Caso de Uso “Escolher Pacote”

Os Rastros Consolidados (b) são apresentados de forma muito semelhante à Execução Post-Mortem, apenas com menos informações o que facilita a identificação das unidades utilizadas (Figura 12). As repetições estão suprimidas e não há qualquer indicação da hierarquia de chamadas. A representação dos métodos como hiperlinks funciona de forma semelhante e a navegação automática para o código fonte também.

Figura 12 – Apresentação do Rastro Consolidado do Caso de Uso “Escolher Pacote”

As análises comparativas implementadas (c) e (d) se basearam em um cálculo de similaridade entre casos de uso e entre ações de casos de uso. A similaridade é um valor numérico que indica o quanto dois rastros são parecidos. A forma de cálculo é simples e o resultado apresentado varia de 0% a 100%, sendo 0% quando os rastros são totalmente diferentes – sem nada em comum – e 100% quando são idênticos.

Os cálculos de similaridade deste protótipo são realizados segundo a fórmula apresentada na Figura 13. Neles são considerados apenas os rastros consolidados; ou seja, aqueles que não incluem nem repetições nem a hierarquia de chamadas dos métodos.

Figura 13 – Fórmula de Similaridade entre Rastros

O cálculo de similaridade pode ser aplicado nos diversos níveis do caso de uso. Como a coleta de rastros é segmentada no nível de ações, é possível calcular a similaridade entre rastros de ações, entre rastros de fluxos ou entre rastros de casos de uso. Cada um com um resultado diferente e independente dos demais. Em um caso extremo – teórico – é possível que um caso de uso seja muito similar a outro, mesmo que nenhuma das ações ou fluxos apresente este nível de similaridade. Neste caso os métodos rastreados em cada ação de um caso de uso

2 x Intersecção dos Rastros * 100 % Similaridade =

(2 x Intersecção dos Rastros) + Rastros Exclusivos

Intersecção dos Rastros: número de unidades computacionais presentes em comum nos dois rastros Rastros Exclusivos: número de unidades computacionais presentes em apenas um dos dois rastros

seriam usados separadamente em várias ações do outro. Assim as atividades teriam pouca similaridade entre si, mas no conjunto final dos métodos que implementam cada caso de uso haveria muitas unidades em comum.

A Comparação entre Casos de Uso (c) calcula a similaridade entre rastros de caso de uso desconsiderando a segmentação em ações. Desta forma é possível ter uma visão de mais alto nível, identificando casos de uso que compartilhem mais ou menos unidades computacionais, sem entrar no detalhe de que unidades são essas e de que forma elas são usadas.

A Comparação entre Ações de Casos de Uso (d) realiza o mesmo tipo de métrica de similaridade, mas entre ações de casos uso, incluindo ações diferentes de um mesmo caso de uso. Esta análise permite separar ações do caso de uso que são mais específicas e que, portanto, têm maior potencial de serem mais importantes para o negócio do que aquelas mais genéricas que tratam de aspectos gerais do funcionamento do sistema.

Ações que apresentam baixas similaridades com relação a ações de outros casos de uso podem ser ações que ativam processos computacionais que não são ativados em outros casos de uso. Uma determinada regra de negócio, por exemplo, que é validada apenas naquele ponto do sistema. Quando ações de um mesmo caso de uso apresentam uma alta similaridade entre si, isso pode indicar que aquele conjunto de ações colabora em algum processo específico daquele caso de uso.

Por outro lado, ações cuja similaridade em relação a ações em outros casos de uso é alta e freqüente provavelmente refletem ações mais operacionais do sistema, como navegação entre telas e outros processos que não são específicos de nenhum caso de uso.

A última análise implementada não necessitou sequer de um programa. Usando apenas comandos SQL é possível extrair diretamente da Base de Rastros métricas de uso de unidades computacionais. Por exemplo, realizando uma contagem de métodos executados por caso de uso é possível saber os métodos que são usados em todos os casos de uso e também os métodos executados em apenas um caso de uso. Este tipo de análise atinge o objetivo do trabalho de autores que julgam importante identificar as partes do código fonte específicas de um determinado conceito (WILDE e SCULLY, 1995) (EISENBARTH et al, 2003).