Googleマップの「ルート検索」機能をどのようにテストしますか？

（これは良いインタビューの質問になると思いますが、私の場合はそれよりも実用的です。）

数十の化学成分間の非常に長く洗練された化学反応プロセスをモデル化する大規模で複雑なアプリケーションがあります。私たちは、アプリケーションの受け入れテストを設計する段階にありますが、テストするのに手に負えないほどの数の可能性のあるパスにやや気が進まないのです。私たちの状況は、Googleマップの開発チームが「ルートの取得」機能でルート計画アルゴリズムをテストするときに直面したものと非常によく似ていることがわかりました。明らかに、すべての可能なルートをテスト（検証および検証）することはできませんでした。では、どのような状況でもアプリケーションが機能するという自信をどのようにして得たのでしょうか？

そして、私は彼らがそれをどのようにしたかを知ることを期待していないので、あなたに尋ねましょう：特定のアプリケーションが堅牢であることを満足させるために、適切なコードカバレッジを備えたテストスイートをどのように設計しますか？システムを通るすべての潜在的な経路を調査するために？

私が探しているのは、手に負えない問題を小さく扱いやすい部分に分解するために使用する原則です。その合計は、全体の満足のいく推定を提供します。「すべてをテストすることはできませんが、これをテストすることはできます、これ、そしてこれで十分です。」「確かに正しい」アプローチを探しているのではなく、実際の予算/時間の制約を考慮して、慎重なアプローチを探しています。

（Googleマップの例を使用して、できるだけ具体的な回答を求めています。）

私は10年以上前にカーナビゲーションの分野で働いていました。

ステップA）参照パッケージを使用して、大きなサンプルセットを選択し、A / Bテストを実行します。正確さを求めず、外れ値を探します-参照セットはReroute 1234を10.34kmとして示し、123.5kmを計算しました。

ステップB）-ソフトウェアと参照ソフトウェアを改良します-サンプルを追加し、許容誤差を減らします。

ステップC）-グローバルデータセット全体のローカルな知識を使用した社内テスト。

ステップD）UAT ...「ユーザー受け入れテスト」「これを販売して、顧客が最も不満を持っているものを確認する」のように

1990年代半ばから2000年ごろまでにマッピング製品を使用したことがあるなら、私が何を意味するか知っているでしょう。

質問の例に戻ります。あなたが求められているのは、ソフトウェアが正しいことを証明する方法です。数学的な証明が必要な場合、それができることが示されています-現実的な予算を超える価格の単純なソフトウェア、複雑なソフトウェアパッケージ、それはまだ研究中です...国防総省や航空業界と同様に、経済的に管理可能な価格内で-しかし、ほとんどの人が支払おうとするよりもはるかに高い。最終的には、あなたがいくら支払う準備ができているかによって決まります.....

編集：私はあなたのOPを読み直します。あなたが探しているのは、複雑なソフトウェアの品質をテストするための迅速で安価な方法のようです。品質をテストすることはできません。構築されたものが正しく機能することを知るには、堅牢なプロセスが必要です。それが正しいことを証明する方法について考えなければならず、すでに「大規模で複雑なアプリケーション」を持っているなら、手遅れです。

私たちはGoogleのライバルです。答えは？基本的に2つ。

まず、完全なアドレス間ソリューションを計算します。うん、それは大きな行列です。さらに悪いことに、1日のすべての時間、すべての曜日にそうします。入力ドメインには中間結果をキャッシュするのに十分な類似性があるため、問題を扱いやすくしています。それでも、ハードディスクのバルクレートを取得してみてください。

このオフライン計算は別のアルゴリズムを使用して行われることに注意してください。テストするアルゴリズムよりもはるかに多くのメモリを使用しますが、直線的には使用しません（つまり、1000のルートを計算するときに使用するメモリは1000倍未満です）。

第二に、参加しているユーザーは実際の結果を提供してくれます。何百万ものルートが検証されています。実際のルートは予測どおりの速さですか？

そして、あなたはそのようにしてバグを見つけます。いつも。たとえば、両側が「ローカルトラフィックのみのゾーン」*で区切られた一続きの道路です。唯一の方法があります;）テストでそれを見つけるのは、その特定の道路へのルートを計画するときです。

_{*「ローカルトラフィック専用ゾーン」は、そのようなゾーンでルートを開始または終了するときにのみ使用できます。したがって、中央のストレッチはメインの道路網から切り離されています。これは、ゾーニングまたはマップ障害です。}

Googleが世界中のアドレスのペアごとに別々のコードを書くわけではありません。大規模に開始されるヒューリスティックを除き、3脚の旅のアルゴリズムは3000脚の旅とまったく同じです。短いパスを徹底的にテストし、誘導を使用して、長いパスにもテストが適用されることを示します。

実際のルートの健全なサンプルを選択し、人間が思い付くものと照合します。最初のリリースでは、エンドユーザーのフィードバックに多くの注意を払い、簡単に提供できるようにします。最適なルートが実際に目的地からしばらく離れる必要がある場合や、距離による最短ルートがわずかに長い直接ルートと比較して18ターンある場合など、境界条件をテストします。カリフォルニアからハワイへ車で行こうとしている場合など、ネガティブなテストを行い、賢いイースターエッグが所定の位置にあることを確認します。