TestStandには、テストシーケンスのビルディングブロックとして機能する多数の内蔵ステップタイプが用意されています。TestStandでは、内蔵ステップタイプに加えて、カスタムステップタイプを作成して追加の機能を実装することができます。
カスタムステップタイプにより、既存のステップを以下の方法で拡張することができます。
ステップタイプを適切に設計すると、シーケンス開発を迅速に行うことができ、デバッグの労力が軽減され、開発者が標準化されたコードを共有できるようになるほか、複数のテストステーションおよび異なるグループの間に一貫性がもたらされます。ただし、カスタムステップタイプでは、計画、プログラム、デバッグ、デプロイ、および保守にかなりの時間がかかる場合があります。
この記事を読むには、カスタムステップタイプを作成する手順に精通している必要があります。この手順の詳細については、チュートリアル「波形のカスタムステップタイプの作成」を参照してください。
カスタムステップタイプの設計を開始する前に、新しい機能に適した他のアプローチを検討することをお勧めします。
カスタムステップタイプを作成または変更することは、次の場合にはお勧めしません。
以下の場合にステップタイプを作成または変更します。
ステップテンプレートを作成するには、シーケンス内でステップを作成して設定し、挿入パレットにあるテンプレートリストにドラッグアンドドロップします。TestStandがステップインスタンスのコピーを再利用可能なテンプレートとして保存するので、それを新規シーケンスにドラッグアンドドロップするだけで、新しいシーケンスをすぐに作成することができます。
ステップテンプレートとカスタムステップタイプの違いは、テンプレートは既存のステップタイプからのみ作成でき、テンプレートには元のステップタイプと同じ機能しか含まれていない点にあります。カスタムステップタイプが可能な範囲でステップテンプレートを変更または再設計することはできません。テンプレートリストに追加するステップでは、元のステップタイプの開発者が有効にした設定のみを構成できます。対照的に、新しいカスタムステップタイプを使用して、まったく新しい動作の完全に新しいステップを作成できます。また、ステップテンプレートへの変更は、今後作成されるステップのインスタンスにのみ影響し、そのステップの既存のインスタンスは変更しません。
ステップテンプレートを使用することにより、同じステップを同じ方法で再利用する場合に、ステップ設定を複数回カスタマイズする必要がなくなります。たとえば、IVI電源を5Vに設定してから3.3Vに設定し、シーケンス全体で何回も行う予定の場合、最初にステップを使用して構成した後に2つのステップテンプレートを作成すると、時間を節約できます。ただし、テストコードを実行する前に電源を最初に構成するステップが必要な場合は、カスタムステップタイプを作成することをお勧めします。
ステップテンプレート | カスタムステップタイプ |
|
|
カスタムステップタイプを設計するときは、フレームワーク開発者とテスト開発者の個々の役割を考慮してください。 フレームワーク開発者の役割は、ツールとビルディングブロックを開発することですが、テスト開発者の役割は、これらのツールを使用して実際のテストコードを実装することです。
カスタムステップタイプを設計するときは、自分がフレームワーク開発者の役割であることを意識します。そして、エンドユーザーであるテスト開発者の観点から、開発するステップタイプの機能を考慮することが重要です。
カスタムステップタイプの要件を決定する際は、これらのガイドラインを使用してください
カスタムステップタイプでは、ステップタイプのインスタンスの動作を構成し、ステップタイプの機能に必要なデータを管理するためのプロパティと設定にデータを格納します。詳しくは以下をご覧ください。
ビルトインステップタイププロパティはすべてのステップタイプに存在し、ユーザはステップタイプのインスタンスでこれらの設定を変更できません。 さらに、これらのプロパティの値に加えた変更は、ステップタイプのインスタンスに反映されます。
例: すべてのステップタイプで記述式が定義されます。これは、ステップのインスタンスの横にある [ステップ] ペインに表示されます。 このプロパティはすべてのステップタイプに存在しますが、値はステップタイプごとに設定されます。 ステップタイプのインスタンスでは、値は変更できません。
ステップタイプのビルトインプロパティにアクセスするには以下の手順に従います。
ステップタイププロパティダイアログボックス
このダイアログの設定のほとんどはデフォルト値であり、次のセクションで説明しています。 ビルトインプロパティは以下のとおりです。
記述はステップインスタンスでは構成できないため、ステップタイプの開発者として定義し、ユーザが自己文書化のステップを作成できるようにすることができます。 記述フィールドは、重要なステッププロパティを表示する動的な記述の作成を可能にする式によって指定されます。 ユーザがステップタイプのインスタンスでこれらのプロパティ値を変更すると記述が更新され、ステップ設定ペインに移動しなくてもステップの状態をすばやく確認できます。
例: 下の画像の2番目のステップのステップ記述はよりわかりやすく、適切に文書化しています。 この記述では、次の式を使用して記述を定義します。
"Calibrate Channels: " + Str(Step.minChannel) + " - " +Str(Step.maxChannel)
この式は、ユーザがminChannelおよびmaxChannelステッププロパティを構成する場合に、動的に更新されるように記述を設定します。
ステップ記述の例
ステップタイプを開発する場合、開発者はユーザが構成可能なすべてのステップ設定のデフォルト値を構成できます。 さらに、設定したデフォルト値を変更できないように、これらのプロパティをステップインスタンスで無効にするように構成できます。 ビルトインプロパティと同様に、デフォルト値はステッププロパティウィンドウで定義されます。 ただし、すべてのデフォルト値の設定には、設定名または構成されている設定タブのいずれかに「デフォルト」というワードが含まれています。
例: ステータス式プロパティは、ステップの結果を決定するために使用します。 このプロパティはすべてのステップタイプに存在しますが、デフォルト値はステップタイプごとに設定されます。 数値リミットテストなどのいくつかのステップタイプでは、ステータス式がステップタイプで無効になっているため、個々の数値リミットテストステップでは編集できません。
カスタムステップタイプを設計する場合、ステップタイプのインスタンス間で変化しないプロパティを無効にできます。 これにより、ステップタイプのユーザが動作を変更する方法をより詳細に制御できます。ただし、ユーザがステップ設定を編集できないようにすると、柔軟性が制限される可能性があるため、ユーザが変更する必要がないと確信できる設定のみを無効にしてください。
ステッププロパティのデフォルト値に今後加える変更は、ステップインスタンスでの編集を無効にした場合でも、ステップタイプのインスタンスには反映されないことに注意してください。この問題の軽減の詳細については、ステップタイプの更新と維持を参照してください。
これらのプロパティの値を使用して、ステップタイプの開発者による更新が必要になる可能性のあるステップタイプの機能を定義しないでください。 たとえば、ステップのPost式を使用して、ステップタイプ固有の機能を実装しないでください。 ステップタイプのバージョン変更時にこの機能を更新しなければならない場合に、ステップのインスタンスを更新する方法がなくなる場合があります。 代わりに、前または後のステップのサブステップで機能を実装します。
ビルトインプロパティに加えて、ステップタイプに固有のカスタムプロパティを定義できます。 これらのプロパティを使用して、ステップタイプの機能に特に関連するデータを保存します。
例: 数値リミットテストステップには、数値リミットステップタイプに固有のLimits.Highプロパティが含まれています。 タイプでこのプロパティのデフォルト値11を定義し、ユーザは作成した各インスタンスの値を変更できます。
カスタムステッププロパティを作成するには以下の手順に従います。
ステップタイプの結果コンテナでプロパティを定義すると、そのプロパティは結果コレクションに含まれます。 これで、IncludeInReportまたはIncludeInDatabaseフラグを使用して、データをレポートまたはデータベースに記録できます。
デフォルトでは、ユーザは各ステップインスタンスのステッププロパティ値を変更できます。 ただし、ステップタイプのステッププロパティに共有フラグを設定すると、値はステップタイプの値にロックされます。 ステップのデフォルト値とは異なり、値を更新すると、ステップタイプのインスタンスに反映されます。
ステッププロパティに選択するデータタイプは、ステップタイプの対象によって決定する必要があります。数値リミットテストと複数の数値リミットテストステップを例として考えてみます。 複数の数値リミットテストでは追加の制限に対応でき、より多くの機能を備えていますが、編集時のユーザインタフェースと結果のログ記録が複雑になります。 より基本的な数値リミットテストは、対象が小さく、インタフェースがはるかに単純です。開発作業が少なく済むだけでなく、対象が小さいステップは、テストシーケンス開発者にとっても使いやすくなります。
独自のカスタムステップタイプを開発する場合、選択したプロパティはステップタイプの複雑さに大きく影響するため、カスタムプロパティを定義する前にステップの対象を定義することが重要です。
次のセクションでは、サブステップを使用して以下のステップタイプの動作を実装する方法について説明します。
サブステップは、提供されているTestStandアダプタの1つを使用してコードモジュールを呼び出します。 ステップのインスタンスでサブステップを変更することはできません。サブステップ設定へのすべての変更は、ステップタイプのインスタンスに反映されます。
カスタムステップタイプにサブステップを追加するには以下の手順に従います。
複数の数値リミットテストステップタイプのサブステップの投稿と編集
プレステップおよびポストステップのサブステップを使用して、ステップタイプのランタイム機能を定義できます。 これらのサブステップは、ステップが実行されるときにメインコードモジュールの前または後に実行されます。
例メッセージポップアップステップタイプは、Cコードモジュールを使用して、実行時にメッセージボックスを作成および表示します。 このモジュールはポストステップサブステップで呼び出されます。
ステップ実行順序: サブステップ
これらのサブステップを使用して、ステップのすべてのインスタンスに適用される機能を定義します。 多くの場合、サブステップには、ステップタイプの動作に関連する特定のデータが必要です。 このデータをカスタムステッププロパティで定義して、ステップのすべてのインスタンスで使用できるようにします。
複数のプレステップまたはポストステップのサブステップが存在する場合、それらは [ステップタイププロパティ] ダイアログボックスの [サブステップ] タブに表示される順序で実行されます。
デフォルトでは、テスト開発者はステップタイプのインスタンスごとにコードモジュールを指定できます。 ステップタイプがコードモジュールを必要としない場合は、ステップタイプ構成の [プロパティの無効化] タブで [モジュールの指定] オプションを無効にする必要があります。 ステートメントやメッセージポップアップステップなど、多くのビルトインステップタイプはこのように設計されます。
TestStandは、続行する前に、プレステップまたはポストステップのサブステップのコードが実行されるのを待ちます。これらのステップのコードモジュールの動作が遅いかサイレントである場合、TestStandが応答していないように見えることがあります。これに対処するには、カーソルを変更するか、UIMsg_ProgressPercentなどのUIメッセージを使用して、ステータスバーの進行状況バーを更新します。
このアプローチの詳細については、UIメッセージを使用したステータスバーの更新を参照してください。
開発するコードモジュールには、ユーザがTestStandまたはTestStand APIのビルトインオプションを使用してシーケンスの実行を終了または中止したときに適切に処理するために、ターミネーションモニターを含め、定期的にポーリングする必要があります。 ターミネーションモニターを使用すると、ユーザがシーケンスの実行を終了した場合に、サブステップをすばやく終了できます。
コードへのターミネーションモニターの使用方法の詳細については、ターミネーションモニターの例を参照してください
ステップタイプに固有の基本操作のコードモジュールを、デフォルトモジュールとしてではなく、プレステップまたはポストステップのサブステップとして実装します。ステップの各インスタンスが異なるコードモジュールを呼び出すことができる場合にのみ、デフォルトのモジュール設定を使用します。デフォルトのモジュール設定は、ステップのすべてのインスタンスに個別に存在し、ステップタイプの設定を変更しても、TestStandはデフォルトで既存のステップインスタンスを更新しません。ただし、サブステップへの変更は、ステップタイプの既存のすべてのインスタンスに自動的に影響します。
編集サブステップは、コードモジュールに実装されたグラフィカルユーザインタフェース(GUI)を提供します。ユーザは、編集時にそのステップインスタンスの変数または設定を変更できます。通常、編集サブステップは、ステップタイプに定義するカスタムステッププロパティを構成するために使用されます。
例オープンデータベースのステップタイプは、編集サブステップを介してダイアログを提供し、ユーザがデータベースステップタイプのカスタムプロパティであるConnectionStringおよびDatabaseHandleステッププロパティを設定できるようにします。
編集サブステップでステップ設定を構成するためのユーザインタフェースを提供
ユーザがカスタムステップタイプのインスタンスを作成すると、ステップ設定ペインのボタンを使用して編集サブステップユーザインタフェースにアクセスでき、新しいウィンドウで編集サブステップUIが起動します。 ただし、多くのビルトインステップタイプのように、編集サブステップのユーザインタフェースをタブに直接埋め込むこともできます。 このアプローチには追加の開発作業が必要であり、.NET言語で開発する必要がありますが、ステップタイプのユーザに対し、よりシームレスな編集インタフェースを提供します。 埋め込み式編集サブステップインタフェースの実装方法の詳細については、シーケンスエディタでのカスタムステップタイプ編集タブの作成を参照してください。
埋め込み式の編集インタフェース(上)と別ウィンドウで起動する編集サブステップ(下)の比較
カスタムステップタイプは多くのプロパティを定義できるため、一度にすべてをユーザに表示すると混乱を招くおそれがあります。 別ウィンドウで起動する編集サブステップの一般的なアプローチを使用する場合、タブの導入などの単一の編集サブステップ内の編成方法により、データを管理可能なセクションに編成します。 各インタフェースを個別に起動する必要があるため、複数の編集サブステップを使用することはお勧めしません。 たとえば、Open SQL Statementステップは、複数のタブを持つ単一の編集サブステップを実装します。
Open SQL Statementステップの編集サブステップには、設定を分類する2つのタブが含まれる
複雑なステップタイプに埋め込み式のステップパネルアプローチを使用している場合は、データがステップタブに簡単に表示されるため、複数の編集パネルを使用すると便利です。たとえば、複数数値リミットテストステップには、数値データのソースと各データソースの制限条件を編集するための2つのタブが含まれています。
[リミット] タブと [データソース] タブは、それぞれ別の編集パネルに実装される
TestStandが編集サブステップを呼び出すと、シーケンスエディタが無効になるため、編集サブステップと他のユーザインタフェースコードモジュールはTestStandに対して常にモーダルにします。コードモジュールがモーダルでない場合、TestStandウィンドウはそのコードモジュールを非表示にします。その結果、ユーザがシーケンスエディタがハングしていると考え、TestStandを終了してしまうおそれがあります。
サブステップモジュールでモダリティを実装する方法の詳細については、 ダイアログボックスをTestStandに対してモーダルにするの例を参照してください。
編集サブステップUIで式フィールドを使用すると、ユーザにとってデータを操作する方法が柔軟になり、ユーザがプロパティ値で変数とロジックを使用できるようになります。 ただし、式のコントロールを使用すると、文字列または数値コントロールを使用するよりも多くの労力が必要になる可能性があり、式がプロパティの有効な値に対して評価されることを確認する追加のチェックが必要になります。
式は設定を指定する場合に固定値よりも柔軟性がある
テスト開発者がステップの新しいインスタンスを作成するときに発生する機能を、ユーザが定義したいというケースは多くあります。 たとえば、ビルトインのIfステップタイプでは、OnNewStepサブステップを使用して一致するEndステップを挿入します。
このタイプの機能を実装するには、編集サブステップを作成し、サブステップの名前を「OnNewStep」に変更します。 これらのサブステップは通常、TestStand APIを使用してステップインスタンスを操作したり、追加のステップインスタンスを作成したりします。
標準コードモジュールと同様に、TestStandデータをサブステップに提供するには2つの方法があります。 コードモジュールのパラメータを介してデータを渡すことができます。 または、コードモジュール内からTestStand APIを呼び出して、プロパティに直接アクセスして変更することもできます。通常、プレステップサブステップとポストステップサブステップが動作を決定するには、ステッププロパティを読み取るだけです。たとえば、加熱チャンバーを設定するための温度値が挙げられます。 ただし、編集サブステップでは、初期UIに表示するプロパティの現在の状態が必要ですが、ユーザが変更する値を更新する方法も必要です。
多くの場合、データにはTestStand APIで直接アクセスするのでなく、パラメータを使用してデータを渡すことをお勧めします。 パラメータを使用するとエラーが発生しにくくなります。プロパティはコードモジュール内に直接定義されるのではなく、TestStandのステップタイプ設定に定義されるため、プロパティ名やデータタイプのエラーが見つけやすくなります。さらに、ステップ構成ですべてのプロパティを定義すると、ステップタイプがより保守しやすくなります。 ステッププロパティの変更は、コードモジュールを変更せずに報告することができます。
ただし、APIを使用したプロパティへの直接アクセスは、コードモジュールがステップの状態に基づいてさまざまなデータに動的にアクセスする場合に役立ちます。 そのような場合にステップパラメータを使用すると、パラメータのリストが長くなりますが、実際には各種の条件によって一部のパラメータのみが使用されます。
モジュールアダプタは、コードモジュールの入出力に対してステップ変数の読み取りまたは書き込みを行い、エラーをチェックする
TestStand APIを使用してLabVIEW内からステッププロパティにアクセスしても、編集時にパラメータエラーチェックは行われない
カスタムステップタイプのサブステップのコードモジュールを開発およびテストする場合、サブステップの実行時にTestStandがコードモジュールをメモリにロードして予約することに注意してください。これにより、モジュールは後続の実行のためにロードされたままになるためパフォーマンスが向上しますが、TestStandがアンロードするまでコードモジュールを編集できません。次の2つの方法のいずれかでコードモジュールをアンロードできます。
作成するカスタムステップを保存および配布する方法を考えることは重要です。シーケンスファイルをロードすると、TestStandはタイプパレットファイルでステップタイプの更新を検索するため、NIではすべてのステップタイプをシーケンスファイル内ではなくタイプパレットファイルに作成することをお勧めします。TestStandは、シーケンスファイル内で使用される各ステップタイプのコピーを保持することにより、ステップの再利用を管理するのにも役立ちます。タイプパレットファイルなしでシーケンスファイルをデプロイしても、シーケンスファイルにはステップタイプのコピーが含まれたままです。
フレームワーク開発者によるステップタイプは、複数のテスト開発者によって使用されることが一般的です。 ステップタイプには多くの関連ファイルが存在するため、これは困難な場合があります。 ステップタイプのファイルを管理するには、次のディレクトリを使用して、ステップタイプのファイルを保存します。
これらのディレクトリを使用して、必要なファイルをテスト開発者システムのTestStandパブリックディレクトリに配布できます。 新しいタイプパレットファイルでタイプを定義した場合、タイプパレットファイル名に「Install_」のプレフィックスを追加することにより、タイプパレットを自動的にインポートするようにTestStandを構成できます。 この方法の詳細については、 タイプパレットファイルのヘルプトピックを参照してください。
カスタムプロパティのタイプを変更する必要がある場合は、新しいタイプの別のプロパティを作成し、以前のタイプのプロパティを保持することで、これを行うことができます。プロパティの名前またはデータタイプを変更すると、TestStandは、ステップインスタンスのプロパティの値をプロパティのデフォルト値と置き換えます。新しいタイプの新しいプロパティを作成することに加えて、ステップタイプにロジックを追加して、ステップが古いプロパティと新しいプロパティを使用するケースを処理できます。たとえば、TestStandがリミット値を式として実装する場合、古い数値リミットプロパティを使用するよう指定するために、2つの新しいブーリアンプロパティが追加されます。UseLowExprプロパティとUseHighExprプロパティは、古い数値リミットと新しい式リミットのどちらをステップで評価するかを決定します。