TestStandシステムデプロイメントの最善策

一般に、テストシステムは数多くのコンポーネントとファイルが含まれる複雑なシステムです。稼働システムでテストをスムーズに行うためには、これらすべてを適切にデプロイする必要があります。ここでは、製品のテストで使用されるソフトウェアコンポーネントに限定して説明します。

TestStandシステムには数多くのコンポーネントがあり、これらをデプロイメントに含める必要がある

TestStandテストシステムの主なコンポーネントは、テストコード、テストフレームワークファイル、ドライバとランタイムエンジンです。

テストコード

テストコードには、実際のテストを実装するために作成するシーケンスファイルとコードモジュールが含まれます。テストコードをデプロイする場合、コードモジュールのすべての必要な依存項目を含める必要があります。また、ファイルをディスク上の適切な場所にデプロイして呼び出し側がファイルを見つけられるようにする必要があります。通常、テストコードには、1つ以上のシーケンスファイルとその参照ファイルが含まれます。 

シーケンスファイル

シーケンスファイルは、シーケンスファイルが呼び出すコードモジュール、シーケンスファイルの依存項目、プロパティローダファイルなどの補助的ファイルに依存します。TestStandデプロイメントユーティリティを使用すると、シーケンスファイルを解析してこれらの依存項目を列挙できます。ただし、TestStandデプロイメントユーティリティは、TestStandの式で指定するプロパティファイルのように動的に参照される依存項目や、テストドキュメントのように内部的に参照されるファイルは認識しません。

そのため、できれば各シーケンスファイルのすべての依存ファイルをそのシーケンスファイルのパスの下のサブディレクトリに保存する必要があります。このようなディレクトリ構成には次のような利点があります。

• 参照ファイルは、参照元のシーケンスファイルの相対パスを使用して参照されるため、シーケンスファイルと依存項目を別の場所にコピーしてもパスの有効性が保たれます。
• 依存項目のディレクトリ全体をデプロイできるため、動的に呼び出される依存項目や内部的に参照される依存項目の追跡がずっと容易になります。

コードモジュール自体の依存項目も考慮する必要があります。これらの依存項目をデプロイする手順は、コードモジュールのタイプによって異なります。

LabVIEWのコードモジュール

LabVIEWのコードモジュールには、VI、LabVIEWクラスメンバー呼び出し、Express VI呼び出し、プロパティノード呼び出しなどがあります。LabVIEWパッケージがインストールされていないシステムでLabVIEWのコードモジュールを実行するには、VIコードモジュールのすべての依存項目が同じバージョンのLabVIEWに保存されている必要があります。また、LabVIEWインストールのvi.libディレクトリやinstr.libディレクトリにあるVIなど、LabVIEWパッケージに付属している依存VIもデプロイメントに含める必要があります。以下の方法により、上記の2つの条件を満たすことができます。

• すべてのコードモジュールVIを含むLabVIEWソース配布を作成し、vi.lib、instr.lib、およびuser.libを除外するオプションを選択しません。ソースVIとソース配布に含まれるVIとの相互リンクを防ぐため、新規のプロジェクトライブラリにファイルを追加します。
• ソースファイル用に1つ以上のパックプロジェクトライブラリ（PPL）を作成します。PPLは、すべてのVIとその依存項目を1つのファイルにコンパイルしたものです。この方法では、デプロイしたPPLを更新済みのバージョンで置き換えることによって、既存のデプロイメントを更新できます。

* PPLには、DLL形式の依存項目や、すでにPPLにコンパイルされているVIは含まれません。

TestStandデプロイメントユーティリティを使用して、LabVIEWコードモジュールを呼び出すシーケンスファイルをデプロイすることで、このプロセスの多くを自動的に処理できます。TestStandデプロイメントユーティリティは、すべてのVIを特定バージョンのLabVIEWに保存します。また、このユーティリティには、LabVIEW ADEの一部として必要な依存項目がすべて含まれています。このデプロイメントユーティリティには、パックプロジェクトライブラリ（PPL）を生成するオプションもあります。詳細については、「Deploying VIs in LabVIEW Packed Project Libraries」を参照してください。

C/C++ DLL依存項目

通常、依存項目のDLLはすべてビルドディレクトリにコピーされますが、必要なランタイムエンジンと共にシステムディレクトリに含まれる場合もあります。できれば、DLLまたは他のバイナリをWindowsのシステムディレクトリに直接デプロイするのではなく、これらの依存項目をインストールするソフトウェアを決定してデプロイメントに含めてください。追加ソフトウェアのデプロイメントの詳細については、以下の「ドライバとランタイムエンジン」セクションを参照してください。

.NET依存項目

アンマネージドC/C ++ DLLと同様に、マネージド.NET DLLは、ADEなしで実行できるコンパイル済みコードです。C/C ++ DLLとは異なり、.NETアセンブリはグローバルアセンブリキャッシュ（GAC）内の依存アセンブリを参照する場合があります。このGACには、ドライバまたはランタイムソフトウェアと共にインストールされるアセンブリを含めることができますが、独自のコードを含めることもできます。

.NETアセンブリをビルドする場合、参照するアセンブリの「ローカルのコピー」プロパティを使用して、参照元アセンブリの隣にそのコピーを含めることができます。この場合には、アセンブリと依存項目を含むフォルダをデプロイすることによって、.NET依存項目を確実にデプロイできます。

テストフレームワークのファイル

テストコードに加え、TestStandフレームワークのファイルもデプロイする必要があります。デプロイメントにTestStandランタイムを含めると、これらのファイルのデフォルトバージョンがシステムにインストールされます。ただし、これらのコンポーネントのカスタマイズバージョンがある場合は、それをテストシステムのデプロイメントに含める必要があります。 

TestStand構成ファイル

TestStand構成ファイルには、TestStandのローカルインストールの設定が保存されます。 このファイルにテストシステムの動作を記述して、テストシステムを駆動します。TestStand構成ファイルは、<TestStand Application Data>\Cfgディレクトリにあります。

TestStandに含まれる構成ファイルの詳細および各ファイルに保存される情報については、「構成ファイル」ヘルプトピックを参照してください。

TestStandコンポーネント

TestStandコンポーネントは、テストシステムの高いレベルの実行を実装する機能です。TestStandアーキテクチャのモジュール性を高めるため、テストシーケンスからは切り離されています。TestStandコンポーネントは、ログイン/ログアウト操作、レポート、データベースロギング、シリアル番号入力などの機能を実装します。これらのファイルは、<TestStand>\Componentsディレクトリにあります。

TestStandのComponentsディレクトリに含まれる項目については、「Componentsディレクティブ」ヘルプトピックを参照してください。

TestStandユーザインタフェース

シーケンスエディタを使用できるのは開発マシンだけです。そのため、デプロイ先のマシンでシーケンスを実行するには、少なくともユーザインタフェースを1つデプロイする必要があります。ユーザインタフェースは、必要に応じてシンプルにすることも、高度にカスタマイズすることもできます。TestStandにはユーザインタフェースアプリケーションが含まれおり、<TestStand Public>/UserInterfacesにデプロイできます。

デプロイ先マシンで使用するTestStandユーザインタフェースの作成の詳細については、「TestStand User Interface Development Best Practices」ドキュメントを参照してください。

ドライバとランタイムエンジン

稼働システムでシーケンスとテストコードを実行するには、必要なすべてのランタイムエンジン（ランタイム）とハードウェアドライバをインストールする必要があります。ランタイムエンジンは、DLL、VI、シーケンスファイルなどのソフトウェアコンポーネントを実行するのに必要です。テストシステムで使用するハードウェアコンポーネントには、ドライバが必要です。TestStandランタイムには、TestStandのエンジンとサポートファイルが含まれています。そのため、必ずこのランタイムをデプロイする必要があります。 

