Mentores de Ferramentas > Mentores de Ferramentas do Rational QualityArchitect > Implementação de Teste de Componente Automatizado Usando o Rational QualityArchitect

Finalidade

Este mentor de ferramentas fornece uma visão geral das quatro principais tarefas de teste unitário realizadas com o Rational QualityArchitect:

  • Teste Unitário
  • Teste de Cenário
  • Geração de Stub
  • Registro de Sessão EJB

Informações relacionadas no Rational Unified Process:

Visão Geral

Um processo de desenvolvimento que adie o teste, até que todos os componentes possam ser montados em um sistema completo, é uma proposição arriscada. Defeitos encontrados tardiamente no ciclo de vida serão mais difíceis de consertar e provavelmente provocarão atrasos na programação, principalmente se forem problemas arquiteturais que talvez exijam um novo design para serem corrigidos.

Mesmo que a equipe esteja razoavelmente confiante na alta qualidade dos componentes do sistema, a confiabilidade geral do sistema ainda pode ser inaceitavelmente baixa. Por exemplo, considere um sistema simples, composto de cinco componentes, cada um classificado (seja por métricas de cobertura de teste, seja por métodos menos quantitativos) como sendo 95% confiável. Como a confiabilidade do sistema é cumulativa, a classificação geral é 95% x 95% x 95% x 95%x 95%, ou simplesmente acima de 77%. Ainda que o potencial de problemas em qualquer um dos componentes possa ser somente de 1 em 20, para o sistema geral, ele se aproxima de 1 em 4 — e isso para um sistema com relativamente poucos componentes.

Por outro lado, um processo de desenvolvimento que incorpore teste de componentes em todo o processo de desenvolvimento iterativo oferece várias vantagens significativas:

  • Os problemas podem ser encontrados e solucionados em um contexto isolado, tornando-os não somente mais fáceis de serem reparados, mas também mais fáceis de serem detectados e diagnosticados.
  • Na medida em que teste e desenvolvimento são fatores estreitamente acoplados durante o ciclo de vida, as medições de progresso têm mais credibilidade — o progresso pode, agora, ser visto em termos quantificáveis, ou seja, quanto do projeto não só está codificado mas funcionando.
  • As interrupções no programa, provocadas por problemas não previstos, são minimizadas, o que torna a programação geral mais realista e reduz o risco do projeto.

Embora haja enormes vantagens no teste inicial, a prática está longe de ser lugar comum, especialmente no que está relacionado ao teste de componentes da camada intermediária, sem GUI.

Por quê? Porque isso é demorado e entediante e, no passado, os custos para superar essas questões práticas se tornaram muitas vezes mais importantes que os benefícios. Além disso, como a maioria dos testes é adaptada a um componente específico, há pouca oportunidade para reutilização. Muitas organizações reconhecem o desperdício de criar estruturas e stubs de teste desde o início, usando-os e, em seguida, descartando-os, projeto após projeto. Elas preferem concentrar seus recursos limitados em outras áreas.

Com o QualityArchitect, o teste inicial realmente se torna viável, pois as estruturas e os stubs dos testes são gerados automaticamente: não apenas uma vez, mas de forma incremental, à medida que o modelo evolui durante o desenvolvimento. Todo o processo de desenvolvimento se torna mais estruturado, medido e visível, pois os resultados dos testes de componentes facilitam a obtenção de critérios de entrada mais sólidos, evitando o teste prematuro do sistema. O QualityArchitect permite que os desenvolvedores se concentrem nos aspectos criativos da definição dos testes, de modo que eles possam ter tempo para pensar sobre a melhor maneira de testar um componente, em vez de usar o tempo elaborando e depurando drivers e stubs de teste. Desenvolvedores e arquitetos, em estreita ligação, trabalham com modelos visuais compartilhados, e assim, naturalmente, eles desenvolvem um inter-relacionamento mais produtivo.

Use este mentor de ferramentas durante a execução do Windows 98/2000/NT 4.0.

