Menu

Tipi di test del software: diversi tipi di test con dettagli

types software testing

Prova Il Nostro Strumento Per Eliminare I Problemi

Quali sono i diversi tipi di test del software?

In qualità di tester, siamo consapevoli dei vari tipi di test del software come test funzionali, test non funzionali, test di automazione, test agili e relativi sottotipi, ecc.

Ognuno di noi avrebbe incontrato diversi tipi di test nel nostro viaggio di test. Potremmo averne sentito alcuni e potremmo aver lavorato su alcuni, ma non tutti conoscono tutti i tipi di test.

Diversi tipi di test del software

Ogni tipo di test ha le sue caratteristiche, vantaggi e svantaggi. Tuttavia, in questo articolo, ho trattato principalmente ogni tipo di test del software che di solito usiamo nella nostra vita quotidiana di test.

Andiamo a darci un'occhiata.

Cosa imparerai:

Diversi tipi di test del software

Di seguito è riportato l'elenco di alcuni tipi comuni di test del software:

I tipi di test funzionali includono:

  • Test unitario
  • Test d'integrazione
  • Test di sistema
  • Test di sanità mentale
  • Test del fumo
  • Test dell'interfaccia
  • Test di regressione
  • Beta / Test di accettazione

I tipi di test non funzionali includono:

  • Test delle prestazioni
  • Test di carico
  • Stress Testing
  • Test del volume
  • Test di sicurezza
  • Test di compatibilità
  • Installa test
  • Test di recupero
  • Test di affidabilità
  • Test di usabilità
  • Test di conformità
  • Test di localizzazione

Vediamo maggiori dettagli su questi tipi di test.

Tipi di test del software

# 1) Alpha test

È il tipo di test più comune utilizzato nell'industria del software. L'obiettivo di questo test è identificare tutti i possibili problemi o difetti prima di rilasciarlo sul mercato o all'utente.

L'Alpha Testing viene effettuato al termine della fase di sviluppo del software ma prima del Beta Testing. Tuttavia, a seguito di tali test possono essere apportate piccole modifiche al design.

Alpha Testing è condotto presso il sito dello sviluppatore. Per questo tipo di test è possibile creare un ambiente utente virtuale interno.

# 2) Test di accettazione

Un Test d'ingresso viene eseguito dal cliente e verifica se il flusso end-to-end del sistema è conforme ai requisiti aziendali o meno e se è secondo le esigenze dell'utente finale. Il client accetta il software solo quando tutte le caratteristiche e le funzionalità funzionano come previsto.

È l'ultima fase del test, dopodiché il software entra in produzione. Questo è anche chiamato User Acceptance Testing (UAT).

# 3) Test ad hoc

Il nome stesso suggerisce che questo test viene eseguito su un ad-hoc base, ovvero senza riferimento al caso di test e anche senza alcun piano o documentazione in atto per tale tipo di test.

L'obiettivo di questo test è trovare i difetti e interrompere l'applicazione eseguendo qualsiasi flusso dell'applicazione o qualsiasi funzionalità casuale.

Il test ad hoc è un modo informale per trovare i difetti e può essere eseguito da chiunque nel progetto. È difficile identificare i difetti senza uno scenario di test, ma a volte è possibile che i difetti rilevati durante i test ad hoc non siano stati identificati utilizzando i casi di test esistenti.

# 4) Test di accessibilità

Lo scopo di Test di accessibilità è determinare se il software o l'applicazione è accessibile o meno alle persone disabili.

Qui, disabilità significa sordi, daltonici, disabili mentali, ciechi, vecchiaia e altri gruppi di disabili. Vengono eseguiti vari controlli come la dimensione del carattere per i disabili visivi, il colore e il contrasto per il daltonismo, ecc.

# 5) Beta test

Beta test è un tipo formale di test del software che viene eseguito dal cliente. Viene eseguito in l'ambiente reale prima di rilasciare il prodotto sul mercato per gli utenti finali effettivi.

Il beta test viene eseguito per garantire che non vi siano guasti gravi nel software o nel prodotto e soddisfi i requisiti aziendali dal punto di vista dell'utente finale. Il beta test ha esito positivo quando il cliente accetta il software.

Di solito, questo test viene generalmente eseguito dagli utenti finali o da altri. È il test finale eseguito prima di rilasciare un'applicazione per scopi commerciali. Di solito, la versione Beta del software o del prodotto rilasciato è limitata a un certo numero di utenti in un'area specifica.

