このセクションでは、クロス コンパイラ テストのためのカスタム テスト実行フローを定義する方法について説明します。テスト実行フローを使って、たとえばクロス コンパイラを使ってテストをビルドした後、デプロイ、テスト実行、結果収集のためのプラットフォーム固有の処理を実行できます。

このセクションの内容

テスト実行フローについて

テストを実行するように設定されたテスト コンフィギュレーションを実行すると、一連のアクションが実行されます。そして通常、C/C++test GUI に単体テストの結果がロードされます。このアクションはテスト実行フロー ファイルで指定されています。テスト実行フロー ファイルは XML 形式のファイルであり、テスト コンフィギュレーションの一部として保存されます。テストを実行するすべてのビルトイン テスト コンフィギュレーションには、対応する定義済みテスト実行フローが存在します。 

ホスト ベースのテストを目的として作成された定義済み実行フローを利用するだけでなく、C/C++test では、非標準の環境での作業を容易にするために、ユーザーがカスタム テスト実行フローを定義できます。 

テスト実行フローのカスタマイズ

テスト実行フローのパラメーターは必要に応じてカスタマイズすることができます。テスト コンフィギュレーションの [実行] > [全般] の [実行の詳細] でカスタマイズします。

ビルトイン テスト コンフィギュレーションを利用して簡単にテスト実行フローを編集できます。ただし多くの場合、テスト実行フローを作成する必要はありません。 

ユーザー定義テスト コンフィギュレーションのためのカスタム テスト実行フローを定義するには、次の操作を行います。

  1. [Parasoft] メニューの [テスト コンフィギュレーション] をクリックします。
  2. [実行] タブの [全般] タブをクリックします。
  3. 既存のプロパティを変更するには、プロパティ テーブルでパラメーターを直接編集します。



    プロパティ テーブルを右クリックして次のショートカット メニューを使用できます。 
    • デフォルト値に戻す
    • ファイルの場所を挿入
    • ディレクトリの場所を挿入
  4. プロパティ テーブルに現在表示されていないテスト フロー プロパティを変更するには、次の操作を行います。たとえば、頻繁に変更する予定のプロパティなどの場合です。
    1. 適切なテスト実行フローを選択し、[編集] ボタンをクリックします。

    2. テスト フロー中のプロパティ定義を探します。プロパティ定義は次のような形式になっています。

      <SetProperty key="property_key"
value="property_default_value"

    3. 2 つの属性 uiEditable="true" および displayName="user_friendly_name" を追加します。プロパティ定義は次のようになります。

      <SetProperty key="property_key"
value="property_default_value"
uiEditable="true"
displayName="This is a customizable property" />

      uiEditable="true" 属性が SetProperty フロー ステップに追加されるため、このプロパティはプロパティ テーブルでカスタマイズできるようになります。このプロパティは、displayName 属性の値を使って表示されます。value 属性はデフォルト値として使用されます。

    4. [OK] ボタンをクリックしてファイルを保存します。XML 文書が検証されます。検証中に問題が発見された場合、その問題がレポートされます。
  5. [適用] ボタンをクリックしてから [OK] をクリックして変更後のテスト コンフィギュレーションを保存します。

テスト実行フローのカスタマイズは、テスト コンフィギュレーションと共に保存されます。

カスタム テスト実行フローの定義: 詳細

まず上記の「テスト実行フローのカスタマイズ」で説明したように、プロパティ リストを変更することを推奨します。さらにカスタマイズが必要な場合には、カスタム テスト実行フローを定義することができます。

カスタム テスト実行フロー定義は XML 形式のファイルであり、テスト コンフィギュレーションの一部として保存されます。そのため、チーム メンバー間で共有することができます。通常、カスタム テスト実行フロー定義には、非標準の環境で単体テストを実行するのに必要な手順を記述します。また、任意のコマンドライン ユーティリティを起動するためにカスタム テスト実行フロー定義を使用することもできます。実際、 カスタム テスト実行フロー定義には、C/C++test の内部アクションまたは OS でプロセスとして起動される外部ユーティリティを含めることができます。デフォルトのテスト実行フローは、次の方法で変更できます。

  • 既存のステップを削除する。
  • 新しいステップを追加する。
  • 既存のステップのパラメーターをカスタマイズする。

ユーザー定義テスト コンフィギュレーションのためのカスタム テスト実行フローを定義するには、次の操作を行います。

  1. [Parasoft] メニューの [テスト コンフィギュレーション] をクリックします。
  2. [ビルトイン] > [Unit Testing] を展開します。
  3. [Build Test Executable] テスト コンフィギュレーションを右クリックし、ショートカット メニューの [複製] をクリックします。




  4. [ユーザー定義] > [Build Test Executable] を選択します。
  5. テスト コンフィギュレーションの名前を Build <target> Executable などに変更します (<target> の部分にはターゲット名を入れてください)。

  6. [実行] > [C++test] > [シンボル] タブをクリックし、[次の場所で発見されたファイルのシンボルも使用] チェックボックスをオフにします。

    注意

    [次の場所で発見されたファイルのシンボルも使用] チェックボックスをオフにせずにテスト用実行モジュールをビルドすると、ビルド時に次のエラーが発生します。

    Error preprocessing file "C:\Program 
Files\ParaSoft\C++test9.0\plugins\com.parasoft.xtest.libs.cpp.win32.x86_9.0.4.43\ os\win32\x86\etc\safestubs\safe_stubs_Win32.c": 

Process exited with code: 1
  7. テスト実行フローを編集します。
    1. [実行] タブの [全般] タブをクリックします。
    2. [テスト実行フロー] から [カスタム フロー] を選択して [編集] ボタンをクリックします。
    3. 既存のテスト実行フローを [利用可能なビルトイン テスト実行フロー] から選択して [XML を再現] ボタンをクリックします。表示された XML ファイルを編集します。フロー定義の変更の詳細については、「テスト実行フロー 定義のカスタマイズ例」を参照してください。
  8. [OK] ボタンをクリックしてファイルを保存します。XML 文書が検証されます。検証中に問題が発見された場合、その問題がレポートされます。
  9. [適用] ボタンをクリックしてから [OK] をクリックして変更後のテスト コンフィギュレーションを保存します。

