Cos'è il test dell'interfaccia? Tipi ed esempi

Cos'è il test dell'interfaccia?

Test di interfaccia è definito come un tipo di test del software che verifica se la comunicazione tra due diversi sistemi software avviene correttamente.

Una connessione che integra due componenti è chiamata interfaccia. Nel mondo dell'informatica, questa interfaccia può essere qualsiasi cosa, come API, servizi web, ecc. Il test di questi servizi di connessione o interfaccia è definito test di interfaccia.

Un'interfaccia è in realtà un software costituito da insiemi di comandi, messaggi e altri attributi che consentono la comunicazione tra un dispositivo e un utente.

Il punto importante è che un'interfaccia ha una contract: un formato di richiesta concordato, un formato di risposta concordato, un insieme concordato di codici di errore e un timeout concordato. Esercizi di test dell'interfaccia che contracda entrambi i lati, quindi una modifica apportata da una squadra non interrompe silenziosamente l'altra. Poiché la maggior parte di questo traffico non raggiunge mai uno schermo, i difetti che trova sono invisibili a test della scatola nera eseguito esclusivamente tramite l'interfaccia utente.

Come eseguire il test dell'interfaccia

Il test dell'interfaccia include il test di due segmenti principali:

1. Interfaccia del server Web e del server delle applicazioni
2. Interfaccia del server dell'applicazione e del server del database.

Per gli scenari sopra menzionati, viene eseguito il test dell'interfaccia

• I server di controllo vengono eseguiti correttamente o meno
• Gli errori vengono gestiti correttamente o restituiscono un messaggio di errore per qualsiasi query effettuata da un'applicazione
• Controlla i risultati quando la connessione a un server web viene reimpostata nel frattempo

Il diagramma sottostante mostra questi due segmenti come un'unica catena, in cui il browser comunica con il server web, il server web comunica con il server applicativo e il server applicativo comunica con il server di database.

In pratica, un tester percorre quella catena un passaggio alla volta. Ogni passaggio viene eseguito prima con una richiesta valida, poi con una richiesta non valida, quindi con l'estremità remota deliberatamente non disponibile, in modo che sia il percorso di successo che quello di fallimento vengano registrati rispetto allo stesso caso di prova.

Esempio di test dell'interfaccia

Supponiamo che per qualsiasi applicazione xyz, l'interfaccia prenda XML file come input e consegna JSON file come output. Per testare l'interfaccia di questa applicazione, è sufficiente specificare i formati di file XML e JSON.

Grazie a queste specifiche, possiamo creare file XML di input di esempio e inserirli nell'interfaccia. La successiva validazione dei file di input (XML) e di output (JSON) rispetto ai requisiti costituisce il test dell'interfaccia.

Notate cosa non è necessario nell'esempio: nessuna schermata, nessuna build del front-end e nessuna conoscenza del codice all'interno dell'interfaccia. Due specifiche di formato sono sufficienti per scrivere i test, ed è per questo che il testing dell'interfaccia può iniziare ben prima che l'interfaccia utente esista.

Perché eseguire il test dell'interfaccia

Viene eseguito il test dell'interfaccia

• Per garantire che gli utenti finali o i clienti non incontrino alcun problema durante l'utilizzo di un particolare prodotto software
• Identificare a quali aree applicative accedono solitamente gli utenti finali e verificarne anche la facilità d'uso.
• Per verificare i requisiti di sicurezza mentre la comunicazione si propaga tra i sistemi
• Per verificare se una soluzione è in grado di gestire i guasti di rete tra un server applicativo e un sito web

C'è anche una questione di costi. Correggere un difetto nel formato di una richiesta è economico finché i due sistemi sono ancora in fase di collegamento, ma costoso una volta che un sistema a valle ha già memorizzato i dati non validi.

Tipi di test dell'interfaccia

Durante il test dell'interfaccia vengono eseguiti vari tipi di test sull'interfaccia che possono includere

• Flusso di lavoro: Garantisce che il motore dell'interfaccia gestisca i flussi di lavoro standard come previsto.
• Casi limite - valori inattesi: Questo aspetto viene preso in considerazione quando i test includono l'inversione di data, mese e giorno.
• Test di prestazioni, carico e rete: Un'interfaccia ad alto volume potrebbe richiedere di più Caricare i test rispetto a un'interfaccia a volume ridotto, a seconda del motore dell'interfaccia e dell'infrastruttura di connettività
• Sistemi individuali: Ciò include testare ogni sistema singolarmente. Ad esempio, il sistema di fatturazione e il sistema di gestione dell'inventario per il punto vendita al dettaglio dovrebbero essere in grado di funzionare separatamente.

Il primo elemento è abbastanza vicino a test del flusso di lavoro per riutilizzare i suoi scenari e l'ultimo elemento si sovrappone a test del modulopoiché un sistema che si guasta da solo si guasterà di nuovo una volta collegato.

Strategia di test dell'interfaccia

