Engenharia de Teste de Software com o IBM Rational Functional Tester: Aprimoramentos Gerais de Script.
Este capítulo é do livro.
Este capítulo é do livro.
Este capítulo é do livro & # xF501;
Esperando que os objetos de teste cheguem à existência.
Quando os objetos GUI não são renderizados em tempo hábil, você simplesmente deseja que seu script aguarde até que eles apareçam. O Capítulo 1 discutiu os prós e contras do uso de configurações globais de atraso (por exemplo, usando as configurações de reprodução do Rational Functional Tester). Você também acabou de aprender a usar o método sleep () na seção anterior. Isso é útil porque o atraso é específico de um script, liberando suas dependências nas configurações da ferramenta global. No entanto, é um atraso estático. Ele aguarda até que um determinado número de segundos decorrer, independentemente de o objeto da GUI aparecer mais cedo ou não. Esta seção discute um meio feliz entre as configurações globais de atraso e o método sleep ().
A API do Rational Functional Java fornece um método waitForExistence () útil ou uma função WaitForExistence () se você estiver usando o VB. NET. Em ambos os casos, ele vem em duas variantes. Um depende das configurações globais de reprodução. O outro é específico do script.
Para usar esse método, você precisa chamá-lo de um objeto de teste. Simplificando, você precisa dizer ao seu script qual objeto aguardar. Você pode digitar o nome do objeto, seguido de abrir e fechar parênteses, diretamente no seu código e pressionar a tecla period, ou simplesmente colocar o cursor no script onde deseja que o comando vá, clique com o botão direito do mouse no teste. objeto na pasta Objetos de Teste (na visualização Explorador de Script) e clique em Inserir no Cursor no menu exibido. Qualquer uma dessas duas opções exibe uma janela suspensa do IntelliSense (algumas pessoas referem-se a isso como "código completo & # 8221;). Esta janela fornece uma lista de métodos e funções que você pode chamar. Digitar a palavra espera mostra os métodos e funções que começam com a espera. O método waitForExistence () está entre eles. As Figuras 3.3 e 3.4 mostram como chamar o método waitForExistence (), usando os ambientes Eclipse e. NET Studio, respectivamente.
Se você usar a linguagem Java, precisará acrescentar um ponto-e-vírgula no final da linha. Se você usa a linguagem VB. NET, você está pronto e não há mais nada a fazer. A Listagem 3.2 mostra como o comando se parece no mesmo script do Rational Functional Tester, usando Java e VB. NET, respectivamente.
Listagem 3.2. Usando waitForExistence () / WaitForExistence () em um script.
Na Listagem 3.2, ClassicsJava () é um objeto de teste, representando a janela principal do aplicativo. Você chama o método waitForExistence () deste objeto de teste para informar ao seu script que ele precisa aguardar até que esse objeto apareça, antes de executar a próxima linha. O valor desse método é que ele continua imediatamente a execução do script depois que o objeto de teste é renderizado na tela (versus espera de um período de tempo estático). No entanto, essa variante específica do método depende das configurações de atraso global acessadas a partir das configurações de reprodução primária do Rational Functional Tester. As Figuras 3.5 e 3.6 mostram essas opções para Java e VB. NET.
As duas últimas configurações são específicas para o método waitForExistence () / WaitForExistence (). Se você quiser alterar o tempo de espera ou a frequência de verificação da existência de um objeto de teste, basta substituir os padrões e fornecer seus próprios valores. Você deve observar que o uso dessa variante do método mantém você dependente das configurações globais do Rational Functional Tester.
Para se tornar específico do script, você usaria a segunda variante desse método & # 8212; waitForExistence (double arg0, double arg1). Isso permite que você forneça a quantidade máxima de tempo que a reprodução do script espera pelo objeto a ser renderizado (ou seja, arg0). Você também insere a quantidade de tempo que espera entre as tentativas de localizar o objeto de teste (ou seja, arg1). Você especifica esses dois valores usando segundos. O uso dessa versão do método mantém seus scripts independentes dos valores nas configurações de atraso global do método waitForExistence (). A Listagem 3.3 mostra como isso ficaria em Java e VB. NET.
Listagem 3.3. Usando a versão específica do script de waitForExistence () / WaitForExistence () em um script.
Você pode ver que seu script agora aguarda a janela principal (por exemplo, classicsJava) do aplicativo por no máximo 180 segundos, procurando por ele a cada dois segundos.
Dos três tópicos de sincronização que você viu até agora, este é o mais desejável. Ele fornece a você a capacidade de fazer com que seus scripts esperem até que um objeto de teste apareça ao invés de aguardar uma quantidade de tempo estática. Além disso, ele permite que você se torne específico do script, permitindo que qualquer testador em sua equipe o execute sem ter que ajustar as configurações globais de atraso de reprodução.
O Rational Functional Tester e o WaitForexistence não funcionam para o processo Ajax.
Technote (resolução de problemas)
Problema (resumo)
Esta nota técnica afirma que a WaitForexistence não funciona para processos Ajax no IBM & reg; Rational & reg; Testador Funcional (RFT).
Alguns dos aplicativos Ajax possuem botões de opção que podem preencher o campo Selecionar texto. O RFT também pode registrar as caixas de seleção e o texto no campo de texto selecionado. No entanto, durante o tempo de reprodução, o RFT não conseguiu encontrar o texto selecionado no campo de texto selecionado.
Isso ocorre porque o RFT não esperará até que o campo Selecionar o texto seja preenchido. Usando este método (document_htmlDocument (). WaitForAjaxPendingRequests ();) em um Script, pode não ajudar.
O RFT encobre todos os pedidos AJAX gerados a partir de documentos HTML por qualquer ação e, em seguida, passa o pedido HTTP xml empacotado. O aplicativo definiu algumas APIs do AJAX para abort (), addEventListener () e removeEventListener (). Existem alguns problemas no empacotamento da solicitação xml http para essas APIs.
Resolvendo o problema.
Esse problema foi identificado como um defeito do produto no APAR PK55901. Foi resolvido no iFix02 para o RFT 7.0.1.2.
Usando o IBM Rational Functional Tester.
Entendendo e usando o método TestObject. find.
Publicado em 11 de julho de 2006.
O método TestObject. find é um Java & # 8482; método que o IBM & # 174; Racional & # 174; A ferramenta Functional Tester (RFT) usa para localizar um TestObject no aplicativo em teste (AUT) dinamicamente, em tempo de execução. Ao usá-lo, você evita a necessidade de registrar ações para adicionar o TestObject ao Mapa de Objetos.
Os objetos mapeados usam propriedades de reconhecimento estáticas armazenadas e hierarquias de objetos para verificar se o script usa o controle correto durante a reprodução. Embora o reconhecimento de objetos seja rápido com objetos gravados, a atualização das propriedades pode ser demorada, especialmente quando você precisa alterar os valores de peso da propriedade ou as propriedades de texto de um objeto para valores de expressão regular (Regex). O método find oferece a opção de eliminar a maioria dos controles gravados do Mapa de Objetos.
O método TestObject. find é mais robusto na versão 6.X do RFT. O desempenho agora é quase igual ao de usar um objeto mapeado.
Benefícios do uso do método find.
Uma das melhores razões para usar o find em vez do Object Map é que você pode alterar facilmente as propriedades de reconhecimento dos controles armazenados em arquivos Java ou de propriedades. A vantagem é que você não precisa alterar as propriedades de reconhecimento armazenadas em um Mapa de Objetos, evitando assim a maneira mais tediosa e demorada de usar a UI do Mapa de Objetos para fazer as alterações ou regravar o objeto para atualizá-lo.
Entendendo e usando o find.
Para entender o método find e seu relacionamento com um objeto mapeado, pense em um controle em seu aplicativo que provavelmente será alterado, portanto, será necessário atualizar um Mapa de Objetos. O controle pode ser algo simples, como um aplicativo que possui um botão de comando do usuário com um rótulo que muda de release para release. Por exemplo, talvez seu AUT inclua uma caixa de diálogo que envolva um botão rotulado como Abrir. Na versão anterior, esse botão estava rotulado como OK. Para a próxima versão, o botão ainda será rotulado como Aberto, mas também haverá um novo botão chamado Abrir com.
Se você gravou o botão OK no Mapa de Objetos, precisará alterar as propriedades de reconhecimento para acomodar as alterações de rótulo, além de precisar registrar o novo botão Abrir com. (Para este exemplo, estamos ignorando possíveis alterações na hierarquia de objetos no aplicativo que resultam das alterações da interface do usuário.)
Em seguida, suponha que essa caixa de diálogo também mencione outros botões, como Cancelar e Ajuda. Você pode ver que os botões podem ser diferenciados por seus rótulos, mesmo que apareçam no diálogo do aplicativo em uma ordem diferente no futuro. Portanto, contanto que você possa diferenciar entre os botões pelas palavras nos rótulos, não é necessário se preocupar com a propriedade de índice ou com quaisquer outras propriedades.
Explorando encontre com ClassicsJavaA.
Você também pode usar o RFT para capturar informações sobre os controles que você pode precisar encontrar posteriormente. Para esta ilustração, use o aplicativo de amostra ClassicsJavaA fornecido com o RFT e siga estas etapas.
Crie um script temporário de Teste Funcional Vazio para manter seu Mapa de Objetos enquanto trabalha na definição das propriedades dos botões. No menu do script de teste vazio, selecione Script & gt; Abra o mapa de objetos de teste. Em seguida, selecione Aplicativos & gt; ClassicsJavaA para iniciar o aplicativo. Clique no botão Fazer pedido. Clique no botão OK na caixa de diálogo Logon de membro.
O diálogo Colocar um Pedido agora deve ser exibido. Você pode usar este diálogo para ver como usar o find para localizar os botões na caixa de diálogo e para obter um TestObject para cada controle.
Figura 1. O diálogo Colocar um Pedido no aplicativo ClassicsJavaA.
Você verá três botões nesta próxima caixa de diálogo: Itens Relacionados, Fazer Pedido e Cancelar. Observe os botões conforme eles aparecem em um Mapa de Objetos e prossiga com estas etapas:
No Mapa do objeto de teste particular, selecione Objeto de teste & gt; Inserir objeto (s) no menu. Arraste o controle Localizador de Objetos pela caixa de diálogo Colocar um Pedido, movendo-o para a barra de título, de forma que toda a caixa de diálogo fique envolta em um contorno vermelho e solte o botão do mouse. Agora, no diálogo Inserir um objeto GUI no mapa de objetos, selecione Incluir todos os objetos disponíveis nessa janela e clique em Concluir. Clique no botão Fazer pedido.
Agora você deve ter um objeto javax. swing. JFrame no seu Mapa de Objetos. Selecione o controle JFrame para que você possa examinar as propriedades de reconhecimento do diálogo. Para esse controle, o rótulo ou texto é o mais significativo de dois atributos que definem o controle. O segundo atributo importante é a classe do controle, porque pode haver muitos objetos JFrame exibidos, mas provavelmente apenas um chamado Colocar um Pedido. Continue com estas etapas:
Expanda a hierarquia para encontrar os rótulos dos botões. Selecione o botão Cancelar para examinar as propriedades de reconhecimento que o RFT usa para descrever o botão no Mapa de Objetos. Existem quatro propriedades listadas, duas das quais são cruciais para definir o botão correto: as propriedades class e accessibleContext. accessibleName (veja a Figura 2).
Figura 2. Exemplo de um Mapa de Objetos usando o aplicativo ClassicsJavaA.
Encontre o botão correto. Muitas caixas de diálogo incluem um botão Cancelar, portanto, primeiro você precisa encontrar a caixa de diálogo TestObject que contém o botão Cancelar correto. Se você encontrar o diálogo correto primeiro, é mais fácil encontrar o botão correto dentro desse diálogo. Volte para o seu script de teste vazio. Porque o diálogo é um objeto de alto nível, você pode iniciar sua pesquisa TestObject definindo o RootTestObject. Depois de ter feito isso, você pode usar o método find para localizar o diálogo TestObject:
RootTestObject root = getRootTestObject ();
Você está pronto para usar o método find para localizar o diálogo Place an Order, usando as informações da classe para a janela.
Nota: Certifique-se de imprimir as propriedades de todos os TestObjects encontrados, para que você possa revisá-los.
Seus comandos devem ser algo como isto:
A saída de tela resultante deve ser algo como isso (menos a maioria das propriedades, para economizar espaço):
Em seguida, em vez do código acima, use o método find para localizar o diálogo Place an Order usando o texto do rótulo para essa janela na caixa de diálogo:
Em ambos os casos, você encontrará apenas um objeto e as propriedades exibidas serão as mesmas. Essa é a situação ideal. Para aumentar a probabilidade desse resultado em todas as situações, você pode combinar as duas propriedades em uma chamada de localização:
Agora que você encontrou o controle que contém o botão com o rótulo que estava procurando, use a opção Localizar para localizar o botão correto:
Você pode chamar find de qualquer TestObject. Dependendo do objeto selecionado, a pesquisa é restrita a objetos na hierarquia abaixo da que você selecionou.
No exemplo acima, o código usa o atDescendant para localizar o botão. No entanto, existem vários métodos que você pode usar com o find:
atChild procura por qualquer filho direto do TestObject. atDescendant procura por qualquer filho do TestObject. atList permite especificar uma lista de objetos atChild, atDescendant e atProperty, para que você possa restringir a pesquisa.
Parte 2: exemplos de aplicações práticas do método TestObject. find.
Experimentar várias propriedades ajudará você a determinar quais propriedades funcionarão melhor para localizar objetos em seu aplicativo. Assim que você entender como a localização ajuda a definir seus controles dinamicamente, você pode começar a escrever métodos getter, para poder localizar objetos sem depender de um Mapa de Objetos gravado.
Definindo Controles Como Parte do Diálogo.
Para o diálogo Inserir um Pedido, por exemplo, você pode decidir definir os controles como parte do diálogo. Nesse caso, você primeiro encontrará a caixa de diálogo e, em seguida, procurará dentro da caixa de diálogo o controle que deseja modificar. Para esse cenário, seu design de código pode ser assim:
Aqui está um exemplo de como você pode usar esses métodos em um script:
Definindo Métodos para Encontrar Objetos Comuns.
Para encontrar rótulos de botão mais comuns, como Cancelar, talvez seja necessário desenvolver métodos mais gerais que localizem qualquer botão existente em seu aplicativo. Por exemplo, você pode usar getButton ("Cancel", placeAnOrderDialog), onde pai é a janela pai. Para este segundo cenário, seu design seria parecido com este exemplo:
Aqui está um exemplo de como você pode usar esses métodos em um script ou, mais apropriadamente, com uma classe que define o diálogo Colocar um Pedido:
O aplicativo que você está testando determinará como você define seus métodos para localizar os controles. A seção a seguir é um exemplo real de como um sistema foi projetado em torno do método find.
Uso real do RFT encontrado em um aplicativo baseado no Eclipse.
Este exemplo de uso do método find no teste do aplicativo baseado no Eclipse foi limitado a apenas uma parte do AUT como uma forma de trabalhar com o design dos métodos getter do objeto. Há um padrão discernível com objetos neste aplicativo. Os objetos SWT padrão eram predominantes, mas há algumas classes personalizadas especiais fornecidas pela equipe de desenvolvimento de aplicativos.
Os desenvolvedores de teste criaram métodos genéricos para obter todos os objetos de uma determinada classe ou para obter apenas um objeto em um determinado índice sob um objeto pai específico. Para permitir que a automação trabalhasse em versões localizadas do aplicativo, os desenvolvedores de teste decidiram usar os índices de objeto como a propriedade de chave para localizar objetos, em vez de texto. As classes descritas abaixo são projetadas para fazer isso.
Nota: Todos os métodos nessas classes são estáticos, portanto, o desenvolvedor de teste não precisa instanciar um objeto desse tipo para usá-los. Eles podem ser chamados usando o formato & lt; class name & gt ;. & lt; nome do método & gt; (& lt; parâmetros & gt;).
A classe FindAppObjects. java permite usar dois métodos diferentes: getAllObjects e getObjectAtIndex. Esses métodos geralmente não são destinados a serem usados diretamente, mas são a base para outros métodos. No entanto, você pode usá-los diretamente para determinar quais objetos são encontrados em quais índices.
getAllObjects obtém um TestObject pai e uma sequência de tipo de classe como entrada e, em seguida, retorna uma matriz de TestObjects que inclui todos os descendentes do objeto pai que são do tipo de classe especificado. Este exemplo retorna todos os diálogos filho do RootTestObject:
Selecionando o TestObject pai correto é importante, para que você obtenha apenas os objetos que você está procurando entre os resultados. Como exemplo, suponha que o seguinte represente uma hierarquia de objetos no AUT:
Chamar getAllObjects (aplicativo, "botão") retornará uma matriz de quatro botões. No entanto, não é possível determinar rapidamente quais índices correspondem a quais botões sem fazer o loop na matriz e imprimir cada índice e a seqüência de caracteres [index].getProperty ("texto") do botão.
Em vez desse processo complicado, faz mais sentido fazer mais de uma chamada hierárquica:
A chamada getAllObjects (group0, "button") retorna apenas dois botões, e é provável que eles estejam na ordem correta (button0, then button1), conforme exibido na tela. Se houver apenas alguns botões em todo o aplicativo ou caixa de diálogo, talvez seja mais fácil obter todos os botões e descobrir os índices.
getObjectAtIndex refina o uso de getAllObjects. Ele usa um TestObject pai, uma cadeia de tipo de classe e um inteiro com índice baseado em zero e, em seguida, retorna um único TestObject. Esse código, por exemplo, retorna o primeiro botão encontrado abaixo do grupo (pai) fornecido:
Esses métodos retornam TestObjects, e esses podem não ser o tipo específico de objeto que você precisa encontrar. Os métodos acima retornam TestObjects genéricos. Muitas vezes, você desejará usar um tipo específico de objeto. Ao usar esses métodos, certifique-se de converter explicitamente os TestObject (s) retornados para o tipo correto de objeto antes de usar em seu código.
A classe FindBasicAppObjects. java fornece mais refinamento e assistência. É uma subclasse de FindAppObjects. java e usa o método getObjectAtIndex. Ele contém métodos getter que retornam o objeto filho da classe de tipo no índice do pai TestObject. Isso já foi definido como a classe correta do objeto de produto, portanto, você não precisa transmitir o item por conta própria. Este exemplo retorna um subconjunto dos tipos de widget padrão do Eclipse SWT, como org. eclipse. swt. widgets. Button:
getDialog é o único método em FindBasicAppObjects. java que não toma um pai, porque assume que o pai é o AUT. Para poder reconhecer a caixa de diálogo correta mesmo que a caixa de diálogo tenha uma legenda mutável, getDialog usa um objeto de expressão regular (Regex) como parâmetro, conforme mostrado:
Compare o código do diálogo Colocar um Pedido (no início desta seção) com o mesmo comportamento usando FindAppObjects e FindBasicAppObjects no exemplo a seguir. Ele assume que o diálogo Colocar um Pedido é um diálogo do Eclipse do tipo WFrame e que os botões são do tipo WButton.
O código anterior é escrito de uma maneira fácil de manter, com cada parte do código segregada em partes compreensíveis. Para codificadores que preferem um layout mais compacto, esse código pode ser reescrito desta forma:
Sempre escreva testes de unidade.
Além dos métodos getter baseados em find, a classe FindBasicAppObjects. java mencionada anteriormente inclui métodos de teste de unidade rudimentares para cada um dos tipos de objetos definidos. Cada um desses métodos de teste de unidade usa um objeto de uma classe específica e uma string (em que a string deve ser o nome do método getter que você está testando). Esse nome é enviado ao console para rastrear os resultados de aprovação ou reprovação.
Os métodos de teste de unidade primeiro verificam se o objeto fornecido não é nulo e executam uma ou mais ações muito básicas no objeto. Por exemplo, o método de teste de unidade para um objeto WButton imprime a propriedade de texto (label) do objeto. Você pode então ver se o método getter está retornando o botão correto.
Usar métodos de teste de unidade para testar cada método getter é recomendado. O teste de unidade é geralmente considerado como trabalho extra, mas após qualquer alteração na interface do usuário do aplicativo, a execução dos testes da unidade verificará se os métodos continuam encontrando os controles corretos no AUT e confirmarão que qualquer alteração de código no getter métodos estão funcionando corretamente. A execução de testes de unidade garante que o código do caso de teste continue a localizar e retornar os objetos corretos.
Exemplo de chamada de um método de teste de unidade:
Limitações e Recomendações.
Sempre encontre o controle antes de usá-lo; nunca dependa de TestObjects salvos no seu código. O objeto encontrado pode mudar (ou ser excluído e recriado) entre a primeira vez que você encontrar o objeto e a próxima vez que precisar usá-lo. Certifique-se de ter o objeto correto, chamando localizar cada vez que você trabalha com o objeto.
Você não pode gravar scripts se estiver usando find. Como seus TestObjects não estão definidos no Mapa de Objetos, o gravador não selecionará o nome correto do objeto durante a gravação. Ainda é possível usar a gravação para o código estrutural básico necessário para seus scripts, mas será necessário substituir seus métodos getter baseados em localização pelos getters de controle mapeado que são registrados.
Muitos objetos podem parecer iguais. Pode haver mais de um botão OK quando você chama o método de localização. Certifique-se de ter o botão correto usando uma propriedade distintiva, como a caixa de diálogo na qual o botão OK está. Imprima o resultado do método getProperties no TestObject para o console para ver quais propriedades podem ajudá-lo a diferenciar o objeto que você procura de objetos semelhantes.
Técnicas efetivas de automação de testes para o Rational Functional Tester.
Publicado em 19 de junho de 2007.
Se você é um usuário comum de ferramentas de automação de teste, provavelmente está familiarizado com o conceito de estruturas de automação de teste. Os testadores freqüentemente pedem recomendações, referências e soluções de framework, mas os frameworks são apenas metade do que você precisa considerar. A maneira como você estrutura seu código de teste para facilitar o teste dos aplicativos que você está testando é o segundo passo em direção à automação efetiva.
Este artigo enfoca a primeira etapa, que é entender como usar efetivamente a ferramenta que você possui. Esta etapa abrange vários tópicos:
Objetos e propriedades Problemas comuns com navegadores Pontos de verificação Comandos de baixo nível A superclasse de ajuda do script.
Para cada um desses tópicos, você encontrará links para informações adicionais no final deste artigo em Tópicos relacionados.
O autor usou este software para escrever este artigo:
IBM & # 174; Racional & # 174; Versão do Functional Tester 7.0.0 Microsoft & # 174; Internet Explorer & # 174; Versão 6.0.2900.2180, SP2 Microsoft e # 174; Windows & # 174; XP Professional, SP2.
Alternativas para encontrar objetos e suas propriedades.
Componentes como caixas de diálogo, botões de comando e rótulos têm partes associadas de informações chamadas propriedades. Propriedades possuem nomes e valores. Você geralmente precisa acessar as várias propriedades dos objetos que está testando para poder realizar uma verificação de algum tipo ou para determinar programaticamente o que o script de teste deve fazer a seguir. Esta seção explica objetos, propriedades e formas que você pode interagir com eles em seus scripts.
Consultando e definindo valores de propriedades do objeto.
Você já quis comparar dinamicamente versões anteriores de um valor ao valor atual em tempo de execução? Ou você já desejou incluir uma ramificação em seu script do Rational Functional Tester baseada no valor atual de uma propriedade contida em um objeto? Você pode recuperar o valor de uma propriedade programaticamente chamando o método getProperty.
O exemplo no código A Listagem 1 usa o método getProperty para determinar se um rótulo contém uma mensagem de sucesso. Em caso afirmativo, o botão OK será clicado. Se isso não acontecer, o botão Cancelar será clicado.
Listagem 1: usando o método getProperty.
Se você precisar descobrir quais propriedades um objeto possui, você pode abrir o Mapa de Objetos de Teste e examinar as propriedades disponíveis lá. (Veja a Figura 1.)
Figura 1. Propriedades listadas no Mapa de Objetos de Teste.
Você também pode consultar as propriedades disponíveis registrando temporariamente um VP (ponto de verificação de propriedades de objeto) ou inserindo os comandos para extrair um valor de propriedade em uma variável por meio do VP e do assistente de ações.
O Rational Functional Tester também suporta um método setProperty. No entanto, esse método vem com um aviso de isenção de responsabilidade: não use a menos que você tenha certeza do resultado. Isso ocorre porque ele chama métodos internos que podem violar a integridade do aplicativo que você está testando.
Agora que você sabe como obter propriedades de seus objetos, você pode estar se perguntando: "Como eu acho o objeto em primeiro lugar?" Bem, essa é uma boa pergunta.
Formas de procurar por TestObjects.
O bloco de construção básico de seu script do Rational Functional Tester é o TestObject onipresente. Um TestObject representa um ponto de conexão entre o script que está sendo reproduzido e o aplicativo que você está testando. Para cada TestObject em um script de teste gerado, existe um objeto correspondente no aplicativo em que você registrou e esse objeto agora também existe no Mapa de Objetos de Teste.
Provavelmente, você normalmente interage com um TestObject usando o mapa de objetos. No entanto, o Rational Functional Tester também suporta um meio para localizar um TestObject programaticamente. A pesquisa é baseada em pares nome e valor que representam propriedades do TestObject ou TestObjects que você está procurando. A pesquisa pode ser global ou limitada a filhos de um TestObject pai.
O Rational Functional Tester usa um objeto chamado RootTestObject para representar uma visualização global do software em teste.
Se você quiser pesquisar o aplicativo inteiro, invoque o método find no RootTestObject. Se você quiser pesquisar um objeto específico, basta invocar o objeto TestObject. A pesquisa de um TestObject específico pesquisará apenas os filhos desse TestObject.
Mark Nowacki e Lisa Nodwell escrevem sobre como entender melhor e usar o método TestObject. find (consulte a segunda listagem em Tópicos relacionados). Eu poupei minhas amostras de código para que você possa ver as delas. Eles fazem um ótimo trabalho de explicar e ilustrar os princípios através de exemplos práticos.
Resolvendo o reconhecimento ambíguo de objetos.
Às vezes, o Rational Functional Tester não consegue distinguir entre dois objetos semelhantes durante a reprodução. É comum que isso ocorra quando dois navegadores ou instâncias do mesmo aplicativo são abertos simultaneamente. Quando dois navegadores da Web estão abertos, o Rational Functional Tester tenta resolver a ambiguidade usando uma âncora para ajudar a determinar o objeto de destino. Agora que você sabe como usar o método find, é possível identificar as instâncias do navegador e do aplicativo usando uma referência de TestObject.
Executar mais de uma instância de um aplicativo simultaneamente durante a reprodução resultará em ambiguidade sobre o destino dos comandos, como object () ou click (). Para resolver isso, você pode usar ProcessTestObject quando chamar o comando startApp. No exemplo da Listagem 2, o ProcessTestObject funciona como uma âncora para localizar o aplicativo desejado.
Listagem 2: Usando o ProcessTestObject para ancorar o aplicativo.
Limpar a casa excluindo o registro de objetos de teste.
O aspecto final do uso do método find lida com a exclusão do registro do objeto. TestObject. find retorna uma nova referência TestObject (às vezes chamada de referência vinculada, referência encontrada ou referência não mapeada). Essas referências mantêm o acesso ao objeto até que você "cancele o registro" explicitamente, o que significa que elas podem causar alguns problemas se você não cuidar delas.
O Rational Functional Tester cancela o registro de referências vinculadas apenas quando a reprodução inteira termina, não quando o script é finalizado. Contanto que exista uma referência vinculada ao objeto, o Rational Functional Tester pode impedir que o objeto no aplicativo seja totalmente gratuito. Por exemplo, enquanto você mantém uma referência vinculada a um Java & # 8482; objeto, o objeto Java não é tratado como não é mais necessário, assim, excluído. Portanto, é uma boa ideia cancelar explicitamente quaisquer referências vinculadas criadas assim que você não precisar mais delas.
O RationalTestScript contém vários métodos que removem referências a TestObjects:
com. rational. test. ft. script RationalTestScript. unregister unregisterAll.
Ao lidar diretamente com TestObjects, usá-los pode criar instabilidade em seu aplicativo. Cancele o registro de seus TestObjects o mais rápido possível.
Formas de resolver problemas comuns com navegadores.
Aqui estão alguns dos problemas comuns que você pode encontrar ao testar aplicativos HTML e como lidar com eles.
Corrigir comportamento funky com o método. readystate.
Se o seu navegador ou os objetos dentro do navegador não estiverem no estado certo, você poderá obter alguns comportamentos estranhos (erráticos) quando interagir. com eles - especialmente se você faz muita interação fora dos métodos auxiliares. É por isso que verificar o navegador da Web ou o readyState de um objeto é um bom hábito para entrar.
Комментариев нет:
Отправить комментарий