TestStandタイプの管理の最善策

TestStandは、さまざまなタイプのカテゴリを使用して、情報を保存し、ステップの動作を定義します。 データタイプは、テストシステムの開発および実行中の情報を保存します。ステップタイプは、ステップの動作と、ステップが実行中に収集する結果を定義します。 データタイプとステップタイプのどちらも、組込にしてTestStandに同梱することも、ユーザが開発したカスタムタイプにすることもできます。

TestStandタイプは、ステップタイプ、カスタムデータタイプ、および標準データタイプに分類されます。

データタイプ

多くの場合、テストデータを管理するには複雑なデータ構造を定義する必要があります。 データタイプを使用すると、これらのデータ構造を1か所で管理できます。 データタイプは、シーケンスファイルのグローバル変数、シーケンスのローカル変数、ステップのプロパティなど、TestStandのプロパティや変数の構造を定義します。 すべてのデータタイプには以下のコンポーネントがあります。

• タイプ名: タイプを一意に識別するために使用されます。 TestStandでは、同じ名前を持つ複数のタイプをメモリにロードすることはできません。
• バージョン: タイプのリビジョンを管理し、タイプの競合を解決するために使用されます。
• データ: タイプで定義されているプロパティの構造です。
• デフォルト値: ユーザがタイプペインで定義するプロパティ値で、タイプのインスタンスのデフォルト値として機能します。

通常、データタイプは、いくつかの異なるプロパティやコンテナを含む、関連する複雑なデータのセットを定義する場合に使用します。 たとえば、エラーデータタイプは、エラーが発生したかどうかを指定できるタイプのブールプロパティ、エラーメッセージを含めることができる文字列値プロパティ、エラーコードを定義できる整数プロパティの3つのプロパティで構成できます。

複雑なデータを管理する場合は、常にデータタイプを使用してください。これは、データタイプの構造を変更した場合に、新しいデータタイプの構造を反映するように、そのデータタイプのすべてのインスタンスが更新されるからです。 このため、データの構造を1か所で管理できます。 

標準データタイプ

標準データタイプは、TestStandに組み込まれている特定のデータタイプのセットであり、エラー、パス、波形などの一般的なタイプのデータを保存するための標準形式を定義します。 ほとんどの標準データタイプは変更できません。変更できるものもありますが、これらのタイプは他のTestStandコンポーネントによって広範囲に使用されるため、必要な場合にのみ変更してください。 

ステップタイプ

カスタムデータタイプから変数やプロパティを作成できるのと同じように、ステップタイプからステップを作成します。 ステップタイプはそれぞれ、一意の名前、組込およびカスタムのステップタイププロパティ、およびプロパティとステップタイプ操作のデフォルト値で構成されます。 すべてのステップタイプは、すべてのステップの基本操作とデータを定義する共通のプロパティセットを共有します。 これらの共通のプロパティを編集するには、ステップタイププロパティダイアログボックスを使用します。

このドキュメントでは、ステップタイプやデータタイプを含むすべてのタイプに適用される概念を中心に説明します。 ステップタイプの最善策の詳細については、「カスタムステップタイプの開発の最善策」ドキュメントを参照してください。

タイプを新規に作成するときは、タイプが保存されるディスク上の場所を考慮することが重要です。TestStandでは、タイプをシーケンスファイルまたはタイプパレットファイルに保存できます。 ほとんどの場合、作成したタイプはすべてタイプパレットファイルに保存してください。タイプパレットを使用すると、次の利点があります。

• タイプパレットファイルは、タイプを複数のシーケンスファイルに保存するための一元的な場所を提供します。
• タイプパレットファイルは、TestStandの起動時にメモリにロードされるように構成できます。これにより、すべての新しいシーケンスファイルでタイプを使用できるようになります。
• 複数の開発者が複数の場所に保存されているタイプに変更を加えると競合が生じる可能性がありますが、タイプを1か所で操作することはこうした競合の回避に役立ちます。
• TestStandのデフォルトでは、タイプパレットのタイプは自動的に更新されないため、不要なタイプの伝達から保護されます。

