計画

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

始める前に

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

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

ドキュメント — 詳細については、ドキュメントのセクションまたは使い方の記事を参照してください。

テストの基本原則 — ソフトウェアテストと品質保証の基本原則に注意する必要があります。プロジェクトのテスト経験があることが望ましい。

このような原則を扱うウェブサイト、本書、コースは多くあり、本ドキュメントでは詳細には取り扱われない。

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

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

品質に対する取り組み — テストを行う者は中立的なままで、テストの結果を報告するだけで済むことは、最も重要です。

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

関与する — すべての関係者が任意の会議(ステータス、ワークショップなど)で完全に関与していることを確認するのはプロジェクトマネージャの責任ですが、情報収集や要件分析プロセスなど、プロジェクトサイクルの早い段階でも対応してください。

お客様の関与 — 同様のテーマで、テストケースとプランを定義する際に、(可能な場合は)お客様に関与するようにします。

テストの種類

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

メモ

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

ユニットテスト — 個々の要素が単独ではあるが正しく動作することを確認するために開発チームが行うテスト(通常)。

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

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

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

ブラックボックステストは、対象となる要素の内部動作に関する知識なく実行される、完全なユニット/コンポーネント/モジュールの機能テストです。

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

機能は黒いボックス単位でテストされます。

パフォーマンステスト :AEMのテストでは、パフォーマンステストが重要です。

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

  • 標準

    90%の割合でサイトが経験する条件。 例えば、作者の割合しかシステムを使用していない場合です。

  • ピーク時

    特別な事情により、比例的に短い時間で経験される条件例えば、すべての作成者が同時にシステムを使用している場合や、新しいコンテンツが公開され、サイトの表示に多くの訪問者がアクセスする場合などです。

  • 極端な

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

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

その結果を使用して、アプリを調整します。

応力テスト — 応力テストは、コンポーネントやアプリケーションが極端な条件下でどのように動作するかを確認するために行われます。特に、これらのテストは、行動の悪化、エレメントの失敗、その方法を示すために使用されます。

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

回帰テストは、自動化を可能な限り行うのに適しており、迅速かつ一貫した方法で繰り返すことができます。

受け入れテスト — 受け入れテストは、お客様がプロジェクトを受け入れたことを示すために使用される特別なカテゴリです。

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

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

はじめに

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

目標の定義 — 高レベルの目標を定義し、テストの進行に合わせた最適な調整の開始点として機能させます。次の操作を行います。

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

などをおこないます。

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

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

外部のWebサイトからのトラフィック統計の収集 — 他のWebサイトからのトラフィック統計を比較できる場合は、比較のために収集してみますが、これらの統計は必ずしも公開されているわけではありません。

ターゲット指標の確認 — 指標は、達成すべきパフォーマンスの目標を示す、Webサイトの質の定量測定値を定義するために使用されます。

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

このページ

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now