テスト結果の理解

パイプライン実行中は、多数の指標が取得され、ビジネスオーナーによって定義された主要業績評価指標（KPI）または Adobe Managed Services で設定された標準と比較されます。

これらは、この節で定義する 3 層ゲートシステムを使用して報告されます。

パイプライン実行中の 3 層ゲート

パイプラインには次の 3 つのゲートがあります。

• コード品質
• パフォーマンステスト
• セキュリティテスト

これらの各ゲートで特定された問題には、3 段階の構造があります。

• 重大 - ゲートで特定される問題のうち、パイプラインの即時失敗につながるもの。
• 重要 - ゲートで特定される問題のうち、パイプラインの一時停止につながるもの。デプロイメントマネージャー、プロジェクトマネージャーまたはビジネスオーナーは、問題をオーバーライドできます。この場合、パイプラインは続行されます。または、問題を承認できます。この場合、パイプラインはエラーで停止します。重要なエラーのオーバーライドは、タイムアウトの影響を受けます。
• 情報 - ゲートで特定される問題のうち、情報提供だけを目的とするもの。パイプラインの実行には影響しません。

コード品質テスト

この手順では、アプリケーションコードの品質を評価します。これはコード品質のみのパイプラインの主な目的であり、非実稼動および実稼動のすべてのパイプラインで、ビルド手順の直後に実行されます。様々なタイプのパイプラインの詳細については、CI/CD パイプラインの設定を参照してください。

コード品質テストの理解

コード品質テストでは、ソースコードが一定の品質基準を満たしていることを確認するためにスキャンされます。現在、これは、SonarQube、OakPAL を使用したコンテンツパッケージレベルの調査、および Dispatcher 最適化ツールを使用したディスパッチャー検証の組み合わせによって実装されます。汎用の Java ルールと AEM 固有のルールを組み合わせた 100 以上のルールがあります。AEM 固有のルールの一部は、AEM エンジニアリングのベストプラクティスに基づいて作成され、カスタムコード品質ルールと呼ばれます。

この手順の結果は、評価​として提供されます。次の表に、様々なテスト条件の評価の概要を示します。

偽陽性の処理

品質スキャンプロセスは完璧ではなく、実際には問題がないにもかかわらず問題として誤って特定することもあります。これは「偽陽性」と呼ばれます。

この場合、ルール ID を注釈属性として指定した標準の Java @SuppressWarnings 注釈を使用して、ソースコードに注釈を付けることができます。例えば、よくある問題の 1 つとして、ハードコードされたパスワードを検出する SonarQube ルールにおいて、ハードコードされたパスワードの識別方法が強引な場合があります。

具体的な例を見てみましょう、次のコードは、一部の外部サービスに接続するコードを含んだ AEM プロジェクトではかなり一般的なものです。

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

この場合、SonarQube は致命的脆弱性を報告します。コードを見直した後、これが脆弱性でないことを確認し、適切なルール ID でこれに注釈を付けることができます。

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

一方、コードが実際には次のようになっていた場合は、

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

ハードコードされたパスワードを削除するのが正しい解決策です。

セキュリティテスト

Cloud Manager では、デプロイメント後に既存の AEM セキュリティヘルスチェック​を実行し、UI を通じてそのステータスを報告します。結果は、環境内のすべての AEM インスタンスから集計されます。

同じヘルスチェックは、Web コンソールまたはオペレーションダッシュボードを使用して、いつでも実行できます。

いずれかの​インスタンス​が特定のヘルスチェックに対して不合格を報告した場合、環境​全体がそのヘルスチェックに対して不合格となります。コード品質テストやパフォーマンステストと同様に、これらのヘルスチェックもいくつかのカテゴリにまとめられ、3 層ゲートシステムを使用して報告されます。セキュリティテストの場合にはしきい値がない点だけが異なります。すべてのヘルスチェックでは、単純に合格または不合格のみの結果になります。

現在のチェックは次の表のとおりです。

パフォーマンステスト

AEM Sites

Cloud Manager は、AEM Sites プログラムのパフォーマンステストを実行します。このパフォーマンステストは、実際のユーザーをシミュレーションする仮想ユーザー（コンテナ）を起動してステージング環境にアクセスし、トラフィックをシミュレーションすることで、最大 30 分間実行されます。これらのページは、クローラーを使用して検出されます。

