Comment testeriez-vous la fonctionnalité «Obtenir l'itinéraire» de Google Maps?


13

(J'imagine que ce serait une bonne question d'entrevue , mais dans mon cas, c'est plus pragmatique que cela.)

Nous avons une application large et complexe qui modélise un processus de réaction chimique extrêmement long et sophistiqué entre des dizaines de composants chimiques. Nous sommes au stade de la conception des tests d'acceptation pour l'application, mais nous sommes quelque peu découragés par le nombre insurmontable de chemins possibles à tester. Il m'est venu à l'esprit que notre situation ressemble beaucoup à ce que l'équipe de développement de Google Maps a dû faire face au moment de tester l'algorithme de planification d'itinéraire dans sa fonction "Obtenir l'itinéraire". De toute évidence, ils ne pouvaient pas tester (vérifier et valider) tous les itinéraires possibles. Alors, comment ont-ils eu l'assurance que leur application fonctionnerait dans toutes les situations?

Et comme je ne m'attends pas à découvrir comment ils l' ont fait, permettez-moi de vous demander: comment allez- vous concevoir une suite de tests avec une couverture de code adéquate, pour vous assurer qu'une application donnée est robuste - quand elle est littéralement impossible pour sonder chaque chemin potentiel à travers le système?

Ce que je recherche, ce sont les principes que vous utiliseriez pour décomposer un problème insoluble en morceaux plus petits et plus maniables, dont la somme fournit une estimation satisfaisante de l'ensemble: "Je ne peux pas tout tester, mais je peux le tester , ceci et cela - et cela suffit. " Je ne recherche pas une approche qui soit «prouvablement correcte», mais plutôt une approche prudente , compte tenu des contraintes de budget / temps réelles.

(J'utilise l'exemple de Google Maps comme un clin d'œil pour solliciter des réponses aussi précises que possible.)


Dans le passé, Google Maps a essayé de me diriger dans les rues réservées aux bus, dans le mauvais sens dans les rues à sens unique, et de faire des virages aux intersections qui n'existent pas (par exemple, un survol avec seulement une offramp). Je pense qu'ils ont une fonction "signaler les directions incorrectes", mais ce n'est probablement pas quelque chose qui fonctionnerait dans votre situation. La réponse au peu qu'ils ont tout testé? Ils ne l'ont pas fait, et ils n'en avaient pas vraiment besoin.
John Lyon

Comme toujours avec ce genre de question, je vous recommande de lire les livres et articles de Nassim Nicholas Taleb. Voici un article technique qui rentre dans le calcul mais je recommande fortement de lire ses livres.
jfrankcarr

Je ne pense pas que vous puissiez concevoir un test qui couvre tous les cas pour quelque chose de suffisamment complexe. Si vous savez comment l'intérieur fonctionne, vous pouvez proposer des tests pour chaque chemin évident, mais il y aura toujours des choses auxquelles personne n'a jamais pensé. Vous pensez au plus grand nombre possible et vous espérez que ceux qui vous manquent ne sont pas un gros problème.
Loren Pechtel

2
@jozzas: Tout ce que vous décrivez est une erreur de base de données, pas vraiment un problème avec l'algorithme de direction de Google. Un équivalent serait ce matin mon satnav a essayé de me diriger sur une route non entretenue. D'un autre côté, quand il m'a donné un avis de fermeture de voie sur une route que j'allais quitter, c'est un bug réel. (L'avis ne regarde évidemment que la route sur laquelle vous vous trouvez, pas l'itinéraire qu'il suit.)
Loren Pechtel

1
Appelez ça "Beta". Terminé. C'est la façon dont Google.
Paystey

Réponses:


10

J'ai travaillé dans le domaine de la navigation automobile il y a plus d'une décennie.

Étape A) Utilisez un package de référence et sélectionnez un grand ensemble d'échantillons, exécutez des tests A / B. Ne recherchant pas l'exactitude, recherchant des valeurs aberrantes - L'ensemble de référence a montré la Reroute 1234 à 10,34 km, et nous avons calculé 123,5 km.

Étape B) - Affiner notre logiciel et le logiciel de référence - Ajouter plus d'échantillons et réduire les tolérances.

Étape C) - Tests internes utilisant les connaissances locales à travers des ensembles de données mondiaux.

Étape D) UAT ... "Test d'acceptation des utilisateurs" Comme dans "Vendez ces trucs et voyez ce que les clients se plaignent le plus"

Si vous avez déjà utilisé des produits de cartographie vers le milieu des années 1990-2000, vous savez ce que je veux dire, ceux d'entre nous qui vérifiaient toujours les directions tour par tour à chaque fois.

