Tutorial sul test delle API REST: esempi di casi di test manuali
Team editoriale
⚡ Riepilogo intelligente
Il test delle API REST convalida i servizi web RESTful inviando richieste HTTP come GET, POST, PUT e DELETE, e verificando il codice di stato, le intestazioni di risposta e il payload restituiti dal server.
Cos'è il test dell'API REST?
Test dell'API REST È una tecnica di test di automazione web open-source utilizzata per testare le API RESTful delle applicazioni web. Lo scopo del test delle API REST è registrare la risposta dell'API REST inviando diverse richieste HTTP/S per verificare se l'API REST funziona correttamente. Il test delle API REST viene eseguito tramite i metodi GET, POST, PUT e DELETE.
REST sta per Representational State Transfer. È uno stile architettonico e un approccio per la comunicazione utilizzato nello sviluppo di Servizi webREST è diventato una scelta logica per la creazione di API, perché consente agli utenti di connettersi e interagire con i servizi cloud in modo efficiente.
Un'API, o Interfaccia di Programmazione delle Applicazioni, è un insieme di istruzioni di programmazione per accedere a un'applicazione software basata sul web. In altre parole, è un insieme di comandi utilizzati da un programma per comunicare direttamente con un altro e utilizzare le rispettive funzioni per ottenere informazioni.
Per esempio, un Google Un sito web può disporre di un'API per la ricerca, le traduzioni e i calendari. In genere, le API si presentano come nell'esempio seguente, con nome del server, percorsi e parametri.
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
Ma perché investire tempo e risorse nei test a questo livello?
Perché è importante testare le API REST
Un'API REST si interpone tra l'interfaccia utente e il database, rappresentando quindi il livello in cui risiede la maggior parte della logica di business. Un difetto in una regola di prezzo o in un controllo delle autorizzazioni emerge nella risposta dell'API molto prima che qualcuno noti un numero errato sullo schermo, pertanto i test in questa fase consentono di individuare i problemi in una fase più precoce e più vicina alla loro causa.
La velocità è il secondo motivo. Una richiesta si completa in millisecondi e non necessita di browser, motore di rendering o localizzatori di elementi fragili. Un tester può testare decine di endpoint nel tempo necessario al caricamento di una pagina per un singolo test di interfaccia, e la stessa richiesta si comporta in modo identico sia che il front-end sia un sito web, un'app mobile o un'integrazione con un partner.
La stabilità è la terza ragione. I layout cambiano costantemente, ma un REST con pubblicatotracsi prevede che rimanga stabile. Test scritti contro tale convinzionetracPer sopravvivere alle riprogettazioni, proteggono le parti del prodotto su cui poi altri team costruiscono.
Tipi di metodi API
Ne esistono principalmente 4 tipi Test API Metodi: GET, POST, DELETE e PUT.
- GET– Il metodo GET viene utilizzato per esportaretracottenere informazioni dal server specificato utilizzando un URI specificato. Quando si utilizza una richiesta GET, dovrebbe essere eseguita solotraci dati t e non dovrebbero avere altri effetti sui dati.
- POST– Una richiesta POST viene utilizzata per creare una nuova entità. Può anche essere utilizzato per inviare dati al server, ad esempio informazioni sui clienti, caricamento di file, ecc. utilizzando moduli HTML.
- PUT– Crea una nuova entità o aggiornane una esistente.
- DELETE– Rimuove tutte le rappresentazioni correnti della risorsa di destinazione fornite da un URI.
Come testare l'API REST
Il test delle API REST richiede che un'applicazione interagisca con un'API di esempio da testare. Per testare un'API, sono necessarie due cose:
- Strumento/framework di test per gestire l'API
- Scrivi il tuo codice per testare l'API REST di esempio
I casi di test delle API REST possono essere testati con strumenti come:
- Cliente di riposo avanzato
- Postman-Resto del cliente
- Curl in Linux
Qui utilizzeremo Advanced Rest Client. Di seguito sono riportati i passaggi per ottenere Advanced Rest Client.
Come ottenere Advanced Rest Client?
- Vai su Google ChromeWeb Store
- Cerca "Advanced Rest Client" o vai direttamente Qui. e installa l'estensione
- Seleziona l'icona "Advanced Rest Client" nella sezione app di Chrome: chrome://apps/
La pagina del negozio online appare come mostrato di seguito.
Una volta completata l'installazione, segui il test qui sotto per testare un API RESTful.
Passaggi per testare l'API REST
Qui stiamo utilizzando l'estensione client REST nel browser Chrome. Per comprenderlo in modo chiaro, stiamo usando un'API fittizia a scopo di test:
http://ip.jsontest.com/
Passaggio 1) Aprire il client REST avanzato
Avviare l'app Advanced REST client (ARC), una volta installata correttamente.
Passaggio 2) Inserire il URL di API da testare
Inserisci l'API REST di esempio URL per testare nel URL casella di testo.
Passaggio 3) Selezionare il metodo HTTP
Seleziona il metodo per il tipo di metodi HTTP nel test API per colpire, ad esempio POST
Passaggio 4) Fornire il set di intestazioni
Fornisci il set di intestazioni, nella casella di testo Intestazioni. Fai clic su Inserisci set di intestazioni.
Passaggio 5) Confermare le intestazioni impostate
Successivamente fare clic su USA QUESTO SET.
Passaggio 6) Fornire il contenuto del corpo richiesto
- Ora passa alla scheda Corpo.
- Imposta il tipo di contenuto del corpo richiesto e la visualizzazione dell'editor, ad esempio Tipo di contenuto del corpo: application/json
- Visualizzazione editor: input non elaborato.
- Nella sezione Payload, passa il corpo della richiesta dell'API demo per i test sotto forma di coppie chiave-valore, ad esempio {"chiave1":"valore1","chiave2":"valore2"}. Se si tratta di un'API POST, è necessario passare un corpo o dei parametri. Li passeremo nella sezione payload.
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️ Attenzione: Un Content-Type di application/json con un payload non valido JSON Restituisce l'errore 400 Bad Request.
Passaggio 7) Invia i dettagli per iniziare il test
- Premi il pulsante di invio.
- Puoi cliccare sul pulsante DETTAGLI per vedere le intestazioni delle risposte.
Ecco i dettagli della risposta:
La risposta deve ancora essere valutata in base al risultato atteso.
Convalida dei risultati
Principalmente, per testare le API Web, dobbiamo controllare il codice di risposta, il messaggio di risposta e il corpo della risposta.
I codici di risposta si suddividono in cinque famiglie:
| Famiglia | Categoria | Significato |
|---|---|---|
| 1xx | Informativo | Ricevuto, ancora in elaborazione |
| 2xx | di successo | Completato; 200 OK, 201 Creati |
| 3xx | Reindirizzamento | È necessaria un'ulteriore azione |
| 4xx | Errore del cliente | Payload, token o risorsa non validi. |
| 5xx | Errore del server | Richiesta valida, errore del server |
Di seguito sono riportati i codici di risposta che si potrebbero incontrare.
Una singola richiesta dimostra che l'endpoint funziona. Una serie di richieste dimostra che continua a funzionare.
Casi di test API REST che devi assolutamente coprire
Una suite di API REST utile si estende su diverse categorie anziché ripetere la stessa chiamata standard con dati diversi:
- Percorso felice: Invia una richiesta valida a ciascun endpoint e conferma il codice di stato, lo schema e il valore di ogni campo.
- Casi negativi: Se si invia un JSON non valido, un metodo non supportato e un ID risorsa mancante, è probabile che si ricevano codici di errore 400, 405 e 404 anziché 500.
- Valori limite: Se un campo accetta da 1 a 200 caratteri, testa 0, 1, 200 e 201. Le regole di validazione si interrompono ai limiti.
- Caratteri speciali: Inserisci lettere accentate, emoji, virgolette e testo multibyte in ogni campo per individuare eventuali errori di codifica.
- Contraccontrolli t: Confronta la risposta con le specifiche OpenAPI o Swagger pubblicate, in modo da individuare tempestivamente eventuali modifiche non documentate.
- Sequenziamento: È importante chiamare gli endpoint in un ordine realistico, ad esempio POST, poi GET e infine DELETE, poiché lo stato viene mantenuto tra una chiamata e l'altra.
- Sanità delle prestazioni: Registra i tempi di risposta per ogni esecuzione e segnala qualsiasi endpoint che superi la soglia concordata con il team.
Strumento di test dell'API REST
Strumenti diversi sono adatti a fasi di test diverse.
| Chiavetta | Tipo | migliori per |
|---|---|---|
| Cliente di riposo avanzato | Client desktop | Chiamate manuali rapide |
| Postman | Client desktop | Collezioni e spazi di lavoro di gruppo |
| JMeter | Test di carico | Tempi di risposta sotto carico |
| SoapUI | Test funzionali | RIPOSO e SAPONE insieme |
| Stia tranquillo | Java libreria | Automatizzazione dei casi stabili |
| cURL | riga di comando | Incollare le chiamate nei report di bug |
Vedi il riepilogo di Strumenti di test dell'API.
La maggior parte degli endpoint reali si rifiuta di rispondere finché la richiesta non dimostra chi l'ha inviata.
Autenticazione e controlli di sicurezza delle API REST
Gli endpoint demo pubblici rispondono a chiunque, ma un'API REST di produzione è protetta da un sistema di autenticazione e una falla nell'autorizzazione è molto più dannosa di un valore errato in un campo. Innanzitutto, identifica il meccanismo: una chiave API statica, credenziali HTTP Basic, un token bearer OAuth 2.0 o un JSON Web Token firmato.
Una volta che la richiesta autenticata ha esito positivo, analizzate attentamente i possibili scenari di errore:
- Nessuna credenziale: Rimuovere l'intestazione Authorization. Aspettarsi un errore 401 Non autorizzato e nessun dato nel corpo della risposta.
- Credenziali non valide: Corrompere un carattere del token. Aspettarsi di nuovo un errore 401, con un messaggio che non spiega il motivo.
- Credenziali scadute: Riutilizzare un token oltre la sua scadenza. Verificare che venga rifiutato anziché onorato, un difetto comune di sfasamento dell'orologio.
- Livello di privilegio errato: Autenticarsi come utente con privilegi limitati e chiamare un endpoint riservato agli amministratori. Aspettarsi un errore 403 Forbidden, non 200.
- Il record di un altro utente: Modifica l'ID in modo che l'utente A richieda i dati dell'utente B. Se ciò dovesse funzionare, si tratterebbe di un grave difetto nel controllo degli accessi.
Infine, verificare che ogni chiamata transiti su HTTPS e che le risposte errate non lascino tracce dello stack. tracbanner es o di versione e che le ripetizioni rapide attivano l'errore 429 Too Many Requests.
Anche il test delle API REST presenta difficoltà che il test delle interfacce non ha.
Sfide per il test delle API
I problemi interessanti per i tester durante il test delle API REST sono:
- Per garantire che il framework di test vari i parametri delle chiamate API in modo da verificare la funzionalità e al contempo evidenziare i malfunzionamenti. Ciò include l'esplorazione delle condizioni limite e l'assegnazione di parametri comuni.
- Creazione di interessanti combinazioni di valori di parametro per chiamate con due o più parametri
- Identificare il contenuto in base al quale devono essere effettuate le chiamate API. Ciò potrebbe includere l'impostazione di condizioni ambientali esterne (dispositivi periferici, file, ecc.) nonché dati memorizzati internamente che influenzano l'API.
- Sequenziamento delle chiamate API secondo l'ordine in cui la funzione verrà eseguita
- Per fare in modo che l'API produca risultati utili dalle chiamate successive.