Passos na Ferramenta

Esse mentor de ferramentas abrange as seguintes tarefas principais, associadas à implementação de teste automático de componente, usando o QualityArchitect:

  1. Passos que são pré-requisitos para o teste unitário
  2. Implementar um teste unitário
  3. Implementar um teste de cenário
  4. Criar um componente stub
  5. Usar o Registrador de Sessão EJB

1.   Passos que são pré-requisitos para o teste unitário Início da página

Para gerar quaisquer testes usando o QualityArchitect, sejam eles para componentes COM ou EJB, é necessário criar e configurar um Projeto da Rational usando o Rational Administrator. Esse projeto deve conter um Depósito de Dados de Teste para manter todos os componentes do teste, como, por exemplo, os resultados e agrupamentos de dados. Isso está descrito em Mentor de Ferramentas: Configuração de Projetos Usando o Rational Administrator.

2.   Implementar um teste unitário Início da página

O objetivo de um teste unitário é validar se uma determinada operação em um componente específico fornece o valor de retorno correto para um determinado conjunto de entradas. Os testes unitários são criados fora da especificação de classe, na visão lógica. O processo de criação e execução de um teste unitário é composto de três passos:

  • Geração do código do teste unitário
  • Geração dos dados do teste unitário
  • Execução do teste e exame dos resultados

Geração do código do teste unitário Início da página

O código do teste unitário contém todas as instruções necessárias para criar instâncias do componente, chamar a operação em teste e examinar o resultado retornado em comparação a uma baseline.

Para componentes COM
  1. Selecione a operação a ser testada na interface do componente, na Visão Lógica.
  2. Clique com o botão direito do mouse na operação listada na interface do componente e selecione Rational Test> Generate Unit Test. Se solicitado, talvez você precise, durante esse processo, fazer logon em um Projeto da Rational.

O QualityArchitect, como resultado desse processo, gerará um código compatível com o Visual Basic 6.

No Visual Basic, é preciso primeiro tentar compilar o código. Qualquer erro de compilação deve ser examinado. Em certas circunstâncias, o QualityArchitect não conseguirá gerar código para operações de teste que façam uso intensivo de tipos de dados complexos. Se for esse o caso, o QualityArchitect inserirá código inválido, o que, no momento da compilação, realçará os segmentos de código em que é necessária a codificação manual. Depois que o código for compilado, você poderá passar para o próximo passo, Geração dos dados do teste unitário.

Para componentes EJB
  1. Selecione a operação a ser testada na interface remota, na Visão Lógica.
  2. Clique com o botão direito do mouse na operação e selecione Rational Test> Select Unit Test Template.
  3. Navegue até o template adequado para o servidor EJB. Para WebSphere, selecione websphere_remote.template na pasta EJB\WebSphere\Business Methods. Para Web Logic, selecione weblogic_remote.template na pasta EJB\Web Logic\Business Methods.
  4. Selecione Rational Test > Generate Unit Test. Se solicitado, talvez você precise, durante esse processo, fazer logon em um Projeto da Rational. 

O QualityArchitect, como resultado desse processo, gerará código Java.

Você pode usar o IDE ou o editor de sua escolha para examinar o código Java. O Rational Rose é vendido juntamente com o editor R2, que pode ser usado para essa finalidade.

Após iniciar o seu editor, tente primeiro compilar o código. Qualquer erro de compilação deve ser examinado. Em certas circunstâncias, o QualityArchitect não conseguirá gerar código que faça uso intensivo de tipos de dados complexos. Se for esse o caso, o QualityArchitect inserirá código inválido, que não será compilado para linhas de sinalização de código em que a codificação manual será necessária. Depois que o código for compilado, você poderá passar para o próximo passo, Geração dos dados do teste unitário.

Geração de dados do teste unitário Início da página

