Nei post precedenti del blog, abbiamo parlato di come suddividere un aspetto della sfida del testing, ovvero gestire input multipli come un esperimento progettato in cui possiamo iniziare concentrandoci su un input alla volta. Un post successivo del blog ha rivisitato i principi fondamentali degli effetti fattoriali negli esperimenti progettati. Ora, combineremo queste idee e discuteremo cosa potremmo desiderare nella progettazione di un esperimento da utilizzare per il testing.
Torniamo alla distribuzione beta e consideriamo ora se vogliamo testare la variazione degli input della distribuzione beta, concentrandoci su q, alpha e beta.
Supponiamo di scegliere tre valori per ciascuno di quegli input (basso/medio/alto). Si potrebbe immaginare di provare tutte le 27 (3x3x3) possibili combinazioni. Ma funzionerebbe se avessimo 10 input? 20? 100? A un certo punto, diventa evidente che abbiamo bisogno di una strategia diversa. Mentre abbiamo un modo per gestire questo nei tipici problemi di progettazione di esperimenti, questo stesso approccio funziona per i test del software? Ricordando che vogliamo trovare bug e che si nascondono negli angoli e nei confini , riformuliamo questo per dire che il nostro obiettivo è trovare combinazioni di input che indurranno un fallimento (vale a dire, non osserviamo il risultato previsto).
E i confini?
Potreste aver notato che sembro ignorare i confini. È qui che l'approccio OFAT può avere valore. Idealmente, abbiamo già verificato i nostri confini per ciascuno dei nostri input (e abbiamo risolto eventuali problemi) prima di arrivare a questo punto del test. Tuttavia, come scopriremo più avanti, possiamo tenere conto dei confini mentre variamo i nostri input.
Andare oltre l'OFA
In un design fattoriale, i principi fondamentali degli effetti fattoriali sono in relazione agli effetti importanti/significativi. Tuttavia, per il test del software, riformuliamo i principi fondamentali in termini di "combinazioni che inducono errori":
Gerarchia delle combinazioni : i) Le combinazioni che implicano meno input hanno maggiori probabilità di causare fallimenti rispetto a quelle che implicano più input. ii) Le combinazioni dello stesso ordine hanno la stessa probabilità di essere importanti.
Scarsità di combinazioni : il numero di combinazioni che inducono guasti sarà ridotto.
Ereditarietà combinata : una combinazione ha maggiori probabilità di indurre un fallimento se è noto che almeno uno dei fattori principali che coinvolgono l'interazione è più probabilmente coinvolto nell'indurre fallimenti.
Perché dovremmo fare questa distinzione?
Una delle principali differenze nei test è che la nostra risposta è semplicemente un pass/fail: ci discostiamo dal risultato previsto o no? Inoltre, di solito assumiamo un risultato deterministico. Vale a dire, se utilizziamo gli stessi input, otteniamo gli stessi risultati (nessun errore). Mentre un tester vuole trovare bug, alla fine speriamo che quei bug vengano risolti. Non stiamo cercando di adattare un modello, trovare effetti o ottimizzare una risposta. Infatti, l'analogo più vicino all'idea di modellazione è il compito di rintracciare una combinazione che ha indotto un errore. Questo è noto come problema di localizzazione degli errori e ha il suo insieme di sfide uniche.
Quindi, questi principi hanno senso ai fini dei test?
Si scopre che ci sono prove empiriche che la gerarchia di combinazione è valida (vedi Kuhn et al., 2004). D'altro canto, la scarsità di combinazione potrebbe non essere sempre un'ipotesi ragionevole. Se un sistema non è stato sottoposto ad alcun tipo di test per le interazioni, o persino test di input individuali, potrebbero esserci molti fallimenti in una suite di test (specialmente prima che i bug inizino a essere corretti). Ciò è anche correlato al principio di ereditarietà della combinazione: se un input individuale induce un fallimento, allora qualsiasi combinazione che coinvolga quell'input indurrà un fallimento.
Quindi, se queste ipotesi sono ragionevoli, cosa rende un buon set di test? Restate sintonizzati per i nostri prossimi post del blog.
Kuhn, DR, Wallace, DR e Gallo, AM, 2004. Interazioni di errori software e implicazioni per i test del software.Transazioni IEEE sull'ingegneria del software, 30(6), pp.418-421.
