* Miguel Argollo Jr., Carlos J. M. Olguin, Ari de M. Villaça e Daniel Weller

Orientação a objetos, análise essencial de sistemas, linguagens de 4ª geração, desenvolvimento incremental, prototipação rápida, etc. Não importa o método ou a tecnologia empregados, erros continuarão ocorrendo nos programas de computador desenvolvidos. Erros não são cometidos apenas no desenvolvimento inicial de um programa, mas também em sua fase de manutenção e evolução. Quem nunca ouviu falar de um erro que apareceu em uma nova versão de um aplicativo, em um ponto do programa aparentemente não afetado pelas alterações realizadas? A única maneira prática de garantir que nenhum erro foi introduzido na nova versão de um programa é testá-la completamente.

O processo de teste de programas, como qualquer processo repetitivo, é melhor realizado quando automatizado, por diversas razões, entre as quais:

·quando um teste encontra algum erro, é fundamental que o teste possa ser reproduzido com exatidão;

·testes manuais, que dependem totalmente da capacidade de observação de seres humanos, não são confiáveis;

·a automação tem um impacto positivo nos custos do processo de teste e na qualidade dos produtos obtidos.

O teste de programas de computador com interfaces gráficas apresenta dificuldades adicionais, porque a complexidade deste componente de software, que permite a manipulação direta de objetos com resposta ao usuário em tempo real e programação dirigida por eventos, é responsável por uma explosão combinatorial de cenários com as possíveis interações que devem ser testadas.

Neste artigo será apresentado um tipo de ferramenta que permite a automação de testes de programas de computador com interfaces gráficas.

FERRAMENTAS DE AUTOMAÇÃO DE TESTES

Essas ferramentas utilizam o método "gravar e repetir" para capturar tanto as ações do usuário sobre a interface quanto os resultados dessas ações. O conjunto de ações e resultados capturados são gravados em arquivos denominados scripts de teste. As ferramentas permitem a repetição das ações do usuário e a comparação dos resultados obtidos através da execução automática dos scripts de teste.

Ferramentas deste tipo são capazes de realizar, por exemplo, teste exaustivo para valores possíveis em um determinado intervalo, reproduzir exatamente o mesmo teste inúmeras vezes, ou mesmo ficar testando um programa ininterruptamente durante sua fase de testes com um mínimo de assistência humana.

Um cenário típico e simplificado de utilização destas ferramentas é o seguinte: com a primeira versão de um aplicativo funcionando corretamente, o operador da ferramenta executa o plano de teste do aplicativo, previamente preparado; a ferramenta, operando no modo de gravação, captura tanto as ações do operador (basicamente, eventos nos elementos da interface e texto digitado em campos de entrada de dados) quanto os resultados alcançados pelo aplicativo, teoricamente corretos, e gera o script de teste correspondente, capaz de reproduzir todas as ações realizadas pelo operador e gravadas pela ferramenta.

Suponhamos que uma nova versão do aplicativo é gerada sem alterar sua interface com o usuário. A ferramenta pode testar essa nova versão a partir do script de teste obtido anteriormente. Neste processo todas as ações gravadas no script de teste são executadas novamente com a nova versão do aplicativo, e os resultados obtidos são comparados com os resultados anteriormente gravados. A ferramenta identifica e comunica as possíveis diferenças de funcionamento entre as versões do aplicativo, uma tarefa pouco confiável quando realizada repetidamente por operadores humanos. Essas mudanças de funcionamento do aplicativo são chamadas de falhas de teste.

O cenário apresentado procurou dar uma idéia geral do uso deste tipo de ferramenta; sendo um cenário simplificado, deve ter levantado algumas dúvidas que vamos tentar abordar agora.

Toda a funcionalidade do aplicativo, tanto a correta quanto a incorreta, é gravada pela ferramenta; se a versão do aplicativo utilizada para gerar o script contiver erros, o script gerado irá capturar resultados incorretos.

Melhores resultados são obtidos quando for utilizado um plano de teste que exercite de uma maneira abrangente todo o aplicativo. Esse plano de teste deve ser preparado durante a fase de desenvolvimento do aplicativo, se possível, por uma equipe distinta da equipe de desenvolvimento.

Vários tipos de verificação sobre os elementos da interface gráfica podem ser obtidos :

·estado dos elementos da interface (push buttons ou radio buttons ligados, elementos ativos ou visíveis, etc.);

·conteúdo de mensagens em janelas de diálogo ou advertência;

·conteúdo de áreas gráficas (bitmaps);

·conteúdo de arquivos de dados; etc.

É esta capacidade que permite a identificação de diferenças de comportamento entre distintas versões do aplicativo.

O que acontece com o script de teste quando o aplicativo sofre alguma alteração que modifique sua interface gráfica?

Modificações simples, tais como mudança no tamanho ou posição dos elementos da interface, não exigem nenhuma alteração no script gerado. Porém, modificações estruturais, tais como criação de novos elementos ou a remoção de elementos existentes, exigem alterações no script para que ele reflita a nova estrutura da interface gráfica. Entretanto, o script só precisa ser alterado nos pontos relacionados com as mudanças realizadas, e o resto do mesmo continua a funcionar normalmente.

Algumas dessas ferramentas utilizam linguagens de programação tradicionais, como C ou Visual Basic, para o desenvolvimento dos scripts, ao passo que outras ferramentas utilizam linguagens desenvolvidas especificamente para o teste de programas de computador.

Algumas linguagens utilizadas são bastante complexas, podendo apresentar cerca de 200 primitivas específicas para a automação de testes. Os scripts de teste gerados podem ser considerados como um programa normal, apresentando comandos que controlam o fluxo de execução do programa de teste, sub-rotinas, passagem de parâmetros, etc., além das construções orientadas para o teste de programas de computador.

As linguagens apresentam características que permitem a realização de testes de desempenho dos aplicativos. É possível, por exemplo, definir as faixas aceitáveis para a performance de um sistema cliente/servidor, rodar scripts aumentando ou diminuindo o número de clientes e descobrir quando a performance começa a degradar. Um conjunto de teste desenvolvido para uma determinada configuração de software e hardware pode ser utilizado para avaliar se uma modificação de hardware ou uma atualização de software impacta de modo significativo a performance do sistema.

Uma característica dessas ferramentas é a dificuldade que elas têm em capturar diretamente o comportamento de objetos compostos, planilhas, por exemplo, uma vez que tal comportamento não é padronizado. Soluções para este problema podem ser obtidas com recursos avançados oferecidos pelas ferramentas.

Exemplos de ferramentas que se destacam são WinRunner, da Mercury Interactive Inc. (pela fatia de mercado em termos financeiros), SQA Team Test, da Software Quality Automation Inc. (pela base instalada) e QA-Partner, da Segue Software Inc. (pela abrangência das plataformas suportadas).

ESTRUTURANDO SCRIPTS DE TESTE

A maneira mais indicada de estruturar um script de teste é através de cenários; cada cenário representa uma tarefa, por exemplo: a digitação do código de um funcionário em uma janela de entrada de dados e a ativação de uma janela de diálogo com a informação de seu salário ou com uma mensagem de erro.

Normalmente são necessários vários testes para se estabelecer se uma determinada função do aplicativo foi implementada corretamente ou não. Tais testes levam o aplicativo até um determinado ponto (por exemplo, a ativação de uma janela de entrada de dados), o fornecimento de dados para o aplicativo (por exemplo, a digitação do código de um funcionário) e o exame dos resultados do aplicativo (salário do funcionário na base de dados ou mensagem de erro). Mesmo um cenário tão simples quanto este precisa ser testado em, pelo menos 4 situações distintas: funcionário existente na base, funcionário não existente, código nulo ou código com caracteres inválidos. É fácil perceber que cenários mais complexos exigem uma quantidade muito maior de testes.

Com a utilização destas ferramentas basta gravar uma única interação - código do funcionário na base - e alterar, com a utilização de um editor de texto, por exemplo, os comandos gerados para contemplar os outros 3 casos. Se a linguagem da ferramenta permitir, o script básico gerado pode ser manualmente transformado em uma sub-rotina, que pode ser chamada várias vezes, uma por cada teste necessário para o cenário. No exemplo dado acima, a sub-rotina seria chamada 4 vezes, e seus parâmetros seriam valores para o campo de código do funcionário e a respectiva mensagem na janela de diálogo (com o salário do funcionário ou uma mensagem de erro). Uma solução deste tipo dá origem a scripts menores e de mais fácil manutenção, mas exige um profissional com experiência em desenvolvimento de software capaz de projetar uma estrutura modular para o script, de forma semelhante à que ocorre durante o projeto de um programa de computador.