A real medida de um teste unitário bem-sucedido são os dados do teste. O próprio código de teste é completamente descartável, já que o QualityArchitect pode gerar outra vez o código a qualquer momento. Embora o QualityArchitect possa criar o código de teste, o programa não pode criar dados de teste significativos. Isso é responsabilidade do analista ou do implementador. É preciso cuidado para criar dados de teste que validem testes positivos e negativos representativos. Os dados de teste que se concentram nas condições de fronteira da lógica do componente são excelentes sugestões de dados de teste unitário.

Para componentes COM
  1. Selecione a operação a ser testada na interface do componente, na Visão Lógica.
  2. Clique com o botão direito do mouse na operação e selecione Rational Test > Create Datapool.
  3. Depois que você selecionar Create Datapool, a caixa de diálogo Datapool Properties será exibida. Nesse ponto, é possível selecionar Edit Datapool Data para iniciar a inserção de dados ou Define Datapool Fields para que o QualityArchitect gere os dados de teste para você.
Para componentes EJB
  1. Selecione a operação a ser testada na interface remota, na Visão Lógica.
  2. Clique com o botão direito do mouse na operação listada na interface remota e selecione Rational Test > Create Datapool.
  3. Depois que você selecionar Create Datapool, a caixa de diálogo Datapool Properties será exibida. Nesse ponto, é possível selecionar Edit Datapool Data para iniciar a inserção de dados ou Define Datapool Fields para que o QualityArchitect gere os dados de teste para você.
Trabalho com Agrupamentos de Dados

Se selecionar Define Datapool Fields, você poderá usar os recursos de geração de dados de teste do QualityArchitect. O QualityArchitect pode gerar vários tipos de dados genéricos, os quais são especificados na lista suspensa de tipos de dados, no campo Type. 

Quando tiver selecionado os tipos adequados, selecione o número de linhas a serem geradas e clique em Generate Data. É muito provável que o QualityArchitect não consiga gerar todos os dados para você. Por exemplo, o QualityArchitect gerará uma lista genérica de cidades dos EUA, mas não gerará uma lista de números de faturas válidos e específicos do sistema para um sistema de pedidos. Esses dados devem ser inseridos manualmente, como um tipo de dado, ou inseridos diretamente em um agrupamento de dados. É importante criar um tipo de dado com dados personalizados porque o QualityArchitect, a partir desse ponto, conseguirá gerar esse tipo de dado na interface Define Datapool Fields. Se você inserir os dados diretamente no agrupamento de dados, eles ficarão disponíveis somente para esse agrupamento específico.

Se selecionar Edit Datapool Data, você inserirá, de forma direta, os dados de teste significativos. Há um campo para cada argumento, bem como um campo para o retorno previsto e um campo para o erro previsto. Quando você especifica um erro, o número do erro e suas mensagens textuais são entradas válidas. Se a sua operação exigir um objeto complexo como argumento, ou se ela retornar um objeto complexo, você não poderá inserir a referência desse objeto no agrupamento de dados. Em vez disso, divida o objeto em tipos de argumentos simples e necessários para construir uma instância do objeto. Use os botões Insert Before e Insert After para adicionar campos ao agrupamento de dados, para essa finalidade. Você terá de modificar o código do teste para construir uma instância de objeto com os dados fornecidos.

Execução do teste e avaliação dos resultados

Depois de criar o código e os dados do teste, você estará pronto para executar o teste. É possível executar o teste no IDE ou programá-lo em um Conjunto de Testes do TestManager. Consulte Mentor de Ferramentas: Execução de um Conjunto de Testes Usando o Rational TestManager para obter mais informações sobre esse tópico.

  1. No início da execução do teste, você é solicitado a fornecer um local para inserir os resultados do log de teste. Depois que você especifica um local, o TestManager inclui os resultados da execução do teste.
  2. No final da execução, o TestManager exibe o Test Log. Para exibir os resultados do teste, selecione a guia Detailed View da janela Log Viewer. Expanda a visão da árvore de resultados para ver os detalhes da execução do teste. Para obter mais informações, clique com o botão direito do mouse em qualquer linha e selecione Properties.

3.   Implementar um teste de cenário Início da página

