Linea guida: Analisi della classe di equivalenza
L'analisi della classe di equivalenza è una tecnica che consente di ridurre il numero degli scenari di test. Questa linea guida descrive questa tecnica e le modalità di utilizzo.
Relazioni
Descrizione principale

Introduzione

Ad eccezione delle applicazioni software meno importanti, è generalmente considerato impossibile eseguire il test di tutte le combinazioni di input logicamente realizzabili per un sistema software. Pertanto, la scelta di un buon sottoinsieme che abbia la probabilità più alta di trovare gran parte degli errori è un'importante e utile attività per i tester da intraprendere.

La verifica basata sull'analisi della classe di equivalenza (sinonimi: partizionamento di equivalenza, analisi di dominio) è una forma di analisi di test a scatola nera che tenta di ridurre il numero totale di potenziali test ad una minima serie che rileverà quanti più errori possibili [MYE79]. E' un metodo che esegue la partizione della serie di input e output in un numero limitato di classi di equivalenza che abilitano la selezione di un valore di test rappresentativo per ciascuna classe. Il test risultante dal valore rappresentativo di una classe viene definito "equivalente" agli altri valori nella stessa classe. Se non è stato trovato alcun errore nel test del valore rappresentativo, è ragionevole pensare che tutti gli altri valori "equivalenti" non identificheranno altri errori.

L'efficacia delle classi di equivalenza risiede nella loro capacità di guidare il tester utilizzando una strategia di prova che consente di ridurre la moltitudine di combinazioni dei potenziali test richiesti. La tecnica fornisce una base logica con cui un sottoinsieme del numero totale concepibile di test può essere selezionato. Di seguito sono riportate alcune categorie di aree di problemi per un numero elevato di test che possono trarre beneficio dalla valutazione delle classi di equivalenza:

  1. Combinazioni di variabili indipendenti
  2. Variabili dipendenti basati sulla relazione gerarchica
  3. Variabili dipendenti basati sulla relazione temporale
  4. Relazioni raggruppate in base agli esemplari di mercato
  5. Relazioni complesse che possono essere modellate

Strategie

Esistono diverse strategie e tecniche utilizzabili nella verifica della partizione di equivalenza. Eccone alcuni esempi:

Partizione della classe di equivalenza

La teoria della partizione di equivalenza come proposta da Glenford Myers [MYE79]. tenta di ridurre il numero totale di scenari di test necessari mediante partizione delle condizioni di input in un numero limitato di classi di equivalenza. Sono classificati due tipi di classi di equivalenza: la serie di input validi per il programma è considerata come la classe di equivalenza valida e tutti gli altri input sono inclusi nella classe di equivalenza non valida.

Di seguito è riportata una serie di linee guida per identificare le classi di equivalenza:

  1. Se una condizione di input specifica un intervallo di valori (quale il programma "accetta valori da 10 a 100"), vengono identificate una classe di equivalenza valida (da 10 a 100) e due classi di equivalenza non valide (meno di 10 e maggiore di 100).
  2. Se una condizione di input specifica una serie di valori (quale "il tessuto può essere di molti colori: ROSSO, BIANCO, NERO, VERDE, MARRONE "), vengono identificate una classe di equivalenza valida (i valori validi) e una classe di equivalenza non valida (tutti gli altri valori non validi). Ciascun valore della classe di equivalenza valida deve essere gestito distintamente.
  3. Se la condizione di input è specificata come una situazione "deve essere" (quale "la stringa di input deve essere in maiuscolo"), vengono identificate una classe di equivalenza valida (caratteri maiuscoli) e una classe di equivalenza non valida (tutti gli altri input ad eccezione dei caratteri in maiuscolo).
  4. Ogni cosa è terminata "molto" prima che l'attività sia stata eseguita in una classe di equivalenza. Ogni cosa completata in un breve intervallo di tempo prima che sia terminato il programma è un'altra classe. Ogni cosa completata appena prima che il programma avvii un'altra operazione è un'altra classe.
  5. Se un programma è specificato per funzionare con una dimensione di memoria da 64M a 256M. Questo intervallo di dimensioni è una classe di equivalenza. Una qualsiasi altra dimensione di memoria, maggiore di 256M o inferiore a 64M, può essere accettata.
  6. La partizione dell'evento di output risiede negli input del programma. Anche se diverse classi di equivalenza di input possono avere lo stesso tipo di evento di output, occorre tuttavia gestire le classi di equivalenza di input distintamente.

