Як би ви протестували функцію "Отримати вказівки" на Картах Google?

(Я думаю, це було б гарним питанням інтерв'ю , але в моєму випадку це більш прагматично, ніж це.)

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

А оскільки я не сподіваюся дізнатися, як вони це зробили, дозвольте запитати вас: як би ви вирішили розробити тестовий набір з адекватним покриттям коду, щоб переконатись у тому, що дана програма є надійною - коли це буквально неможливо перевірити кожен потенційний шлях через систему?

Що я шукаю - це принципи, які ви б використали, щоб розбити нерозв'язну проблему на більш дрібні, простежувані фрагменти, сума яких дає задовільну оцінку всього: "Я не можу перевірити все, але можу перевірити це , це і це - і цього достатньо ». Я не шукаю підходу, який є "вірно правильним", а раціональнішого , враховуючи обмеження бюджету / часу в реальному світі.

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

Я працював у сфері автомобільної навігації понад десять років тому.

Крок А) Використовуйте довідковий пакет і виберіть великий набір зразків, запустіть тести A / B. Не шукаючи точності, шукаючи інших людей - Довідковий набір показав Reroute 1234 як 10,34 км, і ми обчислили 123,5 км.

Крок В) - Удосконаліть наше програмне забезпечення та довідкове програмне забезпечення - додайте більше зразків та зменшіть допуски.

Крок C) - Внутрішнє тестування з використанням місцевих знань у глобальних наборах даних.

Крок D) UAT ... "Тест на прийняття користувача" Як у "Продайте цей матеріал і подивіться, на що найбільше скаржаться клієнти"

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

Назад до вас на приклад питання. Те, що вас запитують - це довести, що частина програмного забезпечення є правильною. Якщо ви хочете мати математичне підтвердження, показано, що це можна зробити - для простого програмного забезпечення за ціною, що перевищує будь-який реалістичний бюджет, для складного програмного пакету, ну, це все ще дослідження .... НАСА має моделі для написання високонадійного програмного забезпечення в економічно керованих цінах, як це роблять DoD та авіаційна промисловість, хоча все ще набагато вищі, ніж більшість готові платити. Зрештою, це зводиться до того, скільки ви готові платити .....

Редагувати: Я просто перечитував вам ОП. Здається, що ви шукаєте - це швидкий і дешевий спосіб перевірити якість складного програмного забезпечення. Ви не можете перевірити якість. Потрібно мати надійний процес, щоб ви знали, що те, що побудовано, працює правильно. Якщо вам доведеться задуматися над тим, як довести, що це правильно, і у вас вже є "велике і складне додаток", ви запізнилися.

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

По-перше, ми обчислюємо повне рішення адреси до адреси. Так, це велика матриця. Ще гірше - ми робимо це на всі дні доби, у всі дні тижня. У вхідному домені є достатня схожість з кеш-проміжними результатами, що робить проблему простежуваною. Проте спробуйте отримати масовий показник на жорстких дисках.

Зауважте, що цей офлайн-розрахунок проводиться за допомогою іншого алгоритму. Він використовує набагато більше пам'яті, ніж алгоритм, який ми маємо намір перевірити, але не лінійно більше (тобто він використовує менше 1000 разів більше пам’яті при оцінці тисячі маршрутів).

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

І звичайно, ви знайдете помилки саме таким чином. Усі часи. Наприклад, ділянка дороги, яка з обох боків обмежена "зоною лише для місцевого руху" *. Є лише один спосіб;), що ви збираєтеся знайти це під час тестування, і саме тоді ви плануєте маршрут до конкретної дороги.

_{* "Зону лише для місцевого руху" можна використовувати лише тоді, коли ви починаєте або закінчуєте маршрут у такій зоні. Тому ділянка в середині відключається від основної дорожньої мережі. Це або зонування, або карта.}

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

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