ソケット通信チャネルを使用するテスト実行フローを定義する

TCP/IP ソケットを利用できる組込み環境では、 TCP/IP ソケットを使ってテスト実行フローを自動化するのが一般的です。ソケット通信チャネルを利用するテスト実行の一般的な流れは次のとおりです。

  1. 適切なユーザー定義テスト コンフィギュレーションを実行して、テスト用実行モジュールをビルドします。

    • 必要に応じて、個別のニーズに合わせてこのテスト コンフィギュレーションのテスト実行フローを変更します。ほとんどの場合、異なる点は、生成される実行ファイルの拡張子、そして特定のネットワーク関連の値 (ポートや IP 番号など) の設定だけです。

      テスト フローの変更例

      <SetProperty key="results_port" value="2567" />
<SetProperty key="coverage_port" value="2568" />
<TestRunnerWithSocketsGenerationStep
testSuiteConfigFile="${cpptest:testware_loc}/testsuites.xml" 
testrunnerCFile="${cpptest:testware_loc}/cpptest_testrunner.c" 
testrunnerCppFile="${cpptest:testware_loc}/cpptest_testrunner.cpp" 
resultsHost="10.9.1.30"
testLogPort=${cpptestproperty:results_port}
covLogPort=${cpptestproperty:coverage_port}
/>
<CompileStep />
<LinkStep result="${cpptest:testware_loc}/${project_name}Test.foo"/>

      最初の部分 (TestRunnerWithSocketsGenerationStep) は、特定のネットワーク値 (プロパティ ファイルから取得された IP とポート番号) を使って、テスト フレームワークの実行を準備します。 

      2 番目の部分は、テスト用実行モジュールをコンパイルします。

      最後の部分 (LinkStep) は、最終的なテスト用実行モジュールを得るために、リンカーを呼び出します (この例では $ {project_name}Test.foo ですが、ご使用のシステムに合わせて、拡張子を変更する必要があります)。

      なお、デフォルトの TestRunnerGenerationStep ではなく TestRunnerWithSocketsGenerationStep を使用する点に注意してください。

  2. テスト用実行モジュールをターゲット デバイスにデプロイします。
    • このステップは、常に自動化できるとは限りません。システムが自動デプロイをサポートしていない場合、ターゲット デバイスにユーザーが自分で実行モジュールをデプロイしなければならないことがあります。システムが自動デプロイをサポートしている場合、システムが提供する FTP プロトコルや同期化ツール、その他の手段を利用できます。
  3. ソケット通信チャネルを使って結果を収集するように構成した、C/C++test SocketListener ツールを実行します。
    • このステップ 3 およびステップ 4 の詳細については、下記の「ステップ 3 とステップ 4 のテスト実行フロー例」を参照してください。
    • 実行された SocketListener ツールは、指定のポートに結果が到着するのを待機し始めます。
  4. テスト用実行モジュールを起動します。初期化の後、テスト用実行モジュールは 2 つのポートをオープンし、C/C++test にデータを送信しようとします。このデータはリスニング エージェントによって収集され、今後の解析のために C/C++test にロードされます。
    • このステップ 3 およびステップ 3 の詳細については、下記の「ステップ 3 とステップ 4 のテスト実行フロー例」を参照してください。
ステップ 3 とステップ 4 のテスト実行フロー例
<CustomStep
id="run_socket_listeners"
label="Running Socket Listeners..."
commandLine=""java" -cp "${cpptest:cfg_dir}/../lib/source/socket_listener"
SocketListener --channel "${cpptestproperty:results_port}@$
{cpptest:testware_loc}/cpptest_results.tlog" --channel 
"${cpptestproperty:coverage_port}@$
{cpptest:testware_loc}/cpptest_results.clog" -sf 
"${cpptest:testware_loc}/sync_file" -to 60"
workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.res"
runInBackground="true"
/>
<CustomStep
id="run_synchronization"
label="Running Synchronization..."
commandLine=""java" -cp "${cpptest:cfg_dir}/../lib/source/socket_listener"
Synchronize -sf "${cpptest:testware_loc}/sync_file.init" -to 60"
workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.res"
runInBackground="false"
/>
<CustomStep
id="run_test_exec"
label="Running Tests..."
commandLine="${cpptest:testware_loc}/${project_name}Test.foo" workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.res"
runInBackground="false"
/>
<CustomStep
id="run_synchronization"
label="Running Synchronization..."
commandLine=""java" -cp "${cpptest:cfg_dir}/../lib/source/socket_listener"
Synchronize -sf "${cpptest:testware_loc}/sync_file.final" -to 60"
workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.res"
runInBackground="false"
/>

上記のステップは、次のアクションを順番に実行します。

  • SocketListener Java クラスを実行します。この SocketListener Java クラスは、定義済みのポートをリッスンするように設定されています。また、-sf スイッチを使って同期化ファイル (この例では sync_file) を作成します。

  • Synchronize Java クラスを実行します。最初のステップに runInBackground="true" 属性がある点に注意してください。このことは、次のステップが、前のステップの終了を待たずに実行できることを意味します。この属性の設定は必要です。なぜなら、SocketListener は、リスニングが停止するまで完了しないからです。SocketListener は、初期化して結果を受け取る準備ができると、run_synchronization ステップが完了して test_exec が実行できるよう、同期化ファイル (この例では sync_file) を作成します。このことは、適切にリスニング エージェントを初期化することなくテスト用実行モジュールが起動するのを防止します。リスニング エージェントを適切に初期化しなければ、テスト結果が失われます。

  • run_test_exec ステップが開始し、テスト用実行モジュールが実行されます。テスト用実行モジュールは SocketListener に接続して、 TCP/IP プロトコルを介して結果を送信します。
  • 送信が終了すると、SocketListener は .tlog ファイル (テスト情報ファイル) および .clog ファイル (カバレッジ情報ファイル) を作成します。別の同期化ファイル (sync_file.final) は、すべてが完了し、結果を読むことができることを同期化ステップに通知します。

外部組込みデバッグ モードの選択

