Visão Geral

Este mentor de ferramenta oferece uma visão geral das quatro principais tarefas de teste de unidade executadas com o Rational QualityArchitect:

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

Um processo de desenvolvimento que desativa os testes até que todos os componentes possam ser montados em um sistema concluído é uma proposição de risco. Quanto mais tarde os defeitos forem detectados no ciclo de vida, mais difícil será para corrigir e maiores serão as chances de ocorrerem sérios retardos no planejamento, especialmente problemas de arquitetura que possam requer um novo design extensivo para a correção.

Mesmo se uma equipe tiver confiança razoavelmente alta quanto à qualidade dos componentes do sistema, a confiança geral do sistema ainda poderá ser inaceitavelmente baixa. Por exemplo, considere um sistema simples composto por cinco componentes, cada um classificado (pela métrica da cobertura de teste ou por métodos menos quantitativos) como 95% confiável. Como a confiabilidade do sistema é acumulativa, a classificação geral é 95% x 95% x 95% x 95%x 95%, ou apenas cerca de 77%. Considerando que a possibilidade de problemas em qualquer componente pode ser apenas 1 em 20, para o sistema geral, ela chega a 1 em 4 - e para um sistema com relativamente poucos componentes.

Por outro lado, um processo de desenvolvimento que incorpora testes de componente em todo um processo de desenvolvimento iterativo oferece muitas vantagens significantes:

• Problemas podem ser encontrados e corrigidos em um contexto isolado, não somente facilitando seu reparo, mas também facilitando a detecção e o diagnóstico.
• Como o teste e o desenvolvimento estão vinculados ao ciclo de vida, as medidas do andamento são mais confiáveis - o andamento agora pode ser visualizado para saber quanto do projeto está codificado e em funcionamento, não apenas codificado.
• Rupturas no planejamento causados por problemas imprevistos são minimizados, o que torna o planejamento geral mais realístico e reduz o risco do projeto.

Embora o teste antecipado ofereça muitos benefícios, a prática é muito diferente, especialmente no que diz respeito ao teste de componentes de nível médio, sem GUI.

Por quê? Porque é demorado e cansativo, e no passado os custos de resolução desses problemas práticos freqüentemente ofuscavam os benefícios. Além disso, como a maioria dos teste é personalizada para um componente específico, há pouca chance de reutilização. Muitas organizações reconhecem o desperdício de construir chicotes de teste e stubs do início, utilizando-os e inutilizando-os projeto após projeto. Elas preferem focalizar seus recursos limitados em outras áreas.

Com o QualityArchitect, o teste antecipado se torna realmente plausível, pois os chicotes de teste e os stubs são gerados automaticamente: não apenas uma vez, mas incrementalmente, à medida que o modelo se desenvolve. O processo de desenvolvimento inteiro torna-se mais estruturado, medido e visível, pois os resultados dos testes de componente facilitam critérios de entrada mais rígidos para impedir testes do sistema prematuros. O QualityArchitect permite que os desenvolvedores focalizem os aspectos criativos da definição de testes, para que possam gastar mais tempo pensando na melhor forma de utilizar um componente, em vez de gravar e depurar drivers de teste e stubs. Os desenvolvedores e arquitetos trabalham muito próximos com os modelos visuais compartilhados, para desenvolverem naturalmente um relacionamento mais produtivo um com o outro.

Esse mentor de ferramenta é aplicável ao executar o Windows 98/2000/NT 4.0.

Etapas da Ferramenta

Ele abrange as principais tarefas associadas à implementação de um teste de componente automatizado utilizando o QualityArchitect:

1. Etapas de Pré-requisito para Teste de Unidade
2. Implementar um Teste de Unidade
3. Implementar um Teste de Cenário
4. Criar um Componente de Stub
5. Utilizar o Gravador de Sessão EJB

1.   Etapas de Pré-requisito para Teste de Unidade

Para gerar testes utilizando o QualityArchitect, se forem para os componentes COM de EJB, um Projeto do Rational deve ser criado e configurado utilizando o Rational Administrator. Esse projeto deve conter um Datastore de Teste com todos os recursos de teste, como resultados de teste e datapools. Isso é descrito em Mentor de Ferramenta: Configurando Projetos Utilizando o Rational Administrator.

2.   Implementar um Teste de Unidade

O objetivo de um teste de unidade é validar se uma determinada operação de um determinado componente oferece o valor de retorno correto para um determinado conjunto de entradas. Os testes de unidade são criados fora da especificação da classe na visualização lógica. O processo de criação e execução de um teste de unidade é composto por três etapas:

