(Immagino che questo sarebbe un buon domanda dell'intervista , ma nel mio caso è più pragmatica di così.)
Abbiamo large & un'applicazione complessa che modella un processo di reazione chimica estremamente lungo e sofisticato tra dozzine di componenti chimici. Siamo nella fase di progettazione di Acceptance Tests per l'applicazione, ma siamo piuttosto scoraggiati dal numero intrattabile di possibili percorsi da testare. Mi è venuto in mente che la nostra situazione è molto simile a quello che deve aver affrontato il team di sviluppo di Google Maps quando è arrivato il momento di testare l'algoritmo di pianificazione del percorso nella loro funzione "Ottieni indicazioni". Ovviamente non potevano testare (verificare e validare) ogni possibile percorso. Quindi, come hanno avuto la certezza che la loro applicazione avrebbe funzionato in ogni situazione?
E poiché non mi aspetto di scoprire come loro l'hanno fatto, permettimi di chiederti: come farebbe tu a progettare una suite di test con un'adeguata copertura del codice , per soddisfare te stesso che una data applicazione è solida - quando è letteralmente impossibile sondare ogni potenziale percorso attraverso il sistema?
Quello che sto cercando sono i principi che useresti per abbattere un problema intrattabile in parti più piccole e trattabili, la cui somma fornisce una stima soddisfacente del tutto: "Non posso testare tutto, ma io posso testare questo, questo e questo - e questo è abbastanza. " Non sto cercando un approccio che sia "provabilmente corretto", ma piuttosto un prudente , dati i vincoli di budget / tempo del mondo reale.
(Sto usando l'esempio delle mappe di Google come una sorta di pellicola per sollecitare risposte il più specifiche possibile.)