Empfohlene Methoden für die TestStand-Systembereitstellung

Ein Testsystem ist in der Regel komplex und enthält viele Komponenten und Dateien. Diese müssen alle ordnungsgemäß bereitgestellt werden, damit der Test auf einem Produktionssystem reibungslos ausgeführt wird. In diesem Dokument werden nur die Softwarekomponenten behandelt, die zum Testen eines Produkts verwendet werden.

TestStand-Systeme umfassen viele Komponenten, die in einer Bereitstellung enthalten sein müssen.

Die Hauptkomponenten eines TestStand-Testsystems sind Testcode, Test-Framework-Dateien sowie Treiber und Runtime-Engines.

Testcode

Der Testcode enthält die Sequenzdateien und Codemodule, die Sie zur Implementierung der eigentlichen Tests erstellen. Bei der Bereitstellung von Testcode müssen Sie sicherstellen, dass alle erforderlichen Abhängigkeiten der Codemodule enthalten sind und dass Dateien an den richtigen Speicherorten auf dem Datenträger bereitgestellt werden, damit sie von ihren Aufrufern gefunden werden können. Normalerweise enthält der Testcode mindestens eine Sequenzdatei zusammen mit den jeweils referenzierten Dateien. 

Sequenzdateien

Sequenzdateien hängen von den von ihnen aufgerufenen Codemodulen, den Abhängigkeiten von Sequenzdateien und von ergänzenden Dateien wie Property Loader-Dateien ab. Mit dem TestStand Deployment Utility können Sie Sequenzdateien analysieren und diese Abhängigkeiten auflisten. Dynamisch referenzierte Abhängigkeiten, wie eine durch einen TestStand-Ausdruck angegebene Eigenschaftendatei, oder implizit referenzierte Dateien, wie Testdokumentation, werden vom TestStand Deployment Utility nicht erkannt.

Nach Möglichkeit sollten Sie alle abhängigen Dateien für eine bestimmte Sequenzdatei in einem Unterverzeichnis unter dem Pfad der Sequenzdatei speichern. Diese Struktur bietet die folgenden Vorteile:

• Die Dateien können mit einem relativen Pfad zur aktuellen Sequenzdatei referenziert werden, um sicherzustellen, dass die Pfade gültig bleiben, wenn Sie die Sequenzdatei und Abhängigkeiten an einen anderen Speicherort kopieren.
• Das Verfolgen von dynamisch aufgerufenen und impliziten Abhängigkeiten ist viel einfacher, da Sie das Abhängigkeitsverzeichnis als Ganzes bereitstellen können.

Berücksichtigen Sie auch die Abhängigkeiten der Codemodule selbst. Der Prozess zum Bereitstellen dieser Abhängigkeiten hängt vom Modultyp ab.

LabVIEW-Codemodule

LabVIEW-Codemodule umfassen VIs, Aufrufe von LabVIEW-Klassenbestandteilen, Express-VI-Aufrufe und Eigenschaftsknotenaufrufe. Um LabVIEW-Codemodule auf einem System ohne installiertes LabVIEW-Entwicklungssystem auszuführen, müssen Sie sicherstellen, dass alle Abhängigkeiten von VI-Codemodulen in derselben Version von LabVIEW gespeichert sind. Außerdem müssen Sie alle abhängigen VIs, die im Lieferumfang des LabVIEW-Entwicklungssystems enthalten sind, wie z. B. diejenigen in den Verzeichnissen vi.lib oder instr.lib in der LabVIEW-Installation, in die Bereitstellung einbeziehen. Mit den folgenden Ansätze können Sie sicherstellen, dass beide Bedingungen erfüllt sind:

• Erstellen Sie ein LabVIEW-Quellcodepaket für alle Codemodul-VIs, und stellen Sie sicher, dass die Optionen zum Ausschließen von vi.lib, instr.lib und user.lib nicht ausgewählt sind. Fügen Sie die Dateien einer neuen Projektbibliothek hinzu, um Cross-Linking zwischen Ihren Quell-VIs und den VIs im Quellcodepaket zu verhindern.
• Erstellen Sie eine oder mehrere komprimierte Projektbibliotheken (PPLs) für Ihre Quelldateien. Eine PPL ist eine einzelne kompilierte Datei, die alle VIs und deren Abhängigkeiten enthält. Mit diesem Ansatz können Sie vorhandene Bereitstellungen aktualisieren, indem Sie eine bereitgestellte PPL durch eine aktualisierte Version ersetzen.

