テストケースの定義

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

ユースケース

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

要求仕様の詳細

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

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

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

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

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

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

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

特定の側面のテスト

AEMをテストする際には、特に関心のある特定の詳細を以下に示します。

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

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

AEMは次の2つのアプリケーションと見なす必要があります。

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

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

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

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

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

パーソナライズ機能

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

正しい動作を確認するには、キャッシュもチェックする必要があります。

Dispatcher

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

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


  • Webサイトの訪問者にコンテンツの更新が表示されるようにしてください。


  • 続行する場合は、1台のサーバーがシャットダウンしてもWebサイトが引き続き使用可能であることを確認してください。


  • ClustersClustersは、次の機能を提供するために使用されます。


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


    • 完全なフェイルオーバーを伴うPerformanceLoadバランシングは、クラスターのパフォーマンスを向上させます。顧客プロジェクトに使用する場合は、構成の正しい操作を確認するために、クラスターをテストする必要があります。

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

AEMにインターフェイスされたサードパーティソフトウェアは、詳細な要件仕様で参照されます。

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

このページ