サポートの概要

サポートされる Green Hills コンパイラについては「コンパイラ」を参照してください。

Green Hills INTEGRITY プロジェクトの統合は、BDF 作成/インポート機能によってサポートされます。詳細については「単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート」を参照してください。

元のプロジェクトのすべてのオプションが取得されます。
.gpj プロジェクトの直接的なインポートは、Green Hills MULTI プロジェクト (INTEGRITY ではない) だけをサポートしています。

C/C++test は (ユーザーが指定した) INTEGRITY カーネルにロードされる動的ダウンロード INTEGRITY アプリケーションプロジェクトをテストできます。テスト対象として選択された仮想アドレス空間 (VAS) を実行し、単体テストまたはアプリケーション検証を行うことができます。C/C++test は VAS プロジェクトを分離して自動化されたテストを実行するため、元のプロジェクトに多数の仮想アドレス空間が含まれており、それらの仮想アドレス空間が互いに通信する場合、統合 (.int) ファイルに手動で変更を加える必要がある場合があります。

C/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/C++test に用意されているコンフィギュレーションは、rtserv2 接続を経由して isimppc シミュレーターでテストを実行することを前提としています。他の方法でテストを行う場合は、コンフィギュレーションをカスタマイズする必要があります。
C/C++test は INTEGRITY API を使用したマルチタスクの実行をサポートしていないため、それらの API 機能の呼び出しをスタブ化することを推奨します。
Posix API を使用したマルチタスクの実行はサポートされています。詳細については「マルチスレッドアプリケーションのテスト」を参照してください。
テスト対象関数が所属するタスクにかかわらず、すべての単体テストはシングルタスクで実行されます。テストやカバレッジ結果に干渉する可能性があるため、他のタスクは無効化するべきです。
以下の非標準キーワードはサポートされていません。
- __interrupt
- __packed
- __bytereversed
- __bigendian
- __littleendian
- __typeof__
- __linkonce

要件

コンパイラのフルパスが C/C++test プロジェクトのビルドオプションに設定されていない場合、PATH 変数に追加されていること。
シミュレーター (isimppc) が PATH 変数に追加されていること。またはテストコンフィギュレーションの Debug Server Name プロパティにシミュレーターへのフルパスが設定されていること。
デバッガー (multi) が PATH 変数に追加されていること。

単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート

テスト対象プロジェクトを準備します。
1. 動的ダウンロードモジュールを作成 (または既存のモジュールを使用) します。仮想アドレス空間 (VAS) の数によって、後で統合構成スクリプト (.int) を手動で調整する必要があるかどうかが決まります。
2. テストする VAS を 1 つ選択します (C/C++test の場合、1 つの VAS が分割できないアプリケーションになります)。
3. 最上位の .gpj プロジェクトを右クリックし、[Edit] をクリックします。
4. プロジェクトのフラグの 1 つとして :binDir=bin を追加します。この引数は、元のプロジェクト成果物が C/C++test の自動化に影響を与えないことを保証します。C/C++test はプロジェクトディレクトリを作業ディレクトリとしてコマンドを実行するため、そのディレクトリにビルド成果物が残されていると、テスト実行可能ファイルのビルド時に予期しない結果につながる可能性があります。
5. MULTI IDE 内で .int ファイルをダブルクリックし、Integrate GUI に表示します。
6. [Task Initial] をダブルクリックし、Task Options エディターに表示します。
7. [Start Automatically] オプションをオンにし、C/C++test がテスト対象モジュールを自動的にカーネルにロードし、開始できるようにします。
8. アクティブ/テスト対象タスクの「スタックサイズ」を調整します。C/C++test ランタイムは、テスト対象 VAS に約 8 キロバイトのオーバーヘッドを追加するため、スタックサイズを 0x2000 増やすことを推奨します。
9. プロジェクトに複数の 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/C++test にプロジェクトをインポートします。
1. C/C++test で [ファイル] > [新規] > [プロジェクト] をクリックします。
2. [C/C++test] > [ビルドデータファイルからプロジェクトを作成] を選択し、[次へ] をクリックします。
3. 手順 2 で生成したビルドデータファイルへのパスを指定します。
4. コンパイラ設定が正しく設定されていることを確認し、[次へ] をクリックします。
5. プロジェクトの構造を確認し、[終了] をクリックします。
プロジェクトのテスト準備のため、VAS のリンク中にインテグレーションを行うよう設定します。
1. プロジェクトノードを右クリックし、[プロパティ] をクリックします。
2. [Parasoft] > [C/C++test] > [ビルド設定] をクリックします。
3. [リンカーオプション] フィールドに -lhostio および -intfile=<path_to_integrate_file> を追加します。C/C++test は fopen() を使用して単体テストおよびカバレッジのデータをログに書き込むため、hostio ライブラリとリンクする必要があります。intfile ファイルは INTEGRITY アプリケーション用の単一 VAS の .int ファイルです。この指定により、リンクステップが完了すると、インテグレーションが実行されます。
テスト対象のソースを選択し、[Parasoft] > [テストの実行] > [ビルトイン] > [Unit Testing] > [Generate Unit Tests] をクリックします。
テスト対象関数が Exit() 関数を呼び出さないことを確認します。Exit() 関数が呼び出される場合、スタブ化されていることを確認します。Exit() 関数を直接呼び出すと、テスト実行可能ファイルが途中で実行を終了します。詳細については「Additional Notes」を参照してください。
自動生成スタブに次のステートメントが自動的に追加されていない場合、手動で追加します。
#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:dbserv} -- "${cpptestproperty:kernel}"" />