* PPLs enthalten keine Abhängigkeiten, die DLLs sind, oder VIs, die bereits zu einer PPL kompiliert wurden

Um einen Großteil dieses Prozesses automatisch abzuwickeln, können Sie das TestStand Deployment Utility verwenden, um die Sequenzdateien bereitzustellen, die LabVIEW-Codemodule aufrufen. Das TestStand Deployment Utility speichert alle VIs in einer einzigen LabVIEW-Version und enthält alle erforderlichen Abhängigkeiten, die Teil der LabVIEW-Entwicklungsumgebung sind. Das Deployment Utility kann optional auch eine komprimierte Projektbibliothek (Packed Project Library, PPL) generieren. Weitere Informationen finden Sie unter Deploying VIs in LabVIEW Packed Project Libraries (Bereitstellen von VIs in komprimierten LabVIEW-Projektbibliotheken).

C/C++-DLL-Abhängigkeiten

In der Regel werden alle abhängigen DLLs in das Build-Verzeichnis kopiert, oder sie sind System-DLLs, die in den erforderlichen Runtime-Engines enthalten sind. Nach Möglichkeit sollten Sie DLLs oder andere Binärdateien nicht direkt in Windows-Systemverzeichnissen bereitstellen, sondern die Software ermitteln, mit der diese Abhängigkeiten installiert werden, und diese in Ihre Bereitstellung einbeziehen. Weitere Informationen zum Bereitstellen zusätzlicher Software finden Sie im Abschnitt Treiber und Runtime-Engines weiter unten.

.NET-Abhängigkeiten

Verwaltete .NET-DLLs bestehen genauso wie unverwaltete C/C++-DLLs aus kompiliertem Code, der ohne eine Entwicklungsumgebung ausgeführt werden kann. Im Gegensatz zu C/C++-DLLs können .NET-Assemblys abhängige Assemblys im Global Assembly Cache (GAC) referenzieren. Dazu können Assemblys gehören, die mit Treibern oder Runtime-Software installiert sind, aber auch Ihr eigener Code.

Beim Erstellen von .NET-Assemblys können Sie die Eigenschaft „Copy Local“ (Lokal kopieren) für referenzierte Assemblys verwenden, um eine Kopie davon neben Ihrer Assembly hinzuzufügen. Auf diese Weise können Sie sicherstellen, dass .NET-Abhängigkeiten bereitgestellt werden, indem Sie den Ordner bereitstellen, der die Assemblys und Abhängigkeiten enthält.

Test-Framework-Dateien

Zusätzlich zum Testcode müssen Sie auch TestStand-Framework-Dateien bereitstellen. Wenn Sie die TestStand-Runtime in Ihre Bereitstellung einbeziehen, werden die Standardversionen dieser Dateien auf dem System installiert. Wenn Sie jedoch angepasste Versionen dieser Komponenten nutzen, müssen Sie diese in die Testsystembereitstellung einbeziehen. 

TestStand-Konfigurationsdateien

TestStand-Konfigurationsdateien speichern die Einstellungen der lokalen Installation von TestStand.  Diese Dateien beschreiben und steuern das Verhalten eines Testsystems. TestStand-Konfigurationsdateien werden im Verzeichnis <TestStand-Anwendungsdaten>\Cfg gespeichert.

Ausführliche Informationen zu den in TestStand enthaltenen Konfigurationsdateien und zu den in den einzelnen Dateien gespeicherten Informationen finden Sie im Hilfethema zu Konfigurationsdateien.

TestStand-Komponenten

TestStand-Komponenten sind Funktionen, die die allgemeine Ausführung des Testsystems implementieren und von der Testsequenz entkoppelt sind, um die Modularität der TestStand-Architektur zu verbessern. TestStand-Komponenten implementieren Funktionen wie Anmelden und Abmelden, Reporting, Datenbankprotokollierung und Eingabe der Seriennummer. Diese Dateien befinden sich im Verzeichnis <TestStand>\Components.

Einzelheiten zu den Elementen im TestStand-Komponentenverzeichnis finden Sie im Hilfethema zum Komponentenverzeichnis.

TestStand-Benutzeroberflächen