Quindi l'utente finale utilizza effettivamente il software e condivide il feedback con l'azienda. La società intraprende quindi le azioni necessarie prima di rilasciare il software a livello mondiale.

# 6) Test di back-end

Ogni volta che un input o dati vengono inseriti nell'applicazione front-end, vengono archiviati nel database e il test di tale database è noto come Test del database o Test del backend.

Esistono diversi database come SQL Server, MySQL e Oracle, ecc. Il test del database implica il test della struttura della tabella, dello schema, della procedura memorizzata, della struttura dei dati e così via.

In Back-end Testing GUI non è coinvolta, i tester sono direttamente connessi al database con un accesso adeguato e i tester possono facilmente verificare i dati eseguendo alcune query sul database.

Durante questo test di back-end possono essere identificati problemi come perdita di dati, deadlock, danneggiamento dei dati, ecc. E questi problemi sono fondamentali per la risoluzione prima che il sistema vada in linea nell'ambiente di produzione

# 7) Test di compatibilità del browser

È un sottotipo di test di compatibilità (spiegato di seguito) e viene eseguito dal team di test.

Test di compatibilità del browser viene eseguito per le applicazioni web e garantisce che il software possa essere eseguito con la combinazione di browser e sistemi operativi diversi. Questo tipo di test convalida anche se l'applicazione Web viene eseguita su tutte le versioni di tutti i browser o meno.

# 8) Test di compatibilità con le versioni precedenti

È un tipo di test che convalida se il software sviluppato di recente o il software aggiornato funziona bene con la versione precedente dell'ambiente o meno.

Il test di compatibilità con le versioni precedenti verifica se la nuova versione del software funziona correttamente con il formato di file creato da una versione precedente del software; funziona bene anche con tabelle di dati, file di dati, strutture di dati create dalla versione precedente di quel software.

Se uno dei software viene aggiornato, dovrebbe funzionare bene sulla versione precedente di quel software.

# 9) Test della scatola nera

La progettazione del sistema interno non è considerata in questo tipo di test. I test si basano sui requisiti e sulla funzionalità.

Informazioni dettagliate su vantaggi, svantaggi e tipi di Black box Testing si può vedere Qui .

# 10) Verifica del valore limite

Questo tipo di test controlla il comportamento dell'applicazione a livello di confine.

Verifica del valore limite viene eseguito per verificare se esistono difetti ai valori limite. Il test del valore limite viene utilizzato per testare un intervallo di numeri diverso. C'è un limite superiore e inferiore per ogni intervallo e il test viene eseguito su questi valori limite.

Se il test richiede un intervallo di test di numeri da 1 a 500, il test del valore limite viene eseguito sui valori a 0, 1, 2, 499, 500 e 501.

# 11) Test di filiale

È un tipo di test white box e viene eseguito durante gli unit test. Branch Testing, il nome stesso suggerisce che il codice viene testato a fondo attraversando ogni ramo.

# 12) Test di confronto

Il confronto dei punti di forza e di debolezza di un prodotto con le sue versioni precedenti o altri prodotti simili è definito test di confronto.

# 13) Test di compatibilità

È un tipo di test in cui convalida il modo in cui il software si comporta e viene eseguito in un ambiente, server Web, hardware e ambiente di rete diversi.

Test di compatibilità garantisce che il software possa essere eseguito su una configurazione diversa, database diverso, browser diversi e relative versioni. Il test di compatibilità viene eseguito dal team di test.

# 14) Test dei componenti

Viene eseguito principalmente dagli sviluppatori dopo il completamento dei test unitari. Test dei componenti implica il test di più funzionalità come un unico codice e il suo obiettivo è identificare se esiste qualche difetto dopo aver collegato tali funzionalità multiple tra loro.

# 15) Test end-to-end

Simile al test di sistema, Test end-to-end implica il test di un ambiente applicativo completo in una situazione che imita l'uso del mondo reale, come l'interazione con un database, l'utilizzo delle comunicazioni di rete o l'interazione con altri hardware, applicazioni o sistemi, se appropriato.

# 16) Partizionamento di equivalenza

È una tecnica di test e un tipo di Black Box Testing. Durante questo Partizionamento di equivalenza , viene selezionato un insieme del gruppo e alcuni valori o numeri vengono raccolti per il test. Resta inteso che tutti i valori di quel gruppo generano lo stesso output.

Lo scopo di questo test è rimuovere i casi di test ridondanti all'interno di un gruppo specifico che genera lo stesso output ma non alcun difetto.

