Glossario Testing Software per migliorare la qualità del software

Che cos’è il testing software?

In informatica, il testing software è definito come un’attività o un processo per verificare se i risultati effettivi corrispondono ai risultati previsti e per garantire che il sistema software sia privo di difetti. Il test del software consente dunque di identificare errori, bug, malfunzionamenti o requisiti mancanti in contrasto con i requisiti effettivi per lo sviluppo del software al fine di produrre un prodotto di qualità.

Glossario Testing software

accettazione: l’ultima fase del ciclo di vita in cui il prodotto è sottoposto alla valutazione del committente (cfr. collaudo). La valutazione è basata su un insieme di controlli, i controlli di accettazione appunto, che hanno come obiettivo la validazione delle caratteristiche di qua- lità del prodotto rispetto ai suoi requisiti.

affidabilità: la caratteristica di qualità di un prodotto software relativa alla sua capacità di funzionare correttamente nel tempo. Lo standard ISO 9126 la prevede come una caratteristica di qualità primaria, a sua volta decomposta in maturità, tolleranza ai guasti, recuperabilità.

a-test: indica un test o più in generale una serie di controlli (e non necessariamente controlli dinamici) eseguiti su un prodotto software a cura della stessa organizzazione che lo ha svilup- pato. Obiettivo dell’a-test è decidere se è possibile rilasciare, almeno in b-test, un prodotto. In questa prospettiva, i test di sistema propriamente detti fanno parte di un a-test, ma non è detto che un a-test si limiti ai test di sistema.

ambiente di test: è un ambiente controllato che permette il controllo dinamico di un modulo o di un sistema software indipendentemente da fattori esterni che potrebbero influenzarne il comportamento e quindi inquinare i risultati del test (cfr. driver e stub).

anomalia: vedi difetto.

back-to-back: soluzione per la realizzazione di un’oracolo da usare nell’analisi dei risultati dei test. Consiste nel sottoporre allo stesso test due copie funzionalmente identiche di un programma. Le copie possono essere indipendenti, una delle due realizzata in funzione del test o recuperata da librerie esistenti, oppure essere una versione precedente dello stesso programma (cfr. regressione).

b-test: indica un test o più in generale una serie di controlli (e non necessariamente controlli dinamici) eseguiti su un prodotto software da organizzazioni diverse da quella che lo ha sviluppato. Scopo di un b-test è far provare il prodotto da un insieme selezionato di utenti prima di rilasciarlo definitivamente. Il b-test non va confuso con i controlli di accettazione.

big bang: tecnica di integrazione dei moduli che consiste nel provare il sistema software completo immediatamente dopo aver controllato i singoli moduli. In presenza di progettazione, realizzazione e controllo dei moduli eseguiti a regola d’arte, il risultato atteso è il funzionamento corretto del sistema. In realtà questo è un evento spettacolare e insperato e questa tecnica è utilizzabile solamente per sistemi di limitate dimensioni.

black box: un modo per indicare un programma quando se ne vuole considerare la sola specifica funzionale, disinteressandosi alla sua realizzazione. A questa visione dei programmi sono ispirati i criteri funzionali per la progettazione dei test.

bottom-up: vedi top-down.

branch: vedi decisione.

bug: in inglese “cimice”, in americano più generalmente “insetto”, indica la causa di un malfunzionamento in un sistema software; in italiano è spesso tradotto per assonanza con baco. Esistono hardware bug e software bug: la leggenda vuole che il primo bug fosse un hardware bug e, più propriamente, una falena arrostita fra i relé del Mark II di Harvard (che si dice tuttora conservata allo Smithsonian). Con riferimento alla terminologia IEEE un bug è un difetto, ovvero ciò che deve essere rimosso per eliminare un malfunzionamento. Con debugging si intende propriamente la ricerca dei bug effettuata dinamicamente ispezionando lo stato del programma durante una sua esecuzione controllata; in senso più lato debugging è sinonimo di tutta l’attività di controllo del software. Con debugger si identifica uno strumento realizzato appositamente per supportare questo tipo di attività.

