テストケースの定義

テストケースは、次の項目に基づいて定義する必要があります。

ユースケース

  • アクター（特定のアクションを開始する役割）とシステムとのやり取りにおいて必要とされる機能を定義します。
  • ユースケースは、顧客によって定義されます。

要求仕様の詳細

  • すべての機能要件とパフォーマンス要件をテストする必要があります。

テストでは、次の事項を明確に定義する必要があります。

  • 前提条件：具体的なシステム、設定、テスター向けのエクスペリエンスが含まれる場合があります。
  • 実行手順。適切な詳細レベルで指定します。
  • 期待される結果。
  • 合格または不合格の基準を明確にします。

テストケースを自動化すると、繰り返されるタスクを省略できるので、明らかに便利です。

手動テストか自動テストか

ただし、テストケースの自動化は大きな投資なので、次の点を考慮する必要があります。

  • セットアップと設定には、時間、労力、経験が必要です。
  • ブラウザーをベースにしている場合、ブラウザーのアップデートがインストールされる際に問題が発生するリスクが高くなります。修正にはさらに時間が必要です。
  • 大きなプロジェクトでのみ実際に実行可能です。
  • 複数のリリースがテスト用または長期リリース計画用に生成されている場合に適しています。

特定の側面のテスト

AEM のテストをする際に、特に関連のあるいくつかの事項を次に説明します。

オーサー環境とパブリッシュ環境

ただし、環境で説明していますが、テストに関する AEM の決定要因をハイライトする価値があります。

AEM は 2 つのアプリケーションとして考える必要があります。

  • 作成者環境
    このインスタンスを使用すると、作成者はコンテンツを入力および公開できます。
    これには、少数の予測可能なユーザーのセットが含まれ、そのユーザーに対する特定の機能とパフォーマンスが重要です。

  • 公開環境
    このインスタンスは、訪問者がアクセスするための、公開済みのフォームの web サイトを表します。
    この環境には通常、より多くのユーザーのセットが含まれ、トラフィック量が常に 100% 予測できるわけではありません。リクエストに応答する際は、パフォーマンスが引き続き重要です。キャッシュとロードバランシングも考慮する必要があります。

同じソフトウェアでも、次のようになります。

  • 異なる目的を果たす
  • 機能とパフォーマンスに関して異なる要件を持つ
  • 別の方法で設定される
  • 別々に調整される
  • それぞれに独自の受け入れテストがある

したがって、これらの環境のテストは、異なるテストケースを使用して別々におこなう必要があります。

パーソナライズ機能

パーソナライゼーションをテストする場合、動作を証明するために、複数のユーザーアカウントを使用して個々のユースケースを繰り返す必要があります。

正しい動作を得るには、キャッシュもオンにする必要があります。

Dispatcher

多くのプロジェクトで、キャッシュおよびロードバランシングのために Dispatcher をインストールします。

（キャッシュが発生するレベルおよび場所が多様なので）テストの実行は複雑で、ブラックボックスベースでおこなう必要があります。テストの主要な側面は次のとおりです。

  • 精度
    Web サイトの訪問者がコンテンツの更新を確実に閲覧できるようにします。

  • 連続性
    1 台のサーバーがシャットダウンしても、web サイトが引き続き使用できるようにします。

  • クラスター
    クラスターは以下を提供するために使用されます。

    • フェイルオーバー
      1 台のサーバーに障害が発生すると、クラスター内の他のサーバーが処理を引き継ぎます。

    • パフォーマンス
      ロードバランシングと完全なフェイルオーバーをおこなうと、クラスターのパフォーマンスが向上します。
      顧客のプロジェクトで使用する場合、クラスターをテストし、顧客の設定で正常に動作することを確認する必要があります。

サードパーティのソフトウェアのテスト

AEM に接続されているサードパーティのソフトウェアは、詳細要件仕様で参照されます。

必要なテスト（指定範囲によって異なる）を調査し、明確なテストをおこなう必要があります。

このページ