Cos'è il test dei componenti? Tecniche, casi di test di esempio

By: Tommaso Hamilton Tommaso Hamilton
Hours aggiornato

⚡ Riepilogo intelligente

Il test dei componenti verifica ogni singola parte di un'applicazione separatamente, senza integrarla con il resto, in modo da individuare e correggere i difetti all'interno di un singolo modulo prima dell'inizio dell'assemblaggio.

  • 🧩 Scopo: Un componente alla volta, isolato dai componenti circostanti.
  • 👥 Proprietario: I tester lo eseguono dopo che gli sviluppatori hanno completato i test unitari.
  • 🔬 CTIS: Il test dei componenti in Small isola completamente il componente.
  • 🔗 CTIL: Il test dei componenti in Large mantiene le dipendenze, reali o simulate.
  • 🧱 Doubles: Un driver chiama il componente; da esso viene chiamato uno stub.
  • ✅ Exit: Nessun difetto critico, elevato o medio rimane aperto nel registro.
Scopri di più

Tecniche di test dei componenti ed esempi di casi di test

Cos'è il test dei componenti?

Test dei componenti è un tipo di test del software in cui il test viene eseguito su ogni singolo componente separatamente, senza integrarlo con altri componenti. Da una prospettiva architetturale è anche chiamato test del moduloe alcune fonti lo chiamano test del programma.

Qualsiasi software nel suo insieme è composto da diversi componenti e il test a livello di componente si occupa di testare tali componenti individualmente. È uno dei più frequenti test della scatola nera tipologie eseguite dal team di controllo qualità.

È opportuno fare una nota sulla denominazione fin da subito. Il glossario ISTQB tratta il test dei componenti e unit test come sinonimi dello stesso livello di test. Molti team di sviluppo, e questo articolo, li tengono separati nella pratica: gli sviluppatori eseguono unit test sul proprio codice, e i tester eseguono poi test di componente sulla build consegnata. La tabella comparativa alla fine di questo articolo illustra tale distinzione pratica.

Come mostra il diagramma sottostante, il test dei componenti ha una propria strategia di test e un proprio piano di test, in cui ogni parte del software o dell'applicazione viene considerata individualmente. Per ogni componente un scenario di prova viene definito, che viene poi scomposto in casi di test di alto livello e infine in casi di test dettagliati di basso livello casi test con prerequisiti.

Gerarchia di test dei componenti, dalla strategia di test fino ai casi di test di basso livello.

Il modo in cui viene utilizzato il termine "test dei componenti" varia da settore a settore e da organizzazione a organizzazione. Le ragioni più comuni di questa differenza di percezione sono le tre elencate di seguito.

  1. Il tipo di modello del ciclo di vita dello sviluppo scelto
  2. La complessità del software o dell'applicazione in fase di test
  3. Se il test viene eseguito con o senza isolamento dagli altri componenti dell'applicazione

Il ciclo di vita del test del software produce numerosi artefatti di test, ovvero i documenti creati e utilizzati durante le attività di test. Tra questi, la politica di test e la strategia di test definiscono quali tipi di test vengono utilizzati e quanto approfonditamente vengono eseguiti i test in un determinato progetto.

Chi esegue i test sui componenti

Il test dei componenti viene eseguito dai tester. Il test unitario viene eseguito dagli sviluppatori, che testano una singola funzione o procedura. Una volta completato il test unitario, segue il test dei componenti, di cui i tester si assumono la responsabilità.

Quando eseguire il test dei componenti

Il test dei componenti viene eseguito subito dopo che gli sviluppatori hanno completato i test unitari e la build è stata rilasciata al team di test. Questa build viene definita build UT, o build di test unitario. In questa fase vengono testate le funzionalità principali di ogni componente.

Criteri di ingresso per il test dei componenti

  • È stato sviluppato e testato a livello unitario l'insieme minimo di componenti da includere nella build UT.

Criteri di uscita per il test dei componenti

  • La funzionalità di ciascun componente funziona come specificato.
  • Nessun difetto critico, di gravità elevata o media o di priorità rimane aperto nel registro dei difetti.

Tecniche di test dei componenti

In base al livello di approfondimento dei test, i test dei componenti vengono classificati in due modi.

  1. CTIS: test dei componenti in piccole dimensioni
  2. CTIL — Test dei componenti su larga scala

CTIS: test dei componenti in piccole dimensioni

Il collaudo dei componenti può essere eseguito con o senza isolamento dagli altri componenti dell'applicazione in esame. Quando viene eseguito con gli altri componenti isolati, si parla di collaudo dei componenti in ambiente ridotto.

Esempio 1: Su un sito web con cinque pagine web diverse, testare ogni pagina web separatamente e in isolamento dagli altri componenti è il test dei componenti in piccolo.

Esempio 2: La home page di guru99.com mostrata di seguito contiene molti componenti, come Home, Test, SAPWeb, Da imparare assolutamente!, Big Data, Progetti dal vivo e Blog.

Guru99 menu di navigazione della home page trattati come componenti testabili separati

Allo stesso modo, qualsiasi software è composto da molti componenti, e ogni componente ha i propri sottocomponenti. Testare ciascun modulo elencato nell'Esempio 2 separatamente, senza considerare la sua integrazione con gli altri componenti, rappresenta un test dei componenti in miniatura.

Aprendo il menu a tendina Test vengono visualizzati i sottocomponenti del componente Test: Test manuale, SOAPUI, QTP, JUnit, Selenium, Gestione dei test e Test mobiliNell'immagine sottostante, questi sottocomponenti sono evidenziati in rosso.