外部組込みデバッグ モードの選択は、テスト フローを直接編集することによってのみ可能です。最初の <RunnableExecution> セクションの開始位置の近くで、他のパブリッシュされないプロパティの間に次の行を挿入します。

<SetProperty key="emb_dbg" value="true" />

たとえば、外部組込みモードがサポートされる環境向けのビルトイン テスト コンフィギュレーションを参照してください。

外部組込みデバッグ モードについては 「テスト ケースのデバッグ」を参照してください。

テストのエントリ ポイント関数の変更

ENTRY_POINT マクロは、エントリ ポイントのテストを制御します。デフォルトでは main() が呼び出されます。ただし、テスト対象プログラムの他のポイントからしかテストを呼び出せない場合や、特別な方法でテストを呼び出す必要がある場合もあります。次のマクロを使ってテストの呼び出し方を制御できます。

名前説明
CPPTEST_EPT_mainint main(int, char*[]) をエントリ ポイントとして使用します。
CPPTEST_EPT_wmainint wmain(int, wchar_t*[]) エントリ ポイントとして使用します。
CPPTEST_EPT_WinMainint WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPSTR, int) をエントリ ポイントとして使用します。
CPPTEST_EPT_WinMainint WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) をエントリ ポイントとして使用します。
CPPTEST_EPT_void_mainvoid main(int, char*[]) をエントリ ポイントとして使用します。
CPPTEST_EPT_main_no_argsint main(void) をエントリ ポイントとして使用します。
CPPTEST_EPT_void_main_no_argsvoid main(void) をエントリ ポイントとして使用します。
CPPTEST_ENTRY_POINT_C_LINKAGEC++ コードとしてコンパイルした場合に、main 関数の宣言の先頭に extern "C" を追加します。


また、CPPTEST_ENTRY_POINT マクロを定義することもできます。CPPTEST_ENTRY_POINT マクロを定義した場合、生成される main 関数は次のようになります。

    CPPTEST_ENTRY_POINT_RETURN_TYPE 
CPPTEST_ENTRY_POINT(CPPTEST_ENTRY_POINT_ARGS)
{
	CppTest_Main(CPPTEST_ENTRY_POINT_ARGC, CPPTEST_ENTRY_POINT_ARGV); 
	CPPTEST_ENTRY_POINT_RETURN_STATEMENT
}

CPPTEST_ENTRY_POINT_RETURN_TYPE, CPPTEST_ENTRY_POINT_ARGS、 CPPTEST_ENTRY_POINT_ARGC, CPPTEST_ENTRY_POINT_ARGV、および CPPTEST_ENTRY_POINT_RETURN_STATEMENT は、次のデフォルト値を持ちます。これらのデフォルト値は再定義することができます。

名前値
CPPTEST_ENTRY_POINT_RETURN_TYPEint
CPPTEST_ENTRY_POINT_ARGSvoid
CPPTEST_ENTRY_POINT_ARGC0
CPPTEST_ENTRY_POINT_ARGV0
CPPTEST_ENTRY_POINT_RETURN_STATEMENTreturn 0;

CPPTEST_ENTRY_POINT_DEFINED マクロを定義することもできます。このマクロを定義すると、main ルーチンは生成されません。この場合、テスト ケースを実行するために CppTest_Main(0, 0) 関数を呼び出す必要があります。 

CppTest_Main(0, 0) の呼び出しがあるソース ファイルには、cpptest.h ファイルをインクルードする必要があります。また、単体テストの最中に呼び出される関数から CppTest_Main(0, 0) を呼び出してはいけません。CppTest_Main(0, 0) が無限に呼び出されてループが発生します。 

PARASOFT_CPPTEST マクロを使って、ソース ファイルに対する変更を必ずコントロールしてください。例:

#ifdef PARASOFT_CPPTEST 
#include "cpptest.h"
#endif
...
#ifdef PARASOFT_CPPTEST
    CppTest_Main(0, 0); 
#endif

これらのマクロは、プロジェクト プロパティの [ビルド設定] の [コンパイラ オプション] フィールドで設定することができます。


プロジェクト オプションの詳細については 「プロジェクトとファイルのオプション設定」を参照してください。

テスト実行フロー 定義のカスタマイズ例

次のコードは、Windows ホスト ベースのテストのためのテスト実行フローのサンプルです。

<?xml version="1.0" encoding="UTF-8"?>
<FlowRecipeTemplate toolName="C++test" formatVersion="1.0">
	<Name>Default host-based unit testing</Name>
 
	<RunnableExecution>
 
	<SetProperty key="stub_config_file" value="${cpptest:testware_loc}/stubconfig.xml" />
	<SetProperty key="stub_config_header_file" value="${cpptest:testware_loc}/cpptest_stubconfig.h" />
 
	<TestCaseFindingStep
		testSuiteConfigFile="${cpptest:testware_loc}/testsuites.xml" allowNoTestCasesRun="false"
	/>
 
	<PrecompileStep />
		<AppendIncludedTestCases />
		<HarnessInstrumentationStep /> 
		<ReadStaticCoverageStep />
		<SendStaticCoverageStep />
		<UserStubsInstrumentationStep />
		<ReadSymbolsDataStep /> 
		<LsiStep />
		<ReadLsiConfigStep />
 
	<AnalyzeMissingDefinitions stopOnUndefined="true" generateS-tubs="false" />
	
	<ConfigureStubs />
 
	<CreateStubConfigHeader />
 
	<TestRunnerGenerationStep
		testSuiteConfigFile="${cpptest:testware_loc}/testsuites.xml"
		testrunnerCFile="${cpptest:testware_loc}/cpptest_testrunner.c"
		testrunnerCppFile="${cpptest:testware_loc}/cpptest_testrunner.cpp"
		testLogFile="${cpptest:testware_loc}/cpptest_results.tlog" 
		covLogFile="${cpptest:testware_loc}/cpptest_results.clog"
	/>
 
	<CompileStep />
 
	<LinkStep result="${cpptest:testware_loc}/${project_name}Test.exe"/>
 
	</RunnableExecution>
	     <ExecuteTestsExecution>
			<RemoveFileStep
				file="${cpptest:testware_loc}/cpptest_results.tlog"
			/>
 
	<CustomStep
		id="run_tests"
		label="Running tests..."
		commandLine=""${cpptest:testware_loc}/${project_name}Test.exe" --start-after=${cpptestprop-erty:test_case_start_number}"
		workingDir="${cpptest:test_exec_work_dir}"
		result="${cpptest:testware_loc}/cpptest_results.tlog" 
		timeoutTrackFile="${cpptest:testware_loc}/cpptest_results.tlog" 
		timeoutInfoProperty="test_exec_timeouted"
		runInDebugger="${cpptest:run_in_debugger}"
	/>
 
	<ReadTestLogStep
		testLogFile="${cpptest:testware_loc}/cpptest_results.tlog" timeoutInfoProperty="test_exec_timeouted"
	/>

	<ReadDynamicCoverageStep
		covLogFile="${cpptest:testware_loc}/cpptest_results.clog"
	/>
 
	   </ExecuteTestsExecution>
		
		   <RunnableExecution>
				     <ClearTempCoverageData />
							</RunnableExecution>
