このブログはもともとcimetrix.comに掲載されていました。
Cimetrix® 機器テスト
Cimetrix® EquipmentTestソフトウェア製品には、ユーザーの好みに合わせて詳細にカスタマイズ可能なユーザーインターフェースを作成する機能が備わっています。このユーザーインターフェースは、標準的な .NET 統合開発環境を使用して Microsoft Windows Presentation Framework (WPF) のユーザーコントロールとして作成され、EquipmentTest 内のデフォルトの「Tests」タブの後に個別のタブとして表示されます。また、タブのヘッダーも、さまざまなテストシナリオに合わせてカスタマイズすることが可能です。 なお、プラグイン内でカスタマイズされたGUIタブを開発するには、EquipmentTest Pro版が必要です。
この機能は、さまざまなユーザー層にとって有用です。例えば、製造工場では、設備に対して連続してテストを実行し、カスタムGUI機能を利用して出力ログをシステム上に個別のファイルとして保存することで、不合格ケースを効率的に特定することができます。設備メーカーは、この機能を活用してテストシナリオをカスタマイズし、過去のテスト出力データと最新の結果を比較できる形で結果を分析することができます。その他のユーザー層も、さまざまな追加の可能性を想像できるため、EquipmentTestは真に多用途なツールとなっています。
プラグインにカスタムGUIタブを追加する方法
PluginBaseModelクラスのOtherTabsプロパティをオーバーライドするか、または追加することで、必要な数のGUIタブを追加できます。以下の例には、両方のケースのコードスニペットが含まれています。
以下の画像は、カスタムGUIが単一のボタンを含むように変更された、2つのGUIタブを持つ一般的なプラグインを示しています。
プラグインにおけるカスタマイズされたGUIの用途
以下の段落では、EquipmentTestにおけるカスタマイズされたGUIの2つの優れた活用方法について論じる。
別のコントロールパネルを複製する
EquipmentTestを初めてご利用になる方は、カスタムGUI機能を使用して、他のテストシステムでお馴染みのインターフェースを再現することができます。 GUIはWPFで開発されているため、レイアウトや操作に関して高い柔軟性と制御性を発揮できます。これにより、ユーザーの選択に応じてテストを実行するように変更したり、選択したテスト固有の追加情報をGUIに表示したりすることが可能です。例えば、ログを修正して、デフォルト画面に現在表示されているものよりも詳細な情報を含めることもできます。
以下の画像は、TESTConnectのユーザーインターフェースと、EquipmentTest上で再現されたGUIを示しています。もちろん完全な複製ではありませんが、元の機能の大部分はサポート可能です。また、一定の努力を払えば、GUIを完全一致するように変更することも可能です。
オンザフライコンパイル
EquipmentTestのカスタムGUI機能は、.NETのコンパイルオンザフライ機能の利用を可能にします。テストコードを動的に記述・実行できるため、変更が必要になるたびにプラグインを編集・再構築・再ロードすることなくテストシナリオを変更できます。これにより、より迅速かつ効率的なテストプロセスが実現します。
以下に定義する「コンパイル」メソッドは、実行対象のテストコードをパラメータとして受け取ります。その後、必要な参照を含むDLLライブラリを作成するためにコンパイルされます。コンパイルエラーが発生した場合は、イベントハンドラ「WriteLog」を通じてGUI上の指定されたTextBoxに書き込まれます。
以下の画像は、動的にコードを実行するための追加カスタムコントロールパネルを備えたGEMプラグインです。テキストボックスはコード記述専用であり、各種ボタンはテスト手順の制御に使用されます。この例は、EquipmentTestにおけるTESTConnectスクリプトの直接実行をサポートするプロジェクトの一部です。
最初のタスクは、引数として渡すTESTConnectスクリプトの変換済みC#テストコードを含むXMLファイルを生成するコンソールアプリケーションの作成でした。次のタスクは、XMLファイルを読み込み、各スクリプトを下記のサンプルGUI上で個別のテストとして表示するEquipmentTestプラグインの開発でした。このサンプルは任意の数のテストをサポートするよう設計されており、「新規」ボタンを使用して新しいテストを追加できます。 これにより、メッセージ送信コードを直接記述し、返信メッセージが期待通りか確認できます。また、このメッセージングコードを再利用するためのラッパーメソッドを定義し、類似ユースケースの開発プロセスを高速化しています。コンソール出力はログ用テキストボックスへリダイレクト可能で、メッセージ詳細を記録するラッパーメソッドも定義できます。この機能によりEquipmentTestでのスクリプティングが実質的に可能になりますが、対処すべき欠点もいくつか存在します。 新しいAPIメソッドを使用する必要がある場合、テストを継続するにはプラグインに必要なライブラリの参照を追加し、再構築して再度ロードする必要があります。有効な解決策として、「保存」ボタンを設置し、初期にロードしたXMLファイルと同様の形式で現在の変更内容を保存できるようにします。これにより、ライブラリ参照を追加後、直接そのファイルをロードできます。もう一つの問題は、Visual Studioで記述されたコードの見た目が、EquipmentTestのテキストボックスとは異なる点です。
しかし、全体像はここで説明した内容よりもはるかに大きいものです。 EquipmentTestは自由にカスタマイズ可能で、任意の方法でテストを実行できます。テストコードを書くスペースが不足する場合は、コンピュータ上のC#ファイルでコードを編集し、EquipmentTestから直接実行できます。EquipmentTestのGUI上のテキストボックスにコードを表示するかどうかは任意です。さらに、生成された出力ログをローカルファイルに保存することも可能です。この機能の詳細な活用方法は、ユーザー次第です。
結論
前の段落では、カスタムGUIプラグインの定義と専用GUIタブからのアクセス方法について説明しました。これはEquipmentTestの全ユーザーに幅広い可能性を開く強力な機能です。この機能を探索し、テストの生産性向上に活用することで、結果を得るために必要な全体的な労力を削減できることを強く推奨します。EquipmentTestのドキュメントは追加情報の優れた情報源であり、ぜひお試しいただくよう心から願っております！