Test del software - Livelli
Ci sono diversi livelli durante il processo di test. In questo capitolo viene fornita una breve descrizione di questi livelli.
I livelli di test includono diverse metodologie che possono essere utilizzate durante lo svolgimento dei test del software. I principali livelli di test del software sono:
Test funzionali
Test non funzionali
Test funzionali
Questo è un tipo di test black-box basato sulle specifiche del software che deve essere testato. L'applicazione viene testata fornendo input e quindi vengono esaminati i risultati che devono essere conformi alla funzionalità per cui è stata progettata. Il test funzionale di un software viene condotto su un sistema completo e integrato per valutare la conformità del sistema ai requisiti specificati.
Ci sono cinque passaggi coinvolti durante il test di un'applicazione per la funzionalità.
| Passi | Descrizione |
|---|---|
| io | La determinazione della funzionalità che l'applicazione prevista deve eseguire. |
| II | La creazione di dati di test in base alle specifiche dell'applicazione. |
| III | L'output in base ai dati di test e alle specifiche dell'applicazione. |
| IV | La scrittura di scenari di test e l'esecuzione di casi di test. |
| V | Il confronto dei risultati effettivi e previsti in base ai casi di test eseguiti. |
Una pratica di test efficace vedrà i passaggi precedenti applicati alle politiche di test di ogni organizzazione e quindi si assicurerà che l'organizzazione mantenga gli standard più rigorosi quando si tratta di qualità del software.
Test unitario
Questo tipo di test viene eseguito dagli sviluppatori prima che la configurazione venga consegnata al team di test per eseguire formalmente i casi di test. Il test unitario viene eseguito dai rispettivi sviluppatori sulle singole unità di aree assegnate del codice sorgente. Gli sviluppatori utilizzano dati di test diversi dai dati di test del team di controllo qualità.
L'obiettivo del test unitario è isolare ogni parte del programma e mostrare che le singole parti sono corrette in termini di requisiti e funzionalità.
Limitazioni degli unit test
I test non sono in grado di rilevare ogni singolo bug in un'applicazione. È impossibile valutare ogni percorso di esecuzione in ogni applicazione software. Lo stesso è il caso dei test unitari.
Esiste un limite al numero di scenari e dati di test che uno sviluppatore può utilizzare per verificare un codice sorgente. Dopo aver esaurito tutte le opzioni, non resta altra scelta che interrompere il test di unità e unire il segmento di codice con altre unità.
Test d'integrazione
Il test di integrazione è definito come il test di parti combinate di un'applicazione per determinare se funzionano correttamente. Il test di integrazione può essere eseguito in due modi: test di integrazione bottom-up e test di integrazione top-down.
| Sr.No. | Metodo di test di integrazione |
|---|---|
| 1 | Bottom-up integration Questo test inizia con il test di unità, seguito da test di combinazioni di unità di livello progressivamente più alto chiamate moduli o build. |
| 2 | Top-down integration In questo test, i moduli di livello più alto vengono testati per primi e progressivamente, i moduli di livello inferiore vengono testati successivamente. |
In un ambiente di sviluppo software completo, il test bottom-up viene solitamente eseguito per primo, seguito da test top-down. Il processo si conclude con più test dell'applicazione completa, preferibilmente in scenari progettati per imitare situazioni reali.
Test di sistema
Il test del sistema verifica il sistema nel suo complesso. Una volta integrati tutti i componenti, l'applicazione nel suo complesso viene testata rigorosamente per verificare che soddisfi gli standard di qualità specificati. Questo tipo di test viene eseguito da un team di test specializzato.
Il test del sistema è importante per i seguenti motivi:
Il test del sistema è il primo passo nel ciclo di vita dello sviluppo del software, in cui l'applicazione viene testata nel suo insieme.
L'applicazione viene testata accuratamente per verificare che soddisfi le specifiche funzionali e tecniche.
L'applicazione viene testata in un ambiente molto vicino all'ambiente di produzione in cui verrà distribuita l'applicazione.
I test di sistema ci consentono di testare, verificare e convalidare sia i requisiti aziendali che l'architettura dell'applicazione.
Test di regressione
Ogni volta che viene apportata una modifica a un'applicazione software, è del tutto possibile che altre aree all'interno dell'applicazione siano state influenzate da questa modifica. Il test di regressione viene eseguito per verificare che un bug corretto non abbia comportato un'altra funzionalità o una violazione delle regole aziendali. Lo scopo del test di regressione è garantire che una modifica, ad esempio una correzione di bug, non comporti la scoperta di un altro errore nell'applicazione.
Il test di regressione è importante per i seguenti motivi:
Ridurre al minimo le lacune nei test quando un'applicazione con modifiche apportate deve essere testata.
Testare le nuove modifiche per verificare che le modifiche apportate non abbiano influito su nessun'altra area dell'applicazione.
Riduce i rischi quando viene eseguito il test di regressione sull'applicazione.
La copertura dei test è aumentata senza compromettere le tempistiche.
Aumenta la velocità di commercializzazione del prodotto.
Test di accettazione
Questo è probabilmente il tipo di test più importante, poiché viene condotto dal team di garanzia della qualità che valuterà se l'applicazione soddisfa le specifiche previste e soddisfa i requisiti del cliente. Il team QA disporrà di una serie di scenari pre-scritti e casi di test che verranno utilizzati per testare l'applicazione.
Verranno condivise più idee sull'applicazione e più test potranno essere eseguiti su di essa per valutarne l'accuratezza e le ragioni per cui il progetto è stato avviato. I test di accettazione non hanno solo lo scopo di evidenziare semplici errori di ortografia, errori estetici o lacune dell'interfaccia, ma anche di evidenziare eventuali bug nell'applicazione che provocheranno arresti anomali del sistema o errori importanti nell'applicazione.
Eseguendo i test di accettazione su un'applicazione, il team di test ridurrà le prestazioni dell'applicazione in produzione. Esistono anche requisiti legali e contrattuali per l'accettazione del sistema.
Alpha Testing
Questo test è la prima fase del test e verrà eseguito tra i team (team di sviluppatori e QA). Il test unitario, il test di integrazione e il test di sistema quando combinati insieme sono noti come test alpha. Durante questa fase, nell'applicazione verranno testati i seguenti aspetti:
Errori di ortografia
Collegamenti interrotti
Indicazioni nuvolose
L'applicazione verrà testata su macchine con le specifiche più basse per testare i tempi di caricamento e gli eventuali problemi di latenza.
Beta test
Questo test viene eseguito dopo che il test alfa è stato eseguito con successo. In beta testing, un campione del pubblico previsto testa l'applicazione. Il beta test è anche noto comepre-release testing. Le versioni beta test del software sono idealmente distribuite a un vasto pubblico sul Web, in parte per fornire al programma un test "reale" e in parte per fornire un'anteprima del prossimo rilascio. In questa fase, il pubblico testerà quanto segue:
Gli utenti installeranno, eseguiranno l'applicazione e invieranno il loro feedback al team di progetto.
Errori tipografici, flusso di applicazioni confuso e persino arresti anomali.
Ottenendo il feedback, il team di progetto può risolvere i problemi prima di rilasciare il software agli utenti effettivi.
Più problemi risolverai che risolvono i problemi reali degli utenti, maggiore sarà la qualità della tua applicazione.
Avere un'applicazione di qualità superiore quando la rilasci al pubblico aumenterà la soddisfazione del cliente.
Test non funzionali
Questa sezione si basa sul test di un'applicazione dai suoi attributi non funzionali. Il test non funzionale implica il test di un software in base ai requisiti che sono di natura non funzionale ma importanti come prestazioni, sicurezza, interfaccia utente, ecc.
Alcuni dei tipi di test non funzionali importanti e comunemente usati sono discussi di seguito.
Test delle prestazioni
Viene utilizzato principalmente per identificare eventuali colli di bottiglia o problemi di prestazioni piuttosto che trovare bug in un software. Esistono diverse cause che contribuiscono a ridurre le prestazioni di un software:
Ritardo di rete
Elaborazione lato client
Elaborazione delle transazioni del database
Bilanciamento del carico tra i server
Rendering dei dati
Il test delle prestazioni è considerato uno dei tipi di test importanti e obbligatori in termini di seguenti aspetti:
Velocità (ovvero tempo di risposta, rendering dei dati e accesso)
Capacity
Stability
Scalability
Il test delle prestazioni può essere qualitativo o quantitativo e può essere suddiviso in diversi sottotipi come Load testing e Stress testing.
Test di carico
È un processo di verifica del comportamento di un software applicando il carico massimo in termini di accesso al software e manipolazione di dati di input di grandi dimensioni. Può essere eseguito sia in condizioni di carico normali che di picco. Questo tipo di test identifica la capacità massima del software e il suo comportamento nelle ore di punta.
La maggior parte delle volte, il test di carico viene eseguito con l'aiuto di strumenti automatizzati come Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, ecc.
Gli utenti virtuali (VUser) vengono definiti nello strumento di test automatizzato e lo script viene eseguito per verificare il test di carico per il software. Il numero di utenti può essere aumentato o diminuito contemporaneamente o in modo incrementale in base ai requisiti.
Stress Testing
Lo stress test include il test del comportamento di un software in condizioni anomale. Ad esempio, può includere la rimozione di alcune risorse o l'applicazione di un carico oltre il limite di carico effettivo.
Lo scopo dello stress test è testare il software applicando il carico al sistema e assumendo le risorse utilizzate dal software per identificare il punto di rottura. Questo test può essere eseguito testando diversi scenari come:
Arresto o riavvio delle porte di rete in modo casuale
Attivazione o disattivazione del database
Esecuzione di diversi processi che consumano risorse come CPU, memoria, server, ecc.
Test di usabilità
Il test di usabilità è una tecnica black-box e viene utilizzato per identificare eventuali errori e miglioramenti nel software osservando gli utenti attraverso il loro utilizzo e funzionamento.
Secondo Nielsen, l'usabilità può essere definita in termini di cinque fattori, ovvero efficienza d'uso, capacità di apprendimento, capacità di memoria, errori / sicurezza e soddisfazione. Secondo lui, l'usabilità di un prodotto sarà buona e il sistema è utilizzabile se possiede i fattori di cui sopra.
Nigel Bevan e Macleod hanno considerato che l'usabilità è il requisito di qualità che può essere misurato come il risultato delle interazioni con un sistema informatico. Questo requisito può essere soddisfatto e l'utente finale sarà soddisfatto se gli obiettivi prefissati vengono raggiunti efficacemente con l'uso di risorse adeguate.
Molich nel 2000 ha affermato che un sistema di facile utilizzo dovrebbe soddisfare i seguenti cinque obiettivi, ovvero facile da imparare, facile da ricordare, efficiente da usare, soddisfacente da usare e facile da capire.
Oltre alle diverse definizioni di usabilità, ci sono alcuni standard e modelli e metodi di qualità che definiscono l'usabilità sotto forma di attributi e sotto-attributi come ISO-9126, ISO-9241-11, ISO-13407 e IEEE std. 610.12, ecc.
UI vs test di usabilità
Il test dell'interfaccia utente implica il test dell'interfaccia utente grafica del software. Il test dell'interfaccia utente garantisce che la GUI funzioni in base ai requisiti e testata in termini di colore, allineamento, dimensioni e altre proprietà.
D'altra parte, i test di usabilità garantiscono una buona e intuitiva GUI che può essere facilmente gestita. Il test dell'interfaccia utente può essere considerato come una sottoparte del test di usabilità.
Test di sicurezza
Il test di sicurezza implica il test di un software al fine di identificare eventuali difetti e lacune dal punto di vista della sicurezza e della vulnerabilità. Di seguito sono elencati gli aspetti principali che i test di sicurezza dovrebbero garantire:
Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Il software è protetto da vulnerabilità note e sconosciute
I dati del software sono protetti
Il software è conforme a tutte le normative di sicurezza
Controllo e convalida degli input
Attacchi di inserimento SQL
Difetti di iniezione
Problemi di gestione delle sessioni
Attacchi di cross-site scripting
Il buffer supera le vulnerabilità
Attacchi di attraversamento delle directory
Test di portabilità
Il test di portabilità include il test di un software con l'obiettivo di garantirne il riutilizzo e che possa essere spostato anche da un altro software. Di seguito sono riportate le strategie che possono essere utilizzate per i test di portabilità:
Trasferimento di un software installato da un computer a un altro.
Creazione di eseguibili (.exe) per eseguire il software su piattaforme diverse.
Il test di portabilità può essere considerato come una delle sottoparti del test di sistema, poiché questo tipo di test include il test generale di un software rispetto al suo utilizzo in ambienti diversi. L'hardware del computer, i sistemi operativi e i browser sono l'obiettivo principale dei test di portabilità. Alcune delle condizioni preliminari per i test di portabilità sono le seguenti:
Il software deve essere progettato e codificato, tenendo presente i requisiti di portabilità.
Il test unitario è stato eseguito sui componenti associati.
È stato eseguito il test di integrazione.
È stato stabilito l'ambiente di test.