SalesforceはCRM(顧客関係管理)プラットフォームであり、マーケティング自動化、カスタマーサービス、分析、アプリケーション開発など、企業がビジネスの顧客中心のあらゆる側面を管理する能力を提供します。単純で分かりやすいクラウドベースのCRMツールとして始まったものが急速に成長しました。Salesforceは進化、拡大を続け、お客様に新しいサービスを提供し続けています。

現在では、企業はPlatform、Experience Cloud、Commerce Cloud、Customer 360などのSalesforce製品を使って独自のカスタムアプリケーション、サービス、ポータル、ソリューションを構築し、顧客体験の自動化やパーソナライズを支援できます。そして、あらゆるウェブアプリケーションやウェブサイトと同様に、Salesforceのパフォーマンステストを実施して、正常に機能しているか、応答性があるか、ユーザーベースの拡大に応じてスケールできるかを確認する責任があります。

Salesforceの環境が統合、API、カスタムLightningアプリケーションで拡大し続ける中で、パフォーマンステストはこれらの相互接続されたコンポーネントが大量のユーザーアクセス下でどのように動作するかを検証する上でさらに重要になっています。

Salesforceアプリケーション、ウェブページ、その他のサービスのロードまたはストレステストが必要ですか?私たちは世界中のお客様と協力し、Salesforce環境のパフォーマンステストのソリューションを提供しています。私たちのチームにお問い合わせいただき、LoadViewがどのように役立つかをご紹介します!

Salesforceのロードまたはストレステストを実施

LoadViewはSalesforceのアプリケーション、ウェブページ、API、その他のウェブサービスのテストが可能です。

Lightning App Builder:ローコードアプリケーションフレームワーク

SalesforceのLightning App Builderはローコードアプリケーションフレームワークとして知られていますが、それは実際に何を意味するのでしょうか?簡単に言うと、コードの専門家でない開発者でもアプリ開発を簡単にするために設計されています。Lightning App Builderを使えば、複雑なコードを掘り下げなくても強力なSalesforceアプリが作れます。

このようなローコードフレームワークは、アプリをニーズに合わせてカスタマイズできる使いやすいツールやマイクロサービスを提供します。これにより時間が節約され、負荷が軽減され、チームはより重要な優先事項に集中できます。また、バックログを減らし、更新を容易にしてプロジェクトの進行を加速させます。

さらに「ノーコード」ソリューションもあり、もっとシンプルです。これはコード経験がほとんどない人に適しています。例えば、ウェブサイトやeコマースストアの構築プラットフォームは、ドラッグ&ドロップで機能を配置できるノーコードセットアップをよく使います。とても便利ですが、企業レベルのセキュリティ、コンプライアンス、スケールしたパフォーマンスの制限といった欠点もあります。そこでLightning App Builderが光ります。これは双方の長所を組み合わせており、開発者向けのローコードの柔軟性と、組み込みのセキュリティやコンプライアンスツールといったノーコードマイクロサービスを提供します。つまり、企業は堅牢でスケーラブルなアプリを得て、ユーザーは簡単でシームレスな体験を享受できます。Lightning App Builderを使えば、クラウドベースのアプリ構築はこれまでになく簡単でスマートになりました!

 

Salesforceパフォーマンステスト:概要

Salesforceが私のアプリケーションをホストし、バックエンドのインフラ、セキュリティ、コンプライアンスなどを管理しているなら、なぜSalesforceパフォーマンステストを行う必要があるのか疑問に思うかもしれません。彼らの環境が私のためにスケールできるはずだし、他に何をすれば良いのでしょうか?多くの理由で「設定したら放置」するのは良くありませんが、最も重要な理由は、トラフィックが増加した場合のアプリケーションのパフォーマンスをテストして、性能劣化がないことを確認することです。例えば、あなたの組織が大規模なマーケティング促進を行う場合。あるいは、あなたのSaaSプラットフォームの動画がバイラルになり、多くの人がそれを知りたいと思った場合。またはアプリケーションが季節性で、ブラックフライデーからサイバーマンデーのショッピングシーズンに大きく依存している場合もあります。そうした場合、予期せぬ事態に備える計画を立て始める必要があります。では、どんなパフォーマンステストを行うべきか、それぞれのテストの種類を見てみましょう。

 

パフォーマンステストの種類

パフォーマンステストは非機能テストの一種です。非機能テストの他の種類には、セキュリティテスト、信頼性テスト、コンプライアンステスト、互換性テストなどがあります。ロードテストとストレステストは最も一般的なパフォーマンステストですが、混同されることもあります。それぞれの違いを理解しましょう。

ロードテスト

ロードテストは、最も一般的なパフォーマンステストの種類で、多くの人がよく知っています。ロードテストは、ソフトウェアにどれだけの負荷をかけるとパフォーマンスが低下するかを把握します。

ストレステスト