O objetivo de um teste de cenário é validar se uma determinada série de operações em uma determinada série de componentes se combinam para executar corretamente uma tarefa coletiva. Testes de cenário são criados a partir de diagramas de interação, mais especificamente, diagramas de seqüência e de colaboração. O processo de criação e execução de um teste de unidade é composto destes três passos:

  • Geração do código de teste de cenário
  • Geração dos dados de teste de cenário
  • Execução do teste e exame dos resultados

Geração do código de teste de cenário Início da página

O código de teste de cenário abrangerá todo o código do driver de teste necessário para criar instâncias dos componentes, chamar as operações em teste e avaliar os resultados dessas operações usando pontos de verificação. Os pontos de verificação são um mecanismo por meio do qual o código de teste pode executar instruções SQL em um banco de dados, a fim de verificar a manipulação adequada dos dados subjacentes.

Para componentes EJB
  1. Selecione o diagrama de colaboração no navegador.
  2. Clique com o botão direito do mouse no diagrama e selecione Rational Test > Select Scenario Test Template.
  3. Navegue até o template adequado para o servidor EJB. Para WebSphere, selecione websphere_scenario.template na pasta EJB\WebSphere\Scenario. Para Web Logic, selecione o weblogic_scenario.template na pasta EJB\Web Logic\Scenario.
  4. Abra a seqüência fornecida ou o diagrama de colaboração que modela o cenário em teste. É importante que as mensagens para os componentes sejam especificadas para os componentes do diagrama que serão testados. Para especificar mensagens, clique duas vezes na linha de mensagem e especifique um nome na caixa de listagem suspensa, na guia General. O nome precisa corresponder à operação em teste. Além disso, essas especificações podem ser modificadas para incluir dados de caso de teste.

    Por exemplo, o Rose, por padrão, mostrará a especificação das mensagens da seguinte forma:
    getTransactions(customerID : String)

    Essa especificação pode ser modificada para incluir um único caso de dados:
    getTransactions(customerID : String="BBryson")

     Para cada teste de cenário, o QualityArchitect gera automaticamente um agrupamento de dados de caso de teste. Os dados no diagrama serão preenchidos na primeira linha. É possível adicionar mais linhas a partir desse ponto.
  5. Para iniciar o teste, clique com o botão direito do mouse no diagrama, no navegador, e selecione Rational Test > Generate Scenario Test. Se for solicitado a fazer logon no seu projeto, faça-o. 
  6. Uma caixa de diálogo solicitará que você selecione os objetivos do teste de cenário. Selecione todos os componentes no diagrama que farão parte do teste. Para cada componente selecionado, a operação correspondente, especificada na mensagem desse componente, será chamada. 
Para componentes COM
  1. Abra a seqüência fornecida ou o diagrama de colaboração que modela o cenário em teste. É importante que as mensagens para os componentes sejam especificadas para os componentes do diagrama que serão testados. Para especificar mensagens, clique duas vezes na linha de mensagem e especifique um nome na caixa de listagem suspensa, na guia General. O nome precisa corresponder à operação em teste. Além disso, essas especificações podem ser modificadas para incluir dados de caso de teste.

    Por exemplo, o Rose, por padrão, mostrará a especificação das mensagens da seguinte forma:
    getTransactions(customerID : String)

    Essa especificação pode ser modificada para incluir um único caso de dados:
    getTransactions(customerID : String="BBryson")

     Para cada teste de cenário, o QualityArchitect gera automaticamente um agrupamento de dados de caso de teste. Os dados no diagrama serão preenchidos na primeira linha. É possível adicionar mais linhas a partir desse ponto.
  2. Para iniciar o teste, clique com o botão direito do mouse no diagrama, no navegador, e selecione Rational Test > Generate Scenario Test. Se for solicitado a fazer logon no seu projeto, faça-o. 
  3. Uma caixa de diálogo solicitará que você selecione os objetivos do teste de cenário. Selecione todos os componentes no diagrama que farão parte do teste. Para cada componente selecionado, a operação correspondente, especificada na mensagem desse componente, será chamada. 
Pontos de verificação

Em cada operação chamada e novamente no final do teste, você será solicitado a inserir um ponto de verificação. Os pontos de verificação são usados pelo QualityArchitect para validar se as operações ocorreram corretamente. Embora a arquitetura do ponto de verificação seja aberta e extensível, atualmente, somente o ponto de verificação do banco de dados está implementado. O ponto de verificação do banco de dados permite inserir SQL para executar uma consulta. A consulta criada será executada no momento do teste para validar a manipulação correta do banco de dados pelo componente. 

Ícone da Ajuda Você pode implementar seus próprios pontos de verificação, usando os passos encontrados na Ajuda on-line do QualityArchitect.

  1. Selecione Yes para inserir um ponto de verificação.
  2. Selecione o tipo adequado de ponto de verificação a ser inserido. A menos que tenha implementado seus próprios pontos de verificação, selecione Database VP.
  3. Um Construtor de Consultas será aberto. Use-o para determinar os parâmetros de conexão com o seu banco de dados e para criar a consulta a ser executada para validar o funcionamento correto da operação que está sendo chamada. É preciso ter conhecimentos básicos de banco de dados e sintaxe SQL subjacente para estabelecer essa conexão e criar a consulta.

É obtido nesse estágio o código necessário para criar instâncias de todos os componentes, chamar todas as operações e executar os pontos de verificação inseridos.

Geração dos dados de teste de cenário Início da página

Para cada teste de cenário gerado, o QualityArchitect cria automaticamente um agrupamento de dados contendo os dados do teste. Se os dados tiverem sido especificados no diagrama, a primeira linha desse agrupamento de dados já estará preenchida com essas informações, bem como com as informações relacionadas a qualquer ponto de verificação inserido. Caso contrário, o agrupamento de dados conterá somente as informações relacionadas a pontos de verificação.

Para exibir e editar essas informações, siga estes passos:

  1. No Rose, selecione Tools > Rational Test > Toolbar.
  2. Na Barra de Ferramentas, selecione o segundo item para editar o agrupamento de dados. O QualityArchitect já terá criado um agrupamento de dados contendo o nome do diagrama de cenário; esse nome termina com um _D. O algoritmo usado para nomear o agrupamento de dados é tão complexo que é muito difícil prever, nesta documentação, o nome de cada agrupamento de dados.

Para editar esses dados, siga os mesmos passos básicos descritos em Trabalho com Agrupamentos de Dados.

Execução do teste e avaliação dos resultados

Depois de criar o código e os dados do teste, você estará pronto para executar o teste. É possível executar o teste no IDE ou programá-lo em um Conjunto de Testes do TestManager. Consulte Mentor de Ferramentas: Execução de um Conjunto de Testes Usando o Rational TestManager para obter mais informações sobre esse tópico.

  1. No início da execução do teste, você é solicitado a fornecer um local para inserir os resultados do log de teste. Depois que você especifica um local, o TestManager inclui os resultados da execução do teste.
  2. No final da execução, o TestManager exibe o Test Log. Para exibir os resultados do teste, selecione a guia Detailed View da janela Log Viewer. Expanda a visão da árvore de resultados para ver os detalhes da execução do teste. Para obter mais informações, clique com o botão direito do mouse em qualquer linha e selecione Properties.

Para pontos de verificação, nenhuma indicação Pass ou Fail é fornecida na primeira execução, que é usada para capturar uma imagem dos resultados da consulta a serem usados como dados de baseline para futuras execuções do teste.

Clique duas vezes nos pontos de verificação para exibir um comparador que apresente os resultados da consulta. Esses resultados podem ser editados, assim, se a consulta não tiver retornado os resultados corretos, será possível modificar esses dados. Todas as execuções subseqüentes desse teste compararão os resultados de suas consultas com os resultados capturados na primeira execução.

4.   Criar um componente stub Início da página

