テストケースの定義 defining-your-test-cases
テストケースは、次の条件に基づく必要があります。
ユースケース
- これらは、アクター（特定のアクションを開始する役割）とシステムとの間のやり取りに関して必要な機能を定義します。
- ユースケースは、お客様が定義する必要があります。
要件の詳細仕様
- すべての機能要件とパフォーマンス要件をテストする必要があります。
テストでは、次の事項を明確に定義する必要があります。
- 前提条件：具体的なシステム、設定、テスター向けのエクスペリエンスが含まれる場合があります。
- 従うべき手順適切な詳細レベルで
- 期待される結果。
- 合格または不合格の基準を明確にします。
テストケースの自動化の見通しは、繰り返しのタスクを排除できるので、明らかに魅力的です。
手動テストと自動テスト manual-versus-automated-tests
ただし、テストケースの自動化は大きな投資なので、次の点を考慮する必要があります。
- セットアップと設定には、時間、労力、経験が必要です。
- ブラウザーをベースにしている場合、ブラウザーのアップデートがインストールされる際に問題が発生するリスクが高くなります。修正にはさらに時間が必要です。
- 大きなプロジェクトでのみ実際に実行可能です。
- 複数のリリースがテスト用または長期リリース計画用に生成されている場合に適しています。
特定の側面のテスト testing-specific-aspects
AEM のテストをする際に、特に関連のあるいくつかの事項を次に説明します。
オーサー環境とパブリッシュ環境
ただし、環境で説明していますが、テストに関する AEM の決定要因をハイライトする価値があります。
AEM は 2 つのアプリケーションとして考える必要があります。
- 作成者 環境
このインスタンスを使用すると、作成者はコンテンツを入力および公開できます。
これには、少数の予測可能なユーザーのセットが含まれ、そのユーザーに対する特定の機能とパフォーマンスが重要です。 - 公開 環境
このインスタンスは、訪問者がアクセスするための、公開済みのフォームの web サイトを表します。
この環境には通常、より多くのユーザーのセットが含まれ、トラフィック量が常に 100% 予測できるわけではありません。リクエストに応答する際は、パフォーマンスが引き続き重要です。キャッシュとロードバランシングも考慮する必要があります。
同じソフトウェアでも、次のようになります。
- 異なる目的を果たす
- 機能とパフォーマンスに関して異なる要件を持つ
- 別の方法で設定される
- 別々に調整される
- は、それぞれ独自の受け入れテストを持ちます
つまり、別々にテストし、異なるテストケースでテストする必要があります。
パーソナライズ機能
パーソナライゼーションをテストする場合、動作を証明するために、複数のユーザーアカウントを使用して個々のユースケースを繰り返す必要があります。
正しい動作を得るには、キャッシュもオンにする必要があります。
Dispatcher
ほとんどのプロジェクトでは、キャッシュとロードバランシングのために Dispatcher がインストールされます。
テストは困難です（キャッシュは様々なレベルや場所でおこなわれます）。また、ブラックボックスベースでおこなう必要があります。 テストの主要な側面は次のとおりです。
-
精度;web サイトの訪問者がコンテンツの更新を確実に閲覧できるようにします。
-
連続性;1 台のサーバーがシャットダウンしても、Web サイトが引き続き使用可能であることを確認します。
-
クラスター
クラスターは以下を提供するために使用されます。- フェイルオーバー
1 台のサーバーに障害が発生すると、クラスター内の他のサーバーが処理を引き継ぎます。 - パフォーマンス
ロードバランシングと完全なフェイルオーバーをおこなうと、クラスターのパフォーマンスが向上します。
- フェイルオーバー
顧客のプロジェクトで使用する場合、クラスターをテストし、顧客の設定で正常に動作することを確認する必要があります。
サードパーティのソフトウェアのテスト testing-third-party-software
AEM に接続されているサードパーティのソフトウェアは、詳細要件仕様で参照されます。
必要なテスト（指定範囲によって異なる）を調査し、明確なテストをおこなう必要があります。