Jtest で解析した結果をDTP Standard のプロジェクトにアップロード（パブリッシュ）することで、DTP Standard 上で結果を確認することができます。
本項目では、パブリッシュした結果の収集に関連する概念について説明します。
実行（ラン）
DTP Engine (C++test/Jtest/dotTEST) の1 回の「実行」を表します。
ラン コンフィギュレーション
一連の「実行」を表します。以下の属性によって定義されます。以下属性の全てが同じ「実行」は、1 つのラン コンフィギュレーションにグループ化されます。
使用例は セッションタグとラン コンフィギュレーション に記述します。
使用しているEngine(C++test/Jtest/dotTEST)
結果をパブリッシュしたDTP プロジェクト
使用したテストコンフィギュレーション
セッションタグ
セッションタグ
類似する「実行」を区別するために使用します。
使用例は セッションタグとラン コンフィギュレーション に記述します。
セッションタグを設定する手順は、Jtest（CUI）側のDTP Standard 連携向け設定ファイルの用意を参照ください。
セッションタグとラン コンフィギュレーション
ラン コンフィギュレーションを定義する属性の1～3が同一であっても、セッションタグが異なる場合、異なる「実行」と見なされ、異なるラン コンフィギュレーションにグループ化されます。
類似の「実行」を区別するために適切な設定が必要です。以下に事例を示します。
[前提条件]
A) "Code Parser" という製品は "core" と "API" という2 つのモジュールから構成されている。
B) "core" に対して ”Flow Analysis” を使用した静的解析を行う。 "API" に対して ”Flow Analysis”、”MISRAC 2012”を使用した静的解析を行う。解析結果はDTP Standard の ”Code Parser” プロジェクトにパブリッシュする。
C) 構成管理ツールを使用しており、"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 つのラン コンィギュレーション）など表示する結果を絞り込むことができます。
フィルタ機能の設定については 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 のフィルタ作成 を参照ください。