Show Menu
トピック×

テストケースの定義

テストケースは、次の項目に基づいて定義する必要があります。
ユースケース
  • アクター(特定のアクションを開始する役割)とシステムとのやり取りにおいて必要とされる機能を定義します。
  • ユースケースは、顧客によって定義されます。
要求仕様の詳細
  • すべての機能およびパフォーマンス要件をテストする必要があります。
テストでは、次の事項を明確に定義する必要があります。
  • 前提条件これらは、特定のシステム、設定、またはテスターエクスペリエンスを対象とする場合があります。
  • 実行手順。適切な詳細レベルで指定します。
  • 期待される結果。
  • 合格または不合格の条件をクリアします。
テストケースを自動化すると、繰り返されるタスクを省略できるので、明らかに便利です。

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

ただし、テストケースの自動化は重要な投資なので、次のような特定の側面を考慮する必要があります。
  • セットアップと設定に時間、労力、経験が必要。
  • ブラウザーベースの場合は、ブラウザーの更新がインストールされる際に問題が発生するリスクが高くなります。修正するのにさらに時間がかかる。
  • 大きなプロジェクトに対してのみ実現可能です。
  • テスト用または長期リリース計画用に複数のリリースが生成される場合に適しています。

特定の側面のテスト

AEMをテストする際には、特に重要な点がいくつかあります。
オーサー環境とパブリッシュ環境
ただし、環境で取り上げ ると 、テストに関するAEMの決定要因を強調する価値があります。
AEMは、次の2つのアプリケーションと見なす必要があります。
  • 作成者環 境この インスタンスを使用すると、作成者はコンテンツを入力し、発行できます。 これには小規模で予測可能なユーザーのセットが含まれ、特定の機能とパフォーマンスが非常に重要です。
  • the Publish environment This instance presents the website in its published form for access from visitors. 通常、これはより多くのユーザーセットを持ち、トラフィック量が必ずしも100%予測可能とは限りません。 要求に応答する際には、パフォーマンスは依然として重要です。 キャッシュとロードバランシングも考慮する必要があります。
同じソフトウェアですが、次のようになります。
  • 異なる目的を果たす
  • 機能性と性能に関して異なる要件を持つ
  • 異なる設定が行われる
  • は別々に調整されます。
  • それぞれに独自の受け入れテストがある
したがって、これらの環境のテストは、異なるテストケースを使用して別々におこなう必要があります。
パーソナライズ
パーソナライゼーションをテストする場合は、行動を証明するために、複数のユーザーアカウントを使用して個々の使用事例を繰り返す必要があります。
キャッシュの動作が正しいかどうかも確認する必要があります。
Dispatcher
多くのプロジェクトで、キャッシュおよびロードバランシングのために Dispatcher をインストールします。
(キャッシュが発生するレベルおよび場所が多様なので)テストの実行は複雑で、ブラックボックスベースでおこなう必要があります。テストの主な要素は次のとおりです。
  • 正確さに ​より、Webサイトの訪問者がコンテンツの更新を確実に確認できます。
  • 継続性 ​により、1台のサーバがシャットダウンしてもWebサイトが引き続き利用可能になります。
  • クラスター ​は、次の機能を提供するために使用されます。
    • フェイル ​オーバー:1台のサーバーで障害が発生した場合は、クラスター内の他のサーバーが処理を引き継ぎます。
    • フルフェイルオ ​ーバーを使用したパフォーマンスのロードバランシングは、クラスターのパフォーマンスを向上させます。 お客様のプロジェクトに使用する場合は、構成の正しい動作を確認するためにクラスターをテストする必要があります。

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

AEMにインターフェイスされるサードパーティ製ソフトウェアは、「要件の詳細な仕様」に記載されています。
必要なテスト(指定範囲によって異なる)を調査し、明確なテストをおこなう必要があります。