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

by nihonbuson

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