このセクションの内容

静的解析

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との接続」を参照してください。

  • No labels