どんな方法でカーネルを実行したかにかかわらず、テスト実行フローは、テスト完了時に実行中の可能性があるカーネルプロセスを終了しようとします。

ファイルの同期

テスト実行フローは、ファイル同期ステップを利用してテスト実行の完了を検知します。ファイル同期ステップはテスト実行フローの最後のほうにあります。

<FileSynchronizeStep
   fileSync="${cpptest:testware_loc}/cpptest_results.tlog" 
   fileInactiveTimeout="10000"
/>

このステップは、テストログファイルのタイムスタンプを追跡します。テスト実行に伴って、テストログファイルは各テストの情報で更新されます。C/C++test はログファイルが 10000 ミリ秒間アクティブではないことを検出すると、実行を停止します。単体テスト実行中に 10 秒以上アクティブではない状態が持続することが予想される場合、fileInactiveTimeout 属性の値を適切なタイムアウト値に変更するべきです。FileSynchronizeStep フローステップの詳細およびテストフロー実行に関するその他の情報については、「テスト実行フローの説明とサンプル」を参照してください。

タイムアウト時間の延長

[Run GHS INTEGRITY Application with Mem Monitoring] テストコンフィギュレーションを使用してアプリケーション検証を実行する場合、テスト実行フローでのファイル同期の利用方法が適切ではない可能性があります。アプリケーションにレポート可能なメモリ違反が少ししか含まれていない場合、結果ファイルは時々しか更新されないため、意図しないタイムアウトにつながる可能性があります。

タイムアウトまでの時間を増やすのに加えて、FileSynchronizeStep の別の機能を利用して、アプリケーション実行の終了を知らせる同期ファイルが作成されるまで C/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/C++test テストコンフィギュレーションは、テストケース内で発生した予期しない振る舞いによってテスト実行可能ファイルがクラッシュまたは異常終了した後、自動的にテスト実行可能ファイルを再実行する仕組みを使用します。この仕組みによって、テスト実行可能ファイルが再実行され、次のまだ実行されていない単体テストが開始されます。しかし、INTEGRITY アプリケーションに関する Green Hills フレームワークの制限事項により、INTEGRITY アプリケーションの実行時にはこの仕組みが利用できません。単体テストが原因でテスト実行が途中終了した場合、単体テストが終了し、その時点までに収集された結果を確認できます。

複数の仮想アドレス空間のテスト

C/C++test でテストを行う際、1 つの VAS を単独でテストするのが理想的ですが、テスト対象 VAS が同じ INTEGRITY アプリケーション内の他の VAS と対話する必要があるかもしれません。この場合、手動でワークフローをカスタマイズする必要があるでしょう。また、以下の点に注意する必要があります。

他の VAS は C/C++test とのインテグレーションの前にビルドされている必要があります。「単体テストまたはアプリケーション検証のための INTEGRITY プロジェクトのインポート」を参照してください。
C/C++test はプロジェクトの場所からインテグレーションコマンドを実行するため、他の仮想アドレス空間のビルド成果物をプロジェクトディレクトリに置く必要があるでしょう。または、ビルド成果物を C++test テスト実行可能ファイルの場所の内部に配置します。
他の仮想アドレス空間と通信する必要がある関数に対して自動生成テストを実行すると、予期しない振る舞いや結果につながる場合があります。1 つの仮想アドレス空間を他の仮想アドレス空間と共にテストする場合、注意が必要です。

共有ライブラリ使用時の C/C++test ランタイムの終了処理

C/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/C++test は必要なすべての終了処理ステップを実行できるようになります。CppTest_FinalizeRuntime() 関数の使用に関する詳細は、「初期化と終了処理」を参照してください。

Page tree

About INTEGRITY