Summaries

Processi di test

Abbiamo due tipi di test che devono testare tutto il sistema:

• Test dei componenti: test dei singoli componenti del programma. Solitamente la responsabilità è dello sviluppatore del componente (tranne a volte per i sistemi critici). I test derivano dall'esperienza dello sviluppatore;
• Test del sistema: collaudo di gruppi di componenti integrati per realizzare un sistema o sottosistema. La responsabilità di un team di test indipendente. I test si basano su una specifica di sistema.

Gli obiettivi dei processi di test sono o per validarlo o per trovare difetti:

• Test di convalida (validation testing): dimostrare allo sviluppatore e al cliente del sistema che il software soddisfa i suoi requisiti. Un test riuscito mostra che il sistema funziona come previsto;
• Test dei difetti (defect testing): scoprire vizi o difetti del software il cui comportamento è scorretto o non conforme alle sue specifiche. Un test di successo è un test che fa funzionare il sistema in modo errato e quindi espone un difetto nel sistema. I test mostrano la presenza e non l'assenza di difetti.

Lo schema di seguito il processo di test del software:

Politiche di test

Solo test approfonditi possono dimostrare che un programma è privo di difetti: tuttavia, è impossibile eseguire test esaustivi.

Le politiche di test definiscono l'approccio da utilizzare nella selezione dei test di sistema:

• Tutte le funzioni a cui si accede tramite i menu devono essere testate;
• Devono essere testate le combinazioni di funzioni a cui si accede attraverso lo stesso menu;
• Laddove è richiesto l'input dell'utente, tutte le funzioni devono essere testate con input corretto e errato.

Test del sistema

Implica l'integrazione di componenti per creare un sistema o un sottosistema.

Può comportare il test di un incremento da consegnare al cliente.

Abbiamo due fasi:

• Test di integrazione: il team di test ha accesso al codice sorgente del sistema. Il sistema viene testato poiché i componenti sono integrati;
• Test di rilascio: il team di test verifica l'intero sistema da consegnare come una scatola nera.

Test d'integrazione

Implica la costruzione di un sistema dai suoi componenti e il test per i problemi che derivano dalle interazioni dei componenti.

Abbiamo due tipi di integrazioni:

• Integrazione dall'alto verso il basso: sviluppa lo scheletro del sistema e popolalo con i componenti;
• Integrazione dal basso: integra i componenti dell'infrastruttura, quindi aggiungi componenti funzionali.

Per semplificare la localizzazione degli errori, i sistemi dovrebbero essere integrati in modo incrementale.

Test di rilascio

È il processo di test di una versione di un sistema che verrà distribuito ai clienti.

L'obiettivo principale è aumentare la fiducia del fornitore che il sistema soddisfi i suoi requisiti.

I test di rilascio sono solitamente black-box o test funzionali.

Test black-box

Un esempio di test black-box è testare se la macchina funziona oppure no senza vedere cosa c'è dentro la macchina: se funziona, allora il test è superato.

Linee guida per i test

Le linee guida per i test sono suggerimenti per il team di test per aiutarli a scegliere i test che riveleranno difetti nel sistema. Alcuni esempi di linee guida:

• Scegliere input che costringano il sistema a generare tutti i messaggi di errore;
• Progettare gli input che causano l'overflow dei buffer;
• Ripetere più volte lo stesso input o la stessa serie di input;
• Forza la generazione di output non validi;
• Forza i risultati del calcolo a essere troppo grandi o troppo piccoli.

Casi d'uso

I casi d'uso possono essere una base per derivare i test per un sistema: aiutano a identificare le operazioni da testare e aiutano a progettare i casi di test richiesti.

Da un diagramma di sequenza associato si possono identificare gli ingressi e le uscite da creare per le prove.

Test delle prestazioni

Parte del test di rilascio può comportare il test delle proprietà emergenti di un sistema, come le prestazioni e l'affidabilità.

I test delle prestazioni di solito comportano la pianificazione di una serie di test in cui il carico aumenta costantemente fino a quando le prestazioni del sistema diventano inaccettabili.

Test dello stress

Esercita il sistema oltre il suo carico massimo di progetto: stressare il sistema spesso fa emergere dei difetti.

I sistemi non dovrebbero fallire in modo catastrofico e lo stress test verifica la perdita inaccettabile di servizi o dati.

Lo stress test è particolarmente rilevante per i sistemi distribuiti che possono presentare un grave degrado quando una rete viene sovraccaricata.

Test dei componenti

Il test del componente o dell'unità è il processo di test dei singoli componenti in isolamento. È un processo di verifica dei difetti.

Le componenti possono essere:

• funzioni o metodi individuali all'interno di un oggetto;
• classi di oggetti con diversi attributi e metodi;
• componenti compositi con interfacce definite utilizzati per accedere alle loro funzionalità.

Progettazione del banco di prova

Coinvolge la progettazione dei casi di test (input e output) utilizzati per testare il sistema.

L'obiettivo della progettazione dei casi di test è creare una serie di test che siano efficaci nella convalida e nel test dei difetti.

Approcci alla progettazione sono:

• test basati sui requisiti;
• test delle partizioni;
• prove strutturali.

Test basati sui requisiti

Un principio generale dell'ingegneria dei requisiti è che i requisiti dovrebbero essere testabili.

Il test basato sui requisiti è una tecnica di test di convalida in cui si considera ogni requisito e si ricava una serie di test per quel requisito.

Test delle partizioni

I dati di input e i risultati di output spesso rientrano in classi diverse in cui tutti i membri di una classe sono correlati.

Ognuna di queste classi è una partizione o dominio di equivalenza in cui il programma si comporta in modo equivalente per ogni membro della classe.

I casi di test dovrebbero essere scelti da ciascuna partizione.

Test del percorso

L'obiettivo del test del percorso è garantire che l'insieme dei casi di test sia tale che ogni percorso del programma venga eseguito almeno una volta.

Il punto di partenza per il test del percorso è un grafico di flusso del programma che mostra i nodi che rappresentano le decisioni del programma e gli archi che rappresentano il flusso di controllo.

Le istruzioni con condizioni sono quindi nodi nel grafo di flusso.

Automazione dei test

Il test è una fase di processo costosa. I banchi di prova forniscono una gamma di strumenti per ridurre il tempo richiesto e i costi totali di prova. Sistemi come Junit supportano l'esecuzione automatica dei test.

La maggior parte degli ambienti di test sono sistemi aperti perché le esigenze di test sono specifiche dell'organizzazione.

A volte sono difficili da integrare con workbench di progettazione e analisi chiusi.