読者です 読者をやめる 読者になる 読者になる

#ICST2017 基調講演「The State of Continuous Integration Testing at Google」聴講レポート

ICST2017

はじめに

  • ICST2017の中で、「The State of Continuous Integration Testing at Google」というタイトルでGoogleのエンジニアであるJohn Miccoさんが基調講演を行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation

発表スライド

http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf

今日話すこと

  • Googleのテストの状況を話す
  • 開発者が3万人頑張っている

Googleについて

  • 420万のテストケースが継続的に動いている
  • 1億5千万のテストケースが動いている
  • ほぼ全てが自動化されている
  • Googleは自動テストが好き
  • 開発者はテストに時間をかけられません
  • 1万3千行のプロジェクトチームがある
  • 99%がテストに合格している
    • 失敗することはたまにある

テスト文化について

  • 自動化テストを促進する文化がある
  • 10年の文化がある
  • コードビューがある
  • テストの経験についても話し合う
  • Googleの新入社員に対してテストの仕方を教える
  • SETIでテストについて教えている
  • コードビューでモニターしている
  • チームに取り込まれているプラクティスを行う
  • 他にも色々行われている
  • 420万のテストは開発者が行っている

回帰テスト

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
  • 例えばfoo.hを選んだ場合は赤部分のところをテストする(スライド5ページ)
  • 選択が適切にできればスケジュール化しなくても良くなる
  • クレームから状況を解析して行う
  • 1秒間に変更を2つ行うとBackendが追いついていかなくなる

Presubmit testing

  • 粒度の細かい従属性について見ていく
  • 同じプールを使って
  • Presubmit testを上手く使ってコミットを行う
  • コードビューツールがテスト結果を検知して却下したりする
  • 開発者の判断ミスによって壊れないようにする

Postsubmit testing

  • リグレッションテストが上手く行っても、それでOKではない
  • テストの優先順位は付けない
    • 時間がかかるし
  • なるべく並列に行う
  • Backendとしてキャパシティがあるか確認する
  • スケジューリングの場合、どこかが空かないとやれないから
  • passしたらflagをたてて変更を書ける
  • 2年間のテスト結果やコンソールログを保存している(DBに入れている)
    • どのようなファイルのエディットをしたかなど

グラフ

  • チャンジリストを表している(スライド10ページ)
  • 横軸が時間、縦軸が個々のテストを表現している
  • グラフの1つ目の縦軸は回帰テストを4つ行うことを表している
  • 今までの変更を見て、マイルストーンを引いて、多くのテストのトリガーを引くことになる
  • キャパシティが溜まった時にテストが行われる
  • 45分間ごとにテストを実行される
  • 1日1回45分ぐらいで行われる
  • 最も直近で影響を受けた変更を探し出す(スライド11ページ)
  • きちんと順番通りになっていない可能性もある(スライド12ページ)
  • これをDBに入れて、どれがGreenなのか探す
  • 失敗した場合、何が原因で失敗だったのかを明らかにする(スライド14ページ)
  • どの変更がBreakしたのか判断する必要がある
  • 回帰試験のセレクションをして、スケジューラが必要になる
  • これを塊にしなければならない
  • キューに入れてバッチに入れる
  • もしある特定のシステムが受けた場合、システムのものなのかユーザーのものなのか明らかにする
  • ツールが失敗した場合は再実行を行う
  • 開発者のサブミッションと合格・不合格の判断をなるべく速くする
  • マイクロスケジューリング
  • 原因がどこにあるのか
  • ケースのリストアップをしていく
  • ギャップを埋めていく
  • 開発者が破壊する恐れがある
  • 限られたリソースで済むようにする
  • 破壊実験をしていく

Flaky(スライド21ページ)

  • あてにならないテストのこと。
  • コード以外のものには従属していない
  • テストのアイソレート化、切り分けが必要
  • 全体の16%はFlakyである
  • プロダクトのリリースをブロックすることが多い
    • 全てのパスしなければいけない
  • 16%はいつかFlakyになる
    • 全体で1万近くのテストがあるので1000近くある
  • 何か問題があるとFlakyだから、となってしまう
  • 2%〜16%はFlakyテストを再送されることになる
  • このFlakによって赤信号になってしまう
  • マイクロスケジューラだとパスするかなと思うかもしれないが、緑にするためには、Flakyもクリアする必要になる
  • プロダクションコストに関してはフレーキになる
  • どのくらいのコストがFlakyにかけてしまうのか

  • 何が原因なのか

  • テスト実行の1.5%がFlakyの継続率になる

    • これをFixさせないといけない
      • Fixさせるのは時間がかかる
  • Flakynessを緩和しないといけない

