Cos'è il test SOA? Tutorial con esempio

Cos'è il test SOA?

SOA (Orientato ai servizi Architest della struttura) Si tratta della verifica dello stile architetturale SOA, in cui i componenti dell'applicazione sono progettati per comunicare tramite protocolli di comunicazione, tipicamente su una rete.

Cos'è la SOA?

La SOA è un metodo per integrare insieme applicazioni e processi aziendali in modo da soddisfare le esigenze aziendali.

In Software EngineeringL'architettura SOA offre agilità e flessibilità ai processi aziendali. Una modifica a un processo o a un'applicazione può essere indirizzata a un componente specifico senza influenzare l'intero sistema.

Gli sviluppatori di software che lavorano in SOA sviluppano o acquistano blocchi di programmi chiamati servizi.

Che cos'è il servizio?

Il diagramma seguente mostra un gateway di pagamento pubblicato come servizio a cui possono accedere diversi siti di e-commerce.

• Un servizio può essere un'unità funzionale di un'applicazione o di un processo aziendale, riutilizzabile o ripetibile da qualsiasi altra applicazione o processo. (Ad esempio, nell'immagine sopra, il gateway di pagamento è un servizio riutilizzabile da qualsiasi sito di e-commerce. Ogni volta che è necessario effettuare un pagamento, il sito di e-commerce richiama o richiede il servizio del gateway di pagamento. Una volta completato il pagamento tramite il gateway, viene inviata una risposta al sito di e-commerce.)
• I servizi sono facili da assemblare e i componenti sono facili da riconfigurare.
• I servizi possono essere paragonati a dei mattoncini. Permettono di costruire qualsiasi applicazione necessaria, ed è facile aggiungerli o rimuoverli dall'applicazione o dal processo aziendale.
• I servizi sono definiti più dalla funzione aziendale che svolgono che da semplici porzioni di codice.

Servizi web

La maggior parte dei servizi SOA sono esposti come servizi web, quindi vale la pena definire i meccanismi di una chiamata a un servizio web prima di procedere con i livelli di test.

Servizi Web sono componenti applicativi indipendenti disponibili via web.

Possono essere pubblicati, trovati e utilizzati sul web e comunicano tramite Internet. La sequenza seguente mostra come interagiscono un fornitore, un registro e un consumatore.

• Il fornitore di servizi pubblica il servizio su Internet.
• Il cliente cerca uno specifico servizio web nel Registro dei servizi web.
• A URL e wsdl per il servizio web richiesto vengono restituiti. Utilizzando il WSDL e il URLLa comunicazione tra il fornitore del servizio e il richiedente avviene tramite messaggi SOAP.
• Quando un utente accede a un servizio web, viene stabilita una connessione HTTP con il fornitore.
• Viene creato un messaggio SOAP per istruire il provider ad avviare la logica del servizio web richiesta.
• La risposta ricevuta dal fornitore è un messaggio SOAP incorporato nella risposta HTTP. Questa risposta HTTP rappresenta il formato dati comprensibile dall'applicazione client.

Esempio

Lo screenshot qui sotto mostra un bollettino meteorologico fornito da un servizio esterno e incorporato nella home page di un motore di ricerca.

La home page di un sito web e un motore di ricerca mostrano le previsioni del tempo giornaliere. Invece di codificare da zero la sezione dedicata alle previsioni del tempo, è possibile acquistare un servizio di previsioni meteo da un fornitore e integrarlo nelle pagine.

Livelli di test SOA

L'architettura SOA è composta da diverse tecnologie e le applicazioni create utilizzando SOA dispongono di vari servizi a basso accoppiamento. Il diagramma seguente illustra i tre livelli che un piano di test deve coprire.

I test SOA dovrebbero concentrarsi su 3 livelli del sistema.

Livello servizi

Questo livello è costituito dai servizi esposti da un sistema, derivati ​​dalle funzioni aziendali.

Ad esempio, si consideri un sito web dedicato al benessere che comprende:

• Peso Tracker
• Glicemia Tracker
• Miglioramento della pressione sanguigna Tracker

TracI ker visualizzano i dati corrispondenti e la data in cui sono stati inseriti. Il livello dei servizi è costituito dai servizi che recuperano i dati corrispondenti dal database:

• Peso Tracservizio ker
• Glicemia Tracservizio ker
• Miglioramento della pressione sanguigna Tracservizio ker
• Servizio di accesso

Livello di processo

Il livello dei processi è costituito dai processi, ovvero dall'insieme dei servizi che fanno parte di una singola funzionalità.

I processi potrebbero far parte di un'interfaccia utente (ad esempio, un motore di ricerca) o di uno strumento ETL che estrae dati dal database.

L'attenzione principale in questo livello è rivolta alle interfacce utente e ai processi. L'interfaccia utente del peso tracL'attenzione principale è rivolta a ker e alla sua integrazione con il database.

Vengono prese in considerazione le seguenti funzioni:

• Aggiunta di nuovi dati
• Modifica dei dati esistenti
• Creare un nuovo file tracker
• Eliminazione dei dati

Livello del consumatore

Questo livello è composto principalmente da interfacce utente, come illustrato nella schermata seguente.

In base a questi livelli, il testing di un'applicazione SOA è suddiviso in tre fasi:

• Livello di servizio
• Livello di interfaccia
• Livello dall'inizio alla fine

Le due direzioni di marcia differiscono: per la progettazione dei test si utilizza un approccio dall'alto verso il basso, mentre per l'esecuzione dei test si utilizza un approccio dal basso verso l'alto.

Strategia per il test SOA

Approccio alla pianificazione dei test

• I tester SOA devono comprendere l'intera architettura dell'applicazione.
• L'applicazione deve essere suddivisa in servizi indipendenti (un servizio che ha una propria struttura di richiesta e risposta e non dipende da nessun altro servizio per generare una risposta).
• La struttura dell'applicazione deve essere riorganizzata in tre componenti: dati, servizi e applicazioni front-end.
• È necessario analizzare attentamente tutti i componenti e delineare diversi scenari aziendali.
• Gli scenari aziendali dovrebbero essere classificati in scenari comuni e scenari specifici per l'applicazione.
• A TracMatrice di capacità dovrebbero essere preparati e tutti i casi di test dovrebbero essere tracadattato a scenari aziendali.

Approccio all'esecuzione del test

• Ogni componente del servizio dovrebbe essere testato.
• Test d'integrazione dei componenti del servizio dovrebbe essere fatto per convalidare il flusso di dati attraverso i servizi e l'integrità dei dati.
• Test di sistema È necessario eseguire un test completo del modello per convalidare il flusso di dati tra l'applicazione front-end e il database.
• Test di Performance dovrebbe essere fatto per una messa a punto fine e prestazioni ottimali.

Metodi di test SOA

1) Test basati su dati e guidati da scenari aziendali

