DTP を使用すると、コードベースの拡張につれてその変化を比較することができます。ソフトウェアを継続的にビルドしている場合、比較にビルドを使用すると、従来の日付ベースでのデータ比較では得られなかった手掛かりを得ることができます。[ビルド管理] ページは、ビルド アクティビティと DTP に格納された情報を可視化します。
このセクションの内容:
[ビルド管理] ページを開くには、[ビルド管理 - 統計] ウィジェットをクリックします。
フィルター ID が分かる場合、レポート URL を手動で入力できます。
http://<HOST>:<PORT>/grs/dtp/reports/builds?filterId=<ID>
ビルドに説明タグを追加して、[ビルド管理] ページからの特定を簡単にすることができます。この方法で追加したタグは、[ビルド管理] ページおよび [ビルド監査] レポートで、ビルド ID の下に表示されます。説明タグを追加するには、ビルド ID の横にある鉛筆のアイコンをクリックし、表示されるダイアログに説明テキストを入力します。説明は 128 文字以内にする必要があります。
ビルドをロックすると、同じビルド ID でタグ付けされた新規レポートを DTP が受け取るのを防止できます。ロックされたビルドは、一般的に開発フェーズの最後を示します。ビルドをアーカイブして、ビルド ID に関連する XML レポート ファイルを保存できます。これにはテストとカバレッジの詳細も含まれます。DTP は、デフォルトでは最後の 2 つのビルドのテスト データとカバレッジ データだけを保持します。しかし、特定のビルドに関連する全データをアーカイブすれば、既存のテスト データとカバレッジ データが消失するのを防止できます。
XML、HTML、PDF 形式のレポートをダウンロードするには、ビルドをアーカイブする必要があります。詳細については「ビルド監査レポート」を参照してください。 |
<DTP_DATA_DIR>/data/_DEFAULT_/dc/baselined/<BUILD_PRIMARY_ID>/<RUN_ID> ディレクトリに保管されます。<BUILD_PRIMARY_ID> は、データベース中のビルドの ID (プライマリ キー) です。<RUN_ID> はデータベース中の実行の ID (プライマリ キー) です。
一部の実行に関連するデータが信頼できない場合、その実行に関連するビルドを探し、REST API を使ってデータベースからデータを削除することができます。たとえば、ソース管理システムがオフラインになった場合、作成者とブランチ情報やその他の情報の整合性が失われ、DTP のレポート メカニズムの有効性に影響することがあります。テスト対象システムで重大な問題が発生した場合、故障中に実行した実行に関連するテスト結果は、実際の不具合 (リグレッション) ではなく「ノイズ」を表している可能性があります。
データベースから削除したデータは、ビルド レベルであるため、たとえ関連データが複数の実行にわたっている場合でも、そのビルドに関連する全データが削除されます。デフォルトでは、Parasoft 静的解析/テスト ツールは日ごとに一意なビルドを生成します。そのため、あるビルドに関連するデータを削除すると、その日の全データが削除されてしまう可能性が多いにあります。
REST API を使ってビルドを削除することができます。ビルドを削除する API 呼び出しは次のとおりです。
DELETE https://<HOST>:<PORT>/grs/api/v1.12/builds/<NAME_OF_BUILD> |
ビルド名にスペースなどの特殊文字が含まれている場合、URL パスで使用するにはそれらの文字をエスケープする必要があります。
[ビルド管理] ページでビルドをクリックすると、そのビルド ID に対するコンプライアンス レポートが表示されます。コンプライアンス レポートには、ベース ライン ビルドに関連するすべての成果物が表示されます。たとえば、環境属性、使用したテスト コンフィギュレーション、テスト結果などです。このレポートによって、ユーザーはビルドがどの程度テストされているかを把握できます。詳細については「ビルド監査レポート」を参照してください。