Un campo età che accetta da 18 a 60 anni ha un numero enorme di possibili input, una volta contati i negativi, i numeri enormi, il testo e gli spazi vuoti. Nessuno può provarli tutti. Il partizionamento per equivalenza risolve questo problema, raggruppando gli input che il software dovrebbe trattare allo stesso modo e quindi testando un valore da ciascun gruppo.

È una delle prime tecniche di progettazione dei test che ogni tester dovrebbe apprendere. In questa guida lo analizzeremo passo dopo passo e testeremo un esempio in Python. Abbiamo eseguito quel codice su Python 3.13 e il suo output è incluso. Le regole relative alla password e al coupon riportate di seguito sono esempi illustrativi, non presi da un sistema reale.

Cos’è il partizionamento per equivalenza?

Il partizionamento di equivalenza, chiamato anche partizionamento di classi di equivalenza (ECP), è una tecnica di progettazione di test a scatola nera. Divide i possibili input di una funzionalità in partizioni o classi. Ci si aspetta che ogni valore all’interno di una partizione produca lo stesso tipo di comportamento.

Poiché non è necessario visualizzare il codice, è possibile applicarlo direttamente da un requisito. Per saperne di più su questo stile di test, leggi Test della scatola nera e della scatola bianca.

Perché funziona

La tecnica si basa su un presupposto: se un valore in una partizione trova un bug, probabilmente lo troveranno anche gli altri in quella partizione. E se un valore passa, probabilmente passeranno anche gli altri. Testare 25, 26 e 27 in un campo di età adulta probabilmente non ti dirà nulla che testare 25 da solo non abbia detto.

Si tratta però di una supposizione e non di una garanzia. Il software può avere casi speciali nascosti all’interno di una partizione, una limitazione su cui torneremo più avanti.

Come farlo in cinque passaggi

1. Leggere il requisito e identificare l’input e le sue regole.
2. Trova le partizioni valide, quali sono i gruppi di valori che dovrebbero essere accettati e nota se intervalli diversi si comportano diversamente.
3. Trova le partizioni non valide, inclusi valori troppo bassi, troppo alti, tipo sbagliato e vuoti.
4. Scegli un valore rappresentativo da ciascuna partizione, solitamente da qualche parte nel mezzo.
5. Annota il risultato atteso per ciascuno, come in qualsiasi buon caso di test.

Esempio realizzato: un campo età

Requisito: Possono registrarsi gli utenti dai 18 ai 60 anni.

Cinque test ti offrono la copertura di ogni comportamento previsto dal requisito. Molti tutorial si fermano alle prime tre righe, ma le ultime due sono quelle che gli utenti reali attivano per sbaglio. Puoi anche aggiungere righe per numeri negativi o decimali, se questi possono essere ragionevolmente gestiti diversamente.

Testarlo nel codice

Ecco quella regola come funzione, con uno unit test per partizione, usando il built-in di Python unittest:

import unittest

def can_register(age):
    if not isinstance(age, int) or isinstance(age, bool):
        raise TypeError("age must be a whole number")
    return 18 <= age <= 60

class EquivalenceTests(unittest.TestCase):
    def test_valid_partition(self):
        self.assertTrue(can_register(35))

    def test_too_young_partition(self):
        self.assertFalse(can_register(10))

    def test_too_old_partition(self):
        self.assertFalse(can_register(75))

    def test_wrong_type_partition(self):
        with self.assertRaises(TypeError):
            can_register("abc")

La nostra corsa è passata:

test_too_old_partition ... ok
test_too_young_partition ... ok
test_valid_partition ... ok
test_wrong_type_partition ... ok

In un progetto reale, la funzione di parametrizzazione di pytest è un modo accurato per eseguire una tabella di valori di partizione attraverso un singolo test.

Esempio realizzato: una password

Requisito: Una password deve essere lunga da 8 a 20 caratteri e contenere almeno una cifra.

