計画

ここでは、テストを計画するために知っておく必要があることについて説明します。テストを実施する前に、次の項目を検討する必要があります。

始める前に

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

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

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

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

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

回避すべき前提 - 最も大きな前提は、web サイトが毎日数百万件のリクエストに対応する必要があることです。この前提は状況によっては該当する場合もありますが、異なる場合もあります。

将来の数は完全な精度では予測できませんが、既存のサイトや経験されたトラフィックを観察すると、良い指標が得られます。次に、トラフィック増加の予測値または期待値に基づいて、見積もることができます。

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

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

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

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

テストの種類

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

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

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

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

機能テスト — これらは、ソフトウェアの機能をテストするために使用されます。一連のテストは、すべての詳細な機能を対象にし、予期される入力、予期しない入力および誤入力を考慮するように設計します。

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

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

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

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

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

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

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

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

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

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

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

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