cammino: (o path) con riferimento al grafo di flusso, è una successione di nodi che rappresenta uno dei possibili comportamenti del programma in esecuzione. Con path test si indicano quei test progettati per coprire il maggior numero dei cammini possibili sul grafo di flusso.

collaudo: è il controllo definitivo che un prodotto finito rispetti i requisiti del committente. È un controllo effettuato da o per conto del committente e le cui modalità sono normalmente definite nel contratto che regola la commessa (cfr. accettazione).

comando: (o statement) con riferimento al grafo di flusso, è una singola istruzione del programma a cui corrisponde un nodo del grafo; se l’istruzione è di tipo condizionale darà luogo a una decisione. Con statement test si indicano quei test progettati per coprire il maggior numero di comandi sul grafo di flusso.

committente: l’organizzazione che commissiona lo sviluppo di un prodotto software. Non tutta l’industria del software è basata su prodotti commissionati e realizzati in versione unica, anzi: acquista sempre maggiore importanza l’industria del software di massa, realizzato per soddisfare un’utenza generica e venduto in milioni di copie. Tuttavia, anche in questi casi, è sempre possibile identificare il committente nel ruolo svolto dal reparto dell’azienda che studia il mercato e definisce i requisiti del prodotto (cfr. fornitore).

condizione: con riferimento al grafo di flusso di un programma, è una singola condizione booleana usata in un’istruzione condizionale, dalle condizioni dipendono perciò le decisioni.

condition test si indicano quei test progettati per far assumere a ogni condizione del grafo di flusso entrambi i valori di vero e falso.

controllo: la prova a posteriori della qualità di un prodotto, di un servizio o di un processo. Rispetto al rapporto committente/fornitore, si può distinguere fra controllo interno, quando è svolto dal fornitore stesso, e controllo esterno quando invece è svolto da o per conto di un’organizzazione esterna al fornitore. Nel caso di prodotti software è possibile distinguere fra controllo dinamico e controllo statico in base, rispettivamente, alla messa in esecuzione o no del prodotto.

copertura: una misura dell’efficacia di un test; è possibile distinguere fra copertura funzionale, in base alla percentuale di funzionalità del prodotto software esercitate dal test, e copertura strutturale, in base alla percentuale di componenti del grafo di flusso del programma esercitati dal test.

criterio: nella progettazione dei test si distinguono i criteri funzionali (detti anche black- box), basati solo sulla specifica funzionale del software e che quindi mirano a esercitarne soprattutto le funzionalità, e i criteri strutturali (detti anche white-box) che si basano sulla conoscenza della struttura del codice e che hanno l’obiettivo di esercitarlo in tutte le sue parti (cfr. grafo di flusso). Nell’ambito invece della decisione di terminare l’attività di test, possono essere adottati criteri economici basati sull’esaurimento delle risorse destinate ai controlli, criteri qualitativi, basati sul raggiungimento del prefissato grado di qualità del prodotto, e criteri analitici, basati sul confronto fra i costi dell’attività di test e i benefici che se ne ottengono in termini di aumento della qualità del prodotto.

debugger: vedi bug.

debugging: vedi bug.

decisione: (o branch) con riferimento al grafo di flusso di un programma, è una ramificazione nel flusso di controllo tipicamente controllata da un’istruzione condizionale. Con branch test si indicano quei test progettati per esercitare ogni decisione sia in un senso che nell’altro.

desk check: il controllo statico eseguito leggendo il codice e simulando “a mano” l’esecuzio- ne di un programma, spesso mirato all’individuazione di un difetto. È una tecnica che risale ai primordi della programmazione. Sebbene esistano ancora estimatori di questa tecnica, spe- cialmente per l’individuazione di errori algoritmici, essa tende a essere sostituita dall’uso di debugger sempre più sofisticati o da tecniche di controllo statico più formali (cfr. inspection e walkthrough).

