SoapUI - Guida rapida

SOAP è l'acronimo di Simple Object Access Protocol. È definito dal World Wide Web Consortium (W3C) all'indirizzohttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 come segue -

SOAP è un protocollo leggero per lo scambio di informazioni in un ambiente decentralizzato e distribuito. È un protocollo basato su XML che consiste di tre parti: una busta che definisce un framework per descrivere cosa c'è in un messaggio e come elaborarlo; un insieme di regole di codifica per esprimere istanze di tipi di dati definiti dall'applicazione; e una convenzione per rappresentare chiamate e risposte di procedure remote.

SOAP - Caratteristiche importanti

Di seguito sono riportate alcune importanti caratteristiche di SOAP.

È un protocollo di comunicazione progettato per comunicare tramite Internet.
Può estendere HTTP per la messaggistica XML.
Fornisce il trasporto dei dati per i servizi Web.
Può scambiare documenti completi o chiamare una procedura remota.
Può essere utilizzato per trasmettere un messaggio.
È indipendente dalla piattaforma e dalla lingua.
È il modo XML per definire quali informazioni vengono inviate e come.
Consente alle applicazioni client di connettersi facilmente a servizi remoti e richiamare metodi remoti.

Sebbene SOAP possa essere utilizzato in una varietà di sistemi di messaggistica e possa essere distribuito tramite una varietà di protocolli di trasporto, l'obiettivo iniziale di SOAP sono le chiamate di procedura remota trasportate tramite HTTP. Altri framework come CORBA, DCOM e Java RMI forniscono funzionalità simili a SOAP, ma i messaggi SOAP sono scritti interamente in XML e sono quindi indipendenti dalla piattaforma e dal linguaggio.

Un messaggio SOAP è un normale documento XML contenente i seguenti elementi:

Envelope- Definisce l'inizio e la fine del messaggio. È un elemento obbligatorio.
Header- Contiene qualsiasi attributo facoltativo del messaggio utilizzato nell'elaborazione del messaggio, in un punto intermedio o nel punto finale finale. È un elemento opzionale.
Body- Contiene i dati XML che compongono il messaggio inviato. È un elemento obbligatorio.
Fault - Un elemento Fault opzionale che fornisce informazioni sugli errori che si verificano durante l'elaborazione del messaggio.

Tutti questi elementi sono dichiarati nello spazio dei nomi predefinito per la busta SOAP -

https://www.w3.org/2001/12/soap-envelope

Lo spazio dei nomi predefinito per la codifica SOAP e i tipi di dati è:

https://www.w3.org/2001/12/soap-encoding

Note- Tutte queste specifiche sono soggette a modifiche. Pertanto, continua ad aggiornarti con le ultime specifiche disponibili sul sito Web di W3.

SOAP - Struttura del messaggio

Il blocco seguente mostra la struttura generale di un messaggio SOAP:

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST è l'acronimo di Representational State Transfer. Può essere definito come uno stile architettonico di progettazione di software. REST non è una specifica o uno standard W3C. Pertanto, è più facile lavorare con i servizi RESTful. Non richiede alcun framework di specifiche middleware.

RIPOSO - Caratteristiche importanti

Di seguito sono riportate alcune importanti caratteristiche di REST.

Si basa su un protocollo di comunicazione senza stato, client-server, memorizzabile nella cache: praticamente in tutti i casi viene utilizzato HTTP.
È un'alternativa leggera di WebService e RPC (Remote Procedure Call) come SOAP-WSDL.
Rappresenta tutto in ID univoco o URI.
Utilizza metodi HTTP standard, come GET, POST, PUT, DELETE.
Collega le fonti insieme.
Le risorse REST potrebbero avere più rappresentazioni.
Qualsiasi informazione denominata è considerata una risorsa. Ad esempio: un'immagine, una persona, un documento, tutto può essere considerato come un esempio di risorsa e rappresentato come un ID univoco o un URI.
Lo stesso World Wide Web, basato su HTTP, può essere visto come un'architettura basata su REST.

I servizi REST sono indipendenti dalla piattaforma e dalla lingua. Poiché si basa su standard HTTP, può funzionare facilmente in presenza di firewall. Come i WebServices, REST non offre alcuna sicurezza integrata, gestione delle sessioni, garanzia QoS ma questi possono essere aggiunti costruendo su HTTP. Per la crittografia, è possibile utilizzare REST su HTTPS.

SoapUI è uno strumento che può essere utilizzato sia per test funzionali che non funzionali. Non si limita ai servizi Web, sebbene sia lo strumento di fatto utilizzato nei test dei servizi Web.

SoapUI - Caratteristiche importanti

Di seguito sono riportate alcune importanti caratteristiche di SoapUI.

È in grado di svolgere il ruolo sia di cliente che di servizio.
Consente agli utenti di creare test funzionali e non funzionali in modo rapido ed efficiente utilizzando un unico ambiente.
È concesso in licenza in base ai termini della GNU Leaser General Public License (LGPL).
È puramente implementato utilizzando la piattaforma JAVA.
Supporta Windows, Mac, più dialetti Linux.
Consente ai tester di eseguire test automatici funzionali, di regressione, conformità e carico su diverse API Web.
Supporta tutti i protocolli e le tecnologie standard per testare tutti i tipi di API.

SoapUI può essere utilizzato per testare l'API RESTful completa e il test del servizio Web SOAP. Supporta test funzionali, test delle prestazioni, test di interoperabilità, test di regressione, test di carico e molto altro.

È facile da usare ed è facile convertire i test funzionali in test non funzionali come Load, Stress testing.

SoapUI è ricco dei seguenti cinque aspetti:

Test funzionali
Test di sicurezza
Test di carico
Protocolli e tecnologie
Integrazione con altri strumenti

Impariamo di più su ciascuna di queste funzionalità.

Test funzionali

SoapUI consente ai tester di scrivere test API funzionali in SoapUI.
SoapUI supporta la funzionalità Drag-Drop che accelera lo sviluppo dello script.
SoapUI supporta il debug dei test e consente ai tester di sviluppare test basati sui dati.
SoapUI supporta più ambienti, semplificando il passaggio tra ambienti QA, Dev e Prod.
SoapUI consente lo scripting avanzato (il tester può sviluppare il proprio codice personalizzato a seconda degli scenari).

Test di sicurezza