• Occorre analizzare diversi aspetti commerciali relativi al sistema.
• Gli scenari dovrebbero essere sviluppati sulla base dell'integrazione dei vari servizi web dell'applicazione e dei servizi web con l'applicazione.
• La configurazione dei dati deve essere effettuata in base agli scenari sopra descritti.
• La configurazione dei dati dovrebbe inoltre coprire scenari end-to-end.

2) Stub

• Le interfacce fittizie vengono create per testare i servizi.
• Attraverso queste interfacce possono essere forniti vari input e gli output possono essere convalidati.
• Quando un'applicazione utilizza un'interfaccia verso un servizio esterno non sottoposto a test (un servizio di terze parti), è possibile creare uno stub durante i test di integrazione.

3) Test di regressione

• Test di regressione L'applicazione dovrebbe essere aggiornata quando sono presenti più versioni, in modo da garantire la stabilità e la disponibilità dei sistemi.
• Verrà creata una suite completa di test di regressione che coprirà i servizi che costituiscono una parte importante dell'applicazione.
• Questa suite di test può essere riutilizzata in diverse versioni del progetto.

4) Test del livello di servizio

Il test a livello di servizio include la verifica della funzionalità, della sicurezza, delle prestazioni e dell'interoperabilità del componente. Ogni singolo servizio deve essere testato individualmente in anticipo.

5) Test Funzionali

Test di funzionalità dovrebbe essere fatto su ogni servizio per:

