Salesforce は CRM (顧客関係管理) プラットフォームで、組織は、マーケティングの自動化、顧客サービス、分析、アプリケーション開発など、あらゆる種類の顧客中心のビジネスを管理する機能を提供します。 シンプルでわかりやすいクラウドベースの CRM ツールとして始まったものは、急速に成長しました。 Salesforce は、クライアントに新しいサービスを進化させ、拡張し、新しいサービスを提供し続けています。 今日、企業は、プラットフォーム、エクスペリエンスクラウド、コマースクラウド、カスタマー360などの Salesforce 製品を使用して、独自のカスタムアプリケーション、サービス、ポータル、ソリューションを構築し、カスタマーエクスペリエンスの自動化とパーソナライズを支援します。 また、他の Web アプリケーションや Web サイトと同様に、組織は Salesforce パフォーマンステストを実施して、適切に機能し、応答性を備え、ユーザーベースの拡大に応じて拡張できることを確認する責任があります。
Salesforce アプリケーション、ウェブページ、またはその他のサービスをロードまたはストレス テストする必要がありますか。 Salesforce 環境のパフォーマンス テストを実行するためのソリューションを探して、世界中のクライアントと協力しています。 私たちのチームに連絡 して、LoadViewがどのように役立つのかをお見せしましょう!
LoadView は、Salesforce アプリケーション、Web ページ、API、またはその他の Web サービスをテストできます。
照明アプリケーションビルダー: 低コードアプリケーションフレームワーク
Salesforce (特に Lightning アプリケーション ビルダープラットフォーム) は、自らをローコードアプリケーションフレームワークと見なしていますが、それはどういう意味ですか? 低コード アプリケーション フレームワークは、アプリケーション開発の完全なエキスパートではない開発者の技術的知識を減らすのに役立ちます。 このように、ほとんどすべての開発者が、知識や経験の面で多くの重い持ち上げに頼ることなく、Salesforce アプリケーションを簡単に作成できます。 アプリケーションの要件に応じて、ローコード フレームワーク は、 アプリケーションを構成するために選択できるさまざまなマイクロサービスを提供します。 また、チームがより重要なタスクに集中し、アプリケーション のバックログのメンテナンスを軽減し、チームの俊敏性を維持する時間を短縮することもできます。
また、コードのないアプリケーション ソリューションがあることにも注意してください。 名前が示すように、ノーコード ソリューションは 、アプリケーションの作成経験がほとんどまたはまったくない個人に対応しています。 これらの例は、ユーザーが事前に構築されたモジュールまたは機能から選択できるWebサイトまたは eコマース デザインのアプリケーションです。 何も根本から構築する必要はありませんが、特に大規模なエンタープライズ セキュリティ、コンプライアンス、およびパフォーマンスについて考えるときは、その欠点もあります。 アプリケーションフレームワークは、Lightning アプリケーションビルダーのような優れたオプションです。 開発者は、低コードとコードなしの両方の世界を提供します。 セキュリティやコンプライアンス機能などのコードのないマイクロサービスを提供しながら、ユーザーフレンドリーなクラウドベースのアプリケーションを構築して展開する機能は、完全な安心感を提供します。 ビジネスだけでなく、ユーザーにも。
Salesforce パフォーマンステスト: 概要
Salesforce がアプリケーションをホストし、バックエンドインフラストラクチャ、セキュリティ、コンプライアンスなどの面倒を見る場合、Salesforce パフォーマンステストを実行する必要があるのはなぜですか? 彼らの環境は私のためにスケールできないはずですか? 他に何をする必要がありますか? 「設定して忘れる」だけでなく、Salesforce インフラストラクチャに対してアプリケーションをテストして、 トラフィック が増加した場合のパフォーマンスを確認する最も重要な理由はたくさんあります。 これが発生した場合、パフォーマンスの低下を防ぎます。 組織は、大きなマーケティングプロモーションを実施する可能性があります。 または、ビデオがあなたのSaaS(サービスとしてのソフトウェア)プラットフォームについてウイルスに感染し、今では誰もがそれについて知りたいと思っています。 おそらく、あなたのアプリケーションは、サイバーマンデーのショッピング休暇を 通じてブラックフライデー に大きく依存して、本質的により季節的です。 だから、それを念頭に置いて、あなたは予期せぬ計画を考え始めなければなりません。 では、どのようなパフォーマンステストを実施する必要がありますか? より良いアイデアを得るために、さまざまな種類のパフォーマンス テスト を見てみましょう。
パフォーマンス テストの種類
パフォーマンス テストは、非機能テストの一種です。 その他の種類の非機能テストには、セキュリティ テスト、信頼性テスト、コンプライアンス テスト、互換性 テストなどがあります。 負荷テストとストレス テストは、最も一般的な種類のパフォーマンス テストですが、両者の間に混乱が生じることがあります。 さまざまな種類の パフォーマンステストと、それらを互いに区別するものを見てみましょう。
ロードテスト
ロード テストは、ユーザーがよく知っている最も一般的な種類のパフォーマンス テストです。 ロード テスト では、パフォーマンスが低下するまでソフトウェアにどの程度の負荷をかけることができるかを把握します。
ストレステスト
負荷テストと同様に、ストレス テストではロード テストが次のレベルに進みます。 ストレステストは、システムやソフトウェアが壊れるまでプッシュするために行われます。 これにより、パフォーマンス エンジニアは、システムの応答と回復方法を理解できます。
ボリュームテスト
ボリューム テストは、フラッド テストとも呼ばれ、アプリケーションに対して大量のデータをテストして、アプリケーションがどのように応答するか、異常な動作があるかどうかを確認するテスト方法の一種です。
スパイクテスト
スパイク テストはストレス テストに似ていますが、ユーザーのゆっくりとした継続的な増加ではなく、アプリケーションがシステムの負荷の急激な増加にどのように対処できるかを測定するために、 同時ユーザーで アプリケーションにすばやく殺到します。
スケーラビリティテスト
容量テストとも呼ばれる スケーラビリティ テストは、ユーザー負荷の増減に応じてアプリケーションがどのように実行されるかを理解することを目的としています。 これは、将来の需要を満たすために追加のインフラストラクチャが必要かどうかを判断するのに役立ちます。 スケーラビリティ テストの目的は、ユーザー負荷の増加をサポートするために、ソフトウェア アプリケーションの “スケール アップ” の有効性を判断することです。
耐久試験
マラソンと同様に、耐久テストでは、アプリケーションが長期間にわたるトラフィックを処理する方法をテストします。 soakテストとも呼ばれ、これらのテストは、アプリケーションの要件に応じて、数時間、数日または数週間にわたって実行することができます。
ご覧のとおり、選択するパフォーマンス テストの種類は、アプリケーションのパフォーマンスの目標または目的によって異なります。 ただし、テストに関係なく、安定性、応答性、負荷の高いスケーラビリティなどのパフォーマンスの問題を明らかにするという目標は同じです。 何百、何千人ものユーザーがアプリケーションを使用していて、突然、彼らが突然停止する状況で自分自身を見つけることを望んでいません。 また、アプリケーションが Salesforce 環境でホストされている場合、そのようなことが起きた場合の対応に関する可視性、制御、および時間が少なくなります。 Salesforce はパフォーマンス要件をサポートするだけでなく、毎日数十億件の取引を行う何千もの企業のすべての要件をサポートする必要があることを覚えておいてください。
ただし、このような要求では、Salesforce のようなマルチテナントプラットフォームがインフラストラクチャを継続的に監視し、常に SLA (サービスレベル契約) のパフォーマンスしきい値 内に収まるようにして、顧客のパフォーマンスとコンプライアンスを維持します。 ただし、Salesforce のパフォーマンス テストを完全に見下ろすことができるというわけではありません。 Salesforce はプラットフォームの拡張が可能であると確信しているかもしれませんが、企業の成長と拡大に伴ってアプリケーションやページが維持されるという確信が必要です。
Salesforce テスト計画: ベストプラクティス
Salesforce では、パフォーマンス テストを真剣に受け止めています。 内部ポリシーと手順に従わないと、調整とブロックが発生する可能性があります。 そして、誰もそれを好きではありません。 そのため、実稼働環境ではパフォーマンス テストを実行できません。
テストは、他の Salesforce ユーザを妨害しないように、サンドボックスまたは隔離された環境で実行する必要があります
。 さらに、パフォーマンス テストは、テストの日付の少なくとも 2 週間前に承認のために提出する必要があります。 2 週間より早く送信された要求は拒否される可能性があります。 Salesforce の観点から見ると、そのサービスで問題が発生しないように、異常な動作のテストを監視する必要があります。 Salesforce パフォーマンステストのプロセスは、一般的に以下の手順に従います。
読む: 負荷テスト準備チェックリスト
テスト要件の収集
この段階で、ロードマップとして使用するテストの基本的な概要を作成します。 ここでは、テスト対象のアプリケーション、特定のユーザーペルソナシナリオ、環境固有の質問、予想される平均応答時間とシステム使用率、 SLAなどの詳細を含める必要があります。
テスト モデルの開発
テスト モデルは、実際のパフォーマンス テスト中に何が起こると思うかを表すものです。 テストの初期要件に基づいて、仮説は何が起こるでしょうか? テスト モデルは、実際のパフォーマンス テスト中に何が起こるかの予測として使用されます。 テストの前に 、ベースライン パフォーマンスメトリック を必ず受け取ってください。 これは、後で、テスト前のプロジェクションが実際のテスト結果とどのように一致するかを比較するために使用できます。 テストが予想と一致しなかった場合は、結果を確認し、仮説の結果に影響を与えた可能性のある内容を確認できます。
適切なパフォーマンス テスト ツールを選択する
ジョブに適したパフォーマンス テスト ツールを選択する場合、選択するツールは、予算、時間、専門知識、テストユース ケースなどの要因に依存します。 従来のロード テスト ツールでは、現在の最新のプラットフォームやアプリケーションでは十分ではありません。 LoadViewの私たち全員が、パフォーマンスエンジニアが Salesforce アプリケーションをテストするために必要なすべてをプラットフォームが提供していると考えています。 たとえば、多くのアプリケーションは、優れたユーザーまたはクライアントエクスペリエンスを提供することに重点を置いています。 ユーザー エクスペリエンスを完全に理解する唯一の真の方法は、 ユーザー ペルソナをスクリプト化し、実際のシナリオに一致するテストを実行できることです。
最高の Salesforce パフォーマンス テスト ツールとは何ですか?
十分な機能と柔軟性を提供しないJMeterやガトリングのようなオープンソースの負荷テストプラットフォームとは異なり、LoadViewは、今日の絶えず変化するアプリケーションの要求を満たすために専用に構築されています。 このソリューションでは、使いやすいスクリプト レコーダー、実際のブラウザーでのテスト、複数のロード テスト カーブ、グローバル テストの場所、その他 のエンタープライズ レベルの機能 など、使用するブラウザーでの実際のユーザーの動作に合わせてテストを簡単にセットアップできます。 ただし、Web サービスおよび REST API または SOAP API のプロトコルベースのパフォーマンス テストを構成することもできます。 「 テスト スクリプトの開発 」セクションで、EveryStep Web レコーダーについて詳しく説明しますが、機能と利点の完全な一覧については、 機能 ページをご覧ください。
Salesforce テスト計画の設計
Salesforce テスト計画には、パフォーマンス テスト環境の詳細な説明と、開始時間と終了時刻、トランザクション/秒数 (TP)、 ランプアップ/ランプダウン時間などの特定の測定と指標、その他の特定のテスト情報を含める必要があります。 Salesforce はテスト結果を提供しませんので、LoadView のような包括的なレポートやダッシュボードを提供するソリューションを使用して、必要に応じて詳細に分析し、関係者と共有することが重要です。
テスト スクリプトの開発
テストスクリプトは、Salesforce ロードテストプロセスの重要な部分です。 そのため、スクリプトがバグとエラーがないことを確認するために、細心の注意を払う必要があります。 ただし、Salesforce では、スクリプトが正確であるかどうか、または実際のシナリオが適切に反映されていることを確認するために、スクリプトを確認しないことに注意してください。 先ほど触れたように、LoadView ソリューションは 、EveryStep Web レコーダーと呼ばれるポイントとクリック スクリプト ツールを提供します。 このスクリプト ツールにより、複雑なユーザー シナリオやクライアント側の対話機能を簡単に記録できます。
レコーダーを開いて、キーボード操作、マウスのクリック、ホバー、および動きを記録します。 ユーザーとまったく同じようにアプリケーションをナビゲートします。 レコーダーは各ステップを保存します。 レコーダーの機能には、次のものも含まれます。
- 40以上のデスクトップ/モバイルブラウザとデバイスのサポート。
- Web アプリケーションの言語とフレームワークのサポート – HTML5、Java、ルビー、反応など
- ログイン/パスワードなどの動的変数。
- ユーザーの動作、遅延、および待ち時間をカスタマイズします。
- CAPTCHA および OTP (ワンタイム パスワード) のサポート。
- フォームの送信とメニューの選択。
- 暗号変数。
- コンテンツの検証(画像とテキスト)。
- そして、はるかに。
スクリプトが完了すると、スクリプトが再生され、スクリプトやネットワークエラーが発生しないようにします。 また、必要に応じてスクリプトを手動で編集することもできます。 自分のためにEveryStepのWebレコーダーを試してみてください!
テストの実行
最後に、私たちは楽しい部分に到達します。 上記の手順を完了したら、Salesforce を通じてパフォーマンス テスト要求を正式に送信する必要があります。テストの日付の少なくとも 2 週間前にテストを提出し、スケジュールを設定する必要があります。
パフォーマンス テストをスケジュールするには、次の手順を実行します。
- Salesforce アカウントにログインします。
- ヘルプポータルに移動します。
- [ ネットワーク] を選択し、 > 今後のアクティビティを Salesforce に通知します。
- パフォーマンス テストのスケジュールをクリックします。
さらに、次のような追加の情報を Salesforce チームに提供するために、Salesforce テスト計画を利用できるようにする必要があります。
- テストの時間/日付など、Salesforce パフォーマンス テストの一般的な概要。
- 主要な連絡先と担当者。
- 何がテストされ、その理由に関する正当性と詳細をテストします。
- 1 秒あたりのトランザクション (TPS) やランプアップ計画などの指標。
- テストが行われる Salesforce サンドボックスの ID
- そして、あなたが感じる他のものは、テストについて関連しています。
結果の分析
テストが完了したら、結果をキャプチャして 、内部のチーム メンバーや利害関係者と共有できるようにする必要があります。 さいわい、LoadView ソリューションを使用している場合、レポート と概要 はテスト後に自動的に作成されます。
概要レポート データ、要素レベルのコンポーネント、ウォーターフォール チャート、セッション情報、および実行されたスクリプトの概要を表示して、パフォーマンス テスト結果の包括的な画像を取得します。 さらに、Web アプリケーションおよび Web ページのテストでは、テストの記録をユーザーに表示するように表示できるため、アプリケーションまたはページがロード中にどのように動作するかを確認できます。
結論: Salesforce パフォーマンス テスト
Salesforce アプリケーション、Web ページ、API、またはその他の ウェブ サービスをロードウェブ またはストレステストする必要がありますか? Salesforce のパフォーマンステストが必要な世界中のクライアントと協力しています。 状況や Salesforce 環境に関係なく、それが UAT 環境であれ実稼働前の環境であれ、 ファイアウォールの背後でテストする必要がある場合でも、LoadView プラットフォームは対象とします。 Salesforce ロードテストのセットアップ時に 、BlazeMeter、LoadRunner、JMeter など、試した他の一般的なロード テスト ソリューションよりも LoadView を好むとクライアントからお伝えしています。
パフォーマンスエンジニアとサポートチームは、テストの作成、スクリプト作成、計画に関してお客様と協力して、Salesforce ロードテストを実行する前に必要な情報をすべて用意できます。 Salesforce パフォーマンス テスト プロセスの一部をガイドするチームです。 自分でLoadViewを試すか、LoadView が提供するすべてのものを見るために私たちのパフォーマンスエンジニアの一人とデモをスケジュールしてください。