計画 planning

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

始める前に before-you-start

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

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

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

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

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

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

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

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

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

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

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

テストの種類 types-of-tests

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

NOTE
実行する順でテストの一覧を示します。

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

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

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

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

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

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

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

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

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

  • 標準

    90% の確率でサイトが経験する条件。例えば、作成者の一部だけがシステムを使用している場合です。

  • ピーク

    特殊な状況のために比例的に短時間に経験される条件。例えば、すべての作成者がシステムを同時に使用している場合や、新しいコンテンツが公開され、サイトを表示する訪問者数が増えた場合などです。

  • 極端

    新しく関心度が極度に高いコンテンツを web サイトに公開するときに、パフォーマンスを予測するために使用できます。過酷条件時のピークが発生する可能性がありますが、完全に予測することはできません。

    こうした状況は、特定のイベントのチケットが発売されたり、待望の Web サイトが初めて公開されたりする場合に発生することがあります。

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

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

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

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

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

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

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

はじめに getting-started

詳細なテストケースとテスト計画に取り掛かる前に、次の作業を行います。

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

  • 要件の詳細仕様に従って機能をテストします。
  • ターゲット指標に従ってパフォーマンスをテストします。

その他。

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

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

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

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

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

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2