Geralmente, os componentes que fazem parte do teste unitário ou de cenário dependem de outros componentes para concluir suas tarefas. Os problemas surgem quando esses componentes secundários não são operacionais. Às vezes, ainda estão em desenvolvimento, ou então têm muitos erros. De qualquer modo, o teste dos principais componentes não precisa ser interrompido até que os componentes secundários estejam disponíveis. Em vez disso, um stub ou componente temporário pode substituir qualquer componente não operacional para fins de teste. O stub não implementa a funcionalidade do componente real; ele simplesmente reage a entradas. Os stubs retornam uma resposta programada para um determinado conjunto de valores, sem implementar qualquer lógica. É um simples relacionamento de estímulo/resposta.

O QualityArchitect pode facilmente criar stubs para componentes COM e componentes EJB. Esses stubs dependem de tabelas de consulta para replicar a lógica de negócio dos componentes que estão substituindo. A tabela, implementada como um agrupamento de dados, determina qual deve ser o valor retornado para um determinado conjunto de entradas.

O processo de criação e implantação de um stub é composto destes três passos:

  • Geração de um componente stub
  • Geração de uma tabela de consulta
  • Implantação do stub

Geração de um componente stub

Ao gerar um stub, você deve gerar um componente completo. Portanto, nas operações para as quais está sendo gerado o stub, é necessário criar uma tabela de consulta. Um componente stub, que contém código de stub para todas as operações desse componente, é o resultado do processo de geração do stub. Não é possível gerar stub para uma única operação.

Para componentes COM
  1. Selecione a interface de componentes, na Visão Lógica.
  2. Clique com o botão direito do mouse na interface e selecione Rational Test > Generate Stub. Você será solicitado a fornecer o local onde deseja colocar o código do stub gerado. Selecione esse local e o código será gerado.
Para componentes EJB
  1. Selecione a classe de implementação bean, na Visão Lógica. 
  2. Clique com o botão direito do mouse na classe e selecione Rational Test > Generate Stub. Você será solicitado a fornecer o local onde deseja colocar o código do stub gerado. Selecione esse local e o código será gerado.

Geração de uma tabela de consulta stub

Para replicar a lógica do componente real, o stub deve saber como o componente real reagiria quando confrontado com um conjunto de argumentos. Essa lógica é mantida em uma tabela de consulta, que especifica qual valor ou erro deve ser retornado para um determinado conjunto de argumentos. É preciso criar uma tabela de consulta para cada operação do componente para o qual está sendo gerado um stub.

Para componentes COM
  1. Selecione a operação localizada abaixo da interface do componente, na Visão Lógica.
  2. Clique com o botão direito do mouse na interface e selecione Rational Test > Create Lookup Table. A caixa de diálogo Datapool Properties é exibida.
  3. Para criar essa tabela de consulta, siga os mesmos passos básicos descritos em Trabalho com agrupamentos de dados. Use a tabela para especificar valores ou exceções a serem retornados para um determinado conjunto de argumentos.
Para componentes EJB
  1. Selecione a operação da classe de implementação bean, na Visão Lógica. 
  2. Clique com o botão direito do mouse na interface e selecione 
  3. Rational Test > Create Lookup Table. A caixa de diálogo Datapool Properties é exibida.
  4. Para criar essa tabela de consulta, siga os mesmos passos básicos descritos em Trabalho com agrupamentos de dados. Use a tabela para especificar valores ou exceções a serem retornados para um determinado conjunto de argumentos.

Implantação do stub

Quando o stub e a tabela de consulta tiverem sido gerados, o stub deve ser implantado no local do componente existente. Esse processo é específico do ambiente e a orientação para essa tarefa é fornecida no respectivo tópico na Ajuda on-line do QualityArchitect.

5.   Usar o Registrador de sessão EJB Início da página

O registrador de sessão EJB é um aplicativo Java que permite interagir com componentes EJB implantados e em funcionamento. Essa funcionalidade está disponível somente para Enterprise JavaBeans, não para componentes COM.