</FlowRecipeTemplate>

注意

  • runInBackground は、ステップをバックグラウンドで実行するかフォアグラウンドで実行するかを指定します。true に設定した場合、前のアクションが完了するのを待たずに、次のアクションが直ちに実行されます。false に設定した場合、次のアクションが開始するには、実行中のプロセスが終了する必要があります。デフォルト値は false です。

カスタム (クロス) コンパイラ定義を正しく追加し、ビルド済みホスト C/C++test ランタイム ライブラリをクロス コンパイル済みのターゲット固有ライブラリで置き換えた場合 ( 「カスタム コンパイラを使用するテストの設定」を参照)、C/C++test はほとんどすべてのアクションを正常に実行できるはずです。ただし、テスト用実行モジュールの起動およびテスト ログ ファイルのロードのステップは除きます。これらのステップを下記に記述します。

<CustomStep
id="run_tests"
label="Running tests..."
commandLine=""${cpptest:testware_loc}/${project_name}Test.exe"" workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.tlog"
runInBackground="false"
timeoutTrackFile="${cpptest:testware_loc}/cpptest_results.tlog"
/>
<ReadTestLogStep
testLogFile="${cpptest:testware_loc}/cpptest_results.tlog"
/>
<ReadDynamicCoverageStep
covLogFile="${cpptest:testware_loc}/cpptest_results.clog"
contextID=""
/>

おそらく、これらのステップを組込み環境に適したステップで置き換える必要があるでしょう。たとえば、ターゲットが Embedded Linux ベースの Power PC の基板であり、FTP はサポートするがリモート実行はサポートしていないものとします。rsh などのユーティリティは使用できません。この場合、一般的なテスト スキーマは次のようになります。

  1. テスト用実行モジュールを用意し、クロス ビルドを実行します。この処理は、クロス コンパイラを使って、デフォルトのアクションによって処理されます。
  2. FTP を使って、ターゲットの基板にテスト用実行モジュールをデプロイします。
  3. テストの実行が完了するのを待ちます。テスト用実行モジュールは、ターゲットのエージェントによって起動されます。
  4. FTP を使ってテスト結果をダウンロードします。

たとえば、このスキーマの実装例を考えてみましょう。

次のコードが既存のステップである場合：

<CustomStep
id="run_tests"
label="Running tests..."
commandLine=""${cpptest:testware_loc}/${project_name}Test"" workingDir="${cpptest:testware_loc}"
result="${cpptest:testware_loc}/cpptest_results.tlog" runInBackground="false"
timeoutTrackFile="${cpptest:testware_loc}/cpptest_results.tlog"
/>

次のようになるでしょう。

<CustomStep
id="deploy_test"
label="Deploying tests..."
commandLine=""/home/machine/user/cptests/helper/Store.py${project_name}Test""
workingDir="${cpptest:testware_loc}"
/>
<CustomStep
Customizing the Test Flow 341
id="sleep"
label="Waiting for test execution..." 
commandLine="sleep 30" 
workingDir="${cpptest:testware_loc}" 
result="cpptest_results.tlog" 
runInBackground="false"
/>
  • FTP 転送は、ヘルパー python スクリプトを使って自動化しています。このスクリプトについては本セクションの最後で説明します。

テスト実行のフローが sleep ステップに達したとき、テスト用実行モジュールはすでにターゲットの基板にデプロイされているはずです。sleep コマンドは同期化のために必要です。同期化によって、次のステップであるテスト結果のダウンロードがテストの完了前に開始するのを防ぎます。 

実際の稼動環境では、もっと正確な同期の実装が必要でしょう (たとえば、テスト実行が終了した後にファイル マーカーを作成してそれを利用するなど)。ここでは単純に sleep コマンドを使用して、ターゲット プラットフォームの結果にアクセスしようとする前にフローの実行を停止します。ターゲット プラットフォーム上には、アップロードされるテスト用実行モジュールを待って起動する単純なエージェントが必要です。サンプル スクリプトを次に記載します。

