Programmieren mit der TestStand​-API​

Eine gut konzipierte, modulare Testarchitektur bietet einen enormen Nutzen. Sie können eine generalisierte, anpassbare Architektur bei einer Reihe von Testsystemen wiederverwenden, um die Lebensdauer des Testsystems zu verlängern und die Kosten für die Entwicklung von Tests zu verringern. Die TestStand-Plattform ist modular aufgebaut und vereinfacht somit die Entwicklung von Testsystemen und einschlägigen Tests. Die Stärke von TestStand liegt in der offenen Architektur, mit der Sie komplexe und flexible Testlösungen entwickeln können.

Die TestStand-Engine stellt die Funktionen für TestStand-Komponenten bereit, die über die TestStand-API mit der Engine kommunizieren.

Bei TestStand wird zwischen der Präsentationsebene (für den Benutzer sichtbare Inhalte) und der Business-Logik-Ebene (die Aktionen hinter dem Benutzerverhalten) klar getrennt. Diese Ebenen kommunizieren über die TestStand-API miteinander. Aufgrund dieser Methodik können Sie TestStand erweitern, indem Sie zusätzliche Komponenten erstellen, die via TestStand-API auf die TestStand-Engine zugreifen. So können Sie beispielsweise individuelle Benutzeroberflächen erstellen, Testabläufe dynamisch steuern, Sequenzen spontan einrichten und andere erweiterte Lösungen entwickeln.

Die TestStand-Engine ist ein ActiveX/COM-Automatisierungsserver, der Funktionen über eine API bereitstellt. Microsoft hat den Kommunikationsstandard ActiveX entwickelt, um die Kommunikation zwischen Applikationen zu erleichtern. ActiveX ist seit vielen Jahren in der Branche weit verbreitet und basiert auf COM-Technologien. Da TestStand auf COM aufbaut, ist die Kompatibilität mit zukünftigen Windows-Versionen über die Lebensdauer von ActiveX hinaus sichergestellt.

ActiveX verfolgt einen Client/Server-Ansatz. Ein ActiveX-Server ist eine Applikation, die bestimmte Funktionen für Clients bereitstellt, die dem ActiveX-Standard entsprechen. Darüber hinaus verwenden ActiveX-Anwendungen objektorientierte Programmierung (OOP).

Die ActiveX-Serverarchitektur sorgt dafür, dass jede Programmiersprache, die in der Lage ist, ActiveX-Code aufzurufen, mit der TestStand-Engine interagieren kann. Zu diesen Programmiersprachen zählen beispielsweise LabVIEW, LabWindows™/CVI™, C#, VB .NET oder C++. Wenn Sie mit der TestStand-API programmieren, hängt die Implementierung davon ab, welche Sprache Sie nutzen. Zum Beispiel:

• LabVIEW nutzt Eigenschafts- und Methodenknoten für API-Aufrufe.
• LabWindows/CVI wendet bei API-Aufrufen einen Messgerätetreiber-Wrapper an.
• C# oder or VB .NET rufen die API mithilfe einer von TestStand bereitgestellten Interop-Assembly auf.
• TestStand selbst bietet einen ActiveX/COM-Adapter für den Zugriff auf die API. Sie können auch anhand von Ausdrücken direkt auf die API zugreifen.

Ganz gleich, wie Sie auf die API zugreifen: Das Ergebnis fällt in allen Umgebungen gleich aus, da die Funktionalität ungeachtet der von Ihnen genutzten Schnittstelle in der TestStand-Engine implementiert ist.

API-Klassen

Die TestStand-API definiert mehrere Klassen, die für die TestStand-Objekttypen stehen, z. B. SequenceFile oder Execution. Jede dieser Klassen definiert Eigenschaften (Properties) und Methoden für den Zugriff auf relevante Daten oder die Ausführung von Aktionen. Beispielsweise definiert die Klasse „SequenceFile“ die Eigenschaft „Path“, um den Pfad der Sequenzdatei auf dem Laufwerk zu speichern, sowie die Methode „Save“ (Speichern), um die Sequenzdatei zu speichern.

