フレーキーテスト: 原因、コスト、偽陽性を止める方法
不安定なテストと誤検出の解説: 正常に動くアプリでエンドツーエンドテストやビジュアルテストが失敗する理由と、本当のリグレッションを見逃さずにそれを止める方法。
読了 12 分更新日: 2026年11月6日執筆: Ait Nohaila (事業開発担当)
フレーキーテストとは、実行の間に何も変わっていないのに、同じコードで合格したり不合格になったりする自動テストのことです。その失敗は偽陽性です: 動いているアプリケーションについての誤報です。
赤いビルドが意味することは 1 つであるべきです: アプリケーションが壊れている、ということです。しかし実際には別のことを意味する場合が多すぎます: テストが早くクリックしすぎた、フォントが少し違う色合いで描画された、スピナーがまだ回っていた。これらがフレーキーテストと偽陽性であり、チームがエンドツーエンドテストを信頼しなくなる主な理由の 1 つです。
このガイドでは、コードで書かれたテストとビジュアルテストにおけるそれらの出どころと、本物のバグを通さずに偽陽性を止める方法を説明します。
フレーキーテストと偽陽性とは何か?
Definition
偽陽性とは、アプリケーションが正しく動いているのに不合格になるテストのことです。テスターはこれを偽の失敗や誤報とも呼びます。テストが警報を上げ、誰かが調べ、何も問題がない、というものです。
Definition
フレーキーテストとは、実行の間に何も変わっていないのに、同じコードで合格したり不合格になったりするテストのことです。フレーキーな失敗はすべて偽陽性です。ただし、すべての偽陽性がフレーキーなわけではありません: 期待画像が古いために毎回不合格になるテストは、フレーキーではなく、間違っているのです。
アプリケーションは動いている
アプリケーションは壊れている
テストは合格
テストは不合格
フレーキーか、本当に失敗しているか?
赤いビルドで最初に問うべきは、2 つのうちどちらを見ているかです。兆候が異なり、取るべき正しい行動も異なります。
| 見えるもの | その意味 | すべきこと |
|---|---|---|
| テストが不合格になり、同じビルドの再実行で合格した。 | フレーキー: 2 回の実行の間で何も変わっていません。 | テストを隔離し、原因を見つけて修正してください。緑になった再実行で問題を終わらせてはいけません。 |
| ある変更以降、テストが毎回不合格になる。 | 本当に失敗している: 変更が何かを壊したか、意図的に変えました。 | 不合格になったステップを読んでください。リグレッションは開発者に戻し、意図した変更は新しい期待結果にします。 |
| テストがあるマシンでは不合格になり、別のマシンでは合格する。 | 環境によるフレーキー: 画面サイズ、ブラウザーのバージョン、負荷、設定が異なります。 | テストを実行する環境を固定するか、環境ごとに 1 つの期待結果を持ってください。 |
| テストはスイート全体を実行したときだけ不合格になり、単独では決して不合格にならない。 | テストの順序や共有状態によるフレーキー: 別のテストが何かを残していきました。 | 各テストに独自のデータと開始点を与え、順序が関係しないようにしてください。 |
| テストがタイムアウトで不合格になり、毎回違うステップで止まる。 | タイミングによるフレーキー: アプリケーションの準備ができる前にテストが動いています。 | 固定の時間ではなく、条件 (要素、テキスト、スピナーの消失) を待ってください。 |
| テストが数ピクセルの差で不合格になるが、目に見える変化はない。 | 比較の偽陽性: 描画のノイズが変化として読まれています。 | ノイズを無視しつつ、人が気づく本物の差異では不合格になる方法で比較してください。 |
| テストが 20 回に 1 回ほど不合格になり、いつも同じステップで止まる。 | アプリケーションの本物の断続的なバグかもしれません。 | ノイズではなくバグレポートとして扱ってください。再現してから、アプリケーションを修正してください。 |
偽陽性がチームに与えるコスト
誤報 1 件のコストは調査 1 回分です。誰かがログを開き、テストを再実行し、何も見つけません。
- 本当のコストは後からやってきます。赤いビルドの大半がノイズになると、人はそれを読まなくなります: これがアラート疲れです。次に、バグを隠す習慣がやってきます: 緑になるまでテストを再実行する、新しいスクリーンショットを見もせずにすべてベースラインとして採用する、いつも失敗するテストを無効にする、といったものです。
こうした習慣の 1 つ 1 つが、今日の偽陽性を明日の偽陰性に変えます。テストが書かれた目的であるバグが素通りします: 誰ももうテストを信じていないからです。
規模は小さくありません。2016 年、Google のエンジニアリング生産性チームは、何千人ものエンジニアが実行するスイート全体で、全テスト実行の約 1.5% がフレーキーな結果を報告し、テストの 16% 近くに何らかのフレーキーさがあると書きました。テストがはるかに少ないチームも、同じ計算に直面します。
小さなフレーキーさがスイートとともにどう膨らむか
1,000 回に 1 回フレークする単独のテストは、無害に聞こえます。スイートはそれを掛け算にします: ビルドが緑になるにはすべてのテストが合格しなければならないので、確率も掛け合わされます。
この表は、アプリケーションに問題がなく、すべてのテストが同じ小さな確率でフレークするときに、スイート全体の実行が緑になる確率を示します。行はスイートの規模、列は各テストのフレーク率です。
| スイート内のテスト数 | 各テスト 0.1% でフレーキー | 各テスト 0.5% でフレーキー | 各テスト 1% でフレーキー |
|---|---|---|---|
| 50 件のテスト | 95 % | 78 % | 61 % |
| 200 件のテスト | 82 % | 37 % | 13 % |
| 500 件のテスト | 61 % | 8.2 % | 0.7 % |
| 1,000 件のテスト | 37 % | 0.7 % | < 0.1 % |
だからこそ、フレーキーさはテストの問題ではなくスイートの問題です。フレーキーテスト 1 件だけならコストは小さくても、まとまるとビルドを誰かが信じるかどうかを左右します。
フレーキーなエンドツーエンドテストの原因は何か?
エンドツーエンドテストはアプリケーション全体をそのインターフェイスを通じて動かすので、実際のユーザーが遭遇するすべてに遭遇します: 遅いサーバー、アニメーション、他のウィンドウなどです。コードで書かれたテストには、さらに独自の原因が加わります。
| 原因 | 何が起きるか |
|---|---|
| タイミングと待機 | ボタンの準備ができる前にテストがクリックするか、固定のスリープが忙しい日には短すぎます。 |
| 古くなった要素 | 要素を見つけてからクリックするまでの間にページが描き直され、テストはもう存在しない要素を握っています。 |
| 変更されたセレクター | 開発者がクラス名を変えたか、フレームワークの更新でページの構造が変わり、ロケーターが何も見つけないか、間違った要素を見つけます。 |
| テストデータ | 前のテストがレコードを残したか、2 つのテストが同時に同じアカウントを変更しています。 |
| 環境 | 別の画面サイズ、別のブラウザーバージョン、別の OS、または負荷のかかったマシン。 |
| アニメーション | 要素が、まだスライドやフェードで現れている途中に見つかります。 |
| ネットワーク | 遅いリクエストや失敗したリクエストのせいでページが半分しか読み込まれていないか、サードパーティのスクリプトが遅れて届きます。 |
フレーキーテストの 7 つの原因と、それぞれの対処法
フレーキーテストのほとんどすべては、7 つの原因のどれかに行き着きます。それぞれに、隠すリトライではなく、原因を取り除く修正があります。
| 原因 | 現れ方 | 修正 |
|---|---|---|
| タイミング | アプリケーションの準備ができる前にテストが動くので、遅い日には不合格になり、速い日には合格します。 | 条件を待ちます: 要素、テキスト、スピナーの消失です。固定のスリープは決して使いません。 |
| テストの順序 | テストは単独では合格し、別のテストの後では不合格になります: 前のテストがアプリケーションを別の画面に残したからです。 | すべてのテストが同じ既知の状態から始まり、スイートの順序は何も変えません。 |
| 共有状態 | 2 つのテストが同じアカウント、レコード、ファイルを使い、一方が他方の期待するものを変えてしまいます。 | 各テストが自分のデータを持ちます: 自分のユーザー、自分のレコードを、最初に作成して最後に片付けます。 |
| 環境 | 別の画面サイズ、ブラウザーのバージョン、OS、または負荷のかかったマシンが、テストに見えるものを変えます。 | テストを固定した環境で実行し、サポートする環境ごとに 1 つの期待結果を持ちます。 |
| 外部サービス | 決済プロバイダー、メールサービス、遅い API が、遅れて答えるか、間違って答えるか、まったく答えません。 | 自分で管理できないものは安定したテストダブルに置き換え、本物のサービスは別にテストします。 |
| 視覚的なノイズ | アンチエイリアス、フォントのスムージング、カーソル、ホバー状態のせいで、同じ画面が数ピクセル異なります。 | 散らばったノイズは無視しつつ、1 か所に集中した変化では不合格になる方法で比較します。 |
| 本物の断続的なバグ | アプリケーション自体がときどき失敗します: 自身のコードの競合、失われたリクエスト、キャッシュなどです。 | テストを修正しないでください。失敗を再現し、バグを報告して、アプリケーションを修正してください。 |
ビジュアルリグレッションテストが偽陽性を出す理由
ビジュアルリグレッションテストは、アプリケーションの画像を承認済みのベースライン画像と比較します。コードのアサーションが見逃すものを捕まえます: 間違った色、重なったラベル、欠けたアイコンなどです。同時に、誰も変化とは呼ばないような差異も見てしまいます。
| ノイズの発生源 | ピクセルが異なる理由 |
|---|---|
| アンチエイリアス | テキストや図形の縁は中間色でスムージングされ、そのスムージングはマシンごとに異なります。 |
| サブピクセルのフォント描画 | Windows では、テキストは画面とその設定に依存するかすかな色の縁取りとともに描かれます。 |
| 動画と圧縮のノイズ | 記録から取り出した画像や圧縮された画像は、実際の画面が保っている細かな色の情報を失います。 |
| グラフィックスカードとドライバー | 2 台のマシンが同じページを少しだけ違うように合成し、拡大縮小することがあります。 |
| 動的なコンテンツ | 日付、カウンター、広告、ライブフィードが実行のたびに変わります。 |
| カーソルとキャレット | マウスポインターや点滅するテキストカーソルが、一方の画像にあって他方にはありません。 |
| ホバー状態 | ある実行でポインターがボタンの上に留まっていたため、一方の画像でだけボタンが強調表示されています。 |
| 読み込み中のページ | 画像、フォント、トランジションが終わる前に画像が撮られました。 |
チームが今日フレーキーテストに対処している方法
コードで書かれたテストでは
Playwright
Playwright は各操作の前に、要素が表示され、安定し、有効で、他の要素に覆われていない状態になるまで待ち、そうならなければタイムアウトで失敗します。
Cypress
Cypress はクエリとアサーションが通るまで、既定で最大 4 秒間リトライします。失敗したテスト全体をリトライすることもできますが、既定ではオフです。
Selenium
Selenium は条件が満たされるまでアプリケーションをポーリングする明示的な待機を提供し、そのドキュメントは暗黙的な待機と混ぜないよう警告しています。
ビジュアルテストでは
Playwright
Playwright の toHaveScreenshot は、ピクセルごとの色のしきい値 (既定で 0.2) と、絶対値の maxDiffPixels または maxDiffPixelRatio のいずれかを取ります。動的な領域をマスクでき、既定でアニメーションを止め、テキストキャレットを隠します。
BackstopJS
BackstopJS は異なるピクセルの割合 (既定で 0.1) を許容し、画像を撮る前に、指定した要素を隠したり取り除いたりできます。
Chromatic
Chromatic は既定でアンチエイリアスされたピクセルを無視し、diffThreshold (既定で 0.063) がどれだけの変化を許容するかを決めます。
Argos
Argos は既定ですべてのスクリーンショットを安定化します: フォントと画像を待ち、テキストカーソルとスクロールバーを隠し、実行ごとに変わるスクリーンショットにフラグを付けます。
Percy
Percy はアニメーションやその他の動的な要素を固定し、変更はビルド単位、グループ単位、またはスナップショット 1 枚ずつ承認されます。その Visual Review Agent は、意味があると判断した変更を強調表示します。
Applitools Eyes
Applitools Eyes は一致レベルで比較します。Strict は人の目に見えないものを無視することを目指し、Layout は配置だけを検証し、Dynamic は有効な日付、メールアドレス、URL であれば何でも受け入れます。
これらはどれも役に立ちます。しかしどれも、テストごとに数値、マスク、レベルを選び、新しい画像を手作業で確認することを求めます。これらのツールを並べて比べるには、比較調査をお読みください。
許容値を緩めるだけでは答えにならない理由
許容値とは約束です: これだけの差異はノイズである、という約束です。問題は、その「これだけ」が何で測られるかです。
割合は画像とともに大きくなります。1920 × 1080 ピクセルの画面全体では、0.1% は約 2,000 ピクセルで、変わった単語 1 つより多い量です。100 × 40 ピクセルのボタンでは 4 ピクセルで、違って描画された縁 1 本分にも足りません。
画面全体、1920 × 1080
0.1% は約 2,000 ピクセル: 変わった単語 1 つより多い量です。
ボタン、100 × 40
0.1% は 4 ピクセル: 違って描画された縁 1 本分にも足りません。
絶対数は画像とともに大きくはなりませんが、画像全体に散らばったノイズを、まるで 1 つの変化であるかのように合計してしまいます。マスクはノイズを隠しますが、マスクの中にあるバグも隠します。
GUI Test Studio がバグを見逃さずに偽陽性を止める方法
GUI Test Studio は、Web アプリケーション、Windows デスクトップアプリケーション、Android、ゲームのためのエンドツーエンドテスト自動化スイートです。テストを 1 回記録するか、プロンプトで説明し、タイムライン上で編集し、ビルドのたびに実行します。そのアサーションは 1 つのルールに従います: 人が問題に気づくであろうときに不合格になり、そのときにだけ不合格になる、というルールです。
見つける
アプリケーションに尋ねるか、要素を目で見つける
待つ
画面を待つ。タイマーは決して待たない
比較する
明確に変化したものと、その場所を数える
判定する
AI スマート分析、オンにした場合
報告する
何が変わったかを、わかりやすい言葉で
要素は 2 つの方法で見つかる。壊れるセレクターはない
GTS Engine + AI はまず、Windows ではアクセシビリティ情報を通じて、ブラウザーではページ自身の要素を通じて、要素がどこにあるかをアプリケーションに尋ねます。アプリケーションが答えないときは、画面上で要素を目で見つけます。書くべきロケーターがないので、クラス名の変更や新しいフレームワークでテストが壊れることはありません。GUI Test Studio がすべての要素を見つける方法をご覧ください。
アサーションは画面を待つ。タイマーは決して待たない
すべてのアサーションは、期待するものが画面に現れるまで、既定で 5 秒のタイムアウトまで探し続け、現れた瞬間にテストは先へ進みます。ビジュアル不在アサーションはスピナーが消えるのを待つので、遅いページは推測されるのではなく、待たれます。
ビジュアルアサーションまたはテキストアサーションが 1 秒経っても検索範囲内で要素を見つけられないときは、画面全体も探すので、移動したウィンドウのせいでテストが不合格になることはありません。実行の開始前に、GUI Test Runner-Recorder は画面を記録の最初の瞬間と比較し、アプリケーションが別のページにあるときは実行を保留します。アサーションの設定をご覧ください。
検証フェーズは、何が、どこで変わったかを数える
要素が見つかると、検証フェーズがそれを期待する内容と比較します。要素の最も変化の多い小さな領域で、明確に変化したピクセルを数えます: 絶対数であり、画像に対する割合では決してありません。
ノイズは散らばっています: ここは縁が少し柔らかく、あそこは色合いが少し明るい。本物の変化は 1 か所に集中しています: 文字、数字、アイコン。だからこそ、同じルールが小さなアイコンにもダイアログ全体にも通用します。
描画のノイズ
合格かすかで散らばっている: ここは縁が少し柔らかく、あそこは色合いが少し明るい。
本物の変化
不合格1 か所に集中している: 文字、数字、アイコン。
| 画面上では | 検証フェーズが行うこと |
|---|---|
| わずかに異なるだけのピクセル | それ単独では決して数えられません。一方、大文字と小文字が変わった文字は依然としてアサーションを不合格にします |
| スムージングされた縁 | 既定でオンの「軽微な描画アーティファクトを無視」によって許容されます。一方、欠けたアイコンは依然としてアサーションを不合格にします |
| 実際の画面だけが保てる色の細部 | 数えられません。一方、色が変わったボタンやバッジは依然としてアサーションを不合格にします |
| 単独で点滅しているテキストカーソル | 数えられません。一方、その隣で変わった文字は依然としてアサーションを不合格にします |
| 数字 1 桁または単語 1 つの変化 | それが起きた場所で、アサーションを不合格にします |
各アサーションには検証の厳密さがあります: 完全、厳密、標準、緩和です。標準は日常的なボタン、ラベル、アイコンに向き、緩和は広い領域や込み入った画面に向きます。ビジュアルアサーションをご覧ください。
正しい瞬間を、ポインターが元の場所にある状態で
要素は、画面がまだ落ち着いていないうちに見つかることがよくあります: フェードインするメニュー、読み込み中のページなどです。精度向上パスは一致の後に続くフレームを見て、要素が最もよく見えるフレームを採用し、テストの次のステップが始まるところで止まります。精度向上パスをご覧ください。
記録されたテストでは、実行時に、画像が撮られたときにマウスポインターがあった場所へポインターを戻します。記録時にボタンが強調表示されていたなら、実行時もまさにそのときに強調表示されます。
記録したばかりでまだ編集していないテストには、追加の助けがあります。要素が記録されたとおりに現れないとき、実行はテストを賢く調整して要素を見つけますが、本物の差異を隠すためにそうすることは決してありません。
意図的に異なる: ベースラインプロファイル
本物で、しかも望ましい差異もあります: ダークモード、4K モニターではなくノート PC の画面、別のバージョンの Windows、フランス語のアプリケーションなどです。ベースラインプロファイルは、アサーションの期待バージョンを環境ごとに 1 つ保持するので、1 件のテストですべての環境に対応できます。どこを探すか、どれだけ待つか、どれだけ厳密に判定するかは、すべてのバージョンで共有されたままです。ベースラインプロファイルをご覧ください。
AI スマート分析が最終判定を下す
アサーションが変化ピクセルを見つけたとき、AI スマート分析がもう一度確かめて判定を下せます: クラウドのモデルと自分のキーで、または自分のコンピューター上のローカル AI モデル (当社提供のものか持ち込みのもの) で行います。オンにするまではオフのままです。
マウスポインターと点滅するテキストカーソルは決して差異として数えられませんが、変わった文字やアイコンは依然として数えられます。アサーションに自分の言葉で AI 指示を与えることもできます: たとえば、隅の日付は毎日変わる、といった指示です。AI スマート分析をご覧ください。
何が変わったかを伝えるレポート
信頼度レポートは、すべてのビジュアルアサーションを 2 つのフェーズで示します。検索フェーズは要素が見つかったかどうかに答え、検証フェーズは期待どおりの見た目かどうかに答えます。パルスは画面上で変わった箇所を光らせ、判定がそれをわかりやすい言葉で伝えます。
その「弱点」は、最も小さな余裕で合格したアサーション、つまり次に不合格になる可能性が最も高いものを指し示します。履歴は、アサーションがいつから不合格になり始めたかを示します。変更が望ましいものなら、レポートで新しい見た目を採用します: 保存するまで何も書き込まれません。信頼度レポートをご覧ください。
停止か続行か: 失敗の意味は自分で決める
- 各アサーションは、失敗したときにどうするかを示します: テストを停止するか、続行するかです。後に続くクリックが依存するアサーションは既定で停止します: これなしでクリックすると、間違った場所を押してしまうからです。画面の内容を確かめるだけのアサーションは続行するので、1 回の実行で遭遇したすべての問題が報告されます。
パイプラインでは、gtr-cli が retries オプションで失敗したテストをもう一度実行できます。これは最後の手段と考えてください: 修正すべきは上に挙げた原因です。
偽陽性に対するチェックリスト
Do
- 条件を待つ: 要素、テキスト、スピナーの消失。
- 各ビジュアルアサーションは小さく、特徴的なものにする。
- 正当な環境それぞれに独自のベースラインを与える。
- 再実行する前に、アサーションがなぜ失敗したかを読む。
- わずかな余裕で合格しているアサーションに目を配る。
Avoid
- 固定のスリープ。
- ビルドが緑になるまで許容値を上げること。
- 新しいベースラインを見もせずに採用すること。
- 合格するまで失敗をリトライすること。
- 画面の広い領域をマスクすること。
自分のアプリケーションでこれを見てみたいですか?GUI Test Studio によるビジュアルテストが、考え方の全体を 1 ページで示します。
要点
- 1フレーキーテストは、同じコードで合格したり不合格になったりします。フレーキーな失敗はすべて偽陽性であり、偽陽性の 1 つ 1 つがスイートへの信頼を損ないます。
- 2フレーキーさはスイートとともに掛け算で増えます: それぞれ 1% の確率でフレークするテストが 200 件あると、動いているアプリケーションでも緑になる実行は 7 回に 1 回もありません。
- 37 つの原因がほとんどすべてのケースをカバーします: タイミング、テストの順序、共有状態、環境、外部サービス、視覚的なノイズ、本物の断続的なバグです。症状ではなく、原因を修正してください。
- 4フレーキーテストは担当者と期限を付けて隔離します。リトライはビルドを緑にしますが、原因を隠します。
- 5ユーザーに見えるものを、ノイズを無視しつつリグレッションを捉える方法で比較します: GUI Test Studio は 1 か所で明確に変化したものを数え、AI が最終判定を下します。
よくある質問
ソフトウェアテストにおける偽陽性とは何ですか?
偽陽性とは、アプリケーションが正しく動いているのに不合格になるテストのことです。テスターはこれを偽の失敗や誤報とも呼びます。その逆、つまりバグが画面に出ているのに合格するテストは、偽陰性です。
フレーキーテストと偽陽性の違いは何ですか?
フレーキーテストは、実行の間に何も変わっていないのに、同じコードで合格したり不合格になったりします。フレーキーな失敗はすべて偽陽性ですが、テストは古い期待画像などの間違った理由で毎回不合格になることもあります。
フレーキーなエンドツーエンドテストの原因は何か?
最も多いのはタイミングです: アプリケーションの準備ができる前にテストが動いてしまうことです。変更されたセレクター、古くなった要素、共有されたテストデータ、アニメーション、遅いネットワーク、マシン間の違いが、他のよくある原因です。
ビジュアルリグレッションテストで偽陽性を減らすにはどうすればよいですか?
画面が落ち着くのを待ち、比較する領域をそれぞれ小さく保ち、アンチエイリアスなどの描画ノイズを無視し、環境ごとに 1 つのベースラインを保持してください。GUI Test Studio は 1 か所で明確に変化したピクセルだけを数えるので、描画ノイズは合格し、変わった文字、数字、色は依然として不合格になります。
フレーキーテストはリトライすべきですか?
リトライはビルドを緑にしますが、原因を取り除きはせず、時々しか起きない本物のバグを隠すことがあります。リトライはフレーキーテストを見つけるために使い、その背後にあるタイミング、データ、比較を修正してください。
AI は本物のビジュアルバグとノイズを見分けられますか?
はい、ピクセル比較の後のもう一度の確認として可能です。GUI Test Studio では、AI スマート分析が不合格のアサーションの最終判定を下します: 軽微な差異は合格し、変わった単語、数字、値や、欠けたアイコンは依然として不合格になります。
フレーキーテストはどう修正しますか?
まず原因を見つけ、症状ではなくその原因を修正してください。固定の時間ではなく条件を待ち、各テストに独自のデータを与え、環境を固定し、外部サービスを安定したテストダブルに置き換え、描画のノイズを無視する方法で画像を比較してください。それでもフレークするテストは、修正されるか削除されるまで、担当者と期限を付けて隔離します。
フレーキーなテストの割合はどのくらいですか?
スイートによって異なり、小さな割合でも積み重なります。Google は 2016 年に、テスト実行の約 1.5% がフレーキーな結果を出し、テストの 16% 近くに何らかのフレーキーさが見られたと報告しました。それぞれ 0.5% の確率でフレークするテストが 1,000 件あると、本物のバグがまったくなくても、緑になる実行は 100 回に 1 回もありません。
Selenium、Playwright、Cypress、BackstopJS、Chromatic、Argos、Percy、Applitools Eyes は、それぞれの所有者の商標です。
テスト対象のアプリでご覧になりますか? チームとの 30 分の無料相談を予約してください。