Panoramica sui test del software

Il test del software è la valutazione del software rispetto ai requisiti raccolti dagli utenti e alle specifiche del sistema. Il test viene condotto a livello di fase nel ciclo di vita dello sviluppo del software oa livello di modulo nel codice del programma. Il test del software comprende la convalida e la verifica.

Validazione del software

La convalida è il processo di esame se il software soddisfa o meno i requisiti dell'utente. Viene eseguito alla fine dell'SDLC. Se il software corrisponde ai requisiti per cui è stato creato, viene convalidato.

  • La convalida garantisce che il prodotto in fase di sviluppo sia conforme ai requisiti dell'utente.
  • La convalida risponde alla domanda: "Stiamo sviluppando il prodotto che tenta tutto ciò di cui l'utente ha bisogno da questo software?".
  • La convalida sottolinea i requisiti degli utenti.

Verifica del software

La verifica è il processo per confermare se il software soddisfa i requisiti aziendali ed è sviluppato aderendo alle specifiche e alle metodologie appropriate.

  • La verifica garantisce che il prodotto in fase di sviluppo sia conforme alle specifiche di progettazione.
  • La verifica risponde alla domanda: "Stiamo sviluppando questo prodotto seguendo saldamente tutte le specifiche di progettazione?"
  • Le verifiche si concentrano sulla progettazione e sulle specifiche del sistema.

Obiettivo del test sono:

  • Errors- Questi sono errori di codifica effettivi commessi dagli sviluppatori. Inoltre, c'è una differenza nell'output del software e l'output desiderato è considerato un errore.

  • Fault- Quando esiste un errore, si verifica un guasto. Un errore, noto anche come bug, è il risultato di un errore che può causare il malfunzionamento del sistema.

  • Failure - si dice che il fallimento è l'incapacità del sistema di eseguire l'attività desiderata. Il guasto si verifica quando esiste un guasto nel sistema.

Test manuale vs automatizzato

Il test può essere eseguito manualmente o utilizzando uno strumento di test automatizzato:

  • Manual- Questo test viene eseguito senza l'ausilio di strumenti di test automatizzati. Il tester software prepara casi di test per diverse sezioni e livelli del codice, esegue i test e riporta il risultato al manager.

    Il test manuale richiede tempo e risorse. Il tester deve confermare se vengono utilizzati o meno casi di test corretti. La maggior parte dei test comporta test manuali.

  • AutomatedQuesto test è una procedura di test eseguita con l'ausilio di strumenti di test automatizzati. I limiti del test manuale possono essere superati utilizzando strumenti di test automatizzati.

Un test deve verificare se una pagina Web può essere aperta in Internet Explorer. Questo può essere fatto facilmente con il test manuale. Ma per verificare se il server web può sopportare il carico di 1 milione di utenti, è del tutto impossibile testarlo manualmente.

Esistono strumenti software e hardware che aiutano i tester a condurre test di carico, stress test, test di regressione.

Approcci alla verifica

I test possono essere condotti sulla base di due approcci:

  • Test di funzionalità
  • Test di implementazione

Quando la funzionalità viene testata senza prendere in considerazione l'implementazione effettiva, è noto come test della scatola nera. L'altro lato è noto come test white-box in cui non viene testata solo la funzionalità, ma viene anche analizzato il modo in cui viene implementata.

I test approfonditi sono il metodo migliore per un test perfetto. Viene testato ogni singolo valore possibile nell'intervallo dei valori di ingresso e di uscita. Non è possibile testare ogni valore nello scenario del mondo reale se l'intervallo di valori è ampio.

Test in scatola nera

Viene eseguito per testare la funzionalità del programma. È anche chiamato test "comportamentale". Il tester in questo caso, ha una serie di valori di input e rispettivi risultati desiderati. Quando si fornisce l'input, se l'output corrisponde ai risultati desiderati, il programma viene testato "ok" e problematico in caso contrario.

In questo metodo di test, il design e la struttura del codice non sono noti al tester e gli ingegneri di test e gli utenti finali conducono questo test sul software.

Tecniche di test black-box:

  • Equivalence class- L'input è suddiviso in classi simili. Se un elemento di una classe supera il test, si presume che tutta la classe sia passata.

  • Boundary values- L'input è diviso in valori finali superiore e inferiore. Se questi valori superano il test, si presume che anche tutti i valori intermedi possano passare.

  • Cause-effect graphing- In entrambi i metodi precedenti, viene testato un solo valore di input alla volta. Causa (input) - Effetto (output) è una tecnica di test in cui le combinazioni di valori di input vengono testate in modo sistematico.

  • Pair-wise Testing- Il comportamento del software dipende da più parametri. Nel test a coppie, i parametri multipli vengono testati a coppie per i loro diversi valori.

  • State-based testing- Il sistema cambia stato quando viene fornito l'input. Questi sistemi vengono testati in base ai loro stati e input.

Test white-box

Viene condotto per testare il programma e la sua implementazione, al fine di migliorare l'efficienza o la struttura del codice. È anche noto come test "strutturale".

In questo metodo di prova, il tester conosce il design e la struttura del codice. I programmatori del codice conducono questo test sul codice.

Di seguito sono riportate alcune tecniche di test White-box:

  • Control-flow testing- Lo scopo del test del flusso di controllo per impostare casi di test che coprano tutte le istruzioni e le condizioni del ramo. Le condizioni del ramo vengono testate sia per essere vere che per false, in modo che tutte le affermazioni possano essere coperte.

  • Data-flow testing- Questa tecnica di test punta a coprire tutte le variabili di dati incluse nel programma. Verifica dove sono state dichiarate e definite le variabili e dove sono state utilizzate o modificate.

Livelli di prova

