Come testeresti la funzione "Ottieni indicazioni" di Google Maps?

(Immagino che questa sarebbe una buona domanda per l'intervista , ma nel mio caso è più pragmatica di così.)

Abbiamo un'applicazione ampia e complessa che modella un processo di reazione chimica estremamente lungo e sofisticato tra decine di componenti chimici. Siamo nella fase di progettazione dei test di accettazione per l'applicazione, ma siamo un po 'scoraggiati dal numero intrattabile di possibili percorsi da testare. Mi è venuto in mente che la nostra situazione è molto simile a quella che il team di sviluppo di Google Maps deve aver dovuto affrontare quando è arrivato il momento di testare l'algoritmo di pianificazione del percorso nella funzione "Ottieni indicazioni stradali". Ovviamente non sono stati in grado di testare (verificare e validare) ogni possibile percorso. Quindi, come hanno avuto la certezza che la loro applicazione avrebbe funzionato in ogni situazione?

E dal momento che non mi aspetto di scoprire come hanno fatto, lascia che ti chieda: come faresti a progettare una suite di test con un'adeguata copertura del codice, per assicurarti che una determinata applicazione sia solida, quando è letteralmente impossibile sondare ogni potenziale percorso attraverso il sistema?

Quello che sto cercando sono i principi che useresti per scomporre un problema intrattabile in pezzi più piccoli e trattabili, la cui somma fornisce una stima soddisfacente del tutto: "Non posso testare tutto, ma posso testarlo , questo e questo - e questo è abbastanza ". Non sto cercando un approccio "dimostrabilmente corretto", ma piuttosto uno che sia prudente , dati i vincoli di budget / tempo del mondo reale.

(Sto usando l'esempio di Google Maps come qualcosa di un foglio per sollecitare risposte il più specifiche possibile.)

Ho lavorato nel campo della navigazione automobilistica oltre un decennio fa.

Passaggio A) Utilizzare un pacchetto di riferimento e selezionare un set di campioni di grandi dimensioni, eseguire test A / B. Non cercando esattezza, cercando valori anomali - Il set di riferimento mostrava Reroute 1234 come 10,34 km e abbiamo calcolato 123,5 km.

Passaggio B): perfezionare il nostro software e il software di riferimento: aggiungere altri campioni e ridurre le tolleranze.

Passaggio C): test interni che utilizzano le conoscenze locali in tutti i set di dati globali.

Passaggio D) UAT ... "Test di accettazione dell'utente" Come in "Vendi questa roba e vedi di cosa si lamentano di più i clienti"

Se hai mai usato prodotti per la mappatura tra la metà degli anni '90 e il 2000, sai cosa intendo, quelli di noi che controllavano sempre le indicazioni di volta in volta.

Torna alla tua domanda di esempio. Quello che ti viene chiesto è come dimostrare che un software è corretto. Se vuoi una prova matematica, è stato dimostrato che può essere fatto: per un software semplice a un prezzo che supera qualsiasi budget realistico, per un pacchetto software complesso, beh, è ​​ancora ricerca .... La NASA ha modelli per scrivere software altamente affidabile a prezzi economicamente gestibili, così come il DoD e l'industria aeronautica, sebbene siano ancora molto più alti di quelli che la maggior parte è disposta a pagare. Alla fine, si riduce a quanto sei disposto a pagare .....

Modifica: ho appena riletto il tuo OP. Sembra che quello che stai cercando sia un modo rapido ed economico per testare la qualità di un software complesso. Non è possibile testare in termini di qualità. È necessario disporre di un processo solido in modo da sapere che ciò che è costruito funziona correttamente. Se devi pensare a come dimostrare che è corretto e hai già una "grande e complessa applicazione", sei in ritardo.

Siamo uno dei concorrenti di Google. La nostra risposta? Fondamentalmente due.

Innanzitutto, calcoliamo la soluzione completa da indirizzo a indirizzo. Sì, questa è una grande matrice. Ancora peggio, lo facciamo per tutte le ore del giorno, tutti i giorni della settimana. Esiste una somiglianza sufficiente nel dominio di input per memorizzare nella cache i risultati intermedi, il che rende il problema trattabile. Tuttavia, prova a ottenere una percentuale di massa su hard disk.

Si noti che questo calcolo offline viene eseguito utilizzando un algoritmo diverso. Utilizza molta più memoria dell'algoritmo che intendiamo testare, ma non linearmente di più (ovvero utilizza meno di 1000 volte più memoria quando si calcolano mille rotte).

In secondo luogo, gli utenti partecipanti ci forniscono risultati reali. Convalidiamo milioni di percorsi guidati. I percorsi effettivi sono rapidi come previsto?

E certo, trovi i bug in quel modo. Tutte le volte. Ad esempio un tratto di strada delimitato su entrambi i lati da una "zona di solo traffico locale" *. C'è solo un modo;) che lo troverai nei test, ed è quando pianifichi un percorso per quella particolare strada.

_{* Una "zona di solo traffico locale" può essere utilizzata solo quando inizi o finisci un percorso in tale zona. Il tratto nel mezzo è quindi disconnesso dalla rete stradale principale. Questa è una suddivisione in zone o un errore della mappa.}

Non è come se Google scrivesse un codice separato per ogni coppia di indirizzi nel mondo. Con l'eccezione dell'euristica che si avvia su larga scala, l'algoritmo per un viaggio a 3 gambe è esattamente lo stesso di un 3000 a gamba. Collaudi a fondo i percorsi più brevi e usi l'induzione per mostrare che i test si applicano anche ai percorsi più lunghi.

Scegli un campione sano di percorsi del mondo reale e lo confronti con ciò che viene fuori da un essere umano. Presta molta attenzione al feedback degli utenti finali nelle tue prime versioni e rendi facile per loro fornirlo. Metti alla prova le condizioni al contorno, come se il percorso migliore richieda effettivamente un allontanamento dalla destinazione per un po ', o se il percorso più breve per distanza ha 18 curve rispetto a un percorso più diretto leggermente più lungo. Esegui test negativi, ad esempio se stai cercando di guidare dalla California alle Hawaii, e assicurati che siano presenti uova di Pasqua intelligenti.