ロードテストに似ていますが、ストレステストはソフトウェアやシステムを限界まで押し込みます。こうしてパフォーマンスエンジニアはシステムの反応や回復方法を理解できます。

ボリュームテスト

ボリュームテスト(フラッドテストとも呼ばれる)は、大量のデータをアプリケーションに送り、その反応や異常挙動がないかどうかを検証するテスト方法です。

スパイクテスト

スパイクテストはストレステストに似ていますが、ユーザー数は緩やかに増えるのではなく、同時アクセスのユーザーが急激に増加します。その急激な負荷の増加をアプリがどのように処理するかを評価します。

スケーラビリティテスト

キャパシティテストとも呼ばれ、スケーラビリティテストは、ユーザー負荷が増えたり減ったりする際にアプリがどのように動作するかを確認します。これにより、将来の需要に対応するために追加のインフラが必要かを判断できます。スケーラビリティテストの目的は、ユーザー負荷増加に対応して「スケールアップ」できるかどうかを評価することです。

エンデュランステスト

マラソンのように、エンデュランステストは長時間にわたり持続的なトラフィックにアプリがどのように耐えるかを測定します。ソークテストとも呼ばれ、数時間、数日、数週間にわたって実施されることもあります。

 

ご覧のとおり、選択するパフォーマンステストの種類はアプリケーションの性能目標によります。しかし、テストの種類に関係なく、目的は同じです。安定性、応答性、スケーラビリティといったパフォーマンスの問題を負荷下で明らかにすることです。数百または数千のユーザーがアプリケーションを使用していて、突然停止してしまうような事態は避けたいものです。そしてアプリがSalesforce環境でホストされている場合、問題が起きても可視性やコントロール、対応時間が限られます。覚えておいてください。Salesforceはあなたのパフォーマンス要件だけでなく、何千もの企業の要件、つまり毎日何十億ものトランザクションをサポートしなければなりません。

しかし、そのような負荷にも関わらず、Salesforceのようなマルチテナントプラットフォームは、顧客のパフォーマンスとコンプライアンスを維持するため、SLA(サービスレベルアグリーメント)性能閾値内に常にインフラを監視しています。しかし、だからといってSalesforceのパフォーマンステストを完全に省略できるわけではありません。Salesforceがプラットフォームのスケールを自信を持って行えるとしても、あなたのアプリケーションやページが会社の成長や拡大に耐えうるかは別の話です。

salesforce login

Salesforceテスト計画:ベストプラクティス

Salesforceはパフォーマンステストを真剣に考えています。社内のポリシーや手順を無視すると、スロットリングやブロックの対象となる可能性があり、誰もそれを望みません。そのため、パフォーマンステストは本番環境では実行できません。テストはサンドボックスまたは隔離された環境で行い、他のSalesforceユーザーに影響を与えないようにする必要があります。また、パフォーマンステストの申請はテスト日から少なくとも2週間前に承認を得る必要があります。2週間を切る申請は拒否される恐れがあります。Salesforceの立場からすると、彼らの責任はテストの異常挙動を監視し、サービスに問題が発生しないことを確保することに限られます。一般的なSalesforceパフォーマンステストの手順は以下の通りです。

参照: Load Testing Preparation Checklist

 

テスト要件の収集

この段階では、テストの基本的なアウトラインを作成し、それをロードマップとします。ここで、テストするアプリケーション、特定のユーザーペルソナシナリオ、環境固有の質問、期待される平均応答時間とシステム利用率、SLAなどの具体的な内容を含める必要があります。

 

テストモデルの作成

テストモデルは、実際のパフォーマンステストで何が起こると予想するかの表現です。テストの初期要件に基づいて、何が起こると仮定しますか?テストモデルは実際のテスト中に起こることの予測として使われます。テスト前にベースラインパフォーマンス指標を必ず取得してください。これは後で実際のテスト結果と比較するのに役立ちます。もし結果が予測と一致しなければ、結果を再検討して仮説にどんな影響があったかを分析できます。

 

適切なパフォーマンステストツールの選択

適切なパフォーマンステストツールの選択は、予算、時間、専門知識、テストケースなどの要因によります。従来のロードテストツールでは、現代的なプラットフォームやアプリケーションには十分ではありません。LoadViewのスタッフは、当社のプラットフォームがSalesforceアプリケーションのテストに必要なすべてを提供すると信じています。例えば、多くのアプリケーションは優れたユーザー体験を重視しています。真のユーザー体験を理解する唯一の方法は、ユーザーペルソナをスクリプト化して現実のシナリオに沿ったテストを実行する能力です。

 

最適なSalesforceパフォーマンステストツールは何ですか?