• Gerando Código de Teste de Unidade
• Gerando Dados do Teste de Unidade
• Executando o Teste e Examinando os Resultados

Gerando Código de Teste de Unidade

O código do teste de unidade contém todas as instruções necessárias para instanciar o componente, chamar a operação em teste e examinar o resultado retorna com uma linha de base.

Para componentes COM

1. Selecione a operação a ser testada na interface do componente na Visualização Lógica.
2. Clique com o botão direito do mouse na operação listada na interface do componente e selecione Rational Test > Gerar Teste de Unidade. Se for solicitado, durante esse processo, você pode precisar efetuar login em um Projeto do Rational.

O QualityArchitect gera código compatível com Visual Basic 6 como saída desse processo.

No Visual Basic, você precisa primeiramente tentar compilar o código. Os erros de compilação devem ser examinados. Em determinadas circunstâncias, o QualityArchitect não poderá gerar código para testar operações que façam uso extensivo de tipos de dados complexos. Quando for esse o caso, o QualityArchitect inserirá código inválido, que no momento da compilação, destacará os segmentos de código em que é necessária codificação manual. Quando o código for compilado, você poderá prosseguir para a próxima etapa, Gerando Dados do Teste de Unidade.

Para componentes EJB

1. Selecione a operação a ser testada na interface remota na Visualização Lógica.
2. Clique com o botão direito do mouse na operação e selecione Rational Test > Selecionar Gabarito do Teste de Unidade.
3. Navegue para o gabarito apropriado para o servidor EJB. No caso do WebSphere, selecione o arquivo websphere_remote.template na pasta EJBWebSphereBusiness Methods. No caso do Web Logic, selecione o arquivo weblogic_remote.template na pasta EJBWeb LogicBusiness Methods.
4. Selecione Rational Test > Gerar Teste de Unidade. Se for solicitado, durante esse processo, você pode precisar efetuar login em um Projeto do Rational. 

O QualityArchitect gerará código Java como a saída desse processo.

Você pode utilizar o IDE ou o editor de sua preferência para examinar o código Java. O Rational Rose contém o editor R2, que pode ser utilizado para esse fim.

Quando estiver no editor, primeiramente você pode tentar compilar o código. Os erros de compilação devem ser examinados. Em determinadas circunstâncias, o QualityArchitect não poderá gerar código que faça uso extensivo de tipos de dados complexos. Quando for esse o caso, o QualityArchitect inserirá código inválido que não será compilado para indicar linhas de código, em que será necessária codificação manual. Quando o código for compilado, você poderá prosseguir para a próxima etapa, Gerando Dados do Teste de Unidade.

Gerando Dados do Teste de Unidade

A medida real de um teste de unidade com êxito são os dados de teste. O código de teste em si é completamente descartável, pois o QualityArchitect pode gerar novamente o código a qualquer momento. Embora o QualityArchitect possa criar o código de teste, ele não pode criar dados de teste significantes. Isso é responsabilidade do analista ou do implementador. Tome cuidado ao criar dados de teste que validam testes positivo e negativo representativos. Os dados de teste que focalizam condições de limite da lógica do componente são excelentes candidatos a dados do teste de unidade.

Para componentes COM

1. Selecione a operação a ser testada na interface do componente na Visualização Lógica.
2. Clique com o botão direito do mouse na operação e selecione Rational Test > Criar Datapool.
3. Quando você tiver selecionado essa opção, a caixa de diálogo Propriedades do Datapool aparecerá. Nesse momento, você pode selecionar Editar Dados do Datapool para começar a digitar dados ou Definir Campos do Datapool para que o QualityArchitect gere dados de teste.

Para componentes EJB

1. Selecione a operação a ser testada na interface remota na Visualização Lógica.
2. Clique com o botão direito do mouse na operação listada na interface remota e selecione Rational Test > Criar Datapool.
3. Quando você tiver selecionado essa opção, a caixa de diálogo Propriedades do Datapool aparecerá. Nesse momento, você pode selecionar Editar Dados do Datapool para começar a digitar dados ou Definir Campos do Datapool para que o QualityArchitect gere dados de teste.

Trabalhando com Datapools

Se você selecionar Definir Campos do Datapool, poderá utilizar os recursos da geração de dados de teste do QualityArchitect. O QualityArchitect pode gerar diversos tipos de dados genéricos, que são especificados na lista drop-down de tipos de dados no campo Tipo. 

Depois de selecionar os tipos apropriados, selecione o número de linhas a serem geradas e clique em Gerar Dados. É bastante provável que o QualityArchitect não consiga gerar todos os dados. Como exemplo, o QualityArchitect poderá gerar uma lista genérica de cidades dos EUA, mas não poderá gerar uma lista de números de fatura válidos específicos ao sistema para um sistema de pedidos. Esses dados devem ser digitados manualmente como um tipo de dado ou digitados diretamente em um datapool. A importância de criar um tipo de dados com dados personalizados é que o QualityArchitect, desse ponto em diante, poderá gerar esse tipo de dado na interface Definir Campos do Datapool. Se você digitar os dados diretamente no datapool, eles estarão disponíveis a esse datapool específico.

Selecionando Editar Dados do Datapool, você digitará diretamente os dados de teste significantes. Há um campo para cada argumento, e também um campo para um retorno esperado e um campo para um erro inesperado. Quando você especificar um erro, o número do erro e mensagens de erro textuais serão entradas válidas. Se a operação precisar de um objeto complexo como um argumento, ou se tiver de retornar um objeto complexo, você não poderá inserir essa referência do objeto no datapool. Em vez disso, decomponha o objeto em tipos de argumentos simples necessários para a construção de uma instância do objeto. Utilize os botões Inserir Antes e Inserir Depois para incluir campos no datapool com este fim. Você deverá modificar o código de teste para construir uma instância do objeto com os dados fornecidos.

Executando o Teste e Examinando os Resultados

Quando você tiver criado o código de teste e os dados de teste, estará pronto para executar o teste. É possível executar o teste no IDE ou planejá-lo em um Conjunto do TestManager. Consulte o Mentor de Ferramenta: Executando um Conjunto de Teste Utilizando o Rational TestManager para obter mais informações sobre esse tópico.

1. Quando o teste começar a ser executado, será solicitado que você forneça um local para os resultados do registro do teste. Quando você especifica um local, o TestManager utiliza os resultados da execução do teste dele.
2. Ao final da execução, o TestManager exibe o Registro do Teste. Para visualizar os resultados do teste, selecione a guia Visualização Detalhada na janela Visualizador do Log. Expanda a visualização da árvore dos resultados para ver os detalhes da execução do teste. Para acessar mais informações, clique com o botão direito do mouse em qualquer linha e selecione Propriedades.

3.   Implementar um Teste de Cenário

O objetivo de um teste de cenário é validar que uma determinada série de operações em uma determinada série de componentes seja combinada para executar corretamente uma tarefa coletiva. Os testes de cenário são criados a partir de diagramas de interação, especificamente a partir de diagramas de seqüência e de colaboração. O processo de criação e execução de um teste de unidade é composto por estas três etapas:

• Gerando Código de Teste de Cenário
• Gerando Dados do Teste de Cenário
• Executando o Teste e Examinando os Resultados

Gerando Código de Teste de Cenário

O código de teste do cenário conterá todos os códigos de driver de teste necessários para instanciar os componentes, chamar as operações em teste e avaliar os resultados dessas operações utilizando pontos de verificação. Pontos de verificação são um mecanismo pelo qual o código de teste pode executar instruções SQL em um banco de dados a fim de verificar a manipulação correta 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 > Selecionar Gabarito do Teste de Cenário.
3. Navegue para o gabarito apropriado para o servidor EJB. No caso do WebSphere, selecione o arquivo websphere_{_}scenario.template na pasta EJBWebSphereScenario. No caso do Web Logic, selecione o arquivo weblogic_scenario.template na pasta EJBWeb LogicScenario.
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 no diagrama em que serão testados. Para especificar as mensagens, dê um clique duplo na linha da mensagem e especifique um nome na lista de opções na guia Geral. O nome deve corresponder à operação que está sendo testada. Além disso, essas especificações podem ser modificadas para incluir dados da etapa de teste.
   
   Como exemplo, por padrão, o Rose exporá a especificação da mensagem da seguinte forma:
   getTransactions(customerID : String)
   
   Essa especificação pode ser modificada para incluir um caso de dados simples, conforme a seguir:
   getTransactions(customerID : String="BBryson")
   
   Para cada teste de cenário, o QualityArchitect gerará automaticamente um datapool para os dados da etapa de teste. Os dados do diagrama serão preenchidos na primeira linha. Você pode incluir mais linhas a partir desse momento.
