このセクションの内容

静的解析

C/C++test は、指定された静的解析ルールにコードが準拠しているかどうかをチェックして静的解析を実行します。静的解析の目的は、次の処理を行ってエラーを防止し、コードの品質を向上させることです。

ソースコード内の明確な欠陥および欠陥の可能性を検出する。
セキュリティを危うくするコードの使用を防止する。
組織の設計ガイドラインと仕様 (アプリケーション固有、ユーザー固有、プラットフォーム固有の仕様) への準拠、および既知の特定のバグから抽出されたガイドラインへの準拠を推進する。
クラスの設計とコードの構成を向上させることによってコードの保守性を向上させる。
一般的な書式、名前付け、その他の記述方法と形式についてのコーディング規約を適用してコードの可読性を高める。

C/C++test は、付属のビルトインルールを使って静的解析を実行するよう、あらかじめ構成されています。静的解析をチェックするテストコンフィギュレーションでデフォルトで有効に設定されているルールは、コードの品質を直ちに改善することが確認されています。この基本ガイドラインに従うコードはより高速かつ安全になって保守が容易になると共に、機能に関連する問題が起こる可能性が低くなります。

C/C++test では、ビルトインルールを使用するだけでなく、ユーザー独自のルールを定義して組織固有のコーディングポリシーを実装することができます。どのルールに準拠するかをチームが判断しやすいよう、ルールは「セキュリティ」、「最適化」、「国際化」などのカテゴリに分類され、重要度も設定されています。重要度は、検出された問題がバグにつながる可能性を表します。

C/C++test に付属の静的解析ルールについては、[Parasoft] メニューの [ヘルプ] をクリックして『Parasoft C/C++test 静的解析ルールガイド』ブックを参照してください。

C/C++test では、RuleWizard という付属ツールを使って設計したユーザー定義ルールをチェックすることもできます。RuleWizard を使用すれば、フローチャートのようなルール表現を作成してグラフィカルにルールを作成するか、単純なルール違反のコードから自動的にルールを作成できます。ユーザー定義ルールを作成してチェックすることで、チームはプロジェクトや組織に固有の要件を検証するだけでなく、最も一般的なエラーの再発を防止できます。

静的解析の詳細については、「静的コード解析」を参照してください。

抑制

抑制は、特定の静的解析違反メッセージを C/C++test でレポートしないようにする機能です。1 個の静的解析ルールが異なる違反メッセージをレポートすることもあります。全般的にコーディング規約に従いつつ一部のルールだけはあえて無視する場合、抑制機能を使用します。そうすれば、あえて違反しているルールについて何度も静的解析タスクがレポートされることなく、コードがコーディング規約に準拠しているかどうかをチェックできます。なお、あるルールのすべての静的解析違反メッセージをレポートしないようにするには、そのルールをチェックしないようテストコンフィギュレーションでルールを無効にすることを推奨します。

抑制はソースコード内またはローカル抑制ファイルに保存できます。これらのファイルをソース管理システムにチェックインし、チーム全体で共有できます。

静的解析違反メッセージの抑制の設定は、テストコンフィギュレーションから独立しています。次の違いに注意してください。

テストコンフィギュレーションは、静的解析の実行中にチェックされるルールセットを定義します。
静的解析違反メッセージの抑制の設定は、[品質タスク] ビューおよびテスト結果レポートに表示しない静的解析違反 (静的解析の解析結果) を定義します。

つまり、テストコンフィギュレーションで有効に設定されたルールを使って静的解析が実行された後、抑制の設定に一致した違反メッセージがテスト結果の表示から除外されます。

抑制の作成方法の詳細については「静的解析違反メッセージの抑制」を参照してください。

グラフィカルなルールエディター RuleWizard

RuleWizard を使用すると、C/C++ コードと書式の問題のための静的解析ルールを作成できます。RuleWizard で作成した静的解析ルールは C/C++test の静的解析で自動的に推進できます。ユーザー定義ルールを作成してチェックすることで、チームはプロジェクトや組織に固有の要件を検証するだけでなく、最も一般的なエラーの再発を防止できます。