Um Sequenzen auf einem bereitgestellten Computer ausführen zu können, müssen Sie mindestens eine Benutzeroberfläche bereitstellen, da der Sequence Editor nur auf Entwicklungscomputern verfügbar ist. Benutzeroberflächen können je nach Ihren Anforderungen einfach sein oder stark angepasst werden. TestStand enthält bereitstellbare Benutzeroberflächenanwendungen in <TestStand Public>/UserInterfaces.

Detaillierte Informationen zum Erstellen von TestStand-Benutzeroberflächen für bereitgestellte Computer finden Sie im Dokument Best Practices for NI TestStand User Interface Development (Empfohlene Methoden für die Entwicklung von TestStand-Benutzeroberflächen).

Treiber und Runtime-Engines

Um Sequenzen und Testcode auf einem Produktionssystem auszuführen, müssen Sie sicherstellen, dass alle erforderlichen Runtime-Engines (Runtimes) und Hardwaretreiber installiert wurden. Für die Ausführung von Softwarekomponenten wie DLLs, VIs und Sequenzdateien sind Runtime-Engines erforderlich. Für Hardwarekomponenten, die vom Testsystem verwendet werden, sind Treiber erforderlich. Sie müssen immer die TestStand-Runtime bereitstellen, die die TestStand-Engine und unterstützende Dateien enthält. 

Wenn Sie das TestStand Deployment Utility verwenden, können Sie die erforderliche Version von Treibern und Runtimes, die von Codemodulen referenziert werden, ermitteln und einschließen. Wenn Sie die Runtime nicht einbeziehen, stellt das TestStand Deployment Utility stattdessen eine Protokollmeldung bereit, die angibt, welche Versionen in die Bereitstellung aufgenommen werden sollten.

Softwarelizenzen

Stellen Sie sicher, dass die richtigen Softwarelizenzen für bereitgestellte Computer verfügbar sind. Für jeden bereitgestellten Computer ist mindestens eine Basis-Zielsystemlizenz erforderlich, die die Ausführung von Sequenzen ermöglicht, jedoch keine Entwicklung. Für viele Runtime-Engines wie LabVIEW und LabWindows/CVI Runtimes gelten keine Lizenzanforderungen. Stellen Sie anhand der Dokumentation für zusätzliche von Ihnen bereitgestellte Komponenten sicher, dass Sie die erforderlichen Zielsystemlizenzen erhalten. Eine Liste aller Produkte von NI, für die Lizenzen für bereitgestellte Anwendungen erforderlich sind, finden Sie im Abschnitt „Deployment licenses“ (Zielsystemlizenzen) im Hilfethema Deployment and Debug Licenses for NI software (Zielsystem- und Fehlersuchlizenzen für NI-Software).

Wenn die Bereitstellung auf einer großen Anzahl von Produktionscomputern erfolgt, bietet NI Volumenlizenzen an, mit denen Sie Lizenzen über einen zentralen Lizenzserver verwalten können. Weitere Informationen zu Volumenlizenzoptionen finden Sie auf der Seite Volumenlizenzprogramm für Software.

Nachdem Sie die Dateien definiert haben, die Sie in Ihre Testsystembereitstellung aufnehmen, müssen Sie eine Methode zum Verteilen der Dateien an Produktionscomputer auswählen. In den folgenden Abschnitten werden die einzelnen Bereitstellungsmethoden beschrieben:

• Bereitstellung per NI-Paket
• Bereitstellung per Installationsprogramm
• Bereitstellung per Netzwerkdatenträger

Bereitstellung per NI-Paket

NI-Pakete bieten einen Mechanismus zum Konsolidieren aller Dateien in der Bereitstellung in einer einzigen Datei. Diese können Sie mithilfe des NI-Paketmanagers bereitstellen und an den richtigen Speicherorten auf Produktionscomputern extrahieren. Mit dem TestStand Deployment Utility können Sie ein Paket erstellen, das alle Dateien in der Bereitstellung enthält. Bei paketbasierten Bereitstellungen werden Treiber und Komponenten, die für die Bereitstellung erforderlich sind, als Abhängigkeiten des Pakets referenziert, jedoch nicht in das Paket selbst aufgenommen. 