システム

  • Flaky testを認識する
  • failedになると、Flakyになるか確認する
  • 10回それを走らせてFlakyであると判断する
  • スタックトレースもDBに保存する
  • Flakynessレベルに変更になる。(1%のFlaky率から5%のFlaky率に変更など)
  • 自動テストをして、Flaky状態も管理する
    • 例えば、50%のFlakyになるGmailは上手くいかないだろう、とか

OSS

  • Bazelなどのように、OSS化して公開しているものもある(Bazel.io)

学会のリサーチについて

  • OSSプロジェクトのものに対して仮説をたてる
    • 実用性には欠ける
  • Sponser resercherの方々や学生に協力を頂いて、データセットのペーパーを出している
  • Googleコードベースも仮説をたてている
  • 1つのテストがFailになった時に何が原因なのか調査している
  • 1億5000万のテストの結果をOpenにしている
  • 業界と学会のコラボレーションで解決ができるはず
  • API frameworkも作成している
  • かなりのビジネスチャンスがある
  • インターンシップもある
  • journal clubに参加すると、月刊誌をお送りする

質問

3rdPartyについて

  • 異なる言語の自動化をどのように行っているのか
  • また、テストコードと開発コードを同じ言語ですべきか
  • 他の言語で書くこともできるが、枠組みとしては同じ言語で行う
  • 慣れ親しんでいる言語で行う

コンカレンシー問題

  • Flakyテストだとコンカレンシー問題があると思う
  • Flakyの診断をする。もう一度実行するなどを行う
  • ある程度のレベルのFlakynessはあるがそこまで心配していない
  • パーフェクトな状態ではない

マニュアルテストとの兼ね合いについて

  • マニュアルテストとのリンクにしているのか
  • マニュアルでメンテを行っている
  • 必要でないdependencyは削除しているが、基本的にはマニュアルで行う
  • 過度に依存している問題はあるが許容する必要がある

包括的なテストについて

  • 包括的なテストであるが、どのような形でどのタイプを行うと選択しているのか。
  • ある制約がある
    • どのくらいの規模で…
      • 15分
      • 4Coreで
  • E2EテストはFrameworkの中で行う
  • 大きなインテグレーションテストを行う時、45分の中でテストをしていく。
  • システムテストだけではなく必ずUnit testとシステムテストの両方が必要である

Flag optionについて

  • Flagの組み合わせの問題に直面にしなかったのか。
  • 全ての組み合わせをテストするのは不可能ですよね?
  • Flagの組み合わせに対しては相当きつい制約をしている。
    • 例えば、キャッシングに制約をかけるようにしている。
  • 例外にすることはできるがほとんどしていない。
  • Optが失敗してDebugが成功することもあるが…。

  • 400万のこーどがあると言っていたが…。

  • プロダクションテストはあるが、その他のテストはしない。
  • 新しいVersionとして全てうまくいくか
  • プロダクションサーバイメージに対して行う
  • sandboxテストとプロダクションテストは違うということか?
  • そうです
  • これはABテストか?
  • そういうことです

420万のテストケースについて

  • 420万のテストケースは増えていっているのでしょうか?
  • テストプールは常に増えていっている
  • テストケースの最適化は行っているのか?
  • 自動化の分析は行っていない。
  • ただしテスト品質の解析をしている。
  • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない
  • Backendが有限になると思うと、テストの質に意識するようになった。
  • テストについても何らかの責任をもたせることは大切

  • UTestで開発者が作ったもの。自動的なケース。自動化で良い点。どこでどこで使われているのか

  • テストを書くことが企業理念になっている
  • テストリソースを消費してしまう
  • 探求にも時間がかかってしまう

感想

  • テストケースをbreakした時の判断の仕方が良いなと感じた。
  • 「Flaky」という言葉を使って、テストの種別をするというやり方は参考になった。