現在表示中:

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

始める前に

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

AEM アーキテクチャ

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

ドキュメント

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

テストの基本原則

ソフトウェアテストと品質保証の基本概念を知る必要があります。できれば、テストプロジェクトを経験しておきます。

このような原則を扱う Web サイト、書籍、講座は多数あるので、このドキュメントでは詳細について説明しません。

仮定の排除

(一般的に考えられる)最大の前提事項は、Web サイトは数百万単位の要求に毎日対応する必要があるということです。この前提は状況によっては該当する場合もありますが、異なる場合もあります。

100 %の精度で将来的な数を予測することはできませんが、既存のサイトとトラフィックの実績を観察すると適切な指針として利用できます。次に、トラフィック増加の予測値または期待値に基づいて、見積もることができます。

品質への責任

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

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

積極的な参加

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

顧客の協力

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

テストの種類

AEM プロジェクトをテストするときには、様々な種類のテストを使用できます。使用するテストを決定するには、テストをよく理解する必要があります。

注意:

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

単体テスト

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

統合テスト

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

スモークテスト

ソフトウェアを実行できること、および高レベルの機能を使用できることを証明するために使用する簡易テストです。詳細についてはテストしません。

機能テスト

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

ブラックボックステストは、完全なユニット、コンポーネント、モジュールの機能テストです。対象とする各要素の内部的な動作の情報がない状態で実行します。

システムテスト

システム全体を統合し、適切なプラットフォームにインストールしたときに、システム全体をテストするのがシステムテストです。

ブラックボックスの原則で機能をテストします。

パフォーマンステスト

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

様々な条件下でのパフォーマンスを明らかにするために使用します。

  • 通常時

    約 90 %の時間、サイトはこの状態です。例えば、ごく一部の作成者しかシステムを使用していない時間などです。

  • ピーク時

    特殊な状況で比例的に短い時間、この状態になります。例えば、すべての作成者が同時にシステムを使用するときや、新しいコンテンツが公開され、通常よりも多数の訪問者がサイトを閲覧するときなどです。

  • 過酷条件時

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

    このような状態は、特定のイベントのチケット販売が開始されたときや、関心度が高い Web サイトが初めて公開されたときなどに見られます。

テスト結果は、アプリケーションの調整に使用されます。

ストレステスト

ストレステストは、極端な条件下でコンポーネントまたはアプリケーションがどのように動作するかを確認するためにおこないます。特に、各要素で障害が発生したときおよびその状況で、機能がどのように低下するかを示すために使用されるテストです。

回帰テスト

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

回帰テストは、すぐに一貫した方法で繰り返すことができるようにするために、(可能であれば)自動化することをお勧めします。

受け入れテスト

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

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

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

はじめに

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

目的の定義

起点の役割として高レベルの目標を定義します。目標はテストの進行に従って微調整します。例えば、

  • 詳細な要件仕様に従う機能テスト

  • 目標の測定基準」に従うパフォーマンステスト

などをおこないます。

既存 Web サイトからのトラフィック統計情報の収集

この情報はログファイルから抽出できます。詳しくは、パフォーマンスの監視を参照してください。

統計情報は既存の Web サイトでの現在のトラフィック(量と範囲)を示し、新しい Web サイトの基準点を構成するときに利用できます。

外部 Web サイトからのトラフィック統計情報の収集

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

目標指標の確認

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

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

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー