計画

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

始める前に

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

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

ドキュメント — 詳しくは、ドキュメントの節またはハウツー記事を参照してください。

テストの基本原則 — ソフトウェアテストと品質保証の基本原則を認識しておく必要があります。望ましくは、プロジェクトのテスト経験が必要です。

このような原則を取り扱うウェブサイト、本、コースは多くあり、本書では詳細には取り扱いません。

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

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

品質への取り組み — テストを行う人は誰でも中立を保ち、テストの結果を報告するだけで済みます。

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

関与する — すべての関係者があらゆる会議(ステータス、ワークショップなど)に完全に関与するようにするのはプロジェクトマネージャーの責任ですが、情報収集や要件分析のプロセスを含むプロジェクトサイクルにできるだけ早く関与するよう努める必要があります。

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

テストの種類

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

メモ

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

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

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

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

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

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

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

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

パフォーマンステスト - AEMをテストする際に、パフォーマンステストが重要です。

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

  • 標準

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

  • ピーク時

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

  • 極端

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

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

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

ストレステスト :ストレステストは、極端な条件下でのコンポーネントやアプリケーションの動作を確認するためにおこなわれます。特に、これらのテストは、動作の低下、要素の失敗時、および方法を示すために使用されます。

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

回帰テストは、(可能であれば)自動化に適した候補で、迅速かつ一貫して繰り返すことができます。

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

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

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

はじめに

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

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

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

などをおこないます。

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

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

外部のWebサイトからトラフィック統計を収集 — 可能な場合は、比較のために他のWebサイトからトラフィック統計を収集しようと試みますが、これらの数字は常に公開されるわけではありません。

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

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

このページ