Estrutura de Scripts de Teste

Para aumentar a capacidade de manutenção e reutilização dos Scripts de Teste, eles devem ser estruturados antes de serem implementados. Provavelmente, você encontrará ações que aparecerão em vários Scripts de Teste. Uma meta deve ser identificar essas ações para que você possa reutilizar as suas implementações.

Por exemplo, você pode ter Scripts de Teste que são combinações de diferentes ações que podem ser realizadas em um registro. Esses Scripts de Teste podem ser combinações da adição, da modificação e da exclusão de um registro:

• Adicionar, Modificar, Excluir (o script óbvio)
• Adicionar, Excluir, Modificar
• Adicionar, Excluir, Adicionar, Excluir...
• Adicionar, Adicionar, Adicionar...

Se você identificar e implementar essas ações como Scripts de Teste separados e reutilizá-las em outros Scripts de Teste, alcançará um alto nível de reutilização.

Outra meta seria estruturar os Scripts de Teste para que uma mudança no software-alvo cause uma mudança localizada e controlável nos Scripts de Teste. Esse procedimento torna os Scripts de Teste mais flexíveis a mudanças no software-alvo. Por exemplo, suponha que a parte do log-in do software foi alterada. Em todos os casos de teste que percorrem a parte do log-in, apenas o Script de Teste que pertence ao log-in deverá ser alterado.

Técnica de Registro

Para obter maior capacidade de manutenção dos Scripts de Teste, você deve registrá-los de forma que fique menos vulnerável a mudanças no objetivo do teste. Por exemplo, para um Script de Teste que preenche os campos da caixa de diálogo, há opções para passar de um campo para o próximo:

• Use a tecla TAB
• Use o mouse
• Use as teclas de aceleração do teclado

Dessas opções, algumas são mais vulneráveis às mudanças de design do que outras. Se um novo campo for inserido na tela, a opção de usar a tecla TAB não será muito confiável. Se as teclas de aceleração forem reatribuídas, elas não fornecerão um bom registro. Se o método que o mouse usa para identificar um campo estiver sujeito à mudança, talvez esse método também não seja confiável. Entretanto, algumas ferramentas de automação de teste têm registradores de scripts de teste que podem ser instruídos para identificar o campo por um método mais confiável como, por exemplo, o Nome do Objeto atribuído pela ferramenta de desenvolvimento (PowerBuilder, SQLWindows ou Visual Basic). Dessa maneira, um Script de Teste registrado não é executado por mudanças menores na interface do usuário (por exemplo, mudanças de layout, mudanças do rótulo do campo, mudanças de formatação etc.)

Testes Baseados em Dados

Muitos Scripts de Teste envolvem a inserção de vários conjuntos de dados de campo em uma determinada tela de entrada de dados para verificar funções de validação do campo, tratamento de erros, etc. Os passos do procedimento são os mesmos; apenas os dados são diferentes. Em vez de registrar um Script de Teste para cada conjunto de dados inseridos, um único registro deve ser feito e modificado para tratar vários conjuntos de dados. Por exemplo, todos os conjuntos de dados que produzem o mesmo erro devido a dados inválidos podem compartilhar o mesmo Script de Teste registrado. O Script de Teste é modificado para considerar os dados como informações variáveis, para ler os conjuntos de dados de um arquivo ou outra fonte externa, e para circular por todos os conjuntos de dados relevantes.

Se os Scripts de Teste ou o código do teste foi desenvolvido para circular por todos os conjuntos de dados de entrada e de saída, os conjuntos de dados devem ser estabelecidos. O formato normal para usar esses conjuntos de dados é o de registros de campos separados por vírgulas em um arquivo de texto. Esse formato é fácil de ler a partir dos Scripts de Teste e do código de teste; além disso, ele é fácil de criar e manter.

A maioria dos pacotes de banco de dados e planilha pode produzir a saída textual separada por vírgulas. O uso desses pacotes para organizar ou capturar os conjuntos de dados tem duas vantagens importantes. A primeira é que eles fornecem um ambiente mais estruturado para inserir e editar os dados do que simplesmente para usar um editor ou um processador de textos. A segunda é que a maioria tem a capacidade de consultar os bancos de dados existentes e capturar os dados retornados, permitindo uma maneira fácil de extrair os conjuntos de dados das fontes existentes.

Manipulação de Erro

O Script de Teste registrado é seqüencial na sua execução. Não há pontos de ramificação. O tratamento de erros graves nos Scripts de Teste exige uma lógica adicional para responder às condições de erro. A lógica da decisão que pode ser empregada quando ocorrem erros inclui:

• Ramificar para outro Script de Teste.
• Chamar um script que tenta eliminar a condição de erro.
• Sair do script e iniciar o próximo.
• Sair do script e do software, reiniciar e retomar o teste no próximo Script de Teste após o script que falhou.

Cada técnica de tratamento de erros exige a lógica do programa adicionada ao Script de Teste. Essa lógica deve se restringir o máximo possível aos Scripts de Teste de alto nível que controlam a seqüência de Scripts de Teste de nível mais baixo. Esse procedimento permite que Scripts de Teste de nível mais baixo sejam criados completamente a partir do registro.

Sincronização e Planejamento de Scripts de Teste

Geralmente, ao fazer o teste de stress, é recomendável sincronizar os Scripts de Teste para que eles comecem em momentos predefinidos. Os Scripts de Teste podem ser modificados para começar em um determinado momento, comparando o momento inicial desejado com a hora do sistema. Nos sistemas em rede, cada estação de teste compartilhará, através da rede, o mesmo relógio. No próximo exemplo (de um script gravado em BASIC), instruções foram inseridas no início de um script para suspender a execução do script até alcançar a hora necessária.

InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
   DoEvents
Loop
[Iniciar script]

Nesse exemplo, a hora inicial exigida é armazenada em um arquivo. Esse procedimento permite que a hora inicial seja alterada sem mudar o Script de Teste. A hora é lida e armazenada em uma variável denominada StartTime$. O loop Do While continua até que a hora inicial seja alcançada. A instrução DoEvents é importante: permite que tarefas de segundo plano sejam executadas enquanto o Script de Teste está suspenso e aguardando o início. Sem a instrução DoEvents, o sistema ficaria sem resposta até que a hora de início fosse alcançada.

Testando e Depurando Scripts de Teste

Quando os Scripts de Teste registrados recentemente são executados no mesmo software em que foram registrados, não deve haver erros. O ambiente e o software são idênticos a quando foram registrados. Podem existir instâncias em que o Script de Teste não é executado com sucesso. O teste dos Scripts de Teste revela esses casos e permite que os scripts sejam corrigidos antes de serem usados em um teste real. Dois tipos comuns de problemas são abordados aqui:

• A ambigüidade nos métodos usados para selecionar os itens em uma interface de usuário pode fazer os Scripts de Teste funcionarem de maneira diferente na reprodução. Por exemplo, dois itens reconhecidos pelo texto (ou legenda) podem ter um texto idêntico. Haverá ambigüidade quando os scripts são executados.
• Os dados específicos da execução de teste/sessão são registrados (ou seja, um ponteiro, data/carimbo ou algum outro valor de dado gerado pelo sistema), mas é diferente na reprodução.

As diferenças de hora no registro e na reprodução podem causar problemas. O registro de um Script de Teste é um processo inerentemente mais lento do que sua execução. Às vezes, essa diferença de hora resulta na execução do Script de Teste antes do software. Nesses casos, os Estados de Espera podem ser inseridos para controlar o Script de Teste com a velocidade do software.