difetto: un’imperfezione o una mancanza in un sistema software che può dar luogo a un malfunzionamento. Un difetto quiescente non si manifesta per un lungo periodo perché nascosto in parti del programma raramente utilizzate. Detto anche anomalia (fault nella terminologia dello standard IEEE), in jargon il difetto è il ben noto bug.

driver: in un ambiente di test o nella fase di integrazione di un sistema software, un componente usato per controllare il comportamento di uno o più moduli. Un driver invoca le funzionalità esportate dai moduli letteralmente “pilotando” la loro esecuzione (cfr. stub).

efficienza: la caratteristica di qualità legata alla capacità di un prodotto software di svolgere le proprie funzionalità con un consumo minimo di risorse di calcolo. In generale l’efficienza è considerata relativamente a una particolare risorsa: tempo macchina, occupazione di memoria, occupazione di disco. Lo standard ISO 9126 distingue a questo proposito come sottocaratteri- stiche dell’efficienza l’efficienza nel tempo e l’efficienza delle risorse.

errore: in generale è una deviazione dal comportamento corretto di un sistema software. In una diversa e più precisa accezione (quella definita dalla terminologia IEEE nel corrispondente error), un errore è la causa di un difetto, ovvero una mancanza, di una persona o di uno strumento, che introduce un difetto in un sistema software: ad esempio, la distrazione o la mal comprensione di un algoritmo.

error guessing: vedi previsione degli errori.

esecuzione simbolica: una tecnica a metà fra il controllo dinamico e il controllo statico, il programma viene cioè eseguito ma senza assegnare valori alle sue variabili che, appunto, sono trattate simbolicamente. In teoria, una singola esecuzione simbolica copre tutti i possibili casi di test, ma la tecnica è costosa e poco applicabile a casi industriali.

failure: vedi malfunzionamento.

fault: vedi difetto.

fornitore: l’azienda che sviluppa un prodotto software su commissione. Non sempre, nell’ambito di un progetto software, esiste una effettiva distinzione contrattuale fra com- mittente e fornitore, in molti casi sono questi ruoli svolti da reparti diversi di una stessa azienda.

funzionalità: una particolare funzione o caratteristica di un prodotto software che lo rende abile a soddisfare una parte dei requisiti. In una diversa accezione del termine, la funzionalità è la caratteristica di qualità di un prodotto software relativa alla sua capacità di soddisfare i requisiti.

grafo causa-effetto: rappresentazione delle funzionalità di un programma che descrive i fatti elementari di uscita come risultati di espressioni booleane dei fatti elementari d’ingresso. Può essere usato come strumento di controllo della specifica o come criterio funzionale per la progettazione dei test.

grafo di flusso: rappresentazione schematica di un programma: a ogni nodo è associato un comando mentre gli archi, orientati, rappresentano il legame di sequenzialità fra i comandi. Altri elementi importanti nella struttura di un grafo di flusso sono le decisioni che rappresentano le ramificazioni del grafo e le condizioni che rappresentano le singole espressioni booleane. I grafi di flusso sono usati per la valutazione della complessità ciclomatica di un programma, per la progettazione dei test secondo i criteri strutturali, per la valutazione della copertura strutturale di un test.

gray box: strategia di test che mescola criteri funzionali, criteri strutturali ed error guessing; in pratica, è uno degli approcci più comuni alla progettazione dei test.

guasto: vedi malfunzionamento.

IEEE: (Institute of Electricaland Electronics Engineers, si legge I-triple-E) un’ente internazionale che si occupa di promuovere la ricerca e di redigere e diffondere standard nei campi dell’elettronica e dell’informatica. Riguardo ai temi di ingegneria del software ricordiamo gli standard IEEE Std. 729, un glossario di termini legati a questa disciplina, IEEE Std. 1008, che definisce le attività di un’unità di test, IEEE Std. 829 che definisce lo standard per la documentazione dei test.

inspection: vedi ispezione.

