Mozilla HacksのTesting Firefox more efficiently with machine learningを読みました。Firefoxの巨大なCIで、どのテストをどの構成で走らせるべきかを機械学習で選ぶ取り組みを紹介している記事です。
Firefoxには約85,000個のテストファイルがあり、Windows、macOS、Linux、Android、PGO、debug、ASan、Site Isolation、WebRenderなど、多数の構成で動かす必要があります。記事では、すべてを全構成で全pushごとに走らせると、1日に約23億件のテストファイル実行になり得ると説明されています。つまり、品質を守るにはテストが必要ですが、全部を機械的に走らせるだけではCIが持ちません。
記事の要点
- MozillaのCIは、統合ブランチでは一部テストを走らせ、定期的に広い範囲を確認し、code sheriffsが回帰を調査する運用になっています。
- 従来の単純なヒューリスティックは、過去に失敗しやすいタスクを重視していましたが、変更内容そのものとは強く結びついていませんでした。
- 新しい取り組みでは、過去の回帰データ、変更されたファイル、diff、テストとの距離、過去に一緒に変更された履歴などを使って、どのテストが失敗しそうかを予測します。
- モデルにはXGBoostが使われ、入力は「TEST, PATCH」の組み合わせ、出力はFAIL / NOT FAILの二値分類として扱われています。
- さらに、テストを選ぶだけでなく、どのOSや構成で走らせるかも最適化し、冗長な構成を減らします。
- 結果の評価には、回帰検出率とpushあたりの時間を組み合わせた独自指標を使い、shadow schedulerで実験を継続しています。
参照リンクから見えたこと
記事中のActiveDataは、テスト結果のような大量データを集計・検索する基盤として紹介されています。機械学習以前に、まず過去のテスト実行結果を使える形で持っていることが前提になっています。
bugbugは、Mozillaのソフトウェアエンジニアリング向け機械学習プロジェクト群の基盤です。記事末尾では、このテスト選択の取り組みも、Bugzilla管理支援から広がった大きな機械学習基盤の一部として位置づけられています。
また、Firefox Source Docsのmach try autoを見ると、開発者が手でテスト構成を選ぶ負担を減らす方向が分かります。rust-parsepatchやrust-code-analysisも、パッチ内容を機械が理解できる特徴量へ変換するための部品としてつながっています。
気づき
今回の気づきは、この機械学習の目的が「AIでテストを賢くする」こと自体ではなく、CIという開発基盤のコストと開発者の認知負荷を同時に下げることにある点です。モデルの偽陽性は余分なテストを少し走らせるだけで済みますが、偽陰性は回帰を見逃します。だから精度だけではなく、回帰検出率、実行時間、実験用shadow schedulerまで含めて、運用可能な意思決定システムとして設計されています。
コメントを残す