クロスブラウザーテスト: すべてのブラウザーとデバイスに 1 つのテスト

各ブラウザーは同じページを独自のエンジンで描き、各デバイスはページに異なる画面を与えるため、クロスブラウザーテストでは、ユーザーが使うあらゆるブラウザーとデバイスで Web サイトが正しく動き、正しく見えることを確かめます。

クロスブラウザーテストとは?

この問いが重要なのは、Web ページが固定された絵ではないからです。どのブラウザーも、同じ HTML、CSS、JavaScript をそれぞれのエンジンで描きます。どのデバイスも、ページに合わせるべき異なる画面を与えます。幅の広いモニターの Chrome で動くチェックアウトが、小さなスマートフォンでは「支払い」ボタンをスクロールしないと見えない位置へ押し出すことがあります。

ブラウザーとデバイスの間で何が変わるか

特定のブラウザーの特定の画面で合格したテストは、ほかについてはほとんど何も証明しません。ページを最もよく壊すのは、次の違いです。

2026 年にテストすべきブラウザー

まず答えになるのは自分たちのアクセス解析です: ユーザーが実際に開いているブラウザーです。それ以外については、市場シェアが訪問の出どころを教えてくれます。

2026 年 10 月のStatCounter による世界のブラウザー市場シェアは、全デバイス合計で次のとおりです。

シェアは毎月少しずつ動くので、年に 1 回ではなく、リリースの前にこのページを確認してください。また、3% 未満のシェアでも、アクセスの多いサイトでは数千人に上ります。

チームはふつう、クロスブラウザーテストをどう行っているか

まずは手動アサーションです。テスターが各ブラウザーでページを開き、ウィンドウのサイズを変えます。1 回のリリースには通用しますが、すべてのビルドには広がりません。

次に来るのが自動化スイートです。その形はどのフレームワークでも似ています: コードで書いたテストと、それをブラウザーやデバイスごとに実行し直す構成です。

Playwright のプロジェクトとデバイス

Playwright はテストをプロジェクトにまとめます。プロジェクトとは、ブラウザーやエミュレートされたデバイスなど、同じ構成で実行されるテストのグループです。Playwright は既定ですべてのプロジェクトを実行します。そのデバイスレジストリには、スマートフォン、タブレット、デスクトップが、画面サイズ、ユーザーエージェント、タッチ対応とともに記述されています。

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 12'] } },
  ],
});

Cypress のブラウザーとビューポート

Cypress は、--browser フラグで選ぶ Chrome 系ブラウザー、Firefox、WebKit に対応しています。cy.viewport コマンドは画面のサイズと向きを設定し、iphone-6 や ipad-2 などのプリセットがあります。ドキュメントには、デバイスピクセル比はシミュレートされないと記されています。また、時間と CI のコストを節約するため、Firefox はコミットごとではなく毎晩実行するなど、一部のブラウザーの実行頻度を下げることも提案しています。

Selenium Grid

Selenium Grid は、リモートのマシン上で、ブラウザーのバージョンとプラットフォームをまたいで、WebDriver スクリプトを並列に実行します。Selenium でクロスプラットフォームテストを行う古典的な方法です。それらのマシンの用意と、ブラウザーの更新はチームが行います。

デバイスクラウド

BrowserStack、TestMu AI (旧 LambdaTest)、Sauce Labs などのデバイスクラウドは、ブラウザーとデバイスをホストしてくれます。BrowserStack と TestMu AI はそれぞれ数千のブラウザーと OS の組み合わせを掲げています。Sauce Labs はエミュレーター、シミュレーター、実機を提供します。コードで書いたテストはそれらのマシン上で実行され、BrowserStack Automate のプランは並列テスト数で数えられます。

これらのツールをより広く見るには、比較調査をご覧ください。

コードで書いたクロスデバイススイートのコスト

