C++test で解析した結果を DTP Standard のプロジェクトにアップロード（パブリッシュ）することで、DTP Standard 上で結果を確認することができます。本項目では、パブリッシュした結果の収集に関連する概念について説明します。

実行（ラン）

DTP Engine (C++test/Jtest/dotTEST) の 1 回の「実行」を表します。

ラン コンフィギュレーション

一連の「実行」を表します。以下の属性によって定義されます。以下属性の全てが同じ「実行」は、1 つのラン コンフィギュレーションにグループ化されます。使用例は「セッションタグとラン コンフィギュレーション」に記述します。

1. 使用している Engine(C++test/Jtest/dotTEST)

2. 結果をパブリッシュした DTP プロジェクト

3. 使用したテストコンフィギュレーション

4. セッションタグ

セッションタグ

類似する「実行」を区別するために使用します。
使用例は「セッションタグとラン コンフィギュレーション」に記述します。
セッションタグを設定する手順は、「C++test（CUI）側の DTP Standard 連携向け設定ファイルの用意」を参照ください。

セッションタグとラン コンフィギュレーション

ラン コンフィギュレーションを定義する属性の(1)～(3)が同一であっても、セッションタグが異なる場合、異なる「実行」と見なされ、異なるラン コンフィギュレーションにグループ化されます。類似の「実行」を区別するために適切な設定が必要です。以下に事例を示します。
[前提条件]

1. "Code Parser" という製品は "core" と "API" という 2 つのモジュールから構成されている。

2. "core" に対して "Flow Analysis" を使用した静的解析を行う。 "API" に対して "Flow Analysis"、"MISRA C 2012"を使用した静的解析を行う。解析結果は DTP Standard の "Code Parser" プロジェクトにパブリッシュする。

3. 構成管理ツールを使用しており、"Code Parser" はブランチ X、ブランチ Y が存在する。

"core" と "API" に対する 2 つの解析が同じセッションタグである場合、DTP は 2 つの「実行」を区別せず、同じランコンフィギュレーションと解釈します。この場合、2 回目の解析は、1 回目の「実行」の新しいものと見なされます。このようなセッションタグ
の設定は避けるべきです。この問題はモジュール名にセッションタグを含め、セッションタグを区別することで解決できます。
しかし、モジュール名を含めただけでは、ブランチX の"core"、 ブランチY の"core" が同じセッションタグになるため、これら 2 つの「実行」は区別されません。上記の前提条件において、類似の「実行」を区別するためには、モジュール、ブランチ毎に異なる セッションタグにする必要があります。

以下の設定をすることで、モジュール、ブランチ毎のセッションタグが一意になります。
session.tag=${project_module}_${scontrol_branch}
※本設定は前述の前提条件における適切な設定の一例です。条件によって、適切な設定は異なります。

前提条件(B)の解析を実行した場合、以下のように6 つのラン コンフィギュレーションが生成され、それぞれの解析結果がDTP
の "Code Parser" プロジェクトに格納されます。

デフォルトではプロジェクト単位で解析結果が表示されるため、6 つのラン コンフィギュレーションの解析結果が全て表示されます。DTP のフィルタ機能を使用することで、ブランチ X の解析結果のみ（3 つのラン コンフィギュレーション）、モジュール"API" の解析結果のみ（4 つのランコンフィギュレーション）、ブランチ Y のモジュール"Core"の解析結果のみ（1 つのラン コンフィギュレーション）など表示する結果を絞り込むことができます。
フィルタ機能の設定については 3.3 Parasoft DTP のフィルタ作成 を参照ください。

セッションタグをブランチ名のみにした場合、"Core" に対する解析か "API" に対する解析かの判断ができないため、以下のように "Core" に対するFlow Analysis の解析結果は "API" に対する Flow Analysis の解析結果で上書きされます。

セッションタグをモジュール名のみにした場合、ブランチ X に対する解析か ブランチY に対する解析かの判断ができないため、以下のように ブランチX の解析後、ブランチY を解析すると、ブランチX の解析結果はブランチY の解析結果で上書きされます。

ビルド ID

複数のラン コンフィギュレーションにまたがって「実行」をグループ化するために使用します。セッションタグとラン コンフィギュレーションの前提条件において、セッションタグを"session.tag=${project_module}_${scontrol_branch}" とした場合の 6 つのラン コンフィギュレーションを 1 つのビルド ID にグループ化し、あるビルドにおける"Code Parser"アプリケーションのテスト結果を集約します。

ビルド ID が同じレポートは、アプリケーションの同一ビルドに対するテスト結果を表すことが前提です。たとえば、SCM のバージョンが変わった場合、同一のビルドではありません。


ビルド ID を日付にした場合、上記のように 1 日に SCM のバージョンが数回変わるケースに対応できません。その日の最後のビルドにおける解析結果のみが残り、その前のビルドにおける解析結果は上書きされます。このようなケースでは、SCM の バージョンによって、ビルド ID が変更されるようにするべきです。

1 日に 1 回だけ解析を行なう運用であれば、ビルド ID が日付でも問題ありません。運用に応じて、適切なビルド ID を設定します。

カバレッジタグ

カバレッジタグは、ビルド ID が同じである実行単位のカバレッジデータを集計するために使用される識別子です。このタグは単体テストおよびアプリケーションカバレッジで使用します。このタグを用いることで単体テスト、機能テストなど粒度の異なるテストのカバレッジを区別することができます。デフォルトでは report.coverage.images=${dtp_project}が指定され、すべてのカバレッジ情報が統合された状態で表示されます。
単体テスト結果を区別して管理する場合、テストの実行時に以下のようにカバレッジタグを設定します。
report.coverage.images=${dtp_project};UnitTest
あらかじめカバレッジタグを適切に設定しておき、DTP のフィルタ機能を用いることで、カバレッジタグごとに収集結果をフィルタリングすることができます。フィルタ機能の設定については「Parasoft DTP のフィルタ作成」を参照ください。