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:
-
Operazioni prerequisite per la verifica delle unità:
-
Implementazione di un test delle unità
-
Implementazione di un test di scenario
-
Creazione di un componente stub
-
Utilizzo di un Session Recorder EJB
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.
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
-
Selezionare l'operazione da verificare al di sotto dell'interfaccia del componente nella vista logica.
-
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
-
Selezionare l'operazione da verificare dall'interfaccia remota nella vista logica.
-
Fare clic con il tasto destro sull'operazione e selezionare Test Rational> Seleziona modello di test delle
unità.
-
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.
-
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à.
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
-
Selezionare l'operazione da verificare al di sotto dell'interfaccia del componente nella vista logica.
-
Fare clic con il tasto destro sull'operazione e selezionare Test Rational> Crea pool di dati.
-
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
-
Selezionare l'operazione da verificare dall'interfaccia remota nella vista logica.
-
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.
-
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.
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.
-
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.
-
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à.
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
-
Selezionare il diagramma collaborazione nel browser.
-
Fare clic con il tasto destro sull'operazione e selezionare Test Rational > Seleziona modello di test degli
scenari.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
È possibile implementare
i punti di verifica, utilizzando le fasi individuate nella guida in linea di QualityArchitect.
-
Selezionare Sì per inserire un punto di verifica.
-
Selezionare il tipo appropriato del punto di verifica da inserire. Se non sono stati implementati i propri punti di
verifica, occorre selezionare PV Database.
-
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:
-
Da Rose, selezionare Tool > Test Rational > Barra degli strumenti.
-
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.
-
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.
-
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.
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
-
Selezionare l'interfaccia del componente nella vista logica.
-
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
-
Selezionare la classe di implementazione bean nella vista logica.
-
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
-
Selezionare l'operazione al di sotto dell'interfaccia del componente nella vista logica.
-
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.
-
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
-
Selezionare l'operazione della classe di implementazione bean nella vista logica.
-
Fare clic con il tasto destro sulla classe e selezionare
-
Test Rational > Crea tabella di ricerca. Viene visualizzata la finestra di dialogo Proprietà del pool di
dati.
-
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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
|