#!/bin/bash
while [ 1 ]
do
if [ -e *Test ]; then
# Give it some time to finish upload...
# test executable transfer may be in progress
echo "Found test executable, waiting for upload to be finished..." sleep 10
echo "Cleaning up before tests..."
rm results.*log
echo "Adding exe perm .... to *Test"
chmod +x *Test
# execute
echo "Executing *Test"
./*Test
# Remove test executable
echo "Removing *Test"
rm -f ./*Test
else
echo "Test executable not detected ..." fi
echo "Sleeping..."
sleep 3
done

繰り返しになりますが、同期化は実装されていません。特定のパターンがファイル システムに出現するのを探すだけです。パターンが出現すると、 アップロードの完了をさらに待ちます (この処理はアップロードの完了後にホスト サイドでファイル マーカーを作成して置き換えることができます)。次に、テスト用実行モジュールが起動し、テスト結果ファイル results.tlog およびカバレッジ結果ファイル results.clog が作成されます。これらの結果ファイルは、ホスト マシンにダウンロードして C/C++test にロードする必要があります。テスト実行フロー定義をさらに変更する必要があります。ログの読み取りのステップに進みます。

<ReadTestLogStep
testLogFile="${cpptest:testware_loc}/cpptest_results.tlog" />
<ReadDynamicCoverageStep
covLogFile="${cpptest:testware_loc}/cpptest_results.clog" contextID=""
/>

次のコードは、ターゲット プラットフォームから結果をダウンロードするステップの例です。

<CustomStep
id="results_dwl"
label="downloading tests results..."
commandLine=""/home/machine/user/cptests/helper/Get.py cpptest_results.tlog""
workingDir="${cpptest:testware_loc}"
result="cpptest_results.tlog"
runInBackground="false"
/>
<CustomStep
id="coverage_dwl"
label="downloading coverage results..."
commandLine=""/home/machine/user/cptests/helper/Get.py cpptest_results.clog""
workingDir="${cpptest:testware_loc}"
result="cpptest_results.clog"
runInBackground="false"
/>

このセットアップによって、ターゲット デバイスでの単体テストの完全なテスト ループを自動的に実行できます。開発環境によって、このサンプル スクリプトのさまざまなバリエーションを適用できます。 

FTP 認証スクリプトのサンプル

FTP 操作を認証するPython スクリプトのサンプル ファイルです。

Store.py

#!/usr/bin/python
 
import sys
print "Argv = ", sys.argv
from ftplib import FTP
ftp = FTP('10.9.1.36', 'user', 'pass') ftp.set_debuglevel(1)
print ftp.getwelcome()
file = open(sys.argv[1], "rb")
try:
	     ftp.storbinary("STOR %s" % sys.argv[1], file)
finally:
	     file.close()      
		ftp.quit()

Get.py

#!/usr/bin/python
 
import sys
print "Argv = ", sys.argv 
if len(sys.argv) < 2:
     print "Too few arguments"
from ftplib import FTP
ftp = FTP('10.9.1.36', 'user', 'pass') ftp.set_debuglevel(1)
print ftp.getwelcome()
file = open(sys.argv[1], "wb")
try:
     ftp.retrbinary("RETR %s" % sys.argv[1], file.write)
finally:
     file.close() 
ftp.quit()

テスト実行フローの説明とサンプル

実行を制御する要素

これらは、FlowRecipeTemplate ドキュメント ルートを除けば各テスト実行フローの最上位レベルの要素です。これらの要素は実行フロー ステップ (コマンド) のコンテナーです。実行フロー ステップは、そのコンテキストの内部に置く必要があり、順番に実行する必要があります。ただし、ネストすることはできません。新しい要素を置くには、その前の要素をクローズする必要があります。

RunnableExecution

含まれるコマンドを無条件に実行します。

例:

<RunnableExecution>
    <Echo msg="Hello world!" /> 
</RunnableExecution>"

ConditionalExecution

含まれるコマンドを条件つきで実行します。テスト値が C/C++test 実行フロー変数を含む場合に役立ちます。実行フロー変数については 「変数」 を参照してください。

属性: 

  • value - テスト値 (テストする値)
  • equals - テスト値が一致しなければならない比較値。notEquals と同時に使用することはできません。
  • notEquals - テスト値が一致してはいけない比較値。equals と同時に使用することはできません。

例:

 <ConditionalExecution value="${cpptest:os}" equals="unix">
     <Echo msg="This is UNIX-like OS." /> 
</ConditionalExecution>"

ExecuteTestsExecution

すべてのテスト ケースが実行されるまで、ループ中に含まれるコマンドを実行します。この要素が有効で正しいのは、要素中にテスト実行ステップ (テスト用実行モジュールを起動する CustomStep) があり、その後に ReadTestLogStep が続く場合だけです。${cpptestproperty:test_case_start_number} 変数の中身は自動的に更新され、テスト用実行モジュールの '--start-after=' パラメーターに渡されます。

例:

Example
<ExecuteTestsExecution>
    <CustomStep commandLine=""${cpptest:testware_loc}/
	${project_name}Test.exe" --start-after=${cpptestprop-erty:test_case_start_number}"
...other attributes... /> 
    <ReadTestLogStep testLogFile="${cpptest:testware_loc}/cpptest_results.tlog" />
</ExecuteTestsExecution>"

コマンド

AnalyzeMissingDefinitions

見つからないシンボルに関する情報を解析するための内部的なステップです。また、属性の設定によって、見つからないシンボルに対して自動的にスタブを生成することもできます。スタブを生成した後でも見つからないシンボルが残っている場合、テスト コンフィギュレーション ダイアログの [実行] > [シンボル] パネルの [未解決シンボルが検出された場合は実行を中断する] オプションがオンに設定されていれば、実行フローは中止されます。

属性:

  • generateStubs -- true に設定した場合、見つからないシンボルに対して自動スタブが生成されます。デフォルトでは、false に設定されています。
  • generateUserStubs -- true に設定した場合、スタブ ウィザードが開いて見つからないシンボルのユーザー スタブを定義できるようになります。デフォルトでは、false に設定されています。

例:

     <AnalyzeMissingDefinitions generateStubs="true" />

AppendIncludedTestCases

インクルードされたテスト スイート ファイルと適切なプロジェクト ソース ファイルをバンドルする内部的なステップです。

例:

      <AppendIncludedTestCases />

ClearTempCoverageData

一時的な静的および動的カバレッジ データを消去するための内部的なステップです。後で使用するために静的カバレッジ データを保存しておく必要がない場合、このステップを実行フローの最後に組込みます。たとえば Build test executable と Read test results など、連続して実行される 2 つの実行フローの記述がある場合、2 番目の実行フローの最後にだけ ClearTempCoverageData ステップを組込みます。

例:

     <ClearTempCoverageData />

CompileStep

インストゥルメントされたソース ファイルをテスト実行モジュールにリンクできるようにコンパイルする内部的なステップです。

例:

     <CompileStep />

ConditionalStop

与えられた条件を満たすとき、あるいは条件に反するとき (どちらであるかは属性の設定によります) にテスト実行フローを中止します。

非推奨 - このコマンドは、今後のバージョンの C/C++test で削除される予定です。 ConditionalExecution および無条件の Stop を組み合わせて使用してください。

属性:

  • property -- チェック対象の実行フロー プロパティ名
  • equals -- 指定された値とプロパティ値が等しい場合に実行が中止されます。この属性は任意です。
  • notEquals -- 指定された値とプロパティ値が異なる場合に実行が中止されます。この属性は任意です。

例:

     <ConditionalStop property="test_exec_timeouted" equals="true" />

ConfigureStubs

スタブ コンフィギュレーション XML ファイルを作成する内部的なステップです。ファイルが作成される場所は stub_config_file 実行フロー プロパティによって決定されます。

例:

     <ConfigureStubs />

CustomStep

外部実行モジュールを実行します。

属性:

  • commandLine -- 実行するコマンドラインを定義します。
  • workingDir -- 作成されたプロセスの作業ディレクトリを定義します。
  • runInBackground -- true に設定した場合、プロセスは非同期で実行されます。この属性は任意です。デフォルトでは、false に設定されています。
  • runInDebugger -- true に設定した場合、プロセスはテスト コンフィギュレーションで設定されたとおりにデバッガーを実行します。この属性は任意です。デフォルトでは、false に設定されています。
  • okExitCode -- この属性を指定した場合、プロセスの終了コードがチェックされ、失敗の場合にテスト実行フローが中止されます。この属性は任意です。
  • stdIn -- この属性を指定した場合、設定したファイルの内容がプロセスの標準入力として使用されます。この属性は任意です。
  • stdOut -- この属性を指定した場合、設定したファイルにプロセスの標準出力が書き込まれます。この属性は任意です。
  • stdErr -- この属性を指定した場合、設定したファイルにプロセスのエラー出力が書き込まれます。この属性は任意です。
  • responseFileSupported -- @file で指定したレスポンス ファイルからのコマンドライン パラメーターの読み込みをプロセスがサポートするかどうかを指定します。サポートする場合、プロセスのコマンドラインが最大の長さ (com.parasoft.xtest.common.process.maxcmdlength Java パラメーターで指定されます。デフォルトは 32000) を超えるとき、コマンドライン パラメーターはレスポンス ファイルによってプロセスに渡されます。この属性は任意です。デフォルトでは、false に設定されています。
  • dependencyFiles -- プロセスの依存ファイルを定義します。この属性は result 属性とともに使用します。コマンドラインが前回の実行時と変わらず、また結果ファイルがすべての依存ファイルよりも新しい場合、ステップは "最新" であると見なされてスキップされます。この属性は任意です。
  • result -- プロセスの結果ファイルを定義します。この属性は result 属性とともに使用します。コマンドラインが前回の実行時と変わらず、また結果ファイルがすべての依存ファイルよりも新しい場合、ステップは "最新" であると見なされてスキップされます。この属性は任意です。
  • id -- ステップの識別子を指定します。
  • label -- ステップのラベルを指定します。ラベルは C/C++test のコンソールに表示されます。
  • bypassConsole -- true に設定した場合、プロセスの出力は C/C++test コンソールに表示されません。この属性は任意です。デフォルトでは、false に設定されています。
  • timeoutTrackFile -- この属性を指定した場合、テスト コンフィギュレーションで設定されたタイムアウトが実行モジュールに適用されます。指定されたファイルを定期的にチェックし、タイムアウトより長い期間変更されていない場合、プロセスは中止されます。この属性は任意です。
  • timeoutInfoProperty -- タイムアウトが発生した場合に true に設定するテスト ユニット プロパティ名を指定します。この属性は任意です。

例:

<CustomStep
	id="ctdt_nm"
	label="CTDT Generation - extracting symbols..."
	commandLine=""${cpptestproperty:nm}" -g ${cpptest:test_objects_quoted}"
	workingDir="${cpptest:testware_loc}"
	stdOut="${cpptest:testware_loc}/ctdt_nm.out" 
	result="${cpptest:testware_loc}/ctdt_nm.out" 
	bypassConsole="true"
	dependencyFiles="${cpptest:test_objects_quoted}"
/>

CreateStubConfigHeader

インストゥルメントされたソースからインクルードされるスタブ コンフィギュレーション ヘッダー ファイルを生成する内部的なステップです。ヘッダーが作成される場所は stub_config_header_file 実行フロー プロパティによって決定されます。 

例:

     <CreateStubConfigHeader />

Echo

与えられたメッセージを C/C++test コンソールまたはファイルに出力します。

 属性:

  • msg -- 表示するメッセージを定義します。
  • label -- C/C++test コンソールに表示するフロー ステップのラベルを定義します。
  • file -- この属性を指定した場合、コンソールではなく指定されたファイルにメッセージが出力されます。この属性は任意です。

例:

     <Echo msg="Hello world!"/>

HarnessInstrumentationStep

プロジェクトのソース ファイルをインストゥルメントする内部的なステップです。

例:

     <HarnessInstrumentationStep />

LinkStep

事前に準備されたオブジェクト ファイルを使用してテスト実行モジュールをリンクします。

属性:

  • result -- テスト実行モジュール ファイルを出力する場所を指定します。
  • linker -- この属性を指定した場合、指定されたリンカー実行モジュールが、プロジェクト プロパティで定義された物の代わりに使用されます。  この属性は任意です。
  • linkerCmdLine -- この属性を指定した場合、指定されたリンカー コマンドライン パターンが、プロジェクト プロパティで定義された物の代わりに使用されます。この属性は任意です。

例:

      <LinkStep result="${cpptest:testware_loc}/${project_name}Test.exe" />

LsiStep

使用されているシンボルおよび使用可能なシンボルに関する情報を分析する内部的なステップです。

属性:

  • libSymFile - 読み込む外部シンボル リストがあるファイルを指定します。この属性の使用は任意です。「VxWorks DKM プロジェクトのテスト」を参照してください。

例:

     <LsiStep />

PrecompileStep

LSI 解析を行うためにプロジェクトのソース ファイルを事前コンパイルする内部的なステップです。

例:

      <PrecompileStep />

PrepareDataSources

マネージド データ ソースを C/C++test テスト実行ランタイム ライブラリがサポートするフォーマット (CSV またはソース コード配列を記述したファイル)に変換します。配列ソース ファイルはコンパイルされてテスト実行モジュールに組込まれます。

属性:

  • generationDir -- CSV または配列ソース ファイルが生成されるディレクトリです。この属性は任意です。デフォルトでは、現在のテスト ユニットの C/C++test テストウェア ディレクトリに設定されています。
  • inputDir -- 実際のテスト ケース実行でデータ ソースが読み込まれるとき、生成された CSV が使用される場所です。実際のテスト ケース実行がターゲット デバイス上で行われる場合、この場所は generationDir とは異なる可能性があります。その場合、生成された CSV ファイルを移動する必要があります。この属性は任意です。デフォルトでは、generationDir 属性の値が設定されます。
  • limit -- データ ソースの変換される最大行数を指定します。  0 未満の値はデータ ソースのすべての行が変換されることを意味します。この属性は任意です。デフォルトでは、-1 に設定されます。
  • type -- データを CSV ファイルに変換するかソース コード配列に変換するかを定義します。  "csv" または "array" を指定します。この属性は任意です。  デフォルトでは、csv に設定されています。

例:

     <PrepareDataSources limit="100" type="csv" />

ReadDynamicCoverageStep

テスト実行結果のカバレッジを保持するログ ファイルを読み込みます。

属性:

  • covLogFile -- 読み込むファイル。ワイルドカード '*' および '?' を使用して複数のファイルを一度に読み込むことができます。分割通信チャネル (「ファイル通信チャネル の実装」を参照) によって取得した一連のファイルを読み取るには、最初のファイル (例:'cpptest_results.clog') のパスを指定し、すべてのファイルが同じディレクトリに配置され、名前が元の名前付け規則 ('cpptest_results.clog'、'cpptest_results.clog.0001'、'cpptest_results.clog.0002' 等) に従っていることを確認します。残りのファイルは自動的に最初のファイルにマージされた後、削除されます。

ReadLsiConfigStep

LSI モジュールからデータを読み込む内部的なステップです。

例:

     <ReadLsiConfigStep />

ReadNativeCoverage

現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、そのカバレッジ情報を読み込みます。

例:

      <ReadNativeCoverage />

ReadNativeTestsLog

現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、そのテスト実行ログを読み込みます。

例:

      <ReadNativeTestsLog />

ReadStaticCoverageStep

プロジェクトのソース ファイルをインストゥルメントするときに準備された静的カバレッジ情報ファイルを読み込む内部的なステップです。

例:

     <ReadStaticCoverageStep />

ReadSymbolsDataStep

処理対象のソース ファイルで使用または定義されているシンボルに関する情報を読み込む内部的なステップです。

属性:

  • readStubsSymbols -- 処理されたスタブ ファイルの情報を読み込むかどうかを定義します。デフォルトでは、true に設定されています。

例:

    <ReadSymbolsDataStep />

ReadTestLogStep

テスト ログからテスト実行結果を読み込みます。

属性:

  • testLogFile -- 読み込むテスト ログ ファイルを指定します。分割通信チャネル (「ファイル通信チャネル の実装」を参照) によって取得した一連のファイルを読み取るには、最初のファイル (例:'cpptest_results.tlog) のパスを指定し、すべてのファイルが同じディレクトリに配置され、名前が元の名前付け規則 ('cpptest_results.tlog'、'cpptest_results.tlog.0001'、'cpptest_results.tlog.0002' 等) に従っていることを確認します。残りのファイルは自動的に最初のファイルにマージされた後、削除されます。

  • timeoutInfoProperty -- 内部的な属性です。テストの実行がタイムアウトのためにドライバーによって中止されたかどうかを判断するためにチェックするべきテスト実行フロー プロパティを定義します。test_exec_timeouted を設定します。
  • logTime -- コンソールにテスト ログ メッセージを表示する際の日付の書式を定義します。書式文字列ではすべての文字 (a-z および A-Z) はパターンとして扱われます。テキストはシングル クォーテーション (') で囲みます。2 つのシングル クォーテーション ('') は 1 つのシングル クォーテーションを表示します。次のパターンを使用できます。

    y    年
    M  月
    d   日
    a   am/pm
    H  時間 (0-23)
    h   時間 (1-12)
    m  分
    s   秒
    S   ミリ秒
    Z   RFC 822 タイム ゾーン

    パターン文字を繰り返すことによって最小桁数を指定できます。最小桁数に満たない数はゼロ埋めされます。年のパターンを 2 桁で指定すると (yy)、2 桁の年が使用されます。月のパターンで 3 文字以上を指定すると (MMM)、月を表す文字列が使用されます。2 文字以下の場合は数字が使用されます。この属性は任意です。

例:    

<ReadTestLogStep
	testLogFile="${cpptest:testware_loc}/cpptest_results.tlog" 
	timeoutInfoProperty="test_exec_timeouted"
	logTime="'Date': yy/MM/dd, 'Time': HH:mm:ss.SSS"
/>

RemoveFileStep

ファイル システムからファイルを削除します。

属性:

  • file -- 削除するファイルを定義します。ワイルドカード '*' および '?' を使用して複数のファイルを一度に削除できます。

例:

     <RemoveFileStep file="${cpptest:testware_loc}/*.clog" />

RunNativeTests

現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、それを実行します。

例:

     <RunNativeTests />

SendStaticCoverageStep

読み込んだすべてのカバレッジ情報をカバレッジ結果システムに渡す内部的なステップです。

例:

     <SendStaticCoverageStep/>

SetProperty

実行フロー プロパティを設定します。earch 属性と replace 属性で正規表現を使って、値を検索/置換することができます。テスト値が C/C++test の実行フロー変数を使用している場合、この属性は特に有効です。変数については「変数」を参照してください。

属性:

  • key -- 設定するプロパティの名前
  • value -- プロパティの設定値
  • search -- 値を検索する正規表現。この属性の指定は任意です。この属性の使用は任意です。
  • replace -- 発見された式を代替するテキスト。search 属性がある場合、replace 属性は必須です。

例 1:

<SetProperty key="stub_config_file" value="${cpptest:testware_loc}/stubconfig.xml" />

プレーンな値を "${cpptestproperty:stub_config_file}" に格納します。

例 2:

<SetProperty key="twl_mixed_path" value="${cpptest:testware_loc}" search="\\" replace="/" />

与えられた値についてスラッシュをバックスラッシュに置換し、結果を ${cpptestproperty:twl_mixed_path} に格納します。

Stop

実行フローを無条件に停止します。

TestCaseFindingStep

実行対象のテスト ケースのリストを保持する XML ファイルを準備するための内部的なステップです。XML ファイルは後に TestRunnerGenerationStep で使用されます。

属性:

  • testSuiteConfigFile -- 出力 XML ファイルを定義します。
  • allowNoTestCasesRun -- 実行対象のテスト ケースがない場合に実行フローを中止するかどうかを指定します。

例:

<TestCaseFindingStep

       testSuiteConfigFile="${cpptest:testware_loc}/testsuites.xml" allowNoTestCasesRun="false"

/>

TestRunnerGenerationStep

TestRunnerWithSocketsGenerationStep

テスト ケース実行のドライバーであるテスト ランナーのソース コードを準備します。指定された属性に応じて、テスト実行モジュールはログ ファイルを生成するか、または結果をソケット接続で送信します。

属性:

  • testrunnerCFile -- テスト ランナー ファイルの場所 (プロジェクトに C 言語のコードだけが含まれる場合)
  • testrunnerCppFile -- テスト ランナー ファイルの場所 (プロジェクトに C++ 言語のコードが含まれる場合)
  • testSuiteConfigFile --  実行するテスト ケースのリストを保存した XML ファイル。このファイルは TestCaseFindingStep ステップで準備されます。
  • testLogFile -- テスト実行モジュールが実行ログ ファイルを作成する場所を定義します。ソケット接続を使用する場合は省略できます。
  • covLogFile -- テスト実行モジュールがカバレッジ ログ ファイルを作成する場所を定義します。ソケット接続を使用する場合は省略できます。
  • resultsHost -- テスト実行結果を待機しているソケット リスナーのホストを定義します。
  • testLogPort -- ソケット リスナーがテスト実行結果を待機するポートを定義します。ファイル通信を使用する場合は省略できます。
  • covLogPort --  ソケット リスナーがテスト カバレッジ結果を待機するポートを定義します。ファイル通信を使用する場合は省略できます。
  • ファイル通信を使用する場合、ランタイムによってテスト実行ログおよびカバレッジ ログ ファイルを上書きするのではなく、新しい情報を追加するかどうかを定義します。デフォルトでは、true に設定されています。

UserStubsInstrumentationStep

スタブ ファイルをインストゥルメントする内部的なステップです。

例:

     <UserStubsInstrumentationStep />

変数

実行フローの記述は XML 文書であるため、フロー ステップの属性として使用されるすべての値は有効な XML 文字列でなければなりません。つまり、" や < などの特殊文字はすべて &quot; や &lt; などのエスケープ シーケンスに置き換える必要があります。

フロー ステップ属性で使用できる変数は以下のとおりです。

  • ${workspace_loc} -- ワークスペースの場所
  • ${project_name} -- テスト対象プロジェクト名
  • ${project_loc} -- テスト対象プロジェクトの場所
  • ${project_loc:PROJECT_NAME} -- PROJECT_NAME プロジェクトの場所
  • ${resource_loc:RESOURCE_PATH} -- RESOURCE_PATH で指定したリソースの場所
  • ${cpptest:testware_loc} -- 現在のテスト ユニットの C/C++test テストウェアの場所
  • ${cpptest:cfg_dir} -- C/C++test インストール ディレクトリ内の C/C++test コンフィギュレーション ファイルの場所
  • ${cpptest:utils_dir} -- C/C++test インストール ディレクトリ内の C/C++test ユーティリティの場所
  • ${cpptest:uid} -- ユニークな識別子
  • ${cpptest:add_file_ext} -- 追加で作成されるソース ファイルの拡張子。プロジェクトのソース ファイルの拡張子に基づいて推定されます。
  • ${cpptest:os} -- OS の種類。"windows" または "unix" (solaris または linux)。
  • ${cpptest:run_in_debugger} -- テスト コンフィギュレーションの [デバッガーでテストを実行する] オプションの値に応じて true または false の値を取ります。
  • ${cpptest:test_exec_work_dir} -- テスト コンフィギュレーションで指定されたテスト実行モジュールの作業ディレクトリ
  • ${cpptest:test_object_files} -- テスト実行モジュールを構成するオブジェクト ファイルのカンマ区切りのリスト
  • ${cpptest:test_objects_quoted} -- テスト実行モジュールを構成するオブジェクト ファイルのスペース区切りのリスト。各ファイルは引用符 (") で囲みます。
  • ${cpptest:test_objects_esc_quoted} -- テスト実行モジュールを構成するオブジェクト ファイルのスペース区切りのリスト。各ファイルはエスケープされた引用符 (\") で囲みます。

FileSynchronizeStep

特定のファイルが作成されるのを待つ間、または指定した時間ファイルが非アクティブである間、実行フローを停止します。このステップの振る舞いは、以下で説明する属性によって変わります。

属性:

  • fileSync - このステップが同期化しようとするファイルへの完全なパス。
  • timeout - ファイル (fileSync 属性で指定) が作成されるのを待つ時間長をミリ秒で指定します。タイムアウト時間までにファイルが作成されない場合、実行フローは通常と同じように再開します。この属性は、下記の fileInactiveTimeout 属性よりも優先されます。この属性と fileInactiveTimeout 属性を組み合わせて使用することはできません。
  • fileInactiveTimeout - fileSync 属性で指定したファイルの非アクティブ状態を待つタイムアウト時間をミリ秒で指定します。これは、ファイルが最後に変更された時刻を継続的にチェックすることで実施されます。指定した時間ファイルが非アクティブであることを C/C++test が検出すると、実行フローが再開します。

例:

以下の設定は、10 秒間実行フローを停止するか、または指定した場所に sync_file.txt ファイルが出現するまで実行フローを停止します。

<FileSynchronizeStep
	fileSync="${cpptest:testware_loc}/sync_file.txt" 
	timeout="10000"
/>

以下の設定は、cpptest_results.tlog ファイルのタイムスタンプを追跡します。10 秒間ファイルが 非アクティブであることを C/C++test が検出すると、実行フローが再開します。

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

Need assistance? Visit our support page