5. Para iniciar o teste, clique com o botão direito do mouse no diagrama do navegador e selecione Rational Test > Gerar Teste de Cenário. Efetue login no projeto, caso seja solicitado. 
6. Uma caixa de diálogo aparecerá, solicitando que você selecione os destinos de teste do cenário. Selecione todos os componentes do diagrama que farão parte do teste. Para cada componente selecionado, a operação correspondente especificada nessa mensagem do 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 no diagrama em que serão testados. Para especificar as mensagens, dê um clique duplo na linha da mensagem e especifique um nome na lista de opções na guia Geral. O nome deve corresponder à operação que está sendo testada. Além disso, essas especificações podem ser modificadas para incluir dados da etapa de teste.
   
   Como exemplo, por padrão, o Rose exporá a especificação da mensagem da seguinte forma:
   getTransactions(customerID : String)
   
   Essa especificação pode ser modificada para incluir um caso de dados simples, conforme a seguir:
   getTransactions(customerID : String="BBryson")
   
   Para cada teste de cenário, o QualityArchitect gerará automaticamente um datapool para os dados da etapa de teste. Os dados do diagrama serão preenchidos na primeira linha. Você pode incluir mais linhas a partir desse momento.
2. Para iniciar o teste, clique com o botão direito do mouse no diagrama do navegador e selecione Rational Test > Gerar Teste de Cenário. Efetue login no projeto, caso seja solicitado. 
3. Uma caixa de diálogo aparecerá, solicitando que você selecione os destinos de teste do cenário. Selecione todos os componentes do diagrama que farão parte do teste. Para cada componente selecionado, a operação correspondente especificada nessa mensagem do componente será chamada. 

Pontos de Verificação

Para cada operação que será chamada e novamente ao final do teste, será solicitado que você insira um ponto de verificação. Os pontos de verificação são utilizados pelo QualityArchitect para validar a execução correta dessas operações. Embora a arquitetura do ponto de verificação seja aberta e extensível, atualmente apenas o ponto de verificação do banco de dados está implementado. O ponto de verificação do banco de dados permite digitar SQL para execução de uma consulta. A consulta criada será executada no momento do teste para validar a manipulação correta do banco de dados pelo componente. 

 Você pode implementar seus próprios pontos de verificação, utilizando as etapas da Ajuda on-line do QualityArchitect.

1. Selecione Sim para inserir um ponto de verificação.
2. Selecione o tipo apropriado de ponto de verificação a ser inserido. A menos que você tenha implementado seus próprios pontos de verificação, deve selecionar o Ponto de Verificação do Banco de Dados.
3. Será exibido um Construtor de Consulta, que será utilizado para estabelecer os parâmetros de conexão com o banco de dados e construir a consulta que será executada para validar o funcionamento correto da operação que está sendo chamada. É necessário um conhecimento básico do banco de dados subjacente e da sintaxe SQL para estabelecer essa conexão e criar essa consulta.

O código necessário para instanciar todos os componentes, chamar todas as operações e executar os pontos de verificação inseridos é a saída neste estágio.

Gerando Dados do Teste de Cenário

Para cada teste de cenário gerado, o QualityArchitect cria automaticamente um datapool para conter os dados de teste. Se o diagrama continha dados especificados, então a primeira linha desse datapool já terá sido preenchido com essas informações, e também as informações relacionadas aos pontos de verificação inseridos. Caso contrário, o datapool conterá apenas as informações relacionadas aos pontos de verificação.

Para visualizar e editar essas informações, faça o seguinte:

1. No Rose, selecione Ferramentas > Rational Test > Barra de Ferramentas.
2. Na Barra de Ferramentas, selecione o segundo item da barra de ferramentas para editar o datapool. O QualityArchitect terá criado um datapool que contém o nome do diagrama de cenário, que termina com um _D. O algoritmo utilizado para nomear o datapool é suficientemente complexo, portanto é muito difícil prever o nome de cada datapool nessa documentação.

Para editar esses dados, siga as mesmas etapas básicas descritas em Trabalhando com Datapools.

Executando o Teste e Examinando os Resultados

Quando você tiver criado o código de teste e os dados de teste, estará pronto para executar o teste. É possível executar o teste no IDE ou planejá-lo em um Conjunto do TestManager. Consulte o Mentor de Ferramenta: Executando um Conjunto de Teste Utilizando o Rational TestManager para obter mais informações sobre esse tópico.

1. Quando o teste começar a ser executado, será solicitado que você forneça um local para os resultados do registro do teste. Quando você especifica um local, o TestManager utiliza os resultados da execução do teste dele.
2. Ao final da execução, o TestManager exibe o Registro do Teste. Para visualizar os resultados do teste, selecione a guia Visualização Detalhada na janela Visualizador do Log. Expanda a visualização da árvore dos resultados para ver os detalhes da execução do teste. Para acessar mais informações, clique com o botão direito do mouse em qualquer linha e selecione Propriedades.

Para os pontos de verificação, não é fornecida indicação Aprovado ou Falha na primeira execução, utilizada para obter uma captura instantânea dos resultado de pesquisa a serem utilizados como dados de linha de base para futuras execuções de teste.

Dê um clique duplo nos pontos de verificação para exibir um comparador que apresente os resultados da consulta. Esses resultados podem ser editados, portanto, se a consulta não retornar os resultados corretos, você poderá modificar esses dados. Todas as execuções subseqüentes desse teste compararão os resultados de pesquisa com os capturados na primeira execução.

4.   Criar um Componente de Stub

Geralmente, os componentes que estão sendo testados em um teste de unidade ou de cenário dependem de outros componentes para a execução de tarefas. Porém, os problemas surgem quando esses componentes secundários não são operacionais. Algumas vezes, eles ainda estão em desenvolvimento; outras vezes, com erro. Independente disso, o teste do componente primário não precisa ser parado até que os componentes secundários estejam disponíveis. Em vez disso, um componente de stub ou temporário pode substituir os componentes não-operacionais para testes. O stub não implementa a funcionalidade do componente real; meramente reage com as entradas. Os stubs retornam uma resposta planejada para um determinado conjunto de valores sem implementar a lógica. É um simples relacionamento de resposta a estímulo.

O QualityArchitect pode criar facilmente stubs para componentes COM e EJB. Esses stubs dependem das tabelas de pesquisa para replicar a lógica de negócios dos componentes que estão sendo substituídos. A tabela, implementada como um datapool, determina o valor retornado para um determinado conjunto de entradas.

O processo de criação e implementação de um stub é composto por estas três etapas:

• Gerando um Componente de Stub
• Gerando uma Tabela de Pesquisa de Stub
• Implementando o Stub

Gerando um Componente de Stub

Ao gerar um stub, você deve gerar um componente completo. Então, para as operações que estão sendo colocadas em stub, é necessário criar uma tabela de pesquisa. Um componente de stub, que contém código de stub para todas as operações desse componente, é a saída do processo de geração de stub. Não é possível criar stub de uma única operação.

Para componentes Com

1. Selecione a interface do componente na Visualização Lógica.
2. Clique com o botão direito do mouse na interface e selecione Rational Test > Gerar Stub. Será questionado onde você deseja colocar o código de stub gerado. Selecione este local, e o código será gerado.

Para componentes EJB

1. Selecione a classe de implementação na Visualização Lógica.  
2. Clique com o botão direito do mouse na classe e selecione Rational Test > Gerar Stub. Será questionado onde você deseja colocar o código de stub gerado. Selecione este local, e o código será gerado.

Gerando uma Tabela de Pesquisa de Stub

Para replicar a lógica do componente real, o stub deve saber como o componente real reagiria a um determinado conjunto de argumentos. Essa lógica é mantida em uma tabela de pesquisa, que especifica que valor ou erro retornar para um determinado conjunto de argumentos. Você cria uma tabela de pesquisa para cada operação no componente que está sendo colocado em stub.

Para componentes Com

1. Selecione a operação abaixo da interface do componente na Visualização Lógica.
2. Clique com o botão direito do mouse na interface e selecione Rational Test > Criar Tabela de Pesquisa. A caixa de diálogo Propriedades do Datapool aparecerá.
3. Para criar essa tabela de pesquisa, siga as mesmas etapas básicas descritas em Trabalhando com Datapools. A tabela será utilizada para especificar os valores ou exceções a serem retornados para um determinado conjunto de argumentos.

Para componentes EJB

1. Selecione a operação fora da classe de implementação do bean na Visualização Lógica. 
2. Clique com o botão direito na classe e selecione 
3. Rational Test > Criar Tabela de Pesquisa. A caixa de diálogo Propriedades do Datapool aparecerá.
4. Para criar essa tabela de pesquisa, siga as mesmas etapas básicas descritas em Trabalhando com Datapools. A tabela será utilizada para especificar os valores ou exceções a serem retornados para um determinado conjunto de argumentos.

