Menu

Che cos'è il test dei componenti o il test dei moduli (impara con esempi)

what is component testing

Prova Il Nostro Strumento Per Eliminare I Problemi

Che cos'è il test dei componenti chiamato anche test del modulo nel test del software:

Un componente è l'unità più bassa di qualsiasi applicazione. Quindi, test dei componenti; come suggerisce il nome, è una tecnica per testare l'unità più bassa o più piccola di qualsiasi applicazione.

Il test dei componenti a volte viene anche chiamato test del programma o del modulo.

Un'applicazione può essere pensata come una combinazione e integrazione di molti piccoli moduli individuali. Prima di testare l'intero sistema, è imperiale che ogni componente O l'unità più piccola dell'applicazione venga testata accuratamente.

domande e risposte del colloquio di ingegneria del software pdf

In questo caso, i moduli o le unità vengono testati in modo indipendente. Ogni modulo riceve un input, esegue alcune elaborazioni e genera l'output. L'output viene quindi convalidato rispetto alla funzionalità prevista.

Che cos

Le applicazioni software sono di natura enorme ed è una sfida testare l'intero sistema. Può portare a molte lacune nella copertura del test. Pertanto, prima di passare al test di integrazione o al test funzionale, si consiglia di iniziare con il test dei componenti.

Leggi anche=> Differenza tra unità, integrazione e test funzionali

Cosa imparerai:

Test dei componenti

È una specie di test white box.

Quindi, il test dei componenti cerca bug e verifica il funzionamento dei moduli / programmi che sono testabili separatamente.

Esiste una strategia di test e un piano di test per il test dei componenti. E, per ogni componente, esiste uno scenario di test che verrà ulteriormente suddiviso nei casi di test. Il diagramma seguente rappresenta lo stesso:

Test dei componenti

L'obiettivo del test dei componenti

L'obiettivo principale del test dei componenti è verificare il comportamento di input / output dell'oggetto di test. Assicura che la funzionalità dell'oggetto di prova funzioni correttamente e completamente secondo le specifiche desiderate.

Ingressi al test a livello di componente

I quattro input principali per il test a livello di componente sono:

  • Piano di test del progetto
  • Requisiti di sistema
  • Specifiche dei componenti
  • Implementazioni dei componenti

Chi esegue il test dei componenti?

Il test dei componenti viene eseguito dai servizi di QA o dal tester.

Cosa viene testato durante il test dei componenti?

Il test dei componenti può tenere conto della verifica delle caratteristiche funzionali o non funzionali specifiche dei componenti del sistema.

Può essere testare il comportamento delle risorse (ad esempio determinare le perdite di memoria), test delle prestazioni, test strutturali, ecc.

Quando viene eseguito il test dei componenti?

Il test dei componenti viene eseguito dopo il test dell'unità.

I componenti vengono testati non appena vengono creati, quindi è possibile che i risultati recuperati da un componente sottoposto a test dipendano da altri componenti che a loro volta non sono sviluppati al momento.

A seconda del modello del ciclo di vita dello sviluppo, il test dei componenti può essere eseguito separatamente con altri componenti del sistema. L'isolamento è fatto per prevenire influenze esterne.

Quindi, per testare quel componente, usiamo Stub e Driverper simulare l'interfaccia tra i componenti software.

Il test di integrazione viene eseguito dopo il test dei componenti.

Component Testing strategia di test

A seconda della profondità del livello di test, il test dei componenti è diviso in due parti:

  1. Component Testing in Small (ctis)
  2. Component Testing in Large (CTIL)

Quando il test dei componenti viene eseguito in isolamento con altri componenti, viene chiamato test dei componenti in piccolo. Ciò viene fatto senza considerare l'integrazione con altri componenti.

Quando il test dei componenti viene eseguito senza isolamento con altri componenti del software, viene chiamato come test dei componenti in generale. Ciò accade quando esiste una dipendenza dal flusso di funzionalità dei componenti e quindi non possiamo isolarli.

Se i componenti da cui dipendiamo non sono ancora sviluppati, utilizziamo oggetti fittizi al posto dei componenti effettivi. Questi oggetti fittizi sono lo stub (funzione chiamata) e il driver (funzione chiamante).

Stub e driver

