WebDriver とは何ですか？

Scrapeless Agent Browser は、サポートされている自動化クライアント向けに、文書化されたインターフェースを通じて管理されたブラウザー実行機能を提供します。

WebDriver は、ウェブブラウザ用の標準化されたリモート制御インターフェイスです。ブラウザ外部のプログラムは WebDriver を使用して、ナビゲーションの要求、要素の検索、操作の実行、ブラウザの状態の検査を行います。プロトコルは言語に依存しません。さまざまなクライアントライブラリが、アクションの伝達および実行方法に関する共通のモデルに依拠しながら、ブラウザ操作を表現できます。

WebDriver はしばしば Selenium を通じて触れられますが、これらの用語は異なるレイヤーを指します。Selenium はブラウザー自動化用のライブラリと関連インフラストラクチャを提供します。WebDriver はブラウザー制御のための契約（コントラクト）を定義します。ブラウザーごとの実装が、そのコントラクトのリモート側を、制御対象のブラウザー環境向けに処理します。これらのレイヤーを区別することで、セットアップと診断をより正確に行えるようになります。

WebDriver コマンドがブラウザに届くまで

WebDriver クライアントは、ブラウザを制御するリモートエンドにコマンドを送信します。 WebDriver リモートコントロール仕様 コマンドモデル、機能、セッション、およびブラウザー操作を定義します。

クライアントはブラウザの横で動作する場合もあれば、リモートインフラストラクチャを介して接続する場合もあります。そのデプロイメントの選択によってブラウザがどこで動作するかは変わりますが、互換性のあるコマンド契約という基本的な要件は変わりません。到達可能なサーバーであっても、必ずしも WebDriver サーバーであるとは限らず、ブラウザ制御用の URL は他のあらゆる自動化エンドポイントと互換的に扱えるわけではありません。

コマンドの成功したレスポンスは、そのコマンドで定義された結果を確立します。ナビゲーション操作は、クライアントレンダリングされたチャートが完了したことを必ずしも確立するわけではありません。要素を見つけても、ロケーターが複数の類似したコントロールにマッチする場合、それが意図したインスタンスであることを確立するものではありません。

アプリケーションアサーションは、欠けている意味を補います。どのページ、レコード、またはユーザーに表示される状態が、ある操作の後に続かなければならないかを定義します。プロトコルはブラウザを移動させ、テストまたはワークフローは、その移動によってタスクが達成されたかどうかを判断します。

WebDriver セッションは制御関係である

WebDriver セッションは、クライアントとブラウザー環境との間の制御関係を識別します。セッションの作成ではケイパビリティがネゴシエートされ、その後のコマンドは生成されたセッション内で実行されます。

機能は要件を表現し、選択された実行環境を説明します。これらは、ブラウザーおよびサポートされている動作を特定するのに役立ちますが、ウェブサイトが期待どおりのコンテンツを返すことを保証するものではありません。同じブラウザーセッションでも、ログインページ、空の結果ビュー、または完全にデータが入力されたアプリケーションに到達する可能性があります。

WebDriver セッションをウェブサイトの認証とは分離して保持してください。ウェブサイトはブラウザの状態を通じてサーバー側のログインを維持できます。自動化セッションを終了しても、そのログインが必ずしも失効するわけではなく、またアクティブな自動化セッションがあるからといって、ウェブサイトのログインが有効なままであることも保証されません。

セッションの所有権は明示的であるべきです。セッションが必要な作業を開始するときにセッションを作成し、意図されたワークフロー全体を通してその制御を引き渡し、その所有者が処理を完了したときに終了させてください。アプリケーションコード内で参照を失うことと、リモートブラウザリソースが解放されたことを確認することは別物です。

ロケーターと要素参照では有効期間が異なる

ロケーターは要素の見つけ方を記述し、要素参照は特定のドキュメント状態で見つかった特定の要素を識別します。この区別によって、参照が古くなる場合がある理由が説明できます。

動的なアプリケーションでは、データが読み込まれた後にコントロールが置き換えられる場合があります。新しいコントロールは、外見やセレクターが同じであっても、別のノードである可能性があります。以前に返された参照が、その置き換えられたコントロールへの参照になるわけではありません。

ページが変更されたら、現在のドキュメントを再評価し、対象となる要素をもう一度特定してください。重要な問いは、これから実行しようとしている操作に対して、アプリケーションの状態がまだ一致しているかどうかです。ナビゲーション前に機能していたロケーターが、今では別のものにマッチしたり、誤ったページに属している可能性があります。

タスクの意味に結びついたセレクターを優先して使用してください。安定した識別子、アクセシブルな名前、明確に定義されたアプリケーション属性は、レイアウトコンテナを延々とたどる長いパスよりも、通常はレビューが容易です。どのロケーターを選ぶ場合でも、そのワークフローが実際にサポートしているページバリアントにおいて、正しいコントロールを選択できているかを必ず確認してください。

待機とは関連する条件を確認することを意味する

WebDriver における「待機」とは、関連するアプリケーションの条件が、制限された時間内に真になるのを許可することを意味します。 Selenium の待機戦略 暗黙的ウェイトと明示的ウェイトの違いを説明し、そのタイミングへの影響を理解せずに両者を併用することへの注意喚起を行ってください。

