TestStandプロセスモデルの開発とカスタマイズ

製品の全機能テストを作成するには、一連のテストケースを実行するだけでは不十分です。通常、テストシステムでは、テストを実行するシーケンスの実行前、実行中、実行後に一連の操作を実行する必要があります。テストプロセスを定義する一般的な操作には、UUTの識別、オペレータへの合否ステータスの通知、結果のロギング、テストレポートの生成などがあります。このような一連の操作とその実行フローは、プロセスモデルと呼ばれます。TestStandでは、プロセスモデルのレイヤはシーケンスファイルに実装され、TestStandエンジンと分離されています。このモジュール性により、テストエグゼクティブ自体に影響を与えることなくプロセスモデルをカスタマイズできます。

プロセスモデルは、テストエグゼクティブとテストコードの両方から分離した追加のレイヤを提供し、一般的なテスト機能を実装します

TestStandがほとんどの自社開発のテストエグゼクティブと異なる点はプロセスモデルにあります。通常、これらのアプリケーションにはプロセスモデルの概念がなく、テストシーケンスまたはテストエグゼクティブ自体が一般的なテストタスクのメカニズムを提供します。 以下のアプローチはどちらも理想的ではありません。

• テストコードがこれらの一般的な操作を行う場合、作成された新しいテストセットごとにこのコードを繰り返す必要があります。
• 一般的な操作がテストエグゼクティブに直接実装されている場合、一般的なテスト操作に変更を加えるには、テストエグゼクティブ全体を更新する必要があります。

プロセスモデルを使用して一般的なタスクを実行すると、モジュール化と再利用性が向上します。これは、共通の操作を1か所のみで変更できるうえに、基になるテストエグゼクティブから分離したままにできるためです。

TestStandプロセスモデルは、プラグインアーキテクチャによってさらにモジュール化されています。 プロセスモデルは、プラグインシーケンスファイルを呼び出して、レポート生成やデータベースロギングなどの結果処理を実装します。 これらのプラグインを変更するか、独自のプラグインを作成して、プロセスモデル自体を変更せずにプロセスモデルの機能を拡張できます。

プロセスモデルは、プラグインを呼び出して、レポート生成やデータベースロギングなどの結果処理を実行します。 カスタムプラグインを作成して、カスタムのロギングメカニズムを実装することもできます

TestStandプロセスモデルを使用して、非常に強力で柔軟なテストアプリケーションを作成できます。プロセスモデルのモジュール式の実装により、フレームワーク機能を更新するときに行う必要のあるコード変更の量が最小限に抑えられます。TestStandプロセスモデルアーキテクチャを使用して完全なテストシステムを開発することで、時間、開発コスト、保守コストを節約できます。

TestStandでは、プロセスモデルは、プロセスモデルオプションを有効にしたシーケンスファイルとして実装されます。これにより、追加のタイプのモデル固有のシーケンスを含めることができます。 シーケンスファイルのタイプは、Sequence File PropertiesのAdvancedタブで構成します。これらのシーケンスタイプにはそれぞれ特定の動作があります。

• 実行エントリポイントを使用すると、ユーザは目的のプロセスモデルのシーケンスを使用してテストを実行できます。
• 構成エントリポイントは、ユーザがプロセスモデル設定を構成し、それらの設定を保存するためのユーザインタフェースを提供します。
• モデルコールバックを使用すると、テストシーケンスファイルでプロセスモデルの動作をオーバーライドできます。
  

シーケンスプロパティダイアログボックスのModelタブを使用して、プロセスモデルファイルに含めることができるシーケンスのタイプを構成します。

実行エントリポイントのシーケンス

実行エントリポイントは、ユーザがプロセスモデルを介してテストコードを実行する方法を提供します。デフォルトのTestStandプロセスモデルは、テストUUTとシングルパスの2つの実行エントリポイントを提供します。これらの各エントリポイントは、プロセスモデルのシーケンスファイルのシーケンスに実装されます。シーケンスエディターでは、アクティブなウィンドウにプロセスモデルを使用するシーケンスファイルが含まれている場合、Executeメニューに実行エントリポイントが一覧表示されます。

シーケンシャルプロセスモデルは、シングルパスおよびテストUUT実行エントリポイントを使用します。両方の実行エントリポイントは、クライアントシーケンスファイルのMainSequenceシーケンスを呼び出して、一度に1つのUUTのテストを実行します。エントリポイントは、テストレポートの生成やデータベースへのデータ結果の保存など、他のアクションも共有します。

シーケンシャルプロセスモデルにおけるシングルパスおよびテストUUT実行エントリポイントフロー

エントリポイント名の式は、エントリポイントの使用中にシーケンスエディターまたはユーザインタフェースに表示される名前です。この値を編集するには、シーケンスプロパティダイアログボックスのModelタブにあるEntry Point Name Expressionテキストボックスは、選択したシーケンスが実行エントリポイントである場合にのみ表示されます。を使用します。Entry Point Name Expressionテキストボックスは、選択したシーケンスが実行エントリポイントである場合にのみ表示されます。ResStr("MODEL", "TEST_UUTS")などのデフォルト値は、TestStandのローカライズ性を特徴付けるResStr関数を使用します。値を別のローカライズされた値に置き換えるか、ユーザの視点からエントリポイントを説明する定数文字列式を使用します。 

定数の代わりにローカリゼーション文字列を使用すると、プロセスモデル自体を変更することなく文字列値を変更できるというメリットがあります。ローカリゼーションにTestStandリソース文字列を使用する方法の詳細については、「Localizing TestStand to Different Languages」チュートリアルを参照してください。

構成エントリポイント

構成エントリポイントは、ユーザがプロセスモデルの設定を構成する方法を提供します。 デフォルトのモデルには、モデルオプションと結果処理エントリポイントが含まれています。 実行エントリポイントと同様に、構成エントリポイントはプロセスモデルファイルのシーケンスに実装され、シーケンスエディターのConfigureメニューに一覧表示されます。 設定を保存するために、モデルエントリポイントはTestStand構成ディレクトリの構成ファイルにデータを書き込みます。

モデルコールバック

モデルコールバックを使用すると、テスト開発者は、プロセスモデル自体に変更を加えることなく、特定のテスト用にプロセスモデルの特定の側面をカスタマイズできます。 プロセスモデルは、エントリポイントが実行のさまざまなポイントで呼び出すコールバックシーケンスを定義します。 たとえば、Test UUTエントリポイントは、テストを開始する前にPreUUTコールバックシーケンスを呼び出して、ユーザにシリアル番号を要求します。 テスト開発者がこの機能に特定の変更を加える必要がある場合、テストシーケンスファイルのコールバックをオーバーライドできます。 この場合、モデルがPreUUTシーケンスを呼び出すと、プロセスモデルファイルのPreUUTシーケンスの代わりに、テストシーケンスファイルのシーケンスが呼び出されます。

プロセスモデルのコールバックの詳細については、「Using Callbacks in NI TestStand」ドキュメントを参照してください。

テストシーケンスファイルは、プロセスモデルのコールバックシーケンスをオーバーライドして、カスタム動作を定義できます

プロセスモデルプラグイン

デフォルトのプロセスモデルは、プラグインアーキテクチャを使用して、レポート生成やデータベースロギングなどの結果処理を実装します。 各プラグインは、メインプロセスモデルのエントリポイントのさまざまなポイントで呼び出されるプラグインのエントリポイントのシーケンスを含む個別のシーケンスファイルに実装されます。 プロセスモデルには、テスト開発者がアクティブなプラグインやプラグイン設定を構成できるプラグイン構成ダイアログも用意されています。 

TestStandプロセスモデルプラグインアーキテクチャの詳細については、「Process Model Plug-in Architecture」ヘルプトピックを参照してください。 

追加のエンジンコールバック

プロセスモデルシーケンスファイルは、標準のシーケンスファイルでは利用できない追加のエンジンコールバックを提供します。 これらのコールバックは、接頭辞として「ProcessModel」が付いており、コールバックを定義したプロセスモデルの現在のクライアントシーケンスファイル内のステップに対してのみ実行されます。 たとえば、ProcessModelPostStepコールバックは、テストシーケンスで実行される各ステップの後に実行されますが、プロセスモデル自体のステップの後には実行されません。

これらのコールバックの一般的な用途は、カスタムエラー処理です。 通常、テスト開発者はエラーから可能な限り多くの情報を抽出し、エラーが発生したときのシステムの動作を制御する必要があります。他の使用例では、下請けの完全自動環境では通常、前のシステムをトレースしてエラーアクティビティをテストするために、適切なデバッグログを備えた開始/停止入力と赤/緑の光出力が必要です。

プロセスモデルレベルで定義されたProcessModelPostStepFailureおよびProcessModelPostStepRuntimeErrorエンジンコールバックを使用して、テストシーケンスのプログラマによる追加作業を必要とせずに、すべてのクライアントシーケンスファイルからのエラーを包括的に処理できます。これらのコールバックは、クライアントシーケンスファイルでエラーが発生した場合に実行されます。

多くの場合、TestStandに付属するプロセスモデルの機能を拡張または変更する必要があります。 プロセスモデルに対する一般的な変更としては、レポート、テストの再試行戦略、エラー処理とロギング、ステーションのキャリブレーションルーチン、およびUUT選択メカニズムの変更が挙げられます。

プロセスモデルプラグインを使用した新しい機能の追加

デフォルトのプロセスモデルは、プラグインを使用して、レポート生成やデータベースロギングなどの結果処理機能を実装します。 ただし、プラグインは結果処理のみに限定されません。 プロセスモデルに機能を追加する必要がある場合は、プロセスモデル自体を変更せずに、この機能を実装するプラグインを作成できます。 このアプローチには多くの利点があります。

• 各プラグインに変更を実装する代わりに、プラグインをシーケンシャルモデル、バッチモデル、パラレルモデルに簡単に統合できます。
• カスタマイズされたプロセスモデルを維持およびデプロイする必要はありません。
• カスタマイズを将来のプロセスモデルの変更と統合できます。
• プロセスモデルのコード変更を統合することなくプラグインを共有できます。

デフォルトでは、ユーザがプラグインを実行するには、モデルのプラグインのインスタンスを作成する必要があります。 このオプトインアプローチは、追加する新しい機能が特定の場合にのみ必要な場合に適しています。 プロセスモデル自体のコードと同様に、機能を常に実行する必要がある場合は、プロセスモデルプラグインのアドオンを使用できます。  モデルプラグインのアドオンは、標準のプラグインと同じ方法で実装されますが、プラグインのディレクトリのaddonsサブフォルダに保存されます。 プラグイン構成ダイアログには表示されず、常に実行されます。

新しいプラグインの作成

カスタム結果処理に加えて、さまざまな方法でモデルを拡張するカスタムプラグインを開発できます。 テストステーションのキャリブレーションは、カスタムプラグインを介してプロセスモデルに追加できる機能の一例です。 テストステーションでテストシーケンスファイルを実行する前に、ステーションのキャリブレーションの有効性を確認する必要がある場合があります。これらのルーチンは、通常、テスト装置が有効期限に基づいてキャリブレートされていることを確認します。キャリブレーションの期限が切れると、エラー状態がトリガーされ、オペレータに警告が表示され、テストが実行できなくなります。

カスタムモデルプラグインに機能を実装することで、必要に応じてユーザがキャリブレーションを無効にできるようにし、結果処理ダイアログを通じてテスト開発者に構成インターフェースを提供できます。 実装情報については、「Creating Process Model Plug-ins」トピックを参照してください。

UUTのシリアル番号の追跡など、プロセスモデルに直接実装されている動作を変更するには、モデルを直接変更する必要があります。新しいプロセスモデルを開発したり、既存のプロセスモデルをカスタマイズしたりするための開始点としてプロセスモデルのコピーを使用すると、デフォルトのプロセスモデルにすでに実装されている微調整された大量のロジックを再利用できるようになります。   

プロセスモデルを変更する前に、<TestStand>/Components/Modelsにあるモデルディレクトリ全体のコピーを、TestStandパブリックディレクトリの対応する場所である<TestStand Public>/Components/Modelsに作成します。 TestStandパブリックロケーションにあるファイルのみを変更します。

モデルのエントリポイントの変更

多くの場合、実行エントリポイントの実行フローをカスタマイズする必要があります。 たとえば、特定のタイプの障害が発生した場合にテストシステムでUUTのテストを自動的に再試行したり、再テストの必要性を判断するためにスーパーバイザの介入が必要となるまでのオペレータごとの再試行回数を制限したりできます。これらのタイプの変更では、エントリポイントシーケンスを直接変更して、ループやその他の条件を追加する必要があります。 エントリポイントを変更するときは、変更内容を文書化して、デフォルトの動作とカスタマイズを簡単に区別できるようにしてください。

テスト開発者がモデルの動作をカスタマイズできるようにする

プロセスモデルをカスタマイズするときは、特定のテストで、定義している動作の変更または無効化が必要かどうかを検討することが重要です。 テスト開発者が変更を行う必要がある場合は、既存または新しいコールバックシーケンスを使用して変更を実装します。 テスト開発者は、定義されている動作を変更する必要がある場合、コールバックをオーバーライドできます。 

新しい機能は必ず別のシーケンスに実装する必要があります。そのシーケンスは実装先のエントリポイントから呼び出します。テスト開発者に提供するカスタマイズのレベルに基づいて、次の方法でプロセスモデルにシーケンスを実装できます。

• テスト開発者が実行の特定の時点でモデルを拡張する方法を提供する場合:クライアントのシーケンスファイルが必要に応じて機能を挿入できるように、デフォルト機能のないプレースホルダーを実装します。エントリポイントからコールバックを呼び出すときに、オプションでパラメータをコールバックに渡して、関連するデータをテスト開発者に提供できます。 たとえば、ModifyReportHeaderはデフォルトの実装を提供していませんが、レポート関連データを含むパラメータがコールバックに渡され、テスト開発者がレポートにアクセスして変更できるようにしています。
• テスト開発者がカスタマイズまたは無効化できる機能を定義する場合: デフォルトの動作を実装して、クライアントコールバックがモデルコールバックを呼び出してプロセスモデルのデフォルト実装を実行し、クライアントコールバックが追加機能を実装できるようにします。デフォルトでは、PostUUTはバナーを実装して、テストシーケンスの結果を表示します。クライアントシーケンスファイルは、カスタムPostUUT動作を実装し、コールバックをオーバーライドしてもプロセスモデルの実装を呼び出すことでバナーを維持できます。 シーケンスプロパティのCopy Step and Locals when Creating an Overriding Sequenceオプションを使用して、テスト開発者がコールバックをオーバーライドしたときにシーケンスのコンテンツがコピーされるように指定できます。
• テスト開発者が機能を一切カスタマイズできないようにする場合:テスト開発者が変更してはいけない機能を定義する場合は、コールバックではなく通常のシーケンスを使用します。クライアントシーケンスファイルでは、コールバックをオーバーライドできません。

既存のモデルプラグインの動作のカスタマイズ

テストシステムの特定の要件に対処するために、フレームワーク開発者がレポート生成動作をカスタマイズすることは一般的です。 レポートのカスタマイズの詳細については、Advanced Architecture SeriesのNI TestStandレポートの生成およびカスタマイズの最善策に関するドキュメントを参照してください。 このドキュメントでは、TestStandモデルアーキテクチャ内でレポート生成のカスタマイズを実装する方法について詳しく説明しています。 

デフォルトのプロセスモデルは、現在のUUT、ステーション、モデルオプションに関する情報を格納するデータタイプを定義します。 場合によっては、これらのプロパティに追加データ、最も一般的にはUUTデータを格納する必要があります。 たとえば、デフォルトのTestStand UUT選択メカニズムはシリアル番号のみを追跡しますが、モデル番号も維持する必要がある場合があります。 

ナショナルインスツルメンツでは、できる限りモデルのデータ型を変更しないことをお勧めします。データ型は、さまざまなTestStandファイルで参照されており、更新を維持することが困難な場合があるためです。 ただし、プロセスモデルには、UUTおよびNI_StationInfoデータ型の非構造化プロパティがあります。このプロパティを使用すると、UUTデータ型を変更することなく、追加のUUTトラッキング情報を簡単に追加できます。UUT.AdditionalDataコンテナに新しいModelNumberプロパティを作成して、この情報を保存できます。 TestStandに付属する「Adding Custom Data to a Report」の例は、このプロパティを使用してフィールドをこのプロパティに追加し、それらをテストレポートに含める方法を示しています。 この例では、コールバックを使用してクライアントシーケンスファイルに更新を実装していますが、同じアプローチをプロセスモデルで直接使用することもできます。

<TestStand Public>\Components\Callbacks\StationディレクトリのStationCallbacks.seqに同じ名前で機能が異なるシーケンスを作成して、プロセスモデルシーケンスファイルのコールバックをオーバーライドすることもできます。TestStandは、任意のモデルに定義された同様の名前のコールバックを呼び出す代わりに、StationCallbacks.seqのモデルコールバックを呼び出します。クライアントファイルのコールバックは、モデルおよびStationCallbacks.seqファイルの同様の名前のコールバックをオーバーライドします。

TestStandを新しいバージョンにアップグレードする場合、デフォルトのプロセスモデルに加えた変更と、ナショナルインツルメンツが新しいバージョンで行った変更をマージする必要があります。 これを行うには、まず、シーケンスエディターのEdit→Diff Sequence File AgainstにあるTestStandのDiffツールを使用して、以前のデフォルトプロセスモデルと新しいデフォルトプロセスモデルの違いを確認します。すべての変更がプロセスモデルファイルの新しいシーケンスに一元化されている場合、またはプラグインに個別に実装されている場合、プロセスモデルのカスタマイズを新しいバージョンのプロセスモデルにインポートするのは比較的簡単な作業です。

2012より前のバージョンのTestStandで作成したモデルを移行する場合、プラグインアーキテクチャを実装するために、新しいモデルに大幅な変更が加えられています。 この場合のプロセスモデルの移行の詳細については、「Migrating Process Model Customizations to TestStand 2012 or Later」を参照してください。

NI TestStand上級開発者向けのトピックをカバーする、「TestStand Advanced Architecture Series」の追加ドキュメントを表示するには、ここをクリックしてください。