SoapUI esegue un set completo di scansione delle vulnerabilità.
SoapUI impedisce a SQL Injection di proteggere i database.
SoapUI esegue la scansione per gli overflow dello stack, causati da documenti di dimensioni enormi.
SoapUI esegue la scansione per lo scripting cross-site, che si verifica quando i parametri del servizio vengono esposti nei messaggi.
SoapUI esegue la scansione fuzzing e la scansione dei confini per evitare comportamenti irregolari dei servizi.

Test di carico

SoapUI distribuisce i test di carico su n numero di agenti LoadUI.
SoapUI simula con facilità test di carico ad alto volume e nel mondo reale.
SoapUI consente rapporti personalizzati avanzati per acquisire i parametri delle prestazioni.
SoapUI consente il monitoraggio delle prestazioni del sistema end-to-end.

Protocolli e tecnologie

SoapUI supporta un'ampia gamma di protocolli -

SOAP - Simple Object Access Protocol
WSDL - Linguaggio di definizione del servizio Web
REST - Trasferimento di stato rappresentativo
HTTP: protocollo di trasmissione Hyper Text
HTTPS: protocollo di trasmissione Hyper Text protetto
AMF - Formato messaggio di azione
JDBC - Connettività database Java
JMS - Java Messaging Service

Integrazione con altri strumenti

Progetto Apache Maven
HUDSON
JUnit
Apache - Ant e altro….

SoapUI è uno strumento di versione gratuita open source con funzionalità di base di test, mentre SoapUI NG Pro è uno strumento commercializzato con funzionalità avanzate di reporting, funzionalità basata sui dati e molto altro.

Confronto

La tabella seguente confronta e mette a confronto le varie funzionalità di SoapUI e SoapUI NG Pro.

Caratteristiche	SoapUI	SoapUI NG Pro
Supported Technologies
SAPONE	sì	sì
WSDL / WADL	sì	sì
RIPOSO	sì	sì
JMS	sì	sì
AMF	sì	sì
JDBC	sì	sì
HTTP	sì	sì
General Features
Applicazione standalone	sì	sì
Supporto multi ambiente	No	sì
Licenza flottante	No	sì
Copertura WSDL	No	sì
Copertura richiesta / risposta	No	sì
Asserzione messaggio	sì	sì
Test refactoring	No	sì
Esecuzione di più test	sì	sì
Test guidato dall'origine dati	No	sì
Librerie di scripting	No	sì
Reporting di unità	No	sì
Fasi del test manuale	sì	sì
Reporting
Rapporti Junit	No	sì
Esportazione dei dati del report	No	sì
Report HTML WSDL	sì	sì
Copertura della suite di test	No	sì
Copertura del caso di test	No	sì
Copertura delle asserzioni	No	sì
Copertura della registrazione dei messaggi	No	sì

SoapUI è uno strumento multipiattaforma. Supporta i sistemi operativi Windows, Linux e Mac.

Prerequisiti

Processor - Processore da 1 GHz o superiore a 32 o 64 bit.
RAM - 512 MB di RAM.
Hard Disk Space - Minimo 200 MB di spazio su disco rigido per l'installazione.
Operating System Version - Windows XP o successivo, MAC OS 10.4 o successivo.
JAVA - JAVA 6 o successivo.

Processo di download

Step 1- Vai su www.soapui.org e fai clic su Scarica SoapUI.

Step 2- Fare clic su "Scarica" per scaricare SoapUI Open Source. Inizierà il download del file .exe di 112 MB nel sistema. Attendi il completamento del processo di download.

Processo di installazione

Step 1 - Dopo il download, esegui il file .exe come "Esegui come amministratore".

Windows avvierà il processo di configurazione come mostrato nello screenshot seguente.

Step 2 - Una volta impostato, la finestra del processo visualizza la seguente schermata, fare clic su Avanti.

Step 3 - Accetta il contratto di licenza e fai clic su Avanti.

Step 4- Scegli la directory di installazione o mantienila come percorso predefinito selezionato dal sistema. Fare clic su Avanti.

Step 5- Scegli i componenti che desideri installare. Fare clic su Avanti.

Step 6 - Accetta il contratto di licenza per HermesJMS e fai clic su Avanti.

Step 7 - Seleziona la directory di destinazione in cui salvare i tutorial e fai clic su Avanti.

Step 8 - Scegli la posizione della cartella del menu Start oppure lascia la posizione predefinita così com'è e fai clic su "Avanti".

Step 9 - Abilitare la casella di controllo "crea un'icona sul desktop" e fare clic su "Avanti".

Ora inizia l'installazione. Ci vorranno alcuni minuti per completare.

Step 10 - Dopo il completamento dell'installazione, fare clic su Fine nella seguente procedura guidata.

Facendo clic su Fine, viene avviato SoapUI.

Barra dei menu
Barra degli strumenti
Barra di navigazione del progetto
Proprietà dell'area di lavoro
Pannello di registro

Processo di configurazione

Il primo passaggio è creare un'area di lavoro che possa contenere più progetti.

Step 1 - Vai a File → Nuovo spazio di lavoro.

Step 2 - Aggiungi il nome dell'area di lavoro e fai clic su OK.

Step 3 - Ora, seleziona il percorso in cui verrà salvato lo spazio di lavoro xml.

Step 4 - Seleziona il percorso e fai clic su Salva.

L'area di lavoro viene creata come mostrato nella seguente schermata. Sono inoltre esposte le proprietà dell'area di lavoro.

WSDL è l'acronimo di Web Services Description Language. È un formato standard per descrivere un servizio web. WSDL è stato sviluppato congiuntamente da Microsoft e IBM. WSDL è pronunciato come "wiz-dull" e definito come "WSD-L".

WSDL ─ Una breve storia

WSDL 1.1 è stato presentato come nota W3C da Ariba, IBM e Microsoft per la descrizione dei servizi per l'attività XML del W3C sui protocolli XML nel marzo 2001.

WSDL 1.1 non è stato approvato dal World Wide Web Consortium (W3C), tuttavia ha appena rilasciato una bozza per la versione 2.0 che sarà una raccomandazione (uno standard ufficiale), e quindi approvata dal W3C.

WSDL ─ Punti da notare

WSDL è un protocollo basato su XML per lo scambio di informazioni in un ambiente decentralizzato e distribuito. Alcune delle altre funzionalità di WSDL sono le seguenti:

Le definizioni WSDL descrivono come accedere a un servizio Web e quali operazioni eseguirà.
È un linguaggio per descrivere come interfacciarsi con servizi basati su XML.
È parte integrante di UDDI (Universal Description, Discovery, and Integration), un registro aziendale mondiale basato su XML.
WSDL è la lingua utilizzata da UDDI.

Utilizzo WSDL

WSDL viene spesso utilizzato in combinazione con SOAP e XML Schema per fornire servizi Web su Internet. Un programma client che si connette a un servizio Web può leggere il WSDL per determinare quali funzioni sono disponibili sul server. Tutti i tipi di dati speciali utilizzati sono incorporati nel file WSDL sotto forma di XML Schema. Il client può quindi utilizzare SOAP per chiamare effettivamente una delle funzioni elencate nel WSDL.

Capire WSDL

WSDL suddivide i servizi web in tre elementi specifici e identificabili che possono essere combinati o riutilizzati una volta definiti.

I tre elementi principali di WSDL che possono essere definiti separatamente sono:

Types
Operations
Binding

Un documento WSDL ha vari elementi, ma sono contenuti all'interno di questi tre elementi principali, che possono essere sviluppati come documenti separati e quindi possono essere combinati o riutilizzati per formare file WSDL completi.

In questo tutorial, stiamo seguendo CurrencyConverter WSDL: http://www.webservicex.net

Formato ed elementi

CurrencyConverter WSDL avrà il seguente aspetto:

WSDL ─ Tipo di porta

L'elemento <portType> combina più elementi di messaggio per formare un'operazione completa unidirezionale o di andata e ritorno. Ad esempio, un <portType> può combinare una richiesta e un messaggio di risposta in un'unica operazione di richiesta / risposta. Questo è più comunemente usato nei servizi SOAP. Un portType può definire più operazioni.

Esempio

L'elemento portType definisce una singola operazione, denominata ConversionRate.
L'operazione è costituita da un singolo messaggio di input ConversionRateHttpPostIn.
L'operazione per il messaggio di output è ConversionRateHttpPostOut.

Modelli di funzionamento

WSDL supporta quattro modelli di funzionamento di base:

Senso Unico

Il servizio riceve un messaggio. L'operazione ha quindi un unico elemento di input. La grammatica per l'operazione unidirezionale è:

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Richiesta ─ Risposta

Il servizio riceve un messaggio e invia una risposta. L'operazione ha quindi un elemento di input, seguito da un elemento di output. Per incapsulare gli errori, è anche possibile specificare un elemento fault opzionale. La grammatica per un'operazione di richiesta-risposta è:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Sollecitare ─ Risposta

Il servizio invia un messaggio e riceve una risposta. L'operazione ha quindi un elemento di output, seguito da un elemento di input. Per incapsulare gli errori, è anche possibile specificare un elemento fault opzionale. La grammatica per un'operazione di sollecitazione-risposta è:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Notifiche

Il servizio invia un messaggio. L'operazione ha quindi un unico elemento di output. Di seguito è riportata la grammatica per un'operazione di notifica:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Binding e servizio

Il <binding>element fornisce dettagli specifici su come un'operazione portType verrà effettivamente trasmessa in rete.

Le associazioni possono essere rese disponibili tramite più trasporti tra cui HTTP GET, HTTP POST o SOAP.
I collegamenti forniscono informazioni concrete su quale protocollo viene utilizzato per trasferire le operazioni portType.
Le associazioni forniscono informazioni su dove si trova il servizio.
Per il protocollo SOAP, l'associazione è <soap: binding> e il trasporto è costituito da messaggi SOAP in cima al protocollo HTTP.
È possibile specificare più associazioni per un singolo portType.

Servizio

Il <service>elemento definisce le porte supportate dal servizio web. Per ciascuno dei protocolli supportati, è presente un elemento porta. L'elemento di servizio è una raccolta di porte.

I client del servizio Web possono apprendere quanto segue dall'elemento del servizio:

Dove accedere al servizio,
Attraverso quale porta accedere al servizio web e
Come vengono definiti i messaggi di comunicazione.

L'elemento di servizio include un elemento di documentazione per fornire documentazione leggibile dall'uomo.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

Il progetto SoapUI è il punto centrale in tutti i test SoapUI. Una volta creato il progetto, l'utente può creare ed eseguire test funzionali, test di carico, creare servizi fittizi e molto altro ancora.

In questo capitolo, discuteremo di due cose - Come -

Crea un progetto SOAP
Aggiungi un WSDL

Crea un progetto SOAP

Step 1 - Nel navigatore sul lato sinistro dello schermo, fare clic con il pulsante destro del mouse su "Progetto" e selezionare "Nuovo progetto SOAP".

Oppure vai su File e seleziona Nuovo progetto Soap.

Alla selezione, si apre una nuova finestra pop-up -New Soap Project.

Step 2 - Project Name: Immettere un nome di progetto - è il campo di immissione dell'utente. Initial WSDL: Non è obbligatorio. Dipende dall'utente. L'utente può fornire WSDL o aggiungere dopo la creazione del progetto.

In questo caso, creiamo un progetto e aggiungiamo il WSDL successivamente.

Step 3- Fare clic su OK. Creerà un nuovo progetto e sarà visibile nel pannello di navigazione a sinistra.

Aggiungi un WSDL

I progetti SOAP sono basati su WSDL. Non è necessario iniziare importando un WSDL, ma semplifica il test poiché il WSDL contiene tutte le informazioni necessarie per testare un servizio web come le informazioni sulle richieste e le risposte, cosa contengono e molto altro, il che semplifica il test di SoapUI.

Step 1 - Per aggiungere un WSDL, fare clic con il pulsante destro del mouse sul nome del progetto (SOAP - Esempio) e selezionare Aggiungi WSDL.

Alla selezione, viene visualizzata la procedura guidata WSDL.

Step 2 - WSDL Location: Immettere un WSDL come http://www.webservicex.com o sfogliarlo dal computer.

Step 3- Non appena viene inserito WSDL, 3 caselle di controllo - Crea richieste, Crea TestSuite, Crea MockServices saranno abilitate. In base al requisito, l'utente può selezionare una o più caselle di controllo.

Per impostazione predefinita, la casella di controllo di Crea richieste è selezionata.