1. 仮想ユーザー

   Cloud Manager で実行される仮想ユーザーまたはコンテナの数は、プログラムの作成または編集中に、ビジネスオーナーの役割でユーザーが定義した KPI（応答時間とページビュー数/分）によって決まります。定義済みの KPI に基づき、実際のユーザーをシミュレートする最大 10 個のコンテナが実行されます。テスト用に選択したページは分割され、各仮想ユーザーまたはコンテナに割り当てられます。

2. クローラ

   30 分のテスト期間が開始される前に、Cloud Manager は、カスタマーサクセスエンジニアが設定した 1 つ以上のシード URL セットを使用してステージング環境をクロールします。これらの URL から、各ページの HTML を調べ、幅優先方式でリンクが探索されます。このクロール処理は、最大 5000 ページに制限されています。クローラーからのリクエストのタイムアウトは 10 秒に固定されています。

3. テスト用ページセット

   ページは 3 つのページセットで選択されます。Cloud Manager は、実稼動環境とステージング環境全体で AEM インスタンスのアクセスログを使用して、次の 3 つのバケットを決定します。

   • 最頻訪問ライブページ：このオプションは、実際の顧客が最も頻繁にアクセスした訪問ページをテストするときに選択します。Cloud Manager はアクセスログを読み取り、ライブユーザーによるアクセスが最も多かったページの上位 25 個を特定し、上位 Popular Live Pages のリストを生成します。これらの積集合はステージング環境内にも存在するため、そこでもクロールされます。

   • その他のライブページ：このオプションは、最頻訪問ライブページの上位 25 ページに含まれないページのうち、頻度は低くても、テストに重要なページをテストするために選択します。最頻訪問ライブページと同様、ライブページはアクセスログから抽出され、ステージング環境にも存在する必要があります。

   • 新規ページ：このオプションは、ステージング環境にのみデプロイ済みで、まだ実稼動環境にはデプロイされていないが、テストが必要な新しいページをテストする場合に選択します。

     選択したページセットをまたいだトラフィックの配分

     パイプライン設定（挿入リンク）の「テスト」タブで、1 セットから全 3 セットまでのいずれかを選択できます。トラフィックの配分は、選択したセットの数によって決まります。つまり、全 3 セットが選択されている場合、合計ページビューの 33%が各セットに送られます。2 つのセットが選択されている場合は、各セットに 50%ずつ送られます。1 つのセットが選択された場合は、トラフィックの 100%がそのセットに送られます。

     例えば、「最頻訪問ライブページ」と「新規ページ」セットで 50%ずつ配分し（この例では、「その他のライブページ」は使用されていません）、「新規ページ」セットには 3,000 ページが含まれるとします。「1 分あたりのページビュー数」KPI は 200 に設定されます。30 分間のテストの結果は次のようになります。

     • 「頻度の高いライブページ」セットの 25 ページが各 120 回ヒットします - ((200 * 0.5) / 25) * 30 = 120

     • 「新規ページ」セットの 3000 ページが各 1 回ヒットします - ((200 * 0.5) / 3000) * 30 = 1

テストとレポート

Cloud Manager は、ステージ公開サーバー上で 30 分間のテスト期間（デフォルトでは未認証ユーザー）にページをリクエストし、各ページに対して（仮想）ユーザー生成指標（応答時間、エラー率、1 分あたりの表示数など）と、すべてのインスタンスに対して様々なシステムレベルの指標（CPU、メモリ、ネットワークデータ）を測定することで、AEM Sites プログラムのパフォーマンステストを実行します。
3 層ゲートシステムを使用したパフォーマンステスト指標の概要を次の表に示します。

3 層ゲートシステムを使用したパフォーマンステストマトリックスの概要を次の表に示します。

Sites と Assets のパフォーマンステストで基本的な認証を使用する方法の詳細については、次の​認証済みパフォーマンステスト​の節を参照してください。

認証済みパフォーマンステスト