Questo ha due regole, lunghezza e contenuto, quindi consideriamo le partizioni per entrambi:

Nota che ogni test non valido infrange solo una regola. Se un valore fosse troppo corto e mancasse una cifra, un test superato non potrebbe dirti quale controllo ha funzionato. Un assegno potrebbe essere rotto, mentre l’altro nasconde il fatto.

Esempio realizzato: input non numerici

La tecnica non è limitata agli intervalli di numeri. Anche opzioni, categorie e stati discreti formano partizioni. Supponiamo che un negozio abbia questa regola:

Requisito: La consegna è gratuita per i membri Gold, 50 per i Silver e 100 per tutti gli altri. I valori dei livelli sconosciuti sono errori.

Qui, ogni opzione ha la propria partizione, poiché ognuna dovrebbe comportarsi in modo diverso. Altre partizioni comuni includono tipi di file, come caricamenti validi e non validi, e gruppi basati sull’output, come un prestito approvato o rifiutato.

Diversi input contemporaneamente

Con più campi, il numero di combinazioni cresce rapidamente. Tre campi con quattro partizioni forniscono ciascuno 64 combinazioni. Due strategie aiutano:

• Copertura debole: assicurati che ogni partizione appaia in almeno un test, combinando diversi valori validi per test. Per i valori non validi, testarne uno alla volta in modo che gli errori non si nascondano a vicenda.
• Copertura basata su regole: quando le combinazioni modificano effettivamente il risultato, come lo stato del membro con il valore dell’ordine, utilizza test della tabella decisionale per elencarle correttamente.

Associazione con l’analisi dei valori limite

Il partizionamento indica quali gruppi testare. Dice poco su dove in un gruppo gli insetti amano nascondersi, e molti si nascondono proprio ai bordi. Per dimostrarlo, abbiamo scritto una versione buggy con il classico errore “off-by-one”:

def buggy(age):
    return 18 < age <= 60     # should be 18 <= age

[buggy(a) for a in (35, 10, 75)]   # [True, False, False]
buggy(18)                          # False

I nostri valori di partizione, 35, 10 e 75, hanno dato tutti le risposte corrette, quindi i test sarebbero stati superati. Eppure un 18enne viene ingiustamente rifiutato. Ecco perché le due tecniche vanno di pari passo:

Utilizzare il partizionamento per trovare i gruppi e quindi i confini per verificare dove si incontrano i gruppi. Nel nostro codice, un test separato per 17, 18, 60 e 61 ha superato la funzione corretta e avrebbe rilevato il bug. La nostra guida all’analisi dei valori limite tratta questo argomento in modo completo.

Vantaggi e limiti

Il rischio più grande è un presupposto errato. Se il codice ha una regola nascosta per un valore specifico, il test scelto potrebbe semplicemente non raggiungerlo. Test esplorativi e copertura del codice ti aiutano a trovare ciò che è mancato alle partizioni.

Errori comuni

• Dimenticare le partizioni non valide. Testare solo i percorsi felici lascia la gestione degli errori deselezionata.
• Testare diversi valori da una partizione. Ciò aumenta i costi senza nuove informazioni.
• Combinazione di diversi valori non validi in un test. Un errore può nasconderne un altro.
• Saltare i limiti. I soli test delle partizioni spesso non riescono a individuare i bug singoli.
• Indovinare le regole. Se un requisito non è chiaro, chiedi. Nel 60 dovrebbero rientrare anche le persone che hanno 60 anni e mezzo?

Considerazioni finali

Il partizionamento di equivalenza sostituisce “quanti test dovrei scrivere?” con una domanda molto migliore: “quali comportamenti esistono e li ho trattati ciascuno?” Per provarlo, prendi un modulo che stai testando oggi ed elenca le sue partizioni su carta, comprese quelle non valide. Aggiungi i confini successivamente. Spesso ti ritroverai con meno test che troveranno più bug.

Domande frequenti

Continua a imparare