(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.)