Wenn Sie das Paket auf einem Produktionscomputer installieren, erkennt der NI-Paketmanager diese Abhängigkeiten und ermöglicht Ihnen das Herunterladen und Installieren dieser Pakete. Sie können auch SystemLink-Software verwenden, um ein Repository mit NI-Paketen in Ihrer Organisation bereitzustellen, einschließlich der von Ihnen erstellten NI-Pakete. Weitere Informationen zur Verwendung von SystemLink zum Verwalten paketbasierter Bereitstellungen finden Sie unter How Do I Configure Systems and Deploy Software With SystemLink? (Wie konfiguriere ich Systeme und stelle Software mit SystemLink bereit?)

Da jedes NI-Paket eine einzelne Komponente ist, können Sie eine paketbasierte Bereitstellung aktualisieren, indem Sie eine neue Version des Pakets mit einer aktualisierten Versionsnummer erstellen. Sobald die neue Version getestet und validiert wurde, können Sie sie durch herkömmliche Dateiübertragung oder über SystemLink an Produktionscomputer verteilen.

Bereitstellung per Installationsprogramm

Ein weiterer Ansatz für die Bereitstellung von Dateien besteht darin, ein Installationsprogramm zu erstellen, das alle erforderlichen Komponenten der Bereitstellung enthält. Dieses kann dann kopiert und auf Teststationscomputern installiert werden. Im Gegensatz zu Paketen können Installationsprogramme die erforderlichen Treiber und Komponenten in das Installationsprogramm aufnehmen. Durch das Einbeziehen dieser Komponenten wird das Installationsprogramm viel größer auf dem Datenträger. Es wird jedoch sichergestellt, dass die Treiber und Runtime-Engines immer enthalten und verfügbar sind. Mit dem TestStand Deployment Utility können Sie ein Installationsprogramm für Ihr TestStand-System ohne Kenntnisse von Microsoft-Installationsprogrammen erstellen. Das Utility umfasst die folgenden Funktionen:

• Verteilen Sie Dateien an bestimmte Verzeichnisse auf dem Zielcomputer, wie das <TestStand>-Verzeichnis oder das <Desktop>-Verzeichnis.
• Importieren Sie die in Measurement and Automation Explorer (MAX) generierte Hardwarekonfiguration.
• Kann zusätzliche Komponenten enthalten, wie Treiber und Runtimes. 
•  Sie können Patch-Installationsprogramme zum Anwenden von Updates auf eine vorhandene Bereitstellung erstellen.

Weitere Informationen zu den verfügbaren Funktionen im TestStand Deployment Utility finden Sie im Thema Building an Installer with the TestStand Deployment Utility (Erstellen eines Installationsprogramms mit dem TestStand Deployment Utility) in der TestStand-Hilfe. In den meisten Fällen bietet das TestStand Deployment Utility die erforderlichen Funktionen zum Erstellen eines benutzerdefinierten Bereitstellungsinstallationsprogramms. Wenn Sie zusätzliche Kontrolle über das Verhalten des Bereitstellungsinstallationsprogramms benötigen, können Sie ein Installationsprogramm mit Tools von Drittanbietern erstellen. Weitere Informationen zu Fällen, in denen das erforderlich sein kann, finden Sie unter Building an Installer with Third-Party Tools (Erstellen eines Installationsprogramms mit Tools von Drittanbietern).

Um Updates auf ein vorhandenes Installationsprogramm anzuwenden, können Sie mit dem TestStand Deployment Utility ein Patch-Installationsprogramm erstellen, das nur aktualisierte Komponenten enthält. Weitere Informationen zum Erstellen von Patch-Installationsprogrammen finden Sie im Hilfethema Patching Deployments (Patchen von Bereitstellungen). Darüber hinaus sollten Sie eventuell mehrere Installationsprogramme erstellen, um die Bereitstellung zu modularisieren, z. B. separate Installationsprogramme für Testcode, TestStand-Komponenten sowie Treiber und Runtime-Engines. Mit diesem Ansatz können Sie nur die Installationsprogramme aktualisieren und verteilen, bei denen Änderungen vorgenommen wurden.

Da Installationsprogramme Dateien automatisch an den richtigen Speicherorten ablegen und die erforderlichen Treiber und Runtime-Engines enthalten können, lässt sich das System nach Erstellung eines funktionierenden Installationsprogramms einfach bereitstellen. Da die Bereitstellung per Installationsprogramm jedoch auf jeden Testcomputer verschoben und dort installiert werden muss, eignen sie sich normalerweise am besten für Bereitstellungen für weniger Testcomputer. 

