このセクションの内容:

静的解析

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

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

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

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

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

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

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

抑制

抑制は、特定の静的解析違反メッセージをC++test でレポートしないようにする機能です。1 個の静的解析ルールが異なる違反メッセージをレポートすることもあります。抑制された違反メッセージは [ 品質タスク] ビューではなく[ 抑制] ビューに送られます。これにょり、必要に応じて抑制された違反を参照できるいっぽうで、主要な結果のエリアでは他のエラーに集中することができます。

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

抑制は、GUI から入力することもコード中に記述することもできます。GUI で入力した抑制は、コード中に保持するか、または Parasoft Team Server に保存してチームで共有することができます。

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

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

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

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

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

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

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

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

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

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

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

データフロー解析による静的解析

重要な注意事項

この機能を使用するにはオプションのライセンスが必要です。

「バグ探偵」は新しい静的解析テクノロジーです。「バグ探偵」は実行をシミュレートして、実行時のバグ ( 未初期化メモリの使用、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++test はこれらの作業を自動化し、より効率的で一貫した単体テストプロセスを可能にします。

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

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

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

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

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

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

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

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

テストケースの生成

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

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

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

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

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

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

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

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

スタブ

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

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

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

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

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

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

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

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

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

動的スタブ API を使用するのでは不十分な場合、生成されたスタブの本体をカスタムロジック実装で置き換えて、ユーザー定義スタブの C++test API 関数を利用することができます (「 C++test API Functions for User-Defined Stubs」を参照)。

自動生成スタブの詳細については、「Understanding and Customizing Automated Stub Generation」を参照してください。

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

ファクトリ関数

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

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

ユーザー定義型のための複雑なイニシャライザーを提供する ( 実際のオブジェクトの生成の後に初期化を実行するよう、ファクトリ関数を記述する)。
可能なオブジェクト作成メソッドの数を減らす ( 特定のクラスの利用可能なコンストラクターの中から 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++test の実行時エラー検出機能を利用すると、メモリリーク、NULL ポインター、未初期化メモリ、バッファーオーバーフローといった重大な実行時のエラーをユニットレベルまたはアプリケーションレベルで特定することができます。

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

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

アプリケーション検証

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

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

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

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

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

実行時エラー検出の詳細については「実行時エラー検出」を参照してください。カバレッジ解析の詳細については「カバレッジ解析」を参照してください。

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

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

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

C++test には、最も一般的に使用されるテストシナリオを表現したビルトインテストコンフィギュレーションが用意されています。ビルトインテストコンフィギュレーションをコピーして変更するか、新規にユーザー定義テストコンフィギュレーションを作成することによって、必要に応じてテストコンフィギュレーションをさらにカスタマイズできます。ユーザー定義テストコンフィギュレーションは「ユーザー」または「チーム」カテゴリの下に置くことができます。「ユーザー」カテゴリのテストコンフィギュレーションは、ローカルマシンに格納することで、そのマシン上の C++test が実行するすべてのテストで利用できます。「チーム」カテゴリのテストコンフィギュレーションは、チームの Team Server に格納することで、チームメンバー全員がアクセスできます。

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

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

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

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

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

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

開発者は、ローカルの C++test を使ってコードの作成、変更、必要な修正を行い、ソース管理にコードをチェックインします。毎晩チームのビルドマシンまたは別のチームサーバーマシンに対して cpptestcli を実行し、必要に応じてテストケースを生成し、全開発者がチェックインしたコードを検証します。テストが完了したら、各チームメンバーは静的解析の結果を自分のマシンの C++test GUI にインポートして、違反のレビューと修正を行うことができます。C++test はテスト結果を Report Center に送信するほか、開発者には各開発者に関連したエラー/ 結果だけのレポートを送信し、グループマネージャーにはチーム/ プロジェクトのすべてのエラーのリストと各エラーを起こした開発者のリストをレポートとして送信し、そして Team Server にはレポートとテスト結果をアップロードします。

このプロセスの最中、Team Server はテスト設定とテストファイルの共有と更新を管理します。このプロセスは、チーム全体にわたってテストを標準化し、チームメンバーが互いの作業を活用するのに役立ちます。標準化されたテスト設定とカスタムチームルールは、チームの設計者によって構成/ 管理されます。

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

Parasoft Team Server

Parasoft のコンポーネントである Parasoft Team Server (旧 TCM) は、チームの適切なテストコンフィギュレーション、抑制、ルールファイル、テストケースファイルにチームメンバー全員がアクセスできるようにします。本バージョンの C++test は Team Server 2.0 以上と連携して動作します。

Team Server をインストールして Web サービスとして配布したら、チームの設計者または管理者は 1 つの C++test に対して適切なチーム設定とファイルを構成し、設定と関連テストファイルの場所を Team Server で設定します。各開発者は自分のマシンで Team Server の場所を設定すると、Team Server によってすべての開発者のマシンから適切な設定とファイルにアクセスできるようになります。マスター版のファイルが変更、追加、削除されると、Team Server によってチームのすべての C++test に対して適切に更新が適用されます。

Team Server を使って C++test ファイルを共有するには、チーム中のマシンの 1 台に Team Server をインストールして配置する必要があります。Team Server (別売) については、テクマトリックス株式会社までご連絡ください。なお、C++test Server Edition には Team Server のライセンスが含まれています。

Team Server に接続する方法については「Development Testing Platform との接続」を参照してください。

Parasoft Development Testing Platform

Parasoft Development Testing Platform (DTP) は、ソフトウェアプロジェクトを円滑に進めるのに必要なソフトウェア開発プロセスに関するリアルタイムの可視性と測定を提供する意思決定サポートシステムです。開発プロセス中に生成されたメトリクスを収集・統合して、それらのデータポイントを意味のある統計値やダッシュボードに変換し、開発マネージャーおよびチームメンバーがコードの品質と準備状況、コーディングプロセスのステータス、開発チームの効率性を継続的かつ客観的に評価することを可能にします。Parasoft DTP を利用すると、開発チームはより簡単にコードやコーディングプロセスに潜むリスクを検出し、対処、管理することができます。Parasoft DTP が提供するメトリクスによって、マネージメント層は、より効率的なリソースの評価と割り当て、開発ターゲットの設定とモニター、開発ポリシーへの準拠の伝達・指導・計測を行うことができ、プロジェクトを成功に導くことができます。

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

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

Page tree

Concepts and Terms