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:
-
Identificar as partes do aplicativo que você deseja testar
-
Configurar os objetos de interação para refletir os requisitos do
Script de Teste
-
Fornecer Dados de Teste para os objetos que representam controles de texto
-
Restringir o teste de objetos especificados
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.
Consulte os
seguintes tópicos na Ajuda do Rational TestFactory:
Pilotos: O que eles são e como funcionam
Disposição Eficiente do Piloto
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.
Consulte o tópico
Utilizando objetos de interação para configurar testes específicos na Ajuda do Rational TestFactory:
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.
Consulte o tópico
Utilizando estilos de entrada de dados para objetos de tipo de entrada na Ajuda do Rational TestFactory:
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.
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
|