Test black-box di API basato su partizionamento - Ingegneria Informatica
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Tesi di Laurea Triennale in Ingegneria Informatica Test black-box di API basato su partizionamento Anno Accademico 2018/2019 Relatore Ch.mo Prof Roberto Pietrantuono Candidato Mario Pisacane N46003598
Alla mia famiglia, a Martina e a tutti i miei amici e colleghi.
Indice
Indice..................................................................................................................................................III
Capitolo 1: Test Black Box e API........................................................................................................4
1.1 Test Black Box...........................................................................................................................4
1.2 Classi d’equivalenza...................................................................................................................5
1.3 API – Application Programming Interface.................................................................................6
Capitolo 2: Category Partition e Robustezza........................................................................................8
2.1.1 Identificazione delle caratteristiche dei parametri verificabili separatamente....................9
2.1.2 Identificazione dei valori rappresentativi..........................................................................11
2.1.3 Generazione delle specifiche del caso di prova.................................................................11
2.2 Analisi di Robustezza...............................................................................................................12
Capitolo 3 : Tools per l’ API-Testing.................................................................................................14
3.1 Postman....................................................................................................................................14
3.1.1 Request.............................................................................................................................14
3.1.2 Collections.........................................................................................................................16
3.1.3 Variables............................................................................................................................17
3.1.4 Riposta HTTP....................................................................................................................18
3.2 Altri tools..................................................................................................................................19
3.2.1 SoapUI...............................................................................................................................19
3.2.2 Katalon Studio...................................................................................................................19
3.2.3 Apigee................................................................................................................................20
3.2.4 Jmeter................................................................................................................................20
3.2.5 Assertible...........................................................................................................................20
3.2.6 Fiddler................................................................................................................................21
Capitolo 4 : Un approccio di category-partition per il test di API.....................................................22
4.1 : Collection...............................................................................................................................22
4.2 : Category Partition...................................................................................................................24
4.3 : Request...................................................................................................................................25
4.3.1 List users............................................................................................................................25
4.3.2 Single user.........................................................................................................................26
4.3.3 Create.................................................................................................................................26
4.3.4 Update................................................................................................................................29
4.3.5 Register e Login................................................................................................................31
4.3.6 Delete.................................................................................................................................33
4.4: Vincoli.....................................................................................................................................34
Conclusioni.........................................................................................................................................35
Bibliografia.........................................................................................................................................37Test black-box di API basato su partizionamento
Capitolo 1: Test Black Box e API
1.1 Test Black Box
Il test funzionale è una tipologia di verifica che tenta di rispondere alla domanda "Quali
casi di test devo usare per provare un programma?", considerando solo le specifiche di un
programma e non la sua struttura di progettazione o implementazione. Essendo basato
sulle specifiche e non direttamente sul codice, il test funzionale è anche chiamato test
basato sulle specifiche o test Black-Box.
Il test Black-Box è una tipologia di verifica complanare a quella White-Box, non ne è
un'alternativa ma un completamento. Mentre i test White-Box si occupano di effettuare
operazioni di verifica sul codice sorgente, mediante meccanismi basati sul concetto di
copertura, ovvero la percentuale dei casi testati (ad esempio il numero di stringhe di codice
testate in rapporto con il loro numero totale), il Black-Box è composto da tecniche che
prescindono dalla struttura del programma, e, quasi sempre, si opera su software di cui non
si conosce il codice sorgente, lo stato o il funzionamento interno. Sono tecniche che
valutano il compito di un programma: si esercita il sistema immettendo input e valutando
gli output.
Per effettuare un buon test Black-Box si devono avere: delle specifiche da soddisfare, la
conoscenza dell'interfaccia del sistema e la documentazione, in particolare, i documenti
relativi alla fase d'analisi. Perché? I casi di test vengono derivati direttamente dalle
specifiche, ovvero dall'obiettivo e/o dal compito che il programma deve portare a termine.
In caso si fosse in possesso di una specifica scritta in un linguaggio formale esistono dei
programmi per estrarre casi di test automaticamente e, anche, di derivare automaticamente
risultati, che prendono il nome di oracoli. Un oracolo è un meccanismo usato nel collaudo
del software e, più in generale, nell'ingegneria del software per determinare se un test ha
avuto successo o è fallito. Viene utilizzato confrontando l'output di un sistema sotto
analisi, dato in ingresso uno specifico caso di test, con il risultato che il prodotto dovrebbe
4Test black-box di API basato su partizionamento
fornire (determinato dall'oracolo).
Gli obiettivi principali di questa tipologia di testing possono essere: la copertura degli
scenari di esecuzione definiti dai casi d'uso e la copertura delle funzionalità previste. Per
fare ciò occorre dividere i possibili input in gruppi i cui elementi si ritiene che saranno
trattati similarmente dal processo elaborativo. Questi gruppi sono chiamati classi
d'equivalenza.
La definizione dei casi di test e dell’oracolo è fondata sulla base della sola conoscenza dei
requisiti specificati del sistema e dei suoi componenti. Per definire l'insieme dei casi di test
per ogni funzionalità, bisogna effettuare un numero di esecuzioni dedotte dai dati di
ingresso e di uscita e dalle precondizioni e postcondizioni. Una volta definito il dominio
dei dati di I/O non resta che scegliere i tests-case selezionando:
1 valori all’interno dell’intervallo;
2 valori all’esterno dell’intervallo;
3 valori “critici”.
1.2 Classi d’equivalenza
Il metodo si occupa di esaminare i campi di variabilità degli input, ovvero il loro dominio.
Questo dominio è normalmente troppo grande per un testing esaustivo dei valori, per
esempio una funzione che ha in input due short richiederebbe 256x256 (= 65.000) casi di
test.
L’idea delle classi di equivalenza è di partizionare il dominio di input in un numero finito
di sottoinsiemi in cui “ragionevolmente” il codice si comporta in maniera uniforme.
Se l’unità computa correttamente per un caso di test, si può dedurre ragionevolmente che è
corretto per ogni caso di test in quella classe.
Ogni sottoinsieme è una classe di equivalenza, e serve come base per almeno un input ad
5Test black-box di API basato su partizionamento
un test.
La tecnica del partizionamento in classi di equivalenza consiste nel testare almeno un caso
nel campo dei valori all’interno del dominio, un campo dei valori esterni al dominio e,
soprattutto, nel campo dei valori “critici”, quali possono essere i valori ai margini del
dominio, per ogni classe d'equivalenza. Da una singola problematica è possibile estrarre
molte classi di equivalenza da testare, partendo dalle specifiche.
Una possibile suddivisione è quella in cui la classe d'equivalenza rappresenta un insieme
di stati validi o non validi per una configurazione sulle variabili d'ingresso:
1 Se la variabile di input è un intervallo di valori: almeno una classe valida per valori interni
all’intervallo, una non valida per valori inferiori al minimo, e una non valida per valori
superiori al massimo.
2 Se la variabile di input è un elemento di un insieme discreto: una classe valida per ogni
elemento dell’insieme, una non valida per un elemento non appartenente.
3 Se la variabile di input è un valore specifico: una classe valida per il valore specificato, una non
valida per valori inferiori e una non valida per valori superiori.
4 Se la variabile di input è un valore booleano: una classe valida per il valore TRUE e una non
valida per il valore FALSE.
1.3 API – Application Programming Interface
In informatica con il termine con l'acronimo API si indica application programming
interface, un insieme di procedure (in genere raggruppate per strumenti specifici) atte
all'esplemento di un dato compito. Spesso al concetto di API viene associato il concetto di
libreria software di un linguaggio di programmazione.
6Test black-box di API basato su partizionamento
Le API sono un insieme definito di regole, che contengono metodi di comunicazione
definiti. Un' API aiuta diversi componenti software a interagire tra loro.
Le interfacce consistono in una serie di funzioni, procedure, variabili e strutture dati. Una
buona API fornisce una "scatola nera", basata su un pensiero Object-Oriented, per
garantire l'Information Hiding, cioè un livello di astrazione che evita al programmatore di
sapere come funzionato le API ad un livello inferiore. Questo permette di riprogettare o
migliorare le funzioni all'interno dell'API senza cambiare il codice che si affida ad esse.
L’API-Testing prevede la raccolta di API in un insieme e la conseguente verifica della
conformità alle aspettative di funzionalità, affidabilità, prestazioni, sicurezza e di corretta
risposta.
Il test delle API viene utilizzato per determinare se l'output è ben strutturato e utile a
un'altra applicazione oppure no, controlla la risposta in base al parametro di input
(richiesta) e il tempo impiegato.
Il formato più utilizzato in questo contesto è il JSON, acronimo di JavaScript Object
Notation, un formato adatto all'interscambio di dati fra applicazioni client/server.
È basato sul linguaggio JavaScript, ma ne è indipendente. Viene usato come alternativa a
XML.La maggior parte dei linguaggi di programmazione possiede un typesystem molto
simile a quello definito da JSON per cui sono nati molti progetti che permettono l'utilizzo
di JSON con altri linguaggi. Fra i primi utilizzatori di JSON si trova Yahoo!, dal 2005.
7Test black-box di API basato su partizionamento
Capitolo 2: Category Partition e Robustezza
2.1 Category Partition Test
Il Category Partition Test, come abbiamo detto, è un metodo per generare test funzionali
da specifiche informali. Le seguenti fasi compongono il nucleo della metodologia:
1. Decomposizione delle specifiche in funzionalità testabili in modo indipendente:
I progettisti dei test identificano le caratteristiche da testare separatamente, i
parametri e tutti gli altri elementi dell'ambiente (environment) di esecuzione da cui
l'unità dipende. Le dipendenze ambientali sono trattate in modo identico ai
parametrii. Per ciascun parametro e/o elemento di ambiente, i progettisti
identificano le caratteristiche elementari, che nel category partition vengono,
solitamente, definite categorie (o classi d’equivalenza).
2. Identificazione dei valori rappresentativi: I progettisti dei test selezionano una
serie di classi rappresentative di valori per ciascuna caratteristica del parametro. I
valori (test-case) vengono selezionati separatamente, indipendentemente dalle altre
caratteristiche dei parametri. Nel metodo partizione di categoria, le classi di valori
sono chiamate scelte (test-frame) e questa attività è chiamata “partizionare le
categorie in scelte”.
3. Generazione delle specifiche del caso di test: I progettisti del test impongono
vincoli semantici sui valori per indicare combinazioni non valide e limitare le
combinazioni valide (ad esempio, limitando combinazioni che coinvolgono valori
eccezionali e non validi). Normalmente la scelta dei valori viene effettuata dopo la
scelta dei vincoli.
Categorie, scelte e vincoli possono essere forniti a uno strumento per generare
8Test black-box di API basato su partizionamento
automaticamente una serie di specifiche. Automatizzare attività banali e ripetitive, come
queste, fa si che ci sia un uso migliore delle risorse umane e riduce gli errori dovuti alla
distrazione.
È possibile determinare il numero di casi di test che verranno generati (mediante calcoli o
generandoli effettivamente) prima di investire lo sforzo umano nell'esecuzione del test. Se
il numero di casi di test derivabili supera il budget per l'esecuzione e la valutazione del
test, i progettisti di test possono ridurre il numero di casi di test imponendo ulteriori
vincoli semantici. Il controllo del numero di casi di test prima dell'inizio dell'esecuzione è
preferibile ad approcci ad hoc in cui si possono inizialmente creare suite di test molto
approfondite e quindi testare sempre meno, a mano a mano che le scadenze si avvicinano.
2.1.1 Identificazione delle caratteristiche dei parametri verificabili separatamente
Si assume che questa prima fase inizi selezionando una funzione da testare
indipendentemente dalle altre.
Questa fase richiede al progettista di test di identificare le caratteristiche dei parametri,
cioè le caratteristiche elementari dei parametri e degli elementi ambientali che influenzano
l'esecuzione dell'unità. Un singolo parametro può avere più caratteristiche elementari.
Una lettura più attenta delle specifiche rivela ciò che è "valido", mentre una prima lettura
può offrirci uno sguardo sui possibili elementi in gioco.
Dopo aver identificato i parametri e gli elementi dell'ambiente, per testare la funzionalità,
il progettista del test deve identificare le caratteristiche dei parametri.
Non ci sono regole rigide per scegliere le categorie, e non è un compito banale. Le
categorie riflettono il giudizio del progettista riguardo le classi di valori che possono
essere trattate in modo diverso, oltre alle classi di valori che sono esplicitamente
identificate nella specifica. I progettisti di test devono inoltre utilizzare la propria
9Test black-box di API basato su partizionamento
esperienza e conoscenza, del dominio dell'applicazione e dell'architettura del prodotto, per
esaminare le specifiche e identificare le possibili caratteristiche nascoste.
Il category partition test non prevede una disposizione precisa per i dati strutturati, come
per esempio set di coppie . Un approccio tipico è quello di
"appiattire" le categorie: descrivere le caratteristiche dell'intera categoria come
caratteristiche di parametri.
In genere la dimensione del parametro (la lunghezza di una stringa, ad esempio) è una
caratteristica, mentre, le descrizioni delle possibili combinazioni di elementi (occorrenza
di caratteri speciali in una stringa, ad esempio), sono altre caratteristiche del parametro,
indipendenti dalle precedenti.
Supponiamo che l'unica variazione significativa tra le coppie
sia tra coppie compatibili e coppie incompatibili. Se considerassimo ogni coppia come una
caratteristica separata e assumessimo n spazi, il category partition genererebbe tutte le 2^n
combinazioni parametri compatibili e incompatibili. Quindi potremmo avere un caso di
test in cui la prima opzione selezionata è compatibile, la seconda è compatibile e la terza
incompatibile, e un diverso caso di test in cui la prima è compatibile ma la seconda e la
terza sono incompatibili, e così via. Ognuna di queste combinazioni potrebbe essere
combinata in diversi modi con altre caratteristiche dei parametri. Il numero di
combinazioni, allora, esplode rapidamente.
Scegliendo l'approccio dell’ “appiattimento”, quali classi d’equivalenza si prendono in
considerazione? Una selezione compatibile e una incompatibile? Tutte le selezioni
compatibili e tutte le selezioni incompatibili? Oppure un mix di due o più selezioni
compatibili e due o più incompatibili?
Sicuramente quest'ultimo è più completo, ma se il test ha un costo molto elevato, è una
questione di giudizio del progettista la scelta di tale opzione .
Come tutte le decisioni di progettazione, il modo in cui dati complessi e collezioni sono
suddivisi in categorie richiede un giudizio basato su una combinazione di analisi ed
esperienza.
10Test black-box di API basato su partizionamento
2.1.2 Identificazione dei valori rappresentativi
Questa fase consiste nell'identificare un elenco di valori rappresentativi (più precisamente
un elenco di classi di valori) per ciascuna delle caratteristiche dei parametri identificate
durante la fase precedente. I valori rappresentativi devono essere identificati per ciascuna
categoria in modo indipendente, ignorando le possibili interazioni tra i valori per le diverse
categorie, che sono considerati nella fase successiva.
I valori rappresentativi possono essere identificati applicando manualmente una serie di
regole note come test del valore limite o test di condizione errato. La regola di verifica
del valore limite suggerisce la selezione di valori estremi all'interno di una classe (ad es.,
valori massimi e minimi dell'intervallo), valori esterni ma il più vicino possibile alla classe
e valori "interni" (non estremi) della classe . I valori vicino al margine di una classe sono
spesso utili per rilevare errori nei programmi.
La regola della condizione errata suggerisce la selezione di valori che sono al di fuori del
normale dominio del programma, poiché l'esperienza indica che la corretta gestione dei
casi di errore è spesso trascurata dagli sviluppatori.
2.1.3 Generazione delle specifiche del caso di prova
Una specifica del caso di prova per una caratteristica viene fornita come una combinazione
di classi di valore, una per ogni caratteristica di parametro identificata. Sfortunatamente, la
semplice combinazione di tutte le classi di valore possibili, per ciascuna caratteristica dei
parametri, si traduce in un numero ingestibile di casi di test (molti dei quali sono
impossibili), anche per specifiche semplici. Tuttavia, non tutte le combinazioni di classi di
valore corrispondono a specifiche ragionevoli.
11Test black-box di API basato su partizionamento
Il category partition consente di omettere alcune combinazioni indicando classi di
valore che non devono necessariamente essere combinate con tutti gli altri valori.
Alcuni valori, inoltre, non sono errati di per sé, ma possono essere utili o addirittura validi
in combinazioni particolari. Combinazioni errate di valori validi possono essere escluse
con i vincoli di proprietà.
Un vincolo di proprietà raggruppa i valori di una caratteristica di un singolo parametro per
identificare sottoinsiemi di valori con proprietà comuni.
La scelta di nomi significativi per caratteristiche dei parametri e classi di valore consente
la generazione (semi) automatica delle specifiche del caso di test.
Esistono tre tipologie di vincoli: Error, Propriety e Single. Il vincolo Error indica una
classe di valore che dà luogo ad un errore; Property elimina le combinazioni invalide dei
valori delle categorie; infine, Single indica una classe di valore che si desidera testare una
sola volta e non su tutte le possibili combinazioni per ridurre il numero di test-case.
2.2 Analisi di Robustezza
In termini generali, la robustezza di un software o di un algoritmo è la sua capacità di
comportarsi in modo ragionevole in situazioni impreviste, non contemplate dalle
specifiche. Situazioni di questo tipo in genere riguardano errori ed eccezioni di varia
natura (dati di input scorretti, fallimenti di componenti software o hardware esterni al
sistema e interagenti con esso, e così via).
Anche in questo caso, l'idea intuitiva della robustezza implica certamente considerazioni
di valore sugli effetti dannosi che il sistema o l'utente subiscono se il sistema reagisce in
modo "irragionevole" a situazioni impreviste.
Uno dei metodi per effettuare l’analisi di robustezza è il category partition test.
Normalmente nel category partition test la maggior parte dei casi di test o delle prove
viene effettuata mediante input validi, così da testare il comportamento del software nelle
12Test black-box di API basato su partizionamento
condizioni in cui è stato progettato. Sono solo pochi i casi in cui vengono testati input non
validi, fuori dal corretto dominio di esecuzione.
Per effettuare una buona analisi di robustezza si inverte questo procedimento e effettua,
nelle quasi totalità dei casi, test su input “scorretti”.
Andando a testare tanti input imprevisti si calcola il grado di robustezza del software in
analisi.
Lo scopo è trovare tutti quei casi in cui il programma fallisce, per esempio, se il
programma a un determinato input imprevisto dà come risposta con un codice 404,
anziché con modulo pensato ad hoc, è sintomo di robustezza perché, sebbene non gestita,
il software è stato in grado di riconoscere l’input errato e muoversi di conseguenza.
Sarebbe stato problematico se, invece, al posto del codice d’errore, avesse continuato la
sua esecuzione e alterato lo stato interno della macchina.
13Test black-box di API basato su partizionamento
Capitolo 3 : Tools per l’ API-Testing
3.1 Postman
Postman è una delle applicazioni devolute al testing delle API più
utilizzate. Si basa sull’invio di richieste, request, a un web server e
le annesse risposte.
Consente agli utenti di configurare tutti gli Headers e i Cookies
previsti dall'API al fine di controllare la risposta.
Un test in Postman è un codice JavaScript, che viene eseguito dopo
che una richiesta è stata inviata dal client e una risposta è stata
ricevuta dal server.
3.1.1 Request
Una request è una richiesta che viene effettuata a un server. può
avere tante diverse consegne da comunicare, in base a quanti sono i
metodi di richiesta.
I metodi di richiesta, quindi, definiscono il tipo di richiesta da
effettuare. Quelli disponibili in Postman sono consultabili nella
Figura 3.1 : Metodi di
un' API-Request figura 3.1.
Quelli che vengono utilizzati più spesso sono:
1. POST - Per la creazione o l'aggiornamento dei dati;
2. PUT - per l'aggiornamento dei dati;
3. GET - per il recupero di dati;
4. DELETE – per la cancellazione di dati.
14Test black-box di API basato su partizionamento
Di una request si possono settare le autorizzazioni, le intestazioni, il corpo della richiesta,
un eventuale script da eseguire prima della richiesta e i tests:
Figura 3.2 : Settagi di un' API- Request
Il campo URL di richiesta è atto ad inserire il link per la richiesta http.
Per quanto riguarda le altre categorie:
Headers: nelle intestazioni delle richieste sono presenti le coppie valore-chiave
dell'applicazione. Vediamo, a titolo d’esempio, due coppie:
1. Content-type: un tipo di contenuto descrive il formato dei dati dell'oggetto. Uno di
quelli più usati è senza dubbio application / json.
2. Authorization: un token di autorizzazione, incluso con le richieste, viene
utilizzato per identificare il richiedente.
Body: Nel campo Body (Corpo) si immettono gli input ai campi richiesti dal server, nel
caso fossero necessari:
15Test black-box di API basato su partizionamento
Figura 3.3 : Body di un'API-Request
Infine nei campi Pre-request Script e Tests si inserisce del codice che verrà eseguito
rispettivamente prima di effettuare la richiesta o subito dopo la recezione della risposta.
3.1.2 Collections
Una collection è un gruppo di API-Request che
possono essere raggruppate in un certo ordine.
Sono la “base” per effettuare operazioni più
avanzate.
Una collection può avere sia delle autorizzazioni,
come un username e una password per entrare al
suo interno, sia delle folders (cartelle) per
Figura 3.4 : Creazione di una Collection
migliorare l’organizzazione. Ogni cartella, a sua
volta, può avere delle autorizzazioni per l’accesso.
Una volta che in tutte le cartelle sono presenti più request è possibile mandare in
esecuzione l’intera collection, la quale eseguirà le request presenti sequenzialmente in
ogni cartella e fornirà i risultati.
16Test black-box di API basato su partizionamento
Le collections possono essere esportate o importate per favorire il loro riuso, mediante le
sezioni di Import/Export.
3.1.3 Variables
Sono elementi che possono assumere diversi valori, sia come stringhe che come valori
numerici, ma anche altri tipi di dato. Sono visibili all’interno di una certa collection e
possono essere create e/o modificate mediante la sezione “Edit” (della collection).
Una variable è composta da due campi: key e value. La key rappresenterà la sua shortcut
mentre value il suo corrispettivo. Per esempio con la key “url” si può intendere
“www.miosito.it”, quindi ogni volta che si andrà a scrivere {{url}} al suo posto è come se
ci fosse scritto “www.miosito.it”.
È possibile creare anche variables con visibilità globale, quindi non solo relativa a una
data collection, tramite la sezione “Manage Environment”. Infatti in questi Environments
sono contenute tutte le nostre variables con scope globale.
Si può, inoltre, creare un file .json con all’interno tutte le coppie valore-chiave per le
variables:
[
{
“nome_key_1” : “value_1”,
“nome_key_2” : “value_2”,
“nome_key_3” : “value_3”
},
{
17Test black-box di API basato su partizionamento
“email” : “mario@mario.mario” ,
“password” : “1234”,
“url” : “www.ciao.ciao”
},
{
“email” : “ciao@ciao.ciao” ,
“password” : “1234”,
“url” : “www.ciao.ciao”
}
]
Ogni blocco delineato dalle parentesi graffe indica un caso di test. I vari nomi_key invece
sono le key utilizzate all’interno della collection, mentre i values, che variano di blocco in
blocco, sono i casi di test da effettuare. Nell’esempio appena fatto, i blocchi due e tre
simulano un eventuale login al sito www.ciao.ciao.
3.1.4 Riposta HTTP
Alla request, l'API risponde inviando un messaggio composto da Corpo, Cookie,
Intestazioni, Test, Codice di stato e Tempo di risposta dell'API.
Postman organizza corpo e intestazioni in diverse schede. Per esempio il codice per il
tempo impiegato per completare la request viene visualizzato in una scheda diversa dalle
altre.
Ci sono molti codici di stato, da cui si verifica la risposta. Quelli più frequenti sono:
1. 200 – Per dare un feedback di corretta esecuzione.
2. 201 – Per la corretta esecuzione della richiesta e la corretta creazione dei dati.
3. 204 - Per risposta vuota.
4. 400 - Per richiesta errata. Se la richiesta non può essere compresa o mancano i
18Test black-box di API basato su partizionamento
parametri richiesti.
5. 401 - Per l'accesso non autorizzato. Autenticazione fallita o mancanza di
autorizzazioni per l'operazione richiesta.
6. 403 - Per accesso negato.
7. 404 - Per dati non trovati.
8. 405 – Per la presenza di un metodo non consentito o per la richiesta non
supportata.
9. 500 – Per un errore interno del server.
10. 503 – Per un servizio non disponibile.
3.2 Altri tools
3.2.1 SoapUI
SoapUI è uno strumento di test funzionale dedicato al test API, che consente agli utenti di
testare facilmente API, SOAP ( protocolli che permettono lo scambio di messaggi tra
software) e servizi Web.
Pro:
• Creazione test con Drag and drop, Point-and-click;
• Riutilizzabilità degli script;
• Creazione di codice personalizzato usando Groovy;
• Caricamento dei dati da file, database ed Excel tali che possano simulare il modo in cui i
consumatori interagiscono con le API
3.2.2 Katalon Studio
Katalon Studio è uno strumento di automazione di test per applicazioni API, Web e
Mobile. Sta emergendo come strumento leader per i test dei servizi API / Web e si
posiziona come una soluzione completa di automazione end-to-end per sviluppatori e
tester.
19Test black-box di API basato su partizionamento
Katalon Studio supporta sia le richieste SOAP che API con vari tipi di comandi e
funzionalità di parametrizzazione. Inoltre ha la capacità di combinare UI e servizi API /
Web per più ambienti (Windows, Mac OS e Linux) .
3.2.3 Apigee
Apigee è uno strumento di test API cross-cloud, che consente agli utenti di misurare e
testare le prestazioni delle API.
Pro:
• È multi-step e alimentato da Javascript
• Identifica i problemi di prestazioni monitorando il traffico delle API, i tassi di errore e i
tempi di risposta
• Permette di creare facilmente proxy API e distribuirli nel cloud
• Modello di distribuzione cloud
• Apigee è costruito appositamente per il business digitale e le app basate su dispositivi
mobili.
3.2.4 Jmeter
JMeter è un software open-source ampiamente utilizzato per il test funzionale delle API
sebbene sia stato effettivamente creato per il test del carico.
Pro:
• Supporta la riproduzione dei risultati del test
• Funziona automaticamente con i file CSV, consentendo al team di creare rapidamente
valori di parametri univoci per i test API.
• Può essere utilizzato per test delle prestazioni sia statici che dinamici delle risorse
3.2.5 Assertible
Assertible è uno strumento di test API che si concentra sull'automazione e l'affidabilità.
Pro:
20Test black-box di API basato su partizionamento
• Supporto per l'automazione dei test API attraverso un'integrazione continua.
• Supporto per la convalida delle risposte HTTP come la convalida dello schema JSON e i
controlli di integrità dei dati.
3.2.6 Fiddler
Fiddler è uno strumento che consente di monitorare, manipolare e riutilizzare le richieste
HTTP. Fiddler permette di eseguire il debug dei problemi del sito Web ed estendere le sue
funzionalità mediante degli opportuni Add-on.
Uno di questi, l'estensione APITest, migliora notevolmente Fiddler per convalidare il
comportamento delle API Web.
Per uno sviluppo più dettagliato delle API è possibile utilizzare la libreria di classi.
Questa è un'ottima scelta per i team che utilizzano i linguaggi .NET, dal momento che si
può sviluppare i test utilizzando qualsiasi linguaggio .NET si desidera.
21Test black-box di API basato su partizionamento
Capitolo 4 : Un approccio di category-partition per il test di
API
In questo capitolo, è affrontato un approccio al category partition test pensato per l’API-
Testing utilizzando tutte le tecniche e metodologie viste nei capitoli precedenti. Si parte
dalla creazione di una collection, utilizzando Postman, passando, poi, alla creazione dei
casi di test, che verranno forniti al programma tramite un file .json.
Infine si effettuerà la verifica di tutte le request alla ricerca di eventuali bug.
Il sito sotto analisi è https://reqres.in/, il quale permette di sperimentare, in modo
controllato, varie tipologie di API. Il sito simula un catalogo di persone sul quale poter
operare.
4.1 : Collection
Il primo passo prevede la creazione della nostra Collection (figura 4.1). Nelle Variables
della collection, per comodità, conviene creare una “url” con valore il sito da analizzare:
figura 4.1 : Creazione della collection
22Test black-box di API basato su partizionamento
La collection viene divisa in quattro folder: Operazioni di Get, Operazioni di Delete,
Operazioni con email e password e Operazioni con nome e lavoro. Mentre le prime due
sottocategorie sono divise in base all’operazione che andranno a fare, le restanti due sono
divise in base alla tipologia di dati che usano come input.
Nelle Operazioni di GET sono presenti due request: la prima per ottenere tutti gli utenti
presenti nel sito e la seconda per un singolo utente.
Nelle Operazioni con email e password sono presenti due request: la prima per registrarsi
al sito, la seconda per effettuare il login.
Nelle Operazioni con nome e lavoro sono presenti due request: la prima per modificare il
nome/lavoro di una persona, la seconda per la creazione di un nome/lavoro.
Nelle Operazioni di DELETE, infine, è presente una request per eliminare una persona dal
sito.
figura 4.2 : Requests nella Collection
23Test black-box di API basato su partizionamento
4.2 : Category Partition
Prima di procedere all’analisi di ogni Request sono state create le classi d’equivalenza:
Tipo Nome Descrizione
Nome NomeEmpty Nome vuoto
NomeNULL Nome con valore NULL
NomeInvalid Nome invalido, per esempio con
numeri al suo interno
NomeValid Nome valido
Cognome CognomeEmpty Cognome vuoto
CognomeNULL Cognome con valore NULL
CognomeInvalid Cognome invalido, per esempio
con numeri al suo interno
CognomeValid Cognome valido
Email EmailEmpty Email vuota
EmailNULL Email con valore NULL
EmailInvalid Email invalida, ovvero in un
formato diverso da abc@def.ghi
EmailValid Email valida
Password PasswordEmpty Password vuota
PasswordNULL Password con valore NULL
PasswordInvalid Password invalida, per esempio
con caratteri non consoni o
troppo lunga
PasswordValid Password valida
Id IdEmpty Id vuoto
IdNULL Id con valore NULL
IdInvalid Id invalido, per esempio con un
carattere alfabetico
IdValid Id valido
Lavoro LavoroEmpty Lavoro vuoto
LavoroNULL Lavoro con valore NULL
LavoroInvalid Lavoro invalido, per esempio
con un numero al suo interno
LavoroValid Lavoro Valido
Tabella 4.1 : Classi d’equivalenza
Successivamente, per ogni requests, verranno approfonditi i test-case e presentati i relativi risultati.
24Test black-box di API basato su partizionamento
4.3 : Request
Il passo successivo consiste nel settare, per ogni richiesta, la sua url e l’Header:
figura 4.3 : Setting delle request
4.3.1 List users
figura 4.4 : List Users.
Oracolo: 200 OK.
La request interroga il sito, relativo alla pagina 2 degli users, e ottiene risposta. Lo status
(cerchiato in rosso) ci fornisce il codice 200 (un feedback di corretta esecuzione), che
25Test black-box di API basato su partizionamento
rispecchia a pieno l’oracolo.
4.3.2 Single user
figura 4.5 : Single User.
Oracolo: 200 OK.
La request chiede informazioni relative a un singolo utente, nell’esempio il secondo.
Ottiene come riposta lo status 200, come previsto dall’oracolo.
4.3.3 Create
La request Create prende in input un nome e un lavoro e li associa. L’API, inoltre, ha il
compito di assegnare un ID e la data di creazione per ogni coppia nome-lavoro. L’output,
infine, sarà nome, lavoro, id e data di creazione.
Dalla tabella delle classi d’equivalenza si nota che si devono effettuare almeno sedici test
frame, poiché sono presenti quattro classi relative al nome e quattro relative al lavoro.
figura 4.6 : Request Create
26Test black-box di API basato su partizionamento
Parametrizzato il body della request (figura 4.6) si crea il file .json contenente i test, nella
seguente forma:
[
{
“nome” : “test di nome”,
“lavoro” : “test di lavoro”
}
]
Si passa ai test frame. Nella seguente tabella è presente il test frame con relativo oracolo e
risultato ottenuto.
Test-frame Test-Case Oracolo RispostaTest black-box di API basato su partizionamento
LavoroValid>
Tabella 4.2 : I test frame della request Create
figura 4.7. : Esecuzione della request Create
Il sito non è per nulla robusto, come si nota dallo status “201” in risposta ad ogni request,
poichè valuta “corretta” ogni scelta di nome o di lavoro. Nella quasi totalità dei casi è la
risposta è discorde con l’oracolo.
È stato effettuato, infine, anche un test relativo all’invio di un solo parametro, come il
“nome” senza il parametro “lavoro”, e il sito risponde aggiungendo il nome, senza il
campo lavoro.
28Test black-box di API basato su partizionamento
4.3.4 Update
Per la request “Update” sono stati usati gli stessi dati usati per la request Create, in quanto,
la parametrizzazione comprende “nome” e “lavoro”.
Il compito di questa richiesta è quello di aggiornare un lavoro, dato un nome.
figura 4.8 : Esecuzione della Request Update
Test-frame Test-Case Oracolo RispostaTest black-box di API basato su partizionamento
LavoroInvalid> imp1egato”>
Tabella 4.3 : I test frame della request Update
Anche in questo caso il sito è poco robusto: accetta in input qualsiasi scelta relativa alle
classi d’equivalenza. A differenza della request vista in precedenza, però, se come input si
usasse solo il parametro “nome”, senza “lavoro”, si avrebbe l’errore 400 Bad Request, in
modo concorde all’oracolo (figura 4.9).
figura 4.9 : Esecuzione della Request Update, senza il campo "lavoro"
30Test black-box di API basato su partizionamento
4.3.5 Register e Login
Poichè le due request condividono lo stesso file .json per i dati, si è optato per trattarle in
contemporanea. Questa volta, a differenza delle precedenti, si è presentato un sistema più
robusto, in grado di coprire un bel po’ delle classi d’equivalenza.
La request Register consente di registrarsi al sito mediante un username e una password,
mentre la request Login permette di accedere al sito con un username e una password.
Analisi dei Test-Frame:
Test-frame Test-Case Risposta Risposta Login Oracolo Oracolo Login
Register Register
31Test black-box di API basato su partizionamento
Tabella 4.4 : I test frame delle requests Register e Login
Dalla precedente tabella si è dedotto che il sistema è robusto in caso di Email e/o
Passoword vuota, poiché in risposta è presente lo status “400 Bad Request”.
Inoltre, nel caso di omissione del campo Password nella request, si presenterà un errore
ancora più raffinato: missing password (figura 4.10).
32Test black-box di API basato su partizionamento
figura 4.10 : Esecuzione della Request Register, senza il campo "password"
4.3.6 Delete
L’ultima request, Delete, ha il compito di eliminare un utente dal sistema.
Oracolo: 204 No Content.
In tal caso il sito non ha previsto nessun testo di risposta alla request, ma si può notare
l’avvenuta cancellazione tramite la risposta “204 No Content”, in linea con l’oracolo.
33Test black-box di API basato su partizionamento
figura 4.11 : Esecuzione della Request Delete
4.4: Vincoli
Il Category Partition, come visto nel capitolo due, si conclude con l’applicazione dei
Vincoli, prima di effettuare i test-case. Questo procedimento consente di ridurre di molto il
numero di test-frame e di ottimizzare i risultati.
Nel Category Partition appena visto ciò non è avvenuto perché i test-frame erano
trentadue, quindi del tutto gestibili.
Ipotizzando, dunque, di voler ridurre il numero di test-frame si potrebbe implementare un
vincolo di errore: [Error] Mancato Parametro.
Questo vincolo avrebbe ridotto notevolmente i test frame in quanto i vari NomeEmpty,
PasswordEmpty, IdEmpty e LavoroEmpty e NomeNULL, PasswordNULL, IdNULL e
LavoroNULL sarebbero stati invalidati, così come le loro combinazioni.
Da trentadue test-frame se ne otterrebbero otto.
34Test black-box di API basato su partizionamento
Conclusioni
Sia la collection che il test nel loro stato attuale hanno alcuni aspetti che possono essere
migliorati, ma comunque al momento soddisfa il requisito iniziale di category partition
basato sull’ API-Testing.
L’aspetto più vantaggioso nell’uso di questa metodologia sta nella capacità di valutare
la robustezza di un insieme di API. Tutto questo è possibile grazie all’uso di Postman
e alla creazione di file .json.
Il punto di partenza, ovvero l’unico prerequisito dell’applicazione, è la
conoscenza delle API del servizio. Si tratta di un prerequisito semplice da soddisfare,
soprattutto se si pensa che le specifiche di un servizio, che successivamente
diventeranno API, sono di fondamentale importanza nell’interazione tra diversi gruppi
di lavoro: progettisti, sviluppatori e tester.
Uno dei punti di forza è la capacità di individuare grossi errori in fase di
implementazione.
Ma, come descritto in precedenza, ci sono diversi aspetti che potrebbero essere
migliorati: in un’ottica aziendale si potrebbe inserire nel codice degli script, che ,o
descriveranno, con una stampa a video per esempio, ciò che si sta andando a testare, o
verificheranno un determinato valore o parametro, così da stabilire se il test sia stato
superato automaticamente. Attualmente Postman mette a disposizione “Pre-Request
Script” e “Tests” per effettuare queste modifiche.
Un altro aspetto da poter migliorare è sicuramente la creazione di nuove classi
d’equivalenza, scelte e valori, così da poter fare un category partition più approfondito.
Il sito in analisi, poiché pensato per provare sommariamente il funzionamento di test su
delle API, è poco robusto, quindi creare nuovi classi d’equivalenza o scelte sarebbe
uno spreco di risorse. Quindi è possibile approfondire il category partition, ma non con
il sito in analisi.
35Test black-box di API basato su partizionamento
Infine, uno degli svantaggi di questa tipologia è la difficoltà di automatizzare il
processo di creazione delle classi d’equivalenza, il ché comporta un notevole dispendio
di risorse sia temporali, in quanto è necessario un lasso di tempo maggiore rispetto a un
eventuale processo automatizzato, sia umane, in quanto gran parte del lavoro deve
essere svolto manualmente da una persona.
36Test black-box di API basato su partizionamento
Bibliografia
[1] Michal Young and Mauro Pezze, Software Testing and Analysis: Process, Principles
and Techniques, John Wiley & Sons, Inc., USA, 2005
[2] C. Ghezzi, M. Jazayeri, D.Mandrioli, Ingegneria del software. Fondamenti e
principi, Pearson, 2004
[3] Wikipedia, https://it.wikipedia.org/, 2019
37Puoi anche leggere