integrazione: attività successiva alla codifica e al controllo dei singoli moduli e che consiste nel verificare se i moduli interagiscono correttamente nel rispetto delle loro interfacce e della specifica funzionale del sistema software. Alla strategia non incrementale di integrazione (cfr. big bang) sono preferibili strategie che integrano i moduli a poco a poco, costruendo il sistema secondo approcci top-down o bottom-up e che, facendo uso di stub e driver alternano passi d’integrazione a passi di test.

ISO: (per “International Organization for Standardization”) è un’organizzazione internazionale che si occupa di definire e diffondere standard in tutti i settori produttivi. ISO 9000 è una serie di standard per la gestione e la garanzia della qualità nei processi di produzione industriali. Fra essi lo standard ISO 9000/3 riguarda in particolare la produzione di software, mentre ISO 9126 definisce un modello di qualità per i prodotti software. ISO 8402 è il glossario dei termini inerenti la qualità e ISO 10011 è lo standard che definisce l’attività di verifica ispettiva.

ispezione: analisi di un documento mirata alla scoperta di difetti ed error, generalmente effettuata sul codice o sui requisiti. L’ispezione ha sempre obiettivi precisi: ad esempio la ricerca di un difetto che provoca un malfunzionamento già noto o la verifica del rispetto degli standard di codifica (cfr. walkthrough).

malfunzionamento: un comportamento di un sistema software diverso da quello atteso e definito dalle specifiche. Per analogia con gli apparati fisici, un malfunzionamento è detto anche guasto o, nella terminologia inglese proposta da IEEE, failure (cfr. errore e difetto). manutenzione: fase del ciclo di vita che ha l’obiettivo di modificare un prodotto software per eliminare difetti, per migliorarne le caratteristiche di qualità, per adattare il prodotto ai cambiamenti dell’ambiente operativo. Normalmente svolta quando se ne presenta l’occasione, si parla di manutenzione adattiva quando ha lo scopo di aggiornare il prodotto software, di manutenzione perfettiva quando vuole migliorarlo, di manutenzione correttiva quando nasce dalla necessità di eliminarne difetti.

modulo: un sottosistema di un sistema software (cfr. architettura). Per la sua genericità, il concetto di modulo è usato sia per definire le singole componenti di un sistema che interagiscono dinamicamente tra loro o, da un punto di vista statico, per descrivere una componente di un programma strutturato in procedure e funzioni. Secondo una visione funzionale, un modulo è esternamente visto come una black box accessibile solo tramite le funzionalità che fornisce al sistema. Un modulo deve essere abbastanza semplice da poter essere realizzato da un solo programmatore.

mutante: un programma in cui sono state introdotte intenzionalmente modifiche che lo rendono non conforme alle specifiche. Il test mutazionale è basato sul confronto dei risultati di test dei mutanti con quelli del programma originale, è usato per localizzare un malfunzionamento o per valutare l’efficacia dei test. In quest’ultimo caso, il mutation score è una misura di quanto un test sia sensibile alle modifiche introdotte nel programma.

oracolo: entità in grado di produrre il risultato corretto dell’esecuzione di un programma

usata per produrre i dati con cui confrontare i risultati dei test.

path: vedi cammino.

portabilità: la caratteristica di qualità che indica la capacità di un prodotto software di essere trasportato da un ambiente a un altro. Si prende in considerazione il problema di convertire il software affinché funzioni su una piattaforma hardware, su un sistema operativo o, più in generale, in un ambiente operativo diverso da quello per cui è stato in origine progettato e realizzato.

previsione degli errori: una “non tecnica” di test che, basata sull’esperienza e sull’intuito di chi la applica, permette di trovare difetti ipotizzando gli errori che ne sono la causa. Molto usata quando i debugger erano una rarità o un lusso, è tuttora molto apprezzata. È sempre, almeno inconsciamente, alla base delle scelte circa il tipo di tecnica di test da adottare.

profilo operazionale: il contesto tipico di utilizzo di un’applicazione, dato dalle ca- ratteristiche dell’ambiente operativo medio e dall’insieme di dati d’ingresso più probabili.

