Guida al tool: Implementazione di un test dei componenti automatico utilizzando Rational QualityArchitect
Questa guida al tool fornisce una panoramica dei compiti di verifica delle unità effettuate utilizzando Rational QualityArchitect.
Strumento: Rational QualityArchitect
Relazioni
Descrizione principale

Panoramica

Questa guida al tool fornisce una panoramica dei compiti di verifica delle unità primarie effettuate utilizzando Rational QualityArchitect:

  • Verifica dell'unità
  • Verifica dello scenario
  • Generazione di stub
  • Registrazione di sessione EJB

Un processo di sviluppo, che rimanda la verifica fino a quando non sono stati assemblati tutti i componenti in un sistema, risulta essere una proposta rischiosa. L'individuazione così ritardata di problemi nel ciclo di vita comporterà una maggiore difficoltà nella correzione e potrebbe provocare significativi ritardi, in particolare se si tratta di problemi di architettura, che, per essere corretti, potrebbero richiedere una riprogettazione su larga scala.

Anche se un team ha una fiducia piuttosto elevata nella qualità dei componenti del sistema, la fiducia generale nella qualità del sistema potrebbe essere troppo bassa per essere accettabile. Ad esempio, si consideri un semplice sistema composto da cinque componenti, ciascuno dei quali viene valutato (mediante le metriche di completamento test oppure metodi meno quantitativi) di essere affidabile al 95%. Poiché l'affidabilità del sistema è cumulativa, la valutazione globale è 95% x 95% x 95% x 95%x 95%, oppure appena più del 77%. Mentre i problemi potenziali in ogni componente potrebbero essere appena 1 su 20, per il sistema nel suo complesso tale rapporto diventa da 1 a 4 (e questo per un sistema con relativamente pochi componenti).

Al contrario, un processo di sviluppo che comprende la verifica dei componenti attraverso un processo di sviluppo iterativo offre molti vantaggi significativi:

  • I problemi possono essere rilevati e risolti in un contesto isolato, rendendoli non solo più facili da risolvere, ma anche più facili da rilevare e diagnosticare.
  • Poiché la verifica e lo sviluppo sono saldamente legati attraverso il ciclo di vita, i sistemi di misurazione dell'avanzamento sono più credibili e possono essere ora visualizzati in base a quanto questo progetto sia codificato e operativo, non solo codificato.
  • Interruzioni alla pianificazione, provocate da problemi imprevisti, vengono minimizzate in modo da rendere la pianificazione generale molto più realistica e da ridurre i rischi del progetto.

Sebbene vi siano enormi benefici nell'effettuare verifiche anticipate, la pratica è molto lontana dall'essere utilizzata ordinariamente, specialmente quando si tratta di effettuare la verifica di componenti non GUI e middle tier.

Perché? Perché è noiosa e richiede tempo e, in passato, i costi per l'avvento di queste queste problematiche pratiche hanno avuto spesso maggior peso dei benefici. Inoltre, poiché la maggior parte dei test sono personalizzati per un particolare componente, è molto difficile la possibilità di riutilizzarli. Molte organizzazioni riconoscono lo spreco di creare test harness e stub da zero e poi non utilizzarli più progetto dopo progetto. Preferiscono concentrarsi su risorse limitate in altre aree.

Con QualityArchitect, diventa effettivamente possibile effettuare verifiche tempestivamente poiché i test harness e gli stub vengono generati automaticamente: non solo una volta, ma in modo incrementale mentre il modello si evolve attraverso lo sviluppo. L'intero processo di sviluppo diventa più strutturato, misurato e visibile così come i risultati, provenienti dai test dei componenti, facilitano criteri di immissione più severi per impedire verifiche del sistema premature. QualityArchitect consente agli sviluppatori di focalizzarsi sugli aspetti creativi della definizione dei test, in modo da poter impiegare il tempo nell'individuare il modo migliore per fare esercitazioni con un componente, invece che scrivere ed effettuare il debug di driver di test e stub. Gli sviluppatori e gli architetti lavorano insieme con i modelli visivi condivisi, in modo da poter sviluppare naturalmente una relazione più produttiva gli uni con gli altri.

Questa guida al tool è applicabile quando si esegue Windows 98/2000/NT 4.0.

