最適なテスト スイート構成を決定する
Microsoft Playwright Testing Preview を使用すると、クラウド規模で並列処理を増やすことで、Playwright テストの実行を高速化できます。 テスト スイートの完了時間には、いくつかの要因が影響します。 テスト スイートの完了時間を短縮するための最適な構成の決定は、アプリケーション固有であり、実験が必要です。 この記事では、テストの並列処理を構成するためのさまざまなレベル、テスト継続時間に影響する要因、および、テスト完了時間を最短にする最適な構成の決定方法について説明します。
Playwright では、ワーカー プロセスを使用してテストを並列実行できます。 Microsoft Playwright Testing を使用すると、クラウドでホストされるブラウザーを使用して並列処理をさらに増やすことができます。 一般に、並列処理を強化すると、テスト スイートの完了時間は短縮されます。 ただし、ワーカー プロセスを追加しても、テスト スイートの完了時間は必ずしも短縮されるとは限りません。 たとえば、クライアント マシンのコンピューティング コンピューティング リソース、ネットワーク待機時間、またはテストの複雑さもテスト継続時間に影響する可能性があります。
次のグラフは、テスト スイートの実行例を示しています。 ローカルではなく Microsoft Playwright Testing でテスト スイートを実行することで、並列処理を大幅に増やし、テスト完了時間を短縮することができます。 サービスを使用して実行すると完了時間が下限に達し、それ以降はワーカーを追加しても最小限の効果しかないことがわかります。 このグラフは、クライアント マシンのコンピューティング リソースを増強すると、サービスで実行されるテストの完了時間に好影響があることも示しています。
ワーカー プロセス
Playwright では、すべてのテストはワーカー プロセスで実行されます。 これらのプロセスは OS プロセスであり、個別に並列実行され、Playwright Test ランナーによって調整されます。 すべてのワーカーが同じ環境を持ち、各プロセスが独自のブラウザーを起動します。
一般に、並列ワーカーの数を増やすと、テスト スイート全体の完了にかかる時間を短縮できます。 Playwright Test の並列処理の詳細については、Playwright のドキュメントを参照してください。
既にグラフで示したように、ワーカー プロセスを追加すればするほど、テスト スイートの完了時間も短縮されるわけではありません。 テスト スイートの継続時間に影響を与えるその他の要因があります。
ローカルでテストを実行する
@playwright/test では既定で、ワーカーの数はマシンの CPU コア数の半分に制限されています。 テストを実行するためのワーカーの数はオーバーライドできます。
ローカルでテストを実行する場合、ワーカー プロセスの数はマシンの CPU コア数に制限されます。 一定の水準を超えてワーカーを追加すると、リソースの競合が発生し、各ワーカーの速度が低下し、テストは不安定になります。
ワーカーの数をオーバーライドするには、--workers コマンド ライン フラグを使用します。
npx playwright test --workers=10
ワーカーの数を指定するには、playwright.config.ts で workers 設定を使用します。
export default defineConfig({
...
workers: 10,
...
});
サービスを使用してテストを実行する
Microsoft Playwright Testing を使用する場合、クラウド規模でワーカーの数を増やすことができます。 サービスを使用すると、ワーカー プロセスは引き続きローカルで実行されますが、リソースを多く消費するブラウザー インスタンスはクラウドでリモート実行されるようになります。
ワーカー プロセスは引き続きクライアント マシン (開発者のワークステーションまたは CI エージェント マシン) で実行されるため、ワーカーを追加していくと、やはりクライアント マシンがスケーラブルな実行のボトルネックになる可能性があります。 最適な構成を決定する方法を確認してください。
コマンド ラインで --workers フラグを使用してワーカーの数を指定できます。
npx playwright test --config=playwright.service.config.ts --workers=30
ワーカーの数は playwright.service.config.ts で workers 設定を使用して指定することもできます。
export default defineConfig({
...
workers: 30,
...
});
完了時間に影響する要因
並列ワーカー プロセスの数に加えて、テスト スイートの完了時間に影響する要因がいくつかあります。
| 要素 | テスト継続時間への影響 |
|---|---|
| クライアント マシンのコンピューティング リソース | ワーカー プロセスは引き続きクライアント マシン (開発者のワークステーションまたは CI エージェント マシン) で実行され、リモート ブラウザーと通信する必要があります。 並列ワーカーの数を増やすと、クライアント マシンでリソースの競合が発生し、テストの速度が低下する可能性があります。 |
| テスト コードの複雑性 | テスト コードの複雑さが増すにつれて、テストの完了時間が長くなる可能性もあります。 |
| クライアント マシンとリモート ブラウザーの間の待機時間 | ワーカーはクライアント マシンで実行され、リモート ブラウザーと通信します。 ブラウザーがホストされている Azure リージョンによっては、ネットワーク待機時間が長くなる可能性があります。 Microsoft Playwright Testing でリージョンの待機時間を最適化する方法を確認してください。 |
| Playwright 構成設定 | サービスのタイムアウト、再試行、トレースなどの Playwright 設定がテストの完了時間に悪影響を及ぼす可能性があります。 クラウドでテストを実行するときに、これらの設定の最適な構成を実験してください。 |
| ターゲット アプリケーションの負荷処理容量 | Microsoft Playwright Testing でテストを実行すると、実行の並列処理を向上できますが、ターゲット アプリケーションの負荷も高くなります。 Playwright テストの実行によって生成される負荷をアプリケーションが処理できることを確認してください。 |
テスト スイートの継続時間を最短にする最適な構成を決定するワークフローの詳細を確認してください。
最適な構成を決定するワークフロー
テスト スイートの完了時間を最短にする最適な構成は、アプリケーションと環境に固有です。 最適な構成を決定するには、さまざまなレベルの並列化、クライアント マシンのハードウェア構成、またはテスト スイートの設定を実験します。
次のアプローチは、Microsoft Playwright Testing を使用してテストを実行するための最適な構成を見つけるのに役立ちます。
1.テスト完了時間の目標の決定
テスト スイートの完了時間と、テスト実行あたりの付随コストの許容水準を決定します。
シナリオによっては、テストの完了の要件が異なる場合があります。 継続的インテグレーション (CI) ワークフローの一部として、コード変更のたびにエンドツーエンドのテストを実行する場合、テスト完了時間をできるだけ短縮することは不可欠です。 エンドツーエンドのテストを (夜間の) バッチ実行にスケジュールする場合は、要件を緩和してもよいかもしれません。
2.クライアント マシンでテストが正しく実行されることの確認
Microsoft Playwright Testing で Playwright テスト スイートを実行する前に、クライアント マシンでテストが正しく実行されることを確認してください。 CI ワークフローの一部としてテストを実行する場合は、CI エージェント マシンでテストが正しく実行されることを確認します。 テストが並列実行用に正しく構成されていることを確認するために、少なくとも 2 つの並列ワーカーを使用してテストを実行してください。 Playwright での並列処理の詳細を確認してください。
3.クラウドでホストされるブラウザーを使用して Microsoft Playwright Testing でテストを実行する
テストが正しく実行されたら、クラウドでホストされるブラウザーでサービスを使用してテストを実行するためのサービス構成を追加します。 クライアント マシン (開発者のワークステーションまたは CI エージェント マシン) からテストが引き続き正しく実行されることを確認します。
「クイック スタート: Microsoft Playwright Testing で Playwright テストを大規模に実行する」を開始します。
4.Azure リージョンのリモート ブラウザーの確認
Microsoft Playwright Testing では、クライアント マシンに最も近い Azure リージョンのリモート ブラウザーを使用することも、ワークスペースが作成された固定のリージョンを使用することもできます。
ワークスペースのリージョン待機時間を最適化する方法を確認してください。
5.並列ワーカー数の実験
テストを実行する並列ワーカーの数を実験します。 テスト完了時間を測定し、設定済みの目標と比較します。
それ以上ワーカーを追加してもテスト完了時間が縮まらないポイントを確認します。 次の手順に進み、設定をさらに最適化します。
Note
サービスのプレビュー期間中、ワークスペースあたりの並列ワーカー数は 50 に制限されます。 ワークスペースでこの制限の引き上げをリクエストすることができます。
6.クライアントのスケーリング
並列処理を増やすと、クライアント マシンでコンピューティング リソースの競合が発生する可能性があります。 GitHub でホストされる大規模ランナーを選択するなどして、クライアント マシンのコンピューティング リソースを増強します。
ハードウェアの制限がある場合は、クライアント テストをシャード化することもできます。
テストを再実行し、並列ワーカーの数を実験します。
7.Playwright テスト構成設定を更新する
タイムアウト、トレース設定、再試行などの Playwright 構成設定を調整します。