シーケンスファイルでタイプパレットファイルのタイプを使用すると、タイプパレットファイルがなくても機能するように、タイプのコピーがファイルに保存されます。ただし、タイプパレットでバージョンを使用してタイプに変更を加えるのみにしてください。 テストシーケンスをデプロイする場合、デプロイメントにタイプパレットファイルを含める必要はありません。 ただし、タイプパレットファイルを含めると、テストシステムに対する増分更新がより簡単に行えるようになります。 特定のタイプについて更新が必要な場合は、シーケンスファイルに変更を加えなくても、新しいバージョンのタイプパレットファイルを作成してデプロイできます。

複数の開発者間でタイプを共有する場合、それぞれの開発者が必ず同じ最新バージョンのタイプ定義を使用することが重要です。また、タイプに対する変更をまとめることは難しいため、開発者が同じタイプに対して個別に変更を加えないようにする必要もあります。 共有タイプを効果的に管理するには、次の手法を使用します。

• タイプパレットファイルの所有者を定義する。
• タイプパレットのソースコード管理を使用する。

タイプパレットファイルの所有権を定義する

タイプに対する変更を管理するには、それぞれのタイプについて、タイプに対する変更を実装または承認する明確な所有者を決めることが重要です。 大規模な組織では、多くの場合、グループのさまざまな個人にタイプの所有権を割り当てるのが適切です。 そこで、複数のタイプを論理グループにまとめる個別のタイプパレットファイルを作成すると便利です。たとえば、プロジェクト固有のタイプを、プロジェクト名を含むタイプパレットに保存し、複数のプロジェクトで使用するより一般的なタイプを、共有のタイプパレットファイルに保存できます。 そして、タイプパレットファイルごとに所有者を決めることができます。

タイプパレットファイルを論理グループにまとめると、タイプパレットファイルごとにタイプ所有者を割り当てる操作がもっと簡単になります。

ソースコード管理を使用してタイプパレットファイルへの変更を制限する

タイプバージョンに対する変更を細かく管理するには、ソースコード管理ソリューションを使用して、ファイルがチェックアウトされている場合にのみファイルを編集できるようにします。 ソースコード管理の権限を使用すると、特定のタイプパレットファイルの所有者のみに、変更をチェックインする権限を持たせることができます。 少なくともタイプパレットの所有者は、ファイルに関する通知を有効にする必要があります。これにより、ファイルに関係のあるアクティビティを認識できます。

ユーザは引き続き自分のローカルマシンでタイプを変更する権限を持ちますが、ソースコード管理を使用すると、TestStandでこれらの変更をディスクやファイルの共有バージョンに保存することができなくなります。 

関連のないタイプどうしの競合を防ぐ

関連のない複数のタイプに誤って同じ名前を付けたなどの場合に、タイプの競合が発生する可能性があります。タイプでは、システムでの一意の識別子としてタイプの名前が使用されます。そのため、新しいタイプを作成するときはタイプ名の前に一意の組織IDを付加します。 たとえば、TestStandに組み込まれているステップタイプの名前はすべて、「NI」という接頭辞で始まります。 こうすることで、コードをグループ間で共有する場合でも、タイプが組織外で作成されたタイプと競合しなくなります。

TestStandでは、特定の名前を持つタイプのバージョンが一度に1つだけロードされます。そのため、ステーションにロードされるすべてのファイルで同じタイプ情報が使用されます。 既にロードされているものと同じ名前のタイプを含むシーケンスファイルを開こうとしたりタイプパレットをロードしようとしたりすると、タイプの競合が発生します。その場合、TestStandで現在のタイプをロードしたままにするか、新しいタイプに置き換えるかを決める必要があります。 

ロードしようとしたファイルに、現在TestStandにロードされているものとは異なるタイプ定義が含まれていると、タイプの競合が発生します。 競合を解決しないと新しいファイルをロードすることはできません。