TestStandデプロイメントユーティリティを使用してデプロイすると、コードモジュールがドライバとランタイムを参照する際に必要なバージョンを検出してそれを含める選択ができます。検出されたランタイムを含めない場合には、デプロイメントに含めるバージョンを確認する情報ログメッセージが表示されます。

ソフトウェアライセンス

デプロイしたマシンでは、適切なソフトウェアライセンスが利用できなければなりません。デプロイした各マシンには最低限、ベースデプロイメントライセンスが必要です。このライセンスではシーケンスの実行が可能ですが、開発はできません。LabVIEWおよびLabWindows/CVIランタイムなどの多くのランタイムエンジンには、ライセンス要件はありません。デプロイするコンポーネントを追加する場合は、そのドキュメントを参照して、必要なデプロイメントライセンスを取得してください。デプロイするアプリケーションでライセンスが必要なNI製品のリストについては、「NIソフトウェア用デバッグ/デプロイメントライセンス」ヘルプトピックの「デプロイメントライセンス」セクションを参照してください。

多数の稼働コンピュータにデプロイする場合、ナショナルインスツルメンツのボリュームライセンスを利用すれば、中央のライセンスサーバを介してライセンスを管理できます。ボリュームライセンスオプションの詳細については、「ソフトウェア向けボリュームライセンスプログラム」のページを参照してください。

テストシステムのデプロイメントに含める一連のファイルの定義が完了したら、稼働コンピュータにこれらのファイルをデプロイする方法を選択する必要があります。この章の各セクションでは、次のデプロイメント方法について説明します。

• NIパッケージベースのデプロイメント
• インストーラベースのデプロイメント
• ネットワークドライブのデプロイメント

NIパッケージベースのデプロイメント

NIパッケージでは、デプロイメントのすべてのファイルを1つのファイルに統合するメカニズムを利用できます。NIパッケージマネージャを使用してデプロイすることにより、各ファイルを稼働コンピュータの適切な場所に抽出できます。TestStandデプロイメントユーティリティを使用すると、デプロイメントのすべてのファイルを含むパッケージをビルドできます。パッケージベースのデプロイメントでは、デプロイメントに必要なドライバとコンポーネントはパッケージの依存項目として参照されますが、パッケージ自体には含まれません。 

稼働コンピュータにパッケージをインストールすると、NIパッケージマネージャがこれらの依存項目を検出します。これにより必要なドライバとコンポーネントのパッケージをダウンロードしてインストールできます。SystemLinkソフトウェアを使用すると、組織内のNIパッケージのリポジトリを利用できるため、その中に作成するNIパッケージを含めることもできます。SystemLinkを使用したパッケージベースのデプロイメント管理方法の詳細については、「SystemLinkを使ってシステムを構成し、ソフトウェアを実装する方法」を参照してください。

NIの各パッケージはそれぞれが1個のコンポーネントであるため、パッケージベースのデプロイメントでは、更新後のバージョン番号を付した新しいバージョンのパッケージを作成することによって更新を適用できます。新しいバージョンのテストと検証が完了すると、従来型のファイル転送やSystemLink経由の方法により、稼働コンピュータにパッケージを配布できます。

インストーラベースのデプロイメント

ファイルをデプロイするもう1つの方法は、デプロイメントに必要なすべてのコンポーネントを含むインストーラを作成することです。このインストーラをテストステーションコンピュータにコピーしてインストールします。パッケージとは異なり、必要なドライバとコンポーネントをインストーラに含めることができます。これらのコンポーネントを含めると、インストーラのディスク上のサイズはずっと大きくなりますが、ドライバとランタイムエンジンも含まれているため直ちに利用できるようになります。TestStandデプロイメントユーティリティを使用すると、Microsoftのインストーラ技術の知識がなくてもTestStandシステム用インストーラを作成できます。このユーティリティには次のような機能があります。