Il test stesso può essere definito a vari livelli di SDLC. Il processo di test viene eseguito parallelamente allo sviluppo del software. Prima di passare alla fase successiva, una fase viene testata, convalidata e verificata.

Il test separatamente viene eseguito solo per assicurarsi che non siano presenti bug o problemi nascosti nel software. Il software è testato a vari livelli:

Test unitario

Durante la codifica, il programmatore esegue alcuni test su quell'unità di programma per sapere se è esente da errori. Il test viene eseguito con un approccio di test white-box. I test unitari aiutano gli sviluppatori a decidere che le singole unità del programma funzionano secondo i requisiti e sono prive di errori.

Test d'integrazione

Anche se le unità del software funzionano bene individualmente, è necessario scoprire se le unità, se integrate insieme, funzionerebbero anche senza errori. Ad esempio, passaggio di argomenti e aggiornamento dei dati, ecc.

Test di sistema

Il software viene compilato come prodotto e quindi testato nel suo insieme. Questa operazione può essere eseguita utilizzando uno o più dei seguenti test:

  • Functionality testing - Verifica tutte le funzionalità del software rispetto ai requisiti.

  • Performance testing- Questo test dimostra quanto sia efficiente il software. Verifica l'efficacia e il tempo medio impiegato dal software per eseguire l'attività desiderata. Il test delle prestazioni viene eseguito mediante test di carico e stress test in cui il software viene sottoposto a un carico elevato di utenti e dati in varie condizioni ambientali.

  • Security & Portability - Questi test vengono eseguiti quando il software deve funzionare su varie piattaforme e vi si accede in base al numero di persone.

Test di accettazione

Quando il software è pronto per essere consegnato al cliente, deve passare attraverso l'ultima fase di test in cui viene testato per l'interazione e la risposta dell'utente. Questo è importante perché anche se il software soddisfa tutti i requisiti dell'utente e se all'utente non piace il modo in cui appare o funziona, potrebbe essere rifiutato.

  • Alpha testing- Il team di sviluppatori stesso esegue i test alpha utilizzando il sistema come se fosse utilizzato nell'ambiente di lavoro. Cercano di scoprire come reagirebbe l'utente a un'azione nel software e come il sistema dovrebbe rispondere agli input.

  • Beta testing- Dopo che il software è stato testato internamente, viene consegnato agli utenti per utilizzarlo nel loro ambiente di produzione solo a scopo di test. Questo non è ancora il prodotto consegnato. Gli sviluppatori si aspettano che gli utenti in questa fase porteranno piccoli problemi, che sono stati ignorati per partecipare.

Test di regressione

Ogni volta che un prodotto software viene aggiornato con un nuovo codice, caratteristica o funzionalità, viene testato accuratamente per rilevare se c'è un impatto negativo del codice aggiunto. Questo è noto come test di regressione.

Documentazione di test

I documenti di prova vengono preparati in diverse fasi:

Prima del test

Il test inizia con la generazione dei casi di test. I seguenti documenti sono necessari per riferimento:

  • SRS document - Documento Requisiti Funzionali

  • Test Policy document - Descrive la durata del test prima di rilasciare il prodotto.

  • Test Strategy document - Questo menziona gli aspetti dettagliati del team di test, la matrice di responsabilità e i diritti / responsabilità del responsabile del test e dell'ingegnere del test.

  • Traceability Matrix document- Questo è un documento SDLC, che è correlato al processo di raccolta dei requisiti. Man mano che arrivano nuovi requisiti, vengono aggiunti a questa matrice. Queste matrici aiutano i tester a conoscere la fonte del requisito. Possono essere tracciati avanti e indietro.

Durante il test

I seguenti documenti possono essere richiesti durante l'avvio e l'esecuzione del test:

  • Test Case document- Questo documento contiene l'elenco dei test che devono essere condotti. Include un piano di test unitario, un piano di test di integrazione, un piano di test di sistema e un piano di test di accettazione.

  • Test description - Questo documento è una descrizione dettagliata di tutti i casi di test e delle procedure per eseguirli.

  • Test case report - Questo documento contiene il rapporto del caso di test come risultato del test.

  • Test logs - Questo documento contiene i registri dei test per ogni rapporto sui casi di test.

Dopo il test

I seguenti documenti possono essere generati dopo il test:

  • Test summary- Questo riepilogo del test è un'analisi collettiva di tutti i rapporti e registri dei test. Riassume e conclude se il software è pronto per essere lanciato. Il software viene rilasciato sotto il sistema di controllo della versione se è pronto per il lancio.

Test vs controllo di qualità, garanzia di qualità e audit

Dobbiamo capire che il test del software è diverso dalla garanzia della qualità del software, dal controllo della qualità del software e dall'audit del software.

  • Software quality assurance- Si tratta di mezzi di monitoraggio del processo di sviluppo del software, attraverso i quali si garantisce che tutte le misure siano prese secondo gli standard di organizzazione. Questo monitoraggio viene eseguito per assicurarsi che siano stati seguiti i metodi di sviluppo del software appropriati.

  • Software quality control- Questo è un sistema per mantenere la qualità del prodotto software. Può includere aspetti funzionali e non funzionali del prodotto software, che migliorano la buona volontà dell'organizzazione. Questo sistema garantisce che il cliente riceva un prodotto di qualità per le sue esigenze e il prodotto certificato come "idoneo all'uso".

  • Software audit- Questa è una revisione della procedura utilizzata dall'organizzazione per sviluppare il software. Un team di revisori, indipendente dal team di sviluppo, esamina il processo, la procedura, i requisiti e altri aspetti del software SDLC. Lo scopo dell'audit del software è verificare che il software e il suo processo di sviluppo siano conformi a standard, regole e regolamenti.