パフォーマンス・テスト

パフォーマンス・テストは、変更を環境にデプロイするうえで極めて重要なステップです。 最終パフォーマンス・テストの場合はすべて、実稼働前環境でテストを実行します。

IBM Sterling® Order Managementシステムの実装を開始する際には、すべてのパフォーマンステストを完了し、サービス開始の最低2週間前にテストに署名してください。 この時間フレームにより、テスト段階でパフォーマンス問題が見つかった場合に対応するための時間をチームが持てるようになります。

開始時のパフォーマンステストの一環として、IBM Sterling Order ManagementSystemオペレーションチームにテストサマリーレポートを提出してください。 このレポート内に、テスト済みのピークのボリュームおよび負荷を含めます。 ピーク量と負荷は、IBM Sterling Order Managementに記載されている予定量に対応し ていなければならない。 契約がピーク時のオーダー明細の数「N」に基づいている場合、その上限までパフォーマンス・テストを実行します。 ユーザー、またはユーザーのビジネス・パートナーが、それらの契約ピーク・ボリュームを超えてテストすると、テストによるパフォーマンス上のリスクをすべて負うことになります。

テスト計画の定義

IBM Sterling Order ManagementSystemサービスのパフォーマンスを確保する一環として、開始時および変更 の実施時にパフォーマンス・テスト計画を作成します。 パフォーマンス・テスト計画を作成するには、以下のタスクを実行する必要があります。
  • ワークロードの混合とボリュームを設定します。 予測ボリューム、年ごとの増加量、予測ピーク時間のボリュームなどを処理するため、Web サーバー・ログまたは他のツールからのデータを使用します。
    重要: ロード・スクリプトを開発する前に、ワークロードおよびボリューム定義を定義し、明確に文書化してください。
  • 顧客の非機能要求を検証します。 非機能要求の定義は、設計段階で行います。
  • アプリケーション・コードが安定するよう、すべての開始基準および終了基準を定義します。

テスト段階および反復テスト・プロセス

  1. 単一ユーザー・テスト
    • 詳細なコード分析
    • パス長さ
    • メモリー・フットプリント
    • SQL 基本構造
    • アプリケーション・アーキテクチャー
  2. 単一システムの競合テスト
    • 単一システム
    • ドライブ・フルのワークロード混合
    • 反復テストおよび修正/調整
    • 調整済み参照の確立
  3. 増分スケール・テスト
    • ファームの増分拡張
    • 単一システムの調整
    • システムの反復的な修正および調整
  4. 安定度テスト
    • フェイルオーバー
    • 長期実行
以下の図は、反復的なテストと調整のプロセスの概要を示したものです。
反復テスト・プロセスを示す画像。
  • ベースライン
    • システムの現在の実行内容
    • 改善の測定に必須
  • 最低限の調整
    • 実行間の変更を制限
  • テスト
    • 十分な期間
    • 安定状態での測定
  • 監視
    • システムおよびログをすべて見る
    • 結果の記録
    • 次のテストの計画

テスト環境、データ、および機能テストとパフォーマンス・テストの責任者

  責任 環境 データ
単体テスト 実装チーム デベロッパーズ・ツールキット環境 モック
機能テスト 実装チーム 品質保証 モック
ユーザー受け入れテスト ユーザーまたはユーザーのビジネス・パートナーのサービス・チーム 実動前および実動
品質保証 *
有効なビジネス・データ
パフォーマンス・テスト ユーザーまたはユーザーのビジネス・パートナーのサービス・チーム 品質保証 (初期パフォーマンス・テスト)
実動前 ( DynaCache 使用可能)
有効なビジネス・データ
コンポーネント・フェイルオーバー・テスト 実装チーム 実動 有効なビジネス・データ
* 機能ユーザー受け入れテストは、実稼働環境のデータをテストで使用する準備ができていない場合に、 品質保証環境 で実行できます。
以下のタスクを実行する場合など、デベロッパーズ・ツールキット環境内のすべてのアプリケーション・プロファイルを完了します。
  • パフォーマンスが不十分な機能またはモジュールを特定するためや、設計およびコード内の非効率な箇所を特定するため、Java コードのプロファイルを作成します。
  • SQL アクティビティーのトレースを行い、SQL パフォーマンス・ボトルネックを切り分けて確認するための SQL トレースおよび分析。
  • キャッシュ可能な機能がすべて正確かつ効果的にキャッシュされるようにするための、DynaCache 実装の検証。
  • メモリー・リークと、設計およびコード内の非効率な箇所を特定するための JavaScript コードのプロファイル作成。
  • 重複または不要な要求を特定するための要求分析。