Modalità d'uso del tool

Questa guida al tool fornisce informazioni sui principali compiti associati all'implementazione di test dei componenti automatico utilizzando QualityArchitect:

  1. Operazioni prerequisite per la verifica delle unità:
  2. Implementazione di un test delle unità
  3. Implementazione di un test di scenario
  4. Creazione di un componente stub
  5. Utilizzo di un Session Recorder EJB

1.   Operazioni prerequisite per la verifica delle unità

Per generare test con QualityArchitect, se sono per COM di componenti EJB, occorre creare un progetto Rational e configurarlo utilizzando l'amministratore Rational. Questo progetto deve contenere un archivio dati del test per contenere tutte le risorse di verifica, quali i risultati del test e i pool di dati. Tali informazioni vengono descritte in Guida al tool: Configurazione di progetti utilizzando l'amministratore Rational.

2.   Implementazione di un test delle unità

L'obiettivo di un test delle unità è quello di convalidare che un'operazione data su un dato componente fornisca il valore di ritorno corretto per un insieme specifico di input. I test delle unità vengono creati al di fuori della specifica delle classi nella vista logica. Il processo di creazione e di esecuzione di un test delle unità è composto da queste tre fasi:

  • Generazione di codice di test delle unità
  • Generazione di dati dei test delle unità
  • Esecuzione di test ed esame dei risultati

Generazione di codice di test delle unità

Il codice del test delle unità contiene tutte le istruzioni necessarie a creare le istanze del componente, richiamare l'operazione sottostante al test ed esaminare il risultato restituito rispetto alla linea di base.

Per componenti COM
  1. Selezionare l'operazione da verificare al di sotto dell'interfaccia del componente nella vista logica.
  2. Fare clic con il tasto destro del mouse sull'operazione elencata al di sotto dell'interfaccia del componente e selezionare Test Rational> Genera test di unità. Se richiesto, durante questo processo è possibile che occorra accedere ad un progetto Rational.

QualityArchitect genera codice compatibile con Visual Basic 6 come output di questo processo.

Da Visual Basic, occorre prima cercare di compilare il codice. Occorre esaminare eventuali errori di compilazione. In alcuni casi, QualityArchitect non sarà in grado di generare codice per verificare operazioni che fanno uso massiccio di tipi di dati complessi. In tal caso, QualityArchitect inserirà codice non valido, che al momento della compilazione evidenzierà i segmenti di codice dove occorre l'immissione manuale di codice. Una volta compilato il codice, è possibile procedere alla fase successiva, Generazione di dati di test delle unità.

Per componenti EJB
  1. Selezionare l'operazione da verificare dall'interfaccia remota nella vista logica.
  2. Fare clic con il tasto destro sull'operazione e selezionare Test Rational> Seleziona modello di test delle unità.
  3. Esplorare fino al modello appropriato per il server EJB. Per WebSphere, selezionare websphere_remote.template nella cartella Metodi EJBWebSphereBusiness. Per Web Logic, selezionare weblogic_remote.template nella cartella Metodi EJBWeb LogicBusiness.
  4. Selezionare Test Rational> Genera test delle unità. Se richiesto durante questo processo, è possibile che occorra accedere ad un progetto Rational.  

QualityArchitect genererà codice Java come output di questo processo.

È possibile utilizzare IDE oppure un editor a scelta per esaminare il codice Java. Rational Rose viene fornito con l'editor R2, che può essere utilizzato a tale scopo.

Una volta aperto l'editor, è prima possibile provare a compilare il codice. Occorre esaminare eventuali errori di compilazione. In alcuni casi, QualityArchitect non sarà in grado di generare codice che faccia uso massiccio di tipi di dati complessi. In tal caso, QualityArchitect inserirà codice non valido, che non effettuerà compilazioni, ma contrassegnerà righe di codice dove occorre l'immissione manuale di codice. Una volta compilato il codice, è possibile procedere alla fase successiva, Generazione di dati di test delle unità.

Generazione di dati di test delle unità

