テスト結果の理解

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

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

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

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

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

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

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

コード品質専用パイプラインでは、コード品質テストステップがパイプラインの最終ステップであるため、コード品質テストゲートでの重要なエラーは無効にはできません。

コード品質テスト

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

コード品質テストの理解

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

メモ

ここからルールの完全なリストをダウンロードできます。

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

名前 定義 カテゴリ 不合格のしきい値
セキュリティ評価 A = 脆弱性なし
B = 軽度の脆弱性が 1 つ以上
C = 重要な脆弱性が 1 つ以上
C = の重大な脆弱性が 1 つ以上
E = 致命的な脆弱性が 1 つ以上
重大 < B
信頼性評価 A = バグなし
B = 軽度のバグが 1 つ以上
C = 重要なバグが 1 つ以上
D = 重大なバグが 1 つ以上 E = 致命的なバグが 1 つ以上
重要 < C
保守性評価 コードスメルに対する未処理の修正コスト:
  • アプリケーションに既に投入された時間の 5%以下であれば、評価は A
  • 上記時間の 6~10%であれば、評価は B
  • 上記時間の 11~20%であれば、評価は C
  • 上記時間の 21~50%であれば、評価は D
  • 上記時間の 50%を超えれば、評価は E
重要 < A
カバレッジ ユニットテストのラインカバレッジと条件カバレッジを次の式で計算した結果:
Coverage = (CT + CF + LC)/(2*B + EL)
CT = ユニットテスト実行中に 1 回以上「真」と評価された条件の数
CF = ユニットテスト実行中に 1 回以上「偽」と評価された条件の数
LC = 実行された行の数 = lines_to_cover - uncovered_lines

B = 条件の合計数
EL = 実効行の合計数(lines_to_cover)
重要 < 50%
スキップした単体テスト スキップした単体テストの数。 情報 > 1
未解決の問題 問題の全体的なタイプ - 脆弱性、バグ、コードスメル 情報 > 0
重複行 重複しているブロックに含まれている行の数。
コードブロックが重複していると見なされるための条件:
  • Java 以外のプロジェクトの場合:
  • 100 個以上の連続した重複トークンが必要です。
  • これらのトークンは、少なくとも次の場所に分散している必要があります。
  • 30 行の COBOL コード
  • 20 行の ABAP コード
  • 10 行の他言語コード
  • Java プロジェクトの場合:
  • トークンと行の数にかかわらず、10 個以上の連続した重複ステートメントが必要です。

重複を検出する際は、インデントの違いと文字列リテラルの違いは無視されます。
情報 > 1%
Cloud Service の互換性 識別された Cloud Service の互換性に関する問題の数です。 情報 > 0
メモ

詳しくは、指標の定義を参照してください。

メモ

Cloud Manager で実行されるカスタムコード品質ルールについて詳しくは、カスタムコード品質ルールを参照してください。

偽陽性の処理

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

この場合、ルール 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";

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

メモ

@SuppressWarnings 注釈をできるだけ具体的にすることをお勧めします。つまり、問題の原因となっている特定のステートメントまたはブロックにのみ注釈を付けます。ただし、クラスレベルで注釈を付けることもできます。

セキュリティテスト

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

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

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

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