Prima di passare al brief su Stub e Driver, dovrei informarmi sul differenza tra test dei componenti e test di integrazione. Il motivo è: stub e driver vengono utilizzati anche nei test di integrazione, quindi ciò potrebbe creare confusione tra queste due tecniche di test.

La tecnica di test di integrazione è una tecnica in cui combiniamo 2 componenti in sequenza e testiamo insieme il sistema integrato. I dati di un sistema vengono trasferiti a un altro sistema e la correttezza dei dati viene convalidata per il sistema integrato.

A differenza del test del modulo in cui il singolo componente / modulo viene testato accuratamente prima di integrarlo con altri componenti. Quindi, possiamo dire che il test dei componenti viene eseguito prima del test di integrazione.

Sia l'integrazione che il componente utilizzano Stub e driver .

'Autisti' sono i programmi fittizi che vengono utilizzati per chiamare le funzioni del modulo più basso nel caso in cui la funzione chiamante non esista.

'Stub' può essere indicato come codice uno snippet che accetta gli input / richieste dal modulo superiore e restituisce i risultati / risposta

Come spiegato in precedenza, i componenti vengono testati individualmente e indipendentemente. Quindi, potrebbero esserci alcune caratteristiche dei componenti, dipendenti dall'altro componente che non è attualmente sviluppato. Quindi, per testare i componenti con queste caratteristiche 'non sviluppate', dobbiamo utilizzare alcuni agenti stimolanti che elaborerebbero i dati e li restituirebbero ai componenti chiamanti.

In questo modo ci assicuriamo che i singoli componenti vengano testati accuratamente.

i singoli componenti vengono testati accuratamente

Qui vediamo che:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— sono i componenti
  • C1, C2 e C3 insieme formano la subunità 1
  • C4 e C5 insieme formano la sottounità 2
  • C6, C7 e C8 insieme formano l'unità secondaria 3
  • Solo C9 crea la subunità 4
  • La sottounità 1 e la sottounità 2 si combinano per formare l'unità di business 1
  • La sottounità 3 e la sottounità 4 si combinano per formare l'unità di business 2
  • L'Unità di business 1 e l'Unità di business 2 si combinano per creare l'applicazione.
  • Quindi, il test dei componenti, in questo caso, consisterebbe nel testare i singoli componenti che sono da C1 a C9.
  • Il Netto la freccia tra l'unità secondaria 1 e l'unità secondaria 2 mostra il punto di test di integrazione.
  • Allo stesso modo, il Netto la freccia tra la sottounità 3 e la sottounità 4 mostra il punto di test di integrazione
  • La freccia verde tra Business Unit 1 e Business Unit 2 mostra il punto di test di integrazione

Quindi faremmo:

  • COMPONENTE test per C1 a C9
  • INTEGRAZIONE test tra le sottounità e le unità di business
  • SISTEMA test dell'Applicazione nel suo complesso

Un esempio

Fino ad ora, dobbiamo aver stabilito che il test dei componenti è una sorta di tecnica di test della scatola bianca . Beh, potrebbe essere giusto. Ma questo non significa che questa tecnica non possa essere utilizzata nella tecnica di test della scatola nera.

gateway predefinito wifi di windows 10 non disponibile

Considera un'enorme applicazione web che inizia con una pagina di accesso. Come tester (anche questo in un mondo agile) non potevamo aspettare che l'intera applicazione fosse sviluppata e pronta per il test. Per aumentare il nostro time to market, dobbiamo iniziare i test in anticipo. Quindi, quando vediamo che la pagina di accesso è stata sviluppata, dobbiamo insistere affinché sia ​​resa disponibile per essere testata.

Non appena hai la pagina di accesso disponibile per il test, puoi eseguire tutti i tuoi casi di test (positivi e negativi) per assicurarti che la funzionalità della pagina di accesso funzioni come previsto.

I vantaggi di testare la tua pagina di accesso in questo momento sarebbero:

webservices in java intervista domande e risposte
  • L'interfaccia utente viene testata per l'usabilità (errori di ortografia, loghi, allineamento, formattazione ecc.)
  • Prova ad usare tecniche di test negativo come di autenticazione e autorizzazione. C'è un'enorme probabilità di trovare difetti in questi casi.
  • Uso di tecniche come SQL Injections garantirebbe di testare la violazione della sicurezza in una fase molto precoce.

