mablトレーナーやローカル実行で成功するテストでも、自分のマシンには存在するもののmablのインフラストラクチャには存在しない設定に依存している場合は、クラウドで失敗することがあります。クラウド実行は、ローカルで使用していたログイン、ネットワークアクセス、設定がいずれもない、まっさらな状態から開始されます。この記事では、クラウドでのみ発生する失敗の大半の原因となる5つの違いについて、それぞれがどのように現れるか、どこで修正するかを説明します。
| クラウド実行で見られる症状 | 最も可能性の高い違い |
|---|---|
| 401でログインに失敗する、またはサインインページに戻される | サインイン済みのセッションがない |
| 最初のページの読み込みがタイムアウトする、または拒否される。ホスト名が解決されない | トラフィックの送信元が異なる |
| ステップがタイムアウトし、スクリーンショットに確認ページが表示されている | 何かが実行をボットとして扱っている |
| 内部URLがクラウドでは失敗するが、トレーナーでは動作する | トレーナーとクラウド実行の経路が異なる |
| 見た目が異なるページで検索ステップまたはアサーションが失敗する | クラウドには異なるバージョンのアプリケーションが表示されている |
クラウドのブラウザにはサインイン済みのセッションがない
クラウド実行は毎回新しいブラウザで開始され、トレーナーも同様です。違いは、その下にあるマシンです。自分のマシンでは、ブラウザがオペレーティングシステムのログイン、デバイス証明書、またはIDプロバイダーが信頼する管理対象ブラウザのポリシーを引き継ぐことができるため、シングルサインオンが何も尋ねることなく完了します。クラウドにはそのようなマシンがないため、アプリケーションからは見知らぬユーザーとして扱われます。
Windows統合認証(NTLMまたはNegotiate)は最も厳しいケースです。クラウドのブラウザが持つことのないドメインセッションに依存するため、クラウド実行からはまったく機能しません。
どのように現れるか: テストがログイン時またはログイン直後に失敗し、多くの場合、401が返されるか、サインインページにリダイレクトされます。
どこで修正するか: テストに専用のログインを用意します。デスクトップアプリで、ブラウザオーバーライドのシングルサインオンをブロックをオンにすると、トレーナーにもクラウドと同じログインページが表示されます。次に、ユーザー名とパスワードを持つ専用のテストアカウントを作成し、ログインをフローとして記録します。アカウントで必要な場合は、MFA認証システムのステップを追加します。詳細とNTLMを含む制限事項については、アプリケーションへのログインを参照してください。
トラフィックの送信元が異なる
自分のマシンからは、リクエストはネットワークの内部からアプリケーションに届きます。クラウドからは、リクエストはmablの静的IPアドレスから届きます。環境でmabl Linkを使用している場合は、Link Agentのホストから届きます。ファイアウォール、IP制限のあるアカウント、地域に基づくルールはいずれも、異なる送信元からのリクエストとして認識します。
どのように現れるか: テストが何かを行う前に、最初のページの読み込みがタイムアウトするか、拒否されます。内部ホスト名が解決されません。
どこで修正するか: アプリケーションにパブリックインターネットからアクセスできない場合は、ファイアウォールでmablのIPアドレスを許可リストに追加するか、ネットワーク内でLink Agentを実行するかの、いずれかの方法が必要です。どちらを選ぶかはmabl Linkと静的IPアドレスの許可リストの選択を、ネットワークで許可する必要があるものについてはmablのためのネットワークの設定を参照してください。
mablとアプリケーションの間にある何かが実行をボットとして扱っている
自社のファイアウォールがクラウド実行を許可していても、コンテンツデリバリーネットワークやIDプロバイダーなど、アプリケーションの前段にあるサービスが実行をボットとして扱うことがあります。
どのように現れるか: ステップが要素を待機している間にタイムアウトし、スクリーンショットまたはDOMスナップショットに、アプリケーションではなく確認ページやCAPTCHAが表示されます。
どこで修正するか: エッジが原因であることを確認する方法と対処方法については、接続の問題のトラブルシューティングを参照してください。
トレーナーとクラウド実行の経路が異なる
デフォルトでは、トレーナーは自分のマシン上でブラウザを実行するため、そのトラフィックは自分のマシンからアプリケーションに直接送信されます。内部URLに対してトレーナーでテストが動作しても、それは自分のワークステーションがアプリケーションに到達できることを示すだけで、mablのクラウドが到達できることを示すものではありません。
クラウド実行がブラウザのトラフィックをLink Agent経由で送信するのは、テストの環境がLinkトンネルを使用するように設定されている場合のみです。次の2つのオプションでは、スケジュールされたクラウド実行が使用しない経路でテストが成功することがあります。
- Linkトンネル経由でのトレーニング。 トンネルはトレーナーを起動するたびに選択し、mablはそれをテストやその環境に保存しません。トンネル経由でトレーニングしたテストでも、クラウド実行がトンネルを経由するには、環境をmabl Linkを使用するように設定する必要があります。
- 自分のコンピューター経由での実行のルーティング。 個人Linkトンネルを使用するクラウド実行は、自分のコンピューターが到達できるものすべてに到達できます。同じテストでも、プランやデプロイイベントなど、個人トンネルを使用しない場合は、環境のトンネルのみを使用します。
Link 3.0以降が必要
トンネル経由でのトレーニングと個人Linkトンネルには、Link 3.0以降が必要です。Link 3.0はアカウントごとに有効化されます。アカウントでまだレガシーLinkを使用している場合は、レガシーLinkからLink 3.0への移行を参照してください。
どのように現れるか: 内部URLに対するクラウド実行が最初のページで失敗する一方で、トレーナー、ローカル実行、または自分のコンピューター経由でルーティングした実行は成功します。
どこで修正するか: 環境が、接続済みのエージェントを持つLinkトンネルを使用していることを確認してから、クラウドでテストを実行します。mabl Link経由でのテストの作成と実行とmabl Linkの問題のトラブルシューティングを参照してください。
クラウドには異なるバージョンのアプリケーションが表示されている
セッション、Cookie、またはIPアドレスによって表示内容を変えるアプリケーションでは、クラウド実行に自分のマシンでは見たことのないものが表示されることがあります。たとえば、異なるA/Bバリアント、異なる状態の機能フラグ、ロードバランサーによる別のバックエンドへのルーティングなどです。
どのように現れるか: ページのレイアウトが異なるために検索ステップでテストが失敗する、またはバリアント間で異なる値に対してアサーションが失敗します。
どこで修正するか: Cookieを設定するステップ、開始URL、または機能フラグプロバイダーへのAPI呼び出しを使用して、テストでバリアントを明示的に指定します。チームがバリアントを実装する方法ごとの選択肢については、A/Bバリアントをまたいだテストの自動化を参照してください。