Step 4- Fare clic su OK. WSDL è stato aggiunto correttamente nel progetto. Può essere verificato osservando il pannello di navigazione a sinistra. All'interno del progetto sono presenti più operazioni e le richieste vengono aggiunte in base a WSDL.

Visualizzazione dettagli

Per ottenere maggiori dettagli sul progetto, fare doppio clic sul nome del progetto, si aprirà una nuova finestra con vari dettagli.

Nella scheda Panoramica, vengono fornite varie informazioni come:

File Path - Visualizza la posizione del progetto xml salvato.
Interface Summary - Nome dell'interfaccia e WSDL ad essa associato.
Test Summary - Visualizza suite di test, casi di test, passaggi di test, asserzioni aggiunte al progetto.

L'utente può fare doppio clic sul nome dell'interfaccia per ottenere i dettagli dell'interfaccia. Si aprirà una nuova finestra e visualizzerà le informazioni relative a WSDL. Questi sono molto utili per navigare ed esaminare un WSDL.

Nella scheda Panoramica, elenca le definizioni WSDL, le parti della definizione ei dettagli dell'operazione.

Allo stesso modo, Service Endpoints elenca i dettagli degli endpoint.

Nella scheda Contenuto WSDL, tutti i dettagli di WSDL in formato XML / schema sono forniti come mostrato nella seguente schermata.

TestSuiteè una raccolta di casi di test che possono essere utilizzati per raggruppare i test funzionali in unità logiche. È possibile creare un numero qualsiasi di TestSuite all'interno di un progetto SoapUI per supportare enormi scenari di test.

Creazione di TestSuite

Step 1 - All'interno di un progetto, fare clic con il pulsante destro del mouse sull'interfaccia (accanto al nome del progetto) e quindi fare clic su "Genera TestSuite".

Qui, SOAP - Example è un nome di progetto mentre CurrencyConvertorSoap e CurrencyConvertorSoap12 sono interfacce.

Step 2- Si apre una nuova procedura guidata. Seleziona le scelte in base al requisito.

Step 3 - Una volta effettuata la selezione, fare clic su OK.

Step 4- Seleziona la casella di controllo Genera LoadTest. Questo genererà un LoadTest per ogni TestCase creato in questa TestSuite.

Step 5 - Immettere il nome di TestSuite nella nuova procedura guidata e quindi fare clic su OK.

La TestSuite creata viene visualizzata nel pannello di navigazione come mostrato nella seguente schermata.

Step 6- Fare doppio clic sul nome di TestSuite e la finestra TestSuite si aprirà nel pannello di destra. Poiché non vengono aggiunti casi di test, è vuoto.

Le proprietà di TestSuite possono essere visualizzate nella parte inferiore del pannello di navigazione. È possibile aggiungere nuove proprietà personalizzate a livello di TestSuite.

Un TestCase è una raccolta di TestSteps assemblati per testare alcuni aspetti specifici dei servizi web. L'utente può aggiungere n numero di TestCase a una TestSuite e persino modularizzarli per chiamarsi a vicenda per scenari di test complessi.

Creazione di TestCase

Step 1- All'interno di una TestSuite, l'utente può aggiungere più casi di test. Fare clic con il pulsante destro del mouse su Test Suite e selezionare "Nuovo test case".

Step 2 - Immettere il nome del TestCase e fare clic su OK.

Il TestCase creato ha zero passaggi di test al momento. TestCase viene aggiunto con zero TestSteps per tutti i tipi di test disponibili. Una volta aggiunti i TestSteps, i numeri tra parentesi cambierebbero automaticamente. Il TestStep funzionale dovrebbe andare in "Test Steps" mentre un TestStep delle prestazioni dovrebbe andare in "Load Test", e un TestStep di sicurezza dovrebbe andare in "Security Tests".

Step 3- Fare doppio clic sul nome del TestCase e una finestra TestCase si aprirà sul pannello di destra. Poiché non sono stati aggiunti TestSteps, è vuoto come mostrato nello screenshot seguente.

I TestSteps sono i "mattoni" dei test funzionali in SoapUI. Questi vengono aggiunti a un TestCase e utilizzati per controllare il flusso di esecuzione e convalidare la funzionalità dei servizi Web da testare.

Inserimento di TestStep

Step 1- Fare clic con il pulsante destro del mouse su TestSteps. Aggiungi Step e seleziona un TestStep appropriato dall'elenco. Ad esempio, se l'utente deve testare un WebService REST, selezionerà la richiesta di test REST.

Step 2 - Aggiungere un TestStep per convalidare la richiesta SOAP importata selezionando TestSteps → Add Step → SOAP Request.

Step 3 - Immettere il nome del TestStep e fare clic su OK nella procedura guidata.

Facendo clic su "OK", viene visualizzata una finestra di dialogo per selezionare l'operazione da richiamare. Vengono elencate tutte le operazioni e gli utenti possono selezionare l'operazione che desiderano richiamare.

Ci sono due operazioni che verranno elencate. Entrambe le operazioni sono le stesse tranne la versione SOAP utilizzata.CurrencyConvertorSoap utilizza SOAP versione 1.1 mentre, CurrencyConvertorSoap12 utilizza SOAP versione 1.2.

Step 4 - Seleziona il primo - CurrencyConvertorSoap e fai clic su OK.

Durante l'aggiunta di un TestCase, è possibile aggiungere diverse asserzioni standard. Le asserzioni sono anche chiamate checkpoint / punti di convalida della richiesta / risposta SOAP.

Step 5 - Creiamo un TestCase con un'opzione predefinita che significa creare un TestStep SENZA uno dei seguenti punti di convalida -

Verifica se il messaggio di risposta è SOAP, all'esecuzione del test.
Verifica se lo schema di risposta è valido.
Verifica se la risposta SOAP contiene FAULT.

Step 6 - Facendo clic su OK, viene visualizzata la seguente schermata XML della richiesta.

Il conteggio dei passaggi del test viene ora incrementato a uno quando viene aggiunto un TestStep funzionale. Allo stesso modo, quando si aggiungono TestSteps di carico e sicurezza, il numero corrispondente aumenta automaticamente in base al numero di passaggi aggiunti.

Richiedi configurazione

Qui eseguiremo la conversione della valuta da INR a USD.

FromCurrency - INR
ToCurrency - USD