Eine vollständige Liste der verfügbaren Klassen, die in der TestStand-API definiert sind, finden Sie im Themenabschnitt TestStand-API-Hilfe. Klicken Sie auf eine bestimmte Klasse, um mehr über diese Klasse sowie die von ihr definierten Eigenschaften und Methoden zu erfahren. 

Erbbeziehungen zwischen Klassen

Viele Klassen in TestStand stehen zueinander in einer Erbbeziehung. Dabei kann eine spezifischere Klasse die Eigenschaften oder Methoden von einer allgemeineren Klasse erben. Beispielsweise ist die Klasse „SequenceFile“ eine spezifischere Version der Klasse „PropertyObject“. Die TestStand-API definiert eine Erbbeziehung zwischen diesen Klassen, damit Objekte einer spezifischeren Klasse auf die Eigenschaften und Methoden von allgemeineren Klassen zugreifen können.

Die Klasse „SequenceFile“ erbt Eigenschaften und Methoden von den allgemeineren Klassen „PropertyObjectFile“ und „PropertyObject“.

Fast alle TestStand-API-Klassen erben von der grundlegenden Klasse „PropertyObject“. Diese umfasst allgemeine Methoden und Eigenschaften, die von TestStand-Objekten gemeinsam genutzt werden. Die Klasse „PropertyObject“ definiert allgemeine Eigenschaften wie „Name“ und „Numeric Format“ und stellt gängige Objektverwaltungsmethoden bereit, beispielsweise Klonen, Einstellen und Abrufen von Werten, Erstellen und Löschen von Objekten oder Manipulieren von Arrays. Da die meisten TestStand-API-Klassen von der Klasse „PropertyObject“ erben, können sie auch auf diese allgemeinen Eigenschaften und Methoden zugreifen. So können Sie z. B. mit Hilfe der Methode PropertyObject.Clone() eine Kopie eines Schritts, einer Sequenz oder eines Sequenzdatei-Objekts erstellen.

Viele Entwicklungsumgebungen verhindern den direkten Zugriff auf die Eigenschaften einer übergeordneten Klasse. Ähnlich verhält es sich bei TestStand, wo Sie beispielsweise die Methode „Clone()“ nicht direkt über ein Objekt der Klasse „SequenceFile“ aufrufen können. Die TestStand-API stellt jedoch Methoden bereit, nach denen sich ein Objekt so umbetten lässt, dass der Zugriff auf Eigenschaften und Methoden der allgemeineren Klasse möglich ist. Damit Sie auf Eigenschaften und Methoden zugreifen können, die in der Klasse „PropertyObject“ definiert sind, können Sie das Objekt in die zugehörige Elternklasse einbetten, indem Sie die Methode „AsPropertyObject“ aufrufen. Um z. B. auf die Methode Clone() an einem Sequenzdatei-Objekt zuzugreifen, verwenden Sie
SequenceFile.AsPropertyObject.Clone()

Weitere Informationen über die API-Erbbeziehungen sowie über die Eigenschaften und Methoden der Klasse PropertyObject finden Sie in der Hilfe zu NI TestStand.

Unterschiede zwischen dynamischen Eigenschaften und integrierten Eigenschaften

TestStand-Objekte weisen zwei verschiedene Arten von Eigenschaften auf:

• Integrierte Eigenschaften (API-Eigenschaften) sind durch die Objektklasse definiert und für alle Objekte einer bestimmten Klasse vorhanden.
• Dynamische Eigenschaften (Subproperties) sind nach dem Objekt definiert und können zwischen den einzelnen Objekten derselben Objektklasse variieren.

Ein Objekt vom Typ „Step“ weist einerseits dynamische Eigenschaften, die sich je nach diesem Typ voneinander unterscheiden können, andererseits statische Eigenschaften auf, die durch die Klasse „Step“ in der TestStand-API definiert sind.

Diese beiden verschiedenen Eigenschaftentypen können leicht verwechselt werden, da beide in einem TestStand-Ausdruck mit „.“ aufrufbar sind. Wenn Sie jedoch die API in anderen Programmiersprachen nutzen, können Sie nur auf integrierte Eigenschaften direkt zugreifen, etwa bei der Nutzung eines Eigenschaftenknotens in LabVIEW.