Il vero modo per misurare la riuscita di un test di unità è fornito dai dati del test. Il codice del test stesso è completamente disponibile, poiché QualityArchitect può rigenerare il codice in qualsiasi momento. Mentre QualityArchitect può creare il codice del test, non può creare dati di test significativi. Questa è la responsabilità dell'analista o di chi effettua l'implementazione. Occorre fare attenzione alla creazione di dati di test che convalidano test positivi e negativi rappresentativi. I dati di test, che sono focalizzati sulle condizioni limite della logica del componente, sono candidati eccellenti per i dati di test delle unità.

Per componenti COM
  1. Selezionare l'operazione da verificare al di sotto dell'interfaccia del componente nella vista logica.
  2. Fare clic con il tasto destro sull'operazione e selezionare Test Rational> Crea pool di dati.
  3. Una volta selezionato Crea pool di dati, viene visualizzata una finestra delle proprietà del pool di dati. A questo punto, è possibile selezionare Modifica dati del pool di dati per iniziare l'immissione di dati oppure selezionare Definisci campi del pool di dati affinché QualityArchitect generi dati di test.
Per componenti EJB
  1. Selezionare l'operazione da verificare dall'interfaccia remota nella vista logica.
  2. Fare clic con il tasto destro del mouse sull'operazione elencata al di sotto dell'interfaccia remota e selezionare Test Rational> Crea pool di dati.
  3. Una volta selezionato Crea pool di dati, viene visualizzata una finestra delle proprietà del pool di dati. A questo punto, è possibile selezionare Modifica dati del pool di dati per iniziare l'immissione di dati oppure selezionare Definisci campi del pool di dati affinché QualityArchitect generi dati di test.
Utilizzo dei pool di dati

Se si seleziona Definisci campi dei pool di dati, occorre saper utilizzare le funzioni di generazione dati di test di QualityArchitect. QualityArchitect può generare vari tipi di dati generici, che vengono specificati nell'elenco a discesa dei tipi di dati nel campo Tipo.  

Una volta selezionati i tipi appropriati, selezionare il numero di righe da generare e fare clic su Genera dati. È probabile che QualityArchitect non possa generare tutti i dati. Ad esempio, QualityArchitect potrà generare un elenco generico di città degli USA, ma non potrà generare un elenco valido di numeri di fattura specifici del sistema per un sistema ordinante. Questi dati devono essere immessi manualmente come un tipo dati oppure immessi direttamente in un pool di dati. Il valore di creare un tipo di dati con dati personalizzati è che QualityArchitect, da questo punto in poi, potrà generare questo tipo di dati dall'interfaccia Definisci campi di pool di dati. Se si immettono direttamente i dati nel pool di dati, saranno accettabili solo per quel pool di dati specifico.

Quando si seleziona Modifica dati del pool di dati, si accedono direttamente dati di test significativi. Esiste un campo per ogni argomento, così come un campo per una restituzione prevista e un campo per un errore previsto. Quando si specifica un errore, entrambi i messaggi con numeri di errore e messaggi di errore con testo sono voci valide. Se l'operazione richiede un oggetto complesso come un argomento, non occorre inserire tale riferimento dell'oggetto nel pool di dati. Invece, analizzare l'oggetto fino ad arrivare ai semplici tipi di argomenti richiesti per costruire un'istanza dell'oggetto. Utilizzare i pulsanti Inserisci prima e Inserisci dopo per aggiungere campi al pool di dati a tale scopo. Occorre modificare il codice di test per costruire un'istanza dell'oggetto con i dati forniti.

Esecuzione di test ed esame dei risultati

Una volta creato il codice di test e i dati di test, si è pronti ad eseguire il test. È possibile eseguire il test da IDE oppure pianificare il test in una Suite TestManager. Consultare Giuda al tool: Esecuzione di un gruppo di test utilizzando Rational TestManager per ulteriori informazioni su questo argomento.

  1. Quando comincia l'esecuzione del test, viene richiesto di fornire una posizione per i risultati di log del test. Una volta specificata la posizione, TestManager posiziona i risultati del test eseguito in quella posizione.
  2. Al termine dell'esecuzione, TestManager visualizza il file di log dei test. Per visualizzare i risultati del test, selezionare la scheda Vista dettagliata della finestra Visualizzatore log. Espandere la vista ad albero dei risultati per visualizzare i dettagli del test eseguito. È possibile accedere ad ulteriori informazioni facendo clic con il tasto destro del mouse su qualsiasi riga e selezionando Proprietà.