Successivamente, inserisci questi input al posto del punto interrogativo che verrà inviato come richiesta XML. Dopo aver inserito tali valori nei tag XML corrispondenti, fare clic sul pulsante "Invia richiesta" per verificare la risposta.

Risposta

Dopo aver inviato una richiesta, la richiesta del servizio Web viene elaborata dal server Web e restituisce una risposta come mostrato nello screenshot seguente.

Leggendo la risposta, si può concludere che 1 unità di INR = 0,0147 unità di USD.

Richiesta HTTP

I messaggi SOAP vengono trasportati dal protocollo HTTP. Per visualizzare la richiesta HTTP, fare clic su RAW nella finestra Richiesta SoapUI (lato sinistro).

La richiesta viene pubblicata sul server web. Quindi, viene utilizzato il metodo POST di Http.

La richiesta SOAP viene trasportata nel corpo del messaggio http, che viene mostrato come segue.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Risposta HTTP

Fare clic sulla scheda "RAW" nella finestra di risposta dell'interfaccia utente SOAP per capire come viene inviata la risposta tramite HTTP.

Dopo l'elaborazione della richiesta, viene visualizzato il codice di risposta http (200), il che significa che è andata a buon fine. Il server web lo ha elaborato correttamente.

La risposta SOAP viene rinviata al client come parte del corpo del messaggio HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

I seguenti codici HTTP vengono utilizzati per inviare le risposte dal server Web e sono molto utili per il debug.

Codice HTTP	Descrizione
1xx:	Informational - Ciò significa che è stata ricevuta una richiesta e che il processo è in corso.
2xx:	Success - L'azione è stata ricevuta, compresa e accettata con successo.
3xx:	Redirection - Ciò significa che è necessario intraprendere ulteriori azioni per completare la richiesta.
4xx:	Client Error - Ciò significa che la richiesta contiene una sintassi errata o non può essere soddisfatta.
5xx:	Server Error - Il server non è riuscito a soddisfare una richiesta apparentemente valida.

Le proprietà sono un aspetto centrale dei test più avanzati con SoapUI. Le proprietà del test funzionale vengono utilizzate per parametrizzare l'esecuzione e la funzionalità dei test.

Le proprietà possono essere utilizzate per contenere gli endpoint dei servizi, semplificando la modifica degli endpoint effettivi utilizzati durante l'esecuzione del test.
Le proprietà possono essere utilizzate per contenere le credenziali di autenticazione, semplificando la gestione di queste in una posizione centrale o in un file esterno.
Le proprietà possono essere utilizzate per trasferire e condividere gli ID di sessione durante l'esecuzione del test, in modo che più passaggi o casi di test possano condividere le stesse sessioni.

Definizione delle proprietà

Le proprietà possono essere definite a molti livelli in un progetto.

Le proprietà comuni a livello di progetto possono essere definite a livello di progetto.
Allo stesso modo, le proprietà specifiche di TestSuite e TestCase possono essere definite ai rispettivi livelli.
Le proprietà specifiche del progetto sono definite nella scheda Proprietà personalizzate.

Ad esempio, una proprietà "ToCurrency" può essere definita a livello di progetto facendo clic sul simbolo "+" e immettendo il nome e il valore della proprietà.

Accesso alla proprietà

È possibile accedere a una proprietà ovunque nel progetto utilizzando l'espansione della proprietà.

La struttura sarebbe come -