• Assicurarsi che il servizio fornisca la risposta corretta a ogni richiesta.
• Assicurarsi che vengano ricevuti gli errori corretti per le richieste con dati non validi o errati.
• Verifica ogni richiesta e risposta per ogni operazione che il servizio deve eseguire in fase di runtime.
• Convalidare i messaggi di errore quando si verifica un problema a livello di server, client o rete.
• Verifica che le risposte ricevute siano nel formato corretto.
• Verificare che i dati ricevuti nella risposta corrispondano ai dati richiesti.

6) Test di sicurezza

Il test di sicurezza del servizio web è un aspetto importante durante il test a livello di servizio dell'applicazione SOA, poiché garantisce la sicurezza dell'applicazione stessa.

Durante il test devono essere presi in considerazione i seguenti fattori:

• Il servizio web deve attenersi allo standard di settore definito da WS-Security.
• Le misure di sicurezza dovrebbero funzionare perfettamente.
• Crittografia dei dati e firme digitali sui documenti.
• Autenticazione e autorizzazione.
• SQL injection, malware, XSS, CSRF e altre vulnerabilità devono essere testate su XML.
• Attacchi Denial of Service.

7) Test delle prestazioni

È necessario eseguire test di performance sul servizio perché i servizi sono riutilizzabili e più applicazioni potrebbero utilizzare lo stesso servizio.

Durante il test vengono presi in considerazione i seguenti fattori:

• Le prestazioni e la funzionalità del servizio devono essere testate in condizioni di carico pesante.
• Le prestazioni del servizio devono essere confrontate sia quando funziona singolarmente, sia quando è integrato all'interno dell'applicazione.
• Test di carico È necessario eseguire dei test sul servizio per verificare i tempi di risposta, individuare eventuali colli di bottiglia, controllare l'utilizzo di CPU e memoria e prevedere la scalabilità.

8) Test del livello di integrazione

• Il test dei livelli di servizio garantisce il corretto funzionamento dei singoli servizi; non garantisce il funzionamento dei componenti interconnessi.
• Il test di integrazione viene eseguito concentrandosi principalmente su interfacce.
• Questa fase copre tutti i possibili scenari aziendali.
• In questa fase è necessario eseguire nuovamente i test non funzionali dell'applicazione. I test di sicurezza, conformità e prestazioni garantiscono la disponibilità e la stabilità del sistema sotto tutti gli aspetti.
• I protocolli di comunicazione e di rete dovrebbero essere testati per convalidare la coerenza della comunicazione dei dati tra i servizi.

9) Test end-to-end

Questa fase garantisce che l'applicazione sia conforme ai requisiti aziendali sia dal punto di vista funzionale che non funzionale.

Gli elementi seguenti sono garantiti essere testati durante test end-to-end:

• Tutti i servizi funzionano come previsto dopo l'integrazione
• La gestione delle eccezioni
• Interfaccia utente dell'applicazione
• Il corretto flusso dei dati attraversa tutti i componenti
• Processo di business

Sfide nei test SOA

Applicare questi metodi è raramente semplice e le difficoltà descritte di seguito si ripresentano in quasi tutti i programmi SOA.

• Mancanza di interfacce per i servizi.
• Il processo di test coinvolge più sistemi, il che crea esigenze di dati complesse.
• L'applicazione è un insieme di vari componenti che tendono a cambiare, quindi la necessità di test di regressione è più frequente.
• A causa della struttura multistrato, è difficile isolare i difetti.
• Poiché un servizio viene utilizzato da diverse interfacce, il carico è difficile da prevedere, il che rende complessa la pianificazione dei test di performance.
• SOA è un insieme di tecnologie eterogenee. Il test di un'applicazione SOA richiede persone con competenze diverse, il che a sua volta aumenta i costi di pianificazione ed esecuzione.
• Poiché l'applicazione integra molteplici servizi, i test di sicurezza presentano non poche difficoltà. La convalida dell'autenticazione e dell'autorizzazione è complessa.

Strumenti di test SOA

Sul mercato sono disponibili numerosi strumenti di test SOA per aiutare i tester a testare le applicazioni SOA. Ecco alcuni degli strumenti di test SOA più diffusi.

1) SoapUI

SoapUI è uno strumento di test funzionale open-source per servizi e Test dell'API.