test('open the checkout', async ({ page, isMobile }) => {
  if (isMobile)
    await page.getByRole('button', { name: 'Menu' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
});

1 回の記録からのクロスブラウザーテスト

Windows でエンドツーエンドテストを自動化する GUI Test Studio は、別の道を取ります。毎日使っているブラウザーで自分でワークフローを行い、Web テストを一度だけ記録します。カバーすべきブラウザー、デバイス、条件にチェックを入れます。すると GUI Test Runner-Recorder が、それぞれに対応するテストのバージョン、つまりブランチを生成します。

Web アプリを記録するとき、アドレスの下にあるこのテストを他のブラウザーとデバイス向けにも生成するにチェックを入れてください。ブラウザーは、コンピューターにインストールされているものです: Chrome、Edge、Firefox です。デバイスは、メーカーごとにまとめられた 80 以上のスマートフォン、タブレット、デスクトップの画面サイズです。スマートフォンとタブレットはそれぞれ、縦向き、横向き、またはその両方で持てます。

拡大

ウィンドウには、選択によっていくつのテストができるか、生成にどれだけかかるか、ディスクをどれだけ使うかが表示されます。テストが保存されると、ブランチはバックグラウンドで生成されます。記録時に固定されるものはありません: ブラウザーとデバイスは後から追加できます。

記録は初めてですか?テストを記録するが道のり全体を示します。テストをプロンプトで説明し、同じ文でブラウザーとデバイスを名指しすることもできます: プロンプトからテストを作成するをご覧ください。

ブラウザーとデバイスごとのバージョンが行うこと

ブランチは、記録を同じ座標で再生したものではありません。そのブラウザーとデバイス上で、ページ自身の要素を通じて、テストをステップごとに再生して作られます。

ブランチの各アサーションはそのデバイスが実際に表示するものから切り出されるので、スマートフォン固有のレイアウトが不合格と読まれることはなく、そのスマートフォンでの本当のリグレッションは今までどおり捉えられます。

あるデバイスでステップを実行できないときは、ブランチがそう伝えます。注意が必要な状態になり、GUI Test Studio がそのステップに印を付けて理由を示します。

レスポンシブ、ローカライズ、低速ネットワークのテスト

ブラウザーと画面は、ユーザーが持ち込むものの半分にすぎません。残りの半分は、ブラウザーの設定です。ブランチは条件のもとで実行でき、チェックを入れた各条件は、選んだブラウザーとデバイスと組み合わされます。

拡大

ヘッドレスで、同時に

そのようなテストでテストを実行をクリックすると、GUI Test Runner-Recorder は今回の実行でどのバージョンをカバーするか尋ねます。生成されたすべてのブランチにチェックが入っていて、予想時間がリストの下に表示されます。これは前回それぞれにかかった時間から求めたものです: 典型的な数字であり、上限ではありません。

拡大

最後に、ウィンドウが 1 個開き、すべての実行の判定がそれぞれのレポートとともに並びます。実行そのものについてはテストを実行するをご覧ください。

CI/CD でのクロスブラウザーテスト

GUI Test Studio のコマンドラインである gtr-cli は、どのパイプラインでも同じブランチを実行します。--branch all は記録したテストとすべてのブランチを実行し、それぞれが JUnit ファイルに独自のエントリと独自の履歴を持ちます。gtr-cli generate は、欠けているか古くなったブランチを作ります。

gtr-cli generate Checkout.GTS --branch missing
gtr-cli run Checkout.GTS --branch all --junit results\junit.xml

パイプラインでテストを実行するにすべてのオプションがあります。TeamCity の例は本物のパイプラインを順を追って説明し、どの CI/CD ツールでも同じように動きます。

ブラウザーとデバイスごとに 1 件のレポート

信頼度レポートでは、ブラウザーとデバイスボタンが記録とすべてのブランチを前回の判定とともに並べます。選んだもののレポートを開きます。

編集も同じ考え方です。ステップの動作を変えてブランチを保存すると、GUI Test Studio は、その変更がすべてのブラウザーとデバイス向けか、これだけか尋ねます。記録したテストを変更すると、そこからすべてのブラウザーとデバイスを更新することを提案します。

クロスブラウザーテストのチェックリスト

どのツールでテストを実行するにせよ、リリース前に確認すべき 10 項目です。

始める前に知っておくこと

納得して選べるように、いくつかの制限を挙げます。

ブラウザーの外で GUI Test Studio がカバーするもの全体を知りたいですか?エンドツーエンドテストをご覧ください。

「ブラウザーとデバイス」は Web ページ向けです: Electron アプリは独自の Chromium を同梱しているため、Electron アプリのエンドツーエンドテストで説明しているように、デスクトップアプリとしてビルドごとにテストします。

要点

• 1クロスブラウザーテストは、ユーザーが使うあらゆるブラウザーとデバイスで同じページを確かめます: エンジンごとに描き方が異なり、画面ごとにページの収まり方が異なるからです。
• 23 種類のブラウザーで 3 種類のエンジンをカバーできます: Blink には Chrome、WebKit には Safari、Gecko には Firefox、そして訪問の多くを占める画面にはスマートフォンです。
• 3コードで書いたクロスデバイススイートは、第 2 のスイートです: セレクター、デバイスのリスト、スマートフォンで異なる部分のコードは、すべて自分で保守することになります。
• 4GUI Test Studio は Web テストを一度だけ記録し、チェックを入れたブラウザー、デバイス、条件ごとに、ウィンドウなしで実行されて個別にレポートされるバージョンを生成します。
• 5制限を知っておいてください: Safari のエンジンはなく、スマートフォンは実機ではなくエミュレーションで、Firefox では低速ネットワークを使えません。

よくある質問

Selenium、Playwright、Cypress、BrowserStack、TestMu AI、LambdaTest、Sauce Labs、Chrome、Edge、Firefox、Safari、iPhone は、それぞれの所有者の商標です。

Opera、Samsung Internet、StatCounter は、それぞれの所有者の商標です。