サポートの概要
以下のバージョンのコンパイラ/環境がサポートされています。
- Green Hills MULTI v6.1.x C/C++ compiler v2013.1.x for INTEGRITY on PowerPC
Green Hills INTEGRITY プロジェクトの統合は、BDF 作成/インポート機能によってサポートされます。詳細については 「単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート」を参照してください。
- 元のプロジェクトのすべてのオプションが取得されます。
- .gpj プロジェクトの直接的なインポートは、Green Hills MULTI プロジェクト (INTEGRITY ではない) だけをサポートしています。
C++test は (ユーザーが指定した) INTEGRITY カーネルにロードされる動的ダウンロード INTEGRITY アプリケーション プロジェクトをテストできます。テスト対象として選択された仮想アドレス空間 (VAS) を実行し、単体テストまたはアプリケーション検証を行うことができます。C++test は VAS プロジェクトを分離して自動化されたテストを実行するため、元のプロジェクトに多数の仮想アドレス空間が含まれており、それらの仮想アドレス空間が互いに通信する場合、統合 (.int) ファイルに手動で変更を加える必要がある場合があります。
C++test は、次の C/C++ コンパイラをサポートすることによって、INTEGRITY アプリケーション用 Green Hills MULTI プロジェクトのテストを可能にします。
- ccintppc
- cxintppc
Green Hills MULTI プロジェクトのテストを容易にするために、以下のコンポーネントが用意されています。
- Run GHS INTEGRITY Tests テスト コンフィギュレーション 単体テストを起動する
- Run GHS INTEGRITY Application with Mem Monitoring テスト コンフィギュレーション アプリケーション検証を実行する
Green Hills INTEGRITYテスト コンフィギュレーションでは以下のプロパティを使用できます。
- Debug Server Name テストの実行に使用されるシミュレーター。デフォルトの設定は isimppc。
- Debug Host Name ホスト名。デフォルトの設定は localhost。
- Debug Connection Port ポート番号。デフォルトの設定は 2220。
- INTEGRITY Kernel ターゲットの INTEGRITY カーネルへのフルパス。デフォルトの設定は C:\ghs\int1104\bin\sim800\kernel
- MULTI board setup script (.mbs) ボード固有のセットアップ スクリプト。デフォルトの設定はなし
既知の制限事項
- AltiVec 拡張はサポートされていません。
- SPE 拡張はサポートされていません。
- C++test に用意されているコンフィギュレーションは、rtserv2 接続を経由して isimppc シミュレーターでテストを実行することを前提としています。他の方法でテストを行う場合は、コンフィギュレーションをカスタマイズする必要があります。
- C++test は INTEGRITY API を使用したマルチタスクの実行をサポートしていないため、それらの API 機能の呼び出しをスタブ化することを推奨します。
- Posix API を使用したマルチタスクの実行はサポートされています。詳細については 「マルチスレッド アプリケーションのテスト」を参照してください。
- テスト対象関数が所属するタスクにかかわらず、すべての単体テストはシングル タスクで実行されます。テストやカバレッジ結果に干渉する可能性があるため、他のタスクは無効化するべきです。
- 以下の非標準キーワードはサポートされていません。
- __interrupt
- __packed
- __bytereversed
- __bigendian
- __littleendian
- __typeof__
- __linkonce
要件
- コンパイラのフルパスが C++test プロジェクトのビルド オプションに設定されていない場合、PATH 変数に追加されていること。
- シミュレーター (isimppc) が PATH 変数に追加されていること。またはテスト コンフィギュレーションの Debug Server Name プロパティにシミュレーターへのフルパスが設定されていること。
- デバッガー (multi) が PATH 変数に追加されていること。
単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート
- テスト対象プロジェクトを準備します。
- 動的ダウンロード モジュールを作成 (または既存のモジュールを使用) します。仮想アドレス空間 (VAS) の数によって、後で統合構成スクリプト (.int) を手動で調整する必要があるかどうかが決まります。
- テストする VAS を 1 つ選択します (C++test の場合、1 つの VAS が分割できないアプリケーションになります)。
- 最上位の .gpj プロジェクトを右クリックし、[Edit] をクリックします。
- プロジェクトのフラグの 1 つとして
:binDir=bin
を追加します。この引数は、元のプロジェクト成果物が C++test の自動化に影響を与えないことを保証します。C++test はプロジェクト ディレクトリを作業ディレクトリとしてコマンドを実行するため、そのディレクトリにビルド成果物が残されていると、テスト実行可能ファイルのビルド時に予期しない結果につながる可能性があります。 - MULTI IDE 内で
.int
ファイルをダブルクリックし、Integrate GUI に表示します。 - [Task Initial] をダブルクリックし、Task Options エディターに表示します。
- [Start Automatically] オプションをオンにし、C++test がテスト対象モジュールを自動的にカーネルにロードし、開始できるようにします。
- アクティブ/テスト対象タスクの 「スタック サイズ」 を調整します。C++test ランタイムは、テスト対象 VAS に約 8 キロバイトのオーバーヘッドを追加するため、スタック サイズを 0x2000 増やすことを推奨します。
- プロジェクトに複数の VAS がある場合、元のインテグレーション構成スクリプト (.int) のコピーを作成し、他のすべての VAS を削除します。
- 以下のいずれかのコマンドを実行してビルド データ ファイル (BDF) を生成します。
gpj プロジェクトの場合
cpptesttrace --cpptesttraceProjectName=<VAS_name> --cpptesttraceOutputFile="<dir>\vas.bdf" gbuild -all -top <top_prj_name>.gpj <VAS_name>.gpj
Make プロジェクトの場合
cpptesttrace --cpptesttraceProjectName=<VAS_name> --cpptesttraceOutputFile="<dir>\vas.bdf" make <target_for_chosen_VAS>
- C++test にプロジェクトをインポートします。
- C++test で [ファイル] > [新規] > [プロジェクト] をクリックします。
- [C++test] > [ビルド データ ファイルからプロジェクトを作成] を選択し、[次へ] をクリックします。
- 手順 2 で生成したビルド データ ファイルへのパスを指定します。
- コンパイラ設定が正しく設定されていることを確認し、[次へ] をクリックします。
- プロジェクトの構造を確認し、[終了] をクリックします。
- プロジェクトのテスト準備のため、VAS のリンク中にインテグレーションを行うよう設定します。
- プロジェクト ノードを右クリックし、[プロパティ] をクリックします。
- [Parasoft] > [C++test] > [ビルド設定] をクリックします。
- [リンカー オプション] フィールドに -lhostio および
-intfile=<path_to_integrate_file>
を追加します。 C++test はfopen()
を使用して単体テストおよびカバレッジのデータをログに書き込むため、hostio
ライブラリとリンクする必要があります。intfile
ファイルは INTEGRITY アプリケーション用の単一 VAS の .int ファイルです。この指定により、リンク ステップが完了すると、インテグレーションが実行されます。 - テスト対象のソースを選択し、[Parasoft] > [テストの実行] > [ビルトイン] > [Unit Testing] > [Generate Unit Tests] をクリックします。
- テスト対象関数が Exit() 関数を呼び出さないことを確認します。Exit() 関数が呼び出される場合、スタブ化されていることを確認します。Exit() 関数を直接呼び出すと、テスト実行可能ファイルが途中で実行を終了します。詳細については 「初期化と終了処理」を参照してください。
- 自動生成スタブに次のステートメントが自動的に追加されていない場合、手動で追加します。
#include "INTEGRITY.h
自動生成スタブを使用する場合、通常はINTEGRITY.h
ヘッダーが必要です。 - [Parasoft]> [テストの実行] > [ビルトイン] > [Unit Testing] > [Embedded Systems] > [Green Hills Software] > [Run GHS INTEGRITY Tests] をクリックします。
その他の注意点
grun
の無効化
デフォルトでは、テスト コンフィギュレーション プロパティで指定されたカーネルは grun を使用して開始されます。grun
はデバッグ サーバーの実行に使用されるコマンドです。grun
コマンドは、180 秒というデフォルトのタイムアウト設定を使用して実行されます。これにより、テストを実行した結果として誤動作が発生した場合でも、予測可能な方法でカーネルが停止します。テスト実行に 180 秒より長い時間が必要であることがわかった場合、dbserv_timeout (<SetProperty key="dbserv_timeout" value="180" />)
プロパティの value 属性を変更するか、grun
を無効化することによってテスト実行フローを変更できます。
grun
を無効化するには、テスト実行フロー エディター内にある次の行のコメントを解除し、直接デバッグ サーバーを使用して指定されたカーネルを実行します。
<!--SetProperty key="kernel_cmd" value="${cpptestproperty:dbserv} "${cpptestproperty:kernel}"" /→
テスト実行フロー エディター内の次の行をコメント アウトし、カーネル実行時に grun を無効化します。
<SetProperty key="kernel_cmd" value="grun ${cpptestproperty:dbserv_timeout_opt} ${cpptestproperty:script_opt} ${cpptestproperty
どんな方法でカーネルを実行したかにかかわらず、テスト実行フローは、テスト完了時に実行中の可能性があるカーネル プロセスを終了しようとします。
ファイルの同期
テスト実行フローは、ファイル同期ステップを利用してテスト実行の完了を検知します。ファイル同期ステップはテスト実行フローの最後のほうにあります。
<FileSynchronizeStep fileSync="${cpptest:testware_loc}/cpptest_results.tlog" fileInactiveTimeout="10000" />
このステップは、テスト ログ ファイルのタイムスタンプを追跡します。テスト実行に伴って、テスト ログ ファイルは各テストの情報で更新されます。C++test はログ ファイルが 10000 ミリ秒間アクティブではないことを検出すると、実行を停止します。単体テスト実行中に 10 秒以上アクティブではない状態が持続することが予想される場合、fileInactiveTimeout
属性の値を適切なタイムアウト値に変更するべきです。FileSynchronizeStep
フロー ステップの詳細およびテストフロー実行に関するその他の情報については、「テスト実行フローの説明とサンプル」を参照してください。
タイムアウト時間の延長
[Run GHS INTEGRITY Application with Mem Monitoring] テスト コンフィギュレーションを使用してアプリケーション検証を実行する場合、テスト実行フローでのファイル同期の利用方法が適切ではない可能性があります。アプリケーションにレポート可能なメモリ違反が少ししか含まれていない場合、結果ファイルは時々しか更新されないため、意図しないタイムアウトにつながる可能性があります。
タイムアウトまでの時間を増やすのに加えて、FileSynchronizeStep
の別の機能を利用して、アプリケーション実行の終了を知らせる同期ファイルが作成されるまで C++test を待機させることができます。
<FileSynchronizeStep fileSync="<path/to/synchronization/file.txt>" timeout="30000" />
この同期ファイルはアプリケーション コード内で手動で作成することもできますし、CppTest_Finalize
関数を実装して FileSynchronizeStep
が待機するファイルを手動で作成することもできます。CppTest_Finalize
関数は、アプリケーション実行の最終ステップの 1 つとして自動的に呼び出されます。
同期ファイルを作成した後、タイムアウトの時間を、アプリケーションの実行が継続される時間に合わせて適切な値に増やすことができます。カスタム初期化処理および終了処理については、「初期化と終了処理」を参照してください。
テスト実行の途中終了を防ぐ
テスト対象関数内で Exit() 関数が呼び出されている場合、テスト実行が途中で終了するのを防ぐため、Exit() の呼び出しをスタブ化するべきです。しかし、必要であれば、CppTest_Finalize 関数を実装することによって Exit() 関数を呼び出すことも可能です。CppTest_Finalize 関数は、アプリケーション実行の最終ステップの 1 つとして自動的に呼び出されます。カスタム初期化処理および終了処理については、「初期化と終了処理」を参照してください。
テストの自動再実行
多くの C++test テスト コンフィギュレーションは、テスト ケース内で発生した予期しない振る舞いによってテスト実行可能ファイルがクラッシュまたは異常終了した後、自動的にテスト実行可能ファイルを再実行する仕組みを使用します。この仕組みによって、テスト実行可能ファイルが再実行され、次のまだ実行されていない単体テストが開始されます。しかし、INTEGRITY アプリケーションに関する Green Hills フレームワークの制限事項により、INTEGRITY アプリケーションの実行時にはこの仕組みが利用できません。単体テストが原因でテスト実行が途中終了した場合、単体テストが終了し、その時点までに収集された結果を確認できます。
複数の仮想アドレス空間のテスト
C++test でテストを行う際、1 つの VAS を単独でテストするのが理想的ですが、テスト対象 VAS が同じ INTEGRITY アプリケーション内の他の VAS と対話する必要があるかもしれません。この場合、手動でワークフローをカスタマイズする必要があるでしょう。また、以下の点に注意する必要があります。
- 他の VAS は C++test とのインテグレーションの前にビルドされている必要があります。「単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート」を参照してください。
- C++test はプロジェクトの場所からインテグレーション コマンドを実行するため、他の仮想アドレス空間のビルド成果物をプロジェクト ディレクトリに置く必要があるでしょう。または、ビルド成果物を C++test テスト実行可能ファイルの場所の内部に配置します。
- 他の仮想アドレス空間と通信する必要がある関数に対して自動生成テストを実行すると、予期しない振る舞いや結果につながる場合があります。1 つの仮想アドレス空間を他の仮想アドレス空間と共にテストする場合、注意が必要です。
共有ライブラリ使用時の C++test ランタイムの終了処理
C++test ランタイムは、テスト実行中およびアプリケーション検証中に、静的オブジェクトのデストラクターを呼び出すことによって必要な終了処理ステップの一部を実行することがあります。現行の Green Hills MULTI v6.1.x C/C++ compiler v2013.1.x for INTEGRITY on PowerPC の制限により、プロジェクトで -non_shared フラグが使用されていない場合、静的オブジェクトのデストラクターは呼び出されません。-non_shared コンパイラ フラグが使用されていない場合、アプリケーションの main() 関数の最後に手動で CppTest_FinalizeRuntime() 関数の呼び出しを追加する必要があります。これによって、C++test は必要なすべての終了処理ステップを実行できるようになります。CppTest_FinalizeRuntime() 関数の使用に関する詳細は、「初期化と終了処理」を参照してください。