• <TestStand>ディレクトリや<Desktop>ディレクトリなど、ターゲットコンピュータの指定ディレクトリにファイルを配布する。
• Measurement and Automation Explorer（MAX）で生成したハードウェア構成をインポートする。
• ドライバやランタイムなどの追加コンポーネントを含めることができる。 
•  既存のデプロイメントに更新を適用するパッチインストーラを作成できる。

TestStandデプロイメントユーティリティで利用可能な機能の詳細については、TestStandのヘルプトピック「Building an Installer with the TestStand Deployment Utility」を参照してください。TestStandデプロイメントユーティリティには、カスタムのデプロイメントインストーラを作成するために必要なほとんどの機能があります。デプロイメントインストーラの機能をさらに追加する必要がある場合には、他社製ツールを使用してインストーラを作成することもできます。詳細については、「Building an Installer with Third-Party Tools」を参照してください。

既存のインストーラに更新を適用する場合、TestStandデプロイメントユーティリティを使用すると、更新するコンポーネントのみを含むパッチインストーラを作成できます。パッチインストーラ作成の詳細については、「Patching Deployments」ヘルプトピックを参照してください。また、インストーラを複数作成してデプロイメントをモジュール化することもできます。たとえば、テストコード用、TestStandコンポーネント用、ドライバとランタイムエンジン用というようにインストーラを別個に作成します。この方法では、変更が必要なインストーラのみ更新して配布できます。

インストーラはファイルを適切な場所に自動的に配置し、必要なドライバとランタイムエンジンを含めることができるため、適切に機能するインストーラが完成すれば、システムを簡単にデプロイできるようになります。ただし、インストーラベースのデプロイメントでは、各テストコンピュータに移動してインストールする必要があるため、通常、少数のテストコンピュータで使用するデプロイメントに最適です。 

ネットワークドライブのデプロイメント

ネットワークドライブデプロイメントアーキテクチャでは、ファイルをインストーラに統合するのではなく、ネットワークドライブを使用してテストステーションコンピュータ間でファイルを共有します。ネットワークドライブ上のファイルへのアクセスは、ソースコード管理ソリューションによって管理できます。この方法では、テストの開発者はファイルの作成と更新を共有リポジトリで行います。テストの完了後、これらのファイルを稼働マシンにコピーする場合と、ネットワーク上のファイルをそのまま使用する場合があります。 

ネットワークドライブデプロイメントでは、開発、ステージング、稼働の各環境のコンピュータが共有リポジトリを使用してファイルを共有する

新しいテストコードを開発する場合、テストと検証が完了するまで、開発中のコードがデプロイ先のシステムで使用されないようにすることが重要です。通常、テスト用ハードウェアにアクセスできる稼働コンピュータはステージングテスタとして指定され、リリース前のテストシステムの検証とテストを行うために使用されます。ステージングテスタでの検証が完了すれば、テストシステムを稼働マシンにデプロイできます。

デプロイするコードを検証する最も良い方法は、テストステーションに更新を適用する頻度によって異なります。

頻繁に更新する必要がある場合には、継続的インテグレーション/継続的デリバリ（CI/CD）方式が適しています。この方式では、テストコンピュータで最新のコードを利用できる上、コードのテストと検証を適切に行うことができます。CI/CDアプローチでは、更新のビルド、テスト、デプロイメントの各手順の多くが自動化されるため、コードをテストする際のオーバーヘッドが最小化されます。Jenkinsなどの他社製ツールを使用することで、このような自動化を実装できます。 

厳格に管理された環境では、通常、検証要件がきわめて厳しいため、テストシステムを頻繁に更新できません。このようなテストシステムの場合、開発者がテストへの変更や新しい機能の追加を行う場所として、別個のリポジトリまたはトランクを定義します。テストシステムの最新バージョンが完成し検証が終わると、開発者は稼働マシンで使用するためにトランクのバージョン付きブランチを作成します。このブランチは、検証済みのコードが変更されないように、ソースコード管理内でロックする必要があります。新しいブランチが完成し検証が終わったら、このコードを含む新しいバージョン付きブランチを作成します。