EXPERIÊNCIA DO CTI

Até que ponto ferramentas para a automação de teste de aplicativos são eficazes? Que nível de automação elas conseguem obter? Qual o auxílio que elas fornecem para os processos de teste e de garantia de qualidade? Para responder essas questões selecionamos uma ferramenta, QA-Partner, desenvolvida pela Segue Software Inc., e realizamos experiências com ela. Esta seção apresenta algumas das conclusões obtidas.

QA-Partner é uma ferramenta multi-plataforma, que não só se encontra disponível nas principais plataformas existentes, mas também permite a portabilidade dos scripts obtidos. Desta forma, um script gerado em uma plataforma pode ser transportado, sem modificações, para outras plataformas se o aplicativo associado também precisar ser transportado. Essa característica, marcante na ferramenta, foi fundamental para nossa escolha, devido ao nosso interesse na área de portabilidade de interfaces gráficas (vide "Portabilidade de Interfaces Gráficas", Byte do Brasil, abril, 1996).

QA-Partner utiliza uma linguagem de programação orientada para o domínio de testes de programas de computador chamada 4Test. Esta linguagem, orientada a objetos, possui uma estrutura bastante semelhante à da linguagem C. 4Test possui os tipos de dados predefinidos tradicionais (integer, boolean, array, record, etc.) além de outros tipos específicos para teste de programas com interfaces gráficas (guitype, windclass, window, etc.).

Os comandos da linguagem que controlam o fluxo de execução do script de teste são bastante semelhantes aos comandos encontrados na maior parte das linguagens de programação: if-then-else, while, case, break, continue, etc. A linguagem possui cerca de 200 primitivas específicas para a área de teste de programas de computador, tais como:

• VerifyActive, que verifica se uma determinada janela se encontra ativa;

• VerifyValue, que verifica o estado de check boxes, radio buttons, mensagens em janelas, etc.;

• VerifyBitmap, que verifica se a imagem de uma janela é identica a um bitmap gravado em um arquivo.

A linguagem implementa chamadas de sub-rotinas, e na realidade um script de teste desenvolvido em 4Test pode ser considerado um programa de computador convencional, exigindo uma equipe com experiência em desenvolvimento de software para estruturá-lo de modo a facilitar sua posterior manutenção. Um detalhe

interessante é que a ferramenta é distribuída com um depurador para sua linguagem, útil para encontrar problemas no scripts e que oferece funções para marcar pontos de parada no script (break-points) e para verificar valores de variáveis do script.

DESENVOLVENDO SCRIPTS DE TESTE

O primeiro passo para o desenvolvimento de casos de teste com essa ferramenta é a declaração dos elementos da interface (menus, dialog boxes, buttons, etc.) do aplicativo para o qual o script está sendo gerado. Este passo permite que os objetos presentes na interface sejam referenciados por nomes mnemônicos e facilita o desenvolvimento de scripts de teste robustos, uma vez que mudanças de posição, tamanho e rótulo dos objetos na interface não irão impactar de modo significativo os testes já desenvolvidos.

Este passo pode ser executado diretamente com a ferramenta no modo de gravação; para tanto, basta ativar a ferramenta e o aplicativo e posicionar o cursor na janela deste último. A ferramenta gera automaticamente a declaração de todos os elementos da interface gráfica do aplicativo, conforme apresentado na figura 1. A partir deste ponto, os elementos da interface gráfica podem ser referenciados por seus nomes mnemônicos.

A figura 1 apresenta em 1º plano a janela da ferramenta e a janela do aplicativo no plano inferior, parcialmente encoberta,. As informações capturadas pela ferramenta estão listadas em sua janela interna.

O próximo passo é a geração do script de teste propriamente dito, que também pode ser obtido diretamente com a ferramenta no seu modo de gravação. Para tanto, basta ativar a ferramenta e executar o aplicativo. Todos os eventos submetidos ao aplicativo são gravados pela ferramenta. A figura 2 apresenta um trecho do script de teste gerado pela ferramenta.

MainWin("Exemplo").TextField("Razão Social").SetText ("Fundação CTI");

MainWin("Exemplo").TextField("CGC")

.SetText("10.838.947/0001-53");

