Con questo articolo illustreremo i criteri di copertura basati sul flusso dei dati (dataflow) e che prendono in considerazione il ciclo di vita delle variabili definite all'interno di un programma, in particolar modo delle definizioni e degli usi.

Gli usi possono essere di tipo computazionale (c-use), quando la variabile v è coinvolta nel calcolo di un'altra variabile, e di tipo condizionale (p-use), quando la variabile v è parte di un predicato, che determina il flusso di controllo.

A questo punto possiamo definire il definition clear path (path libero da definizioni) come un percorso che va da un nodo x del GFC a un altro nodo y passando per i nodi n1, n2, ..., nk, dove in nessuno di tali nodi è presente alcuna definizione di v; se nei nodi n1, ... , nk c'è almeno una definizione di v, allora parliamo di definition use path (du-path).

E sulla base del du-path possiamo definire i seguenti criteri di copertura come l'all-du-path: la porzione di GFC selezionato deve eseguire almeno un du-path a partire da ogni definizione e ogni uso. Secondo il criterio all-uses, deve essere eseguito almeno un du-path da ogni definizione a ogni uso.

Altro criterio è l'all-p-uses/some-c-uses, che prevede l'esecuzione di almeno un du-path da ogni definizione a ogni predicate-use; se una definizione non raggiunge nessun p-use, allora va eseguito almeno un du-path dalla definizione a un c-use.

Il criterio all-c-uses/some p-uses prevede l'esecuzione di almeno un du-path da ogni definizione a ogni c-use; se una definizione non raggiunge nessun c-use, allora va eseguito almeno un du-path dalla definizione a un p-use. Il criterio All-c-uses prevede l'esecuzione di almeno un du-path da ogni definizione a ogni suo c-use. Infine i criteri All-p-uses e All-defs prevedono il primo l'esecuzione di almeno un du-path da ogni definizione a ogni suo p-use, il secondo l'esecuzione di un du-path da ogni definizione a un suo uso p-use o c-use.

Concludiamo questo ciclo dedicato al testing strutturale, ricordando che una strategia di testing basata sui path è poco scalabile e che va condotta quando ci si ritrova a fare testing di unità.

• Pubblicazioni correlate:
• 06-04-2011 Linee guida per la progettazione di test case: introduzione
• 11-04-2011 Linee guida per la progettazione di test case: classi di equivalenza e metodi WECT e SECT (1/2)
• 20-04-2011 Linee guida per la progettazione di test case: classi di equivalenza e metodi WECT e SECT (2/2)
• 11-05-2011 Linee guida per la progettazione di test case: testing dei valori al limite
• 18-05-2011 Linee guida per la progettazione di test case: il WCT
• 25-05-2011 Linee guida per la progettazione di test case: ridurre i casi di test (1/3)
• 01-06-2011 Linee guida per la progettazione di test case: ridurre i casi di test (2/3)
• 08-06-2011 Linee guida per la progettazione di test case: ridurre i casi di test (3/3)
• 13-06-2011 Linee guida per la progettazione di test case: concetti base del testing white box
• 20-06-2011 Linee guida per la progettazione di test case: problematiche sulla selezione dei casi di test
• 29-06-2011 Linee guida per la progettazione di test case: la copertura dei percorsi
• 18-07-2011 Linee guida per la progettazione di test case: tecniche basate sulla copertura dei path (1/2)
• 25-07-2011 Linee guida per la progettazione di test case: tecniche basate sulla copertura dei path (2/2)
• 06-09-2011 Linee guida per la progettazione di test case: testing di software object-oriented (1/5)
• 12-09-2011 Linee guida per la progettazione di test case: testing di software object-oriented (2/5)
• 14-09-2011 Linee guida per la progettazione di test case: testing di software object-oriented (3/5)
• 26-09-2011 Linee guida per la progettazione di test case: testing di software object-oriented (4/5)
• 03-10-2011 Linee guida per la progettazione di test case: testing di software object-oriented (5/5)