I difetti che registreresti in questa fase fungerebbero da 'lezioni apprese' per il team di sviluppo e sarebbero implementati nella codifica della pagina successiva. Quindi, testando in anticipo, hai assicurato una migliore qualità delle pagine che devono ancora essere sviluppate.

Poiché le altre pagine consecutive non sono ancora state sviluppate, potresti aver bisogno di stub per convalidare la funzionalità della pagina di accesso. Per esempio ,si potrebbe desiderare una semplice pagina che indichi 'registrazione avvenuta con successo', in caso di credenziali corrette e finestra popup con messaggio di errore in caso di credenziali errate.

Puoi seguire il nostro tutorial precedente su Test d'integrazione per avere maggiori informazioni su stub e driver.

Come scrivere casi di test dei componenti?

I casi di test per il test dei componenti derivano da prodotti di lavoro, ad esempio la progettazione del software o il modello di dati. Ogni componente viene testato attraverso una sequenza di casi di test in cui ogni caso di test copre una combinazione specifica di input / output, ovvero funzionalità parziale.

Di seguito è riportato un esempio di caso di test di un componente per il modulo di accesso.

Possiamo scrivere altri casi di test in modo simile.

casi test

Test dei componenti vs test unitari

La prima differenza tra il test dei componenti e il test unitario è che il primo viene eseguito dai tester mentre il secondo viene eseguito dagli sviluppatori o dai professionisti SDET.

Gli unit test vengono condotti a livello granulare. D'altra parte, il test dei componenti viene eseguito a livello di applicazione. In unit testing, viene verificato se un singolo programma o la parte di codice viene eseguita secondo quanto specificato. Nel test dei componenti, ogni oggetto del software viene testato separatamente con o senza isolamento con altri componenti / oggetti del sistema.

Quindi, il test dei componenti è un po 'come il test unitario, ma viene eseguito a un livello di integrazione più elevato e nel contesto dell'applicazione (non solo nel contesto di quell'unità / programma come nel test dell'unità).

Componente Vs Interfaccia Vs Integrazione Vs Test di sistemi

Componente , come ho spiegato, è l'unità più bassa di un'applicazione che viene testata indipendentemente.

Un interfaccia è lo strato di unione dei 2 componenti. Il test della piattaforma o dell'interfaccia su cui interagiscono i 2 componenti è chiamato Test dell'interfaccia.

Ora, testare l'interfaccia è leggermente diverso. Queste interfacce sono principalmente API o servizi web , quindi il test di queste interfacce non sarebbe simile alla tecnica Black Box, piuttosto faresti un qualche tipo di test API o test del servizio Web utilizzando SOAP UI o qualsiasi altro strumento.

Una volta terminato il test dell'interfaccia, arriva il file Test d'integrazione .

Durante il test di integrazione, uniamo i singoli componenti testati uno per uno e li testiamo in modo incrementale. Durante l'integrazione convalidiamo che i singoli componenti, quando combinati uno per uno, si comportino come previsto e che i dati non vengano alterati quando passano da 1 modulo a un altro modulo.

Una volta che tutti i componenti sono stati integrati e testati, eseguiamo il Test di sistemi per testare l'intera applicazione / sistema nel suo complesso. Questo test convalida i requisiti aziendali rispetto al software implementato.

Conclusione

direi che Test di unità e il test dei componenti vengono eseguiti fianco a fianco.

A differenza del test unitario che viene eseguito dal team di sviluppo, il test dei componenti / moduli viene eseguito dal team di test. Si consiglia sempre di eseguire un test completo dei componenti prima di avviare il test di integrazione.

Se il test dei componenti è solido come una roccia, troveremo meno difetti nel test di integrazione. Ci sarebbero problemi, ma questi problemi sarebbero legati all'ambiente di integrazione o alle sfide di configurazione. È possibile garantire che la funzionalità dei componenti integrati funzioni correttamente.

Spero che questo tutorial sia stato utile per comprendere il test di componenti, integrazione e sistema. Se hai ancora domande, non esitare a chiederci nei commenti.

Lettura consigliata

^