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

このセクションの内容

テスト実行フローとは

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

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

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

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

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

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

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

プロパティテーブルを右クリックして次のショートカットメニューを使用できます。
- デフォルト値に戻す
- ファイルの場所を挿入
- ディレクトリの場所を挿入
プロパティテーブルに現在表示されていないテストフロープロパティを変更するには、次の操作を行います。たとえば、頻繁に変更する予定のプロパティなどの場合です。
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 文書が検証されます。検証中に問題が発見された場合、その問題がレポートされます。
[適用] ボタンをクリックしてから [OK] をクリックして変更後のテストコンフィギュレーションを保存します。

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

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

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

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

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

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

[Parasoft] メニューの [テストコンフィギュレーション] をクリックします。
[ビルトイン] > [Unit Testing] を展開します。
[Build Test Executable] テストコンフィギュレーションを右クリックし、ショートカットメニューの [複製] をクリックします。
[ユーザー定義] > [Build Test Executable] を選択します。
テストコンフィギュレーションの名前を Build <target> Executable などに変更します (<target> の部分にはターゲット名を入れてください)。
[実行] > [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
```
テスト実行フローを編集します。
1. [実行] タブの [全般] タブをクリックします。
2. [テスト実行フロー] から [カスタムフロー] を選択して [編集] ボタンをクリックします。
3. 既存のテスト実行フローを [利用可能なビルトインテスト実行フロー] から選択して [XML を再現] ボタンをクリックします。表示された XML ファイルを編集します。フロー定義の変更の詳細については、「テスト実行フロー定義のカスタマイズ例」を参照してください。
[OK] ボタンをクリックしてファイルを保存します。XML 文書が検証されます。検証中に問題が発見された場合、その問題がレポートされます。
[適用] ボタンをクリックしてから [OK] をクリックして変更後のテストコンフィギュレーションを保存します。

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

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

適切なユーザー定義テストコンフィギュレーションを実行して、テスト用実行モジュールをビルドします。
- 必要に応じて、個別のニーズに合わせてこのテストコンフィギュレーションのテスト実行フローを変更します。ほとんどの場合、異なる点は、生成される実行ファイルの拡張子、そして特定のネットワーク関連の値 (ポートや 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 を使用する点に注意してください。
テスト用実行モジュールをターゲットデバイスにデプロイします。
- このステップは、常に自動化できるとは限りません。システムが自動デプロイをサポートしていない場合、ターゲットデバイスにユーザーが自分で実行モジュールをデプロイしなければならないことがあります。システムが自動デプロイをサポートしている場合、システムが提供する FTP プロトコルや同期化ツール、その他の手段を利用できます。
ソケット通信チャネルを使って結果を収集するように構成した、C++test SocketListener ツールを実行します。
- このステップ 3 およびステップ 4 の詳細については、下記の「ステップ 3 とステップ 4 のテスト実行フロー例」を参照してください。
- 実行された SocketListener ツールは、指定のポートに結果が到着するのを待機し始めます。
テスト用実行モジュールを起動します。初期化の後、テスト用実行モジュールは 2 つのポートをオープンし、C++test にデータを送信しようとします。このデータはリスニングエージェントによって収集され、今後の解析のために 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_main	int main(int, char*[]) をエントリポイントとして使用します。
CPPTEST_EPT_wmain	int wmain(int, wchar_t*[]) エントリポイントとして使用します。
CPPTEST_EPT_WinMain	int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPSTR, int) をエントリポイントとして使用します。
CPPTEST_EPT_WinMain	int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) をエントリポイントとして使用します。
CPPTEST_EPT_void_main	void main(int, char*[]) をエントリポイントとして使用します。
CPPTEST_EPT_main_no_args	int main(void) をエントリポイントとして使用します。
CPPTEST_EPT_void_main_no_args	void main(void) をエントリポイントとして使用します。
CPPTEST_ENTRY_POINT_C_LINKAGE	C++ コードとしてコンパイルした場合に、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_TYPE	int
CPPTEST_ENTRY_POINT_ARGS	void
CPPTEST_ENTRY_POINT_ARGC	0
CPPTEST_ENTRY_POINT_ARGV	0
CPPTEST_ENTRY_POINT_RETURN_STATEMENT	return 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="&quot;${cpptest:testware_loc}/${project_name}Test.exe&quot; --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++test ランタイムライブラリをクロスコンパイル済みのターゲット固有ライブラリで置き換えた場合 ( 「カスタムコンパイラを使用するテストの設定」を参照)、C++test はほとんどすべてのアクションを正常に実行できるはずです。ただし、テスト用実行モジュールの起動およびテストログファイルのロードのステップは除きます。これらのステップを下記に記述します。

<CustomStep
id="run_tests"
label="Running tests..."
commandLine="&quot;${cpptest:testware_loc}/${project_name}Test.exe&quot;" 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 などのユーティリティは使用できません。この場合、一般的なテストスキーマは次のようになります。

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

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

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

<CustomStep
id="run_tests"
label="Running tests..."
commandLine="&quot;${cpptest:testware_loc}/${project_name}Test&quot;" 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="&quot;/home/machine/user/cptests/helper/Store.py${project_name}Test&quot;"
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++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="&quot;/home/machine/user/cptests/helper/Get.py cpptest_results.tlog&quot;"
workingDir="${cpptest:testware_loc}"
result="cpptest_results.tlog"
runInBackground="false"
/>
<CustomStep
id="coverage_dwl"
label="downloading coverage results..."
commandLine="&quot;/home/machine/user/cptests/helper/Get.py cpptest_results.clog&quot;"
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++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="&quot;${cpptest:testware_loc}/
	${project_name}Test.exe&quot; --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++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++test のコンソールに表示されます。
bypassConsole -- true に設定した場合、プロセスの出力は C++test コンソールに表示されません。この属性は任意です。デフォルトでは、false に設定されています。
timeoutTrackFile -- この属性を指定した場合、テストコンフィギュレーションで設定されたタイムアウトが実行モジュールに適用されます。指定されたファイルを定期的にチェックし、タイムアウトより長い期間変更されていない場合、プロセスは中止されます。この属性は任意です。
timeoutInfoProperty -- タイムアウトが発生した場合に true に設定するテストユニットプロパティ名を指定します。この属性は任意です。

例:

<CustomStep
	id="ctdt_nm"
	label="CTDT Generation - extracting symbols..."
	commandLine="&quot;${cpptestproperty:nm}&quot; -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++test コンソールまたはファイルに出力します。

属性:

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

例:

<Echo msg="Hello world!"/>

HarnessInstrumentationStep

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

例:

<HarnessInstrumentationStep />

LinkStep

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

属性:

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

例:

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

LsiStep

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

属性:

libSymFile - 読み込む外部シンボルリストがあるファイルを指定します。この属性の使用は任意です。「Testing VxWorks DKM Projects」、「外部シンボルリストの作成」、および「外部 VxWorks イメージシンボルリストの生成」を参照してください。

例:

<LsiStep />

PrecompileStep

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

例:

<PrecompileStep />

PrepareDataSources

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

属性:

generationDir -- CSV または配列ソースファイルが生成されるディレクトリです。この属性は任意です。デフォルトでは、現在のテストユニットの 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++test 2.3/6.x からインポートしたネイティブテストが含まれている場合、そのカバレッジ情報を読み込みます。

例:

<ReadNativeCoverage />

ReadNativeTestsLog

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

例:

<RunNativeTests />

SendStaticCoverageStep

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

例:

<SendStaticCoverageStep/>

SetProperty

実行フロープロパティを設定します。earch 属性と replace 属性で正規表現を使って、値を検索/置換することができます。テスト値が 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 文字列でなければなりません。つまり、" や < などの特殊文字はすべて " や < などのエスケープシーケンスに置き換える必要があります。

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

${workspace_loc} -- ワークスペースの場所
${project_name} -- テスト対象プロジェクト名
${project_loc} -- テスト対象プロジェクトの場所
${project_loc:PROJECT_NAME} -- PROJECT_NAME プロジェクトの場所
${resource_loc:RESOURCE_PATH} -- RESOURCE_PATH で指定したリソースの場所
${cpptest:testware_loc} -- 現在のテストユニットの C++test テストウェアの場所
${cpptest:cfg_dir} -- C++test インストールディレクトリ内の C++test コンフィギュレーションファイルの場所
${cpptest:utils_dir} -- C++test インストールディレクトリ内の 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++test が検出すると、実行フローが再開します。

例:

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

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

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

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

Page tree

Customizing the Test Execution Flow

テスト実行フローとは

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

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

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

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

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

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

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

Store.py

Get.py

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

実行を制御する要素

RunnableExecution

ConditionalExecution

ExecuteTestsExecution

コマンド

AnalyzeMissingDefinitions

AppendIncludedTestCases

ClearTempCoverageData

CompileStep

ConditionalStop

ConfigureStubs

CustomStep

CreateStubConfigHeader

Echo

HarnessInstrumentationStep

LinkStep

LsiStep

PrecompileStep

PrepareDataSources

ReadDynamicCoverageStep

ReadLsiConfigStep

ReadNativeCoverage

ReadNativeTestsLog

ReadStaticCoverageStep

ReadSymbolsDataStep

ReadTestLogStep

RemoveFileStep

RunNativeTests

SendStaticCoverageStep

SetProperty

Stop

TestCaseFindingStep

TestRunnerGenerationStep

TestRunnerWithSocketsGenerationStep

UserStubsInstrumentationStep

変数

FileSynchronizeStep

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

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

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

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