Bereitstellung per Netzwerkdatenträger

Bei Bereitstellungsarchitekturen mit Netzwerkdatenträger werden Dateien direkt über einen Netzwerkdatenträger für Teststationscomputern freigegeben, ohne dass sie in einem Installationsprogramm konsolidiert werden. Der Zugriff auf Dateien auf dem Netzwerkdatenträger kann von einer Quellcodeverwaltungslösung verwaltet werden. Mit diesem Ansatz erstellen und aktualisieren Testentwickler Dateien im freigegebenen Dateibestand. Nach dem Abschluss zum Testen werden diese Dateien entweder auf Produktionscomputer kopiert oder direkt vom Netzwerkspeicherort aus verwendet. 

Bei einer Bereitstellungsstrategie für Netzwerkdatenträger verwenden Sie ein freigegebenes Repository, um Dateien zwischen Entwicklungs-, Staging- und Produktionscomputern freizugeben

Bei der Entwicklung von neuem Testcode müssen Sie sicherstellen, dass Code in der Entwicklung auf bereitgestellten Systemen erst verwendet wird, wenn er getestet und validiert wurde. In der Regel wird ein Produktionscomputer mit Zugriff auf Testhardware als Staging-Tester gekennzeichnet und zum Validieren und Testen von Testsystemen vor der Veröffentlichung verwendet. Sobald das Testsystem auf dem Staging-Tester validiert wurde, kann es auf Produktionscomputern bereitgestellt werden.

Wie Sie am besten sicherstellen, dass der bereitgestellte Code validiert wird, hängt davon ab, wie oft Updates auf Teststationen angewendet werden müssen.

In Fällen, in denen häufige Updates erforderlich sind, kann ein CI/CD-Ansatz (Continuous Integration and Delivery, kontinuierliche Integration und Bereitstellung) dazu beitragen, dass der neueste Code auf Testcomputern verfügbar ist und dass dieser immer ordnungsgemäß getestet und validiert wurde. Mit einem CI/CD-Ansatz automatisieren Sie einen Großteil des Verfahrens zum Erstellen, Testen und Bereitstellen von Updates für Testcode, um den Overhead so weit wie möglich zu reduzieren. Sie können Tools von Drittanbietern wie Jenkins verwenden, um diese Art der Automatisierung zu implementieren. 

In streng kontrollierten Umgebungen sind die Validierungsanforderungen in der Regel sehr hoch. Daher können Aktualisierungen des Testsystems nicht häufig durchgeführt werden. Definieren Sie für diese Testsysteme ein separates Repository oder einen Dateibestand, in dem Entwickler Änderungen vornehmen und dem Test neue Funktionen hinzufügen. Sobald die neueste Version des Testsystems fertiggestellt und validiert wurde, erstellen Entwickler einen versionierten Zweig des Dateibestands zur Verwendung auf Produktionscomputern. Dieser Zweig sollte innerhalb der Quellcodeverwaltung gesperrt sein, um Änderungen am validierten Code zu verhindern. Erstellen Sie nach Abschluss und Validierung des neuen Zweigs einen neuen versionierten Zweig mit dem Code.

Um den Testcode bereitzustellen, rufen Produktionscomputer eine Kopie des versionierten Codes ab. Diese sollte schreibgeschützt sein, damit der Code unverändert bleibt. Um weiterhin sicherzustellen, dass keine Änderungen an validierten Dateien vorgenommen werden, können Sie der Testsequenz Code hinzufügen, der die Prüfsummen aller Dateien validiert. Weitere Informationen zu diesem Ansatz finden Sie im Dokument Best Practices for Verification and Validation of TestStand Systems (Empfohlene Methoden für die Überprüfung und Validierung von TestStand-Systemen).

Bereitstellen von Treibern und Runtime-Engines bei Bereitstellungen per Netzwerkdatenträger

Wenn Sie einen Ansatz mit Netzwerkdatenträger verwenden, müssen Sie einen separaten Mechanismus einsetzen, um die erforderlichen Treiber und Runtimes auf Testcomputern zu installieren. Runtime-Engines und Treiber können über die folgenden Mechanismen bereitgestellt werden:

• Erstellen eines Installationsprogramms mit der erforderlichen Software. Das TestStand Deployment Utility kann ein Installationsprogramm erstellen, das Runtime-Engines und Treiber enthält.
• Erstellen eines Systemabbilds basierend auf einem System mit allen erforderlichen Treibern und Runtimes.

Der beste Ansatz hängt in erster Linie von der Häufigkeit der Systemaktualisierungen ab. In vielen Fällen können Sie mehrere Ansätze kombinieren. Die folgenden allgemeinen Szenarien veranschaulichen die Auswahl einer Strategie für die Treiber- und Runtime-Bereitstellung:

• Bei Systemen mit seltenen Aktualisierungen hat das Erstellen eines Abbilds normalerweise einen positiven ROI. Kleine Aktualisierungen des Testsystems können weiterhin implementiert werden, ohne dass das Abbild aktualisiert werden muss.
• Erstellen Sie für Systeme, die häufiger aktualisiert werden, ein Installationsprogramm für das Testsystem mit den erforderlichen Treibern und Runtimes.

Strategien für den Zugriff auf Testsystemdateien

Bei einer Bereitstellung per Netzwerkdatenträger können Sie einen der folgenden allgemeinen Ansätze zum Verwalten des Dateispeichers verwenden:

• Greifen Sie direkt vom Netzwerkdatenträger auf Dateien zu.
• Kopieren Sie Dateien mit Tools von Drittanbietern lokal vom Netzwerkdatenträger, um sicherzustellen, dass lokale Dateien mit dem Laufwerk synchronisiert werden.
  
  

Direkter Zugriff auf Dateien von einem Netzwerkdatenträger

Der Vorteil des direkten Zugriffs auf Dateien von einem Netzwerkdatenträger besteht darin, dass Sie beim Aktualisieren von Dateien auf dem Netzwerkdatenträger sicherstellen, dass die Aktualisierung auf alle Testcomputer angewendet wird. Der direkte Zugriff auf Dateien von einem Netzwerkdatenträger aus bedeutet jedoch, dass der Betrieb der Teststationen von der Verfügbarkeit des freigegebenen Laufwerks und der Netzwerkverbindung abhängt. Wenn beides nicht verfügbar ist, können Fertigungsbetreiber keine Testdateien von der Teststation ausführen, was zu Produktionsstillständen führen kann. Stellen Sie daher unbedingt zusammen mit Ihrer IT-Abteilung sicher, dass diese die Verfügbarkeitsanforderungen für das freigegebene Laufwerk und das Netzwerk erfüllen kann. Verwenden Sie beispielsweise Serverredundanz, um die Verfügbarkeitsanforderungen für das freigegebene Laufwerk zu erfüllen. 

Um ein freigegebenes Laufwerk zum Speichern von TestStand-Konfigurationsdateien und -Komponenten zu verwenden, müssen Sie die TestStand-Umgebungsfunktion verwenden. Damit können Sie den Speicherort von TestStand-Verzeichnissen angeben. Dazu erstellen Sie eine Umgebungsdatei (tsenv), die den Speicherort des Netzwerkdatenträgers für diese Verzeichnisse enthält. Ausführliche Informationen zum Erstellen und Verwenden dieser Datei finden Sie im Hilfethema zu TestStand-Umgebungen.

Lokales Kopieren von Dateien auf jede Teststation

Sie können auch lokale Kopien aller Bereitstellungsdateien erstellen. Dieser Ansatz bietet die folgenden Vorteile:

• Teststationen können Tests ohne dauerhafte Netzwerkverbindung ausführen.
• Die Ladezeit für Testsystemdateien kann verringert werden.

Dieser Ansatz erhöht jedoch den Aufwand für das Kopieren von Dateien auf alle Teststationen. Stellen Sie außerdem sicher, dass alle Testsysteme über die neuesten Dateien verfügen, bevor Sie Tests ausführen.

Sie können zusätzliche Tools erstellen, um die Version der Datei auf der Teststation bei jedem Start der Teststation automatisch mit dem freigegebenen Laufwerk zu vergleichen und nicht aktuelle Dateien herunterzuladen.

Klicken Sie hier, um weitere Dokumente der TestStand Advanced Architecture-Serie mit interessanten Themen für fortgeschrittene NI-TestStand-Entwickler anzuzeigen.