この機能は Sites のオプションです。
認証済みサイトを持つ AMS の顧客は、Cloud Manager が Web サイトのパフォーマンステスト中に Web サイトにアクセスするために使用するユーザー名とパスワードを指定できます。
ユーザー名とパスワードは、CM_PERF_TEST_BASIC_USERNAME と CM_PERF_TEST_BASIC_PASSWORD という名前で、パイプライン変数に指定します。
厳密に必須ではありませんが、ユーザー名には string 型変数を、パスワードには secretString 型変数を使用することをお勧めします。これらの両方を指定した場合、パフォーマンステストクローラーとテスト仮想ユーザーからのリクエストすべてに、HTTP 基本認証としての資格情報が含まれます。

Cloud Manager CLI を使用してこれらの変数を設定するには、次のコマンドを実行します。

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

API の使用方法については、変数を参照してください。

AEM Assets

Cloud Manager では、30 分間のテスト期間にわたってアセットを繰り返しアップロードすることで、AEM Assets プログラムのパフォーマンステストを実行します。

1. オンボーディング要件

   Assets のパフォーマンステストの場合、お客様のサクセスエンジニアは、オーサーからステージング環境へのオンボーディング中に、cloudmanager ユーザー（およびパスワード）を作成します。パフォーマンステストの手順では、cloudmanager というユーザーと、CSE によって設定される関連付けられたパスワードが必要です。オーサーから削除したり、wrt 権限を変更したりしないでください。Assets のパフォーマンステストが失敗する可能性があります。

2. テスト用の画像とアセット

   顧客は、独自のアセットをアップロードしてテストできます。この操作は、パイプライン設定または編集画面でおこなうことができます。JPEG、PNG、GIF、BMP などの一般的な画像形式のほか、Photoshop ファイル、Illustrator ファイル、Postscript ファイルがサポートされています。ただし、画像がアップロードされない場合、Cloud Manager では、デフォルトの画像と PDF ドキュメントがテストに使用されます。

3. テスト用アセットの配分

   1 分ごとにアップロードされる各タイプのアセット数の配分は、パイプライン設定または編集画面で設定します。
   例えば、次の図のように 70% と 30% に配分した場合は、1 分あたり 10 個のアセットがアップロードされ、うち 7 個が画像、3 個がドキュメントになります。

4. テストとレポート

   Cloud Manager は、前述の手順 1（オンボーディング要件）で CSE が設定したユーザー名とパスワードを使用してオーサーインスタンスにフォルダーを作成し、オープンソースのライブラリを使用してフォルダー内のアセットをアップロードします。Assets のテスト手順で実行されるテストは、このオープンソースライブラリを使用して記述されます。30 分のテスト期間にわたって、各アセットの処理時間と、様々なシステムレベルの指標の両方が測定されます。この機能では、画像と PDF ドキュメントの両方をアップロードできます。

   メモ

   パフォーマンステストについて詳しくは、CI／CD パイプラインの設定を参照してください。プログラムの設定方法と KPI の定義方法については、プログラムの設定を参照してください。

パフォーマンステスト結果のグラフ

パフォーマンステスト結果ダイアログに、新しいグラフおよびダウンロードオプションが追加されました。

パフォーマンステストダイアログを開いた場合、指標パネルを展開して、グラフやダウンロードへのリンクを表示することができます。

Cloud Manager リリース 2018.7.0 の場合、この機能は次の指標で利用できます。

• CPU 使用率

  • テスト期間中の CPU 使用率のグラフ。

• ディスク I/O 待機時間

  • テスト期間中のディスク I/O 待機時間のグラフ。

• ページエラー率

  • テスト期間中の 1 分あたりのページエラー数のグラフ。
  • テスト中にエラーが発生したページの一覧を示す CSV ファイル。

• ディスク帯域幅使用量

  • テスト期間中のディスク帯域幅使用量のグラフ。

• ネットワーク帯域幅使用量

  • テスト期間中のネットワーク帯域幅使用量のグラフ。

• ピーク応答時間

  • テスト期間中の 1 分あたりのピーク応答時間のグラフ。

• 第 95 百分位応答時間

  • テスト期間中の 1 分あたりの第 95 百分位応答時間のグラフ。
  • 第 95 百分位応答時間が定義済みの KPI を超えたページの一覧を示す CSV ファイル。

パフォーマンステストグラフの表示例を次の図に示します。