3.   Implementazione di un test di scenario

L'obiettivo di un test di scenario è di convalidare che una serie di operazioni date tra una serie di componenti si combinino per eseguire correttamente un compito collettivo. I test di scenario vengono creati dai diagrammi interazione, in particolare diagrammi di sequenza e diagrammi collaborazione. Il processo di creazione e di esecuzione di un test delle unità è compreso da queste tre fasi:

  • Generazione di codice di test degli scenari
  • Generazione di dati dei test degli scenari
  • Esecuzione di test ed esame dei risultati

Generazione di codice di test degli scenari

Il codice di test degli scenari comprende tutti i codici dei driver di test necessari a creare istanze dei componenti, richiamare le operazioni al di sotto dei test e valutare i risultati di tali operazioni utilizzando i punti di verifica. I punti di verifica sono un meccanismo mediante il quale il codice di test può eseguire istruzioni SQL su un database per verificare l'appropriata manipolazione dei dati sottostanti.

Per componenti EJB
  1. Selezionare il diagramma collaborazione nel browser.
  2. Fare clic con il tasto destro sull'operazione e selezionare Test Rational > Seleziona modello di test degli scenari.
  3. Esplorare fino al modello appropriato per il server EJB. Per WebSphere, selezionare websphere_scenario.template nella catella EJBWebSphereScenario. Per Web Logic, selezionare weblogic_scenario.template nella cartella EJBWeb LogicScenario.
  4. Aprire la sequenza data oppure il diagramma collaborazione che modella lo scenario al di sotto del test. È importante che i messaggi ai componenti siano specificati per i componenti sul diagramma che sarà verificato. I messaggi vengono specificati facendo doppio clic sulla riga del messaggio e specificando il nome nell'elenco a discesa sulla scheda Generale. Il nome deve corrispondere all'operazione verificata. Inoltre, queste specifiche possono essere modificate per includere i dati degli scenari di test.

    Come esempio, per impostazione predefinita, Rose esporrà la specifica dei messaggi come:
    getTransactions(customerID : String)

    Questa specifica può essere modificata per includere un caso di dati singoli come segue:
    getTransactions(customerID : String="BBryson")

    Per ogni test di scenario, QualityArchitect genera automaticamente un pool di dati per i dati dello scenario di test. I dati contenuti nel diagramma riempiranno la prima riga. È possibile aggiungere righe aggiuntive da questo punto in poi.
  5. Per iniziare il test, fare clic con il tasto destro del mouse sul diagramma nel browser e selezionare Test Rational> Genera test degli scenari. Accedere al progetto, se viene richiesto.  
  6. Viene visualizzata una finestra di dialogo per richiedere di selezionare le destinazioni dei test degli scenari. Selezionare tutti i componenti sul diagramma che prendono parte al test. Per ciascun componente selezionato, verrà richiamata l'operazione corrispondente specificata in questo messaggio del componente.  
Per componenti COM
  1. Aprire la sequenza data oppure il diagramma collaborazione che modella lo scenario al di sotto del test. È importante che i messaggi ai componenti siano specificati per i componenti sul diagramma che sarà verificato. I messaggi vengono specificati facendo doppio clic sulla riga del messaggio e specificando il nome nell'elenco a discesa sulla scheda Generale. Il nome deve corrispondere all'operazione verificata. Inoltre, queste specifiche possono essere modificate per includere i dati degli scenari di test.

    Come esempio, per impostazione predefinita, Rose esporrà la specifica dei messaggi come:
    getTransactions(customerID : String)

    Questa specifica può essere modificata per includere un caso di dati singoli come segue:
    getTransactions(customerID : String="BBryson")

    Per ogni test di scenario, QualityArchitect genera automaticamente un pool di dati per i dati dello scenario di test. I dati contenuti nel diagramma riempiranno la prima riga. È possibile aggiungere righe aggiuntive da questo punto in poi.
  2. Per iniziare il test, fare clic con il tasto destro del mouse sul diagramma nel browser e selezionare Test Rational> Genera test degli scenari. Accedere al progetto, se viene richiesto.  
  3. Viene visualizzata una finestra di dialogo per richiedere di selezionare le destinazioni dei test degli scenari. Selezionare tutti i componenti sul diagramma che prendono parte al test. Per ciascun componente selezionato, verrà richiamata l'operazione corrispondente specificata in questo messaggio del componente.  
