考えは、可能な限り多くのオプションをテストすることです。 当然、これには深刻なリソースが必要です。 Chromeをテストするために、数百台の仮想マシンで構成されるClusterFuzzサーバーのクラスター全体が作成されました。
1つのクラスターで約6,000個のChromeインスタンスが同時に動作します。 クラスターは、Chrome LKGR（Last Known Good Revision）の最後のビルドを自動的に取得し、 1日に約5,000万のテストケース後に実行します。
GoogleはClusterFuzzでリソースをspareしみません。2011年後半にシステムが開始されて以来、その容量は4倍になり、今後数週間でさらに4つを増やす予定です。
システムは、テストの生成と障害の登録だけでなく、より高いレベルの多くのタスクも自動化されます。
- テストケースの均等なストリームを生成し、数千のChromeインスタンスに分散して、結果を処理します。
- 障害分析：障害のみが重要であり、情報セキュリティの観点からエクスプロイトにつながる可能性があるため、ここではAddress Sanitizerメモリのクイックエラーディテクターを使用してソースコードを処理し、バイナリの特別なバージョンを取得し、潜在的なケースに関する詳細なレポートを提供しますエクスプロイトに適しています。
- テストの最小化：ファジングのテストは多くの場合非常にかさばるファイルであり、通常はそれぞれ数百キロバイトです。したがって、ジェネレーターの後、これらのファイルはより小さく重要なフラグメントに分割されます。
- 回帰識別：クラッシュを引き起こしたソースコードの変更を検索します。
- パッチ検証：新しいLKGRアセンブリで以前に特定された障害を確認します。
昨年末にClusterFuzzクラスターを開始して以来、Chromeテストビルドに95のユニークな脆弱性が発見されました。 これらのうち、44個が特定され、このコードが安定したリリースに達する前にクローズされました。 Googleは、システムをアップグレードした後、安定したリリースでリリースされるまで、Chromeのベースとなっているオープンソースプロジェクトとそれ自体の両方でさらに多くのエラーを修正することを望んでいます。 これには、 WebKitおよびFFmpegが含まれます。