¿Cómo probaría la función "Obtener indicaciones" de Google Maps?

(Me imagino que esta sería una buena pregunta para la entrevista , pero en mi caso es más pragmática que eso).

Tenemos una aplicación grande y compleja que modela un proceso de reacción química extremadamente largo y sofisticado entre docenas de componentes químicos. Estamos en la etapa de diseño de las Pruebas de aceptación para la aplicación, pero estamos algo intimidados por la cantidad insoluble de posibles rutas para probar. Se me ocurrió que nuestra situación es muy parecida a la que el equipo de desarrollo de Google Maps debió enfrentar cuando llegó el momento de probar el algoritmo de planificación de ruta en su función "Obtener indicaciones". Obviamente no pudieron probar (verificar y validar) todas las rutas posibles. Entonces, ¿cómo obtuvieron la confianza de que su aplicación funcionaría en cada situación?

Y como no espero descubrir cómo lo hicieron, déjame preguntarte: ¿cómo harías para diseñar un conjunto de pruebas con una cobertura de código adecuada, para asegurarte de que una aplicación determinada es sólida, cuando es literalmente imposible? para sondear cada ruta potencial a través del sistema?

Lo que estoy buscando son los principios que usaría para dividir un problema intratable en piezas más pequeñas y manejables, cuya suma proporciona una estimación satisfactoria del conjunto: "No puedo probar todo, pero puedo probar esto , esto y esto, y eso es suficiente ". No estoy buscando un enfoque que sea "demostrablemente correcto", sino uno que sea prudente , dadas las limitaciones de presupuesto / tiempo del mundo real.

(Estoy usando el ejemplo de Google Maps como una especie de papel de aluminio para solicitar respuestas que sean lo más específicas posible).

Trabajé en el campo de navegación para automóviles hace más de una década.

Paso A) Use un paquete de referencia y seleccione un conjunto de muestra grande, ejecute pruebas A / B. Sin buscar exactitud, buscando valores atípicos: el conjunto de referencia mostró Reroute 1234 como 10.34 km, y calculamos 123.5 km.

Paso B) - Refine nuestro software y el software de referencia - Agregue más muestras y reduzca las tolerancias.

Paso C): pruebas internas utilizando el conocimiento local en conjuntos de datos globales.

Paso D) UAT ... "Prueba de aceptación del usuario" Como en "Vender estas cosas y ver de qué se quejan más los clientes"

Si alguna vez usó productos de mapeo alrededor de mediados de la década de 1990 - 2000, sabe a lo que me refiero, aquellos de nosotros que todavía verificamos las instrucciones paso a paso cada vez.

De vuelta a tu pregunta de ejemplo. Lo que se le pregunta es cómo demostrar que un software es correcto. Si desea una prueba matemática, se ha demostrado que se puede hacer: para un software simple a un precio que excede cualquier presupuesto realista, para un paquete de software complejo, bueno, eso sigue siendo investigación ... La NASA tiene modelos para escribir software altamente confiable dentro de precios económicamente manejables, como lo hacen el Departamento de Defensa y la industria de la aviación, aunque aún son mucho más altos de lo que la mayoría está dispuesta a pagar. Al final, todo se reduce a cuánto estás dispuesto a pagar .....

Editar: Acabo de volver a leer tu OP. Parece que lo que está buscando es una forma rápida y económica de probar la calidad de un software complejo. No se puede probar en calidad. Debe tener un proceso robusto para saber que lo que está construido funciona correctamente. Si tiene que pensar en cómo demostrar que es correcto y ya tiene una "aplicación grande y compleja", es demasiado tarde.

Somos uno de los competidores de Google. Nuestra respuesta? Básicamente dos.

Primero, calculamos la solución completa de dirección a dirección. Sí, esa es una gran matriz. Peor aún, lo hacemos para todos los momentos del día, todos los días de la semana. Hay suficiente similitud en el dominio de entrada para almacenar en caché los resultados intermedios, lo que hace que el problema sea manejable. Aún así, trate de obtener una tarifa masiva en los discos duros.

Tenga en cuenta que este cálculo fuera de línea se realiza utilizando un algoritmo diferente. Utiliza mucha más memoria que el algoritmo que pretendemos probar, pero no linealmente más (es decir, utiliza menos de 1000 veces más memoria al calcular mil rutas).

En segundo lugar, los usuarios participantes nos proporcionan resultados del mundo real. Validamos millones de rutas conducidas. ¿Son las rutas reales tan rápidas como se predijeron?

Y seguro, sí encuentras errores de esa manera. Todos los tiempos. Por ejemplo, un tramo de carretera que está delimitado a ambos lados por una "zona de tráfico local solamente" *. Solo hay una forma;) que lo encontrará en las pruebas, y es cuando planifica una ruta a esa carretera en particular.

_{* Una "zona de solo tráfico local" solo se puede utilizar cuando comienza o finaliza una ruta en dicha zona. Por lo tanto, el tramo en el medio está desconectado de la red de carreteras principal. Esto es una falla de zonificación o de mapa.}

No es que Google escriba un código separado para cada par de direcciones en el mundo. Con la excepción de las heurísticas que entran en acción a mayor escala, el algoritmo para un viaje de 3 tramos es exactamente el mismo que para un tramo de 3000 tramos. Usted prueba a fondo las rutas más cortas y utiliza la inducción para mostrar que la prueba se aplica también a las rutas más largas.

Elige una muestra saludable de rutas del mundo real y compárala con lo que se le ocurre a un humano. Presta mucha atención a los comentarios de los usuarios finales en sus primeros lanzamientos, y les facilita proporcionarlos. Usted prueba las condiciones de contorno, como si la mejor ruta realmente requiere viajar lejos del destino por un tiempo, o si la ruta más corta por distancia tiene 18 vueltas en comparación con una ruta más directa que es un poco más larga. Hace pruebas negativas, como si estuviera tratando de conducir de California a Hawai, y se asegura de que haya huevos de Pascua listos.