Il sistema di campane automatizzate della Stateless University dovrebbe suonare ogni ora durante il lunedì, mercoledì e venerdì. Dovrebbe suonare ogni 90 minuti durante il martedì e il giovedì, e non suona affatto durante i fine settimana
Quindi le classi di equivalenza per queste sono:
lunedì, mercoledì, venerdì
martedì e giovedì
sabato e domenica
90 minuti
60 minuti
Ho ragione ?? o mi manca qualcosa?
L'uso di una classe equivalente su valori discreti non sembra essere una buona idea. Questo è un evento più rischioso se il numero di possibili valori discreti è piccolo (come i giorni).
Il motivo è il seguente: Se definisci una classe equivalente, diciamo {lunedì, martedì, mercoledì}, speri che testare solo 1 di questi giorni sarà sufficiente per testare il comportamento del software e che non dovrai testare gli altri 2.
Il rischio deriva da una scelta più ampia:
(1) Se lo sviluppatore scrive un test come 'if (Mondays < = day) & (day < = mercoledì) ", la classe equivalente funzionerebbe, perché ogni giorno nell'intervallo si comporterebbe allo stesso modo.
(2) Sfortunatamente se lo sviluppatore scrive un test per ogni giorno, testare solo 1 giorno con quanto segue non verifica completamente l'implementazione: 'if (lunedì == giorno) || (Martedì == giorno) || (Mercoledì == giorno) ' Il motivo è che non hai testato tutte le condizioni.
Il vero caso che ho in mente è il seguente:
Avevamo un componente software che eseguiva un ritardo discreto, da 1 a 8 campioni. Il test case è stato scritto utilizzando la classe equivalente sulla variabile numberOfSample, i cui valori sono compresi nell'intervallo [1..8]. Quindi sono stati fatti test con 1, 3 e 8 (più 0 e 9 per il test di robustezza).
Il problema è il seguente: per ragioni di prestazioni lo sviluppatore ha scritto un prezzo di codice per ogni caso da 1 a 8, con un caso di switch in primo piano. Pertanto alcune parti del codice non sono state testate e la copertura strutturale per questo componente era inferiore al 50%. Ho dovuto spiegare la scelta dell'implementazione e il test case ora verifica ogni valore da 1 a 8 e abbiamo applicato lo stesso principio per ogni variabile simile.
Tornando al tuo esempio:
Se l'implementazione del software ha un input molto discreto, con un numero limitato di valori possibili, non provare la classe equivalente (Inoltre, dovresti davvero non farlo se i valori non sono continui).
Se il software ha un input quasi continuo, come ad esempio il numero di secondi dall'inizio della settimana, ci sono molte possibilità che il comportamento del software sia lo stesso per la gamma di alcuni giorni ininterrotti. In caso contrario, il comportamento dovrebbe essere coerente almeno entro un giorno (testerai alle 0:00, 0:01, 15:34, 23:59, per ogni giorno dato).
Leggi altre domande sui tag testing