ルールは、フローチャートに似たルール表現を作成してグラフィカルに作成することも、サンプルのルール違反から自動的に生成することもできます。ルールを作成および編集するために、パーサーの知識は必要ありません。

RuleWizard を起動するには、次のいずれかの操作を行います。

[Parasoft] メニューの [RuleWizard の起動] をクリックします。
テストコンフィギュレーションの [静的] タブで [新規] ボタンをクリックします。

RuleWizard GUI が表示されます。ユーザー定義ルールを変更、作成、有効化する方法については『RuleWizard ユーザーズガイド』を参照してください。このマニュアルを表示するには、 RuleWizard GUI で [Help] メニューの [Documentation] をクリックします。

ユーザー定義ルールを作成する方法については、「既存ルールのカスタマイズと新規ルールの作成」を参照してください。

フロー解析

重要な注意事項

この機能を使用するにはオプションのライセンスが必要です。Parasoft 担当者にお問い合わせください。

フロー解析は、実行パスのシミュレートなどの解析技術を使用して、実行時にしか明らかにならない潜在的な欠陥を検出する新しいタイプの解析テクノロジーです。検出される欠陥には、未初期化メモリ、null ポインターの間接参照、ゼロによる除算、メモリリークおよびリソースリークなどがあります。

フロー解析は複雑なパスを特定してトレースするため、人間によるテストや検査では発見が難しく、静的解析や単体テストでも発見されないことが多いバグを検出できます。コードを実行せずにバグを検出するフロー解析の機能は、特にレガシーコードベースや組込みコード、つまりそのようなエラーの実行時検出が効果的ではなかったり不可能だったりするコードに有効です。

フロー解析のユニークな静的解析は、まずコード中の「疑わしいポイント」を探索します。疑わしいポイントとは、バグの可能性がある箇所です。「疑わしいポイント」はフロー解析ルール中で定義されています。疑わしいポイントを発見するたびに、フロー解析はそのポイントに至る可能な実行パスを検査し、実行パスがフロー解析ルールに違反しているかどうかをチェックします。ルールに反するパスは違反としてレポートされます。

たとえば、ゼロによる除算の可能性を検出するルールは、“/” または “%” 演算子が使用されている箇所を「疑わしいポイント」と見なします。次にこのルールは、「疑わしいポイント」に至る可能な実行パスにおいて、分母の変数が値としてゼロを取り得るかどうかをチェックします。変数がゼロを取り得る場合、エラーがレポートされます。

発見されたバグごとに、階層的なフローパスデータが表示されます。その内容は、バグに至った完全な実行パスおよびバグが出現した正確なコード行です。発見された問題の診断と修正にかかる時間と労力を削減するために、フローパスデータには豊富な注釈が用意されています。たとえば NULL ポインターの間接参照のフローパスデータには、どの変数にどこで null 値が代入されたかが注釈として表示されます。

ユーザー固有のプロジェクトのニーズに合わせて解析プロセスをより柔軟にできるように、一部のルールはパラメータライズされています。結果として、フロー解析は、非常に特定の API の使用に限定された違反の検出にすら使用できます。

フロー解析の使用は、開発チームにとって次のメリットがあります。