Supponiamo che l'applicazione accetti valori compresi tra -10 e +10, quindi utilizzando il partizionamento di equivalenza i valori raccolti per il test sono zero, un valore positivo, un valore negativo. Quindi il partizionamento di equivalenza per questo test va da -10 a -1, 0 e da 1 a 10.

# 17) Test di esempio

Significa test in tempo reale. Il test di esempio include lo scenario in tempo reale, coinvolge anche gli scenari basati sull'esperienza dei tester.

# 18) Test esplorativi

Il test esplorativo è un test informale eseguito dal team di test. L'obiettivo di questo test è esplorare l'applicazione e cercare i difetti presenti nell'applicazione.

A volte può accadere che durante questo test un grave difetto scoperto possa persino causare un guasto del sistema.

Durante il test esplorativo, è consigliabile tenere traccia di quale flusso hai testato e quale attività hai svolto prima dell'inizio del flusso specifico.

Una tecnica di test esplorativo viene eseguito senza documentazione e casi di test.

# 20) Test funzionale

Questo tipo di test ignora le parti interne e si concentra solo sull'output per verificare se è conforme o meno al requisito. Si tratta di un test di tipo Black-box orientato ai requisiti funzionali di un'applicazione. Per informazioni dettagliate sui test funzionali, fare clic su Qui .

# 21) Test dell'interfaccia utente grafica (GUI)

L'obiettivo di questo test della GUI è convalidare la GUI secondo i requisiti aziendali. La GUI prevista dell'applicazione è menzionata nel documento di progettazione dettagliata e nelle schermate di mockup della GUI.

Il test della GUI include la dimensione dei pulsanti e del campo di input presenti sullo schermo, l'allineamento di tutto il testo, le tabelle e il contenuto nelle tabelle.

Convalida anche il menu dell'applicazione, dopo aver selezionato menu e voci di menu diversi, convalida che la pagina non fluttui e l'allineamento rimane lo stesso dopo aver posizionato il mouse sul menu o sul sottomenu.

# 22) Gorilla Testing

Gorilla Testing è un tipo di test eseguito da un tester e talvolta anche dallo sviluppatore. In Gorilla Testing, un modulo o la funzionalità nel modulo viene testato a fondo e pesantemente. L'obiettivo di questo test è verificare la robustezza dell'applicazione.

# 23) Buon test del percorso

L'obiettivo di Happy Path Testing è testare un'applicazione con successo su un flusso positivo. Non cerca condizioni negative o di errore. L'attenzione si concentra solo sugli input validi e positivi attraverso i quali l'applicazione genera l'output atteso.

# 24) Test di integrazione incrementale

Test di integrazione incrementale è un approccio bottom-up per il test, ovvero il test continuo di un'applicazione quando vengono aggiunte nuove funzionalità. Le funzionalità ei moduli dell'applicazione dovrebbero essere sufficientemente indipendenti da poter essere testati separatamente. Questo viene fatto dai programmatori o dai tester.

# 25) Installa / Disinstalla Test

Test di installazione e disinstallazione viene eseguito su processi di installazione / disinstallazione completi, parziali o di aggiornamento su diversi sistemi operativi in ​​un ambiente hardware o software diverso.

# 26) Test di integrazione

Il test di tutti i moduli integrati per verificare la funzionalità combinata dopo l'integrazione è definito come Test d'integrazione .

I moduli sono tipicamente moduli di codice, singole applicazioni, applicazioni client e server su una rete, ecc. Questo tipo di test è particolarmente rilevante per i sistemi client / server e distribuiti.

# 27) Test di carico

È un tipo di test non funzionale e l'obiettivo del test di carico è verificare la quantità di carico o il carico di lavoro massimo che un sistema può gestire senza alcun degrado delle prestazioni.

Il test di carico aiuta per trovare la capacità massima del sistema sotto carico specifico ed eventuali problemi che causano il degrado delle prestazioni del software. Il test di carico viene eseguito utilizzando strumenti come JMeter , LoadRunner, WebLoad, Silk performer, ecc.

# 28) Monkey Testing

Monkey Testing viene eseguito da un tester assumendo che se la scimmia utilizza l'applicazione, quindi come input casuale, i valori verranno inseriti dalla scimmia senza alcuna conoscenza o comprensione dell'applicazione.

L'obiettivo di Monkey Testing è controllare se un'applicazione o un sistema si arresta in modo anomalo fornendo valori / dati di input casuali. Il Monkey Testing viene eseguito in modo casuale e nessun caso di test è scriptato e non è necessario

