Open1

フレーキーテストの処方箋💊

Urushihara TakeruUrushihara Takeru

フレーキーテストの処方箋(2023)

フレーキーテストとは

落ちたり落ちなかったり、結果が不安定なテスト。テストレイヤーは関係ない。

以下の投稿はフレーキーテストにたどり着いた人が嬉しそうなやつ
https://qiita.com/seigot/items/bec2c934b762a2f50821

フレーキーテストへの処方箋

Retry

  • 再試行しないと安定しているか不安定なのか判別がつかない
  • フレーキーテストが検知されない状況でも、潜在的に存在している可能性があるため、存在するしないに関わらない

優先度づけ

  • すべてに対応できる状況は稀。というかトレードオフを考えた時に99%ありえない(勘)

原因分析&修正

  • 起きているフレーキーテストの種類を把握し、修正順序と修正方法を考える[1]

具体的なアクション

必要なアクションを整理する。

  • [✅最低限]テストケースをRetryする
  • [🔘オプショナル]ログやmetricsを取る
  • [🔘オプショナル]原因を分析&修正する

複数回のRetryが必要という点ですでに手動テストというアプローチは厳しい。
また、ログやmetricsを毎回取るのも非現実的。
そのためここは自動テストで巻き取れると嬉しい。

原因の分析と修正については、システムによって早い段階からアプローチが違ってきそうで、本件の調査対象ではないのでここでは言及しない。

世間のアプローチ

Spotifyのアプローチ[2]

spotifyはフレーキーテストに対してグラフを用いたアプローチをしている。

縦軸がテストケースで、横軸が日付。

「縦軸が連続しているとき、それは何らか根本的な原因があるのでフレーキーではない」というスタンスっぽい。逆に「規則性のないものはフレーキーだ」というスタンスっぽい。

Facebookのアプローチ[2:1]

テスト結果の種類を細分化している。まずコードが正しいか間違っているかの2択があり、コードが正しい場合に失敗する場合と成功する場合があるということを定義している。

これらすべての4ケースについて、テストの実行結果をもとにある数式に基づいてフレーキーかどうかを判断しているらしい。

DropBoxのアプローチ[2:2]

テストケースに対してstatusを与えている。
最初はHalthyで、1回でも落ちたものはNoisyと呼ばれる。

Noisyとされたものは前後のバージョンでの比較や再実行によってフレーキーなのかテストが壊れているのかを判定される。これが自動化されているらしい。

引用

脚注
  1. http://portal.amelica.org/ameli/jatsRepo/30/308007/html/index.html ↩︎

  2. https://www.publickey1.jp/blog/22/itjenkinsdevops_days_tokyo_2022_1.html ↩︎ ↩︎ ↩︎