このテストコードをデプロイするときは、このバージョン付きコードを稼働マシンにコピーします。コピーしたコードは、変更されないように読み取り専用にする必要があります。さらに、検証済みのコードが変更されるのを防ぐため、すべてのチェックサムを検証するコードをテストシーケンスに追加することもできます。この方法の詳細については、ドキュメント「Verification and Validation with TestStand」を参照してください。

ネットワークドライブデプロイメントでドライバおよびランタイムエンジンをデプロイする方法

ネットワークドライブベースの方法を採用する場合、必要なドライバとランタイムをテストコンピュータにインストールするには、別の方法を採用する必要があります。ランタイムエンジンとドライバをデプロイする方法には、次のようなものがあります。

• 必要なソフトウェアを含むインストーラを作成する（TestStandデプロイメントユーティリティにより、ランタイムエンジンとドライバを含むインストーラを生成できる）。
• 必要なすべてのドライバとランタイムがインストールされているシステムをベースとしてシステムイメージを作成する。

最も良い方法は、主にシステムの更新頻度によって決まります。多くの場合、複数の方法を組み合わせることができます。ドライバとランタイムのデプロイ方法の選択についての次の一般的なシナリオは次のとおりです。

• 更新頻度が少ないシステムの場合、通常はイメージを作成した方がROIが向上します。ただし、テストシステムの更新が軽微であれば、イメージを更新しなくても実装できます。
• 更新頻度が多いシステムの場合は、必要なドライバとランタイムを含むテストシステム用のインストーラを作成します。

テストシステムのファイルにアクセスする方法

ネットワークドライブデプロイメントでは、次の一般的な方法のいずれかにより、ファイルストレージを管理できます。

• ネットワークドライブ経由で直接ファイルにアクセスする。
• 他社製ツールを使用してネットワークドライブからファイルをローカルにコピーし、ローカルのファイルとネットワークドライブを同期させる。
  
  

ネットワークドライブ経由で直接ファイルにアクセスする

ネットワークドライブのファイルに直接アクセスする利点は、ネットワークドライブでファイルを更新すれば、すべてのテストコンピュータに更新が適用されることです。ただし、ネットワークドライブのファイルに直接アクセスする場合、共有ドライブおよびネットワーク接続の稼働状況によって、テストステーションでの操作が影響を受けます。いずれかが利用できない場合、製造部門のオペレータはテストステーションからテストファイルを実行できず、製造ラインが停止する可能性があります。そのため、IT部門と協力して、共有ドライブとネットワークの両方のアップタイム要件が確実に満たされるようにすることが重要です。たとえば、サーバの冗長性を利用して共有ドライブのアップタイム要件を満たすことができます。 

TestStand構成ファイルとコンポーネントの保存に共有ドライブを使用する場合は、TestStand環境の機能を利用して、TestStandディレクトリの場所を指定する必要があります。この機能を利用するためには、TestStandディレクトリ用のネットワークドライブの場所を指定する環境ファイル（tsenv）を作成する必要があります。このファイルの作成および使用方法の詳細については、「TestStand環境」ヘルプトピックを参照してください。

ローカルの各テストステーションにファイルをコピーする

デプロイするすべてのファイルのローカルコピーを作成する選択も可能です。この方法には次の利点があります。

• テストステーションが常時ネットワークに接続されていない場合でも、テストを実行できる。
• テストシステムファイルのロード時間を短縮できる。

ただし、この方法では、すべてのテストステーションでファイルをコピーするという追加作業が必要です。また、テストを実行する前に、すべてのテストシステムが最新のファイルで構成されていることを確認する必要もあります。

テストステーションを起動するたびに、テストステーション上のファイルのバージョンを共有ドライブのものと自動的に比較し、旧バージョンのものがあれば最新のファイルをダウンロードするような、追加ツールを作成することもできます。

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