テスト結果の理解

メモ

Cloud Services パイプライン用 Cloud Manager でサポートするテスト結果およびテストについて詳しくは、こちらを参照してください。

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

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

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

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

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

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

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

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

コード品質テスト

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

コード品質テストの理解

コード品質テストでは、ソースコードが一定の品質基準を満たしていることを確認するためにスキャンされます。現在、これは、SonarQube、OakPAL を使用したコンテンツパッケージレベルの調査、および Dispatcher 最適化ツールを使用したディスパッチャー検証の組み合わせによって実装されます。汎用の 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 プログラムのパフォーマンステストを実行します。このパフォーマンステストは、実際のユーザーをシミュレーションする仮想ユーザー(コンテナ)を起動してステージング環境にアクセスし、トラフィックをシミュレーションすることで、最大 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 層ゲートシステムを使用したパフォーマンステストマトリックスの概要を次の表に示します。

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

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

メモ

各インスタンスは、テスト期間中、パブリッシュとオーサーの両方について監視されます。もし 1 つのインスタンスでも指標が取得されない場合、その指標は不明として報告され、対応する手順は失敗します。

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

この機能は Sites のオプションです。
認証済みサイトを持つ 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. オンボーディング要件

    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 ファイル。

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

このページ