Playwright Workspacesでマルチプラットフォーム・マルチブラウザの並列テストを実行する

クラウドE2Eテストを実現するMicrosoft Playwright Workspaces入門 第3回

--workersで実行時間を縮める

　テストが安定して通るようになったところで、本題の並列実行に進みます。

計測の前提を揃える

　今回のサンプルは、5つのプロジェクトに対してデスクトップ向け8本とモバイル向け2本のテストを組み合わせ、合計44件になりました。この44件を、ローカルとクラウドそれぞれでワーカー数を変えながら計測します。ワーカー数はコマンドラインの--workersで指定します。

　筆者の環境（12コアのMac、クラウド側はEast Asiaリージョン）で計測した結果は次の通りです。

44件のテストにおけるワーカー数と所要時間

実行環境	ワーカー数	所要時間
ローカル	1	14.8秒
ローカル	4	8.6秒
ローカル	8	10.5秒
クラウド（Linux）	4	約72秒
クラウド（Linux）	10	約60秒
クラウド（Linux）	20	27.4秒

　クラウド実行はワーカー数を20まで増やしても27.4秒で、ローカルの8.6秒に届いていません。

　理由は、テスト1本あたりの実行時間が0.2〜0.5秒と非常に短いことにあります。この規模では、リモートのブラウザへ接続する往復のオーバーヘッドが処理時間を上回り、クラウドの並列性が活きません。逆に言えば、クラウド実行が効いてくるのは、テスト1本が数秒以上かかる、あるいは件数が数百規模になり、ローカルのCPUでは並列度を稼げなくなってからです。前回述べた「テスト件数が多いほど恩恵が大きい」という性質が、数字として表れた形です。

　ただし、クラウド側はワーカー数を4から20へ増やすと明確に短縮しており、並列度を上げる余地が十分残っていることは読み取れます。

増やしても速くならない点がある

　一方でローカル実行の結果に注目すると、ワーカー数を4から8へ増やすことでかえって遅くなっています。

　ポイントは、前回説明した本サービスの構造です。クラウドへオフロードされるのはブラウザの起動と描画であり、テストを制御するワーカープロセス自体は手元のマシンで動き続けます。ワーカーを増やせばクライアント側のCPUとメモリを消費するため、ある点を超えると別プロセスとリソースの奪い合いが起きてしまい、結果的に実行時間が遅くなる可能性が生じます。

　他にもテスト全体の完了時間には、次の要因が影響します。

• クライアントマシンのCPU・メモリ（ワーカーを増やすほど消費する）
• テストコードの複雑さ（1本が重いほど並列化の効果は大きくなる）
• リモートブラウザまでのレイテンシ（リージョンが遠いほど不利）
• 対象アプリの負荷耐性（並列度に応じてアプリにも負荷がかかる）

　ワーカー数の上限はワークスペースあたり100ですが、上限まで上げることが最適とは限らないのは表が示す通りです。まずローカルで2ワーカー以上を指定して正しく通ることを確認し、クラウドへ移してからワーカー数を振って計測する、という順序で最適値を探していくべきです。

リージョンアフィニティを確認する

　実行時間に影響する要因のうち、レイテンシに直接効くのがブラウザのホスト先リージョンです。

　Playwright Workspacesには「リージョンアフィニティ」という仕組みがあり、既定では、クライアントマシンにもっとも近いAzureリージョンのブラウザが使われます。テスト結果はいったんそのリージョンで収集され、ワークスペースのリージョンへ転送されます。開発者が国内から実行しても、CIエージェントが海外にあっても、それぞれに近いブラウザが割り当てられるわけです。

　この設定は、Azureポータルの「設定」セクションにある「リージョン管理」から確認・変更できます。

図3：リージョン管理の設定画面

　既定の設定を無効にすると、クライアントの位置にかかわらず、ワークスペースを作成したリージョンのブラウザが常に使われます。テスト結果の保存先を特定のリージョンに固定したい場合はこちらを選びます。ただし特別な事情がなければ、既定のまま利用するのが無難です。

まとめ

　今回は、projectsによるブラウザマトリクスの設計から、モバイルエミュレーションの追加、並列化で顕在化したテストの脆さの修正、--workersによる並列実行の実測までを行いました。

　次回は最終回として、テスト結果ダッシュボードとTrace Viewerによる失敗分析、そしてGitHub ActionsへのE2Eテストの組み込みを取り上げ、継続的にテストを回す運用基盤の作り方を紹介する予定です。