既存のリソースを使って、より包括的なテストを実行するボタンをクリックするだけで、従来はテストケースの開発、実行、保守が必要だった問題を発見できます。フロー解析は、従来のテストでは困難なパスカバレッジレベルでプログラム中のさまざまな分岐の可能性を検査します。その結果、フロー解析は通常のテストでカバーされない珍しい状況を処理するときに発生する問題を特定できます。さらに、コードの機能が変わったときに、ユーザーはテストケースを更新したり再生成することなく、変更後のコードのバグを探すことができます。
複数のクラスにわたるバグを自動検出する従来の単体テストの自動生成は、1 つのクラス中のバグを特定するのに有効です。これは重要ですが、包括的ではありません。ほとんどの開発者は、1 つのクラスを徹底的にテストし、明らかな問題をすべて修正してコードを統合します。そして後で NULL ポインターの間接参照のような、診断に何日も要する問題に直面します。なぜなら、このような問題は複数の関数や複数のコンパイル単位にわたる複雑なパスによって発生するからです。フロー解析を使用すれば、同じ問題を短時間で発見できます。
実際のバグと設計ミスに集中できるフロー解析は、データまたはフローに依存するバグをかなりの正確さで自動的に特定します。フロー解析が違反をレポートする場合、その多くは設計ミスが原因であり、ゼロによる除算やリソースリークのような単純な違反として設計ミスが現れています。
たとえば次のコードの場合、通常の単体テストは単純に問題をレポートするでしょう。しかしフロー解析は、calculateBufferLength のメソッド呼び出しに null 値を渡さない限り、違反をレポートしません。
```
int calculateBufferLength(char* str)
{
            return strlen(str) + 1;
}
```
API の誤用を発見するAPI の誤用によるバグは数多くあります。誤った引数を API に渡したり、API から返る値の処理が不適切だったりするのが原因です。たとえば、ある API はパラメーター 1 が true の場合、パラメーター 2 に null 以外の値を渡す必要があります。また、ある API はオブジェクトの一部のフィールドに null をセットする可能性があります。手続き間の解析を行うことによって、フロー解析はそのような API の使用での不一致を検出できます。

詳細については「フロー解析」を参照してください。

単体テスト

単体テストとは、最も単純な機能ポイントでのソフトウェアコードのテストのことであり、このコードは通常 1 つのクラスまたは関数です。一般的に、単体テストは QA フェーズではなく開発サイクル中に開発者が実行します。コードブロックをアプリケーションに統合する前に単体テストを実行することで、エラーがない安定したコードブロックだけをアプリケーションに統合できるため、アプリケーション全体の品質が向上します。コードについての記憶がまだ新鮮なうちに早い段階でテストを実施すれば、後になってからテストする場合と比較して、コードの修正が容易になり、修正にかかる作業時間も短縮されます。

開発者が自分で単体テストを作成する場合、テストハーネスの記述、入力データの指定、見つからない関数と変数を代替するスタブの用意などの作業が必要です。 C/C++test はこれらの作業を自動化し、より効率的で一貫した単体テストプロセスを可能にします。

一般的に単体テストには次のテストが含まれます。

例外テスト例外テストはストレステストや信頼性テストとも呼ばれます。例外テストは、「コードが正しく安定していること」を検証するほか、「可能な入力範囲の値と値の組み合わせをすべて処理することができ、予想外の例外をスローしないこと」を検証します。
機能テスト機能テストは、ソフトウェアのビルディングブロックが仕様に準拠していること、そして仕様中の機能がすべて実装されていて正しく動作していることを検証します。単体レベルの機能テストを作成するには、入力、ステータス条件、および例外出力を指定します。機能テストは、ホワイトボックステストまたはブラックボックステストとして実装できます。ホワイトボックステストは、内部に関する知識とテスト対象ユニットの実装に関する知識を用いたテストです。ブラックボックステストは、テスト対象ユニットの外部的な動作にだけ基づいたテストです。
回帰テスト回帰テストは、コードの動作が一貫しているかを検証します。回帰テストは通常、一連のテストの開発、テストの正しさの検証、およびコードの変更後のテストの再実行から構成されます。コードの変更前と変更後のテスト結果を比較することによって、コードの動作が変わっていないかを検証します。回帰テストは例外テストと機能テストの両方に依存する場合があります。

C/C++test はこれらの単体テストをすべて実行できます。また、実行するテストのレベルとスコープをニーズに合わせてユーザーがカスタマイズできます。

例外テストは、C/C++test の自動生成テストケースを実行するときに実施されます。例外テストは、予想外の例外を検出して、クラスに構造的な問題がないかどうかをチェックします。信頼性テストが成功するかどうかは徹底的なコードカバレッジにかかっています。カバレッジ率が上昇するよう、必要に応じて自動生成テストケースを拡張してください。C/C++test のカバレッジ機能は、ユーザーがカバレッジ状況を確認し、テストの追加が必要かどうかを判断するのに役立ちます。