Implementando o Stub

Quando a tabela de stub e de pesquisa de stub forem geradas, o stub deverá ser implementado no local do componente existente. Esse processo é específico ao ambiente, e orientações para essa tarefa são fornecidas no título da Ajuda on-line do QualityArchitect.

5.   Utilizar o Gravador de Sessão EJB

O gravador de sessão EJB é um aplicativo Java que permite interagir com componentes EJB ativos e implementados. Essa funcionalidade está disponível apenas para Enterprise JavaBeans, não para componentes COM.

O processo de utilização do registro de sessão EJB envolve estas etapas:

• Iniciando uma Sessão de Gravação XML
• Conectando ao Servidor EJB
• Criando uma Instância do Bean em Teste
• Chamando uma Operação no Bean
• Inserindo Pontos de Verificação e Código Java
• Gerando Código de Teste a partir da Gravação da Sessão EJB

O gravador de sessão EJB pode ser utilizado em dois modos: gravação e não-gravação. Na gravação, todas as ações tomadas são gravadas em um log XML que o gravador de sessão EJB converterá em código Java executável. O código contém todas as chamadas de método, o código Java inserido e os pontos de verificação. Ao operar no modo não-gravação, a ferramenta será limitada ao criar instâncias de EJBs e chamar suas operações.

1. Para se conectar ao servidor EJB, você deve fornecer a URL do Provedor e InitialContextFactory para se conectar ao servidor EJB. Essas informações devem ser iguais às utilizadas pelo código do cliente para se conectar ao servidor. As informações de conexão padrão do WebSphere e do Web Logic podem ser encontradas na documentação do produto on-line. 
2. Depois de fornecer as informações de conexão, selecione Conectar, e será apresentada uma lista de beans implementados no servidor. Você pode interagir com um para muitos beans durante uma sessão, e precisa selecionar o primeiro bean para interagir nesse momento.
3. Aqui, você cria uma instância do primeiro bean em teste. Selecione o método de criação apropriado na metade superior da janela Métodos. Se o método de criação precisar de parâmetros específicos, informe-os na seção Parâmetros. Quando concluir, selecione Chamar para criar uma instância do bean.
4. Com a instância do bean criada, o gravador de sessão EJB apresenta as diversas operações disponíveis nesse bean. Serão exibidas as próprias operações do bean na metade superior da janela Métodos, e as operações herdadas na metade inferior. Como regra geral, as operações herdadas não serão testadas. Quando você tiver selecionado a operação a ser testada, forneça os parâmetros obrigatórios para esta operação na janela Parâmetros.
5. Se o parâmetro não for um objeto complexo, haverá um botão chamado Novo. Será aberta uma janela subseqüente, com uma caixa de diálogo que permite criar uma instância do objeto obrigatório. A janela mostrará todos os construtores e os argumentos obrigatórios para a construção de uma instância do objeto. Quando você tiver fornecido as informações do construtor, deverá nomear o objeto para que ele possa ser mencionado posteriormente durante a gravação, se necessário. 
6. É importante designar nomes aos parâmetros se esses valores forem utilizados novamente durante a gravação da sessão. Se você fornecer um nome, o QualityArchitect poderá preencher o valor no campo de parâmetro quando você clicar com o botão direito do mouse nesse campo.
7. Quando você clicar em Chamar, a operação será chamada com os parâmetros fornecidos. O valor de retorno será mostrado no campo Último Valor de Retorno. Se esse valor for obrigatório como a entrada para uma chamada subseqüente, ele poderá ser arrastado e solto no campo obrigatório. Você também pode clicar com o botão direito quando o mouse estiver apontando no campo de parâmetro em que o valor será inserido. Para determinar quais valores exibir no menu de clique com botão direito, o gravador de sessão EJB vinculará o tipo do parâmetro aos tipos anteriores utilizados durante o teste. 
8. Nesse ponto na sessão, você pode inserir código java ou pontos de verificação no menu Inserir. Os pontos de verificação são iguais ao utilizados na geração do código de teste do cenário. Da mesma forma, o código Java pode ser inserido para executar processamento adicional.
9. Se você estiver no modo de gravação, pode converter a gravação com base em XML em código Java quando todas as etapas do teste forem concluídas. Clique em Parar para executar essa ação. Será solicitado que você converta o código XML em código Java, e você deverá fornecer um nome de sessão e um de script. Código Java, que você pode executar para replicar as etapas executadas durante a gravação, é a saída deste processo.