JMeterやGatlingなどのオープンソースのロードテストプラットフォームは機能や柔軟性が十分でなく、Micro FocusのLoadRunnerのような複雑で高価なソリューションとは異なり、LoadViewは現代の多様化するアプリケーションのニーズに合わせて設計されています。このソリューションは使いやすいスクリプトレコーダー、実ブラウザでのテスト、複数のロードテスト曲線、グローバルなテストロケーション、その他のエンタープライズレベルの機能を提供し、ユーザーが使用するブラウザに合わせて実際のユーザー行動にマッチしたテストを簡単に設定できます。また、ウェブサービスやREST・SOAP API向けのプロトコルベースのパフォーマンステストも可能です。以下のテストスクリプトの作成でEveryStep Web Recorderについて詳しく説明しますが、詳細は当社の機能ページもご覧ください。

 

Salesforceテスト計画の設計

Salesforceテスト計画には、パフォーマンステスト環境の全体説明や、開始・終了時間、毎秒トランザクション数(TPS)、ラ ンプアップ・ダウン時間などの具体的な計測データを含める必要があります。Salesforceはテスト結果の提供は行わないため、LoadViewのように詳細なレポートやダッシュボードが得られるソリューションを使用し、分析や関係者への報告を行うことが重要です。

 

テストスクリプトの作成

テストスクリプトはSalesforceのロードテストで非常に重要です。バグやエラーのないスクリプト作成に十分注意を払う必要があります。ただし、Salesforceはスクリプトの正確性や実際のシナリオの反映をレビューしません。前述のようにLoadViewはEveryStep Web Recorderというポイント&クリックのスクリプティングツールを提供しています。これにより複雑なユーザーシナリオやクライアント側の操作を簡単に記録できます。

 

load test scripting

 

レコーダーを開いてキーボード操作、マウスクリック、ホバー、マウス動作を記録します。ユーザーの操作通りにアプリをナビゲートします。レコーダーは各ステップを保存します。主な特徴は以下の通りです:

  • 40以上のデスクトップおよびモバイルブラウザ・デバイスをサポート。
  • HTML5、Java、Ruby、Reactなどのウェブアプリ言語・フレームワーク対応。
  • ログイン/パスワードなどの動的変数。
  • ユーザー動作のカスタマイズ、遅延、思考時間。
  • CAPTCHAやOTP(ワンタイムパスワード)対応。
  • フォーム送信やメニュー選択。
  • 暗号化変数。
  • 画像やテキストのコンテンツ検証。
  • その他多数。

スクリプト完成後は、スクリプトやネットワークのエラーがないか再生して確認します。必要に応じて手動編集も可能です。EveryStep Web Recorderをお試しください

 

テストの実行

ついに楽しい部分です。上記の準備が整ったら正式にSalesforceへパフォーマンステストの申請を行います。テスト日は少なくとも2週間前に申請してスケジュールを確定する必要があることを忘れないでください。申請の手順は以下の通りです。

  1. Salesforceアカウントにログインする。
  2. ヘルプポータルに移動する。
  3. ネットワークおよびパフォーマンス > Salesforceに近日の活動を通知を選択する。
  4. パフォーマンステストのスケジュールをクリックする。

さらに、Salesforceチームに提出する情報として以下が必要です:

  • テストの概要(日時など)。
  • 主要な連絡先と担当者。
  • テストの正当性や対象の詳細。
  • 毎秒トランザクション数(TPS)やラ ンプアップ計画などの指標。
  • テストを実施するSalesforceサンドボックスのID。
  • その他関連すると思われる内容。

 

結果の分析

テスト完了後は、結果を内部のチームやステークホルダーと共有できるようにします。幸いなことに、LoadViewを使用していれば、レポートやサマリーがテスト後に自動作成されます。

 

 

概要レポートのほか、要素レベルの構成要素、ウォーターフォールチャート、セッション情報、実行されたスクリプトの概要も閲覧可能で、パフォーマンステスト結果の包括的な把握ができます。さらにウェブアプリやページのテストでは、ユーザーに見える形でのテスト録画も確認でき、負荷時の挙動を視覚的に把握可能です。多くの組織はSalesforceパフォーマンステストをCI/CDパイプラインに組み込み、更新、新しい統合、アプリ変更後に定期的に性能を検証しています。

 

まとめ:Salesforceパフォーマンステスト

Salesforceのアプリケーション、ウェブページ、API、その他のウェブサービスのロードまたはストレステストが必要ですか?私たちは世界中のSalesforceパフォーマンステストを必要とするクライアントと協力しています。UATやプレプロダクション環境であれ、ファイアウォールの背後でのテストが必要であれ、LoadViewプラットフォームが対応します。お客様は、Salesforceロードテストのセットアップで、BlazeMeter、LoadRunner、JMeterなど他の有名なロードテストソリューションよりもLoadViewを好むと話しています。

当社のパフォーマンスエンジニアとサポートチームは、テスト作成、スクリプト作成、計画のサポートを行い、Salesforceロードテストを実施する前に必要なすべてを提供します。私たちはSalesforceパフォーマンステストのプロセスのあらゆる部分であなたを支援します。LoadViewをお試しください、またはパフォーマンスエンジニアとのデモを予約し、LoadViewの全機能をご覧ください。