$30 off During Our Annual Pro Sale. View Details »

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/

nihonbuson

March 28, 2018
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. GoogleのJohn Micco氏による
    Flakyなテストと
    その判別方法の解説
    @nihonbuson

    View Slide

  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

    View Slide

  3. はじめに
    ● 私はJohn Micco氏の発表を日本で3回聴講
    – ICST2017 (ソフトウェアテストの国際カンファレンス)
    – JaSST'18 Tokyo(テストシンポジウム) 基調講演
    – JaSST'18 Tokyo チュートリアル
    ● これらの内容から、今回は以下の2つに絞って紹介
    – Googleの自動テストについて
    – Flakyについて
    ● イベント記事はこちら(今回の発表内容も含む)
    – http://nihonbuson.hatenadiary.jp/entry/2018/03/10/110000
    この記事が長いので
    スライドを作成することに…

    View Slide

  4. 本スライドの狙い
    ● John Micco氏の発表内容を元に、
    Googleの取り組みを知ろう。
    ● Googleといえど、特殊なことをしているわけではない
    ということを知ろう。
    ● 「JaSSTで有益な発表があったんだ」と知ってもらい、
    次回以降のJaSSTに参加したいと感じてもらおう。

    View Slide

  5. Agenda
    ● はじめに
    ● Googleの自動テストの内容
    ● Googleの自動テストリソースを減らす取り組み
    ● Flaky Testsとは何か
    ● チュートリアルから見るFlakyの世界
    ● おわりに

    View Slide

  6. Googleの
    自動テストの内容
    基調講演資料ページ数
    基調講演資料ページ数

    View Slide

  7. Googleの自動テスト
    ● 自動テストは2種類ある
    – Presubmit Testing と Postsubmit Testing
    ● 継続的に420万件のテストケースが実行されている。
    ● 1日に1億5千万のテストケースが動いている。
    ● 全ての結果はDBに保存している。
    ● ほぼすべてのテストが自動化されている
    – 手動なのは、UXと多言語対応のみ
    P2
    P2

    View Slide

  8. Regression Test Selection(RTS)
    ● 依存関係から対象となるテストケースを見つける。
    ● 下記のfoo.hの場合はfoo_testとbar_testが対象。
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=5
    P5
    P5

    View Slide

  9. Presubmit Testing
    ● RTSを用いて、依存関係からテストする
    ● コミットごとに分離してテストする
    ● テストがPass→提出OK
    ● コードレビュー画面にもテスト結果情報が掲載される
    ● だいたい2秒に1回はテスト実行
    P6
    P6

    View Slide

  10. Postsubmit testing
    ● 「420万件のテストケースが実行」はコッチの話。
    ● ある程度の塊(約45分)で1回の実行を行う。
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=8
    1回のテスト実行
    1回の変更
    P8
    P8

    View Slide

  11. Postsubmit testing
    ● テストが失敗したら、そのテストケースが実行される
    原因となったプロダクトコードの変更を探す
    ● すべてのテスト結果をDBに保存する(2年間)
    P12
    P12
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=12

    View Slide

  12. 理想的な自動テスト
    ● その1…テストが失敗した瞬間に原因のコードが分かる
    – テストとプロダクトコードが1:1なUnitテストはまさにこれ
    – 影響が大きなプロダクトコードが存在(ライブラリとか)
    ● その2…コミットが入るたびに、全テストが流れる
    – リソースの問題で実現できない
    ● その3…コミットが入るたびに、影響がある
           失敗するテストだけが流れる
    – 「影響がありそう」「失敗する可能性が高い」テストなら
    見つけられるかも

    View Slide

  13. 影響があるテスト
    38
    90
    2604
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=14
    P14
    P14

    View Slide

  14. 影響があるテスト
    ● 420万件のテストケースのうち…
    – コード全体の半分の箇所のいずれかを変更した場合、
    38のテストケースは失敗する可能性がある。
    ● 38のテストケースは影響範囲が大きいテスト
    – コード全体の90%の箇所のいずれかを変更した場合、
    2604のテストケースを実行する必要がある。
    ● 420万件の残りのテストケースは局所的な部分のテストである。
    P14
    P14

    View Slide

  15. 失敗するテスト
    ● 実行したテストの99.8%はテストが成功する。
    – 残り0.2%のテストのみを実行したい!
    – プロジェクトに関係ない失敗は無視したい!
    P15
    P15
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=15

    View Slide

  16. Googleの
    自動テストリソースを
    減らす取り組み
    基調講演資料ページ数
    基調講演資料ページ数

    View Slide

  17. 取り組み1. Greenish Service
    ● 各サービス毎にテストを紐づけている
    ● 決定論的ではなく確率論を用いて、
    リスクを持って各サービス毎にリリースしている
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=19
    P19
    P19

    View Slide

  18. 取り組み2. Skip Tests
    ● 必要ないテストをスキップして、
    テスト結果が変わる可能性が高いテストのみ実施
    ● 失敗し続けているテストよりも、「成功→失敗」や
    「失敗→成功」の、結果遷移したテストが気になる。
    スキップ
    成功
    失敗
    Flaky
    ※後述で
      説明
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=21
    P21
    P21

    View Slide

  19. 取り組み2. Skip Tests
    1. 全体の96%はテスト結果の遷移が発生しなかった。
    2. アルゴリズムがうまくいくと、全体の98%のテストをSkip
      しても、結果遷移が発生するテストをすべて拾えた。
    1
    2
    http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf#page=33
    P33
    P33

    View Slide

  20. Googleでのテスト結果分析
    ● 成功→失敗の遷移の84%はFlakyテストが原因だった
    – これが厄介
    ● 全体のテストの1.23%で不具合を発見した。
    ● 以下の場合に破損する可能性が高くなる
    – ファイルが頻繁に変更される
    – 3人以上の開発者がファイル変更に関わっている
    ● ペアプロ、モブプロの人数ではなく、別案件での人数
    – 特定の人、自動テストが関わっている
    – 特定の言語が関わっている
    P34
    P34

    View Slide

  21. Flaky Testsとは何か
    基調講演資料ページ数
    基調講演資料ページ数

    View Slide

  22. Flaky Tests
    ● あてにならないテストのこと
    ● 同じコードで成功と失敗の両方が観測できるテスト
    ● 420万件のうち16%のテストケースはFlakyである
    ● Flakyテストを再実行するのに、
    リソースの2~16%を費やす
    ● Googleでは、Flaky Testsを全力で解決したい!
    – Flaky Testsを無視したいわけではない
    P35
    P35

    View Slide

  23. Flaky Testsの定義
    ● 以下の2パターンが存在する
    – 1. テストが失敗したが、そのまま(コード変更せずに)
    リトライしたら成功した
    ● 例えば、タイムアウトが5秒で、約4.9秒かかるページ遷移など
    – 2. テストが成功(失敗)したが、次のタイミングで
    もう一度テストを実行したら失敗(成功)した。
    ● おそらく、John Micco氏は、このどちらも
    Flaky Testsと表現しているようだ。
    ● どちらにせよ、このFlaky Testsを見極めることが大切

    View Slide

  24. チュートリアルから見る
    Flakyの世界
    チュートリアル資料ページ数
    チュートリアル資料ページ数

    View Slide

  25. チュートリアルの概要
    ● GoogleのテストケースをBigQueryを用いて実行。
    ● チュートリアルで使用したSQLなどは
    以下のサイトにあります。
    – https://github.com/jmicco/JaSST_tutorial
    ● チュートリアル資料は未公開
    ● 資料には                 の文字が!
    – 私「Micco, これって公開しちゃまずいもの?」
    – Micco「すまん、テンプレのままだったわ。公開OKさ!」
    P2
    P2

    View Slide

  26. 対象データ
    ● 対象データは以下の通り
    – シンプルなデータ
    ● 1万件のテストケース
    ● 340万件のテスト結果
    – Fullデータ
    ● 143万件のテストケース
    ● 5億件のテスト結果
    P2,3
    P2,3
    testcase_id
    pullrequest_id
    読み替えるなら、

    View Slide

  27. テスト結果の分類
    ● テスト結果を以下のように分類している。
    – PASSED…テスト成功
    – FAILED_TO_BUILD…ビルド失敗
    – FAILED…テスト失敗
    – INTERNAL_ERROR…テスト開始準備が失敗
    – PENDING…実行開始しようとしたができなかった
    – ABORTED_BY_TOOL…開始後15分超過で強制終了
    – FLAKY…テスト失敗後、リトライしたら成功
    ● 失敗の責任者を明確にしている。
    インフラの
    責任
    開発の
    責任
    P6
    P6

    View Slide

  28. Flakyを見極める
    ● 自動テスト失敗時に、
    そのテストケースがFlakyである確率が高いかどうかの
    情報も一緒に提供している
    ● Flakyかどうかの情報は以下の2つのアプローチがある
    – 1. Flakyなテスト候補を特定する
    – 2. Flakyでないテストを特定する
    ● これらは単純なSQLで示すことができる
    – 次のページ以降で紹介

    View Slide

  29. 1. Flakyなテスト候補を特定する
    ● テスト結果の遷移に注目する。
    ● より多くの遷移があるテストはFlakyの疑いあり。
    Flakyっぽい→
    P7,8
    P7,8

    View Slide

  30. 1. Flakyなテスト候補を特定する
    (特定方法)
    ● テストケース毎の遷移数を抽出するSQL
    – https://github.com/jmicco/JaSST_tutorial/blob/master/count_transitions.sql
    P9
    P9
    結果例

    View Slide

  31. 1. Flakyなテスト候補を特定する
    (結果) P10,11
    P10,11
    ● 884回/月も結果の遷移が発生するケースが存在
    ● 4回/月以上の遷移は、340万件中7590ケース
    – 3回/月以下は
    Flakyではない(?)
    ● テスト結果を保存すれば
    簡単にFlaky候補を
    特定できる例

    View Slide

  32. 2. Flakyではないテストを特定する
    ● Flakyなテストケースは結果にランダム性あり
    ● Flakyではないテストケースはパターンが存在
    ● t4,t6やt2,t3,t5,t7は同パターンなのでFlakyではない
    P12,13
    P12,13

    View Slide

  33. 2. Flakyではないテストを特定する
    (特定方法)
    ● 手順1. テストケースごとに遷移が起こった
    チェンジリストIDを抽出するSQL
    – https://github.com/jmicco/JaSST_tutorial/blob/master/target_transitions.sql
    結果例
    P16
    P16

    View Slide

  34. 2. Flakyではないテストを特定する
    (特定方法)
    ● 手順2. 手順1の結果を元に、同じ遷移のパターンに
    なっているテストケースを抽出するSQL
    – https://github.com/jmicco/JaSST_tutorial/blob/master/shared_history.sql
    結果例
    ● 下記のような結果を基に
    グラフを作成(次ページ)
    P18
    P18

    View Slide

  35. 2. Flakyではないテストを特定する
    (結果)
    ● 横軸…同じパターンのテストケース数
    ● 縦軸…1ヶ月で遷移が発生した回数
    ● 赤…Flaky 5000ケース
    以上が
    同じパターン
    →ライブラリの
    修正が影響?
    2ケースで
    20以上の遷移が
    まったく同じ
    パターン
    →Flakyでない
    縦軸に接して
    いるデータは
    同じパターンが
    存在せず
    P15
    P15

    View Slide

  36. おわりに

    View Slide

  37. おわりに
    ● Googleは、シンプルな内容を愚直に実施
    – 特殊なことはしていない
    ● ここまで分析できる前提として、
    自動テストによる大量なテストと
    そのテスト結果をDBに保存、の2つの取り組みが存在
    – 地道なテスト文化を作り上げたからこそ
    ● そのデータを分析することで、Flakyの判別にも活用
    ● Flakyの判別などを基に、
    さらにリソースを省略したテスト実施を考えている。

    View Slide

  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

    View Slide