Show Menu
トピック×

計画

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

始める前に

実際にテストの分析と定義を始める前に、次の情報を確認してください。
AEMアーキテクチャ - AEMのアーキテクチャと基本原則について詳しくは、「基本概念」を参照してください。
ドキュメント — 詳しくは、ドキュメントの任意のセクションまたは使い方の記事を参照してください。
テストの基本原則 — ソフトウェアテストと品質保証の基本原則に注意する必要があります。 プロジェクトのテストの経験があることをお勧めします。
このような原則を扱うウェブサイト、本書、コースは多くあり、本書では詳しく説明しません。
回避する前提条件 - webサイトが毎日数百万件のリクエストを処理する必要があることを(定期的に行う)最も大きな前提としています。 この前提は状況によっては該当する場合もありますが、異なる場合もあります。
将来の数値を100%の精度で予測することはできませんが、既存のサイトと経験したトラフィックを観察すると、良い表れが得られます。 次に、トラフィック増加の予測値または期待値に基づいて、見積もることができます。
クォリティへの取り組み — テストを行う人は誰でも中立的なままで、テストの結果を報告することが最も重要です。
テスト結果に基づいて決定やアクションの開始をおこなうのは、プロジェクトマネージャーの役割です。
Bece Incerated — すべての関係者が任意の会議(ステータス、ワークショップなど)に完全に参加するようにするのはプロジェクトマネージャの責任ですが、情報収集や要件分析プロセスを含め、プロジェクトサイクルの早期の段階でも参加するようにしてください。
お客様の関与 — 同様のテーマで、テストケースやプランを定義する際に、(可能な場合は)お客様の関与を試みます。

テストの種類

AEM プロジェクトをテストするときには、様々な種類のテストを使用できます。どちらを使用するかは、次の点に精通しておく必要があります。
実行する順でテストの一覧を示します。
ユニットテスト — 開発チームが個別の要素が正しく動作するかどうか(単独ではあるが)を確認するために行うテスト(通常)。
統合テスト — 組み合わせ時にモジュールをテストします。 このテストは、単体テストの後、システムテストの前におこないます。
煙テスト — これは、ソフトウェアが実行中で、高レベルの機能が使用可能であることを証明するために使用される、迅速で汚れたテストです。 詳細はテストされません。
機能テスト — ソフトウェアの機能をテストするために使用します。 一連のテストは、すべての詳細な機能を対象にし、予期される入力、予期しない入力および誤入力を考慮するように設計します。
ブラックボックステストは、対象の要素の内部動作に関する知識を持たずに実行される、完全なユニット/コンポーネント/モジュールの機能テストです。
システムテスト — システムを完全に統合し、適切なプラットフォームにインストールした後に、システム全体をテストします。
機能を黒いボックス単位でテストします。
パフォーマンステスト - AEMのテストでは、パフォーマンステストが重要です。
異なる条件でのパフォーマンスを示すために使用されます。
  • 標準
    サイトが90%の割合で経験する条件。 例えば、作成者の割合のみがシステムを使用している場合です。
  • ピーク時
    特殊な状況により、比例的に短い時間で経験される状況例えば、すべての作成者が同時にシステムを使用している場合や、新しいコンテンツが投稿され、サイトを閲覧する訪問者が増えた場合などです。
  • 極端な
    新しく関心度が極度に高いコンテンツを Web サイトに公開するときに、パフォーマンスを予測するために使用できます。過酷条件時のピークが発生する可能性がありますが、完全に予測することはできません。
    特定のイベントのチケットが公開されたり、待ち望んでいたウェブサイトが初めて公開された場合に、このような状況が表示されることがあります。
その結果を使用して、アプリを調整します。
応力テスト — 応力テストは、コンポーネントやアプリケーションが極端な条件下でどのように動作するかを確認するために行われます。 特に、これらのテストは、動作の劣化、要素の失敗時、およびその方法を示すために使用されます。
回帰テスト — 回帰テストは、ソフトウェアの前のリリースで既に実証済みの機能が引き続き正しく動作していることを確認するために使用されます。
回帰テストは、自動化を可能な限り迅速かつ一貫して繰り返せるようにするのに適しています。
受け入れテスト — 受け入れテストは、顧客がプロジェクトを受け入れたことを示すために使用される特別なカテゴリです。
受け入れテスト項目では、前述の多様なカテゴリのテストを組み合わせることもあります。また、プロジェクトが顧客の要件を満たしていることを確認するために選択します。
詳しくは、 受け入れとサインオフ を参照してください。

概要

詳細なテストケースとテスト計画に取り掛かる前に、次の作業をおこないます。
目標の定義 — 高レベルの目標を定義し、テストの進行に合わせて微調整を行うための出発点として機能します。 次の操作を行います。
などをおこないます。
既存のWebサイトからトラフィック統計を収集 — この情報はログファイルから抽出できます。詳しくは、パフォーマンスの監視を参照してください。
これらの数字は、既存のWebサイト上の現在のトラフィック(量と広がり)を示し、新しいWebサイトのベースポイントの形成に使用できます。
外部Webサイトからのトラフィック統計の収集 — 可能であれば、他のWebサイトから比較用にトラフィック統計を収集できますが、これらの数値は必ずしも公開されているとは限りません。
ターゲット指標の確認 — 指標は、達成すべきパフォーマンス目標を表すので、Webサイトの質の定量的測定値を定義するために使用されます。
顧客と共に、プロジェクトの開始時に定義する必要があります。 詳しくは、 目標の測定基準 を参照してください。