Test del menu a tendina con i relativi sottocomponenti evidenziati in rosso

ARTICOLI CORRELATI

CTIL — Test dei componenti su larga scala

Il test dei componenti eseguito senza isolamento dagli altri componenti dell'applicazione in fase di test viene definito test dei componenti su larga scala.

Un esempio chiarisce meglio la differenza. Supponiamo che un'applicazione sia composta da tre componenti: Componente A, Componente B e Componente C.

Lo sviluppatore ha realizzato il Componente B e desidera testarlo. Per testare completamente il Componente B, alcune delle sue funzionalità dipendono dal Componente A e altre dal Componente C, come illustrato nel diagramma seguente.

Il componente B è stato testato con un driver in sostituzione del componente A e uno stub in sostituzione del componente C.

Il flusso funzionale è A → B → C, il che significa che il componente B dipende sia da A che da C. In questo flusso, lo stub è la funzione chiamata e il driver è la funzione chiamante.

I componenti A e C non sono ancora stati sviluppati. Per testare completamente il componente B, A e C vengono sostituiti, a seconda delle necessità, da un driver e da uno stub, quindi i due pezzi mancanti fungono da oggetti fittizi finché non saranno disponibili quelli reali.

  • Mazzo: Il componente in fase di test chiama uno stub. Il componente C non è pronto, quindi uno stub lo sostituisce e restituisce le risposte che B si aspetta.
  • Autista: Un driver richiama il componente da testare. Il componente A non è pronto, quindi un driver lo sostituisce e richiama B con gli input richiesti.

Casi di test di esempio per il test dei componenti

Le due pagine web riportate di seguito sono interconnesse dal punto di vista funzionale, il che le rende una coppia di componenti utili da testare.

La pagina web 1 è la pagina di accesso del sito di prova di banking.

Componente della pagina di accesso con campi per ID utente e password

Quando l'utente inserisce un ID utente e una password validi e clicca sul pulsante Invia, la pagina reindirizza alla home page del sito web della banca demo, mostrata di seguito.

Componente della pagina iniziale del gestore con link di navigazione e immagini

In questo caso, la pagina di login è un componente e la home page è un altro. Testare la funzionalità di ciascuna pagina separatamente è chiamato test dei componenti.

Scenari di test dei componenti sulla pagina web 1:

  • Inserisci un ID utente non valido e verifica che all'utente finale venga mostrato un avviso chiaro e comprensibile.
  • Inserisci un ID utente e una password non validi, fai clic su Reimposta e verifica che i campi ID utente e password siano stati cancellati.
  • Inserisci un nome utente e una password validi e fai clic sul pulsante Accedi.

Scenari di test dei componenti sulla pagina web 2:

  • Verifica che il messaggio di benvenuto della pagina del gestore venga visualizzato nella pagina iniziale.
  • Verifica che tutti i link sul lato sinistro della pagina web siano cliccabili.
  • Verifica che l'ID del responsabile sia visualizzato al centro della pagina iniziale.
  • Verifica la presenza delle tre diverse immagini sulla home page, come mostrato nel diagramma.

Test unitario e test dei componenti

La tabella seguente riassume le differenze tra i due livelli nella pratica quotidiana.

Test unitari Test dei componenti
Testare singoli programmi e moduli per dimostrare che il programma viene eseguito come previsto. Testare ciascun oggetto o parte del software separatamente, con o senza isolamento dagli altri oggetti.
Convalidato rispetto ai documenti di progetto. Convalidato rispetto ai requisiti di test e ai casi d'uso.
Fatto dagli sviluppatori. Fatto dai tester.
Fatto prima. Eseguito dopo il completamento dei test unitari da parte degli sviluppatori.
I difetti vengono solitamente riparati sul posto e non vengono formalmente registrati. I difetti vengono registrati e tracguidato attraverso il processo di gestione dei difetti.

DOMANDE FREQUENTI

Ridurre il rischio, verificare il comportamento funzionale e non funzionale del componente, rafforzare la fiducia nella sua qualità, individuare i difetti e impedire che tali difetti si propaghinoping in livelli di test più elevati.

I modelli leggono un componente contrace proporre input non validi, valori limite e percorsi di errore che un passaggio manuale tende a tralasciare. Un tester conferma comunque ogni risultato atteso prima dell'esecuzione.

Sì. Uno stub che restituisce risposte predefinite e un driver che immette input fissi sono codici schematici che un assistente scrive rapidamente. Decidere quali risposte siano realistiche rimane una decisione umana.

Il test dei componenti esamina un componente singolarmente. Componente test d'integrazione Esamina le interfacce e le interazioni tra i componenti e viene eseguito dopo il test dei componenti.

Code-strutture di livello come JUnit, TestNG, NUnit e pytest, oltre a runner di componenti UI come Cypress Test dei componenti, Storybook e Jest. Tutti questi elementi si inseriscono in un automazione tubatura.

Creazione e manutenzione dei duplicati. Uno stub che si discosta dal componente reale nasconde i difetti fino all'integrazione, quindi ogni risposta simulata deve essere rivista una volta che la dipendenza reale viene rilasciata.

Inverte l'ordine. I casi di test vengono scritti e automatizzati prima che il componente esista, quindi si aggiunge codice finché non vengono superati. Il componente viene quindi rilasciato con la sua suite di test già predisposta.

Entrambi, a seconda di chi lo esegue. I tester lavorano a scatola nera rispetto alle specifiche del componente, mentre gli sviluppatori con accesso al codice applicano scatola bianca copertura all'interno dello stesso componente.

Riassumi questo post con: