グーグルのクラウドを支えるテクノロジー > 第79回 CI環境のテストを安全に効率化するアルゴリズム(パート2

※この記事は読者によって投稿されたユーザー投稿です:
  • 編集部の見解や意向と異なる内容の場合があります
  • 編集部は内容について正確性を保証できません
  • 画像が表示されない場合、編集部では対応できません
  • 内容の追加・修正も編集部では対応できません

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー > 第79回 CI環境のテストを安全に効率化するアルゴリズム(パート2)」を公開しました。

###

はじめに
 前回に続いて、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」を紹介します。今回は、Flaky(不安定な)テストの影響、そして、実際のアルゴリズムの評価結果を紹介します。
Flaky(不安定な)テストの影響
 前回は、テストデータの構成とアルゴリズムの評価方法の概要を説明しました。まず、テストデータについては、前回の図1のように、安全にスキップできるテスト(「Safe」フラグがついたもの)とスキップしてはいけないテスト(「Unsafe/Maybe Unsafe」フラグがついたもの)がありました。そして、それぞれのコミットに含まれるテストの中で、安全にスキップできるもの、すなわち、Safeフラグがついたものを発見するアルゴリズムについて、その性能を評価していきます。この際、前回の図2のように、すべてのコミットの中で、「Safeフラグがついたテストだけをスキップしたコミット」の割合を計算するわけですが、ここで言う「すべてのコミット」の範囲を明確にする必要があります。
 この際に問題なるのが「Flakyテスト」と呼ばれる不安定なテストの影響です。テストターゲットの中には、関連するコードを変更していないにも関わらず、タイミングによって、成功したり失敗したりするテストがあります。これは、テスト内容そのものに問題があるか、もしくは、コード以外の部分に失敗の原因があるものですので、コード変更のコミットごとにテストしても意味がありません。前述のテストデータの中には、このような不安定なテスト(Flakyテスト)が含まれており、これは、アルゴリズム評価の際に余計なノイズとなります。

この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai279.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アドベリフィケーション
広告のブランド保護に利用する広告テクノロジーで、広告配信システムと組み合わせて利 ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]