Share
Embed
Slide 1
Slide 1 text
GoogleのJohn Micco氏による
Flakyなテストと
その判別方法の解説
@nihonbuson
Slide 2
Slide 2 text
はじめに
● 今回の発表は、John Micco氏の発表を
イベント参加者が勝手にまとめたものです。
– 一応、John Micco氏から許可は貰っています。
● John Micco氏の基調講演資料はこちら
– http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf
● JaSST'18 Tokyoの開催レポート（公式）はこちら
– http://jasst.jp/symposium/jasst18tokyo/report.html
Slide 3
Slide 3 text
はじめに
● 私はJohn Micco氏の発表を日本で3回聴講
– ICST2017 （ソフトウェアテストの国際カンファレンス）
– JaSST'18 Tokyo（テストシンポジウム） 基調講演
– JaSST'18 Tokyo チュートリアル
● これらの内容から、今回は以下の2つに絞って紹介
– Googleの自動テストについて
– Flakyについて
● イベント記事はこちら（今回の発表内容も含む）
– http://nihonbuson.hatenadiary.jp/entry/2018/03/10/110000
この記事が長いので
スライドを作成することに…
Slide 4
Slide 4 text
本スライドの狙い
● John Micco氏の発表内容を元に、
Googleの取り組みを知ろう。
● Googleといえど、特殊なことをしているわけではない
ということを知ろう。
● 「JaSSTで有益な発表があったんだ」と知ってもらい、
次回以降のJaSSTに参加したいと感じてもらおう。
Slide 5
Slide 5 text
Agenda
● はじめに
● Googleの自動テストの内容
● Googleの自動テストリソースを減らす取り組み
● Flaky Testsとは何か
● チュートリアルから見るFlakyの世界
● おわりに
Slide 6
Slide 6 text
Googleの
自動テストの内容
基調講演資料ページ数
基調講演資料ページ数
Slide 7
Slide 7 text
Googleの自動テスト
● 自動テストは2種類ある
– Presubmit Testing と Postsubmit Testing
● 継続的に420万件のテストケースが実行されている。
● 1日に1億5千万のテストケースが動いている。
● 全ての結果はDBに保存している。
● ほぼすべてのテストが自動化されている
– 手動なのは、UXと多言語対応のみ
P2
P2
Slide 8
Slide 8 text
Regression Test Selection(RTS)
● 依存関係から対象となるテストケースを見つける。
● 下記のfoo.hの場合はfoo_testとbar_testが対象。
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=5
P5
P5
Slide 9
Slide 9 text
Presubmit Testing
● RTSを用いて、依存関係からテストする
● コミットごとに分離してテストする
● テストがPass→提出OK
● コードレビュー画面にもテスト結果情報が掲載される
● だいたい2秒に1回はテスト実行
P6
P6
Slide 10
Slide 10 text
Postsubmit testing
● 「420万件のテストケースが実行」はコッチの話。
● ある程度の塊(約45分)で1回の実行を行う。
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=8
1回のテスト実行
1回の変更
P8
P8
Slide 11
Slide 11 text
Postsubmit testing
● テストが失敗したら、そのテストケースが実行される
原因となったプロダクトコードの変更を探す
● すべてのテスト結果をDBに保存する（2年間）
P12
P12
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=12
Slide 12
Slide 12 text
理想的な自動テスト
● その1…テストが失敗した瞬間に原因のコードが分かる
– テストとプロダクトコードが1:1なUnitテストはまさにこれ
– 影響が大きなプロダクトコードが存在（ライブラリとか）
● その2…コミットが入るたびに、全テストが流れる
– リソースの問題で実現できない
● その3…コミットが入るたびに、影響がある
失敗するテストだけが流れる
– 「影響がありそう」「失敗する可能性が高い」テストなら
見つけられるかも
Slide 13
Slide 13 text
影響があるテスト
38
90
2604
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=14
P14
P14
Slide 14
Slide 14 text
影響があるテスト
● 420万件のテストケースのうち…
– コード全体の半分の箇所のいずれかを変更した場合、
38のテストケースは失敗する可能性がある。
● 38のテストケースは影響範囲が大きいテスト
– コード全体の90%の箇所のいずれかを変更した場合、
2604のテストケースを実行する必要がある。
● 420万件の残りのテストケースは局所的な部分のテストである。
P14
P14
Slide 15
Slide 15 text
失敗するテスト
● 実行したテストの99.8%はテストが成功する。
– 残り0.2%のテストのみを実行したい！
– プロジェクトに関係ない失敗は無視したい！
P15
P15
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=15
Slide 16
Slide 16 text
Googleの
自動テストリソースを
減らす取り組み
基調講演資料ページ数
基調講演資料ページ数
Slide 17
Slide 17 text
取り組み1. Greenish Service
● 各サービス毎にテストを紐づけている
● 決定論的ではなく確率論を用いて、
リスクを持って各サービス毎にリリースしている
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=19
P19
P19
Slide 18
Slide 18 text
取り組み2. Skip Tests
● 必要ないテストをスキップして、
テスト結果が変わる可能性が高いテストのみ実施
● 失敗し続けているテストよりも、「成功→失敗」や
「失敗→成功」の、結果遷移したテストが気になる。
スキップ
成功
失敗
Flaky
※後述で
説明
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=21
P21
P21
Slide 19
Slide 19 text
取り組み2. Skip Tests
1. 全体の96%はテスト結果の遷移が発生しなかった。
2. アルゴリズムがうまくいくと、全体の98%のテストをSkip
しても、結果遷移が発生するテストをすべて拾えた。
1
2
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=33
P33
P33
Slide 20
Slide 20 text
Googleでのテスト結果分析
● 成功→失敗の遷移の84%はFlakyテストが原因だった
– これが厄介
● 全体のテストの1.23%で不具合を発見した。
● 以下の場合に破損する可能性が高くなる
– ファイルが頻繁に変更される
– 3人以上の開発者がファイル変更に関わっている
● ペアプロ、モブプロの人数ではなく、別案件での人数
– 特定の人、自動テストが関わっている
– 特定の言語が関わっている
P34
P34
Slide 21
Slide 21 text
Flaky Testsとは何か
基調講演資料ページ数
基調講演資料ページ数
Slide 22
Slide 22 text
Flaky Tests
● あてにならないテストのこと
● 同じコードで成功と失敗の両方が観測できるテスト
● 420万件のうち16%のテストケースはFlakyである
● Flakyテストを再実行するのに、
リソースの2~16%を費やす
● Googleでは、Flaky Testsを全力で解決したい！
– Flaky Testsを無視したいわけではない
P35
P35
Slide 23
Slide 23 text
Flaky Testsの定義
● 以下の2パターンが存在する
– 1. テストが失敗したが、そのまま（コード変更せずに）
リトライしたら成功した
● 例えば、タイムアウトが5秒で、約4.9秒かかるページ遷移など
– 2. テストが成功（失敗）したが、次のタイミングで
もう一度テストを実行したら失敗（成功）した。
● おそらく、John Micco氏は、このどちらも
Flaky Testsと表現しているようだ。
● どちらにせよ、このFlaky Testsを見極めることが大切
Slide 24
Slide 24 text
チュートリアルから見る
Flakyの世界
チュートリアル資料ページ数
チュートリアル資料ページ数
Slide 25
Slide 25 text
チュートリアルの概要
● GoogleのテストケースをBigQueryを用いて実行。
● チュートリアルで使用したSQLなどは
以下のサイトにあります。
– https://github.com/jmicco/JaSST_tutorial
● チュートリアル資料は未公開
● 資料には の文字が！
– 私「Micco, これって公開しちゃまずいもの？」
– Micco「すまん、テンプレのままだったわ。公開OKさ！」
P2
P2
Slide 26
Slide 26 text
対象データ
● 対象データは以下の通り
– シンプルなデータ
● 1万件のテストケース
● 340万件のテスト結果
– Fullデータ
● 143万件のテストケース
● 5億件のテスト結果
P2,3
P2,3
testcase_id
pullrequest_id
読み替えるなら、
Slide 27
Slide 27 text
テスト結果の分類
● テスト結果を以下のように分類している。
– PASSED…テスト成功
– FAILED_TO_BUILD…ビルド失敗
– FAILED…テスト失敗
– INTERNAL_ERROR…テスト開始準備が失敗
– PENDING…実行開始しようとしたができなかった
– ABORTED_BY_TOOL…開始後15分超過で強制終了
– FLAKY…テスト失敗後、リトライしたら成功
● 失敗の責任者を明確にしている。
インフラの
責任
開発の
責任
P6
P6
Slide 28
Slide 28 text
Flakyを見極める
● 自動テスト失敗時に、
そのテストケースがFlakyである確率が高いかどうかの
情報も一緒に提供している
● Flakyかどうかの情報は以下の2つのアプローチがある
– 1. Flakyなテスト候補を特定する
– 2. Flakyでないテストを特定する
● これらは単純なSQLで示すことができる
– 次のページ以降で紹介
Slide 29
Slide 29 text
1. Flakyなテスト候補を特定する
● テスト結果の遷移に注目する。
● より多くの遷移があるテストはFlakyの疑いあり。
Flakyっぽい→
P7,8
P7,8
Slide 30
Slide 30 text
1. Flakyなテスト候補を特定する
(特定方法)
● テストケース毎の遷移数を抽出するSQL
– https://github.com/jmicco/JaSST_tutorial/blob/master/count_transitions.sql
P9
P9
結果例
Slide 31
Slide 31 text
1. Flakyなテスト候補を特定する
(結果) P10,11
P10,11
● 884回/月も結果の遷移が発生するケースが存在
● 4回/月以上の遷移は、340万件中7590ケース
– 3回/月以下は
Flakyではない（？）
● テスト結果を保存すれば
簡単にFlaky候補を
特定できる例
Slide 32
Slide 32 text
2. Flakyではないテストを特定する
● Flakyなテストケースは結果にランダム性あり
● Flakyではないテストケースはパターンが存在
● t4,t6やt2,t3,t5,t7は同パターンなのでFlakyではない
P12,13
P12,13
Slide 33
Slide 33 text
2. Flakyではないテストを特定する
(特定方法)
● 手順1. テストケースごとに遷移が起こった
チェンジリストIDを抽出するSQL
– https://github.com/jmicco/JaSST_tutorial/blob/master/target_transitions.sql
結果例
P16
P16
Slide 34
Slide 34 text
2. Flakyではないテストを特定する
(特定方法)
● 手順2. 手順1の結果を元に、同じ遷移のパターンに
なっているテストケースを抽出するSQL
– https://github.com/jmicco/JaSST_tutorial/blob/master/shared_history.sql
結果例
● 下記のような結果を基に
グラフを作成（次ページ）
P18
P18
Slide 35
Slide 35 text
2. Flakyではないテストを特定する
(結果)
● 横軸…同じパターンのテストケース数
● 縦軸…1ヶ月で遷移が発生した回数
● 赤…Flaky 5000ケース
以上が
同じパターン
→ライブラリの
修正が影響？
2ケースで
20以上の遷移が
まったく同じ
パターン
→Flakyでない
縦軸に接して
いるデータは
同じパターンが
存在せず
P15
P15
Slide 36
Slide 36 text
おわりに
Slide 37
Slide 37 text
おわりに
● Googleは、シンプルな内容を愚直に実施
– 特殊なことはしていない
● ここまで分析できる前提として、
自動テストによる大量なテストと
そのテスト結果をDBに保存、の2つの取り組みが存在
– 地道なテスト文化を作り上げたからこそ
● そのデータを分析することで、Flakyの判別にも活用
● Flakyの判別などを基に、
さらにリソースを省略したテスト実施を考えている。
Slide 38
Slide 38 text
参考文献
● JaSST'18 Tokyo基調講演
「Advances in Continuous Integration
Testing @Google」
– http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf
● GoogleのJohn Micco氏によるFlakyなテストと
その判別方法の解説 #JaSST
– http://nihonbuson.hatenadiary.jp/entry/2018/03/10/110000
● #JaSST '18 TokyoのMicco氏のチュートリアルを
復習し、少しデータで遊んでみる
– http://www.kzsuzuki.com/entry/flakyTest