Como você testaria o recurso "Obter direções" do Google Maps?

(Imagino que essa seria uma boa pergunta para entrevista , mas no meu caso é mais pragmática do que isso.)

Temos uma aplicação grande e complexa que modela um processo de reação química extremamente longo e sofisticado entre dezenas de componentes químicos. Estamos no estágio de projetar testes de aceitação para o aplicativo, mas estamos um pouco assustados com o número intratável de caminhos possíveis para testar. Ocorreu-me que nossa situação é muito parecida com a que a equipe de desenvolvedores do Google Maps deve ter enfrentado quando chegou a hora de testar o algoritmo de planejamento de rotas no recurso "Obter direções". Obviamente, eles não puderam testar (verificar e validar) todas as rotas possíveis. Então, como eles obtiveram a confiança de que seu aplicativo funcionaria em todas as situações?

E como não espero descobrir como eles fizeram isso, deixe-me perguntar: como você projetaria um conjunto de testes com cobertura de código adequada, para se certificar de que um determinado aplicativo é robusto - quando é literalmente impossível sondar todos os caminhos em potencial através do sistema?

O que estou procurando são os princípios que você usaria para decompor um problema intratável em pedaços menores e tratáveis, cuja soma fornece uma estimativa satisfatória do todo: "Não posso testar tudo, mas posso testar isso , isso e isso - e isso é o suficiente. " Não estou procurando uma abordagem "comprovadamente correta", mas uma que seja prudente , dadas as restrições de orçamento / tempo do mundo real.

(Estou usando o exemplo do Google Maps como uma espécie de folha para solicitar respostas o mais específicas possível.)

Eu trabalhei no campo de navegação de automóveis há mais de uma década.

Etapa A) Use um pacote de referência e selecione um grande conjunto de amostras, execute testes A / B. Não procurando exatidão, procurando discrepantes - O conjunto de referência mostrou Reroute 1234 como 10,34km e calculamos 123,5km.

Etapa B) - refine nosso software e o software de referência - adicione mais amostras e reduza as tolerâncias.

Etapa C) - Teste interno usando conhecimento local em conjuntos de dados globais.

Etapa D) UAT ... "Teste de aceitação do usuário" Como em "Venda essas coisas e veja o que os clientes mais reclamam"

Se você já usou produtos de mapeamento por volta de meados da década de 1990 - 2000, você entende o que eu quero dizer, aqueles de nós que ainda verificavam as direções de cada vez.

De volta à sua pergunta de exemplo. O que você está sendo perguntado é como provar que um software está correto. Se você quer uma prova matemática, foi demonstrado que isso pode ser feito - por software simples a um preço que excede qualquer orçamento realista, por um pacote de software complexo, bem, isso ainda é pesquisa ... A NASA possui modelos para escrever software altamente confiável dentro de preços economicamente administráveis, como fazem o Departamento de Defesa e a indústria da aviação - embora ainda muito mais altos do que a maioria está disposta a pagar. No final, tudo se resume a quanto você está preparado para pagar ...

Edit: Acabei de reler você OP. Parece que você está procurando uma maneira rápida e barata de testar a qualidade de um software complexo. Você não pode testar em qualidade. Você precisa ter um processo robusto para saber que o que é construído funciona corretamente. Se você tiver que pensar em como provar que está correto e já tiver um "aplicativo grande e complexo", será tarde demais.

Somos um dos concorrentes do Google. Nossa resposta? Basicamente dois.

Primeiro, calculamos a solução completa de endereço para endereço. Sim, isso é uma grande matriz. Pior ainda, fazemos isso para todos os momentos do dia, todos os dias da semana. Há semelhança suficiente no domínio de entrada para armazenar em cache resultados intermediários, o que torna o problema tratável. Ainda assim, tente obter uma taxa em massa em discos rígidos.

Observe que esse cálculo offline é feito usando um algoritmo diferente. Ele usa muito mais memória do que o algoritmo que pretendemos testar, mas não linearmente mais (isto é, usa menos de 1000 vezes mais memória ao calcular mil rotas).

Em segundo lugar, os usuários participantes nos fornecem resultados do mundo real. Validamos milhões de rotas percorridas. As rotas reais são tão rápidas quanto o previsto?

E claro, você encontra erros dessa maneira. Todas as vezes. Por exemplo, um trecho de estrada delimitado em ambos os lados por uma "zona de tráfego local" *. Há apenas uma maneira;) que você encontrará nos testes, e é nesse momento que você planeja uma rota para essa estrada específica.

_{* Uma "zona apenas de tráfego local" só pode ser usada quando você está iniciando ou encerrando uma rota nessa zona. O trecho no meio é, portanto, desconectado da rede principal de estradas. Isso é uma falha de zoneamento ou de mapa.}

Não é como se o Google escrevesse um código separado para cada par de endereços no mundo. Com exceção das heurísticas que ocorrem em uma escala maior, o algoritmo para uma jornada de três pernas é exatamente o mesmo que para uma perna de 3000. Você testa minuciosamente os caminhos mais curtos e usa a indução para mostrar que o teste também se aplica aos caminhos mais longos.

Você escolhe uma amostra saudável de rotas do mundo real e compara com o que um humano cria. Você presta muita atenção ao feedback do usuário final em seus primeiros lançamentos e facilita o fornecimento dele. Você testa as condições de contorno, como se a melhor rota realmente precisasse se afastar do destino por um tempo ou se a rota mais curta por distância tivesse 18 curvas em comparação com uma rota mais direta, um pouco mais longa. Você faz testes negativos, como se estivesse tentando dirigir da Califórnia para o Havaí, e certifique-se de que há ovos de páscoa inteligentes.