開発者が、一意のタイプ名を保持し、単一の管理されたタイプパレットファイルでタイプを保持するよう注意していれば、TestStandでタイプの競合が正しく処理されます。 しかし、自動のタイプ競合解決ルールや、開発者による誤った判断に基づいて、タイプの競合により誤った変更がファイルに加えられ、不要なタイプバージョンの伝達を招くことがあります。 

不要なタイプバージョンの伝達

不要なタイプの伝達が生じるケースでは、タイプの競合を解決する際に、異なるバージョンのタイプが含まれているファイルに対して望ましくない変更が発生します。正しくないタイプのファイルが共有されると、他の開発者が知らないうちに正しくないバージョンのタイプをロードしてしまう可能性があります。 ファイルを共有する開発者の数が多くなるにつれて、新しいタイプが多数のファイルに伝達され、正しくないタイプを持つすべてのファイルを見つけるのが困難になる恐れがあります。
こうした状況は、以下の状況で生じる競合を解決する際に発生する可能性があります。

• 互換性のないタイプが含まれている旧バージョンのTestStandのタイプをロードする。
• 同じ名前を持つ関連のないタイプを複数作成する。
• 複数の開発者がタイプに対して並行して変更を加える。

このセクションで説明する手法を使用して、タイプの競合が誤って処理されるケースを最小限に抑え、不要なタイプバージョンの伝達を防いでください。

タイプバージョンフィールドを維持する

TestStandのタイプでは、どのバージョンのタイプが最新かを判断するために、バージョンフィールドが使用されます。 タイプの最新バージョンがメモリにロードされている場合に、タイプの古いバージョンを使用するシーケンスファイルをロードすると、ステーションの設定に応じて、ファイルが自動的に更新され、新しいタイプのバージョンを使用できるようになります。 TestStandのデフォルトでは、タイプパレットファイルのタイプを更新しない競合が自動的に解決されます。

タイプバージョンが確実に更新されるように、TestStandでは、ユーザが変更済みタイプフラグを使用して編集したタイプが追跡されます。 このフラグを有効にしてタイプを保存すると、変更が加えられたことを示す警告が表示されます。 

TestStandでは、ユーザがタイプを変更する際、変更が意図したものであることを確認するために、保存前に警告が表示されます。

この場合、タイプバージョンの増分を選択する必要があります。これにより、TestStandにロードされるときにそのタイプを参照する他のファイルに、ユーザが加えた変更が確実に伝達されます。 ただし、設定を保存してプロンプトを表示しないオプションは選択しないでください。この警告はタイプに対する不要な変更を防ぐのに役立つからです。 変更が適切かどうかわからない場合は、ダイアログをキャンセルすると保存操作がキャンセルされ、タイプを調べて変更が有効かどうかを確認できます。

タイプの自動競合解決を構成する

場合によっては、タイプが競合する場合にTestStandでどのタイプをロードするかを自動的に決めることができます。 タイプの自動競合解決は、以下の条件が満たされる場合にのみ可能です。

• 2つのタイプのタイプバージョンが同じではない。
• どちらのタイプでも「変更済み」フラグがセットされていない。

TestStandには、タイプの自動競合解決を許可する（Allow Automatic Type Conflict Resolution）設定があり、どのような場合にTestStandでこれらの競合を自動的に解決するかを決定できます。 この設定には次の手順でアクセスします。

1. シーケンスエディタで、設定（Configure）→ステーションオプション（Station Options）を選択します。
2. ファイル（File）タブを選択します。

TestStandでは、どのような場合にタイプの競合を自動的に処理するか、および、どのような場合に開発者に対してどのタイプバージョンをメモリに保持するかを選択するよう求めるかを構成できます。