機能テストは、クラスの public インターフェイスが仕様どおりに動作しているかどうかを検証するために、自動生成テストケースを拡張したときに実施されます。

回帰テストは、使用できるテストケースをすべて実行し、期待される結果が変化していないかどうかをチェックすることによって、拡張中のコードベースに対して定期的に行います。現在のテストによるテストケースの結果が、期待されるテストケースの結果に一致していない場合、 C/C++test はエラーメッセージをレポートします。

テストケースは、C/C++ のソースコードで実装されて保存されます。生成されたテストケースは、IDE のテキストエディターで変更および拡張できます。テストケースの形式は、一般によく使用されている CppUnit 形式に似ています。C/C++test のソーステストは CppUnit よりも幅広い機能をユーザーに提供します。C コードのテストが可能であるほか、テストフレームワーク中の private データ、protected データ、メンバー関数へのプログラム的なアクセスが可能です。また、既存の CppUnit テストケースを C/C++test にインポートして自動生成テストケースと併用することもできます。

単体テストの実行に関する詳細は、「テストの作成と実行」を参照してください。

テストケースの生成

単体テストの作成は、コードの品質を保証するための重要なタスクです。単体テストは機能の問題とバグを発見するだけでなく、定期的な回帰テストとして実行することもできます。回帰テストは、コードの変更によって既存の機能に影響が出ていないか、予想外の変化が発生していないかを検証します。

ただし、単体テストの作成は時間のかかる作業であり、注意して作成しないと重要な状況を逃す可能性があります。C/C++test の単体テストは、優れた単体テストを短時間で作成するのに有効です。C/C++test を使用すると、ニーズに合わせてテストの生成と実行をカスタマイズして、大量の単体テストを自動生成することができます。C/C++test は、コード中の異なるパスをすべて実行するテストケースを大量に自動生成し、実際のテストケースの出力を保存しようとします。たとえて言えば、このテストケースはコードの現在の状況を X 線検査して検査結果を保存するようなものです。コードの現在の動作をキャプチャし、今後コードの変更があったときに現在の動作と変更後の動作を比較できるようにします。また、テストケースはコードの信頼性とセキュリティに影響する例外の可能性を特定するのにも有効です。

C/C++test は、1 つの関数からプロジェクト全体まで、C/C++ コードのためのテストケースを生成します。これらのテストケースを C/C++test で実行することによって、クラスの堅牢さを検証できるほか、プログラムの動作を不安定にしたりプログラムを終了させる入力を検出できます。ユーザーは、定義済みのテストモードをカスタマイズするだけでなく、特定のテスト生成の設定もカスタマイズできます。

テストケースは、テスト対象のソースに応じて、C または C++ のソースコードで実装されて保存されます。テストケースの形式は、一般によく使用されている CppUnit 形式に似ています。C/C++test のテストは CppUnit よりも幅広い機能をユーザーに提供します。C コードのテストが可能であるほか、テストフレームワーク中の private データ、protected データ、メンバー関数へのプログラム的なアクセスが可能です。また、既存の CppUnit テストケースを C/C++test にインポートして自動生成テストケースと併用することもできます。テストスイートはユーザー定義テストケースを使って拡張できます。テストカバレッジを向上し、特定の機能を検証することができます。これらのテストは、自動生成テストケースを変更するか、新規にテストケースを定義することで追加できます。利用可能なテストケースはすべて自動的に検証され、回帰テストのために構成されます。利用可能なすべてのテストケースを保存して自動回帰テストに活用することで、コードの変更によって発生した予定外の変更や例外を直ちに特定する回帰テストインフラストラクチャを確立できます。

テストケースの自動生成は、より短時間により効果的なテストスイートを作成することを可能にします。テストケースの開発は、単体テストプロセスにおいて伝統的に最も時間を要する部分です。この自動生成機能を利用すれば、クラスをテストするテストケースの基本セットを生成するためにコーディングする必要はありません。そして、自動生成テストケースに最小限のコードを追加することによって、さらにテストケースを作成できます。通常、単純なメソッドのためにテストケースを記述する必要はありません。そのため、より複雑なメソッドのためのテストを拡張/ 追加することに集中できます。

