オルタナティブ・ブログ > 吉政忠志のベンチャービジネス千里眼 >

IT業界でベンチャービジネスの支援をしている執筆者が日々の活動ログと感じたことを、徒然なるままに書き綴っていきます。

グーグルのクラウドを支えるテクノロジー > 第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

Comment(0)

コメント

コメントを投稿する