ピクセルパーフェクトなスクリーンショットテスト: 失敗する理由と、本物のビジュアルバグを捕まえる方法

ピクセルパーフェクトなスクリーンショットテストは、スクリーンショットのすべてのピクセルを参照画像と比較します。これは 2 つの点で失敗します: 無害な描画ノイズが誤報を生み、それを黙らせるほど緩いパーセントのしきい値は、間違った数字や欠けたアイコンを通してしまいます。

ピクセルパーフェクトなスクリーンショットテストとは

考え方自体は正しいものです: 人は画面を見て判断するので、テストも画面を見るべきです。問題は尺度にあります。画面はどのマシンでも同じピクセルで描かれるわけではなく、重要なバグはわずか数ピクセルの大きさしかないことがよくあります。

ピクセル単位の比較が誤検知を生む理由

誤検知とは、アプリケーションに問題がないのに不合格になるテストのことです。ピクセル単位の比較では、人に見えるものを変えずにピクセルだけを変えるあらゆるものから誤検知が生まれます。

不安定なテストには、待機やタイミングといった別の原因もあります。それらは不安定なテストと誤検知で取り上げています。

ビジュアルリグレッションテストのしきい値が本物のバグを隠す理由

ノイズへのよくある対処はしきい値です: 画像のある割合、たいてい 1 % か 2 % より差異が少なければ比較を合格にします。誤報は止まります。代わりに本物のバグが通り始めます。

画像に占める割合は間違った尺度

画像全体で数えると、ノイズとバグは似て見えます。しかし、人の目には似て見えません。

ですから正しい問いは、画像のどれだけが変わったかではありません。人が抱く問い、つまりこの画面を見た人に違いが見えるかどうかです。その答えは画像の大きさに左右されないので、小さなアイコンにもダイアログ全体にも当てはまります。

不安定なスクリーンショットテストへのよくある対処と、そのコスト

Playwright のようなコードを書くフレームワークでは、toHaveScreenshot がピクセルごとの色のしきい値と、画像全体で許す異なるピクセルの最大数または最大比率を受け取ります。その数値を選び、マスクを書き、ブラウザーとプラットフォームごとに参照画像を持つのはあなたで、それを保守するコードもあなたが書きます。

GUI Test Studio がスクリーンショットを比較する仕組み

GUI Test Studio は、Web アプリ、Windows デスクトップアプリ、Android スマートフォン、ゲームのエンドツーエンドテストを、コードなしで録画から作成します。クリックや入力をした要素にはそれぞれビジュアルアサーションが付き、要素の小さな画像、つまりビジュアルターゲットを保持します。ビジュアルアサーションを参照してください。

まず要素を見つける

検索フェーズは、要素が今どこにあっても実際の画面上で見つけます。GTS Engine + AI はまずアクセシビリティ情報やページ自身の要素を通じてアプリケーションに尋ね、アプリケーションが答えないときは見た目で要素を見つけます。GUI Test Studio がすべての要素を見つける仕組みを参照してください。

比較はその後、要素がある場所で行われます。動いたウィンドウや 1 ピクセルずれたボタンは、まったく差異になりません。

次に、人が見るように比較する

検証フェーズは、要素をビジュアルターゲットと人の目と同じように知覚的に比較します。人が気づくものには気づき、誰にも見えないものは無視します。

マウスオーバーの状態と日付

録画したテストでは、実行時にマウスポインターを画像を撮ったときの位置に戻します。ボタンが強調されるのは、録画で強調されていたときとまったく同じタイミングです。

毎日変わる値は、ビジュアルターゲットに含めるべきではありません。ターゲットは要素そのものにとどめ、日付、合計、カウンターは、値に関係なく形式を確認する動的テキストアサーションで確認します。テキストアサーションを参照してください。

ダークモード、別の言語、別の画面で、画面が正当に違って見えるときは、ベースラインプロファイルで環境ごとに 1 つの期待バージョンを持ってください: ダークモード、別の言語、別の画面のテストを参照してください。