Punti di verifica

Per ciascuna operazione richiamata e di nuovo alla fine del test, verrà richiesto di inserire un punto di verifica. I punti di verifica vengono utilizzati da QualityArchitect per convalidare che le operazioni accadono correttamente. Sebbene l'architettura dei punti di verifica è aperta e estensibile, attualmente è implementabile solo il punto di verifica del database. Il punto di verifica del database consente di immettere alcuni SQL per eseguire una query. La query creata verrà eseguita al momento del test per convalidare la corretta manipolazione del database da parte del componente.  

Icona della guida È possibile implementare i punti di verifica, utilizzando le fasi individuate nella guida in linea di QualityArchitect.

  1. Selezionare per inserire un punto di verifica.
  2. Selezionare il tipo appropriato del punto di verifica da inserire. Se non sono stati implementati i propri punti di verifica, occorre selezionare PV Database.
  3. Viene visualizzato un Programma di creazione query, che verrà utilizzato per stabilire i parametri di connessione al database e creerà la query da eseguire per la convalida del corretto funzionamento dell'operazione richiamata. Occorre la conoscenza di base del database sottostante e della sintassi SQL per stabilire questa connessione e creare questa query.

Il codice necessario alla creazione di istanze di tutti i componenti, al richiamo di tutte le operazioni e all'esecuzione di punti di verifica inseriti viene emesso in questo punto.

Generazione di dati dei test degli scenari

Per ciascun test di scenario generato, QualityArchitect crea automaticamente un pool di dati per contenere i dati dei test. Se esistevano dati specificati nel diagramma, la prima riga di questo pool di dati verrà riempita con queste informazioni, così come le informazioni relative agli eventuali punti di verifica inseriti. In caso contrario, il pool di dati conterrà solo le informazioni relative ai punti di verifica.

Per visualizzare e modificare queste informazioni, eseguire le seguenti operazioni:

  1. Da Rose, selezionare Tool > Test Rational > Barra degli strumenti.
  2. Dalla Barra degli strumenti, selezionare la seconda voce per modificare il pool di dati. QualityArchitect creerà un pool di dati che contiene il nome del diagramma di scenario, che termina con una _D. L'algoritmo utilizzato per assegnare un nome al pool di dati è sufficientemente complesso per cui è troppo difficile predire il ogni nome del pool di dati in questa documentazione.

Per modificare questi dati, seguire le stesse operazioni di base evidenziate in Utilizzo dei pool di dati.

Esecuzione di test ed esame dei risultati

Una volta creato il codice di test e i dati di test, si è pronti ad eseguire il test. È possibile eseguire il test da IDE oppure pianificare il test in una Suite TestManager. Consultare Giuda al tool: Esecuzione di un gruppo di test utilizzando Rational TestManager per ulteriori informazioni su questo argomento.

  1. Quando comincia l'esecuzione del test, viene richiesto di fornire una posizione per i risultati di log del test. Una volta specificata la posizione, TestManager posiziona i risultati del test eseguito in quella posizione.
  2. Al termine dell'esecuzione, TestManager visualizza il file di log dei test. Per visualizzare i risultati del test, selezionare la scheda Vista dettagliata della finestra Visualizzatore log. Espandere la vista ad albero dei risultati per visualizzare i dettagli del test eseguito. È possibile accedere ad ulteriori informazioni facendo clic con il tasto destro del mouse su qualsiasi riga e selezionando Proprietà.

Per i punti di verifica, non viene fornita alcuna indicazione Pass oppure Fail sulla prima esecuzione, che viene usata per catturare un'istantanea dei risultati della query da utilizzare come riferimento dei dati per future esecuzioni.

Fare doppio clic sui punti di verifica per visualizzare un comparatore che presenti i risultati della query. Tali risultati possono essere modificati, per cui, se la query non restituisce i risultati corretti, tali dati possono essere modificati. Tutte le successive esecuzioni di questo test confronteranno i risultati della query con quelli catturati durante questa prima esecuzione.

4.   Creazione di un componente stub