Sie können auf dynamische Eigenschaften zugreifen, indem Sie die Methoden der PropertyObject-API anwenden, beispielsweise „GetValString()“ und „GetValNumber()“, und per LookupString den Namen der dynamischen Eigenschaft angeben:

In einigen Klassen können Sie auf verschiedene Weise auf eine Eigenschaft zugreifen – entweder mithilfe dynamischer oder anhand integrierter Eigenschaften. Wenn die TestStand-API in einem Codemodul eingesetzt wird, empfiehlt sich die Nutzung von integrierten Eigenschaften, da diese direkt und ohne die nötige Pflege von Lookup-Strings zugänglich sind. 

TestStand-Objektbeziehungen

TestStand-Objekte können weitere Objekte einer anderen Klasse enthalten, was als API Containment bezeichnet wird. So enthält etwa ein Objekt des Typs „SequenceFile“ Objekte vom Typ „Sequence“ für die in der Sequenzdatei definierten Sequenzen. Alle Objekte des Typs „Sequence“ enthalten wiederum Objekte vom Typ „Step“.

Objekte in der TestStand-API enthalten häufig weitere Objekte einer anderen Klasse.

Für die Navigation durch bestimmte Objekte ist es hilfreich, die Containment-Beziehungen zwischen einzelnen Objekten zu kennen. Enthält ein Elternobjekt (übergeordnetes Objekt) mehrere Unterobjekte (untergeordnete Projekte) einer bestimmten Klasse, müssen Sie entweder einen Eigenschaftsnamen oder einen entsprechenden Index angeben, um das gewünschte Kindobjekt zu benennen. Bei den meisten Unterobjekten greifen Sie über ein Elternobjekt auf die eingebundenen Objekte zu. Dabei bedienen Sie sich einer bestimmten Abrufmethode, die den Objektnamen oder -index als Parameter zulässt. Wenn Sie beispielsweise auf einen Schritt innerhalb einer Sequenzdatei zugreifen möchten, nutzen Sie folgende Variante:

SequenceFile.getSequenceByName(“MainSequence”).GetStepByName(“RAM Test”, StepGroup_Main)

Darüber hinaus können Unterobjekte über die API auf die zugehörigen Elternobjekte zugreifen. Da es zu jedem Unterobjekt immer nur ein einziges Elternobjekt geben kann, greifen Sie nicht mithilfe einer Abrufmethode, sondern über eine Eigenschaft direkt auf das Elternobjekt zu. Wenn Sie etwa ein Objekt des Typs „SequenceContext“ haben und auf die Ausführung des Elternobjekts zugreifen müssen, können Sie folgende Option nutzen:

DieserKontext.Thread.Ausführung

Häufig werden integrierte Eigenschaften bereitgestellt, um auf weiter entfernte Vorfahren zuzugreifen. So können Sie zum Beispiel über ein Objekt des Typs „SequenceContext“ direkt auf das Ausführungsobjekt zugreifen:

DieserKontext.Ausführung

Navigation durch Objekte der TestStand-API

Zusätzlich zur Navigation anhand von Containment-Beziehungen stehen in vielen Klassen Eigenschaften oder Methoden zum Zugriff auf andere verwandte Objekte zur Verfügung. So stellt etwa die Klasse „Module“ die Eigenschaft „Adapter“ bereit, damit Sie auf den entsprechenden ausführenden Adapter zugreifen können. 

Sie können anhand des Diagramms im Hilfethema TestStand API Reference feststellen, wie Sie vom aktuellen Objekt ausgehend auf ein gewünschtes Objekt zugreifen können. Ein Teil dieses Diagramms ist unten abgebildet.
 

Vom Objekt des Typs „sequenceContext“ aus können Sie durch die Objektbeziehungen navigieren, um auf andere Objekte zuzugreifen.

Üblicherweise können Sie auf zwei verschiedene Arten auf die API zugreifen. Welche davon zutrifft, hängt von der Art der von Ihnen erstellten Applikation ab:

• Bei eigenständigen Applikationen müssen Sie eine neue Instanz der TestStand-Engine erstellen.
• Für Codemodule oder andere Tools, die aus einer vorhandenen Applikation aufgerufen werden, müssen Sie eine bestehende Referenz zur TestStand-Engine einbinden.

Erstellen einer eigenständigen TestStand-Anwendung

Damit Sie die TestStand-API in einer neuen Applikation nutzen können, müssen Sie zunächst eine Instanz der TestStand-Engine erstellen. Alle TestStand-Applikationen oder -Prozesse, beispielsweise eine TestStand-Benutzeroberfläche, Sequence Editor oder ein benutzerdefiniertes Dienstprogramm, bewahren eine einzelne Instanz der Engine (Singleton) zur Ausführung beliebiger TestStand-Funktionen. Die Engine bewahrt Referenzen zu allen In-Memory-Objekten, richtet Ausführungen ein, steuert diese und speichert die Kontextdaten für eine TestStand-Sitzung sowie globale Varianten für Stationen und Benutzerinformationen.

Die TestStand-Engine stellt Methoden bereit, nach denen Sie weitere TestStand-Objekte erstellen können, die mit dem „neuen“ Schlüsselwort gekennzeichnet sind. Dazu zählen folgende Methoden:

• Engine.NewSequenceFile ()
• Engine.NewStep ()
• Motor.Neue Ausführung ()
• Engine.NewPropertyObject ()

Eine vollständige Liste der über das Engine-Objekt verfügbaren Eigenschaften und Methoden sowie weitere Informationen finden Sie im Themenabschnitt „TextStand-Engine“.

Wenn die Applikation fertig ist, müssen Sie vor dem Beenden der Applikation die TestStand-Engine schließen. Der Schließvorgang muss in zwei Schritten erfolgen, damit der Benutzer die Möglichkeit hat, alle laufenden Ausführungen zu beenden. Dieser Vorgang ist im Themenabschnitt Schließen der Engine in der TestStand-Hilfe erläutert.

Es wird empfohlen, zur Entwicklung von TestStand-Applikationen und -Benutzeroberflächen die TestStand-UI-Steuerelemente zu verwenden, statt direkt ein TestStand-Engine-Objekt zu erstellen, damit sich Ihr Programm weniger komplex gestaltet. Die TestStand-UI-Steuerelemente stellen eine Abstraktionsschicht oberhalb der TestStand-API bereit, sodass die Entwicklung eigenständiger TestStand-Applikationen leichter von der Hand geht. Weitere Informationen zur Nutzung der UI-Steuerelemente finden Sie im Abschnitt UI-Steuerlemente-API dieses Dokuments.

Aufrufen eines Codemoduls oder Tools aus einer vorhandenen Applikation

Wenn Sie die API in einem Codemodul oder Tool nutzen, das sie aus einer anderen TestStand-Applikation aufrufen, arbeiten Sie mit der TestStand-Engine, die von der Applikation auf der höchsten Ebene erstellt wurde. Wird der Code aus einer ausführenden Sequenz aufgerufen, etwa einem Codemodul, empfiehlt es sich, einen Eingangsparameter für das Objekt des Typs „SequenceContext“ anzuwenden. Diese Vorgehensweise ist gegenüber der direkten Übergabe der TestStand-Engine vorzuziehen, da der Sequenzkontext über das TestStand-Engine-Objekt hinaus auch den Zugriff auf den aktuellen Ausführungsstatus ermöglicht.

„SequenceContext“ steht für den aktuellen Ausführungsstatus einer Sequenz und ermöglicht den Zugriff auf einen Snapshot aller Daten für eine bestimmte Ausführungssequenz. Jede ausführende Sequenz in einem Thread weist ein eigenes Objekt des Typs „SequenceContext“ auf.

Wenn Sie die Ansicht „Variables“ durchgehen, sehen Sie eine Liste der Sequenzkontexteigenschaften auf der ersten Ebene. Darin enthalten sind alle Variablentypen, der aktuelle Schritt und die Eigenschaft „RunState“. „SequenceContext“ stellt zudem Referenzen zu zahlreichen weiteren Objekten als integrierte Eigenschaften bereit.