Retour à votre exemple de question. Ce qu'on vous demande, c'est comment prouver qu'un logiciel est correct. Si vous voulez une preuve mathématique, il a été démontré que cela peut être fait - pour un logiciel simple à un prix qui dépasse tous les budgets réalistes, pour un progiciel complexe, eh bien, c'est encore de la recherche ... La NASA a des modèles pour écrire des logiciels très fiables dans des prix économiquement gérables, comme le font le DoD et l'industrie aéronautique - bien que toujours beaucoup plus élevés que la plupart sont prêts à payer. En fin de compte, cela revient à combien êtes-vous prêt à payer .....

Edit: je viens de vous relire OP. Il semble que ce que vous cherchez soit un moyen rapide et bon marché de tester la qualité d'un logiciel complexe. Vous ne pouvez pas tester la qualité. Vous devez avoir un processus robuste pour savoir que ce qui est construit fonctionne correctement. Si vous devez réfléchir à la façon de prouver qu'elle est correcte et que vous avez déjà une "application large et complexe", vous êtes trop tard.


5

Nous sommes l'un des concurrents de Google. Notre réponse? Fondamentalement, deux.

Tout d'abord, nous calculons la solution complète d'adresse à adresse. Oui, c'est une grande matrice. Pire encore, nous le faisons à tout moment de la journée, tous les jours de la semaine. Il y a suffisamment de similitude dans le domaine d'entrée pour mettre en cache les résultats intermédiaires, ce qui rend le problème traitable. Essayez tout de même d'obtenir un taux global sur les disques durs.

Notez que ce calcul hors ligne est effectué à l'aide d'un algorithme différent. Il utilise beaucoup plus de mémoire que l'algorithme que nous avons l'intention de tester, mais pas linéairement plus (c'est-à-dire qu'il utilise moins de 1000 fois plus de mémoire lors du calcul d'un millier de routes).

Deuxièmement, les utilisateurs participants nous fournissent des résultats réels. Nous validons des millions d'itinéraires parcourus. Les itinéraires réels sont-ils aussi rapides que prévu?

Et bien sûr, vous trouvez des bogues de cette façon. Tout le temps. Par exemple, un tronçon de route délimité des deux côtés par une "zone réservée à la circulation locale" *. Il n'y a qu'une seule façon;) que vous allez trouver cela lors des tests, et c'est à ce moment-là que vous planifiez un itinéraire vers cette route particulière.

* Une "zone de trafic local uniquement" ne peut être utilisée que lorsque vous commencez ou terminez un itinéraire dans une telle zone. Le tronçon du milieu est donc déconnecté du réseau routier principal. Il s'agit soit d'un zonage, soit d'un défaut de carte.


3

Ce n'est pas comme si Google écrit un code distinct pour chaque paire d'adresses dans le monde. À l'exception des heuristiques qui démarrent à plus grande échelle, l'algorithme pour un voyage à 3 étapes est exactement le même que pour une étape à 3000 étapes. Vous testez soigneusement les chemins plus courts et utilisez l'induction pour montrer que le test s'applique également aux chemins plus longs.

Vous choisissez un échantillon sain d'itinéraires du monde réel et le comparez à ce que propose un humain. Vous prêtez beaucoup d'attention aux commentaires des utilisateurs finaux dans vos premières versions et vous leur permettez de les fournir facilement. Vous testez les conditions aux limites, comme si le meilleur itinéraire nécessite réellement de s'éloigner de la destination pendant un certain temps, ou si l'itinéraire le plus court par la distance a 18 tours par rapport à un itinéraire plus direct qui est légèrement plus long. Vous effectuez des tests négatifs, comme si vous essayez de conduire de la Californie à Hawaï, et assurez-vous que des œufs de Pâques intelligents sont en place.


Je suis sûr que tout ce que vous avez suggéré est exact, mais je ne peux m'empêcher de penser que ce n'est toujours pas suffisamment rigoureux. «Choisir un échantillon sain d'itinéraires» ressemble plus à ce que je pourrais faire pour un projet de trimestre universitaire, qu'à ce qu'une équipe de développement de classe mondiale pourrait concevoir. Et même si je suis d'accord avec votre observation sur les itinéraires à 3 étapes vs 3000 étapes, tester même une grande partie des itinéraires à 3 étapes semble encore assez ambitieux. Je pense que nous manquons encore quelque chose de fondamental ici.
kmote

@kmote: "mais je ne peux pas m'empêcher de penser qu'il n'est toujours pas suffisamment rigoureux" Pourquoi pas, cela a fonctionné pour l'industrie du logiciel pendant une génération, et il n'y a aucun signe réel qu'il est sur le point d'être remplacé de sitôt. Nous sommes payés pour écrire du code qui fait de l'argent, pas pour écrire du code parfait. À bien y penser, ce qui est utilisé en médecine, en génie et dans pratiquement toutes les professions, et il semble bien faire ces industries.
mattnz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.