このセクションでは、クロス コンパイラ テストのためのカスタム テスト実行フローを定義する方法について説明します。テスト実行フローを使って、たとえばクロス コンパイラを使ってテストをビルドした後、デプロイ、テスト実行、結果収集のためのプラットフォーム固有の処理を実行できます。
このセクションの内容
テストを実行するように設定されたテスト コンフィギュレーションを実行すると、一連のアクションが実行されます。そして通常、C/C++test GUI に単体テストの結果がロードされます。このアクションはテスト実行フロー ファイルで指定されています。テスト実行フロー ファイルは XML 形式のファイルであり、テスト コンフィギュレーションの一部として保存されます。テストを実行するすべてのビルトイン テスト コンフィギュレーションには、対応する定義済みテスト実行フローが存在します。
ホスト ベースのテストを目的として作成された定義済み実行フローを利用するだけでなく、C/C++test では、非標準の環境での作業を容易にするために、ユーザーがカスタム テスト実行フローを定義できます。
テスト実行フローのパラメーターは必要に応じてカスタマイズすることができます。テスト コンフィギュレーションの [実行] > [全般] の [実行の詳細] でカスタマイズします。
ビルトイン テスト コンフィギュレーションを利用して簡単にテスト実行フローを編集できます。ただし多くの場合、テスト実行フローを作成する必要はありません。
ユーザー定義テスト コンフィギュレーションのためのカスタム テスト実行フローを定義するには、次の操作を行います。

テスト フロー中のプロパティ定義を探します。プロパティ定義は次のような形式になっています。
<SetProperty key="property_key" value="property_default_value" |
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 属性はデフォルト値として使用されます。
テスト実行フローのカスタマイズは、テスト コンフィギュレーションと共に保存されます。
まず上記の「テスト実行フローのカスタマイズ」で説明したように、プロパティ リストを変更することを推奨します。さらにカスタマイズが必要な場合には、カスタム テスト実行フローを定義することができます。
カスタム テスト実行フロー定義は XML 形式のファイルであり、テスト コンフィギュレーションの一部として保存されます。そのため、チーム メンバー間で共有することができます。通常、カスタム テスト実行フロー定義には、非標準の環境で単体テストを実行するのに必要な手順を記述します。また、任意のコマンドライン ユーティリティを起動するためにカスタム テスト実行フロー定義を使用することもできます。実際、 カスタム テスト実行フロー定義には、C/C++test の内部アクションまたは OS でプロセスとして起動される外部ユーティリティを含めることができます。デフォルトのテスト実行フローは、次の方法で変更できます。
ユーザー定義テスト コンフィギュレーションのためのカスタム テスト実行フローを定義するには、次の操作を行います。

Build <target> Executable などに変更します (<target> の部分にはターゲット名を入れてください)。[実行] > [シンボル] タブをクリックし、[次の場所で発見されたファイルのシンボルも使用] チェックボックスをオフにします。
[次の場所で発見されたファイルのシンボルも使用] チェックボックスをオフにせずにテスト用実行モジュールをビルドすると、ビルド時に次のエラーが発生します。 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 |
TCP/IP ソケットを利用できる組込み環境では、 TCP/IP ソケットを使ってテスト実行フローを自動化するのが一般的です。ソケット通信チャネルを利用するテスト実行の一般的な流れは次のとおりです。
必要に応じて、個別のニーズに合わせてこのテスト コンフィギュレーションのテスト実行フローを変更します。ほとんどの場合、異なる点は、生成される実行ファイルの拡張子、そして特定のネットワーク関連の値 (ポートや IP 番号など) の設定だけです。
最初の部分 (TestRunnerWithSocketsGenerationStep) は、特定のネットワーク値 (プロパティ ファイルから取得された IP とポート番号) を使って、テスト フレームワークの実行を準備します。 2 番目の部分は、テスト用実行モジュールをコンパイルします。 最後の部分 (LinkStep) は、最終的なテスト用実行モジュールを得るために、リンカーを呼び出します (この例では $ {project_name}Test.foo ですが、ご使用のシステムに合わせて、拡張子を変更する必要があります)。 なお、デフォルトの TestRunnerGenerationStep ではなく TestRunnerWithSocketsGenerationStep を使用する点に注意してください。 |
<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"
/> |
上記のステップは、次のアクションを順番に実行します。
Synchronize Java クラスを実行します。最初のステップに runInBackground="true" 属性がある点に注意してください。このことは、次のステップが、前のステップの終了を待たずに実行できることを意味します。この属性の設定は必要です。なぜなら、SocketListener は、リスニングが停止するまで完了しないからです。SocketListener は、初期化して結果を受け取る準備ができると、run_synchronization ステップが完了して test_exec が実行できるよう、同期化ファイル (この例では sync_file) を作成します。このことは、適切にリスニング エージェントを初期化することなくテスト用実行モジュールが起動するのを防止します。リスニング エージェントを適切に初期化しなければ、テスト結果が失われます。
外部組込みデバッグ モードの選択は、テスト フローを直接編集することによってのみ可能です。最初の <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=""${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> |
|
カスタム (クロス) コンパイラ定義を正しく追加し、ビルド済みホスト 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 などのユーティリティは使用できません。この場合、一般的なテスト スキーマは次のようになります。
たとえば、このスキーマの実装例を考えてみましょう。
次のコードが既存のステップである場合:
<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"
/> |
|
テスト実行のフローが 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 操作を認証するPython スクリプトのサンプル ファイルです。
#!/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() |
#!/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>
<Echo msg="Hello world!" />
</RunnableExecution>" |
含まれるコマンドを条件つきで実行します。テスト値が C/C++test 実行フロー変数を含む場合に役立ちます。実行フロー変数については 「変数」 を参照してください。
属性:
例:
<ConditionalExecution value="${cpptest:os}" equals="unix">
<Echo msg="This is UNIX-like OS." />
</ConditionalExecution>" |
すべてのテスト ケースが実行されるまで、ループ中に含まれるコマンドを実行します。この要素が有効で正しいのは、要素中にテスト実行ステップ (テスト用実行モジュールを起動する CustomStep) があり、その後に ReadTestLogStep が続く場合だけです。${cpptestproperty:test_case_start_number} 変数の中身は自動的に更新され、テスト用実行モジュールの '--start-after=' パラメーターに渡されます。
例:
<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" />
インクルードされたテスト スイート ファイルと適切なプロジェクト ソース ファイルをバンドルする内部的なステップです。
例:
<AppendIncludedTestCases />
一時的な静的および動的カバレッジ データを消去するための内部的なステップです。後で使用するために静的カバレッジ データを保存しておく必要がない場合、このステップを実行フローの最後に組込みます。たとえば Build test executable と Read test results など、連続して実行される 2 つの実行フローの記述がある場合、2 番目の実行フローの最後にだけ ClearTempCoverageData ステップを組込みます。
例:
<ClearTempCoverageData />
インストゥルメントされたソース ファイルをテスト実行モジュールにリンクできるようにコンパイルする内部的なステップです。
例:
<CompileStep />
このステップはファイルからプロパティをロードします。
属性:
例:
<LoadProperties file="${cpptest:testware_loc}/settings.properties" />
このステップはファイルをコピーします。
属性:
例:
<CopyStep from="${project_loc}/source.file" to="${cpptest:testware_loc}/target.file" />
スタブ コンフィギュレーション XML ファイルを作成する内部的なステップです。ファイルが作成される場所は stub_config_file 実行フロー プロパティによって決定されます。
例:
<ConfigureStubs />
外部実行モジュールを実行します。
属性:
例:
<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}"
/> |
インストゥルメントされたソースからインクルードされるスタブ コンフィギュレーション ヘッダー ファイルを生成する内部的なステップです。ヘッダーが作成される場所は stub_config_header_file 実行フロー プロパティによって決定されます。
例:
<CreateStubConfigHeader />
与えられたメッセージを C/C++test コンソールまたはファイルに出力します。
属性:
例:
<Echo msg="Hello world!"/>
プロジェクトのソース ファイルをインストゥルメントする内部的なステップです。
例:
<HarnessInstrumentationStep />
事前に準備されたオブジェクト ファイルを使用してテスト実行モジュールをリンクします。
属性:
例:
<LinkStep result="${cpptest:testware_loc}/${project_name}Test.exe" />
使用されているシンボルおよび使用可能なシンボルに関する情報を分析する内部的なステップです。
属性:
libSymFile - 読み込む外部シンボル リストがあるファイルを指定します。この属性の使用は任意です。「VxWorks DKM プロジェクトのテスト」を参照してください。
例:
<LsiStep />
LSI 解析を行うためにプロジェクトのソース ファイルを事前コンパイルする内部的なステップです。
例:
<PrecompileStep />
マネージド データ ソースを C/C++test テスト実行ランタイム ライブラリがサポートするフォーマット (CSV またはソース コード配列を記述したファイル)に変換します。配列ソース ファイルはコンパイルされてテスト実行モジュールに組込まれます。
属性:
例:
<PrepareDataSources limit="100" type="csv" />
テスト実行結果のカバレッジを保持するログ ファイルを読み込みます。
属性:
covLogFile -- 読み込むファイル。ワイルドカード '*' および '?' を使用して複数のファイルを一度に読み込むことができます。分割通信チャネル (「ファイル通信チャネル の実装」を参照) によって取得した一連のファイルを読み取るには、最初のファイル (例:'cpptest_results.clog') のパスを指定し、すべてのファイルが同じディレクトリに配置され、名前が元の名前付け規則 ('cpptest_results.clog'、'cpptest_results.clog.0001'、'cpptest_results.clog.0002' 等) に従っていることを確認します。残りのファイルは自動的に最初のファイルにマージされた後、削除されます。
LSI モジュールからデータを読み込む内部的なステップです。
例:
<ReadLsiConfigStep />
現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、そのカバレッジ情報を読み込みます。
例:
<ReadNativeCoverage />
現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、そのテスト実行ログを読み込みます。
例:
<ReadNativeTestsLog />
プロジェクトのソース ファイルをインストゥルメントするときに準備された静的カバレッジ情報ファイルを読み込む内部的なステップです。
例:
<ReadStaticCoverageStep />
処理対象のソース ファイルで使用または定義されているシンボルに関する情報を読み込む内部的なステップです。
属性:
例:
<ReadSymbolsDataStep />
テスト ログからテスト実行結果を読み込みます。
属性:
testLogFile -- 読み込むテスト ログ ファイルを指定します。分割通信チャネル (「ファイル通信チャネル の実装」を参照) によって取得した一連のファイルを読み取るには、最初のファイル (例:'cpptest_results.tlog) のパスを指定し、すべてのファイルが同じディレクトリに配置され、名前が元の名前付け規則 ('cpptest_results.tlog'、'cpptest_results.tlog.0001'、'cpptest_results.tlog.0002' 等) に従っていることを確認します。残りのファイルは自動的に最初のファイルにマージされた後、削除されます。
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="${cpptest:testware_loc}/*.clog" />
現在のテスト ユニットに C/C++test 2.3/6.x からインポートしたネイティブ テストが含まれている場合、それを実行します。
例:
<RunNativeTests />
読み込んだすべてのカバレッジ情報をカバレッジ結果システムに渡す内部的なステップです。
例:
<SendStaticCoverageStep/>
実行フロー プロパティを設定します。earch 属性と replace 属性で正規表現を使って、値を検索/置換することができます。テスト値が C/C++test の実行フロー変数を使用している場合、この属性は特に有効です。変数については「変数」を参照してください。
属性:
例 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} に格納します。
実行フローを無条件に停止します。
実行対象のテスト ケースのリストを保持する XML ファイルを準備するための内部的なステップです。XML ファイルは後に TestRunnerGenerationStep で使用されます。
属性:
例:
<TestCaseFindingStep
testSuiteConfigFile="${cpptest:testware_loc}/testsuites.xml" allowNoTestCasesRun="false"
/>
テスト ケース実行のドライバーであるテスト ランナーのソース コードを準備します。指定された属性に応じて、テスト実行モジュールはログ ファイルを生成するか、または結果をソケット接続で送信します。
属性:
スタブ ファイルをインストゥルメントする内部的なステップです。
例:
<UserStubsInstrumentationStep />
実行フローの記述は XML 文書であるため、フロー ステップの属性として使用されるすべての値は有効な XML 文字列でなければなりません。つまり、" や < などの特殊文字はすべて " や < などのエスケープ シーケンスに置き換える必要があります。
フロー ステップ属性で使用できる変数は以下のとおりです。
特定のファイルが作成されるのを待つ間、または指定した時間ファイルが非アクティブである間、実行フローを停止します。このステップの振る舞いは、以下で説明する属性によって変わります。
属性:
例:
以下の設定は、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"
/> |