$ {# Project # PropertyName} - Per il livello di progetto
$ {# TestSuite # PropertyName} - Per il livello di Test Suite
$ {# TestCase # PropertyName} - Per il livello di test case
$ {TestStepName # PropertyName} - Per il livello della fase di test
$ {# MockService # PropertyName} - Per la proprietà MockService
$ {# Global # PropertyName} - Per le proprietà globali, si trova in File → Preferenze → scheda Proprietà globali. Questa proprietà può essere utilizzata in tutti i progetti
$ {# System # PropertyName} - Per la proprietà di sistema, disponibile in Guida → Proprietà di sistema
$ {# Env # PropertyName} - Per la variabile d'ambiente

La stessa struttura può essere inserita in Request XML per ottenere il valore di un attributo specifico durante il runtime.

Una proprietà può anche essere considerata come una variabile in un programma per computer. Se l'utente vuole definire qualcosa che può essere utilizzato anche altrove, le Proprietà sono molto utili. Le proprietà possono anche essere definite dinamicamente, ma dipendono dallo script Groovy.

A volte è necessario estrarre un valore da un messaggio di risposta e includerlo nelle richieste successive. In tal caso, è necessario disporre di un meccanismo per recuperare un valore specificato e trasferirlo agli altri elementi del progetto. SoapUI supporta tale funzionalità tramite il Property Transfer TestStep.

Aggiunta di trasferimento di proprietà

Step 1 - Selezionare TestCase o TestStep, fare clic con il pulsante destro del mouse → Aggiungi passaggi → Trasferimento proprietà.

Step 2 - Immettere il nome TestStep e fare clic su OK.

Step 3 - Viene aggiunto il passaggio RateTransfer e si aprirà una nuova procedura guidata.

Step 4- Fare clic sull'icona Aggiungi un nuovo trasferimento di proprietà + nell'angolo in alto a sinistra nella finestra di trasferimento di proprietà. Verrà richiesto di inserire un nome per il trasferimento. Immettere Tasso e fare clic su OK.

Trasferimento di una proprietà

Una volta creato il trasferimento, Source e Target panesè necessario specificare le espressioni XPath pertinenti per estrarre e sostituire i valori delle proprietà. Nella casella a discesa accanto a Origine, sono elencati vari livelli di progetti SoapUI che possono essere utilizzati come origine dei trasferimenti di proprietà. Per impostazione predefinita, verrà visualizzato il TestStep più vicino.

In questo caso, è il file Request – INR to USDTestStep. L'elenco a discesa accanto a Proprietà mostra la proprietà di origine utilizzata nel trasferimento, che può essere richiesta, risposta o endpoint del servizio.

Step 1- Seleziona Risposta e vai a Lingua percorso. L'utente può selezionare XPath, Xquery o Jason per definire la proprietà. In questo caso, seleziona XPath.

Step 2 - Per ottenere la dichiarazione del codice sorgente xml, fare clic su ns e specificare XPath.

Step 3- Specificare la destinazione in cui trasferire il valore estratto dall'espressione XPath precedente. Il riquadro di destinazione viene utilizzato nella parte inferiore della finestra di trasferimento della proprietà per questo.

Step 4 - Trasferimento del valore estratto di ConversionRateResult dalla risposta del passaggio RequestINRtoUSD.

Target - Proprietà

Property - ConversionRate (una nuova proprietà aggiunta, inizialmente non ha alcun valore).

Step 5 - Una volta che il test case viene eseguito correttamente, la proprietà "ConversionRate" viene aggiornata in base alla risposta.

Di seguito è riportato inizialmente lo screenshot.

Di seguito è riportato lo screenshot dopo una corsa riuscita.

Allo stesso modo, Target potrebbe essere un XML di richiesta successivo. Se Target è una richiesta SOAP, è necessario fornire XPath per identificare l'attributo di destinazione.

Il riquadro dei registri memorizza le informazioni complete relative alla transazione tra il client e il server. Gli utenti potranno vedere le varie schede del riquadro del registro. In questo capitolo discuteremo i riquadri di registro più comunemente usati mentre lavoriamo con SoapUI.

SoapUI Log

Il registro SoapUI mostra le informazioni di risposta dal server web. Le stesse informazioni sono memorizzate nel file soapui.log della cartella installata SOAP-UI nella directory "bin".

Registro HTTP

Il registro HTTP mostra tutti i trasferimenti di pacchetti HTTP. Tutte le informazioni in "RAW" vengono visualizzate nel registro HTTP.

Registro errori

Il registro degli errori mostra tutti gli errori riscontrati durante l'intera sessione del progetto. Le stesse informazioni sono disponibili in "soapui-errors.log" presente nella directory "bin" della posizione di installazione di SoapUI.

Registro di memoria

Questa scheda monitora il consumo di memoria e lo visualizza sotto forma di grafico come mostrato nella schermata seguente. È davvero utile quando viene eseguita un'operazione che richiede molta memoria.

L'asserzione può essere interpretata come un punto di controllo o un punto di convalida. Una volta che una richiesta viene inviata a un server web, viene ricevuta una risposta. È necessario convalidare la risposta che contiene i dati come previsto o meno. Per convalidare la risposta, SoapUI ha una funzione di asserzioni.

Punti da notare

Le asserzioni vengono utilizzate per convalidare il messaggio ricevuto da un TestStep durante l'esecuzione.
Confronta la parte del messaggio o l'intero messaggio con un valore atteso.
È possibile aggiungere un numero qualsiasi di asserzioni a TestStep, ciascuna delle quali convalida un aspetto e un contenuto diversi del messaggio di risposta.
Dopo l'esecuzione di un TestStep, tutte le sue asserzioni vengono applicate alla risposta ricevuta e se una di esse fallisce, TestStep viene contrassegnato come non riuscito nella visualizzazione TestCase.
L'inserimento non riuscito viene visualizzato nel registro di esecuzione del test.

Tipo di asserzioni

SoapUI supporta un'ampia gamma di affermazioni in risposta.

Di seguito è riportato l'elenco delle affermazioni supportate da SoapUI.

Asserzione	Descrizione
Property Content
Contiene	Verifica l'esistenza della stringa specificata. Supporta anche l'espressione regolare.
Non contiene	Verifica la non esistenza della stringa specificata. Supporta anche l'espressione regolare.
XPath Match	Utilizza l'espressione XPath per selezionare il nodo di destinazione ei relativi valori. Confronta il risultato di un'espressione XPath con un valore previsto.
XQuery Match	Utilizza un'espressione Xquery per selezionare il contenuto dalla proprietà di destinazione. Confronta il risultato di un'espressione XQuery con un valore previsto.
Compliance, Status, Standards
HTTP DOwnload All Resource	Scarica tutte le risorse indicate come documento HTML (immagini, script, ecc.) E convalida che siano tutte disponibili. Applicabile a qualsiasi proprietà contenente HTML.
Codici di stato HTTP non validi	Verifica che il TestStep di destinazione abbia ricevuto un risultato HTTP con un codice di stato non nell'elenco dei codici definiti. Applicabile a qualsiasi TestStep che riceve messaggi HTTP.
Errore non SOAP	Convalida che l'ultimo messaggio ricevuto non è un errore SOAP. Applicabile a SOAP TestSteps.
Conformità allo schema	Convalida che l'ultimo messaggio ricevuto è conforme alla definizione dello schema WSDL o WADL associata. Applicabile alle fasi del test SOAP e REST. L'URL di definizione dello schema supporta le espansioni delle proprietà (ad esempio $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Errore SOAP	Convalida che l'ultimo messaggio ricevuto è un errore SOAP. Applicabile a SOAP TestSteps SOAP Request: convalida che l'ultima richiesta ricevuta sia una richiesta SOAP valida. Applicabile solo ai passaggi del test MockResponse.
Risposta SOAP	Convalida che l'ultima risposta ricevuta è una risposta SOAP valida. Applicabile solo ai passaggi TestRequest SOAP.
Codici di stato HTTP validi	Verifica che il TestStep di destinazione abbia ricevuto un risultato HTTP con un codice di stato nell'elenco dei codici definiti. Applicabile a qualsiasi TestStep che riceve messaggi HTTP.
Richiesta di indirizzamento WS	Convalida che l'ultima richiesta ricevuta contiene intestazioni WS-Addressing valide. Applicabile solo a MockResponse TestSteps.
Risposta di indirizzamento WS	Convalida che l'ultima risposta ricevuta contenga intestazioni WS-Addressing valide. Applicabile solo ai passaggi TestRequest SOAP.
Stato WS-Security	Convalida che l'ultimo messaggio ricevuto contenga intestazioni WS-Security valide. Applicabile alle fasi del test SOAP.
Script
Asserzione dello script	Consente agli utenti di eseguire uno script personalizzato per eseguire convalide definite dall'utente. Applicabile solo a TestSteps (cioè non alle proprietà)
SLA
Risposta SLA	Convalida se il tempo di risposta dell'ultima risposta ricevuta rientrava nel limite definito. Applicabile a Script TestSteps e TestSteps che inviano richieste e ricevono risposte.
JMS
Stato JMS	Convalida che la richiesta JMS del TestStep di destinazione sia stata eseguita correttamente. Applicabile a Request TestSteps con un endpoint JMS.
Timeout JMS	Convalida che l'istruzione JMS del TestStep di destinazione non ha richiesto più tempo della durata specificata. Applicabile a Request TestSteps con un endpoint JMS.
Security
Esposizione a informazioni sensibili	Verifica se il messaggio di risposta non espone informazioni riservate sul sistema di destinazione. Possiamo usare questa asserzione per REST, SOAP e HTTP TestSteps.
JDBC
Stato JDBC	Convalida che la richiesta JDBC del TestStep di destinazione è stata eseguita correttamente. Applicabile solo a JDBC TestSteps.
Timeout JDBC	Convalida che l'istruzione JDBC della destinazione TestStep non ha richiesto più tempo della durata specificata. Applicabile solo a JDBC TestSteps.

In SoapUI, gli utenti affrontano molti problemi comuni generici che potrebbero essere risolti con un po 'di attenzione. Alcuni di questi problemi più comuni sono i seguenti:

Issue- Lo spazio dei nomi è definito in modo errato. Usa lo spazio dei nomi corretto. Lo spazio dei nomi dovrebbe essere l'URL in cui si trova il servizio Web.

Solution - Se viene generato un errore durante lo sviluppo di un'asserzione di script, utilizzare "log.info" per stampare il contenuto delle variabili.

Issue - Se viene ricevuto un codice di errore come risposta XML, potrebbe essere dovuto a un input non valido.

Solution - Verifica l'input della richiesta XML.

Example - Nel convertitore di valuta, se l'input di "FromCurrency" è "123" che non è esistente, l'output genera un codice di errore come "SOAP-Client", il che significa che il problema riguarda il parametro che viene passato dal dalla parte del cliente.

Richiesta

Risposta

Issue - Nessuna corrispondenza nella risposta corrente quando si utilizza XPath o XQuery.

Solution -

Utilizzare la sintassi corretta durante la definizione di XPath o XQuery.
Verificare che vengano utilizzati i due punti e non il punto durante la dichiarazione dello spazio dei nomi.
Assicurati che XPath e XQuery siano corretti.

Il test delle prestazioni è uno dei punti di controllo importanti più comuni nei test del servizio Web. Il test delle prestazioni è definito come la creazione o la simulazione artificiale del carico e la misurazione del modo in cui l'ambiente lo gestisce.

Ciò significa che non deve necessariamente essere il modo in cui un sistema si comporta sotto carico elevato, ma può anche essere il modo in cui si comporta con carico di base o carico previsto. Non deve nemmeno essere strutturato, automatizzato o creato in TestWare come SoapUI; il semplice aggiornamento del browser web più e più volte molto velocemente è anche un test di carico.

Tipi di test delle prestazioni

Di seguito sono riportati i tipi di test delle prestazioni:

Baseline Testing - Esamina le prestazioni di un sistema sotto il carico previsto o normale e crea una linea di base rispetto alla quale è possibile confrontare gli altri tipi di test.
Load Testing- Include l'aumento del carico e vedere come si comporta il sistema sotto un carico maggiore. Durante i test di carico, l'utente può monitorare i tempi di risposta, la velocità effettiva, le condizioni del server e molto altro. L'obiettivo del test di carico non è quello di rompere l'ambiente di destinazione.
Soak Testing - L'obiettivo del test è assicurarsi che nessun comportamento indesiderato si manifesti per un periodo di tempo più lungo.
Scalability Testing- Il test di scalabilità è molto simile al test di carico, tuttavia invece di aumentare il numero di richieste, aumenta la dimensione o la complessità delle richieste inviate. Ad esempio, l'invio di richieste di grandi dimensioni, allegati di grandi dimensioni o richieste profondamente nidificate.

Aspetti chiave nel servizio Web

Due aspetti risaltano nelle caratteristiche uniche delle prestazioni del Web Service.

Primo aspetto

Sul lato server, è in corso l'elaborazione XML / JSON, sia l'analisi che la serializzazione XML / JSON . La cosa che spesso fallisce per prima è l'elaborazione dei payload. Le ragioni del fallimento possono essere molteplici; può essere nella piattaforma, i punti deboli del server delle applicazioni o può essere un problema di implementazione sotto forma di WSDL inutilmente complessi. Potrebbe anche significare che il codice sta effettuando una richiesta a un database che è lento a rispondere.

Testing Aspect- La complessità dell'analisi del payload XML / JSON significa che è necessario concentrarsi ulteriormente sui test di scalabilità. Significa anche che i WSDL dovrebbero essere esaminati attentamente. Se le richieste e le risposte sono complesse o più grandi, o se includono allegati di grandi dimensioni, concentrarsi sull'enfatizzazione della complessità e vedere come si comporta sotto carico.

Secondo aspetto

Un altro fattore che si incontra frequentemente è la sicurezza. I siti protetti dietro HTTPS hanno prestazioni notevolmente inferiori e nei test del servizio Web possiamo aggiungere un livello di WSSecurity al livello di sicurezza HTTP, diminuendo ulteriormente le prestazioni.

Testing Aspect- La questione della sicurezza significa che è necessario concentrarsi sull'esecuzione di test di richieste sicure. Se l'intero servizio Web è protetto, significa che il test di carico è più importante, soprattutto se si utilizza WS-Security e la gestione dei token.

Load testingè una forma specifica di test delle prestazioni che viene condotta per valutare il comportamento del sistema sotto un carico specifico. In SoapUI, generalmente usiamo il termine "test di carico" per tutti i tipi di test non funzionali, tuttavia SoapUI supporta tutti i tipi di valutazioni delle prestazioni dei servizi web come carico, stress e resistenza.

Punti da notare

Il test di carico è abbastanza unico in SoapUI; un test case funzionale che consente di creare e modificare rapidamente i test delle prestazioni.
Il principale elemento di differenziazione è che i test delle prestazioni in SoapUI generalmente vengono creati dai test funzionali esistenti. Ciò consente di creare rapidamente test prestazionali avanzati.
Le prestazioni del servizio Web possono essere convalidate in diversi scenari di carico. Mantieni le convalide funzionali per vedere che non si rompono sotto carico, esegui diversi test di carico contemporaneamente per vedere come si influenzano a vicenda e molto altro ancora.

Creazione del test di carico

Step 1 - Fare clic con il pulsante destro del mouse su Scenario di test funzionale e selezionare Nuovo test di carico.

Step 2 - Immettere il nome del test di carico e fare clic su OK nella finestra di dialogo guidata.

Load Test si aprirà e il Load Test verrà creato come mostrato nella seguente schermata.

Esecuzione del test di carico

Quando viene creato un nuovo test di carico, è preconfigurato per essere eseguito per 60 secondi (in alto a destra) con 5 thread utilizzando la strategia di caricamento semplice.

Modificare questi valori in base ai requisiti ed eseguire. Note - L'utente deve essere a conoscenza della configurazione e dei concetti del test di carico.

L'utente vedrà la tabella delle statistiche al centro, iniziando con la raccolta dei dati e dopo 60 secondi dovrebbe avere un LoadTest finito.

Aggiunta di un'asserzione

Step 1 - Nell'editor LoadTest, seleziona la scheda Asserzione LoadTest nella parte inferiore dell'editor.

Step 2 - Fare clic sul pulsante Aggiungi asserzione nella barra dei menu LoadTest Assertion per aggiungere un'asserzione.

Step 3- Si aprirà la finestra di dialogo Aggiungi asserzione. Seleziona Step Maximum. Seleziona Massimo imposta un Tempo massimo in millisecondi che le risposte possono prendere, se il tempo supera quello che abbiamo impostato, il test fallirà. Fare clic su OK.

Step 4- Si aprirà la finestra TestStep Max Assertion. Come si vede nello screenshot seguente, consentiamo una risposta massima di un secondo, 1000 millisecondi. Non modifichiamo nulla. Fare clic su OK.

L'asserzione Step Maximum verrà ora aggiunta correttamente.

Step 5- Ora esegui di nuovo il test. Se le risposte richiedono troppo tempo, dovresti vedere i numeri nella colonna degli errori sommarsi rapidamente.

Un servizio Web è una raccolta di protocolli aperti e standard utilizzati per lo scambio di dati tra applicazioni o sistemi. Le applicazioni software scritte in vari linguaggi di programmazione e in esecuzione su varie piattaforme possono utilizzare i servizi Web per scambiare dati su reti di computer come Internet in un modo simile alla comunicazione tra processi su un singolo computer. Questa interoperabilità (ad esempio, tra Java e Python, o applicazioni Windows e Linux) è dovuta all'uso di standard aperti.

I servizi Web basati sull'architettura REST sono noti come servizi Web RESTful. Questi servizi Web utilizzano metodi HTTP per implementare il concetto di architettura REST. Un servizio Web RESTful di solito definisce un URI (Uniform Resource Identifier), che è un servizio che fornisce la rappresentazione delle risorse come JSON e una serie di metodi HTTP.

Tutte le funzionalità di test REST di SoapUI si basano su una rappresentazione logica nota come servizio REST. Non dobbiamo confonderlo con il termine "servizio" qui, poiché non è un'implementazione del servizio ma una mappatura del servizio RESTful che viene richiamato. Possiamo aggiungere quanti più servizi REST possibile in un progetto SoapUI. Ciascuno rappresenta un particolare servizio RESTful. Sono i seguenti:

REST - Configurazione del progetto
RIPOSO - WADL
RIPOSO - Richiesta
RIPOSO - Risposta
REST - Metodi HTTP

SoapUI consente di gestire le operazioni del database utilizzando un TestStep chiamato JDBC Request.

Step 1 - Fare clic con il pulsante destro del mouse su TestStep e selezionare Aggiungi passaggio → Richiesta JDBC.

Step 2 - Immettere il nome del passaggio e fare clic su OK.

Viene aggiunto il passaggio JDBC. Fare doppio clic sul passaggio e si aprirà la procedura guidata JDBC.

Per creare una connessione JDBC, l'utente deve fornire un driver e una stringa di connessione validi. Questi parametri vengono utilizzati per identificare il tipo di database e creare una connessione per utilizzare il database.

Per MySQL, il driver del database può essere com.mysql.jdbc.Driver. Allo stesso modo, per altri database, esiste un driver predefinito che può essere trovato dalla sezione documento del database.

Step 3 - La stringa di connessione deve essere nel seguente formato -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Qui, la proprietà è il nome utente e la password insieme ad altri parametri richiesti per connettersi a un database.

Per esempio,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Fare clic su Verifica connessione. In caso di connessione riuscita, verrà visualizzato SUCCESS altrimenti fornirà i dettagli dell'errore.

JDBC ha la propria sezione Aggiungi proprietà che può essere utilizzata come variabile in SQL Query.

Vediamo come si comporta -

Si supponga che la query SQL che deve essere eseguita nel passaggio JDBC sia Seleziona * da Valuta dove CurrencyCode = 'xxx'.

In questo scenario, CurrencyCode può essere modificato in base all'input della richiesta. Se l'utente fornisce un valore hardcoded, il passaggio JDBC non verrà eseguito per la valuta fornita nella richiesta.

Per superare tali scenari, JDBC supporta la proprietà add, in cui è possibile definire un codice di proprietà che continuerà a cambiare utilizzando il passaggio di trasferimento proprietà.

SQL Query verrà eseguito in base al valore corrente di Property Code e SQL Query parametrizzerà CurrencyCode =: Code.

Fare clic su Aggiungi proprietà + e il nome come codice e fornire il valore o lasciare vuoto per utilizzare il passaggio Trasferimento proprietà per fornirlo.

La richiesta JDBC può anche utilizzare la maggior parte delle asserzioni con la richiesta SOAP TestSteps. In SoapUI, la maggior parte di queste affermazioni sono indipendenti da TestSteps. Pertanto, le asserzioni come Contains e XPath Match possono essere utilizzate con JDBC Request TestStep.

Facendo clic su Add an assertion icona nel menu in alto di JDBC Request TestStep, l'utente può scoprire quali asserzioni sono supportate da TestStep.

Oltre alle asserzioni generiche, ci sono due asserzioni specifiche JDBC Request TestStep:

JDBC Timeout - Questa asserzione può essere utilizzata per verificare se la query SQL corrente viene eseguita entro il valore della proprietà Query Timeout specificato.

JDBC Status - Per verificare se l'istruzione SQL viene eseguita correttamente, è possibile utilizzare l'asserzione di stato JDBC.

Per impostare il Timeout query, fornire il valore relativo a Timeout query proprietà sul lato sinistro dello schermo. Tieni presente che accetta valori in millisecondi (ms).