MainWin("Exemplo").RadioList("Tipo

de empresa").Select ("Pública");

Figura 2. Trecho de script de teste.

O trecho gerado representa a digitação dos valores "Fundação CTI" e "10.838.947/0001-53" nos campos "Razão Social" e "CGC" e da seleção do radio button "Pública" no campo "Tipo de empresa" da interface do aplicativo apresentado na figura 1 . Os comandos fazem menção aos objetos da interface através de seus nomes mnemônicos "Razão Social", "CGC" e "Tipo de empresa", capturados na fase anterior. Note que na figura 1 , que representa a declaração dos elementos da interface, esses nomes aparecem na coluna mais à direita da janela interna da ferramenta. As palavras em negrito representam primitivas da linguagem 4Test.

Neste passo, os resultados gerados pelo aplicativo também são gravados para posterior comparação.

Note que o script usa diretamente os nomes dos objetos da interface gráfica. Por exemplo, o comando:

MainWin("Exemplo").PushButton("Próximo").Click (); especifica um evento, clique no botão "Próximo" da janela "Exemplo".

O script de teste pode ser obtido manualmente a partir da especificação do aplicativo, sem o uso da ferramenta. Esta opção tem várias vantagens, entre as quais o fato do script obtido ser menos imune a erros de funcionamento do aplicativo e o fato de não ser necessário que este se encontre funcionando para se iniciar o desenvolvimento do script de teste, quando talvez não haja tempo hábil para a realização desta tarefa de modo apropriado.

Entretanto, estas vantagens ficam de certa forma comprometidas pela carga de trabalho adicional que supõe gerar o script sem o auxílio da ferramenta. Uma solução intermediária pode ser obtida com o uso de protótipos do aplicativo para geração do script básico de teste. Este script pode ser estruturado e expandido em paralelo ao desenvolvimento do aplicativo.

REPETINDO TESTES

O script de teste gravado pode ser reexecutado pelo modo de repetição da ferramenta, que manipula o aplicativo selecionando itens do menu, check boxes, radio buttons, entrando texto em campos de entrada de dados, e examinando os resultados obtidos, de forma semelhante à realizada por um ser humano.

A ferramenta, neste modo de operação, precisa da intervenção de um operador somente para ser ativada e iniciar o processo de teste, podendo continuar funcionando sem nenhum outro tipo de intervenção por parte do operador.

Este módulo também grava os resultados do teste em um arquivo de relatórios, indicando o tempo necessário para sua realização e os resultados obtidos.

O passo final do uso da ferramenta é o exame dos resultados obtidos no arquivo de relatório gerados. A Figura 3 apresenta um exemplo desse tipo de relatório.

Os resultados são apresentados na janela inferior da ferramenta. A primeira linha desta janela informa a data e o horário em que os testes foram realizados. As linhas seguintes mostram os resultados obtidos pela execução dos scripts. Note que o script "goto.t" apresentou dois erros, o que significa que em duas ocasiões os resultados obtidos foram diferentes dos resultados gravados anteriormente.

RESUMINDO

Existem disponíveis tecnologias e ferramentas para a automação de teste de aplicativos com interface gráfica, e a utilização das mesmas tem um impacto positivo nos custos do processo de teste e na qualidade dos produtos gerados. Entretanto, é necessária uma equipe com experiência em desenvolvimento de software para a plena utilização das potencialidades oferecidas. Não existe uma ferramenta que seja nitidamente superior às demais em todas as situações, e a escolha da ferramenta mais adequada depende tanto das características dos aplicativos para os quais se deseja automatizar a fase de teste quanto do processo de teste utilizado. Finalmente, a simples utilização de ferramentas como as descritas não será capaz, por si só, de promover uma significativa melhoria na qualidade dos produtos desenvolvidos se não for acompanhada pela adoção de uma metodologia de trabalho que reconheça a importância da fase de teste na qualidade dos programas de computador desenvolvidos.

* Este artigo foi originalmente publicado na revista Byte Brasil, vol 5, n° . 7,em julho de 1996. Embora a tecnologia associada tenha evoluído desde então, com o surgimento de novas ferramentas e a evolução das ferramentas existentes, os autores acreditam que os conceitos apresentados continuam válidos.

Os autores, da Fundação CTI, trabalham no Programa de Qualidade e Produtividade em Software. O principal objetivo deste programa é ajudar às empresas produtoras de software a utilizar tecnologia avançada para a produção de programas de computador. Eles podem ser contatados pelo telefone (019) 240-1011 r.170, pelo fax (019) 240-1464.