はじめに
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秒間に変更を２つ行うと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にかけてしまうのか
何が原因なのか
- マルチスレッド
- Backend
- アーキテクチャの問題
テスト実行の1.5%がFlakyの継続率になる
- これをFixさせないといけない
- 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は良くないから
- システムテストだけではなく必ずUnit testとシステムテストの両方が必要である
Flag optionについて
- Flagの組み合わせの問題に直面にしなかったのか。
- 全ての組み合わせをテストするのは不可能ですよね？
- Flagの組み合わせに対しては相当きつい制約をしている。
- 例えば、キャッシングに制約をかけるようにしている。
- 例外にすることはできるがほとんどしていない。
Optが失敗してDebugが成功することもあるが…。
400万のこーどがあると言っていたが…。
- プロダクションテストはあるが、その他のテストはしない。
- 新しいVersionとして全てうまくいくか
- プロダクションサーバイメージに対して行う
- sandboxテストとプロダクションテストは違うということか？
- そうです
- これはABテストか？
- そういうことです
420万のテストケースについて
- 420万のテストケースは増えていっているのでしょうか？
- テストプールは常に増えていっている
- テストケースの最適化は行っているのか？
- 自動化の分析は行っていない。
- ただしテスト品質の解析をしている。
- 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない
- Backendが有限になると思うと、テストの質に意識するようになった。
テストについても何らかの責任をもたせることは大切
UTestで開発者が作ったもの。自動的なケース。自動化で良い点。どこでどこで使われているのか
- テストを書くことが企業理念になっている
- テストリソースを消費してしまう
- 探求にも時間がかかってしまう
感想
- テストケースをbreakした時の判断の仕方が良いなと感じた。
- 「Flaky」という言葉を使って、テストの種別をするというやり方は参考になった。
