Googleマップの「ルート検索」機能をどのようにテストしますか？
（これは良いと思います インタビューの質問 ですが、私の場合はそれよりも実用的です。）
大規模で複雑なアプリケーション があり、数十の化学成分間の非常に長く洗練された化学反応プロセスをモデル化しています。現在、アプリケーションの受け入れテストを設計する段階にありますが、テストすることが可能なパスの扱いにくい数にいくらか気を配っています。私たちの状況は、Googleマップの開発チームが「ルート検索」機能でルート計画アルゴリズムをテストするときに直面したはずの状況と非常に似ていることに気付きました。もちろん、すべての可能なルートをテスト（検証および検証）することはできませんでした。では、どのようにしてアプリケーションがすべての状況で機能するという確信を得たのでしょうか。
そして、私はtheyがどのようにそれをしたかを知ることを期待しないので、あなたに尋ねさせてください：どのようにあなたは適切なコードカバレッジを備えたテストスイートの設計に取り掛かり、特定のアプリケーションが堅牢であることを納得します-システムを通過する可能性のあるすべてのパスを文字通り調査することが不可能である場合？
私が探しているのは、扱いにくい問題を小さく扱いやすい断片に分解するために使用する原則です。それらの合計は、全体の満足のいく見積もりを提供します。「すべてをテストすることはできませんが、これをテストできます、これとこれ-それで十分です。」私は「確かに正しい」アプローチを探しているのではなく、実際の予算/時間の制約を前提として、prudentのアプローチを探しています。
（私は、可能な限り具体的な回答を求めるために、Googleマップの例をホイルのようなものとして使用しています。）
私は10年以上前にカーナビ分野で働いていました。
ステップA）参照パッケージを使用して大きなサンプルセットを選択し、A/Bテストを実行します。正確さを求めるのではなく、外れ値を探す-参照セットはReroute 1234を10.34kmと示し、123.5kmを計算しました。
ステップB）-ソフトウェアと参照ソフトウェアを改良します-サンプルを追加して許容誤差を減らします。
ステップC）-グローバルデータセット全体のローカル知識を使用した社内テスト。
ステップD）UAT ...「ユーザー受け入れテスト」「これを販売して、顧客が最も不満を持っていることを確認する」のように
1990年代中頃から2000年ごろにマッピング製品を使用したことがある人なら、私が何を意味するかを知っているでしょう。
例の質問に戻ります。あなたが求められているのは、ソフトウェアの一部が正しいことを証明する方法です。数学的な証明が必要な場合は、それが可能であることが示されています-現実的な予算を超える価格の単純なソフトウェアの場合、複雑なソフトウェアパッケージの場合、それはまだ研究中です... NASAには信頼性の高いソフトウェアを作成するためのモデルがあります経済的に管理可能な価格の範囲内で、DoDや航空業界がそうであるように-ほとんどの人が支払うよりもはるかに高いですが結局、それはあなたがいくら支払う準備ができているかにかかっています.....
編集：私はあなたにOPを再読するだけです。探しているのは、複雑なソフトウェアの品質をテストするための迅速で安価な方法です。品質テストはできません。ビルドされたものが正しく機能することを確認するために、堅牢なプロセスが必要です。それが正しいことを証明する方法について考える必要があり、すでに「大規模で複雑なアプリケーション」を持っている場合は、遅すぎます。
私たちはGoogleのライバルの1つです。私たちの答えは？基本的には2つです。
まず、完全なアドレス間ソリューションを計算します。うん、それは大きなマトリックスです。さらに悪いことに、私たちは一日中いつでも、それを行っています。入力ドメインには、中間結果をキャッシュするのに十分な類似性があるため、問題は扱いやすくなっています。それでも、ハードディスクのバルクレートを取得してみてください。
このオフライン計算は別のアルゴリズムを使用して行われることに注意してください。テストするアルゴリズムよりもはるかに多くのメモリを使用しますが、直線的にはそうではありません（つまり、1,000ルートを計算するときに使用するメモリは1000倍未満です）。
次に、参加しているユーザーが実際の結果を提供します。私たちは何百万ものルートを走行することを検証します実際のルートは予測どおりですか？
そして確かに、あなたはそのようにしてバグを見つけます。いつも。例えば。 「ローカルトラフィックのみのゾーン」*によって両側が区切られた道路のストレッチ。テストでそれを見つける方法は1つだけです;）その特定の道路へのルートを計画するときです。
*「ローカルトラフィックのみのゾーン」は、そのようなゾーンでルートを開始または終了するときにのみ使用できます。したがって、中央のストレッチは主要な道路網から切り離されています。これは、ゾーニングまたはマップの障害です。
グーグルが世界のアドレスのペアごとに別々のコードを書くのとは異なります。より大きなスケールで開始するヒューリスティックを除いて、3脚の旅のアルゴリズムは3000脚の場合とまったく同じです。短いパスを徹底的にテストし、誘導を使用して、テストが長いパスにも適用されることを示します。
実際のルートの健全なサンプルを選び、人間が思いついたものと照合します。最初のリリースでは、エンドユーザーのフィードバックにたくさんの注意を払い、エンドユーザーが簡単に提供できるようにします。最適なルートが実際に目的地からしばらく離れる必要がある場合や、距離が最も短いルートの方が少し長い直接ルートと比較して18ターンある場合など、境界条件をテストします。カリフォルニアからハワイに車を運転する場合のように、否定的なテストを行い、賢いイースターエッグが配置されていることを確認します。