さらに、テストケースの生成は次の 2 つの重要な点でエラーを防止するのに役立ちます。

テストケースの自動生成によって、クラスの作成または変更が完了したときにすぐにテストケースを生成して実行できます。コーディング後にすぐに自動生成テストケースを実行することは、誤ってエラーを挿入する前に問題を発見して修正するのに役立ちます。
必要な範囲と型のテストケースを自動生成することによって、迅速かつ徹底的な信頼性テストを行うことができます。そのようなテストケースを開発者が自分で記述して作成することは現実的ではありません。C/C++test は、テスト対象の各メソッドについて、可能性があるすべてのブランチを実行するテストケースを作成します。たとえば、メソッドに if ブロックなどの条件文が含まれる場合、C/C++test は if 文の結果の true または false をテストするテストケースを生成します。

テストケースの生成の詳細については、「回帰テストと例外検出のためのテストケースの生成」を参照してください。

スタブ

スタブは、関数の代替実装の役割を果たすものであり、テスト対象の外部への依存関係からテストを切り離すことができるようにします。スタブを使用する場合、代替実装があるスタブ関数に実行フローがリダイレクトされます。

スタブは主に次の 2 つの目的で使用されます。

統合された環境からテスト対象コードを分離する
関数の動作に影響を与えることができず、代替実装が必要な場合にテストを実行する

C++ テンプレートにもスタブを利用できます。詳細については、「C++ テンプレートに対するスタブの使用」を参照してください。

自動生成テストケースでもユーザー定義テストケースでも、ユーザー独自のスタブを定義できます。ユーザー定義スタブを使用する場合、テスト対象のクラスに外部メソッドが返す値や例外を完全に制御できます。実際の外部メソッドが利用できない場合でも、スタブがあればテストを実行できます。

ユーザー定義スタブは、たとえオリジナル関数がある場合でも、常にテスト中に使用されます。当初オリジナル関数が存在せず、後から追加された場合、C/C++test はユーザー定義スタブを使用し続けます。つまり、オリジナル関数を使用する場合は、スタブを削除するかコメントアウトする必要があります。

ユーザー定義スタブは関数定義の形式で実装され、関数名の接頭辞は "CppTest_Stub_" です。例:

/* C++test user stub definition for int doSomething(int i) */
int ::CppTest_Stub_doSomething(int i)
{
    return i + 10;
}

スタブ化した関数の宣言にはスタブファイルからアクセスできなければなりません。ほとんどの場合、適切なヘッダーファイルをスタブファイルにインクルードしてスタブファイルと関数宣言を結ぶことができます。

C/C++test のスタブは、コンストラクタースタブを除き、オリジナル関数と同じ値を取ります。

自動生成されたスタブまたはスタブウィザードを使って作成されたスタブは、スタブの本体を変更することなく、テストケースから動的に設定することができます。動的なスタブの設定は、テストケースエディターから行うか (「テストケースエディターによるテストスイートとテストケースの追加」)、または動的スタブコンフィギュレーションを使ってテストケースのソースコードから直接行うことができます (「動的スタブの設定」を参照)。

動的スタブコンフィギュレーションを使用するのでは不十分な場合、生成されたスタブの本体をカスタムロジック実装で置き換えて、ユーザー定義スタブの C/C++test API 関数を利用することができます (「ユーザー定義スタブのための C/C++test API 関数」を参照)。

自動生成スタブの詳細については、「スタブの自動生成とカスタマイズ」を参照してください。

テスト中にアクセスできない外部リソースのためのユーザー定義スタブを使用する方法については、「スタブの追加と変更」を参照してください。

ファクトリ関数

ファクトリ関数は、特定の型のオブジェクトを初期化するために使用されるユーザー定義メソッドです。このユーザー定義メソッドは、テストケースを自動生成する場合およびテストケースウィザードを使ってテストケースを作成する場合に使用できます。

ファクトリ関数は次の目的で使用できます。

