SalesforceはCRM（顧客関係管理）プラットフォームであり、マーケティング自動化、カスタマーサービス、分析、アプリケーション開発など、ビジネスの顧客中心のあらゆる側面を管理する機能を組織に提供します。最初は単純で分かりやすいクラウドベースのCRMツールとして始まりましたが、急速に成長しました。Salesforceは進化し続け、拡大し、新しいサービスをクライアントに提供し続けています。
現在、企業はPlatform、Experience Cloud、Commerce Cloud、Customer 360などのSalesforce製品を使って、独自のカスタムアプリケーション、サービス、ポータル、ソリューションを構築し、顧客体験の自動化とパーソナライズを支援しています。そして、あらゆるウェブアプリケーションやウェブサイトと同様に、組織はSalesforceのパフォーマンステストを実施し、正常に機能し、応答性があり、ユーザーベースの拡大に合わせてスケールできることを確認する責任があります。
Salesforce環境は統合、API、カスタムLightningアプリケーションで拡大し続けているため、これらの相互接続されたコンポーネントが多大なユーザートラフィック下でどのように動作するかを検証するパフォーマンステストの重要性が増しています。
また、現代のSalesforce環境はAPI、ミドルウェア、サードパーティ統合などの接続サービスに大きく依存しているため、これらの依存関係が負荷時のパフォーマンスにどのように影響するかテストすることが重要です。
Salesforceアプリケーション、ウェブページ、その他のサービスのロードテストやストレステストが必要ですか？私たちは世界中のクライアントと協力し、Salesforce環境のパフォーマンステストを実行するソリューションを提供しています。チームにお問い合わせいただき、LoadViewがどのように役立つかをご紹介しましょう！
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テストプラン：ベストプラクティス
Salesforceはパフォーマンステストを真剣に扱っています。社内のポリシーや手順を守らないとスロットリングやブロッキングが発生する可能性があり、誰にも望まれません。そのため、本番環境でのパフォーマンステストは実行できません。テストはサンドボックスまたは分離環境で行う必要があり、他のSalesforceユーザーに影響を与えないようにしなければなりません。さらに、パフォーマンステストはテスト予定日の少なくとも2週間前に承認申請を提出しなければなりません。2週間より前に申請された要求は却下されることがあります。Salesforceの視点からは、テスト中の異常な挙動を監視する責任だけがあり、サービスの問題が発生しないようにすることが目的です。一般的なSalesforceパフォーマンステストの手順は以下のとおりです。
読む: ロードテスト準備チェックリスト
テスト要件の収集
この段階で、テストの基本的な概要を作成し、ロードマップとして機能させます。ここには、テスト対象のアプリケーション、特定のユーザーペルソナシナリオ、環境固有の質問、予想される平均応答時間とシステム利用率、SLAなどの詳細を含めます。
テストモデルの作成
テストモデルは、実際のパフォーマンステスト中に何が起こると予測するかの表現です。テストの初期要件に基づき、どのような結果になると仮定しますか？テストモデルは、実際のテストで何が起こるかの予測として使われます。テスト前にベースラインパフォーマンス指標を取得し、実テストの結果と比較してください。結果が予想と異なる場合、仮説に影響した要素を検証します。
適切なパフォーマンステストツールの選択
適切なパフォーマンステストツールの選択は、予算、時間、専門知識、テストのユースケースなどの要因に依存します。従来のロードテストツールは、今日のモダンプラットフォームやアプリケーションには不十分です。LoadViewのチームは、Salesforceアプリケーションのテストに必要なすべてを提供できると自信を持っています。多くのアプリは優れたユーザー体験やクライアント体験を提供することに注力しています。真のユーザー体験を理解する唯一の方法は、ユーザーペルソナをスクリプト化し、実際のシナリオに合ったテストを実行する能力を持つことです。
最良のSalesforceパフォーマンステストツールは？
JMeterやGatlingのようなオープンソースのロードテストプラットフォームは機能や柔軟性が不足し、Micro FocusのLoadRunnerのような複雑で高価なソリューションもある中で、LoadViewは変化の激しい今日のアプリケーションの要求に合わせて設計されています。このソリューションは使いやすいスクリプトレコーダー、本物のブラウザでのテスト、複数の負荷テストカーブ、グローバルなテストロケーション、その他企業レベルの機能などを提供し、ユーザーが使うブラウザでの実際のユーザー行動にマッチしたテスト設定を簡単に行えます。ただし、WebサービスやRESTまたはSOAP APIのプロトコルベースのパフォーマンステストも設定可能です。以下のテストスクリプトの開発セクションでEveryStep Web Recorderについて詳述しますが、完全な機能一覧については機能ページをご覧ください。
Salesforceテストプランの設計
Salesforceのテストプランには、パフォーマンステスト環境の詳細な説明、開始及び終了時間、秒あたりトランザクション数（TPS）、ランプアップおよび/またはランプダウン時間など具体的な測定基準を含める必要があります。Salesforceはテスト結果を提供しないため、LoadViewのような包括的なレポートとダッシュボードがあるソリューションを使い、詳細な分析とステークホルダーとの共有が可能にすることが重要です。
テストスクリプトの作成
テストスクリプトはSalesforceロードテストの重要な部分であり、バグやエラーがないよう十分注意を払う必要があります。ただし、Salesforceはスクリプトの正確性や実際のシナリオを適切に反映しているかのレビューは行いません。先述の通り、LoadViewはポイント＆クリックで作成可能なEveryStep Web Recorderというスクリプトツールを提供しており、複雑なユーザーシナリオやクライアント側の操作を簡単に記録できます。
レコーダーを開き、キーボード操作、マウスクリック、ホバーや移動を記録開始してください。ユーザーと同様にアプリケーションを操作し、各ステップが記録されます。レコーダーの特徴は以下の通りです：
- 40以上のデスクトップ/モバイルブラウザとデバイスをサポート
- Webアプリケーションの言語とフレームワーク対応 — HTML5、Java、Ruby、Reactなど
- ログイン/パスワードなどの動的変数
- ユーザーの振る舞い、遅延、思考時間のカスタマイズ
- CAPTCHAやOTP（一回限りのパスワード）対応
- フォーム送信やメニュー選択
- 暗号化変数
- 画像やテキストのコンテンツ検証
- その他多数
スクリプト完成後は、その再生でスクリプトエラーやネットワークエラーがないか確認します。必要に応じてスクリプトの手動編集も可能です。EveryStep Web Recorderをぜひお試しください！
テストの実行
最後に楽しい段階です。上記のステップを完了したら、Salesforceを通じて正式にパフォーマンステストの申請を行う必要があります。テスト予定日の少なくとも2週間前に申請とスケジュール登録を行う必要があります。以下のステップでパフォーマンステストのスケジューリングを行います。
- Salesforceアカウントにログイン
- ヘルプポータルに移動
- ネットワークとパフォーマンス > Salesforce通知を選択
- パフォーマンステストのスケジュールをクリック
また、Salesforceチームに提出するためにテストプランの詳細情報も準備してください。
- テストの一般概要（日時など）
- 主要な連絡先や関係者
- テストの正当性や内容の詳細
- 秒あたりトランザクション数（TPS）やランプアップ計画
- テストが行われるSalesforceサンドボックスのID
- その他テストに関して関連あると思われる情報
結果の分析
テスト完了後は、結果を内部チームやステークホルダーと共有できるようにしたいものです。幸いにも、LoadViewを使用している場合は、レポートやサマリーがテスト終了後に自動で作成されます。
サマリーレポートデータや要素レベルの詳細、ウォーターフォールチャート、セッション情報、実行されたスクリプトの概要を閲覧し、パフォーマンステストの結果を包括的に把握できます。さらに、Webアプリケーション・ウェブページのテストの場合、ユーザーが体験する様子を録画で閲覧できるため、負荷下での動作を確認可能です。多くの組織はSalesforceパフォーマンステストをCI/CDパイプラインに組み込み、アップデートや新規統合、アプリ変更後のパフォーマンスを定期的に検証しています。
結論：Salesforceパフォーマンステスト
Salesforceアプリケーション、Webページ、API、その他ウェブサービスのロードまたはストレステストが必要ですか？私たちは世界中のクライアントと共にSalesforceパフォーマンステストを提供しています。UAT環境、プレプロダクション環境、あるいはファイアウォール内でのテストが必要な場合でも、LoadViewプラットフォームが対応します。クライアントからは、BlazeMeter、LoadRunner、JMeterなど他の人気のロードテストソリューションよりもLoadViewを好むとお聞きしています。
私たちのパフォーマンスエンジニアとサポートチームは、テスト作成、スクリプト作成、計画に関して支援し、Salesforceロードテストを実施する前に必要な準備をすべてサポートします。Salesforceパフォーマンステストのあらゆる段階をガイドするためにここにいます。LoadViewをお試しいただくか、パフォーマンスエンジニアとのデモを予約してLoadViewの全機能をご覧ください。