Unterschiede zwischen RunState und SequenceContext

Die Eigenschaft „RunState“ und der Objekttyp „SequenceContext“ ermöglichen beide den Zugriff auf viele derselben Objekte, zum Beispiel aktuelle Ausführung, Thread, Sequenzdatei und Sequenz. Allerdings sind diese Objekte in „RunState“ als dynamische Eigenschaften enthalten, wohingegen sie von SequenceContext als integrierte Eigenschaften bereitgestellt werden.

Daher sollten Sie die Eigenschaft „RunState“ nutzen, wenn Sie auf Informationen über den Status in TestStand-Ausdrücken zugreifen. Hingegen ist „SequenceContext“ besser geeignet für Codemodule, bei denen Sie nicht direkt auf dynamische Eigenschaften zugreifen können.

 „SequenceContext“ stellt Informationen zum Ausführungsstatus über integrierte und dynamische Eigenschaften bereit, während „RunState“ Statusinformationen ausschließlich über dynamische Eigenschaften bereitstellt.

Fortbestand von Sequenzdaten

Bevor die Schritte in einer Sequenz ausgeführt werden, erstellt TestStand eine Laufzeitkopie der Sequenz, um separate lokale Variablen und Schritteigenschaftswerte für jeden Sequenzaufruf zu bewahren. Wenn Sie innerhalb einer Ausführungssequenz über „RunState“ oder „SequenceContext“ auf Objekte zugreifen, handelt es sich bei diesen Objekten zumeist um die erwähnten Laufzeitkopien. Somit bleiben Änderungen, die Sie an diesen Objekten vornehmen, nach Abschluss der Ausführung nicht bestehen. Beispielsweise haben Änderungen an den Werten lokaler Variablen oder die programmatische Erstellung der Untereigenschaft (Subproperty) eines Parameters keine Auswirkungen auf die Sequenzdatei auf dem Laufwerk:

Locals.SetValString("RuntimeVariable",1, "value")

Objekte, die von der Klasse „PropertyObjectFile“ erben, etwa Objekte des Typs „SequenceFile“, haben keine separate Laufzeitkopie. Daher bleiben Änderungen, die Sie anhand dieser Objekte vornehmen, auch nach Abschluss der Ausführung bestehen. So können Sie beispielsweise eine dauerhafte lokale Variable erstellen, wenn Sie über ein Objekt des Typs „SequenceFile“ auf die Eigenschaft „Locals“ zugreifen, .

RunState.sequencefile.GetSequenceByName("MainSequence").Locals.SetValString("PersistantVariable",1, "value")

Die TestStand-API ermöglicht die Automatisierung aller TestStand-Funktionen, doch es gibt noch gängigere Anwendungsbereiche:

• Erstellen von Zusatzeigenschaften
• Erstellen von neuen Sequenzdateien
• Ändern von bestehenden Sequenzen

Erstellen von Zusatzeigenschaften

Mit der TestStand-API können Sie Zusatzeigenschaften zur Laufzeit dynamisch erzeugen, um beispielsweise die Testergebnisse um spezifische Diagnosedaten zu ergänzen, wenn eine bestimmte Komponente den Test nicht besteht, oder um benutzerdefinierte Daten zum Protokoll-Header hinzuzufügen. 

Es gibt viele Möglichkeiten zur Erstellung von Zusatzeigenschaften über die API. Bei primitiven Daten lassen sich neue Eigenschaften am einfachsten anhand der Methode „SetVal“ mit der Option „InsertIfMissing“ erzeugen. So können Sie zum Beispiel mithilfe des folgenden Ausdrucks eine neue Eigenschaft zum Schritt „Numeric Limit Test“ hinzufügen:

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetValString(
"Result.extraResult",
PropOption_InsertIfMissing,
"dieser String ist ein zusätzliches Ergebnis")