ユーザー定義型のための複雑なイニシャライザーを提供する (実際のオブジェクトの生成の後に初期化を実行するよう、ファクトリ関数を記述する)。
可能なオブジェクト作成メソッドの数を減らす (特定のクラスの利用可能なコンストラクターの中から 1 つだけを使用するよう、ファクトリ関数を記述する)。

ファクトリ関数は、関数名に "CppTest_Factory_" という接頭辞が付く関数です。ファクトリ関数の戻り値の型は、そのファクトリ関数を使ってどの型のオブジェクトを作成するかを定義します。ファクトリ関数は、ファクトリ関数をパラメータライズ可能にする引数を取ることができます。たとえば、次の std::vector<string> のファクトリ関数は多くの文字列を含みます。

std::vector<std::string> CppTest_Factory_vector_of_strings(unsigned int size, const std::string&value)
{
    std::vector<std::string> vec;     
    for (int i = 0; i < size; i++) { 
          vec.push_back(value); 
    }
    return vec; 
}

詳細については、「ファクトリ関数の使用」を参照してください。

実行時エラー検出

C/C++test の実行時エラー検出機能を利用すると、メモリリーク、NULL ポインター、未初期化メモリ、バッファーオーバーフローといった重大な実行時のエラーをユニットレベルまたはアプリケーションレベルで特定することができます。実行時エラー検出は、エンタープライズ開発にも組み込み開発にも適しています。

この実行時エラー検出機能は柔軟であるため、たとえば組込みシステムのような標準ではないメモリ割り当てモデルを使用している場合でも、実行時のメモリ解析を行うことができます。また、実行時エラーを検出するためのインストゥルメントは軽量であるため、ターゲット基板、シミュレーター、またはホスト上で組込みテストを実行できます。

詳細については「実行時エラー検出」を参照してください。

アプリケーション検証

アプリケーション検証は、実際のアプリケーションの実行からテスト結果を提供することを目的とします。アプリケーション検証を実行するために使用されるインストゥルメンテーションは軽量であり、組込みテストのターゲット基板上での実行に適しています。

C/C++test を使って、C/C++test のインストゥルメンテーションを使って準備されたアプリケーションの実行モジュールを監視することができます。アプリケーション検証は、多くの場合、通常のアプリケーションテストセッションにおいて、他の補完的な品質プラクティス (ピアレビュー、静的解析、単体テストなど) と合わせて開発者と QA の両方が実行します。

テスト中にアプリケーション検証を有効にすると、テスターの作業を増やすことなく、通常の QA セッションでは得られない詳細な情報を入手できます。唯一必要な準備は、C/C++test を使ってアプリケーションをビルドすることです。

アプリケーション検証の解析は次の機能を提供します。

カバレッジ解析 アプリケーションの実行中にアプリケーションコードのどの部分が実行されたかについての情報を提供します。この情報は、どのソースコード要素が特定の機能を実装しているか、どのユースケースがアプリケーションレベルのテストで実行されなかったかを特定するのに役立ちます。
実行時エラー検出 メモリアクセスエラー、メモリリーク、メモリ破損など、メモリエラーを検出できます。

アプリケーション検証の実施の詳細については、「実行時エラー検出」を参照してください。カバレッジ解析の詳細については「カバレッジ解析」を参照してください。

テストコンフィギュレーション

テストコンフィギュレーションは、C/C++test のテストシナリオを定義する設定の集合です。GUI からでもコマンドラインからでも、C/C++test でテストを実行するときには必ず専用のテストコンフィギュレーションが使用されます (明示的にテストコンフィギュレーションを選択しない場合は「お気に入り」テストコンフィギュレーションが使用されます)。テストコンフィギュレーションはすべてのテストパラメーターを決定します。たとえば：

実行するテストの種類 (静的解析のチェック、テストケースの生成、回帰テストなど)
静的解析の実行中にチェックするルール
テストケースの生成のためのパラメーター
テストのスコープ (カバーする行、使用する締切日など)