Il Monkey Testing viene eseguito in modo casuale e non è stato creato alcun caso di test e non è necessario essere a conoscenza della piena funzionalità del sistema.

# 29) Test di mutazione

Test di mutazione è un tipo di test white box in cui il codice sorgente di uno dei programmi viene modificato e verifica se i casi di test esistenti possono identificare questi difetti nel sistema.

La modifica del codice sorgente del programma è minima in modo che non influisca sull'intera applicazione, solo l'area specifica che ha l'impatto ei relativi casi di test dovrebbero essere in grado di identificare quegli errori nel sistema.

# 30) Test negativo

I tester che hanno la mentalità di 'attitudine alla rottura' e utilizzano il test negativo lo convalidano se il sistema o l'applicazione si rompe. Una tecnica di test negativo viene eseguito utilizzando dati errati, dati non validi o input. Convalida che se il sistema genera un errore di input non valido e si comporta come previsto.

# 31) Test non funzionali

È un tipo di test per il quale ogni organizzazione ha un team separato che di solito viene chiamato team di test non funzionale (NFT) o team di prestazioni.

Test non funzionali implica il test di requisiti non funzionali come il test di carico, lo stress test, la sicurezza, il volume, il test di ripristino, ecc. L'obiettivo del test NFT è garantire se il tempo di risposta del software o dell'applicazione è abbastanza veloce secondo i requisiti aziendali.

Non dovrebbe richiedere molto tempo per caricare qualsiasi pagina o sistema e dovrebbe sostenere durante i picchi di carico.

# 32) Test delle prestazioni

Questo termine è spesso usato in modo intercambiabile con 'stress' e 'carico'. Test delle prestazioni viene eseguito per verificare se il sistema soddisfa i requisiti di prestazione. Per eseguire questo test vengono utilizzati diversi strumenti di prestazioni e caricamento.

# 33) Test di recupero

È un tipo di test che convalida il modo in cui l'applicazione o il sistema si riprendono da arresti anomali o disastri.

Il Recovery Testing determina se il sistema è in grado di continuare l'operazione dopo un disastro. Si supponga che l'applicazione stia ricevendo dati tramite il cavo di rete e che improvvisamente il cavo di rete sia stato scollegato.

Qualche tempo dopo, collega il cavo di rete; quindi il sistema dovrebbe iniziare a ricevere i dati da dove ha perso la connessione a causa del cavo di rete scollegato.

# 34) Test di regressione

Il test di un'applicazione nel suo complesso per la modifica in qualsiasi modulo o funzionalità viene definito test di regressione. È difficile coprire tutto il sistema Test di regressione , così tipicamente Strumenti di test di automazione vengono utilizzati per questi tipi di test.

# 35) Test basato sul rischio (RBT)

Nel Test basati sul rischio , le funzionalità oi requisiti vengono testati in base alla loro priorità. Il test basato sul rischio include il test di funzionalità altamente critiche, che ha il maggiore impatto sul business e in cui la probabilità di guasto è molto alta.

La decisione sulla priorità si basa sulle esigenze aziendali, quindi una volta impostata la priorità per tutte le funzionalità, vengono eseguite prima le funzionalità ad alta priorità oi casi di test, seguiti da funzionalità a priorità media e poi bassa.

La funzionalità a bassa priorità può essere testata o non testata in base al tempo disponibile.

Il test basato sul rischio viene eseguito se non è disponibile tempo sufficiente per testare l'intero software e il software deve essere implementato in tempo senza alcun ritardo. Questo approccio è seguito solo dalla discussione e dall'approvazione del cliente e dell'alta dirigenza dell'organizzazione.

# 36) Test di sanità mentale

Test di sanità mentale viene eseguito per determinare se una nuova versione del software sta funzionando abbastanza bene da accettarla per un importante sforzo di test o meno. Se un'applicazione si arresta in modo anomalo per l'uso iniziale, il sistema non è abbastanza stabile per ulteriori test. Quindi una build o un'applicazione viene assegnata per risolverlo.

# 37) Test di sicurezza

È un tipo di test eseguito da un team speciale di tester. Un sistema può essere penetrato in qualsiasi modo hacker.

Test di sicurezza viene eseguito per verificare in che modo il software, l'applicazione o il sito Web sono protetti da minacce interne ed esterne. Questo test include quanto software è protetto da programmi dannosi, virus e quanto sono sicuri e potenti i processi di autorizzazione e autenticazione.

Controlla anche come si comporta il software per eventuali attacchi di hacker e programmi dannosi e come viene mantenuto il software per la sicurezza dei dati dopo un tale attacco di hacker.

