Version 1.0 2006/08/22 Application Note AN-JND-1-002
日本語版 Virsion 1.0J
Author(s) Stefan Krauß
Restrictions Public Document
Abstract 本アプリケーションは、CANoe テスト機能について基本的な概念について説明したものです。 目次 1.0 概要 ...3 2.0 CANoeを使用したテスト ...3 2.1 CANoeテスト コンセプト ...3 2.1.1 アーキテクチャ...3 2.1.2 テスト モジュールの設定...4 2.1.3 テスト結果 – 判定...5 2.2 テスト結果のレポート...6 2.2.1 概要...6 2.2.2 手動または自動で生成されたレポート情報...7 2.2.3 IDの使用...8 2.2.4 テスト ステップ ...8 2.2.5 テスト ステップによるCAPLプログラムのドキュメンテーション ...9 2.3 CAPLでのテスト ケースの作成 ...10 2.3.1 原理...10 2.3.2 CAPLテスト モジュールの設定 ...11 2.3.3 待機コマンド ...11 2.3.4 複雑な条件を含む待機コマンド ...13 2.3.5 テスト モジュールのイベント プロシージャ ...14 2.3.6 ユーザー定義のイベント ...14 2.3.7 シミュレーション解析用のCAPLとテスト用のCAPLの違い ...14 2.4 XMLテスト モジュールでのテスト ケースの定義 ...15 2.4.1 原理...15 2.4.2 XMLテスト モジュールの設定 ...16 2.4.3 テスト パターンの使用 ...18 2.4.4 XMLテスト モジュールとCAPLテスト モジュール...18 2.5 制約と条件 ...19 2.5.1 原理...19 2.5.2 あらかじめ定義されたチェックの使用 CAPLの場合 ...21 2.5.3 XMLの制約と条件...22 2.5.4 ユーザー定義のテスト条件 ...22 2.5.5 テスト フローへの影響 ...22 2.6 テスト サービス ライブラリ ...23 2.6.1 チェック...23
2.6.2 刺激ジェネレータ ...24 2.7 テスト セットアップ ...24 3.0 テスト方針 ...25 3.1 プロトコル テスト...25 3.1.1 テスト コンセプト ...25 3.1.2 CANoeでの実装 ...26 3.2 アプリケーション テスト ...26 3.2.1 テスト コンセプト ...27 3.2.2 CANoeでの実装 ...28 3.3 不変テスト...28 3.3.1 テスト コンセプト ...28 3.3.2 CANoeでの実装 ...29 4.0 テスト マネジメント システムへのインターフェイス...30 4.1 テスト マネジメントの基本...30 4.2 インターフェイスの原理 ...30 5.0 お問い合わせ...31
1.0 概要
CANoeはバス システムの解析とシミュレーションを行うためのツールとして設計されましたが、当初からECUとネットワーク システムのテストにも使用されていました。バージョン 5.0 で効率的になったCANoe1 では、機能拡張によりテスト サポート 機能などが追加され、さらに、「テスト機能セット」が統合されました。「テスト機能セット」はCANoeに含まれるコンポーネント ではなく、テスト設定のプロセスを簡素化し、テスト レポートなどの重要な機能を追加するためにCANoeを拡張したシリー ズです。 本書では、テスト コンセプトと CANoe および「テスト機能セット」の可能性について述べます。特に、CANoe を使用してテ ストを設定する方法と、テスト シーケンスを作成する方法について述べます。2.0 CANoe を使用したテスト
この章では、「テスト機能セット」のコンセプトとコンポーネント、およびテストを実行するプラットフォームとしての CANoe の 使用方法について説明します。 2.1 CANoe テスト コンセプト 2.1.1 アーキテクチャ CANoe には、よく知られる解析/シミュレーション コンポーネントの他に、テスト用のコンポーネントを含んでいます。「テスト モジュール」は、測定中にシステムまたはユーザーにより開始され、テスト シーケンスを実行します。テスト シーケンスは、 CAPL プログラムまたは XML ファイルとして作成することができます (これらは、「CAPL テスト モジュール」と「XML テスト モジュール」とも呼ばれます)。これらのファイルには 1 つのテスト モジュールしか記述しないので、単にテスト モジュールと 呼ぶことがあります。CANoe のシミュレーション ノードと同じように、テスト モジュールは、CAN や MOST のバスなどの 1 つまたは複数バスに アクセスし、さらに環境変数を使用して「テスト対象デバイス (Device Under Test)」のデジタル/アナログ入出力ラインにア クセスできます。ECU は単体でテストすることもできますが、さまざまな ECU で構成されるネットワークの一部としてテスト することもできます。この場合、テストの対象は「テスト対象システム (System Under Test (SUT))」と呼びます。ユーザー が操作するパネルや出力 Window への書き込みなどは、テスト モジュールに使用できます。 1 プログラム パッケージCANoe/DENoeは、CAN、LIN、MOST、FlexRayなどのさまざまなバス システムをサポートしています。そのた め、プログラムは、サポートする特定のバス システムによって少しずつ異なります (CANoe.MOSTはCANとMOSTをサポートするな ど)。本書では、「CANoe」はこれらすべてのバス システムを対象とします。つまり、そのコンフィギュレーションはすべてのバスに対応 します。
CANoe test module CAPL XML HTML XML test report test module test module System Under Test (SUT) digital/analog I/O environment variables bus communication
remaining bus simulation
図1: CANoe を使用したテスト システムの設定 CANoe を使用してただテストを実行するだけでなく、従来の CANoe の機能を使用することもできます。たとえば、シミュレ ーション ノードを使用してシステム全体の一部をシミュレーションしたり、バスの状態や SUT の動作を解析することもできま す (トレース Window での監視、CAPL プログラムによる解析、統計のログ取得など)。 「テスト レポート」は、テスト モジュールの実行結果として作成されます。テスト レポートは、テスト中にXML形式で書かれ、 テスト モジュールの実行完了後に、HTML形式に変換されます (第2.2章を参照)。通常、テスト終了時には、XMLファイル とHTMLファイルの 2 つのテスト レポートが作成されます。XMLファイルは、他のプログラム (テストマネジメントシステムな ど) で情報を扱いやすい形式で、変換されたHTMLテスト レポートは、最も見やすい形式です。 2.1.2 テスト モジュールの設定 最も重要な単位は「テスト ケース」で、そこに実際の動作とテストを作成します。CANoe では、「テスト モジュール」がテスト の実行単位です。テスト モジュールは、テストを実行する際に開始され、実行結果は、テスト レポートにまとめられます。テ スト モジュールはテスト ケースで構成され、さらに、テスト ケースはテスト ステップで構成されます。テスト ステップは、テス ト シーケンスがある特定ポイントに達したことを示す情報の 1 つです。 Test Module Test Case Test Step Test Step Test Step Test Case Test Case 図2: テスト モジュール･F テスト ステップで構成されるテスト ケースを含みます。
テスト ケースには、テストを実行する命令を記述します。できる限り、テスト ケースは他のすべてのテスト ケースに依存せ ず動作するように設定します。テスト ケースは、テスト モジュールの一部として実行されますが、それぞれ別個に開発や保 守を行います (第3.0章のTest Management Systemsについて参照)。テスト対象ECUのプロパティや機能をテストする命 令は、テスト ケースの中に作成します。 たとえば、ECU のネットワーク マネジメントは膨大なプロパティと機能から構成されるため、すべてのテストは行いません。 その代わり、システムのスタートアップや特定の障害状態の処理に対しては、個々のテスト ケースで各プロパティを作成し ます。 実行したテスト ケースは、テスト レポートに結果と一緒にリストされます。これらの「実行した」テスト ケースは、「テスト グル ープ」単位でテスト レポートにまとめることができます。テスト グループは、実行したテスト ケースのまとまった単位または ヘッダーです。本の章タイトルのように、テスト グループは階層構造に作成することができます。そのため、実行したテスト ケースは、テスト グループのツリー構造となります。 Test Module Test Case Test Case Test Case 1 Test Group Test Case Test Case 1.1 Test Group Test Case 1.2 Test Group Test Case Test Case 2 Test Group 図3: テスト ケース･F テスト グループごとに階層構造にできます CAPL テスト モジュールではテスト グループはスタティックに定義することはできません。つまり、テストの実行前にはテス ト ケースとテスト グループの関連性を CANoe は認識せず、それらはテスト実行の際に CAPL プログラムで初めて関連付 けられることになります。テスト実行中にテスト ケースを何度も呼び出すことができるため、同じテスト ケースを複数のテス ト レポートや複数のテスト グループと何度も割り当ることが可能です。 XML テスト モジュールでは、CAPL と異なりプログラミングの必要がないので、テスト ケースの構造 (シーケンスとテスト グ ループの関係) は、スタティックに定義されます。テスト ケースはレポートに一度だけ現れ、必ず同じテスト グループが割り 当てられます。 2.1.3 テスト結果 – 判定 テスト結果は、CANoe で自動的に取得され、処理されます。テスト機能セットは非常にシンプルなコンセプトに従っています。 テストは、「pass (合格)」または「fail (失敗)」のどちらかになります。このシンプルなテスト結果を「判定」と呼びます。 テストの実行は、テスト ケースのレベルとテスト モジュール全体のレベルの 2 つのレベルで評価されます。少なくとも CAPL テスト モジュールではテスト ケースがテスト グループにスタティックに割り当てられないので、CANoe ではテスト結 果がテスト グループのレベルで構成されません。その結果、複数のテスト実行で一貫したテスト結果を得ることができませ ん。つまり、「テスト グループ XY がパス/失敗」というタイプの結論を得ることはできません。
原則的に、あるテスト ケースの実行時にエラーがない場合、そのテスト ケースはパスしたと考えられます。そのため、エラ ーなしの実行は、テスト フローで明示的に報告されません。エラーは、さまざまな原因によってレポートされます。特に以下 の原因があります: • CAPLプログラムでは、エラーはTestStepFailまたはTestCaseFailで示されます。 • テスト パラメータのエラー (第0章を参照) は自動的にレポートされます。 • 条件または制約のエラー (第2.4.4章を参照) は自動的にレポートされます。 • テスト コマンドの実行に関する問題はエラーとして評価されます (不適切なパラメータ値の入力など)。 エラーが発生した後、通常、テスト ケースは継続されます。後続のテストはエラーがなく、テスト レポートには明示的に 「pass」でレポートされるかもしれません。しかしこれは、テスト ケースの判定が「pass」に再設定されるという意味ではあり ません。明確なルール:一度エラーが発生した場合、そのテスト ケースは必ず fail とします。 実行されたテスト ケースの判定ルールと同じように、テスト モジュールも判定されます。テスト ケースが失敗した場合、すぐ にテスト モジュール全体も失敗したと見なされます。テスト モジュールの実行時に CANoe によって自動的に判定されます。 基本的に、判定は実行したテスト モジュールや実行したテスト ケースに関する結論です。そのため、「実行されていない」と いった種類の判定はありません。ただし、実行されていないテスト ケースは、テスト レポートに記録することができます。実 行されていないテスト ケースには判定はなく、この場合の pass は、それらのテスト ケースは指定されたが実行されなかっ たことを示しています。 特定のポイントまでにエラーが発生し、テスト ケースの fail がすでに確定している場合、現在の判定状況をクエリーし、非 常に長いテストシーケンスの実行を特定のポイントで自動的に終了させたりすることができます。モジュール レベルでは、 判定を明示的に設定することもできます。このオプションにより、例外的な状況においてユーザー独自の判定ロジックを実 装することができます。 2.2 テスト結果のレポート テスト結果を確認する為に、テスト実行時にテスト レポートが作成されます。 2.2.1 概要 CANoe は、テスト実行中に XML 形式でハード ドライブにテスト レポートの書き出しを始め、連続的に追加します。非常に 長いテストを実行し、且つ極端に大きな RAM 容量がない場合でも、内部バッファ オーバーランなしで処理することができ ます。テスト実行の終了後、すぐにこの XML ファイルは XSLT スタイルシートを使用して HTML に変換されます。 XSLT スタイルシートには、XML テスト レポートの形式とコンテンツを指定します。このスタイルシートを使用すると、シンプ ルな HTML ページにレポートを表示することができますが、多くのファイルで構成される複雑な HTML を作成することもで きます。さらに、変換の際にすべての情報を XML レポートから HTML レポートにコピーする必要はありませんので、このス タイル シートを使用して、情報をフィルタにかけることができます。提供しているスタイルシートをユーザー固有のニーズに 合わせて簡単に変更することができ、カスタマイズしたスタイルシートも使用できます。 XMLレポートからHTMLレポートへの変換は、CANoeが直接コントロールするXSLTプロセッサで実行します。ただし、 CANoeを使用せずに、DOSプロンプトからXSLTプロセッサを呼び出すこともできます (CANoeインストール ディレクトリの Exec32 の下にsabcmがあります)。
sabcmd <XSLT stylesheet> <XML report file> <HTML report file>
そのため、後で既存の XML レポートを HTML レポートに変換することができます。さまざまな XSLT スタイルシートを使用 して、さまざまなスタイルのサンプル レポートを生成することができます。たとえば、エラー解析のための非常に詳細なレポ ートとしてだけでなく、単にテスト概要のファイリングを目的として生成することもできます。同様に、特定の出力メディアによ って異なるスタイル (プリントアウトしやすいレポートや、Web ブラウザでインタラクティブに表示するためのナビゲーション
コントロールを多く含むバージョンなど) にすることができます。XSLT スタイルシートを使用して、RTF やテキスト形式のフ ァイルなどのその他の出力フォーマットでレポートを生成することもできます。 CANoe test module XML test report XSLT style sheet HTML test report XSLT processor
writing XML report controlling XSLT processor
図4: CANoe を使用したレポートの作成 XML テスト レポートは、全ての記録データを含んだ、CANoe が直接生成するレポートです。HTML レポートは、XML レポ ートから生成されるシンプルな表示のレポートです。 CANoe では、レポート以外に「ログ」機能と呼ばれる、データを記録するモードもサポートしています。テスト レポートがログ に取って代わることはなく、2 つの出力タイプは互いに補完し合っています。ログはバスの状態および環境(ex.I/O と環境変 数)との相互関係を記録し、テスト レポートは、テスト ケースがいつ実行され、どのような結果になったかについて情報を提 供します。 2.2.2 手動または自動で生成されたレポート情報 基本的にテスト レポートはCANoe2で自動的に生成されます。そのため、コマンドや情報をテスト シーケンスの記述に追加 する必要はありません。たとえば、CANoeでは、CAPLまたはXMLで定義したテスト ケースの名前を使用しています。 既存の情報を使用して、実行したテスト ケースとその結果および特定の開始時間と終了時間を一覧表示する、といったシ ンプルなテスト レポートを生成します。一方で、テストの設定内容やテスト対象デバイス、テスト エンジニア、個々のテスト ケースなどに関する補足情報を含めることができます。この情報は、対応するCAPLコマンド (TestModuleDescriptionな ど) またはXMLエレメント (<description> in <testmodule> or <testcase>) によって、テスト記述に追加されます。 CAPL では、複数のレポート コマンドを使用して長いテキストを作成することができます。この場合、記述用コマンドを連続 して使用します。すべてのテキスト セグメントは自動的に相互に追加され、スペース文字 によって区切られます (改行は使 用しません)。そのため、極端に長い行にはなりません。
TestModuleDescription (“It is the aim of this test module to check all”); TestModuleDescription (“network management facilities (including startup)”); TestModuleDescription (“of the ECU under test.”);
変数の値もこのような記述の中に含めることができます。これにはString変数を使用し、このStringは関数snprintfにて定義 されます。
2
char buffer[100];
snprintf (buffer, 100, “Test case was called with parameter value:%d”, value); TestCaseDescription (buffer); 2.2.3 ID の使用 多くのテスト仕様では、テスト グループ、テスト ケース、個々のテスト ステップへ名前と固有の ID が割り当てられます。通 常、テスト ケースはシーケンシャルに番号が振られるだけですが、より複雑な ID 体系を使用する場合もあります (たとえば、 “NWM01” から “NWM15” はネットワーク マネジメント機能のためのテスト ケースであると特定できるなど)。 CAPL または XML のテスト モジュールで、テスト グループ、テスト ケース、テスト ステップに ID を割り当て、それをテスト レポートに記述することができます。例:
TestCaseTitle (“Identifier”, “Name of the test case”);
これらの ID は、テスト仕様と一致させるよう考慮します。ただし、ID は、テスト モジュールのテスト グループ、テスト ケース、 テスト ステップを一意に特定する目的にも使用できるので、テスト モジュールとテスト レポート間の参照を可能にします。 ID が必要ない場合、その引数は省略しても構いません (空文字列を入力)。テスト レポートのフォーマットは長い名前に対 応していないので、ID をあまり長い名前で保存することはできません。テストケース名と説明には別のフィールドを使用す ることができます。 2.2.4 テスト ステップ テスト ステップは、テスト シーケンスの詳細をレポートする重要な役割を持ちます。テスト ステップは、特定のポイントでの テスト実行の状態です3。含まれる内容は以下のとおりです: • 詳細レベル • ID • 説明 • 判定 詳細レベルの入力は任意です。これは、通常のテスト ステップとテスト レポートに詳細を提供するだけのテスト ステップと を区別する場合に役立ちます。入力することにより、HTML レポートを生成する場合の詳細レベルを変えることができます。 「詳細レベル」は数字で入力します。数字が入力されていない場合、0 とみなします。「詳細レベル」が 0 ということは、重要 で最も基本的なテスト ステップのみであることを示し、値が大きくなるほど、テスト ステップが詳細であることを示します。そ れにより、レベル番号の大きいほうが重要度の低い詳細なテスト ステップであることを示します。これにより、提供する XSLT スタイルシートによって、指定した値までテスト ステップの出力を制限することができます。ただし、特定の詳細レベ ルのテスト ステップのみ選択する XSLT スタイル シートを作成することもできます。 CANoe は、0 より大きい詳細レベルの重要度を厳密に定義しません。そのため、ユーザーは、実装する前に、特定のプロ ジェクトに対して個々のレベルの重要度を厳密に定義する必要があります。通常、たくさんのレベルを導入しても意味があ りません。次の定義の例からこれらのコンセプトが実用的であることが分かります。 0: テスト処理の基本的なステップと、テスト ケースの失敗につながるすべての結果。 1: 実行した動作や障害状況を解析するための反応 (テストしているデバイスの障害解析) に関する詳細情報。 3 テスト ケースの実行は、シーケンスの特定のポイントでテスト ステップによりレポートされますが、テストステップで細分されているわけ ではありません。それにもかかわらず、テスト ステップはセクションごとにテスト ケースを説明するために使用されます。
2: テスト シーケンスを解析するためのテスト ケース内の内部処理に関する詳細情報 (テスト ケースの障害解析の出 力のデバッグ)。 上述のテスト ステップのIDを使用して (第2.2.3章を参照)、ユーザーの既存のテスト文書にあるテスト ステップの各記述を 参照することができます (テスト仕様のテスト ステップ番号を参照するなど)。 テスト ステップは、特定のテスト ステップ コマンドによって「判定」を割り当て、それをレポートに出力します。このテストステ ップにおける動作は、評価している内容に相当します。 • pass (TestStepPass):動作は予期した通りに実行されました。たとえば、テスト シーケンスで予期した通りに、特 定のメッセージを受信しました。エラー解析は前にパスしたテスト ステップを正確に認識する必要があるので、テス ト シーケンスは正確にレポートされます。 • fail (TestStepFail):動作はテスト フローでのエラーを示します。たとえば、予期されるメッセージを指定した時間内 に受信できませんでした (タイムアウト)。TestStepFailは、テスト ケースをfailにします。 • warning (TestStepWarning):動作が期待通りに実行されましたが、その結果は潜在的な問題を示しています。 • none (TestStep):テスト ステップは特定の動作が実行されたことのみを示します (メッセージが送信されたなど) が、 厳密な意味で、判定は不可能です (実際起こった動作の報告)。 基本的に、テスト ステップは、テスト シーケンスの情報をレポートに転送するのみです。テスト実行自体には影響を及ぼし ません。ただし、CAPLコマンドTestStepFailは例外です。 テストステップの「fail」判定は、テスト ケースも同時にfailの場合 のみ有効となります。そのため、CAPLコマンドTestStepFailは同様に、自動的にテスト ケース全体をfailにします。この方 法でテスト ステップを使用して記述する場合、CAPLコマンドTestCaseFailでテストケース全体の判定を行う必要はありま せん。 CAPL テスト モジュールのみ、テスト ステップの定義ができます。XML テスト モジュールでは、ユーザーが定義しなくても テスト ステップが生成されます。 2.2.5 テスト ステップによる CAPL プログラムのドキュメンテーション CAPL では、テスト ステップは、プログラムを体系付けたり、プログラム コメントを管理します。このため、テスト ステップの コマンドは、「2 つの部分」で使用されます。最初の部分では、テスト ステップコマンドによってテスト ステップを初期化し、そ れに続くプログラムのタイトルを設定します。そして、テスト ステップを完結させるテストステップコマンドは、この最初のテス トステップにあらかじめ指定された時に呼び出されます。2 つ目は、テスト ステップにタイムスタンプを設定します。このタイ ムスタンプはテスト レポートにコピーされます。 コメント付きでテスト ステップが 1 つのみで構成される次のプログラム セクションを参照してください。 // Test step 27:waiting for answer
if (1 != TestWaitForMessage (Answer, 500))
TestStepFail (“27”, “Waiting for answer - answer not received”); else
TestStepPass (“27”, “Waiting for answer – answer received”);
このプログラム セクションは、次のプログラム セクションで置き換えることができます。 TestStepBegin (“27”, “Waiting for answer”);
if (1 != TestWaitForMessage (Answer, 500)) TestStepFail (“ - answer not received”); else
TestStepPass (“ – answer received”);
待機動作の結果によって異なりますが、上記サンプルのテスト ステップの結果が「Waiting for answer – answer not received」というコメント付きの「fail」か、「Waiting for answer – answer received」というコメント付きの「pass」判定となりま す。
2.3 CAPL でのテスト ケースの作成 テスト モジュールは、CANoe 上でさまざまな方法で定義できます。CAPL によってテストモジュールを柔軟に作成すること ができます。 2.3.1 原理 CANoe が提供する CAPL プログラムは、「制御モジュール通信」に対して最適で、習得しやすいプログラミング言語です。 このプログラミング言語は、テスト機能セットのフレームワークに対しても拡張されており、効果的にシミュレーション機能や タスクの解析機能を処理するだけでなく、明確且つ簡潔な手法でテストを作成することができます。上述したように、テスト を実装する CAPL プログラムは、テスト モジュールとして実行されます。そのため、これらの CAPL プログラムは、CAPL テスト モジュールと見なされます。 time event based execution sequential execution event A
event procedure test program
start of test end of test wait for event C event B event A event B 図5: イベント ベースの実行とシーケンシャルな実行 大抵、テストは開始と終了ポイントを定義したテストシーケンシャルな実行フローで構成されます。そのため、CAPL テスト モジュールは、厳密なイベント ベースの実行モデルに従うのではなく、むしろ、待機 ポイントを含むシーケンシャルな実行モ デルに従います。 テスト モジュールは、測定中に明示的に開始されます。テスト モジュールが開始されると、CAPL関数MainTestが呼び出 されます。テスト モジュールが呼び出すこの関数とテストケースがシーケンシャルに実行されます。MainTest関数が停止 すると、すぐにテスト モジュールも自動的に終了します。つまり、MainTest関数の実行時間が、テスト モジュールの実行時 間になります。 テスト モジュールは、いったん停止した後、同じ測定中であっても再開することができます。これは、テスト モジュールは測 定中に何度も使用することができますが、常に同じテスト モジュールの 1 つのインスタンスしか実行できないことを意味し ます。シミュレーション ノードのようにテスト モジュールは独立した実行ブロックなので、CANoe では、さまざまなテスト モジ ュールを同時に操作することができます。ただし、これは、テスト シーケンスが互いに完全に独立している場合のみ可能で す。
2.3.2 CAPL テスト モジュールの設定 CAPLテスト モジュールは、主にMainTest関数とテスト ケースで構成されます。テスト ケースは、特殊な関数として定義さ れます。 • キーワードtestcaseで特定されます。 • 戻り値がありません。 • 他の関数のようにパラメータを使用できます。 • テスト レポートに呼び出しが自動的に記録されます (第2.2.2章を参照)。 • CANoeは自動的にテスト結果、つまりVerdictを決定します (第2.1.3章を参照)。 MainTest関数は、実際にテスト モジュールの「メイン プログラム」です。この関数のタスクは、必要なシーケンスで必要なテ スト ケースを呼び出すことです。MainTestは、テスト シーケンスを制御します。最もシンプルなフォームのMainTestは、テ スト ケースの呼び出しのみで構成されます。 void MainTest () { Testcase_1 (); Testcase_2 (); Testcase_3 (); } MainTestにテスト シーケンスのシステム自体をoutputコマンドと待機コマンドを使用して実装することは技術的に可能であ るとしても、MainTestにはテスト フロー コントロールのみ含め、システム自体を定義しない方がよいでしょう。これは、個々 のテスト ケースにて定義します。ただし、MainTestの柔軟性を利用して、複雑なフローのロジックを実装することができます。 たとえば、特定のテスト ケースがすでに失敗していると検出された場合、エラーが発生した時にそれらを組み込んだソース にて除外することができます。テスト ケースは、ループさせて呼び出すことにより、何度も実行することができます (各回で 異なるパラメータ セットを使用したりします)。 MainTestの幅広いプログラミングや、テスト ケースの実装でグローバル変数を使用する場合、技術的な観点から、テスト ケースが実装時に相互に依存している可能性があるというリスクを負います。このような依存性は、テスト ケースのトラブ ルシューティングが困難になり、テスト ケースの再利用の妨げとなります。そのため、テスト ケースがお互いのテスト ケー スを基準として構築されないようにし、テスト ケースの最後にテスト対象ECUに行った変更を元に戻すようにする必要があ ります。 イベント プロシージャをテスト モジュールで定義して使用することもできます (テスト モジュールの実行時間中のみ。第 2.3.5章を参照) が、テスト モジュールは測定の最初から最後までアクティブではない為、システム イベント プロシージャ Prestart、Start、MeasurementStopはテスト モジュールでは使用できません。 2.3.3 待機コマンド シーケンシャルに実行される CAPL テスト プログラムは、待機コマンドで割り込みを発生させることができます。これらのコ マンドの特徴は、CANoe にフロー コントロールを返し、特定のイベントが発生するまで処理を再開しない点にあります。技 術的な観点から、待機用の CAPL 関数が呼ばれると、指定されたイベントが発生するまで、フロー コントロールは呼び出し 元に戻りません。
measurement start test module start
test module end measurement end event event MainTest () testcase TC1 () testcase TC2 () wait command continue execution test case call
test case end
図6: 待機コマンドを使用したテスト モジュールの実行原理 CAN メッセージの受信などの CANoe のイベントが登録されている場合･環境変数やドリフトやジッターを変更、これらのイ ベントは CANoe のクロックによってタイムスタンプを取得し、バッファで待機中となって処理を待ちます。最初に、あるポイ ントで発生したこれらのすべてのイベントが処理され、次に内部クロックが進みます。 CAPL プログラムでのイベント プロシージャの実行には、割り込みができません。必ず 1 つのイベント プロシージャが完全 に実行されてから、次のイベントが待ち行列から取り出されて処理されます。これは、CANoe クロックで測定しながら、 CAPL プログラム内のすべてのオペレーションが同時に実行されることを意味します。 CAPL プログラムのこの実行モデルは、待機コマンドによって中断されます。最初に、テスト モジュールの開始は、他と同 様に CANoe イベントです。これにより、テスト モジュールの処理を開始します。この処理は割り込みできないので、待機コ マンドが発生するまで独自のタイミングで実行されます。待機コマンドは CAPL プログラムに割り込みを行い、まず待ち行 列の他のすべてのイベントが処理されることを確認し、それからクロックが進みます。CAPL テスト モジュールは待機オブ ジェクトであったイベントが発生するまで、実行を再開しません。次の待機コマンドまで割り込みされることなく、他の CAPL プログラムが再び実行されます。 特定のメッセージを受信するなどの、待機コマンドで指定されたイベントが発生すると、待機条件がトリガーされます。最大 待機時間 (タイムアウト) を過ぎた場合、待機条件が削除されるように、待機コマンドには最大待機時間を指定します。待機 は、パラメータの入力に何らかのエラーがある場合も、すぐに停止します (たとえば、シンボリックに指定された MOST メッ セージがファンクション カタログにリストされていないなど)。 待機条件がクリアされた理由は、戻り値に示されます。一般的には、すべての戻り値を個々に考慮する必要はありません。 予期した戻り値とそうでないすべての戻り値を区別するだけで十分です。後者はエラーとして評価されます。予期した戻り 値が、待機命令に指定したイベントが発生したことを示す戻り値である必要は必ずしもありません。たとえば、実際に最大 待機時間の時間切れがテスト ケースで予期されるという場合もあります (ステートメント: 「指定されたイベントが時間内に 発生しませんでした」)。 可能な限り、さまざまな待機コマンドが同じイベントに対して同じ戻り値を返すはずです。そのため、いくつかの待機コマンド の戻り値の範囲にはギャップがある場合があります。負の戻り値は、通常、テスト シーケンスでエラーとして評価されるイベ ントであることを意味します。ただし、実際の特別なケースではこのようなイベントがテスト シーケンスで期待される場合もあ
るので、必ずしもテスト エラーにはなりません。この違いは、唯一、多くのケースにおける判定に反映します。そうでない場 合は、テストの実行には影響はありません。
if (1 == TestWaitForSomething (…)) {
… // expected event received, go ahead with normal test course }
else {
… // expected event not received, handle this error } 待機条件をクリアする理由は、テスト レポートに自動的に記録されます。ただし、無効なパラメータを入力するなどの実際 のエラーが発生した場合のみ、テスト ケースは失敗となります。他のすべてのケースでは、CAPL プログラム自体が待機コ マンドをクリアするかどうか評価および決定する必要があります。 もし、待機コマンドの予期せぬ終了に対する反応があるのであれば、CAPL プログラムをより明確に構成します。この場合、 CAPL プログラム内の多くの部分で if 条件文がネストするのを避けることができます。 if (1 != TestWaitForSomething (…)) {
// Some thing went wrong – handle this error }
… // all correct, go ahead with the normal test course
メインのプログラム フローはここで予期されるテスト コースを反映し、待機コマンド後にif分岐でエラーを処理します。最もシ ンプルなシナリオでは、エラーが発生するとすぐにテスト ケースは終了します (テスト モジュールは終了しません)。エラー 処理では、TestStepFailを使用して失敗をレポートし、returnを使用してテスト ケースを終了します。 例: if (1 != TestWaitForMessage (msg, 1000)) {
TestStepFail (“”, “Message msg not received within 1000ms.”); return;
}
TestStepPass (“”, “Message msg received.”); … // go ahead with normal test course
この例では、テストが成功した場合に、テスト レポートにコメントも出力されます (2.2.4を参照)。コメントは絶対に必要では ありませんが、テスト レポートのテスト フローを追う手助けになります。 2.3.4 複雑な条件を含む待機コマンド 1 つのイベントだけを待つシンプルな待機コマンドの他に、待機条件を組み合わせた待機コマンドを設定することができま す。ここには、各条件 (TestJoin...CAPLコマンド) の定義を含めます。これらの定義は待機プロセスを起動するのでも、状 況を監視するのでもありません。それは、TestWaitForAnyJoinedEvent (ORロジックを使用して定義されたイベントのいず れかを待つ) またはTestWaitForAllJoinedEvents (ANDロジックを使用してすべてのイベントを待つ) によって行われます。 TestJoinMessageEvent (msg1); TestJoinMessageEvent (msg2); TestJoinEnvVarEvent (envvar); if (0 < TestWaitForAnyJoinedEvent (2000)) … TestJoinコマンドは、待機条件の一意のIDとして 0 より大きい値を返します。TestWaitForAnyJoinedEventを使用する場 合、戻り値は、発生したイベントを示します。
待機オペレーションの後、すべての待機条件は内部的にクリアされます。これは、組み合わせた待機コマンドが 2 回以上 必要な場合、ユーザーはもう一度待機条件をすべて入力する必要があることを意味します。ただし、CAPL サブルーチンを 使用することにより、コードのコピーの必要はありません。 2.3.5 テスト モジュールのイベント プロシージャ テスト モジュールには、MainTest関数とそれが呼び出すテスト ケースによって構成されるテスト シーケンス以外に、イベン ト プロシージャも含まれる場合があります。イベント プロシージャは、実際のテスト シーケンスとある程度同時に実行され ます。ただし、前述するように、実行は 2 つの待機コマンドの間に割り込まれることはなく、ロジック レベルで 1 つの時間ス テップの範囲で発生するので、イベント プロシージャは、テスト モジュールの「メイン プログラム」が待機の場合のみ実行で きます。イベント プロシージャは、割り込みされることがなく、待機コマンド自体を含むことができません。そのためセマフォ ーのような同期ツールは省略することができます。 イベント プロシージャをテスト モジュールで使用する場合、テスト モジュールはMainTestの開始前と終了後は非アクティブ なので、それらの時間中にはイベント プロシージャを実行することはできません。さらに、すべてのCAPL変数は、テスト モ ジュールの各開始時にリセットされます。このようにして、各テスト ランは、同じ初期条件になります。 2.3.6 ユーザー定義のイベント 考えられるすべての待機条件を既存の待機コマンドで実現することはできません。そのため、ユーザー定義のイベントをト リガーし、それを待機するものを提供します。ユーザー定義のイベントは、ユーザーが選択した一意の文字列によって特定 されるため、「テキスト イベント」とも呼ばれます。 テスト モジュール内のイベント プロシージャに、ユーザー定義の待機条件を記述することもできます。これらのプロシージャ では、チェックを行って待機条件を満たすかどうか確認します。この場合、テスト ケースで待機する可能性のあるユーザー 定義のイベントが起動します。イベント プロシージャの CAPL プログラミングは、必要な待機条件を実装することができます。 簡単な例: on message Engine { if (this.Speed > 100) TestSupplyTextEvent (“Speed100”); } testcase TC () { … TestWaitForTextEvent (“Speed100”, 2000); … } ユーザー定義のイベントは、テスト モジュールでのみ動作します。そのため、ユーザー定義のイベントを 1 つのテスト モジ ュールまたはシミュレーション ノードで起動し、別のテスト モジュールで再度動作させることはできません。 ユーザー定義のイベント (「テキスト イベント」) の他に、よく似た「補助イベント (auxiliary event)」もあります。これらのイベ ントは、番号で示され、エラー発生時に「テスト サービス ライブラリ」のChecks (第2.6と比較) または他の拡張ライブラリ (DLL) によって生成されます。これらのイベントは待機することができます。 2.3.7 シミュレーション解析用の CAPL とテスト用の CAPL の違い
基本的に、テスト用の CAPL は、よく知られる CAPL 実装の拡張なので、ほとんどすべての既存の CAPL 機能は、CAPL テスト プログラムでも使用することができます。しかしながら、実行モデルが変更されているので、シミュレーション･解析用
の CAPL プログラムとテスト モジュール用の CAPL プログラムには、いくつかの原理の違いがあります。次の表に違いを まとめます。 シミュレーションと解析 テスト 実行期間 測定全体でアクティブ テスト モジュールの開始からMainTest関数の最 後までのみアクティブ 実行モデル イベント ドリブン イベント プロシージャは、概念上、最小単位であ る必要がある。待機は不可 シーケンシャルに実行 追加として:イベント プロシージャを実行可能 概念上、2 つの待機コマンド間でイベント プロシ ージャを最小単位で実行 初期化と最終決定 測定の開始時と終了時に使用するイベント: on PreStart () on Start () on MeasurementEnd () メインのテスト プログラムでテストの開始時と終 了時に使用するイベント: MainTest () 測定の開始時と終了時にはこのイベント プロシ ージャは使用できない 使用可能な CAPL コマンド CAPL テスト コマンドは使用不可 ほとんどすべて 補助 CAPL テスト コマンドも使用可能 レポート – 自動 2.4 XML テスト モジュールでのテスト ケースの定義 CAPL プログラミングでの定義の他に、テスト モジュールをより抽象的な XML 形式で定義することもできます。 2.4.1 原理 XML のテスト モジュールは、CAPL のテスト モジュールとは異なるアプローチでテスト ケースの記述を行いますが、両方と も同じ基本コンセプト、構造、テスト機能セットのプロパティに基づいています。ファイル形式以外で最も重要な違いは、テス ト ケースの記述方法です。 XML テスト モジュールの場合、テスト 形式は「テスト パターン」で記述されます。テスト パターンは、テストがパスしたかど うかの確認を含む一般的なテスト シーケンスを実現します (i.e. テストパターンの、名前付けをします)。テスト パターンは、 特定のキー情報を指定しなければならないという点で一般的です。たとえば、使用可能なテスト パターンのいずれかで、状 態遷移のチェックを実施します。このクエリーを実行する方法は、テスト パターンで決定されます。開始状態と終了状態を 表すシグナルとシグナル値は、パラメータによってテスト パターンと連携しています。 テスト パターンには以下が含まれます。 • 実際のテスト シーケンス • 判定が設定される条件のチェック • レポート出力 • テスト パターンを設定するためのパラメータ XML ファイルでは、実行するテスト パターンに名前を付け、パラメータを使用して設定することが必要です。この事から、 XML ではテスト ケースでは「定義」され、CAPL テスト ケースでは「プログラム」されます。 1 つのテスト パターンで実現されるテスト ケースを含むシンプルなテスト モジュールの例: <testmodule title=”Mirror Control Test” version=”1.2”>
<statechange title=”Close Mirror, check motor” wait=”1000”> <in> <cansignal name=”Mirror_2”>1</cansignal> </in> <expected> <cansignal name=”MirrorMotor2”><gt>5</gt></cansignal> </expected> </statechange> </testcase> </testmodule> 使用可能なテスト パターンは、CANoeのライブラリのコンポーネントです。ここでstatechangeテスト パターンを使用し、次 のステップを実行します。 1. <in> セクションに指定するシグナルまたは環境変数に、特定の値が設定されています。例では、“Mirror_2” シグ ナルには 1 が設定されています。 2. 指定した時間、待機が発生します。この待ち時間は、システムがシグナルを送信するために必要です。ECU の状 態遷移をさせ、変更されたシグナルをテスターに送り返すことができます。この例では、待機時間は 1000ms に設 定されています。 3. シグナル値と環境変数の値は、<expected> セクションでチェックされます。例では、“MirrorMotor2” シグナルの値 は、5 以上になるはずです。 入力シグナル セットは、よく「入力ベクトル」言われますが、規定された出力シグナルは、「出力ベクトル」または「ターゲット ベクトル」と言われます。入力ベクトルは、システムをシミュレーションするために設定される値を確立します。一方、出力ベ クトルは、実際に発生している値をチェックする「条件」を定義します。これらの条件のいずれかが満たされない場合、テスト ケースの判定が「fail」と設定されます。 テスト ケースでは、複数のテスト パターンを使用することができます。ただし、条件、ループ、その他のプログラミング方法 はここでは使用できません。テスト パターンは、指定した順序でシーケンシャルに実行されます。上の例では、２つのテスト パターンは、まずウィンドウを開き, 初期化し、実際のテストを確実な初期状態で行います。 XML テスト モジュールでも、テスト ケースを互いのテスト ケースに基づいて構築すべきではなく、テスト対象 ECU を各テ スト後に初期状態にリセットしたほうが良いでしょう。ただし、XML テスト モジュールでは、テスト ケース間ですべての依存 を避けるのは簡単ではありません。 2.4.2 XML テスト モジュールの設定 XML テスト モジュールには、テスト ケースのコレクションが含まれます。CAPL テスト モジュールの場合のように、テスト ケ ースはテスト グループの中に構成され、その実行はテスト ステップの中で報告されます。ただし、テスト ステップは定義す る必要がなく、逆にテスト パターンが実行されると、自動的に出力されます。 XMLテスト モジュールでは、MainTestに匹敵するフロー コントロールがありません。テスト グループやテスト ケースの階 層とそのシーケンシャルな順序を定義するのがXMLファイルです。テスト モジュールを開始すると、CANoeは自動的にす べてのテスト ケースを順次その順序で実行します。 CANoe のユーザー インターフェイスでは、実行用のテスト ケースを選択するオプションを提供しています。ここでも、実行 シーケンスは、XML ファイルで指定されますが、選択されていないテスト ケースはスキップされます。テスト レポートでは、 これらの選択されていないテスト ケースは、実行しないもの (スキップする) として示されます。 XML ファイルは、特にテスト ケースにおいて、XML テスト レポートと同じ設定ができます。テスト エンジニアの名前やテス トする ECU の説明などの多くの一般情報は、既存のテスト レポートからテスト モジュールにコピーすることもできます。こ の情報は、テスト モジュールの実行中にテスト レポートに転送されます。
完全なテスト モジュールの例 (XML ヘッダーを含む): <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE testmodule SYSTEM "testmodule.dtd"> <testmodule title="Window Lift System Test" version="2.0">
<description>Test the states of the window lift system</description> <sut>
<info>
<name>Name</name>
<description>Central Locking System</description> </info> <info> <name>Version</name> <description>0.9 a3</description> </info> </sut> <engineer> <info>
<name>Test Engineer Name</name> <description>Stefan Krauss</description> </info>
</engineer>
<testgroup title="Function Tests">
<testcase ident="TC201" title="Open The Window">
<description>Initiate window open procedure over CAN bus.</description> <initialize wait="2000" title="Initialize signals, ensure window closed"> <cansignal name="LockRequest">0</cansignal>
<cansignal name="EngineRunning">0</cansignal> <cansignal name="Ignition15">2</cansignal> <cansignal name="KeyUp">1</cansignal> </initialize>
<initialize wait="100" title="Reset window up key"> <cansignal name="KeyUp">0</cansignal> </initialize>
<statechange wait="3000" title="Open window"> <in> <cansignal name="KeyDown">1</cansignal> </in> <expected> <envvar name="WindowMotion"><ge>2</ge></envvar> </expected> </statechange> </testcase> </testgroup> </testmodule> 上のstatechangeテスト パターンの他に、initializeテスト パターンもここで使用されます。このテスト パターンは、シグナル と環境変数の初期化を行い、statechangeテスト パターンと同じように動作しますが、条件のセクションがありません。 テスト ケースが失敗した場合、通常はテスト モジュール全体の失敗につながりますが、失敗したテストケースに続くテスト ケースがまだ実行されます。テスト ケースの中で、CANoe は違った動作をします:テスト パターンが失敗すると、テスト ケ ース (テスト モジュールではありません) が終了します。つまり、失敗したテスト パターンに続くテスト パターンはもう実行さ れません。この動作により、テスト フローが時間短縮されます。
2.4.3 テスト パターンの使用 多くのテスト パターンはシグナルで動作します。システムを刺激する場合、メッセージは直接バスで生成されるのではなく、 組み込まれたインタラクション レイヤーの入力シグナルが休止しているシミュレーションバスを変化させます。このレイヤー が変更したシグナルを通信に渡す場合、バスは選択したインタラクション レイヤーに依存し、直接テスト パターンに影響さ れなくなります。基本的に、テスト パターンで使用されるメカニズムは、CAPL プログラムのシグナル レベルでの動作と違 いません。 シグナル値を定義する際に、テスト パターンは必ず物理値で動作することに注意する必要があります。これは、転送される シグナル値は、データベース (CANdb) を使用して物理値に変換されることを意味します。シグナルの生値に、テスト パタ ーンから直接アクセスすることはできません。 結果の値は物理変数を表すので、必ず単純な比較の代わりに範囲を使用したほうが良いでしょう。この方法は、生値の変 換による不正確さをカバーします。厳密には、これはテスト パターン固有の問題ではなく、CAPL プラグラムであっても、物 理パラメータで動作する限りは監視されます。浮動小数点数を含むシグナルで動作させる場合、比較は必ず範囲を使用し たほうがよいでしょう。 2.4.4 XML テスト モジュールと CAPL テスト モジュール XML テスト モジュールは CAPL テスト モジュールに置き換わることはなく、多くの場合テストの定義をより簡単にするため の別の記述タイプとして CAPL テスト モジュールを補うものです。簡単に言うと、重要な違いは、XML テスト シーケンスで はユーザーはパラメータ値を割り当てるのみですが、CAPL ではテスト シーケンスはプログラミングされるということです。 CAPL テスト モジュールと XML テスト モジュールは、多くの類似点がありますが、技術的には次の表に挙げる点が異なり ます。 XML テスト モジュール CAPL テスト モジュール テスト ケースの実行 各テスト ケースを 1 回 各テスト ケースを任意の回数 実行順序 XML ファイルでスタティックに固定 MainTest関数で呼び出すことによりダイナミッ クに設定 実行のコントロール 線形。テスト ケースをユーザーが GUI で選択 可能 MainTest関数にプログラムされる テスト グループ XML ファイルでスタティックに定義 Æ 固定。テスト ケースをグループに 1 対 1 に 割り当て MainTestのコードによりダイナミックに定義 Æ 「実行する」テスト ケースは、実行時にテス ト グループに割り当てられる テスト ケースの定義 テスト パターンにより定義 CAPL でプログラミングされる テスト レポート XML ファイルに定義されるすべてのテスト ケ ースの情報を含む 実行されるテスト ケースに関する情報を含む テスト ケースを記述するために使用するテスト モジュールのタイプは、特定のテスト タスクおよび既存のテスト環境によっ て異なります (社員のプログラミングの知識、テスト管理ツールの使用方法など)。両者の選択がしやすいように、2 つの記 述タイプの長所を以下にリストします。 XML テスト モジュールの長所:
• アプリケーションが簡単です:実行コントロール、判定処理、テスト シーケンス (テスト パターン) の実施は、内蔵さ れたコンポーネントなので、ユーザーはこれらについて懸念する必要はありません。 • 生成:XML 形式のテスト モジュールは、他のツールを使用して簡単に生成できます (テスト ジェネレータ、テスト マ ネジメント システムなど)。 • 既存のテスト シーケンスのパラメータ化: テスト シーケンス自体をテスト パターンで実装します。 • プログラミングが不要です:テスト モジュールにテスト ケースと必要なパラメータのスタティックな記述が含まれます。 CAPL テスト モジュールの長所: • 最大の柔軟性:CAPL プログラミング言語は、テスト モジュールの設定、フロー コントロールのプログラミング、テス ト ケースの実装において非常に柔軟性があります。特に、CAPL テスト モジュールでは、XML テスト モジュール で不可能な複雑なテスト ケースをプログラミングすることができます。 • 複雑なフロー コントロール:MainTestでプログラムされるフロー コントロールは、テスト コントロールの呼び出しを ダイナミックにコントロールできるので、テスト シーケンス中にチェックされる条件に応じて呼び出しを行うことがで きます。 XML テスト モジュールは、同じシーケンスでありながら異なるパラメータを使用して多くのテスト ケースを実行するようなテ ストに最適です (特にテスト パラメータがデータベース、Excel ファイル、テスト マネジメント システムのいずれかに保存さ れている場合)。一方、CAPL テスト モジュールは、自動生成できない複雑なテスト シーケンスのプログラミングに最適です。 どちらにするか迷った場合、簡単かつ短時間にテストケースを定義できることから、初めは XML テストモジュールでの実装 を薦めます。 2.5 制約と条件 2.5.1 原理 制約と条件は、指定したテスト シーケンスで同時に実行されるチェックです。これらを使用して、テスト中に特定のターゲット 値から、テスト環境やテスト対象 ECU の偏差を検出します。これは、実際のテストの一部であることもあります (ECU がテ スト シーケンスで刺激されます。つまり、テストの目的は、ECU がテスト中のある時点で不変の条件に反するかどうかをチ ェックすることです)。また、制約と条件を使用し、テスト環境がテスト中に正しく動作することを確認することができます。 基本的に、テスト シーケンスにはこのようなチェックを挿入することができますが、同様のチェックをテスト シーケンスの多く のポイントでプログラミングする必要があります。一方、制約と条件は、あまり手間をかけずに実装することができます。さら に、制約と条件は、テスト フロー中は絶えず条件のコンフォーマンス チェックを必ず行うというコンセプトに基づいています。
time
Constraints/Conditions test main program
start of a Constr./Cond. checks MainTest/test cases test start test end test report start of a Constr./Cond. end of a Constr./Cond. start of a Constr./Cond. end of a Constr./Cond. end of a Constr./Cond. violation of a checked condition verdict test infrastructure 図7: 制約と条件は、実際のテスト プログラムと平行して実行されます。 チェックする条件は、テスト シーケンスで定義および開始されます。テスト条件は、テスト シーケンスで制約や条件が停止 されるまで、テスト フローと平行して継続してチェックされます。制約/条件が開始されたコンテキスト (テスト ケース、テスト モジュール、XML テスト モジュールのテスト グループ) が終了すると、制約/条件は自動的に停止します。CAPL では、制 約と条件は、イベント プロシージャではなく、「メイン テスト プログラム」でのみ定義、開始、停止を行わなければなりません。 テスト モジュールでは、制約と条件は必要な数だけ使用することができ、同時に有効であっても構いません。ただし、必ず 定義されたテスト シーケンス (いわゆる「メイン テスト プログラム」) は‚1 つです。 概念的に、制約と条件は次のように区別されます。 • 「制約」は、テスト環境が有効なテストを実行できる状態であることを保証します。制約では、テストの仮定をチェッ クすることができますが、テスト対象 ECU のチェックはできません。制約違反は、テスト環境での問題を示すもの であり、ECU の不具合を示すものではありません。 例: テスト中、ECU は安定した供給電圧を維持する必要があります。時間内の任意のポイントで、この電圧が指定 した最小値よりも下回ると、テストは無効になります。 • 「条件」は、テスト対象 ECU に関する仮定をチェックします。そのため、条件違反は ECU の欠陥を示します。 例:テストの実行中、メッセージの指定された周期時間を、ECU は守らないとなりません。ECU がこのその仕様を 満たさないということは、周期時間が上限または下限を超えているということです (プロセッサの過負荷によるなど)。 アプリケーションにおいて、2 つの主な違いは、結果の表示が異なり、それに応じて解釈する必要があることです。条件違 反によりテストが失敗すると、たとえ失敗の結果であろうとも、テストの目的が達成され、ECU がテストされたことになります。 一方、制約違反は、テスト環境の欠陥によってテストを実行できなかったことが示されます。この場合、テストの目的は達成 されず、テスト対象 ECU の品質に関する判定に直結しません。 制約または条件の違反が検出されると、テスト レポートに記録され、現在有効なテスト ケースの判定が「fail」に設定されま す。CAPL テスト モジュールでは、これは同時に実行されるテスト シーケンスに影響しません。そのため、制約や条件が失 敗したために「fail」判定のテスト シーケンスで問題が検出されることなく、テストを最後まで行うことができます。一方、XML テスト モジュールでは、実行されているテスト ケースは終了しますが、テスト モジュールは終了しません。 制約/条件違反の時間ポイントは、CANoeが違反を認識した時刻としてテスト レポートに示されます。厳密には、これが発 生した時間は、使用されるテスト条件によって異なります。レポートが扱いにくくならないようにするために、テスト ケースで の最初の制約/条件違反の発生のみが補足の統計的概要と一緒に報告されます。この概要は、違反が検出された回数と
違反チェックが行われた回数について述べます。4
ただし、これらの 2 つの数字の正確な定義は、使用されるテスト条件と その実装によって異なります。
2.5.2 あらかじめ定義されたチェックの使用 CAPL の場合
制約と条件の状態のチェックは、Test Service Library (2.6.1を参照) またはCAPLでユーザー定義のイベントで事前定義 されたチェックを使用して、CAPLテスト モジュールで実装することができます。Test Service Libraryに提供されるチェック は非常に使いやすいので、多くの場合に適するはずです。CAPLの条件に対してユーザー定義のチェックを行うのは、後続 の第2.5.4章に記述されるような例外の場合のみ必要です。
制約と条件にてチェックを使用するために 4 つの手順が必要です。
1. Test Service Libraryから必要なチェックの作成、パラメータ化、開始を行います。関連する関数は、ChkStart_と
いう接頭辞で始まります。各関数は、新しく作成されたチェックに対して一意のIDを返します。 2. 制約と条件は、TestAddConstraintまたはTestAddConditionで生成されます。手順 1 で作成されるチェックは、制 約/条件ステートメントを表し、そのIDがパラメータとして返されます。これは、先に監視している制約/条件とは平行 動作し、監視されます。つまり、「チェックされ始める」のです。 3. 制約/条件のモニタリングはTestRemoveConstraintまたはTestRemoveConditionによってもう一度削除されます。 4. チェックは ChkControl_Destroy によって破棄されます。 制約/条件はそれらが作成されたプログラム構造の最後に自動的に削除されるので、最後の 2 つのステップはオプションで す。チェックは、測定の最後に自動的に破棄されます。例: testcase TC () { dword check_id;
check_id = ChkStart_MsgAbsCycleTimeViolation (StatusMsg, 90, 110); TestAddConstraint (check_id);
…
// The actual test sequence is located here … TestRemoveConstraint (check_id); ChkControl_Destroy (check_id); } チェックは、チェックを作成したときに返されたIDによってシステムで特定されます (タイプ: dword)。テスト機能では、IDは、 チェックやそれらが使用するコンポーネントが送信したイベントを特定する場合にも使用されるので、Auxiliary IDとも言わ れます。そのため、技術的な観点から、TestAddConstraint (check_id) は、ID check_idの (Auxiliary) イベントを受信した 場合、このポイントから先、制約違反が報告されることを示します。チェックがチェック仮定の違反を検出するとすぐ、実際の テスト シーケンスと平行して実行されているチェックによってこのイベントが送信されます。チェックは、IDによってイベントが リンクされるまで制約になりません。 監視は、TestAddConstraintとTestRemoveConstraint間で実施します。この 2 つのコマンドは、同じコンテクスト、(同じテ スト ケースまたはMainTest内) で実行されます。制約または条件として、2 回以上同じチェックを使用することができます。 たとえば、1 つのテスト ケースで複数の監視セクションを作成できます。基本的に、チェックを最初に使用する前に TestAddConstraintで作成する必要はありませんが、これは、よりコードが読み易くなる為、コードをローカライズする代わ りに推奨します。 4 概念的に、チェックはバックグラウンドで実行されます。実際に、チェックする条件に匹敵するイベントが発生した場合のみ、チェックが 発生します。
2.5.3 XML の制約と条件
XML テスト モジュールでも制約と条件を使用できます。テスト サービス ライブラリのチェック関数をチェックとして使用でき ます。制約と条件は、テスト ケース、テスト グループ、テスト モジュールのいずれかの開始時に、別途 XML エレメントで定 義し、XML テスト モジュールの該当セクションに適用します。例:
<testcase ident=”TC2” title=”Wiping Level 2”> <conditions>
<cycletime_abs min="0" max="1100"> <canmsg id="WipingStatus"/> </cycletime_abs> </conditions> … </testcase> 同様に、チェックまたは制約/条件を明示的に別途作成する必要も削除する必要もありません。ただし、基本的な機能は、 CAPL テスト モジュールの制約と条件の機能と同じです。 監視は、テスト ケース内のテスト パターンに定義されるテスト シーケンスの実行全体を対象とします。制約と条件をテスト グループやテスト モジュールで定義する場合、監視は、テスト ケースに含まれる全セクションを含んだテスト ケースとテスト グループの実行全体を対象とします。制約や条件の失敗は、実行されたテスト ケースの「fail」判定につながります。 2.5.4 ユーザー定義のテスト条件 ユーザー定義のイベントを使用して、希望の制約と条件をCAPLで実装することができます。基本的に手順はユーザー定 義の待機条件の実装方法と同じです (第2.3.6章と比較)。実際のチェックは、制約/条件違反が発生した場合にユーザー定 義のイベント (「テキスト イベント」) を発行するテスト モジュールのイベント プロシージャで実装されます。例: on message Status { if (this.Temperature > 100) TestSupplyTextEvent (“Overheated”); } testcase TC { TestAddConstraint (“Overheated”); …
// The actual test sequence is located here … TestRemoveConstraint (“Overheated”); } この場合、文字列によって表されるユーザー定義のイベントが入力され、制約/条件として使用されます。ユーザー定義の イベントを制約/条件として入力することは「このイベントが発生しないようにする」ことを意味します。 2.5.5 テスト フローへの影響 制約と条件は、CAPL テスト モジュールのテスト フローには影響しません。XML テスト モジュールでは、処理されているテ スト ケースが終了するまで監視します。通常、制約/条件の監視は、テスト プログラムからは評価されません。制約/条件が 失敗すると、直接判定に影響し、テスト レポートに記録されます。プログラムでは、手順は必要としません。 テスト シーケンスのその後の方向が、実際に制約/条件の監視結果によって異なる場合、CAPLで実行している制約や条 件のステータスを明示的にクエリーすることができます (TestCheckConstraintまたはTestCheckCondition)。ただし、現在 の状態でのVerdictが依存するため、TestGetVerdictLastTestCaseおよびTestGetVerdictModuleによって判定をクエリー