prova formale: una tecnica di controllo statico basata sulla dimostrazione dell’equivalenza fra un programma e la sua specifica funzionale.

qualità: l’insieme delle caratteristiche di un prodotto software che ne influenzano la capacità di soddisfare le specifiche esigenze dichiarate nei requisiti. Molte sono le proposte di razionalizzazione del concetto di qualità tramite la definizione di un modello di qualità che elenchi e definisca le caratteristiche di qualità di cui è importante tenere conto nella valutazione di un prodotto. In inglese indicate genericamente come “ilities”, le caratteristiche di qualità previste, ad esempio, dal modello di qualità descritto dallo standard ISO 9126 sono: funzionalità, affidabilità, usabilità, efficienza, manutenibilità, portabilità. In un contesto aziendale, il sistema qualità è l’insieme delle risorse e delle politiche che un’organizzazione dedica esplicitamente al conseguimento della qualità nei prodotti o nei servizi che essa offre.

regressione: la possibilità che un programma, in seguito a una modifica dovuta a un intervento di manutenzione o a un processo di sviluppo incrementale, peggiori le proprie funzionalità. Il confronto di versioni successive dello stesso programma prende il nome di test di regressione.

sandwich: la strategia per integrazione dei moduli di un sistema software che fonde le strategie top-down e bottom-up; di fatto, la più usata in pratica.

statement: vedi comando.

stub: in un ambiente di test o nella fase di integrazione di un sistema software, un componente che simula il comportamento di uno o più moduli. Uno stub (letteralmente “mozzicone”) è usato per esportare funzionalità (eventualmente semplificate) invocate dai moduli in analisi (cfr. driver).

test: una tecnica di controllo che ha l’obiettivo di rivelare eventuali malfunzionamenti analizzando il comportamento di un programma mentre è eseguito in un ambiente controllato (cfr. ambiente di test) e su insiemi predefiniti di dati di ingresso; il termine inglese test è molto più usato della dizione italiana controllo dinamico. In una differente accezione, con test si identifica il particolare insieme di dati e procedure usati per verificare un programma. Il test è usato come tecnica di controllo durante tutto il processo di sviluppo: è propria di questo contesto infatti la distinzione fra test di modulo, test d’integrazione e test di sistema.

top-down: un modo di affrontare la decomposizione di un problema che prevede di andare da una visione astratta della realtà alle sue entità fisiche, da una descrizione generale a una particolare, da un punto di vista ampio a uno dettagliato. Il termine bottom-up indica il tipo di procedimento inverso. In ingegneria del software esistono tecniche di analisi, di progettazione e di integrazione ispirate sia ai procedimenti top-down che bottom-up.

usabilità: la caratteristica di qualità di un prodotto software relativa alla sua possibilità di essere impiegato produttivamente da una particolare utenza. Lo standard ISO 9126 prevede l’usabiltà come caratteristica di qualità primaria, a sua volta decomposta in comprensibilità, apprendibilità, operabilità.

validazione: l’attività di controllo che risponde alla domanda “stiamo realizzando il prodotto corretto?”, che confronta un risultato dello sviluppo, anche intermedio, con i requisiti iniziali del prodotto.

verifica: l’attività di controllo che risponde alla domanda “stiamo realizzando correttamente il prodotto?”, che mira a scoprire i difetti introdotti durante un passo di lavorazione analizzando due prodotti intermedi successivi o controllando il corretto svolgimento di un’attività di sviluppo (vedi in ispezione, verifica ispettiva).

walkthrough: una tecnica di analisi formale del codice che prevede due fasi: nella prima gli ispettori esaminano il codice simulandone l’esecuzione in assenza del gruppo che l’ha sviluppato, nella seconda fase i due gruppi discutono i problemi individuati. Come l’inspection, il walkthrough, nell’ambito del processo software, è un’attività prevista e documentata, ma ha obiettivi più generali mirando a favorire una collaborazione costruttiva fra i gruppi di sviluppo e di ispezione.

white box: vedi criterio strutturale.