ほとんどの場合、この設定のデフォルト値を使用してください。この場合、タイプパレットファイルが変更される場合にのみプロンプトが表示されます。 この設定では、低い方のバージョンのタイプがタイプパレットファイルに保存されていない限り、高い方のバージョンのタイプが自動的に選択されます。 この設定があると、不要なタイプの伝達が生じる可能性がある場合にのみ、タイプの競合のプロンプトが表示されるようになります。 また、害のない競合（新しいバージョンのTestStandで古いNIタイプを持つ古いシーケンスファイルをロードするなど）が自動的に解決され、ユーザが判断をする必要がなくなります。

たとえば、開発者Aがステップタイプ「RunCalibration」を更新し、このタイプが会社のタイプパレットファイルCompany_types.iniに保存されているとします。 これについてタイプパレットファイルの所有者と話し合った結果、両者はタイプへの変更を保存し、タイプバージョンを1.0.1.0に増分することを選択します。 次に、更新されたタイプパレットをソースコード管理リポジトリに保存します。 後で、別の開発者Bがリポジトリと同期し、更新されたタイプを持つCompany_types.iniのバージョンを取得します。 その後、開発者がTestStandを開き、対象のタイプを参照するシーケンスファイルをロードします。 シーケンスファイルからはまだ以前のタイプバージョンを参照しているため、シーケンスファイル内の参照は自動的に更新されますが、これは望ましい動作です。

しかし、3人目の開発者Cも「RunCalibration」ステップを使用するシーケンスファイルを持っていて、タイプの所有者に相談せずに誤って「RunCalibration」ステップタイプを個別に変更し、自分のローカルインスタンスをバージョン1.1.0.0に更新したとします。 この開発者が、会社のタイプパレットファイルを同期させてからシーケンスファイルをTestStandにロードすると、新しいバージョンを使用する場合はタイプが変更されるため、タイプの競合を解決するよう求めるプロンプトが表示されます。 開発者Cは、タイプパレットファイルが更新されたことを知り、タイプパレットの所有者に連絡するか、タイプに加えたローカルの変更を元に戻します。

TestStandでタイプの競合を自動的に解決できない場合は、競合の解決方法を決めるよう求めるプロンプトが表示されます。

ファイルのタイプの競合（Type Conflict In File）ダイアログボックスを使用して、自動的に解決できないタイプの競合を解決します。

タイプの競合を解決する場合、2つのタイプのいずれかをロードするか、タイプの一方の名前を変更するか、またはファイルのオープンをキャンセルするかを選択できます。 使用するバージョンを選択すると、選択したタイプに合わせてメモリ内のすべてのインスタンスが変換されます。タイプの一方の名前を変更すると、TestStandによりメモリ内のインスタンスはロード済みのタイプを参照するように変更され、新しいファイル内のインスタンスはファイル内のタイプを参照するように変更されます。

タイプ固有の競合解決を設定する

厳密に管理された環境では、常に競合を解決するようユーザに求める（Always prompt the user to resolve the conflict）オプションを選択して、すべてのケースでタイプの自動競合解決を無効にすることを望むかもしれません。この場合、ユーザはタイプの競合が検出されたすべてのケースで競合を解決するよう求められ、どのタイプをロードするかを完全に制御できます。 しかし、そのために開発プロセスに余分な意思決定の過程が加わり、開発者が正しくない決定を行い、表示される多数のダイアログをほとんど確認しなくなる恐れがあります。 

厳密な管理を必要とするタイプの場合には、タイプ固有の設定を使用することをお勧めします。 この設定はタイプ設定のバージョン（Version）タブにあり、タイプを自動的に解決できるかどうかを指定できます。 この設定を使用すると、リスクの低いタイプの競合（新しいバージョンのTestStandに古いNIタイプを持つ古いシーケンスファイルをロードするなど）の場合に、必要のないユーザ操作が防止されると同時に、厳密に管理されたカスタムタイプを完全に制御できます。

より厳密な管理を必要とする特定のタイプについて、タイプの自動競合解決を無効にします。

不要なタイプバージョンが旧バージョンのTestStandへ伝達されるのを回避する