Spesso i componenti sottoposti a test delle unità o degli scenari dipendono da altri componenti per completare i loro compiti. Si verificano problemi quando questi componenti secondari non sono operativi. A volte sono ancora in fase di sviluppo; a volte sono non operativi. Il test del componente primario non deve essere fermato finché non sono disponibili i componenti secondari. Invece, un componente temporaneo o stub può sostituire componenti non operativi per effettuare una verifica. Lo stub non implementa la funzionalità del componente reale, ma reagisce semplicemente agli input. Gli stub restituiscono una risposta programmata ad un insieme dato di valori senza implementare alcuna logica. Si tratta di una semplice relazione stimolo risposta.

QualityArchitect può creare facilmente stub per i componenti COM e EJB. Tali stub dipendono dalle tabelle di ricerca per replicare la logica di business dei componenti che stanno sostituendo. La tabella, implementata come un pool di dati, determina quale deve essere il valore restituito per un insieme dato di input.

Il processo di creazione e di sviluppo di uno stub è composto da queste tre fasi:

  • Generazione di un componente dello stub
  • Generazione di una tabella di ricerca per stub
  • Distribuzione dello stub

Generazione di un componente dello stub

Quando si crea uno stub, occorre generare un componente completo. Pertanto, per operazioni per le quali si effettua lo stub, occorre creare una tabella di ricerca. Un componente per cui si effettua lo stub, che contiene codice stub per tutte le operazioni di questo componente, è l'output del processo di generazione di stub. Non è possibile effettuare lo stub di una singola operazione.

Per componenti COM
  1. Selezionare l'interfaccia del componente nella vista logica.
  2. Fare clic con il tasto destro sull'interfaccia e selezionare Test Rational> Genera stub. Viene richiesta la posizione in cui si desidera localizzare il codice stub generato. Selezionare questa posizione e il codice verrà generato.
Per componenti EJB
  1. Selezionare la classe di implementazione bean nella vista logica. 
  2. Fare clic con il tasto destro sulla classe e selezionare Test Rational> Genera stub. Viene richiesta la posizione in cui si desidera localizzare il codice stub generato. Selezionare questa posizione e il codice verrà generato.

Generazione di una tabella di ricerca per stub

Per replicare la logica del componente reale, lo stub deve sapere come reagisce il componente reale quando viene fornito un insieme di argomenti. Tale logica viene mantenuta in una tabella di ricerca, che specifica quale valore o errore restituire per un insieme dato di argomenti. Si crea una tabella di ricerca per ciascuna operazione sul componente di cui si effettua lo stub.

Per componenti COM
  1. Selezionare l'operazione al di sotto dell'interfaccia del componente nella vista logica.
  2. Fare clic con il tasto destro sull'interfaccia e selezionare Test Rational> Crea tabella di ricerca. Viene visualizzata la finestra di dialogo Proprietà del pool di dati.
  3. Per creare questa tabella di ricerca, eseguire le stesse operazioni di base evidenziate in Utilizzo dei pool di dati. La tabella verrà utilizzata per specificare i valori o le eccezioni da restituire per un insieme dato di argomenti.
Per componenti EJB
  1. Selezionare l'operazione della classe di implementazione bean nella vista logica. 
  2. Fare clic con il tasto destro sulla classe e selezionare  
  3. Test Rational > Crea tabella di ricerca. Viene visualizzata la finestra di dialogo Proprietà del pool di dati.
  4. Per creare questa tabella di ricerca, eseguire le stesse operazioni di base evidenziate in Utilizzo dei pool di dati. La tabella verrà utilizzata per specificare i valori o le eccezioni da restituire per un insieme dato di argomenti.

Distribuzione dello stub

Quando sono stati generati lo stub e la tabella di ricerca, lo stub deve essere distribuito al posto del componente esistente. Tale processo è specifico dell'ambiente e la guida per questo compito viene fornita al di sotto dell'intestazione della guida in linea di QualityArchitect.

5.   Utilizzo del registratore di sessione EJB

Il registratore di sessione EJB è un'applicazione Java che consente di interagire con componenti EBJ distribuiti e attivi. Questa funzionalità è disponibile solo per JavaBean Enterprise, non per i componenti COM.

