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

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/

706ff501573a736401aa4de5adc88e05?s=128

nihonbuson

March 28, 2018
Tweet

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