# 38) Test del fumo

Ogni volta che una nuova build viene fornita dal team di sviluppo, il team di test del software convalida la build e garantisce che non esista alcun problema di rilievo.

Il team di test garantisce che la build sia stabile e che venga ulteriormente eseguito un livello dettagliato di test. Test del fumo verifica che nella build non esista alcun difetto show stopper che impedirà al team di test di testare l'applicazione in dettaglio.

Se i tester scoprono che la funzionalità critica principale è scomposta nella fase iniziale stessa, il team di test può rifiutare la build e informare di conseguenza il team di sviluppo. Il test del fumo viene eseguito a un livello dettagliato di qualsiasi test funzionale o di regressione.

# 39) Test statici

Il test statico è un tipo di test che viene eseguito senza alcun codice. L'esecuzione viene eseguita sulla documentazione durante la fase di test.

Comprende revisioni, procedure dettagliate e ispezione dei risultati finali del progetto. Il test statico non esegue il codice al posto della sintassi del codice, vengono controllate le convenzioni di denominazione.

Test statici è applicabile anche per casi di test, piano di test, documento di progettazione. È necessario eseguire test statici da parte del team di test poiché i difetti identificati durante questo tipo di test sono convenienti dal punto di vista del progetto.

# 40) Test di stress

Questo test viene eseguito quando un sistema viene sottoposto a stress oltre le sue specifiche per verificare come e quando fallisce. Questa operazione viene eseguita in condizioni di carico elevato, come l'inserimento di un numero elevato oltre la capacità di archiviazione, query complesse del database, input continuo al sistema o carico del database.

riferimento indefinito al c ++ principale

# 41) Test di sistema

Sotto Tecnica di test del sistema , l'intero sistema viene testato secondo i requisiti. Si tratta di un test di tipo Black-box basato sulle specifiche dei requisiti generali e copre tutte le parti combinate di un sistema.

# 42) Test unitario

Il test di un singolo componente software o modulo è definito come Test unitario . In genere viene eseguito dal programmatore e non dai tester, poiché richiede una conoscenza dettagliata della progettazione e del codice interni del programma. Potrebbe anche richiedere lo sviluppo di moduli driver di test o di test harness.

# 43) Test di usabilità

Sotto Test di usabilità , Il controllo della facilità d'uso è stato eseguito. Il flusso dell'applicazione viene testato per sapere se un nuovo utente può comprendere l'applicazione facilmente o meno, un aiuto adeguato documentato se un utente si blocca in qualsiasi momento. Fondamentalmente, la navigazione del sistema viene controllata in questo test.

# 44) Test di vulnerabilità

Il test che implica l'identificazione di debolezze nel software, nell'hardware e nella rete è noto come Vulnerability Testing. Programmi dannosi, l'hacker può assumere il controllo del sistema, se è vulnerabile a questo tipo di attacchi, virus e worm.

Quindi è necessario verificare se tali sistemi vengono sottoposti a Test di vulnerabilità prima della produzione. Può identificare difetti critici, falle nella sicurezza.

# 45) Test del volume

Test del volume è un tipo di test non funzionale eseguito dal team di test delle prestazioni.

Il software o l'applicazione viene sottoposta a un'enorme quantità di dati e Volume Testing controlla il comportamento del sistema e il tempo di risposta dell'applicazione quando il sistema rileva un volume così elevato di dati. Questo volume elevato di dati può influire sulle prestazioni del sistema e sulla velocità del tempo di elaborazione.

# 46) Test della scatola bianca

Test della scatola bianca si basa sulla conoscenza della logica interna del codice di un'applicazione.

È anche noto come Glass box Testing. Il software interno e il funzionamento del codice dovrebbero essere noti per eseguire questo tipo di test. Questi test si basano sulla copertura di istruzioni di codice, rami, percorsi, condizioni, ecc.

Conclusione

I suddetti tipi di test del software sono solo una parte del test. Tuttavia, esiste ancora un elenco di oltre 100 tipi di test, ma tutti i tipi di test non vengono utilizzati in tutti i tipi di progetti. Quindi ho coperto alcuni tipi comuni di test del software che vengono utilizzati principalmente nel ciclo di vita del test.

Inoltre, esistono definizioni o processi alternativi utilizzati in diverse organizzazioni, ma il concetto di base è lo stesso ovunque. Questi tipi di test, processi e metodi di implementazione continuano a cambiare man mano che il progetto, i requisiti e l'ambito cambiano.

Lettura consigliata

^