C/C++test には、最も一般的に使用されるテストシナリオを表したビルトインテストコンフィギュレーションが用意されています。ビルトインテストコンフィギュレーションをコピーして変更するか、新規にユーザー定義テストコンフィギュレーションを作成することによって、ニーズに合わせてテストコンフィギュレーションをカスタマイズできます。ユーザー定義テストコンフィギュレーションは、[ユーザー定義] カテゴリに保管できます。ユーザー定義テストコンフィギュレーションはローカルマシンに保存され、ローカルの C/C++test で実行されるすべてのテストで利用可能です。

C/C++test が DTP に接続されている場合は、DTP に格納されたコンフィギュレーションを使用して解析を実行できます。

テストコンフィギュレーションの構成と共有に関連する全般的な情報については、「テストコンフィギュレーションとルールの設定」を参照してください。C/C++test 固有のテストコンフィギュレーションオプションの詳細については「テストコンフィギュレーションの設定」を参照してください。

コマンドラインインターフェイス (cli)

C/C++test のコマンドラインインターフェイス (cpptestcli) では、コマンドラインから静的解析と単体テストを実行したり、バッチファイル、スクリプト、make、Ant などの自動ビルドユーティリティから C/C++test を実行したりできます。コマンドラインモードは C/C++test Automation Edition で利用できます。

cpptestcli は、Parasoft DTP に結果を送ったり、チームマネージャーや Team Server に全体的なレポートを送ったり、開発者に個別のレポートを送信したりできます。レポートは、HTML、PDF、およびカスタム XSL 形式で生成することができます。レポート関連の詳細設定 (レポートの送信相手、レポートのラベルの付け方、使用するメールサーバーとドメインなど) をはじめ、電子メール、ライセンスなどの設定は「オプションファイル」で制御できます。

最適な C/C++test チームコンフィギュレーションは、チームのビルドマシンに C/C++test Automation Edition を 1 つ、各開発者のワークステーションに C/C++test を 1 つ、設計者のマシンに C/C++test を 1 つ、そしてチームのビルドマシンまたは別のチームマシンに Parasoft DTP を 1 つ置くことです。

開発者は、ローカルの C/C++test を使ってコードの作成、変更、必要な修正を行い、ソース管理にコードをチェックインします。毎晩、C/C++test は cli モードでチームのビルドマシン上で実行され、チェックインされたコードを検証します。開発者が (自動テスト生成および手動テスト定義/カスタマイズによって) 作成してソース管理システムに追加したすべてのテストを実行します。テストが完了したら、各チームメンバーは静的解析の結果を自分のマシンの C/C++test GUI にインポートして、違反のレビューと修正を行うことができます。また、C/C++test は結果を Parasoft DTP に送信します。

コマンドラインからのテストの詳細については「コマンドラインインターフェイスからのテスト」を参照してください。

Parasoft DTP

Parasoft DTP は、ソフトウェア開発プロジェクトを順調に進めるために必要な、継続的な可視性とプロセスの測定を提供する意思決定サポートシステムです。DTP は開発プロセスで生成されたメトリクスを収集および関連付けし、これらのデータポイントを意味のある統計値およびダッシュボードに変換し、開発マネージャーやチームメンバーが継続的かつ客観的にコードの品質や進捗、コーディングプロセスのステータス、開発チームの生産性を評価することを可能にします。Parasoft DTP を使用すると、開発チームはプロジェクトのスケジュールや品質にとって脅威となるコードやコーディングプロセスのリスクをより簡単に発見、対応、管理することができます。Parasoft DTP が提供するメトリクスにより、経営層はより効果的にリソースの評価と配分を行い、開発ターゲットをモニターし、開発ポリシーの順守に関して通知、指導、計測を行い、プロジェクトの成功を確かなものにできます。

Parasoft DTP に情報を送信するよう C/C++test を設定すると、開発者、アーキテクト、マネージャーは Parasoft DTP のダッシュボードを使用して品質、進捗、生産性に関するロールベースのレポートにアクセスできます。

Parasoft DTP に接続する方法については「DTPとの接続」を参照してください。

Page tree

Concepts and Terms