Wenn Sie eine Zusatzeigenschaft zum Protokoll hinzufügen möchten, müssen Sie zudem das Objekt mit „IncludeInReport“ markieren. Anhand dessen wählt die Protokollerstellungsfunktion die zu protokollierenden Ergebniseigenschaften aus:

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetFlags(
"Result.extraResult",
0,
EigFlags_IncludeInReport)

Nähere Informationen darüber, wie Sie mit der API Daten zum Testprotokoll hinzufügen können, finden Sie im Beispiel Benutzerdefinierte Daten zu einem Protokoll hinzufügen.

Bei komplexeren Eigenschaften wie Containern müssen Sie die Eigenschaften direkt nach der Methode NewSubProperty() erstellen, die Ihnen das Erzeugen von Containern, Datentypinstanzen und Arrays ermöglicht. Wenn Sie etwa eine neue lokale Variable des Typs „Error“ erstellen möchten, verwenden Sie den folgenden Ausdruck:

Locals.NewSubProperty("ComplexContainer.Error",PropValType_NamedType, False, "Error",0)

Nähere Informationen zum Erstellen von Eigenschaften mithilfe der API finden Sie im Beispiel [Neue Eigenschaften mit der API erstellen].

Erstellen neuer Sequenzen

Wenn Sie das Erstellen einer Sequenzdatei auf Basis von Benutzereingaben automatisieren möchten, können Sie mit der TestStand-API neue Sequenzdateien erzeugen oder modifizierte Kopien einer bestehenden Datei erstellen. Sie möchten z. B. ein Tool erstellen, das basierend auf bestimmten Benutzereingaben eine Startpunkt-Sequenzdatei erzeugt oder bestimmte Änderungen an Schritten in einer vorhandenen Sequenzdatei durchführt.

Weitere Informationen zum Erstellen neuer Sequenzdateien mit Hilfe der API finden Sie im Beispiel „Erstellen einer Sequenz mit der API“.

Sie können die TestStand-API auch zum Entwickeln eines „Sequence File Translator“, eines Sequenzdateiübersetzers, nutzen, um Sequenzdateien anhand eines benutzerdefinierten Dateiformats zu erzeugen. Beim Entwickeln eines „Sequence File Translator“ erzeugen Sie mithilfe der TestStand-API Sequenzdateien, Sequenzen, Schritte und Eigenschaften auf  Basis der Daten in einer von Ihnen angegebenen Datei. Anhand des Translator-Frameworks können Sie diesen Code in TestStand integrieren und Dateien direkt in einem benutzerdefinierten Format öffnen. 

Weitere Informationen zur Nutzung von Sequence File Translators finden Sie in der TestStand-Hilfe im Themenabschnitt Sequence File Translators.

Modifizieren von Sequenzen

Sie können die TestStand-API in benutzerdefinierten Tools nutzen, mit denen Sie Modifikationen an bestehenden Sequenzdateien vornehmen. So können Sie etwa ein Tool erzeugen, das nach Codemodulen auf Basis von absoluten Pfaden sucht und diese durch relative Pfade ersetzt. 

Weitere Informationen hierzu finden Sie im Beispiel Iterationstool für Sequenzdatei erzeugen.

Zusätzlich zur mit Kernfunktionen ausgestatteten TestStand-API bietet TestStand weitere APIs, die erweiterte Funktionen und weitere Merkmale umfassen.

• UI-Steuerelemente-API
• Adapter-API
• Synchronisationsserver-API

Anders als die auf Kernfunktionen beschränkte TestStand-API können diese APIs nicht direkt über Ausdrücke aufgerufen werden, sondern durch einen ActiveX-Schritt oder ein separates Codemodul.

UI-Steuerelemente-API

TestStand umfasst UI-Steuerelemente zur schnellen Entwicklung von TestStand-Benutzeroberflächen. Darunter befinden sich sichtbare Steuerelemente zur Anzeige von TestStand-Daten, beispielsweise die Ansichten „Steps“ oder „Variables“, sowie „Invisible Manager“-Steuerelemente, die einen Großteil der Kommunikation mit der TestStand-Engine-API innerhalb einer TestStand-Benutzeroberfläche abwickeln.

