Как бы вы протестировали функцию «Проложить маршрут» на Картах Google?

(Я думаю, это был бы хороший вопрос для интервью , но в моем случае это более прагматично, чем это.)

У нас есть большое и сложное приложение, которое моделирует чрезвычайно длительный и сложный процесс химической реакции между десятками химических компонентов. Мы находимся на стадии разработки Приемочных тестов для приложения, но нас несколько пугает несметное количество возможных путей для тестирования. Мне пришло в голову, что наша ситуация очень похожа на то, с чем столкнулась команда разработчиков Google Maps, когда пришло время протестировать алгоритм планирования маршрута в их функции «Получить направления». Очевидно, они не могли проверить (проверить и подтвердить) каждый возможный маршрут. Так как же они получили уверенность, что их приложение будет работать в любой ситуации?

И поскольку я не ожидаю узнать, как они это сделали, позвольте мне спросить вас: как бы вы разработали набор тестов с адекватным покрытием кода, чтобы убедиться, что данное приложение устойчиво - когда оно буквально невозможно исследовать каждый потенциальный путь через систему?

То, что я ищу, - это принципы, которые вы бы использовали, чтобы разбить неразрешимую проблему на более мелкие, поддающиеся обработке куски, сумма которых обеспечивает удовлетворительную оценку целого: «Я не могу проверить все, но я могу проверить это , этого и этого - и этого достаточно. Я не искал подход , который является «доказуемо правильным», а тот , который благоразумен , учитывая реальные ограничения бюджета / время.

(Я использую пример карт Google как нечто вроде фольги, чтобы получить ответы, которые являются как можно более конкретными.)

Я работал в области автомобильной навигации более десяти лет назад.

Шаг A) Используйте справочный пакет и выберите большой набор образцов, запустите A / B тесты. Не ищем точности, ищем выбросы - контрольный набор показал Reroute 1234 как 10,34 км, и мы вычислили 123,5 км.

Шаг B). Уточнение нашего программного обеспечения и эталонного программного обеспечения. Добавление большего количества образцов и уменьшение допусков.

Шаг C) - Внутреннее тестирование с использованием локальных знаний в глобальных наборах данных.

Шаг D) UAT ... «Приемочный тест пользователя» Как в «Продайте этот материал и посмотрите, на что клиенты больше всего жалуются»

Если вы когда-либо пользовались картографическими продуктами примерно в середине 1990-х - 2000-х, вы знаете, что я имею в виду, те из нас, кто все еще проверял направление поворота за поворотом каждый раз.

Обратно к вам пример вопроса. Вас спрашивают, как доказать, что часть программного обеспечения верна. Если вам нужны математические доказательства, было показано, что это можно сделать - для простого программного обеспечения по цене, превышающей любые реалистичные бюджеты, для сложного программного пакета, ну, это все еще исследование ... У НАСА есть модели для написания высоконадежного программного обеспечения. в экономически управляемых ценах, как DoD и авиационная промышленность - хотя все еще намного выше, чем большинство готовы платить. В конце концов, все сводится к тому, сколько вы готовы заплатить .....

Изменить: я просто перечитал вас ОП. Кажется, вы ищете быстрый и дешевый способ проверить качество сложного программного обеспечения. Вы не можете проверить качество. Вы должны иметь надежный процесс, чтобы вы знали, что то, что построено, работает правильно. Если вам нужно подумать о том, как доказать, что это правильно, и у вас уже есть «большое и сложное приложение», вы опоздали.

Мы один из конкурентов Google. Наш ответ? В основном два.

Во-первых, мы рассчитываем полное адресное решение. Да, это большая матрица. Еще хуже, мы делаем это для всех времен дня, всех дней недели. Существует достаточное сходство во входной области для кэширования промежуточных результатов, что делает проблему доступной. Тем не менее, попробуйте получить оптовую ставку на жестких дисках.

Обратите внимание, что это автономное вычисление выполняется с использованием другого алгоритма. Он использует гораздо больше памяти, чем алгоритм, который мы намереваемся протестировать, но не линейно больше (то есть он использует менее чем в 1000 раз больше памяти при вычислении тысячи маршрутов).

Во-вторых, участвующие пользователи предоставляют нам реальные результаты. Мы проверяем миллионы пройденных маршрутов. Являются ли реальные маршруты такими же быстрыми, как и предполагалось?

И конечно, вы находите ошибки именно таким образом. Постоянно. Например, участок дороги, ограниченный с обеих сторон «зоной только местного движения» *. Есть только один способ;) что вы найдете это в тестировании, и именно тогда вы планируете маршрут к этой конкретной дороге.

_{* «Зона только для местного трафика» может использоваться только когда вы начинаете или заканчиваете маршрут в такой зоне. Поэтому участок посередине отсоединен от главной дорожной сети. Это ошибка зонирования или карты.}

Это не так, как Google пишет отдельный код для каждой пары адресов в мире. За исключением эвристики, которая включается в большем масштабе, алгоритм для 3-этапного путешествия точно такой же, как и для 3000-этапного. Вы тщательно тестируете более короткие пути и используете индукцию, чтобы показать, что тестирование применимо и к более длинным трассам.

Вы выбираете здоровый образец реальных маршрутов и сравниваете его с тем, что придумывает человек. Вы уделяете большое внимание отзывам конечных пользователей в своих первых выпусках и облегчаете их предоставление. Вы проверяете граничные условия, например, если лучший маршрут действительно требует некоторого времени отъезда от пункта назначения или если самый короткий маршрут на расстоянии имеет 18 поворотов по сравнению с более прямым маршрутом, который немного длиннее. Вы проводите отрицательное тестирование, например, если вы пытаетесь ехать из Калифорнии на Гавайи, и убедитесь, что на месте есть умные пасхальные яйца.