Flakyとその判別方法の解説 #D3QA /FlakyTests

■John Micco氏の基調講演資料
http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf

■JaSST'18 Tokyoの開催レポート（公式）
http://jasst.jp/symposium/jasst18tokyo/report.html

■本スライドの元となったブログ記事
http://nihonbuson.hatenadiary.jp/entry/2018/03/10/110000

■#JaSST '18 TokyoのMicco氏のチュートリアルを復習し、少しデータで遊んでみる
http://www.kzsuzuki.com/entry/flakyTest

以下の勉強会で発表しました。
https://d-cube.connpass.com/event/83288/

Transcript

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