O processo para usar o registrador de sessão EJB envolve estes passos:

  • Início de uma sessão de registro XML
  • Conexão com o servidor EJB
  • Criação de uma instância do bean em teste
  • Chamada da operação no bean
  • Inserção de pontos de verificação e de código java
  • Geração do código de teste no registro da sessão EJB

O registrador de sessão EJB pode ser usado de duas maneiras: registro e não registro. No registro, toda ação tomada é gravada em um log de XML que o registrador de sessão EJB converterá em um código java executável. O código contém todas as chamadas de método, qualquer código java inserido e os pontos de verificação. Ao operar no modo de não registro, a ferramenta ficará limitada à criação de instâncias de EJBs e à chamada de suas operações.

  1. Para estabelecer uma conexão com o servidor EJB, é necessário fornecer o URL do Provedor e o InitialContextFactory. Essas informações devem ser as mesmas usadas pelo código de cliente para a conexão com o servidor. As informações de conexão padrão para WebSphere e Web Logic podem ser encontradas na documentação on-line do produto. 
  2. Após ter fornecido as informações de conexão, selecione Connect e você receberá uma lista dos beans implantados nesse servidor. A interação de beans, durante uma sessão, pode ser de um para muitos, e é preciso que você selecione o primeiro bean que interagirá com esse ponto.
  3. Aqui é possível criar uma instância do primeiro bean em teste. Selecione o método de criação adequado na metade superior da janela Methods. Se o método de criação exigir parâmetros, especifique-os na seção Parameters. Quando terminar, selecione Invoke para criar uma instância de bean.
  4. Criada a instância de bean, o registrador de sessão EJB apresentará as várias operações disponíveis nesse bean. Você verá as próprias operações do bean na metade superior da janela Methods e, na metade inferior, as operações herdadas. Como regra geral, as operações herdadas não estarão em teste. Depois de selecionar a operação a ser testada, você poderá fornecer os parâmetros necessários para essa operação na janela Parameters.
  5. Se o parâmetro for um objeto complexo, haverá um botão denominado New. Isso abre uma janela subseqüente, com uma caixa de diálogo que permite criar uma instância do objeto necessário. A janela mostra todos os construtores e os argumentos necessários para construir uma instância do objeto. Depois de fornecer as informações do construtor, você precisará nomear o objeto para que possa ser feita referência a ele posteriormente durante a ação de registro, se necessário. 
  6. Haverá valor na atribuição de nomes a parâmetros se esses valores tiverem de ser usados novamente durante o registro da sessão. Se você fornecer um nome, o QualityArchitect conseguirá preencher o valor em qualquer campo de parâmetro quando você clicar com o botão direito do mouse nesse campo.
  7. Quando você clica em Invoke, a operação é chamada com os parâmetros fornecidos. O valor de retorno é mostrado no campo Last Return Value. Se esse valor for necessário como input para uma chamada subseqüente, arraste-o e solte-o no campo necessário. Você também pode clicar no valor, usando o botão direito do mouse, caso o cursor esteja apontando para o campo de parâmetro em que o valor será inserido. Para determinar quais valores serão apresentados no menu obtido com um clique do botão direito do mouse, o registrador de sessão EJB fará a correspondência do tipo de parâmetro com os tipos anteriormente usados durante o teste. 
  8. Em qualquer ponto da sessão, é possível inserir código java ou pontos de verificação no menu Insert. Os pontos de verificação são os mesmos usados durante a geração do código de teste de cenário. De modo semelhante, o código java pode ser inserido para realizar qualquer processamento adicional.
  9. Se estiver no modo de registro, você poderá converter o registro baseado em XML em código java, quando todos os passos do teste estiverem concluídos. Clique em Stop para executar essa ação. Você será solicitado a converter o código XML em código java e precisará fornecer um nome de sessão e um nome de script. O código java, que pode ser executado para replicar os passos executados durante a ação de registro, é o resultado desse processo. 

Copyright  © 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process