名前 ヘルスチェックの実装 カテゴリ
デシリアライゼーションファイアウォール添付 API レディネスが、受け入れ可能な状態である デシリアライゼーションファイアウォール添付 API レディネス 重大
デシリアライゼーションファイアウォールが機能している デシリアライゼーションファイアウォール機能 重大
デシリアライゼーションファイアウォールが読み込まれている デシリアライゼーションファイアウォール読み込み 重大
AuthorizableNodeName 実装において、認証可能な ID がノード名/パスで公開されていない 認証可能なノード名生成 重大
デフォルトのパスワードが変更されている デフォルトのログインアカウント 重大
Sling のデフォルトの GET サーブレットが DOS 攻撃から保護されている Sling Get Servlet 重大
Sling Java Script Handler が適切に設定されている Sling Java Script Handler 重大
Sling JSP Script Handler が適切に設定されている Sling JSP Script Handler 重大
SSL が正しく設定されている SSL 設定 重大
安全でないことが明確なユーザープロファイルポリシーが存在しない ユーザープロファイルへのデフォルトアクセス 重大
Sling Referrer Filter が CSRF 攻撃を防止するように設定されている Sling Referrer Filter 重要
Adobe Granite HTML Library Manager が適切に設定されている CQ HTML Library Manager 設定 重要
CRXDE サポートバンドルが無効である CRXDE サポート 重要
Sling DavEx のバンドルおよびサーブレットが無効である DavEx ヘルスチェック 重要
サンプルコンテンツがインストールされていない サンプルコンテンツパッケージ 重要
WCM Request Filter と WCM Debug Filter が両方とも無効になっている WCM フィルター設定 重要
Sling WebDAV のバンドルおよびサーブレットが適切に設定されている WebDAV ヘルスチェック 重要
Web サーバーが、クリックジャッキングを防止するように設定されている Web サーバー設定 重要
レプリケーションが「管理者」ユーザーを使用していない レプリケーションとトランスポートユーザー 情報

パフォーマンステスト

AEM Sites

Cloud Managerは、AEM Sitesプログラムのパフォーマンステストを実行します。 このパフォーマンステストは、実際のユーザーがStage環境上のページにアクセスした場合とトラフィックをシミュレートする場合をシミュレートする仮想コンテナ(ユーザー)を回転させて、~ 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のリストを生成します。 次に、Stage内にも存在するこれらの交差部分が、Stage環境上でクロールされます。

    • その他のライブページ:このオプションは、人気の高いライブページの上位25ページの外にあるページのうち、人気がない可能性があるが、テストに重要なページをテストするために選択します。人気のあるライブページと同様、ライブページはアクセスログから抽出され、ステージにも存在する必要があります。

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

      選択したページセット間のトラフィックの分布

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

      例えば、人気のあるライブページと新しいページセット(この例では、他のライブページは使用しません)の間に50 ~ 50%の分割があり、新しいページセットには3000ページが含まれているとします。 「1 分あたりのページビュー数」KPI は 200 に設定されます。30 分間のテストの結果は次のようになります。

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

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

テストとレポート

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

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

指標 カテゴリ 不合格のしきい値
ページリクエストエラー率 % 重大 >= 2%
CPU 使用率 重大 >= 80%
ディスク I/O 待機時間 重大 >= 50%
第 95 百分位応答時間 重要 >= プログラムレベルの KPI
ピーク応答時間 重要 >= 18 秒
1 分あたりのページビュー数 重要 < プログラムレベルの KPI
ディスク帯域幅使用量 重要 >= 90%
ネットワーク帯域幅使用量 重要 >= 90%
1 分あたりのリクエスト数 情報 >= 6000

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

メモ

各インスタンスは、テスト期間中、発行と作成者の両方で監視されます。 1つのインスタンスの指標が取得されない場合、その指標は不明としてレポートされ、対応する手順は失敗します。

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

この機能はサイトオプションです。
認証済みサイトを持つ AMS の顧客は、Cloud Manager が Web サイトのパフォーマンステスト中に Web サイトにアクセスするために使用するユーザー名とパスワードを指定できます。ユーザー名とパスワードは、CM_PERF_TEST_BASIC_USERNAMECM_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. オンボーディング要件

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

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

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

  3. 試験用資産の分配

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

  4. テストとレポート

    Cloud Managerは、前述の手順1(オンボーディングの要件)でCSEが設定したユーザー名とパスワードを使用して作成者インスタンスにフォルダーを作成し、オープンソースのライブラリを使用してフォルダー内のアセットをアップロードします。 アセットのテスト手順で実行されるテストは、このオープンソースライブラリを使用して書き込まれます。 各アセットの処理時間と、様々なシステムレベルの指標の両方が、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 ファイル。

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

このページ

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
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