La strategia di test dell'interfaccia è un metodo utilizzato per testare le interfacce con test comuni indipendentemente dall'implementazione. Possiamo usare assolutitract casi di test e creare istanze concrete del caso di test per ogni implementazione della strategia di test dell'interfaccia. La base/assolutatracI casi di test t eseguono test indipendenti dall'implementazione, mentre i test concreti si occupano di istanziare gli oggetti da testare ed eseguire test specifici dell'implementazione.

Il vantaggio di quella struttura è il riutilizzo. Quando appare una terza implementazione della stessa interfaccia, l'assolutotract suite funziona senza modifiche e solo il codice di istanziazione deve essere scritto. La stessa idea viene applicata su scala più ampia in test dei componenti, dove una condivisionetract suite viene eseguito su ogni componente che dichiara di soddisfarlo.

Strumenti per il test dell'interfaccia

Poiché un'interfaccia non ha uno schermo, gli strumenti devono costruire le richieste direttamente ed effettuare verifiche sulle risposte grezze. I team in genere combinano tre categorie di strumenti.

• Client API e strumenti per la creazione di richieste: Strumenti come Postman, SoapUIInsomnia e Hoppscotch inviano chiamate REST, SOAP o GraphQL, le memorizzano come collezioni riutilizzabili ed effettuano asserzioni su codici di stato, intestazioni e corpi di risposta.
• Code-librerie di test di livello: Le librerie che vengono eseguite all'interno della suite di test esistente consentono ai controlli di interfaccia di coesistere con i test unitari ed essere eseguiti a ogni build, impedendo così che diventino obsoleti.
• Strumenti di caricamento e protocollo: Uno strumento come JMeter guida la stessa interfaccia a volume, che è ciò che trasforma un controllo funzionale in test delle prestazioni della connessione.
• Virtualizzazione e simulazione dei servizi: Un moncone che funge da estremità consente di testare un lato mentre l'altro non è disponibile, non è completato o è troppo costoso da chiamare ripetutamente.

La selezione è meno importante della copertura. Qualunque client venga scelto, la raccolta di richieste deve essere memorizzata nel controllo di versione insieme al codice, in modo che una modifica all'interfaccia e una modifica ai relativi test arrivino nello stesso commit. I dettagli della categoria più ampia sono trattati in Test dell'API.

Checklist per il test dell'interfaccia e migliori pratiche

Una breve checklist garantisce la coerenza della copertura delle interfacce tra le diverse versioni. È consigliabile utilizzarla per ogni singola connessione, anziché per l'applicazione nel suo complesso.

• Contract prima: Verificare che gli schemi di richiesta e risposta corrispondano alle specifiche pubblicate, campo per campo, inclusi i tipi di dati e i campi opzionali.
• Valori limite: Invia payload vuoti, campi di lunghezza massima, set di caratteri imprevisti e formati data invertiti.
• Percorsi di errore: Verificare che ogni errore restituisca un codice e un messaggio significativi anziché uno stack trace o un successo silenzioso.
• Timeout e tentativi: Interrompere la connessione a metà richiesta e verificare che il chiamante riprovi in ​​modo sicuro senza duplicare la transazione.
• Sicurezza: Verifica l'autenticazione, l'autorizzazione e la crittografia del collegamento e assicurati che i messaggi di errore non rivelino dettagli interni.
• Coerenza dei dati: Rileggere il disco dall'altro lato e verificare che nulla sia stato troncato, ricodificato o riordinato durante la trasmissione.
• Volume: Ripeti la chiamata con il traffico più elevato in condizioni di carico simultaneo e monitora l'esaurimento del pool di connessioni.

Tre pratiche rendono ripetibile questa checklist. In primo luogo, automatizzare la suite ed eseguirla a ogni build, perché le interfacce cambiano più silenziosamente rispetto alle schermate. In secondo luogo, registrare la richiesta e la risposta complete per ogni errore, poiché un difetto dell'interfaccia è quasi impossibile da riprodurre da uno screenshot. In terzo luogo, mantenere la suite indipendente dai dati di test creati da altre suite, in modo che un errore sia riconducibile all'interfaccia piuttosto che a un record mancante.

Questi controlli si inseriscono naturalmente nel piano più ampio descritto in tipi di test del softwaree vengono eseguiti prima che le stesse connessioni vengano esercitate end-to-end durante test di sistema.

Test di interfaccia e test di integrazione

I due termini sono correlati piuttosto che opposti: il test di interfaccia è la parte del lavoro di integrazione che si concentra sulla connessione stessa. La tabella seguente illustra l'importanza di ciascun aspetto.

Chiunque sia nuovo alla disciplina più ampia troverà i livelli circostanti descritti in test d'integrazione e in generale test del software introduzione, mentre la terminologia utilizzata sopra deriva dallo standard Ingegneria del software pratica. Per i sistemi rivolti al browser, le stesse connessioni vengono infine esercitate di nuovo durante test di applicazioni web.

DOMANDE FREQUENTI