Il processo per l'utilizzo di un registratore di sessione EJB comporta le seguenti fasi:

  • Avvio di una sessione di registrazione XML
  • Connessione al server EJB
  • Creazione di un'istanza del bean sottoposto a test
  • Richiamo dell'operazione sul bean
  • Inserimento dei punti di verifica e codice java
  • Generazione di codice di test dal registratore di sessione EJB

Il registratore di sessione EJB può essere utilizzato in due modalità: registrazione e non registrazione. Durante la registrazione, tutte le azioni effettuate vengono registrate in un log XML che il registratore di sessione EJB convertirà in un codice java eseguibile. Il codice contiene tutte le chiamate al metodo, tutti i codico java inseriti e i punti di verifica. Quando si opera in modalità di non registrazione, il tool verrà limitato alla creazione di istanze EJB e al richiamo delle relative operazioni.

  1. Per collegarsi al server EJB, occorre fornire l'URL del provider de InitialContextFactory per collegarsi al server EJB. Queste informazioni devono essere uguali a quelle utilizzate dal codice del client per collegarsi al server. È possibile reperire le informazioni di connessione predefinite per WebSphere e Web Logic nella documentazione del prodotto in linea.  
  2. Quando vengono fornite le informazioni sulla connessione, selezionare Collega (Connect) e viene visualizzato un elenco di bean distribuiti su quel server. È possibile interagire con bean one-to-many durante una sessione e occorre selezionare il primo bean con cui interagire in questo punto.
  3. Viene creata un'istanza del primo bean sottoposto a test. Selezionare il metodo di creazione appropriato dalla metà superiore della finestra Metodi. Se per il metodo di creazione sono necessari parametri specifici, specificarli nella sezione Parametri. Una volta completato, selezionare Invoke per creare un'istanza del bean.
  4. Con l'istanza del bean creato, il registratore della sessione EJB presenta le varie operazioni disponibili su tale bean. Le proprie operazioni del bean vengono visualizzate nella metà superiore della finestra Metodi, mentre le operazioni ereditate nella metà inferiore. Come regola generale, non dovrà essere eseguito il test delle operazioni ereditate. Una volta selezionata l'operazione di cui eseguire il test, è possibile fornire i parametri richiesti per questa operazione nella finestra Parametri.
  5. Se il parametro è un oggetto complesso, verrà visualizzato un pulsante Nuovo. Viene visualizzata una finestra successiva in cui è presente un dialogo che consente di creare un'istanza dell'oggetto richiesto. La finestra illustra tutti i costruttori e gli argomenti richiesti per costruire un'istanza dell'oggetto. Quando vengono fornite le informazioni relative al costruttore, occorre assegnare un nome all'oggetto in modo da potergli fare riferimento durante la registrazione, se necessario.  
  6. Esiste un valore nell'assegnare nomi ai parametri, se tali valori verranno di nuovo utilizzati durante la sessione di registrazione. Se si fornisce un nome, QualityArchitect inserirà il valore in qualsiasi campo dei parametri, quando si fa doppio clic su tale campo.
  7. Quando si fa clic su Richiama (Invoke), l'operazione viene richiamata con i parametri forniti. Il valore di ritorno viene visualizzato nel campo Ultimo valore restituito (Last Return Value). Se questo valore è necessario come input per una chiamata successiva, può essere trascinato nel campo richiesto. È inoltre possibile fare clic con il tasto destro del mouse quando il mouse sta puntando al campo dei parametri dove inserire il valore. Per determinare quali valori presentare sul menu visualizzato con il tasto destro del mouse, il registratore della sessione EJB fa corrispondere il tipo di parametro ai tipi precedenti utilizzati durante la verifica.  
  8. In qualsiasi momento della sessione, è possibile inserire codice java oppure punti di verifica dal menu Inserisci(Insert). I punti di verifica sono uguali a quelli utilizzati durante la generazione di codice di test dello scenario. Allo stesso modo, il codice java può essere inserito per effettuare tutte le ulteriori elaborazioni.
  9. Se si è in modalità registrazione, è possibile convertire la registrazione basata su XML in codice java, quando tutte le fasi del test sono complete. Fare clic su Stop per eseguire questa azione. Viene richiesto di convertire il codice XML in codice java e occorre fornire un nome sessione e un nome script. Il codice Java, che può essere eseguito per replicare queste fasi durante la registrazione, è l'output di questo processo.