ArcGIS システムのテストでは、実装された設計が期待どおりに動作し、想定されたワークフロー、ユーザー、負荷をサポートできることを検証する必要があります。 システム テストは、本番環境で問題が発生する前に問題を発見して修正する機会となります。 可能なすべてのコンポーネント、イベント、または状況をテストするのは現実的ではありませんが、システムの主要な側面をテストするため、いくつかの実用的な方法を定義する必要があります。 たとえば、システムが定義されたワークフローをサポートし、コンポーネントの障害から復旧して、新しいワークロードを処理できることをテストします。
意図的で構造化されたテストは、アプリケーション、ワークフロー、またはシステムの成功に不可欠です。 開発サイクル全体を通じて、機能テスト、アクセシビリティー テスト、受け入れテスト、その他にも各種のテストが関連します。 テストはアーキテクチャー プロセスの重要な部分で、アーキテクチャーの推奨事項を検証するだけでなく、特定のデータベースやソフトウェア リリースのパフォーマンスが他の製品と比べて特に優れている、または劣っているなど、アーキテクチャーの変更を提案するための手がかりとなる情報が得られる場合もあります。
このセクションの目的から、このトピックではパフォーマンス テスト (システム ベースラインのパフォーマンス特性が満たされているかどうかを識別するために役立つ方法とプロセス) に焦点を当てます。 テストはテレメトリー監視と並行して行う必要があり、監視対象の各コンポーネントのテストを可能にする必要があります。 システムに変更が加えられたときは、劣化が起きていないかどうかを識別するため、テストの再実行が不可欠です。 また、予想される負荷の変化に基づいて、潜在的なアーキテクチャーのボトルネックを通知するためにも、テストを使用する必要があります。
このような、理想的なレベルの反復的で標準化された繰り返し可能なテストを成功させるには、プロセスの自動化が必要です。 SaaS のデプロイメント パターンでは、自動テスト、特にパフォーマンス テストを実装するために、他のプロバイダー、システム、および利害関係者との調整も必要です。
何よりも、堅実なテストの取り組みでは、テストの目標、テストする項目としない項目 (テストの範囲)、測定の対象 (テレメトリー)、および成功基準を決定する必要があります。
パフォーマンス テストでは、エンド クライアントのハードウェア、バックエンド システムへのネットワーク接続、バックエンド システムの設定など、多くの要因がワークフローのパフォーマンスに影響を与えます。 これらのコンポーネントの詳細を理解することは、パフォーマンス計測が主にテスト対象の ArcGIS ソフトウェアによって影響を受けるのか、それともプロキシー、データベース、ネットワーク スイッチなど他のコンポーネントによるレイテンシーや中断の影響を受けるのかを理解するために重要です。
さまざまなタイプのテストを使用して、各種の目標を達成できます。 たとえば、次のようなテストを実施できます。
テスト戦略を構築する際には、目標を明確にすることで、その後の作業をより効率的に進めることができます。
多くのシステムでは、機能テストや負荷テストを目的とした「下位」の環境 (テスト、ステージング、運用前など) を維持しています。 テスト環境またはステージング環境の正しい使用法の詳細については、このサイトの「環境分離」ページをご参照ください。
エンタープライズ システムには、多くの場合にいくつかの別のアプリケーションがあり、デスクトップ、モバイル、Web クライアントなどのワークフローが実行されます。また、読み取り/書き込みやレポート作成のワークフロー、さまざまな種類のユーザーのサポートも含まれる場合があります。 最初にテスト対象の範囲を定義せずに「システム全体をテスト」しようとすると、テストケースが膨大になり、有用な情報が得られにくくなります。
適切なシステム テストは、実際の使用方法を模倣することで、システムが期待どおりに機能し、パフォーマンスを発揮するかを確認できます。 そのため、テスト範囲には、システムが明確にサポート対象としているワークフローを含め、成功基準を評価するためのメトリックが得られるように設計する必要があります。 たとえば、既存のシステムでソフトウェアをアップグレードする場合、テスト範囲には、負荷がかかった状態で実行されるすべての主要なワークフローを含め、1 時間あたりの想定最大操作数を反映させる必要があります。
一部のワークロードは同時に発生しない可能性があります。たとえば、データをインポートまたはエクスポートするスクリプトの夜間の処理と、通常の昼間の運用は同時に行われません。 このような場合、システムを 2 回テストすることがあります。1 回は、昼間システムにアクセスするユーザーの負荷を処理できることを確認するため、もう 1 回は、夜間の処理が必要な時間内に完了することを確認するためです。 また、変更が導入された場合は、システムを再テストして、それらの変更が悪影響を引き起こしたかどうかを確認する必要があります。
テレメトリーは、システムのテスト中に、さまざまなシナリオにおけるシステムのパフォーマンスについての情報を収集し、システムが要件を満たしているかどうかを評価して、問題や異常を識別するために使用されます。 ArcGIS Server のデプロイメントの負荷テストを真っ先に思い浮かべる人も多いかもしれませんが、重要なのはシステム全体にわたってテレメトリーをキャプチャーすることです。 たとえば、サーバー インフラストラクチャー全体にわたってテレメトリーを収集した結果、システムのパフォーマンスが高いことが示されたにもかかわらず、デスクトップ コンピューターのリソースが不足していたためにエンド ユーザーがワークフローを完了するのに苦労したことから、バックエンド システムのパフォーマンスは妥当だったにもかかわらず、エンド ユーザーには許容できないほど遅いシステムに見えたことが後から判明することもあります。
主な目標の 1 つは、テレメトリーによって収集されたリクエストに基づき、テスト スクリプトやテスト中に送信されるリクエスト (平均的なリクエストと外れ値の両方) をモデル化することです。 テストでは、個々のコンポーネントとともにエンドツーエンドのプロセスをテストすることも検討する必要があります。 ほとんどのエンタープライズ システムは複雑なので、単一のテスト ツールを使用してすべてのテスト機能を実行することはできないかもしれませんが、JMeter などの自動テスト ランナーは、標準化されたテストの入力と出力を使用してテスト ルーチンを調整できるように構成する必要があります。
適切な成功基準があれば、システムがテストに合格したか失敗したか、またどこに問題があるかを判断できます。 成功基準は、テストの範囲、およびキャプチャーするテレメトリーの種類と粒度を示します。 基準には、時間あたりの操作数、同時ユーザー数、ハードウェア パフォーマンス、ワークフローの完了時間などのメトリックが含まれることがあります。
テストに関連する追加リソースとしては、次のようなものがあります。