完了したナビゲーションは、その後のスクリプトの動作に先行して行われる場合があります。ボタンは、実際に使用可能になる前から存在していることがあります。テーブルは、まだプレースホルダー行を表示している状態でも表示されている場合があります。次に安全に行える操作、または最終的な有用な結果を表す条件を選択してください。

レポートのワークフローでは、条件は想定されたレポート見出しと完了した結果領域が存在していることかもしれません。フォームの場合は、正しいコントロールが有効になっていて、かつオーバーレイによってブロックされていないことかもしれません。固定遅延は経過時間を表すものであり、アプリケーションの準備完了を示すものではありません。

失敗した待機は、不足していたものを説明できるだけの十分なコンテキストを保持すべきです。期待していた条件、現在のページの識別情報、そして範囲を限定した診断用の観察情報を取得してください。これにより、変更されたロケーターと、別のページまたは未完了のアプリケーション状態とを区別できます。

コマンドの適用先を定義するフレームとウィンドウ

WebDriver のコマンドは選択されたブラウザーコンテキスト内で動作するため、正しいウィンドウやフレームを特定することが正しさの一部となる。埋め込みドキュメント内の要素は、親ドキュメントの DOM の通常の子孫ではない。

この HTML 閲覧コンテキストモデル は、ドキュメント、ウィンドウ、およびネストされたコンテンツの関係を説明している。ワークフローは、操作が属するドキュメントを選択する際に、その関係に従わなければならない。

アプリケーションが送料見積もりツールを埋め込んでいるとする。親ドキュメント内のロケーターは iframe 要素を見つけることはできても、見積もりツール内部のフォームコントロールは見つけられないかもしれない。目的のフレームを選択し、そのドキュメントの準備完了を確認してから、そのドキュメント内でコントロールを検索する。

ポップアップも関連する問題を提示する。元のウィンドウは開いたままでも、必要な出力は別の場所に表示される可能性がある。API が最後に返したハンドルが常に正しいと仮定するのではなく、タスクに関連する証拠によって新しいウィンドウを識別する。元のコンテキストで作業を続ける前に、意図した親コンテキストに戻る。

Cookie とアプリケーションセッションは Web サイトの状態を維持する

Cookie はブラウザーのリクエストを Web サイトの状態と結び付けることができるが、それは WebDriver セッションと同じものではない。 HTTP state management mechanism は、Cookie がそのスコープ内でどのように保存・送信されるかを定義している。

認証が必要なテストでは、承認されたアカウントと意図的な開始状態を用いるべきである。ブラウザーデータの再利用は継続性の要件には役立つが、依存関係を見えにくくすることもある。テストが合格するのは、以前のタスクが同意の選択を受け入れていたり、位置情報を選択していたりするためだけかもしれない。

クリーンな状態を必要とするテストと、意図的に状態を保持するタスクを分ける。Cookie や認証情報を記録することなく、状態の出所を記録する。ワークフローの途中でログインが期限切れになった場合、アプリケーションデータが存在しないことを成功した空の結果として扱うのではなく、その結果として報告する。

他のブラウザーインターフェースと比較した WebDriver

WebDriver は複数あるブラウザー制御インターフェースの 1 つであり、適切なインターフェースは必要なブラウザーのカバレッジと操作内容に依存する。クラシック WebDriver、WebDriver BiDi、CDP は、それぞれ異なるコマンドおよび観測モデルを持つ。

ライブラリー名だけに基づいて選択してはならない。ライブラリーは複数の基盤プロトコルを公開している場合や、環境固有の制限を持つ場合がある。プロトコル間で接続例を類推して翻訳するのではなく、正確な接続方法と動作を確認する。

WebDriver ワークフローの計画

有用な WebDriver ワークフローは、開始状態、コンテキストの変更、準備完了の確認、結果、およびクリーンアップを明示する。それらの詳細によって、開発者マシン上でもリモートインフラストラクチャ上でも、保守しやすくなる。

まず代表的なアプリケーションパスを 1 つ選ぶ。初期 URL、アカウント状態、ビューポート、および期待されるドキュメントを特定する。各インタラクションについて、それを許可するページ条件と、その後に続くべき状態を定義する。これにより、一連のクリックが明示的な振る舞いの契約に変わる。

セッションを終了する前に、得られたデータまたは可視状態を検証する。最終 URL に到達したテストであっても、アプリケーションがエラーを表示していれば不完全であり得る。プロトコルエラー、利用できないリソース、ビジネスアサーションの失敗を、ジョブ結果の中で区別しておく。

意思決定における Scrapeless の位置付け

Scrapeless Agent Browser はブラウザー実行レイヤーに属する。その マネージドブラウザー環境 および Agent Browser 機能 は、任意の WebDriver エンドポイントが存在すると仮定するのではなく、文書化されたクライアントインターフェースを通じて評価すべきである。

「 ブラウザーコンソールとリプレイ診断 」の議論は、リモートページの挙動を観察するための関連コンテキストを与える。マネージド実行を検討する際には Scrapeless pricing を確認すること。ここでの定義では、WebDriver と Scrapeless の統合やベンチマークは一切主張していない。

結論

WebDriver はブラウザー自動化に標準化された制御モデルを提供する。それでも信頼できるワークフローは、アプリケーション固有のロケーター、コンテキスト選択、待機、およびアサーションに依存している。これらの条件をセッションライフサイクルと並行して定義し、単一のコマンドの成功とタスク全体の成功を区別できるようにする。