ピクセル比較と GUI Test Studio、ケースごとの比較

画像比較の許容度の選び方

GUI Test Studio では、ビジュアルアサーションの許容度は検証の厳密さで、わかりやすい言葉で選びます: 細かい部分にはより厳しく、情報の多い画面にはより寛容に。推測すべき割合はありません。

1. 1

   ビジュアルアサーションを選ぶ

   GUI Test Studio でテストを開き、タイムライン上のビジュアルアサーションをクリックします。その設定が「プロパティ」パネルに表示されます。

2. 2

   検証の厳密さを選ぶ

   日常的なボタン、ラベル、アイコンには標準のままにします。小さな文字や細かい部分にはより厳しいレベル、広い領域や情報の多い画面にはより寛容なレベルを選び、まったく同じままでなければならない画像にだけ完全を選びます。

3. 3

   「軽微な描画アーティファクトを無視」はオンのままにする

   これは既定でオンなので、マシンごとに異なる滑らかにされた輪郭は無視されます。その輪郭自体をテストするときだけオフにしてください。

4. 4

   テストを実行してレポートを読む

   「テストを実行」をクリックします。信頼度レポートが変化した部分を光らせて示し、アサーションが不合格になった理由を 1 文で伝えます。

5. 5

   差異が想定内なら「AI への指示」を加える

   「詳細設定」で、「フォントサイズは無視する」のような短い言葉を書きます。AI スマート分析は、そのアサーションを判定するときにそれに従います。

ほとんどのテストではこれ以上は必要ありません。各レベルの正確な設定と、まれに必要になる詳細設定は、ビジュアルアサーションとアサーションの設定にあります。

AI によるビジュアルテスト: わかりやすい言葉でのセカンドオピニオン

ビジュアル比較は、何かがどこで変わったかを伝えます。言葉による 2 つ目の意見があれば、どう対処するかを決めやすくなります。それを担うのが AI スマート分析で、オンにするまではオフです。

マウスポインターと点滅するテキストカーソルは、AI にとって決して差異になりません。合格したアサーションが AI に送られることはありません。

クラウドのモデルとご自身のキーで動かすことも、ご自身のコンピューター上のローカル AI モデルで動かすこともできます: 当社が提供するモデルでも、お持ちのモデルでも構いません。想定内の差異もあり、どれがそうかを知っているのはあなただけなので、アサーションに「フォントサイズは無視する」や「アイコンは何色でもよい」のような「AI への指示」を与えてください。AI スマート分析を参照してください。

拡大

ビジュアルの失敗の読み方

実行後、信頼度レポートは不合格の各アサーションを、期待される画像、見つかった画像、そして画面上で光って示される変化とともに表示します。判定は、何がどこで変わったかを 1 文で伝えます。

拡大

変更が意図したものなら、レポートから新しい見た目を受け入れると、テストはそれ以降その見た目を期待します。

コードによるチェックがまったく見逃すビジュアルバグについては、自動テストが見逃すビジュアルバグで取り上げています。

要点

• 1ピクセルパーフェクトなスクリーンショットテストは 2 つの点で失敗します: 描画ノイズが正しい画面を不合格にし、パーセントのしきい値が本物のバグを通してしまいます。
• 2ノイズは誰にも見えないもの、本物の変化は人が気づくものです: 数字、文字、アイコン、色。
• 3画像に占める割合は間違った尺度です。代わりに、画面を見た人に何が見えるかを問いましょう。
• 4GUI Test Studio はまず要素を見つけてから、人の目と同じように比較するので、スムージング、圧縮、点滅するカーソルでテストが不合格になることはありません。
• 5AI スマート分析はわかりやすい言葉で見直しを加え、オンにすればその答えが最終判定になります。

よくある質問

Playwright、ClearType、Windows は Microsoft Corporation の商標です。