Mentor de Ferramentas: Estruturando o Modelo de Implementação Utilizando o Rational TestFactory
Este mentor de ferramentas descreve como utilizar o Rational TestFactory para começar a estruturar a implementação de teste para permitir que os testes gerados sejam implementados.
Ferramenta: Rational TestFactory
Relacionamentos
Descrição Principal

Visão Geral

No Rational TestFactory, você começa a estruturar a implementação de teste utilizando o recurso "mapa de aplicativos".

Um mapa de aplicativos bem-desenvolvido reflete uma representação precisa da interface com o usuário no AUT (Aplicativo em Teste). Cada janela e controle no AUT é representado por um "Objeto UI" no mapa do aplicativo. Para obter mais informações sobre o mapa de aplicativos, consulte Mentor de Ferramenta: Configurando o Ambiente de Teste no Rational TestFactory.

Este mentor de ferramenta é aplicável durante a execução do Windows 98/2000/NT 4.0.

Para utilizar o Rational TestFactory para capturar os resultados do modelo de teste para teste automatizado:

  1. Identificar as partes do aplicativo que você deseja testar
  2. Configurar os objetos de interação para refletir os requisitos do Script de Teste
  3. Fornecer Dados de Teste para os objetos que representam controles de texto
  4. Restringir o teste de objetos especificados

1.   Identificar as partes do aplicativo que você deseja testar

Depois de desenvolver o mapa de aplicativos, você pode determinar as áreas do AUT que são apropriadas para teste no no Rational TestFactory.

Um "Piloto" é uma ferramenta do Rational TestFactory que gera automaticamente os scripts de teste. Os locais nos quais você coloca os Pilotos no mapa de aplicativos determina os controles naquele AUT que podem ser testados. Um Piloto pode testar todos os objetos de UI disponíveis no mapa que estão em ramificação no objeto pai do Piloto. Se um controle estiver representado por um objeto de UI naquela ramificação do mapa e o objeto estiver disponível, o Piloto irá testá-lo.

Revise os procedimentos de teste criados durante a tarefa Teste de Design, com o objetivo de identificar:

  • Os controles devem ser exercitados em uma ordem específica.
  • Os controles para os quais os Dados de Teste devem ser fornecidos.
  • As janelas e as caixas de diálogo nas quais os controles são exibidos.

Os objetos de UI no mapa do aplicativo que correspondem às janelas, caixas de diálogo e controles que você identifica são bons candidatos para serem testados pelos Pilotos no Rational TestFactory. Você pode especificar como o TestFactory deve testar um controle no AUT, definindo os valores de propriedade do seu objeto de UI correspondente.

Ícone de Ajuda   Consulte os seguintes tópicos na Ajuda do Rational TestFactory:

Pilotos: O que eles são e como funcionam

Disposição Eficiente do Piloto

2.   Configurar os objetos de interação para refletir os requisitos do Script de Teste

Um Script de Teste no qual todos os controles estão localizados na mesma janela é um bom candidato para teste no Rational TestFactory. Um "objeto de interação" é o recurso TestFactory que permite especificar o método de interação do Script de Teste para tais controles.

Um objeto de interação é um contêiner para o qual você pode incluir um ou mais objetos de UI como "componentes". Os componentes do objeto de interação representam os controles que precisam ser exercitados para obter um caminho específico ou executar uma tarefa específica no AUT. Depois de incluir os componentes para a interação, você pode configurá-los para atender aos requisitos do Script de Teste.

Se você tiver mais de um Script de Teste que testa os controles na mesma janela, você pode especificar os requisitos para cada Script de Teste em um objeto de interação separado. O recurso Piloto do TestFactory pode testar vários objetos de interação na mesma janela durante uma única execução do Test Suite ou do Piloto.

ícone de Ajuda   Consulte o tópico Utilizando objetos de interação para configurar testes específicos na Ajuda do Rational TestFactory:

3.   Fornecer Dados de Teste para os objetos que representam controles de entrada

O recurso Piloto do TestFactory executa tantos testes quanto a área disponível de UI do mapa para a qual ele tem acesso permitir. Por padrão, um Piloto exercita os objetos em uma ordem aleatória e fornece valores de dados aleatórios para os objetos que exigem a entrada.

Se houver controles no Script de Teste que requerem Dados de Teste específicos como entrada, você poderá utilizar um "estilo de entrada de dados" para fornecer as informações de entrada necessárias. Um estilo de entrada de dados é um grupo de propriedades do objeto de UI que especifica a entrada de teste para um objeto de UI:

  • Um caso de cadeia exigido que um Piloto do TestFactory deve utilizar.
  • Uma lista de casos de cadeia que age como um datapool que um Piloto pode escolher aleatoriamente.
  • Uma lista de casos de máscara para os quais o Rational TestFactory gera valores de cadeia que um Piloto pode escolher aleatoriamente.
  • As opções que permitem a um Piloto gerar inteiros aleatórios, pontos de flutuação e valores de cadeia.

O Rational TestFactory fornece um conjunto predefinido de estilos de entrada de dados do sistema que refletem os tipos de entrada padrão. Você pode criar estilos de entrada de dados personalizados e adicionais que são baseados nos estilos de sistema ou nos estilos personalizados existentes. Você também pode substituir as configurações em um estilo de sistema ou em um estilo personalizado para um objeto individual.

ícone de Ajuda   Consulte o tópico Utilizando estilos de entrada de dados para objetos de tipo de entrada na Ajuda do Rational TestFactory:

4.   Restringir o teste de objetos especificados

Por padrão, todos os controles no AUT representados por objetos de UI no mapa do aplicativo são qualificados para teste. Se um Piloto encontrar um objeto de UI ao seguir um caminho pelo mapa do aplicativo, o Piloto poderá incluir o objeto de UI em um Script de Teste gerado. Entretanto, seu AUT pode conter controles mapeados que os Pilotos não devem testar. Alguns exemplos são:

  • Um controle instável
  • Um controle cuja funcionalidade causa uma ação destrutiva
    (por exemplo, um controle que exclui um banco de dados)
  • Um controle que você não queira testar
    (por exemplo, um controle de impressão ou um controle que abre a Ajuda)

Se seu AUT contém tais controles, você pode excluir o objeto de UI associado do teste. Você também pode limitar as ações de teste que um Piloto executa em um controle. As propriedades do objeto de UI associado a um controle refletem as possíveis ações que um usuário pode executar no controle.

Ícone de Ajuda   Consulte os seguintes tópicos na Ajuda do Rational TestFactory:

  • Excluindo objetos de UI do teste
  • Alterar ações de teste do objeto de UI