Es wird empfohlen, zur Entwicklung von eigenständigen TestStand-Applikationen die TestStand-UI-Steuerelemente zu verwenden, statt direkt eine TestStand-Engine-Instanz zu erstellen.

Mit der UI-Steuerelemente-API können Sie gängige Benutzeroberflächenaufgaben anhand der Steuerelemente des Managers implementieren, beispielsweise Öffnen und Ausführen von Sequenzdateien, Beantworten von UI-Nachrichten und Schließen von Applikationen. Die UI-Steuerelemente-API stellt auch Verbindungsmethoden zum Konfigurieren der UI-Steuerelemente bereit. 

Weitere Informationen zur Nutzung der UI-Steuerelemente und der UI-Steuerelemente-API finden Sie in den folgenden Hilfethemen:

• TestStand-UI-Steuerelemente – Übersicht über die Nutzung der UI-Steuerelemente zum Entwickeln von TestStand-UI-Applikationen.
• Referenz zur TestStand-UI-Steuerelemente-API – Referenz für die Klassen in der UI-Steuerelemente-API.
• Best Practices zur Entwicklung von Benutzeroberflächen – Bewährte Methoden zur Nutzung der UI-Steuerelemente und der API.

Sie können sich die TestStand-UI-Steuerelemente als Softwareschicht vorstellen, die auf der TestStand-Engine-API liegt. Diese Steuerelemente umfassen viele der Funktionen, die Sie in einer Benutzeroberfläche benötigen, unter anderem Öffnen von Sequenzen, Ausführen von Tests und Anzeigen des Testfortschritts. Die TestStand-UI-Steuerelemente zeichnen sich durch Funktionsreichtum und eine eigene API aus. Eine ausführliche Beschreibung der Funktionen dieser UI-Steuerelemente würde zwar den Rahmen dieses Dokuments sprengen, dennoch sei an dieser Stelle ausdrücklich darauf hingewiesen, dass diese Steuerelemente zusätzliche Funktionen auf Grundlage der TestStand-Engine-API umfassen.

Adapter-API

Die Adapter-API stellt spezifische Klassen für die verschiedenen in TestStand enthaltenen Adapter bereit. Üblicherweise wird die Adapter-API für adapterspezifische Informationen oder Funktionen genutzt, wenn die Adapter- oder Modulklassen in der API mit den Kernfunktionen verwendet werden. In diesem Fall binden Sie das Objekt in die entsprechende Adapter-API-Klasse ein. So können Sie beispielsweise über die Klasse „LabVIEWModule“ auf LabVIEW-spezifische Eigenschaften und Methoden für das Modulobjekt in einem Schritt des Typs „LabVIEW“ zugreifen.

Nutzen Sie die Adapter-API, um auf adapterspezifische Eigenschaften und Methoden für die Modul- oder Adapterklassen zuzugreifen.

Eine Liste der in der Adapter-API bereitgestellten Klassen finden Sie in der Referenz zur TestStand-Adapter-API.

Synchronisationsserver-API

Die Synchronisationsserver-API ermöglicht den direkten Zugriff auf TestStand-Synchronisationsobjekte wie Warteschlangen, Sperren und Benachrichtigungen. Damit Sie diese API nutzen können, muss zunächst eine Referenz zum Synchronisationsserver nach der Methode „Engine.GetSyncManager“ erstellt werden. Nachdem Sie dieses Objekt auf die in der Synchronisationsserver-API definierte Synchronisationsmanager-Klasse angewendet haben, können Sie damit auf Synchronisationsobjekte zugreifen oder neue Synchronisationsobjekte erstellen.

Nutzen Sie den SyncManager und die Synchronisationsserver-API, um kodierte TestStand-Synchronisationsobjekte zu erstellen und darauf zuzugreifen.

Diese API ist nützlich beim Entwickeln von Applikationen, die neben einem TestStand-Test ausgeführt werden und auf Informationen zum Ausführungsstatus zugreifen müssen, beispielsweise eine Applikation zur Statusüberwachung.

Weitere Informationen zu den verfügbaren Klassen finden Sie im Themenabschnitt Referenz zur Synchronisationsserver-API.

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