計画 planning

このドキュメントでは、テストの計画に必要な情報を説明します。 また、テストを実施する前に、次の質問に答える必要があります。

始める前に before-you-start

実際の分析とテストの定義を開始する前に、次の情報を確認してください。

AEM のアーキテクチャ - AEM のアーキテクチャと基本原則の概要については、「基本概念」を参照してください。

ドキュメント ― 詳しくは、各種のドキュメントのセクションや各方法に関する記事を参照してください。

テストの基本原則 ― ソフトウェアテストと品質保証の基本概念を知っている必要があります。プロジェクトのテスト経験があれば尚可です。

多くの Web サイト、本、コースではこのような原則を扱っており、このドキュメントでは詳細に説明しません。

回避すべき前提 — 最も大きな前提（定期的におこなわれる）は、Web サイトが毎日数百万件のリクエストに対応する必要があることです。状況によっては、これが当てはまる場合がありますが、想定できません。

将来の数は完全な精度では予測できませんが、既存のサイトや経験されたトラフィックを観察すると、良い指標が得られます。その後、トラフィックが増加すると期待される要因に応じて、推定を行うことができます。

品質への取り組み ― テスト担当者は中立的な立場を保ち、テスト結果の報告のみをおこなうことが特に重要です。

テスト結果に基づいて決定やアクションの開始をおこなうのは、プロジェクトマネージャーの役割です。

関わる ― すべてのチームをすべてのミーティング（ステータス、ワークショップなど）にしっかり参加させることはプロジェクトマネージャーの役割ですが、プロジェクトサイクルのできるだけ早い段階でプロジェクトマネージャーがプロジェクト（情報収集プロセスや要件の分析プロセスなど）に関わるようにしてください。

顧客を関与させる ― 同様のテーマについて、テストケースと計画を定義するときは、（可能であれば）顧客に協力を求めるようにします。

テストのタイプ types-of-tests

テストには、AEMプロジェクトをテストする際に使用するのに適した、様々な標準の分類があります。 どちらを使用するかを決定するには、次の点に精通している必要があります。

単体テスト ― 個々の要素が正しく動作していることを確認するために、（通常は）開発チームがおこなうテスト。

統合テスト — 組み合わせ時にモジュールをテストします。このテストは、単体テストの後、システムテストの前におこないます。

スモークテスト — これらは、ソフトウェアが実行中で、高レベルの機能が使用可能であることを証明するために使用される間に合わせのテストです。詳細はテストされていません。

機能テスト — これらは、ソフトウェアの機能をテストするために使用されます。一連のテストは、予期される入力と予期しない入力、または誤った入力の両方を含め、すべての機能の詳細をカバーするように設計されます。

ブラックボックステストは、問題の要素の内部動作を知らずにおこなう、完全なユニット/コンポーネント／モジュールの機能テストです。

システムテスト — システムを完全に統合し、適切なプラットフォームにインストールしたら、システム全体をテストします。

機能をブラックボックス単位でテストします。

パフォーマンステスト - AEM をテストする場合、パフォーマンステストは欠かせません。

これらは、異なる条件でのパフォーマンスを示すために使用されます。

その後、結果を使用してアプリケーションを調整します。

ストレステスト ― ストレステストは、極端な条件下でコンポーネントまたはアプリケーションがどのように動作するかを確認するためにおこないます。特に、これらのテストは、動作の低下、要素の失敗のタイミング、方法を示すために使用されます。

回帰テスト — 回帰テストは、ソフトウェアの以前のリリースで既に実証済みの機能がまだ正しく動作していることを確認するために使用されます。

回帰テストは、（可能な場合は）自動処理に適しており、迅速かつ一貫して繰り返すことができます。

受け入れテスト ― 受け入れテストは、顧客によるプロジェクトの承認を示すために使用されるので、特殊な分類のテストです。

受け入れテスト項目では、前述の多様なカテゴリのテストを組み合わせることもあります。また、プロジェクトが顧客の要件を満たしていることを確認するために選択します。

詳しくは、受け入れとサインオフを参照してください。

はじめに getting-started

詳細なテストケースとテスト計画を開始する前に、次の操作を実行できます。

目標の定義 — テストの進行に合わせた微調整の出発点として機能する高レベルの目標を定義します。次の操作を実行します。

特に。

既存の Web サイトからトラフィック統計を収集 — この情報は、ログファイルから抽出できます。詳しくは、パフォーマンスの監視を参照してください。

これらの数字は、既存の Web サイト上の現在のトラフィック（量と広がり）を示し、新しい Web サイトの基点を形成する際に使用できます。

外部 Web サイトからトラフィックの統計を収集 ― 可能であれば、他のキャンペーン用 Web サイトのトラフィックの統計情報を収集してください。ただし、この情報は常に公開されているとは限りません。

ターゲット指標の確認 ― 測定基準を使用して、Web サイトの品質に関する定量的測定を定義します。これは達成するパフォーマンス目標を示します。

これらは、プロジェクトの開始時に、顧客と共に定義する必要があります。詳しくは、 ターゲット指標 を参照してください。