DevOps テストツールの統合

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:10分
  • テストツールの統合により、JenkinsAzure DevOps、GitHub、GitHub Enterprise、および GitLab 単体テスト、機能テスト、およびパフォーマンステストのテスト結果を DevOps で表示できます。

    GitLab と Jenkins では、JUnit テストタイプの統合のみがサポートされています。

    注:
    その他のテストタイプの場合は、DevOps APIDevOps - POST /devops/tool/{capability} エンドポイントを使用します。
    • TestNG を使用して実行および公開された Selenium テストは、ServiceNow DevOps 用の Jenkins プラグインによって報告されます。
    • テストタイプの分類がサポートされています。
    • Apache JMeter などのツールによって報告された追加のテスト結果は、カスタムワークフロースタジオサブフローを使用して DevOps で処理できます (パイプラインの変更は必要ありません)。
    カテゴリ テストタイプ
    単位

    JUnit (デフォルト)

    NUnit

    XUnit

    単体テスト

    注:
    • GitLab および Jenkins では、JUnit テストタイプの統合のみがサポートされています。
    • ADO、GitHub、および GitHub Enterprise では、JUnit、NUnit、XUnit、および単体テストタイプの統合がサポートされています。

    デフォルトのテストタイプを変更するには、 [sn_devops.default_test_type] DevOps プロパティ.

    機能的
    • データ連携
    • 回帰
    • スモーク
    • システム
    • ユーザー受理
    パフォーマンス 負荷

    テストタイプマッピング

    テストタイプマッピングは、テスト対象のテストタイプとエンティティを DevOps ツール (DevOps > 統合 > テストタイプマッピング モジュール)。

    テストタイプマッピング

    正確なテストタイプマッピングにより、テストタイプがテストサマリー結果に常に意図したとおりに表示されます。

    フィールド 説明
    テストタイプ
    • JUnit
    • Nunit
    • Xunit
    • 単体テスト
      注:
      • GitLab および Jenkins では、JUnit テストタイプの統合のみがサポートされています。
      • ADO、GitHub、および GitHub Enterprise では、JUnit、NUnit、XUnit、および単体テストタイプの統合がサポートされています。
    • データ連携
    • 回帰
    • スモーク
    • システム
    • ユーザー受理
    • 負荷
    DevOps エンティティ ID テーブル名

    (テストレポートペイロード内の) テスト結果にリンクされたエンティティを含む DevOps テーブル名。

    • ステップ [sn_devops_step]
    • パイプライン [sn-devops-pipeline]
    注:
    DevOps のステップテーブルとパイプラインテーブルのみがサポートされています。
    ドキュメント

    選択したテーブルで指定されたエンティティの名前。

    たとえば、ステップ、パイプライン、アーティファクト、パッケージの名前などです。

    テストファイルパス

    (Jenkins テストのみ)

    Jenkins サーバー上で生成されたテスト結果ファイルへのパス。

    これは、JUnit や TestNG の実装に準拠しない属性 (たとえば JMeter など) を持つテストレポートを DevOps で活用できるようにするために便利です。

    複数のファイルはカンマで区切ります。

    注:
    生のテストペイロードを変換するには、ワークフロースタジオサブフローを使用する必要があります。
    ツール統合

    テストを実行しているツール。

    DevOps テーブル

    [DevOps エンティティ ID] 設定のテーブル名に対応する DevOps テーブル。

    図 : 1. DevOps テストタイプマッピング
    DevOps テストタイプマッピング
    図 : 2. ADO 単体テストの yaml ファイルの例
    ADO 単体テストの yaml ファイルの例
    図 : 3. GitHub 単体テストの yaml ファイルの例
    GitHub 単体テストの yaml ファイルの例

    生のテストペイロードの変換

    たとえば、カスタムサブフローを呼び出すように DevOps テストサブフロー ポリシーディシジョンテーブルを構成することで、JMeter などの生のテストレポート (JUnit または TestNG 実装に準拠しない属性を含むレポート) を変換できますディシジョンテーブル > ディシジョンテーブル モジュール)。
    注:
    生のテストペイロードを変換するカスタムワークフロースタジオサブフローを作成する必要があります。

    パフォーマンスステージに複数のテストタイプがある場合は、[DevOps テストタイプポリシー (DevOps Test Type Policy)] ディシジョンテーブルを使用して各テストのテストタイプを構成し、テスト結果のペイロードが正しく変換されるようにすることができます。

    図 : 4. DevOps ディシジョンテーブル
    DevOps ディシジョンテーブル
    表 : 1. DevOps ディシジョンテーブル
    ディシジョンテーブル 目的 設定
    DevOps テストサブフローポリシー (DevOps Test Subflow Policy)

    ツールが受信した生のペイロードを変換するカスタムサブフローを自動的に呼び出すこと。

    意思決定の入力:

    • テスト結果ペイロード
    • テストタイプ

    生のペイロードを受信したときに呼び出すカスタムサブフローを指定する意思決定を作成します。

    生のペイロードに含まれるフィールドを含む条件を設定します。

    たとえば、Jenkins BZ パフォーマンステスト (BZ Performance Test) カスタムサブフローを呼び出すには、次のようにします。

    条件:
    • テストタイプは [ロード] です

      (負荷は、パフォーマンステスト用に構成されたテストタイプです)

    • テスト結果ペイロードにスループットが含まれています
    • テスト結果ペイロードに同時実行が含まれている

    解答:フロー: Jenkins BZパフォーマンステスト

    DevOps テストタイプポリシー (DevOps Test Type Policy)

    パフォーマンステストステージに複数のタイプのテストが構成されている場合に、テストタイプを自動的に設定すること

    これは、2 番目のテストタイプの結果を正しく変換するために必要です。

    たとえば、ロードパフォーマンステストと JUnit パフォーマンステストの両方が同じ DevOps ステップでマップされている場合、決定が作成されない限り、JUnit テスト結果は正しくフォーマットされません。

    意思決定の入力:
    • ステップ
    • テスト結果ペイロード
    • ツール統合
    • パイプライン

    テストタイプを設定するために、パフォーマンステストステージの各タイプのテストに対する意思決定を作成します。

    負荷テスト:
    • 条件:
      • ステップはパフォーマンステストです
      • テスト結果ペイロードにスループットが含まれています
      • テスト結果ペイロードに同時実行が含まれている
    • 解答: TestType: ロード

    JUnit テスト:

    • 条件:
      • ステップはパフォーマンステストです
      • テスト結果ペイロードにスループットが含まれていません
      • テスト結果ペイロードに並行処理性が含まれていません
    • 解答: TestType: JUnit

    図 : 5. DevOps 複数のパフォーマンステストタイプ
    DevOps 複数のパフォーマンステストタイプ
    図 : 6. DevOps 複数のテストタイプマッピング
    DevOps テストタイプマッピング
    図 : 7. DevOps ディシジョンテーブルの決定
    DevOps ディシジョンテーブルの決定

    テストサマリー結果

    テストサマリーの結果は、次の方法で表示できます。
    図 : 8. DevOps パフォーマンステストサマリーの例
    DevOps パフォーマンステストサマリー

    予想標準 JSON 通知機能ペイロード - テストツール

    機能的:
    { 
    "name": "CorpSite-selenium#55", 
    "duration": 78.802, 
    "passedTests": 4, 
    "failedTests": 0, 
    "skippedTests": 0, 
    "blockedTests": 0, 
    "totalTests": 4, 
    "startTime": "2020-06-30T18:12:31Z", 
    "finishTime": "2020-06-30T18:12:31Z", 
    "passingPercent": 100, 
     
     
    // Use Artifact OR Package OR Build + Stage + PipelineName Attributes 
    
    Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.
    
    If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
    
    1.packages
    2.artifcats
    3.buildNumber + stageName + pipelineName
    
    "packages": [{"name": "CorpSite-pkg1"}], 
    "artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
    "buildNumber": "55", 
    "stageName": "test", 
    "pipelineName": "CorpSite-selenium", 
    } 
    
    Notes:
    - The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
    - The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.
    パフォーマンス:
    { 
    "name": "Performance Tests", 
    "url": "http://abc.com", 
    "startTime": "2020-06-30T18:12:31Z", 
    "finishTime": "2020-06-30T18:12:31Z", 
    "duration": 78.802, 
    "maximumVirtualUsers": "", 
    "throughput": "", 
    "maximumTime": "", 
    "minimumTime": "", 
    "averageTime": "", 
    "ninetyPercent": "", 
    "standardDeviation": "", 
     
    // Use Artifact OR Package OR Build + Stage + PipelineName Attributes 
    
    Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.
    
    If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
    
    1.packages
    2.artifcats
    3.buildNumber + stageName + pipelineName
    
    "packages": [{"name": "CorpSite-pkg1"}], 
    "artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
    "buildNumber": "55", 
    "stageName": "test", 
    "pipelineName": "CorpSite-Performance", 
    } 
    
    Notes:
    - The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
    - The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.