Analisi dei valori di delimitazione

In ciascuna delle classi di equivalenza, le condizioni di delimitazione hanno un maggiore tasso di successo nell'identificare gli errori risultanti rispetto alle condizioni senza delimitazione. Le condizioni di delimitazione sono i valori immediatamente al di sopra o al di sotto i limiti o le "estremità" di ciascuna classe di equivalenza.

I test effettuati da condizioni di delimitazione fanno uso di valori al minimo (min), appena al di sopra del minimo (min+), appena al di sotto del massimo (max-) e al massimo (max) dell'intervallo da verificare. Quando vengono verificati i valori di delimitazione, i tester scelgono alcuni scenari di test per ciascuna classe di equivalenza. Per un campione relativamente piccolo di test la probabilità di rilevamento dell'errore è alta. Il tester è alquanto confortato dalle difficoltà di verifica di un'enorme quantità di casi in una classe di equivalenza di valori che in modo improbabile produce elevate differenze nei risultati di verifica.

Di seguito sono riportati alcuni consigli nella scelta dei valori di delimitazione:

  1. Per una variabile mobile, se la condizione valida è da -1.0 a 1.0, eseguire il test di -1.0, 1.0, -1.001 e 1.001.
  2. Per un numero intero, se l'intervallo valido dell'input va da 10 a 100, eseguire il test di 9, 10, 100, 101.
  3. Se un programma attende una lettera maiuscola, eseguire il test delle estremità A e Z. Eseguire il test di @ e [, poiché nel codice ASCII, @ è appena sotto A e [ è appena oltre Z.
  4. Se l'input o l'output di un programma è una serie ordinata, prestare attenzione al primo e l'ultimo elemento della serie.
  5. Se il totale degli input deve essere un numero specifico (n), eseguire il test del programma dove il totale è n-1, n o n+1.
  6. Se il programma accetta un elenco, eseguire il test dei valori nell'elenco. Tutti gli altri valori non sono validi.
  7. Quando si legge o si scrive in un file, controllare il primo e l'ultimo dei caratteri del file.
  8. Il taglio più piccolo del denaro è un centesimo o equivalente. Se il programma accetta uno specifico intervallo, da a a b, eseguire il test di a -0.01 e b +0.01.
  9. Per una variabile con più intervalli, ciascun intervallo è una classe di equivalenza. Se gli intervalli secondari non sono sovrapposti, eseguire il test dei valori su quelli limiti, oltre il limite superiore e sotto il limite inferiore.

>Valori speciali

Dopo avere tentato le due precedenti strategie di analisi dei limiti, un tester di esperienza controllerà gli input del programma per individuare eventuali casi di "valore speciale", che sono ancora sorgenti virtualmente ricche per la rilevazione degli errori del software. Eccone alcuni esempi:

  1. Per un numero intero, zero deve essere sempre verificato se si trova nella classe di equivalenza valida.
  2. Durante la verifica dell'orario (ora, minuto e secondo), 59 e 0 devono essere sempre verificati come il limite superiore e inferiore per ciascun campo, indipendentemente dal vincolo che abbia la variabile di input. Quindi, ad eccezione dei valori limite dell'input, -1, 0, 59 e 60 devono essere sempre degli scenari di test.
  3. Durante la verifica della data (anno, mese e giorno), diversi scenari di test, come il numero di giorni in uno specifico mese, il numero di giorni in febbraio nel mese bisestile, il numero di giorni nell'anno non bisestile, devono essere presi in considerazione.

Metodo "Partizione-Categoria"

Ostrand e Balcer [16] hanno sviluppato un metodo di partizione che aiuta i tester ad analizzare le specifiche del sistema, scrivere gli script di test e gestirli. A differenze delle strategie comuni che si concentrano maggiormente sul codice, il loro metodo è basato anche sulle informazioni di progettazione e sulle specifiche.

Il principale vantaggio di questo metodo è la capacità di esporre gli errori prima che il codice sia stato scritto poiché la sorgente di input è la specifica ed i test sono il risultato dell'analisi di quella specifica. Gli errori nelle specifiche saranno individuati in anticipo, molto spesso prima che venga implementato il codice.

La strategia per il metodo "partizione-categoria" è riportata di seguito:

  1. Analizzare la specifica: scomporre la funzionalità del sistema in unità funzionali, che possono essere verificate in modo indipendente sia dalla specifica che dall'implementazione.
    A questo punto;

    1. Identificare i parametri e le condizioni d'ambiente che influiranno l'esecuzione della funzione. I parametri sono gli input dell'unità di funzione. Le condizioni d'ambiente sono gli stati del sistema che avranno effetto sull'esecuzione dell'unità di funzione.
    2. Identificare le caratteristiche dei parametri e delle condizioni d'ambiente.
    3. Classificare le caratteristiche in categorie, che avranno effetto sulla funzionalità del sistema.

    Le descrizioni ambigue, contraddittorie e mancanti della funzionalità saranno individuate in questa fase.

  2. Eseguire la partizione delle categorie in scelte: le scelte sono le diverse situazioni possibili che potrebbero verificarsi e non essere previste. Esse rappresentano lo stesso tipo di informazioni in una categoria.

  3. Stabilire le relazioni ed i vincoli tra le scelte. Le scelte nelle diverse categorie possono subire tra esse delle influenze, che esercitano tuttavia anche un influsso sulla realizzazione della suite di test. I vincoli vengono aggiunti per eliminare la contraddizione tra le scelte di diversi parametri ed ambienti.

  4. Progettare gli scenari di test in base alle informazioni sulle categorie, sulle scelte e sui vincoli. Se una scelta provoca un errore, non eseguirne una combinazione con altre scelte per creare lo scenario di test. Se una scelta può essere "adeguatamente" verificata da un test singolo, si tratta del rappresentante della scelta oppure di un valore speciale.

Letture e riferimenti aggiuntivi

  1. Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
  2. White L. J. e Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software Engineering, Vol. SE-6, No. 3, 1980.
  3. Lori A. Clarke, Johnhette Hassell e Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on Software Engineering, 8-4, 1992.
  4. Steven J. Zeil, Faten H. Afifi e Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction on Software Engineering and Methodology, 1-4, 1992.
  5. BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering and Methodology, 3-3, 1994.
  6. Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
  7. Martin R. Woodward e Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal triangle, ACM Press New York, NY, 2000.
  8. Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software Engineering, 71-16, 2000.
  9. Cem Kaner, James Bach e Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New York, 2002.
  10. Andy Podgurski e Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special Interest Group on Software Engineering, 18-5, 1993.
  11. Debra J. Richardson e Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM Special Interest Group on Software Engineering, 1981.
  12. Lori A. Clarke, Johnette Hassell e Debra J Richardson, A system to generate test data and symbolically execute programs, IEEE Transaction on Software Engineering, SE-2, 1976.
  13. Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons, Inc., 1995.
  14. Steven J. Zeil, Faten H. Afifi e Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM Transaction on Software Engineering and Methodology, 1-4, 1992.
  15. William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
  16. Thomas J. Ostrand e Marc J. Balcer, The Category-Partition method for specifying and generating functional tests, Communications of ACM 31, 1988.
  17. Cem Kaner, Jack Falk e Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.