シーケンスファイルを旧バージョンのTestStandに保存することはできますが、一部のタイプは旧バージョンのTestStandで正しく実行されない可能性があるため、タイプを実行できる最も古いバージョンのTestStandを指定できます。タイププロパティ（Type Properties）ダイアログボックスのバージョン（Version）タブで、このタイプを使用できる最も古いTestStandバージョンを設定する（Set Earliest TestStand Version that can Use this Type）オプションを有効にし、最も古いバージョンをTestStandの現バージョンに設定します。これで、現バージョンのタイプが古いバージョンのTestStandで使用されることも、誤って古いバージョンに伝達されることもなくなります。

タイプを旧バージョンのTestStandで使用できるようにする必要がある場合は、タイプの別のバージョンを作成し、別のバージョンのTestStandで実行します。旧バージョンのTestStand用のシーケンスを保存すると、TestStandによって一連の互換性ディレクトリが検索され、シーケンスファイルの保存対象にする旧バージョンと互換性のあるタイプバージョンを見つけます。タイプパレットファイルのタイプはシーケンスファイルと共に<TestStand Public>\Components\Compatibility\<バージョン番号>ディレクトリと<TestStand Public>\Components\Compatibility\<バージョン番号>ディレクトリに保存されます。旧バージョンのTestStandのタイプパレットファイルを<TestStand Public>\Components\Compatibility\<バージョン番号>ディレクトリに置くと、正しいバージョンのタイプがシーケンスファイルと共に保存されるようになります。

開発者が組込のデータタイプ（標準データタイプやプロセスモデルのデータタイプなど）をカスタマイズする場合は注意が必要です。 CommonResultsなどのビルトインタイプの多くはTestStandの他のステップタイプやデータタイプで広範囲に使用されており、不要なタイプの伝達が生じる可能性が高くなります。

標準データタイプのカスタマイズに関する考慮事項

サードパーティ製品として配布する、または複数の組織で使用する、シーケンスファイルまたはタイプパレットファイルを作成する場合は、ビルトインタイプをカスタマイズしないでください。変更したビルトインタイプを持つファイルは、タイプの変更を認識させる単一の組織内に残してください。 シーケンスファイルやタイプパレットが配布された場合、他の組織では、タイプのカスタマイズが継承されます。または、他の組織におけるこれらのタイプのバージョンがファイルにロードされた場合、競合が発生します。 

ビルトインタイプに変更を加えると、そのタイプが使用されるすべてのテストステーションにこうした影響を与えます。このため、組織のテストアーキテクチャを把握する一元的な開発者またはアーキテクトを割り当てて、変更を最終的に承認してもらい、タイプ管理の問題を軽減してください。

プロセスモデルのデータタイプのカスタマイズに関する考慮事項

TestStandのプロセスモデルやプラグインシーケンスでは、プロセスモデルのデータ構造を定義するためにさまざまなデータタイプが使用されます。 たとえば、UUTデータタイプには、シリアル番号、製品番号、テストソケット指標などのデータが含まれています。 これらのタイプはカスタマイズできますが、必要な場合にのみ行ってください。 プロセスモデルのタイプはシーケンスファイルでのみ定義されており、一元的なタイプパレットはありません。 この理由から、デフォルトの自動競合解決設定ではTestStandによるこれらのタイプの自動更新が可能になるため、他のタイプよりも不要なタイプの伝達が容易に生じる可能性があります。
UUTまたはNI_StationInfoデータタイプに対してさらにデータを追加する必要がある場合は、AdditionalDataプロパティ（タイプで定義された非構造化コンテナ）を使用して、実行時にタイプのインスタンスにデータを追加できます。 このアプローチの詳細については、「プロセスモデルでUUTおよびテストステーションの追加情報を保存する」ヘルプトピックを参照してください。

NI TestStand上級者向けのトピックをカバーする、TestStand上級アーキテクチャシリーズの追加ドキュメントを表示するには、ここをクリックしてください。