ThousandEyesは、アプリケーション監視向けの新しいシンセティック（合成）トランザクション機能をリリースしました。新しいSelenium WebDriverベースのトランザクションテストは100％ネイティブのJavascript対応で、記録と実行にChromiumブラウザーを使用するため、より正確で柔軟かつ一貫性のあるアプリケーションテストを作成できます。Javascript IDEを備えた使いやすいレコーダーが利用可能で、容易に詳細なユーザーワークフローを構築できます。また、完全なAPIサポートにより、トランザクションテストをより自動化し、CI / CDプロセスに統合できます。
新しいトランザクションテストを最大限に活用する方法
このブログでは、Office 365 Sharepoint監視を例として、新しい機能を詳しく見ていきます。現在ご利用のクラウドおよびSaaSアプリケーションの可視性を高めるための強力なマルチレイヤ統合監視テストを作成するベストプラクティスをご紹介します。
＃1：クリックではなくワークフローを考える
まず、トランザクションテストを作成する際には、ユーザーがアプリ上で操作するワークフローに焦点を合わせます。これは「クリック確認」によるテスト手法とは対照的です。このシンセティック（合成）アプリケーション監視の目的は、すべてのリンクやボタンをクリックして、これらが機能していることを確認することではありません。 （これは通常QAチームの仕事となります。）ただし、ThousandEyesをCI / CDプロセスで使用できないと言っているわけではなく、ここでの目標は、一般的な一連のユーザーワークフローを複製して、ユーザーのアプリケーションレベルの体感品質が低下している可能性があるタイミングを特定できるようにすることです。
それを念頭に置いて、ターゲットとする主なユーザーワークフローを特定することから始めましょう。この例では、一般的なユーザーフロー、つまりSharepointにログインして、ファイルをダウンロードすることをターゲットにします。ユーザーフローは次のようになります。
Sharepoint Onlineにアクセス–>ログイン–>ドキュメントページを参照–>ドキュメントを選択–>ダウンロード
このような一般的なユーザーフローの作成により、ユーザーのデジタル体感品質に影響を与える可能性のあるすべてのインフラや相互接続されたサービスを通じて確実にテストを実行できます。
＃2：Javascriptを恐れない-まずはレコーダーからスタート！
確実で信頼性の高いトランザクションスクリプトを作成するには、ネイティブのJavaScriptベースのトランザクションエンジンの利用が最良の方法です。 UIベースのソリューションの方が簡単に思えるかもしれませんが、途中の処理で何かが機能しない場合、そこで行き詰まってしまうことが多くあります。一方、ネイティブJavascriptは、必要に応じて調整が行える柔軟性とパワーを持ち備えています。
ただし、一部の人にとってJavascriptは馴染みのないものかもしれません。でもご安心ください。ThousandEyes レコーダーを使ってまずは始めてみましょう。 ThousandEyes レコーダーは、Web上の操作に基づいて、必要なJavascriptコードを生成するスタンドアロンのトランザクション・スクリプトレコーダーおよびIDEです。例として冒頭で決めたOffice 365 Sharepoint上でのワークフローに沿って、ターゲットURL（「https：//…」）を組み込みのChromiumブラウザーに貼り付け、「記録」をクリックし、Webサイトを操作することから始めます。完了したら「停止」をクリックします。 レコーダーは、記録されたユーザーアクションに基づいて、Javascriptトランザクションを作成します（図1）。
レコーダーは、人間が読めるテキストコメントを作成し、Javascriptの初心者でもコードの各行が実際に何をしているかを簡単に理解できるようにします。 たとえば、ログイン情報を入力するSharepointトランザクションスクリプトの抜粋の1つが下記になります。
// Click on 'Enter your email, phone, or Skype.'
await click(By.id('i0116')); // Clicking the text field
await typeText('marketing@ThousandEyesO365.onmicrosoft.com', By.id('i0116'));
また、credentials.getの利用により、パスワードを自動的にキャプチャし、組み込みの資格情報ストアに保存します。 この資格情報ストア（図2）は、トランザクションのスクリプト内でパスワードの入力が必要な場合に、プレーンテキストとして使用せずに安全な秘密のリポジトリとして利用が可能です。これは、セキュリティ上とても重要なポイントとなります。
最後に、ThousandEyes レコーダーは、必要なスキャフォールディングコード（「インポート」など）と、「click」、「typeText」、「isElementClickable」、「simulateHumanDelay」などの便利な機能を生成し、信頼性の高いトランザクションスクリプトが簡単に作成されます。
＃3：Javascriptを採用（レコーダーを継続利用）
初めての方には、レコーダーはとにかく使い易い最適なツールですが、出来れば早い段階で実際に手を動かしてJavascriptによるコーディングもお試しください。これをサポートするため、ThousandEyes レコーダーはIDE（統合開発環境）としても機能し、構文エラーの強調表示、インテリセンスのようなヒントや入力候補を示すコード補完機能、オートコンプリート、デバッグ用のコンソール出力などの便利なツールを備えています。
トランザクションコードの信頼性を高める最も効果的な方法の1つは、トランザクションスクリプトがWebページ上の要素を見つける最適な方法を選択することです。デフォルトでは、レコーダーはエレメントのIDを使用します（IDがある場合）。たとえば、生成されたOffice 365用のトランザクションスクリプトからの次のコードは、idSIDButton9というIDを持つページ上の要素を識別します（図3）。
通常、IDは一意であるため、このアプローチはベストプラクティスといえます。しかし、今日の動的なWebページでは、ページの読み込みごとにIDが変わる場合があり、その場合には一意のCSS選択文字列、要素名、要素クラス、要素リンクテキスト(linkText)などの構築が含まれます。
Office 365 Sharepointの例では、記録されたトランザクションを定期的に実行すると、「id_354」要素（[ダウンロード]ボタン）が見つからないというエラーが定期的に発生しています（図4）。これは、ページの読み込みごとに要素IDが動的に生成されるためです。
組み込みのChromiumブラウザーでChrome開発ツール（「インスペクト」を右クリック）を使用して、「ダウンロード」ボタンのセレクターを探すことができます（図5）。 Sharepointの例では、[ダウンロード]ボタンの属性がdata-icon-name = "download"である画像が表示されています。これは、「ダウンロード」という名前が一意であり、動的に変更される可能性が低いため、信頼できる識別子の良い例です。
await click（By.id（ 'id__354'））; をawait click（By.css（ '[data-icon-name = "download"]'））; に置き換え、ThousandEyes レコーダー内で変更されたトランザクションスクリプトを再実行すると、問題は解決し、スクリプトを問題なく繰り返し実行できます。
適切なCSSおよびその他のセレクターを識別することは、確実なトランザクションスクリプトを作成する最も強力な方法の1つです。また、Red Gateのシートは、一般的なセレクタレシピを覚えておくのにとても便利です。
しかし、選択スクリプトを変更は、Javascriptによるコーディングの活用法の1つにすぎません。
JavaScriptネイティブエンジンのパワーを活用するもう1つの例は、ThousandEyesが提供する組み込みヘルパー関数の一部を使用することです。たとえば、Sharepointの例でdownloads.waitForDownload（...）関数を使用して、選択したファイルのダウンロードが実際に完了するまで待ちます。これを行うには、downloadモジュールをインポートし、スクリプトの最後に呼び出しを追加するだけです。コードスニペットは次のとおりです。
import { downloads } from 'thousandeyes';…
// Click on 'Download'
await click(By.css([data-icon-name="download"]));
// Wait for download to complete
await downloads.waitForDownload('Public Cloud Report.pdf', 60 * 1000);
コードを微調整しながら改良する作業には、レコーダーからトランザクションスクリプトを直接実行できるため、すべてが期待どおりに機能するまで何度も繰り返し確認できます。他のツールとは異なり、ThousandEyesはクラウドエージェントやエンタープライズエージェントからトランザクションスクリプトをそのまま実行できるため、あらゆる監視ポイントからネイティブなJavascriptアプローチが可能です。そのため、振る舞いに一貫性があり、期待どおりの結果を得ることができるのです。
＃4：アプリケーションレベルの体感品質の可視性を高めるためにマーカーを活用
エンドユーザーのアプリ体感品質を測定する際の課題の1つは、ユーザーが操作する一般的なワークフロー内のさまざまな場所で問題が発生する可能性があることです。マーカーは、ワークフロー内の主要なタスクを識別しその処理時間の測定が可能なため、ある特定のタスクに時間がかかりすぎる場合などの調査に有効です。これは、マーカーアイコンまたはdriver.start / driver.stopを使用して追加できます。
適切なマーカーの設定は、有用なトランザクションスクリプトを作成する上で最も重要な手順の1つです。マーカーを追加しすぎると、意味のあるパフォーマンストリガーを作成できなくなり（ノイズが多すぎる）、一方少なすぎると、ユーザーワークフロー内の重要なステップを識別・測定できなくなります。
作成を検討すべき基本的なマーカーは次のとおりです。
- 「ページ読み込み」―最初のawait driver.get呼び出しの前後にマーカーを作成して、サイトの初期ページ読み込み時間を測定できるようにします。
- 「ログイン」-最初のページの読み込み後にマーカーを開始し、最後のログイン（パスワード）ボタンがクリックされた後にマーカーを停止します。
- 「バックエンド」-ログインが発生した後に開始し、ページが読み込まれたとき/最終的なユーザーアクションが完了したときに終了するマーカーを作成します。
- アプリケーション個別の使用方法に関連するユーザーアクションのマーカーを作成します。たとえば、Sharepointのダウンロード例では、Sharepointの一般的な使用方法である、ファイルを検索してダウンロードするユーザーアクションの前後にマーカーを作成します。
マーカーに関する役立つヒントの一つは、デフォルトのスクリプトでは、ユーザーの「クリック」などのイベントがページの読み込みにつながると、ページが読み込まれるまでイベントが返されないため、マーカーのタイミングが予期せぬものとなる可能性があることです。 Sharepointログインはそのような例の1つです。幸い、Javascriptを使用しているため、isElementClickable（）まで待機して「Login」マーカーを停止し、「Backend Load」マーカーを開始してからclick（）の呼び出しに進むようにコードを簡単に調整できます。
マーカーの配置後は、特定のマーカーにアラートを作成できます。たとえば、「バックエンドページの読み込み」に時間がかかりすぎた場合のアラートを作成できます。
＃5：トラブルシューティングを高速化するためのスクリーンショットの利用
もう1つのベストプラクティスは、スクリーンショットを活用して、エンドユーザーの目に実際に見えているものを定期的にキャプチャすることです。そうすることで、問題をより迅速に特定し、Webの動作をよりよく理解できます。 ThousandEyes のシンセティック（合成）テストでは、await driver.takeScreenshot（）を呼び出すことにより（またはスクリーンショットアイコンをクリック）、トランザクションスクリプトの任意の場所でエンドユーザーに表示されるものと同じスクリーンショットを生成・取得できます。
まずは、最初にページを読み込んだ直後にスクリーンショットを撮ることを強くお勧めします。これにより、エンドユーザーがログインした直後に見ているもの（つまり、サービスの最初の状態）を常に視覚的に記録できます。これは、問題を迅速に修正するのに非常に役立ちます。
たとえば、2019年10月のPG＆E社の Webサイトの停止では、スクリーンショットを使用した簡単なトランザクションテストから、SSL設定の問題が原因でユーザーがサイトとのHTTPS接続を確立できないことがすぐにわかりました。
さらに、ThousandEyes Syntheticsエンジンは、トランザクションエラーまたはタイムアウトが発生するたびにスクリーンショットを自動的に生成します。これは、問題を迅速に解決し、トランザクションスクリプトの動作を最適化するためにとても役立ちます。
「Sharepoint」向けのトランザクションスクリプトで定期的にタイムアウトが発生していた例では、自動キャプチャのスクリーンショットを見ると、既存スクリプトでは処理できなかった想定外のポップアップが表示されていることがわかりました（図7）。
これは、ウォーターフォール情報から見つけ出すことは事実上不可能な事象でした。このスクリーンショットにより、ポップアップを確認しながらトランザクションコードを更新し状況に応じて修正が可能です。
スクリーンショットが単なる美しい写真ではなく、デジタルエクスペリエンス監視ツールキットの貴重なツールである理由のほんの一例です。
＃6：レコーダーを超えて：コードライブラリの構築
ThousandEyes レコーダーは、トランザクションスクリプトの作成を簡単に開始できる素晴らしいツールです。ただし、常にスクラッチからスクリプトを作成する必要はありません。トランザクションテストの構築開始後は、チーム全体で共通コードの再利用を開始することができます。チーム全体で利用可能な共通機能のライブラリを作成すると、信頼性の高い強力なトランザクションテストをより迅速に構築できます。
たとえば、ログイン、ホームページからサイト上のエンドユーザーポータルへのブラウジングなど、Webサイトの一般的なユーザーフロー用の関数や、クリックの再試行、ランダムなポップアップのクローズなどの基本レベルのヘルパー関数などです。
提供を開始した GitHubのトランザクションサンプルをご参照ください。こちらでは、資格情報の利用、ファイルのダウンロードの待機、タブの切り替え、ポップアップのクローズなどの例が含まれています（図8）。
この種のモジュール方式を採用することにより、開発者指向のチームメンバーは再利用可能なコードの構築、テスト、最適化に専念でき、その他のメンバーは個別のアプリケーションに特化したトランザクションスクリプトの構築に専念できます。
また、他のすべてのアプリケーションコードと同様に、GitHubなどのリポジトリでトランザクションスクリプトのバージョン管理を行うベストプラクティスの提供も可能になります。さらに、ThousandEyes APIを使用すると、トランザクションテストスクリプトを動的に更新できるため、既存のCI / CDプロセスとすべてを統合できます。
満足のゆくトランザクションスクリプトの完成後は、レコーダーからThousandEyesに直接簡単にエクスポートできます。
＃7：SSOへの対応
この時点で、SharePointの読み込み、ログイン、共有ドキュメントフォルダーの参照、およびファイルのダウンロードという一般的なユーザーフローに従う、Office 365 Sharepoint向けのトランザクションテストが出来上がりました。ただし、多くの大企業の場合、何らかの形のシングルサインオン（SSO）を使用していることが多く、このSSOがトランザクションテストを実行する上で障害になる可能性があります。場合によっては、SSOプロバイダーが対話型ログインにリダイレクトし、他のログインと同様にトランザクションテストで簡単に処理することができる一方、プロバイダーがKerberosまたはNTLMを必要とする場合があります。幸いなことに、トランザクションテストのセットアップの[認証設定]セクションに資格情報を追加するだけでThousandEyesはこれらを自動的に処理できます。
資格情報が追加されると、ThousandEyes合成エンジンがSSO認証を自動的に処理します。これにより、特別なSSO関連のコードを追加する必要がなくなるだけでなく、トランザクションスクリプトがエンドユーザーの実際のトランザクションステップをより適切に表すようになります。
＃8：ネットワークとアプリケーション合成を組み合わせてより良い洞察を得る
ThousandEyesで新しいOffice 365トランザクションテストを実行すると、シンセティック（合成）テストとエンドツーエンドのネットワークおよびインターネットの可視性と関連付けることの利点がすぐにわかります。
実際の例として、北米にある複数の監視ポイントからSharepointトランザクションテストを実行し、エンドユーザーアプリケーションのパフォーマンスに影響を与えた比較的切り分けが困難なネットワークの問題を迅速に特定することができました。 ご覧の通り最初のページの読み込み時間には問題はありませんでしたが、Sharepointの「共有ドキュメント」ページを読み込むためのマーカー時間は、ボストンからは他の場所の2倍の長さでした（図9）。トランザクションベース以外のテストまたはウォーターフォール分析では、この問題は特定されませんでした。 これは、主要なアプリケーションに対してトランザクションテストを実行することを強くお勧めする理由の良い例です。
従来のシンセティック（合成）ツールでは、この時点で立ち往生し、アプリ・サーバー・ネットワークチームなどの複数部署の担当者を集めた会議を開催するしかありませんでした。 ただし、ネットワーク情報とエンドツーエンドのパスの可視化と完全に相関したThousandEyesでは、ボストン地域のMicrosoftエッジネットワークのルーティングに関連するネットワーク遅延がファイルダウンロード遅延の主な原因であることがすぐにわかりました（図10）。
重要なポイントとしては、ここで検出されたネットワーク遅延は、通常のネットワークテストでアラート通知されるほど大きなものではなかったという事実です。これは、今日のクラウドおよびSaaSベースのアプリケーションで最適なデジタルエクスペリエンスを確保するためには、アプリケーションとネットワークの可視性の連携が非常に重要である理由の良い例です。
まとめ
このブログでは、ThousandEyesレコーダーを使用してJavaScriptネイティブトランザクションテストの作成をすぐに開始できることを学びました。ベストプラクティスとしてご紹介した最適化の例でコードを調整し、組み込みライブラリの活用によりファイルのダウンロード、マーカーやスクリーンショット機能を追加、最終的に1つのテストでアプリケーションとネットワークの可視性を統合する利点を確認しました。
既にThousandEyesをご利用のお客様は、新しいトランザクションテストタイプがテスト設定画面に表示されますので、今すぐお試しください。 ThousandEyesをまだご利用でないお客様は、是非無料トライアルにてお試しください。