• Applicazione desktop
• Supporta molteplici protocolli: SOAP, REST, HTTP, JMS, AMF, JDBC
• I servizi web possono essere sviluppati, ispezionati e richiamati.
• Può essere utilizzato anche per i test di carico, Test di automazionee test di sicurezza
• Gli stub possono essere creati da MockServices
• Le richieste e i test relativi ai servizi web possono essere generati automaticamente tramite il relativo client.
• Dispone di strumenti di reporting integrati
• Sviluppato da SmartBear, che spedisce entrambi i open-source SoapUI distribuzione e commerciale ReadyAPI edizione

2) Virtualizzazione dei servizi Broadcom (precedentemente iTKO LISA)

LISA è una suite di prodotti che offre una soluzione di test funzionale per sistemi distribuiti come SOA. Il prodotto è passato da iTKO a CA Technologies ed è oggi venduto con il nome di Broadcom Service Virtualization.

• Può essere utilizzato anche per test di regressione, integrazione, carico e prestazioni.
• Può essere utilizzato per progettare ed eseguire test.

3) UFT Uno (precedentemente HP Service Test)

Service Test è uno strumento di test funzionale che supporta sia il test dell'interfaccia utente che quello dei servizi condivisi. La sua capacità di test delle API è stata integrata in Unified Functional Testing, ora venduto da OpenText as UFT Uno.

• Sia i test funzionali che quelli prestazionali dei servizi possono essere eseguiti tramite un singolo script.
• Integrato con Quality Center, ora venduto come OpenText ALM / Centro Qualità.
• È possibile gestire un'enorme quantità di servizi e dati.
• Supporta test di interoperabilità simulando ambienti client JEE, AXIS e DotNet.

4) Parasoft SOAtest

Parasoft SOAtest è una suite di strumenti di test e analisi sviluppata per il collaudo di API e applicazioni basate su API.

• Supporta servizi web, REST, JSON, MQ, JMS, TIBCO, HTTP e tecnologie XML.
• Sono possibili test funzionali, unitari, di integrazione, di regressione, di sicurezza, di interoperabilità, di conformità e di performance.
• È possibile creare stub utilizzando Parasoft Virtualize, che sono più capaci di SoapUI Servizi simulati.

Casi d'uso del test SOA

L'esempio pratico riportato di seguito applica la strategia, i metodi e gli strumenti sopra descritti a un singolo sito di e-commerce, fase per fase.

Consideriamo un sito web di e-commerce che includa le funzioni e le sotto-funzioni elencate di seguito.

Elaborazione dell'ordine

Il grafico sottostante suddivide l'elaborazione degli ordini nelle sotto-funzioni che diventano servizi.

FASE 1

Nella prima fase del testing SOA, la fase di strategia di test, l'applicazione viene suddivisa in servizi e funzioni aziendali.

Analizziamo i servizi elencati di seguito nell'applicazione.

• Crea ordine
• Controlla lo stato del cliente
• Modifica lo stato dell'ordine
• Verifica dello stato dell'ordine
• Controlla inventario

Le funzioni aziendali sono le stesse delle funzioni del sito web.

Nota: il documento relativo alla strategia di test conterrà l'elenco dei servizi e delle funzioni che devono essere testati.

FASE 2

Questa è la fase di pianificazione dei test. Casi test sono scritti per ogni livello.

Livello end-to-end. I casi di test vengono scritti per ogni caso d'uso e flusso aziendale. Di seguito sono riportati alcuni esempi di casi di test.

• Crea un ordine con un utente attivo.
• Crea un ordine con un utente inattivo.
• Crea un ordine con un prodotto disponibile con quantità ordinata < quantità disponibile.
• Crea un ordine con un prodotto disponibile con quantità ordinata > quantità disponibile.
• Crea un ordine con più articoli.
• Annulla completamente un ordine.
• Annullare parzialmente un ordine.

Livello di integrazione. I casi di test vengono scritti per l'integrazione tra database e interfaccia utente. Di seguito sono riportati alcuni esempi di casi di test.

• Crea un nuovo ordine con un singolo articolo. Verificare che l'ordine sia stato creato nel database.
• Crea un nuovo ordine con un singolo articolo. Verificare che il prezzo calcolato per l'ordine sia corretto.
• Crea un nuovo ordine con un singolo articolo. Verifica che la quantità del prodotto disponibile sia ridotta dell'importo dell'ordine.
• Verificare che lo stato dell'ordine visualizzato nell'interfaccia utente corrisponda a quello presente nel database.
• Annulla l'ordine e verifica che lo stato dell'ordine sia modificato sul database.
• Per il primo pagamento, verificare che i dati di pagamento inseriti nell'interfaccia utente siano stati salvati nel database.
• Per restituire i pagamenti, verificare che i dettagli del pagamento presenti nel database siano visualizzati nell'interfaccia utente.

Livello di servizio. Ogni servizio viene testato per tutte le condizioni dei dati. Di seguito alcuni esempi.

No.	Dettaglio ordine	Condizioni dell'ordine
1	Crea ordine. N. di articoli = 1	Quantità in ordine < Quantità nel database
2	Crea ordine. N. di articoli > 1	Quantità ordinata < Quantità presente nel database
3	Crea ordine. N. di articoli = 1	Quantità nell'ordine > Quantità nel database
4	Controlla lo stato dell'ordine	Stato sul database = Attivo
5	Controlla lo stato dell'ordine	Stato sul database = Spedito
6	Controlla lo stato dell'ordine	Stato sul database = Annullato
7	Controlla lo stato dell'ordine	ID ordine = non valido
8	Verifica la disponibilità del prodotto	Quantità di prodotto >0
9	Verifica la disponibilità del prodotto	Quantità di prodotto = 0
10	Verifica la disponibilità del prodotto	ID prodotto = non valido

FASE 3 — Esecuzione del test

L'esecuzione dei test utilizza un approccio dal basso verso l'alto: si procede prima con i test a livello di servizio, poi con quelli a livello di integrazione e infine con i test end-to-end.

1) Livello di servizio

Consideriamo che il SoapUI Lo strumento viene utilizzato per testare l'applicazione. Il WSDL e URL vengono sfogliati nella finestra di prova di SoapUIe la richiesta per ciascun servizio viene visualizzata nella finestra delle richieste. Modificando i dati in base ai casi di test a livello di servizio, vengono create le richieste per ciascun caso di test.

Test Case	RICHIEDI	Risposta prevista
Crea ordine. Numero di articoli = 1, Quantità nell'ordine < Quantità nel database	x2 2	o3251 Riuscito
Crea ordine. Numero di articoli > 1, Quantità nell'ordine < Quantità nel database	y1 1 y2 3	o3251 Riuscito
Crea ordine. Numero di articoli = 1, Quantità nell'ordine > Quantità nel database	x23 200	nullo Senza esito
Verifica lo stato dell'ordine. Stato nel database = Attivo	o9876	Attivo Riuscito
Verifica lo stato dell'ordine. Stato nel database = Spedito	o9656	Spedito Riuscito
Verifica lo stato dell'ordine. ID ordine = Non valido	y5686	nulla Non riuscito
Verifica la disponibilità del prodotto. Quantità del prodotto >0	d34	34 SÌ Riuscito
Verifica la disponibilità del prodotto. Quantità del prodotto = 0	y34	0 NO Riuscito
Verifica la disponibilità del prodotto. ID prodotto = non valido	sder	Senza esito

2) Livello di integrazione

I casi di test a livello di integrazione vengono eseguiti sull'interfaccia utente e sul database. Crea un ordine con un singolo articolo:

• Un utente apre il sito Web.
• L'utente procede a effettuare un ordine.
• L'utente seleziona un prodotto e una quantità validi e salva l'ordine.
• Dovrebbe essere visualizzato un messaggio che conferma l'avvenuta conferma dell'ordine.
• L'utente apre il database e verifica che i dettagli dell'ordine corrispondano a quelli inseriti sul sito web.

3) Livello dall'inizio alla fine

I flussi aziendali e i casi d'uso vengono eseguiti sull'interfaccia utente. Crea un ordine con più articoli:

• Un utente apre il sito Web.
• L'utente procede a effettuare un ordine.
• L'utente richiede informazioni su un prodotto e una quantità validi e li aggiunge al carrello.
• Vengono aggiunti altri prodotti validi con le quantità corrette e l'ordine viene salvato. Il pagamento viene effettuato tramite un nuovo metodo di pagamento e l'ordine viene inoltrato.
• Dovrebbe essere visualizzato il messaggio "Ordine effettuato con successo".
• Un tester dovrebbe verificare che l'intero flusso si completi senza alterazioni dei dati.

DOMANDE FREQUENTI