Bewährte Methoden für die Entwicklung benutzerdefinierter TestStand-Schritttypen

Bevor Sie mit dem Entwerfen eines benutzerdefinierten Schritttyps beginnen, sollten Sie andere Ansätze in Betracht ziehen, die möglicherweise besser für neue Funktionen geeignet sind.  

In den folgenden Fällen wird das Erstellen oder Ändern eines benutzerdefinierten Schritttyps nicht empfohlen:

• Die neue Funktionalität wirkt sich auf alle oder viele Schritttypen aus.  In diesem Fall sollten Sie einen Engine-Callback verwenden, der vor oder nach jedem Schritt ausgeführt wird.
• Sie möchten eine Basiskonfiguration eines vorhandenen Schritts bereitstellen, es sind jedoch keine neuen Funktionen oder Eigenschaften erforderlich.  Erstellen Sie in diesem Fall eine Schrittvorlage mit den Änderungen am Schritt.
• Sie möchten ein Tool oder Utility für die Verwendung zur Bearbeitungszeit bereitstellen.  Verwenden Sie in diesem Fall einen benutzerdefinierten Tool-Menüpunkt, um den benutzerdefinierten Code aufzurufen.

Erstellen oder ändern Sie einen Schritttyp in den folgenden Situationen:

• Die Funktionalität kann nicht mit integrierten Schritttypen implementiert werden.
• Die Funktionalität erfordert das Ändern von Eigenschaften, die bei Instanzen vorhandener Schritttypen nicht geändert werden können.
• Die Funktionalität erfordert, dass Aktionen vor oder nach dem Aufrufen des Testcodes ausgeführt werden, z. B. das Einrichten des Schritts oder das Analysieren der Ergebnisse.
• Sie möchten die Benutzererfahrung für die Konfiguration von Schritten mithilfe einer Benutzeroberfläche vereinfachen.
• Sie nutzen die Funktionalität gemeinsam mit anderen Gruppen, Unternehmen oder Kunden.

Vergleich zwischen Schrittvorlagen und benutzerdefinierten Schritttypen

Sie können Schrittvorlagen erstellen, indem Sie Schritte in einer Sequenz entwickeln und konfigurieren und diese Schritte dann per Drag&Drop in die Vorlagenliste der Einfügepalette ziehen. TestStand speichert eine Kopie der Schrittinstanz als Vorlage, die Sie wiederverwenden können, um schnell neue Sequenzen zu erstellen, indem Sie die Schrittvorlage per Drag&Drop in eine neue Sequenz ziehen.

Der Unterschied zwischen einer Schrittvorlage und einem benutzerdefinierten Schritttyp besteht darin, dass Sie eine Vorlage nur aus vorhandenen Schritttypen erstellen können und die Vorlage immer die gleichen Funktionen wie der ursprüngliche Schritttyp enthält. Sie können die Schrittvorlage nicht so ändern oder neu gestalten wie einen benutzerdefinierten Schritttyp. Bei Schritten, die Sie zur Vorlagenliste hinzufügen, können Sie nur die Einstellungen konfigurieren, die vom Entwickler des ursprünglichen Schritttyps aktiviert wurden. Im Gegensatz dazu können Sie einen neuen benutzerdefinierten Schritttyp verwenden, um einen komplett neuen Schritt mit völlig neuem Verhalten zu erstellen. Änderungen an einer Schrittvorlage wirken sich zudem nur auf zukünftige Instanzen des Schritts aus und ändern keine vorhandenen Instanzen dieses Schritts.

Ein Vorteil der Verwendung einer Schrittvorlage besteht darin, dass Sie die Schritteinstellungen nicht mehr als einmal anpassen müssen, wenn Sie denselben Schritt auf dieselbe Weise wiederverwenden. Wenn Sie beispielsweise ein IVI-Netzteil auf 5 V und dann auf 3,3 V einstellen und das während der gesamten Sequenz mehrmals vorhaben, können Sie Zeit sparen, indem Sie nach der ersten Verwendung und Konfiguration der Schritte zwei Schrittvorlagen erstellen. Wenn Sie jedoch einen Schritt benötigen, bei dem zuerst das Netzteil konfiguriert wird, bevor der Testcode ausgeführt wird, ist das Erstellen eines benutzerdefinierten Schritttyps ein besserer Ansatz.

Berücksichtigen Sie beim Entwerfen benutzerdefinierter Schritttypen die separaten Rollen des Framework-Entwicklers und des Testentwicklers.  Der Framework-Entwickler entwickelt Tools und Bausteine, während der Testentwickler diese Tools zur Implementierung des eigentlichen Testcodes verwendet.

Beim Entwerfen eines benutzerdefinierten Schritttyps übernehmen Sie die Rolle eines Framework-Entwicklers. Dabei müssen Sie die Funktionalität des von Ihnen entwickelten Schritttyps im Hinblick auf die Endbenutzer, also die Testentwickler, zu berücksichtigen.
Bestimmen Sie die Anforderungen an den benutzerdefinierten Schritttyp anhand dieser Richtlinien:

• Definieren Sie den Umfang des benutzerdefinierten Schritttyps.  Überlegen Sie, welche Tasks ein Testentwickler mit dem benutzerdefinierten Schritttyp implementiert.  Der Umfang sollte groß genug sein, um diese Anwendungsfälle abzudecken, aber nicht zu groß, wenn der Zweck des Schritttyps nicht eindeutig ist.
• Definieren Sie basierend auf dem Umfang des Schritttyps die Daten, die der Schritttyp benötigt, und wie die Daten gespeichert werden sollen.
• Definieren Sie alle Funktionen, die für alle Instanzen des Schritttyps implementiert werden sollen.  Stellen Sie sicher, dass alle für diese Funktionalität erforderlichen Daten in den Schritteigenschaften definiert sind.
• Definieren Sie, welche Daten von Benutzern bearbeitet und welche im Protokoll oder in der Datenbank protokolliert werden sollen.
• Überlegen Sie, welche Funktionen oder Konfigurationen in Zukunft möglicherweise benötigt werden, und stellen Sie sicher, dass bei der Implementierung dieser Elemente Aktualisierungen des Schritttyps auf alle Instanzen übertragen werden.

Benutzerdefinierte Schritttypen speichern Daten in verschiedenen Eigenschaften und Einstellungen, mit denen Sie das Verhalten der Instanzen des Schritttyps konfigurieren und die für die Schritttypfunktionalität erforderlichen Daten verwalten können. Dazu gehören:

• Integrierte Typeigenschaften, die für alle Schritttypen vorhanden sind und in Instanzen des Typs nicht geändert werden können
• Standardwerteigenschaften, die den Status neuer Schrittinstanzen definieren, aber in Instanzen des Typs geändert werden können
• Benutzerdefinierte Eigenschaften, die Sie für einen Schritttyp definieren

Integrierte Typeneigenschaften

Integrierte Schritttypeigenschaften gibt es für alle Schritttypen. Der Benutzer kann diese Einstellungen in Instanzen des Schritttyps nicht ändern.  Darüber hinaus werden Änderungen, die Sie an den Werten dieser Eigenschaften vornehmen, auf alle Instanzen des Schritttyps übertragen.

Beispiel: Alle Schritttypen definieren einen Beschreibungsausdruck, der im Bereich „Steps“ (Schritte) neben Instanzen des Schritts angezeigt wird.  Diese Eigenschaft ist für alle Schritttypen vorhanden, der Wert wird jedoch für jeden Schritttyp einzeln festgelegt.  Der Wert kann in Instanzen des Schritttyps nicht geändert werden.

So greifen Sie auf die integrierten Eigenschaften eines Schritttyps zu:

1. Navigieren Sie mit dem Menü View (Ansicht) »Types (Typen) oder der Tastenkombination Strg+T zur Typansicht.
2. Klicken Sie mit der rechten Maustaste auf den Schritttyp, und wählen Sie Properties... (Eigenschaften…) aus, um das Eigenschaftenfenster zu öffnen.

Dialogfeld „Step Type Properties“ (Schritttypeigenschaften)

Die meisten Einstellungen in diesem Dialogfeld sind Standardwerte, die im nächsten Abschnitt beschrieben werden.  Zu den integrierten Eigenschaften gehören:

• Symbol: Das Symbol für den Schritt im Ordner <TestStand Public>/Components/Icons
• Schrittbeschreibungsausdruck: Die Schrittbeschreibung, die im Schrittbereich für Instanzen des Schritttyps angezeigt wird
• Versionseinstellungen: Werden zum Lösen von Typkonflikten verwendet  
• Elementnamensausdruck (Registerkarte „Menu“ (Menü)): Definiert den Namen des Schritts in der Einfügepalette

Erstellen selbstdokumentierender Beschreibungen

Da die Beschreibung in Schrittinstanzen nicht konfigurierbar ist, können Sie sie als Schritttypentwickler definieren, um Benutzern das Erstellen selbstdokumentierender Schritte zu ermöglichen.  Das Beschreibungsfeld wird durch einen Ausdruck angegeben, mit dem Sie dynamische Beschreibungen erstellen können, die wichtige Schritteigenschaften anzeigen.  Wenn Benutzer Änderungen an diesen Eigenschaftswerten in Instanzen des Schritttyps vornehmen, wird die Beschreibung aktualisiert. Dann können Benutzer den Status des Schritts schnell anzeigen, ohne in den Schritteinstellungsbereich zu navigieren.

Beispiel: Die Schrittbeschreibung im zweiten Schritt in der Abbildung unten ist aussagekräftiger und bietet eine bessere Dokumentation.  Diese Beschreibung wird mit dem folgenden Ausdruck definiert:

"Calibrate Channels: " + Str(Step.minChannel) + " - " +Str(Step.maxChannel)

Dieser Ausdruck konfiguriert die Beschreibung so, dass sie dynamisch aktualisiert wird, wenn Benutzer die Schritteigenschaften minChannel und maxChannel konfigurieren.

Beispiele für Schrittbeschreibung

Standardwerte für Schritteigenschaften

Bei der Entwicklung eines Schritttyps können Sie Standardwerte für alle von Benutzern konfigurierbaren Schritteinstellungen konfigurieren.  Darüber hinaus können Sie diese Eigenschaften so konfigurieren, dass sie in Schrittinstanzen deaktiviert werden. So können die von Ihnen festgelegten Standardwerte nicht geändert werden.  Wie integrierte Eigenschaften werden Standardwerte im Fenster mit den Schritteigenschaften definiert.  Alle Standardwerteinstellungen enthalten jedoch das Wort „default“ (Standard), entweder im Einstellungsnamen oder auf der Registerkarte „Settings“ (Einstellungen), auf der sie konfiguriert werden.

Beispiel: Mit der Statusausdruckseigenschaft wird das Schrittergebnis bestimmt.  Diese Eigenschaft ist für alle Schritttypen vorhanden, und der Standardwert wird für jeden Schritttyp einzeln festgelegt.  Bei einigen Schritttypen, wie z. B. dem Numeric Limit Test, ist der Statusausdruck im Schritttyp deaktiviert, sodass er nicht in einzelnen Numeric Limit Test-Schritten bearbeitet werden kann.

Beim Entwerfen eines benutzerdefinierten Schritttyps können Sie alle Eigenschaften deaktivieren, die zwischen den Instanzen des Schritttyps gleich bleiben.  So erhalten Sie mehr Kontrolle darüber, wie Benutzer des Schritttyps das Verhalten ändern können. Wenn Sie verhindern, dass Benutzer Schritteinstellungen bearbeiten, kann das jedoch die Flexibilität einschränken. Sie sollten daher nur Einstellungen deaktivieren, bei denen Sie sicher sind, dass Benutzer sie nie ändern müssen.

Denken Sie daran, dass zukünftige Änderungen, die Sie an den Standardwerten für Schritteigenschaften vornehmen, auch dann nicht an Instanzen des Schritttyps weitergegeben werden, wenn Sie die Bearbeitung in Schrittinstanzen deaktivieren. Weitere Informationen zur Behebung dieses Problems finden Sie unter Updating and Maintaining Step Types (Aktualisieren und Verwalten von Schritttypen).

Hinweise zum Aktualisieren von Standardwerten

Sie sollten die Werte dieser Eigenschaften nicht verwenden, um Funktionen des Schritttyps zu definieren, die möglicherweise von Schritttypentwicklern aktualisiert werden müssen.  Verwenden Sie beispielsweise nicht den Post-Ausdruck des Schritts, um die für den Schritttyp spezifische Funktionalität zu implementieren.  Wenn Sie diese Funktionalität in einer zukünftigen Version des Schritttyps aktualisieren müssen, können Sie nicht sicherstellen, dass alle Instanzen des Schritts aktualisiert werden.  Implementieren Sie die Funktionalität stattdessen in einem Unterschritt vor oder nach dem Schritt.

Benutzerdefinierte Eigenschaften

Zusätzlich zu den integrierten Eigenschaften können Sie benutzerdefinierte Eigenschaften definieren, die speziell für den Schritttyp gelten.  Mit diesen Eigenschaften können Sie Daten speichern, die sich speziell auf die Schritttypfunktion beziehen.  

Beispiel: Numeric Limit-Testschritte enthalten die Eigenschaft „Limits.High“, die für den Schritttyp „Numeric Limit“ eindeutig ist.  Der Typ definiert den Standardwert 11 für diese Eigenschaft, und Benutzer können den Wert für jede von ihnen erstellte Instanz ändern.

So erstellen Sie benutzerdefinierte Schritteigenschaften:

1. Navigieren Sie mit dem Menü View (Ansicht) »Types (Typen) oder der Tastenkombination Strg+T zur Typansicht.
2. Blenden Sie das Element „Step Type“ (Schritttyp) ein.
3. Klicken Sie mit der rechten Maustaste auf die übergeordnete Eigenschaft oder auf den Eintrag <Right click to insert field> (<Rechtsklick zum Einfügen eines Feldes>), um eine neue Eigenschaft hinzuzufügen.

Wenn Sie eine Eigenschaft im Ergebniscontainer des Schritttyps definieren, wird die Eigenschaft in die Ergebniserfassung aufgenommen.  Dann können Sie das Flag IncludeInReport oder IncludeInDatabase verwenden, um die Daten in einem Protokoll oder einer Datenbank zu protokollieren.

Standardmäßig können Benutzer Schritteigenschaftswerte für jede Schrittinstanz ändern.  Wenn Sie jedoch das Flag „shared“ für eine Schritteigenschaft im Schritttyp setzen, wird der Wert im Schritttyp gesperrt.  Im Gegensatz zu den Standardwerten für Schritte werden Aktualisierungen des Werts an Instanzen des Schritttyps weitergegeben.

Bestimmen des Umfangs eines benutzerdefinierten Schritttyps

Die Datentypen, die Sie für Schritteigenschaften auswählen, sollten durch den Umfang des Schritttyps bestimmt werden. Betrachten Sie beispielsweise die Schritte „Numeric Limit Test“ und „Multiple Numeric Limit Test“.  Der Multiple Numeric Limit Test kann zusätzliche Grenzwerte berücksichtigen und bietet mehr Funktionen. Er führt jedoch auch zu Komplexität der Benutzeroberfläche zur Bearbeitungszeit und der Ergebnisprotokollierung.  Der einfachere Numeric Limit Test hat einen kleineren Umfang und eine viel einfachere Oberfläche. Schritte mit kleinerem Umfang erfordern nicht nur weniger Entwicklungsarbeit, sondern können auch von Entwicklern von Testsequenzen einfacher verwendet werden.

Bei der Entwicklung Ihrer eigenen benutzerdefinierten Schritttypen müssen Sie den Umfang des Schritts vor den benutzerdefinierten Eigenschaften definieren, da die von Ihnen ausgewählten Eigenschaften einen erheblichen Einfluss auf die Komplexität des Schritttyps haben.

In den folgenden Abschnitten wird beschrieben, wie Sie mithilfe von Unterschritten die folgenden Verhaltensweisen für Schritttypen implementieren können:

• Laufzeitfunktionalität, die für alle Instanzen des Schritttyps vor oder nach dem Hauptcodemodul ausgeführt werden soll
• Benutzeroberflächen zum Anzeigen und Bearbeiten von Schrittdaten während der Bearbeitung von Testsequenzen
• Funktionalität, die ausgeführt werden soll, wenn der Testentwickler neue Instanzen des Schritts erstellt

Implementieren von Unterschritten

Unterschritte rufen Codemodule mit einem der bereitgestellten TestStand-Adapter auf.  Unterschritte können in Instanzen des Schritts nicht geändert werden. Alle Änderungen an Unterschritteinstellungen werden auf Instanzen des Schritttyps übertragen.   

So fügen Sie einem benutzerdefinierten Schritttyp Unterschritte hinzu:

1. Navigieren Sie mit dem Menü View (Ansicht) »Types (Typen) oder der Tastenkombination Strg+T zur Typansicht.
2. Klicken Sie mit der rechten Maustaste auf den Schritttyp, und wählen Sie Properties... (Eigenschaften) aus.
3. Wählen Sie die Registerkarte „Substeps“ (Unterschritte) aus.  Wählen Sie den Adapter aus, der dem gewünschten Codemodul entspricht.
4. Klicken Sie auf „Add“ (Hinzufügen), und wählen Sie einen Unterschritttyp aus.  Ein neuer Eintrag wird in der Liste der Unterschritte angezeigt.
5. Wählen Sie den Eintrag aus, und klicken Sie auf Specify Module (Modul angeben), um das Codemodul für den Unterschritt genauso zu konfigurieren wie das Codemodul für einen Schritt.

     Unterschritte „Post“ und „Edit“ des Schritttyps „Multiple Numeric Limit Test“

Definieren der Laufzeitfunktionalität für den Schritttyp

Sie können die Laufzeitfunktionalität für den Schritttyp mithilfe von Unterschritten vor und nach dem Schritt definieren.  Diese Unterschritte werden bei Ausführung des Schritts vor oder nach dem Hauptcodemodul ausgeführt.   

Beispiel: Der Schritttyp „Message Popup“ (Nachrichten-Popup) verwendet ein C-Codemodul, um das Nachrichtenfeld zur Laufzeit zu erstellen und anzuzeigen.  Dieses Modul wird in einem Unterschritt nach dem Schritt aufgerufen.  

          Ausführungsreihenfolge für Schritte: Unterschritte

Verwenden Sie diese Unterschritte, um Funktionalität zu definieren, die für alle Instanzen des Schritts gilt.  Für Unterschritte sind häufig bestimmte Daten im Zusammenhang mit dem Verhalten des Schritttyps erforderlich.  Definieren Sie diese Daten in benutzerdefinierten Schritteigenschaften, um sicherzustellen, dass sie in allen Instanzen des Schritts verfügbar sind.

Wenn mehrere Unterschritte vor oder nach dem Schritt vorhanden sind, werden diese in der Reihenfolge ausgeführt, in der sie auf der Registerkarte „Substep“ (Unterschritt) des Dialogfeldes „Step Type Property“ (Schritttypeigenschaft) angezeigt werden.

Standardmäßig können Testentwickler für jede Instanz des Schritttyps ein Codemodul angeben.  Wenn für den Schritttyp kein Codemodul erforderlich ist, sollten Sie die Option „Specify Module“ (Modul angeben) auf der Registerkarte „Disable Properties“ (Eigenschaften deaktivieren) für die Schritttypkonfiguration deaktivieren.  Viele integrierte Schritttypen werden auf diese Weise entworfen, z. B. die Schritte für Anweisung und Nachrichten-Popup.

Bereitstellen von visuellem Feedback für lange Vorgänge

TestStand wartet, bis der Code in den Unterschritten vor oder nach dem Schritt ausgeführt wurde, bevor fortgefahren wird. Wenn Codemodule für diese Schritte langsam oder im Hintergrund arbeiten, kann es so scheinen, als würde TestStand nicht mehr reagieren. Um das zu beheben, können Sie den Cursor ändern oder UI-Nachrichten wie UIMsg_ProgressPercent verwenden, um den Fortschrittsbalken in der Statusleiste zu aktualisieren. 

Weitere Informationen zu diesem Ansatz finden Sie unter Updating the Status Bar using UI Messages (Aktualisieren der Statusleiste mithilfe von UI-Nachrichten).

Verwenden des Termination Monitor

Von Ihnen entwickelte Codemodule sollten einen Termination Monitor enthalten und regelmäßig abfragen, um zu gewährleisten, dass Benutzer die Sequenzausführung mithilfe der in TestStand oder in der TestStand-API integrierten Optionen beenden oder abbrechen können.  Mithilfe des Termination Monitor können Sie den Unterschritt schnell beenden, wenn Benutzer die Sequenzausführung beenden.

Weitere Informationen zur Implementierung des Termination Monitor in Ihrem Code finden Sie im Termination Monitor-Beispiel.

Verwenden von Unterschritten vor oder nach dem Schritt anstelle des Standardmoduls

Implementieren Sie das Codemodul für die zum Schritttyp gehörenden grundlegenden Operationen als Unterschritt vor oder nach dem Schritt, anstatt als Standardmodul. Verwenden Sie die Standardmoduleinstellung nur, wenn jede Instanz eines Schritts ein anderes Codemodul aufrufen kann. Die Standardmoduleinstellung ist in jeder Instanz separat vorhanden, und die vorhandenen Schrittinstanzen werden beim Ändern der Einstellung des Schritttyps von TestStand nicht standardmäßig aktualisiert. Änderungen an Unterschritten betreffen allerdings automatisch alle vorhandenen Instanzen des Schritttyps.

Erstellen von Bearbeitungsschnittstellen für Schritttypen

Bearbeitungsunterschritte bieten eine grafische Benutzeroberfläche (GUI), die in einem Codemodul implementiert ist. Darin können Benutzer die Variablen oder Einstellungen dieser Schrittinstanz zur Bearbeitungszeit ändern. In der Regel wird der Unterschritt „Edit“ (Bearbeiten) verwendet, um benutzerdefinierte Schritteigenschaften zu konfigurieren, die Sie für den Schritttyp definieren.   

Beispiel: Der Schritttyp „Open Database“ (Datenbank öffnen) bietet über einen Bearbeitungsunterschritt ein Dialogfeld, in dem Benutzer die Schritteigenschaften ConnectionString und DatabaseHandle konfigurieren können. Dabei handelt es sich um benutzerdefinierte Eigenschaften für den Datenbankschritttyp.

Der Unterschritt „Edit“ (Bearbeiten) bietet eine Benutzeroberfläche zum Konfigurieren der Schritteinstellungen

Wenn Benutzer eine Instanz eines benutzerdefinierten Schritttyps erstellen, können sie über eine Schaltfläche im Bereich mit den Schritteinstellungen auf die Benutzeroberfläche des Unterschritts „Edit“ (Bearbeiten) zugreifen. Dadurch wird die Benutzeroberfläche des Bearbeitungsunterschritts in einem neuen Fenster gestartet.  Sie können die Benutzeroberfläche des Bearbeitungsunterschritts jedoch auch direkt in die Registerkarte einbetten, wie bei vielen integrierten Schritttypen.  Dieser Ansatz erfordert zusätzlichen Entwicklungsaufwand und muss in einer .NET-Sprache entwickelt werden. Er bietet jedoch eine nahtlosere Bearbeitungsoberfläche für Benutzer des Schritttyps.  Weitere Informationen zum Implementieren eingebetteter Oberflächen des Bearbeitungsunterschritts finden Sie unter Creating Custom Step Type Edit Tabs in the Sequence Editor (Erstellen von Registerkarten zum Bearbeiten benutzerdefinierter Schritttypen im Sequenzeditor).

Vergleich zwischen einer eingebetteten Bearbeitungsoberfläche (oben) und einem Bearbeitungsunterschritt, der in einem separaten Fenster gestartet wird (unten)

Einzelner oder mehrere Bearbeitungsunterschritte

Ein benutzerdefinierter Schritttyp kann viele Eigenschaften definieren. Diese können verwirrend sein, wenn sie dem Benutzer alle gleichzeitig angezeigt werden.  Wenn Sie den typischen Ansatz für Bearbeitungsunterschritte verwenden, die in einem separaten Fenster gestartet werden, verwenden Sie Organisationsmethoden innerhalb eines einzelnen Bearbeitungsunterschritts. Nutzen Sie z. B. Registerkarten, um die Daten in übersichtlichen Abschnitten zu organisieren.  Die Verwendung mehrerer Bearbeitungsunterschritte wird nicht empfohlen, da jede Oberfläche unabhängig gestartet werden muss.  Beispielsweise implementiert der Schritt „Open SQL Statement“ (SQL-Anweisung öffnen) einen einzelnen Bearbeitungsunterschritt mit mehreren Registerkarten.   

Der Unterschritt „Edit“ (Bearbeiten) für den Schritt „Open SQL Statement“ (SQL-Anweisung öffnen) enthält zwei Registerkarten zum Kategorisieren der Einstellungen

Wenn Sie den Ansatz des eingebetteten Schrittbereichs für komplexe Schritttypen verwenden, sollten Sie mehrere Bearbeitungsbereiche verwenden, da die Daten auf den Schrittregisterkarten leicht sichtbar sind. Beispielsweise enthält der Schritt „Multiple Numeric Limit Test“ zwei Registerkarten zum Bearbeiten der Quelle der numerischen Daten und der Grenzwertbedingungen für jede Datenquelle.  

Die Registerkarten „Limit“ (Grenzwert) und „Data source“ (Datenquelle) werden jeweils in einem separaten Bearbeitungsbereich implementiert

Setzen von Bearbeitungsunterschritte auf „Modal“ für TestStand

Bearbeitungsunterschritte und andere Benutzeroberflächen-Codemodule müssen immer auf „Modal“ für TestStand gesetzt werden, da beim Aufrufen von Bearbeitungsunterschritten in TestStand der Sequence Editor deaktiviert wird. Wenn Codemodule nicht modal sind, ist es möglich, dass sie vom TestStand-Fenster verdeckt werden. Benutzer könnten dann den Eindruck erhalten, dass der Sequence Editor abgestürzt ist, und versuchen, TestStand zu beenden.

Weitere Informationen zum Implementieren der Modalität in einem Unterschrittmodul finden Sie im Beispiel Making Dialog Boxes Modal to TestStand (Setzen von Dialogfeldern auf „Modal“ für TestStand).

Verwenden von Ausdrücken für maximale Flexibilität

Mit Ausdrucksfeldern in einer Benutzeroberfläche für Bearbeitungsunterschritte können Benutzer ganz flexibel mit Daten interagieren und Variablen und Logik in den Eigenschaftswerten zu verwenden.  Die Arbeit mit dem Ausdruckssteuerelement kann jedoch aufwendiger sein als die Arbeit mit Zeichenfolgen- oder numerischen Elementen. Sie erfordert außerdem zusätzliche Überprüfungen, um sicherzustellen, dass der Ausdruck einen gültigen Wert für die Eigenschaft ergibt.  

Ausdrücke sind flexibler als feste Werte für die Angabe von Einstellungen

Definieren des Verhaltens beim Erstellen von Schrittinstanzen durch Entwickler

In vielen Fällen sollten Sie die Funktionen definieren, die auftreten, wenn ein Testentwickler eine neue Instanz eines Schritts erstellt.  Beispielsweise verwendet der integrierte Schritttyp „If“ (Wenn) einen OnNewStep-Unterschritt, um einen passenden Endschritt einzufügen.

Um diese Art von Funktionalität zu implementieren, erstellen Sie einen Bearbeitungsunterschritt, und benennen Sie den Unterschritt in „OnNewStep“ um.  Diese Unterschritte verwenden in der Regel die TestStand-API, um die Schrittinstanz zu bearbeiten oder zusätzliche Schrittinstanzen zu erstellen.

Allgemeine Empfehlungen für Unterschritte

Verwenden von Parametern im Vergleich zur TestStand-API für den Zugriff auf Daten in Unterschritten

Wie bei einem Standardcodemodul gibt es zwei Methoden zum Bereitstellen von TestStand-Daten für einen Unterschritt.  Sie können Daten über die Parameter des Codemoduls übergeben.  Alternativ können Sie die TestStand-API aus dem Codemodul aufrufen, um direkt auf Eigenschaften zuzugreifen und diese zu ändern. Unterschritte vor und nach dem Schritt müssen normalerweise nur die Schritteigenschaften lesen, um ihr Verhalten zu bestimmen. Beispielsweise der Temperaturwert zum Einrichten einer beheizten Kammer.  Bearbeitungsunterschritte benötigen jedoch den aktuellen Status der Eigenschaften für die Anzeige in der anfänglichen Benutzeroberfläche, aber auch eine Möglichkeit zum Aktualisieren aller vom Benutzer geänderten Werte.   

In den meisten Fällen bietet es sich an, Parameter zum Übergeben von Daten zu verwenden, anstatt mit der TestStand-API direkt darauf zuzugreifen.  Die Verwendung von Parametern ist weniger fehleranfällig: Fehler in den Eigenschaftsnamen oder Datentypen sind leicht zu finden, da die Eigenschaften in den Schritttypeinstellungen in TestStand und nicht direkt im Codemodul definiert werden. Wenn alle Eigenschaften in der Schrittkonfiguration definiert sind, kann der Schritttyp außerdem besser verwaltet werden.  Änderungen an den Schritteigenschaften können ohne Änderungen am Codemodul berücksichtigt werden.

Die Verwendung der API für den direkten Zugriff auf Eigenschaften kann jedoch in Fällen nützlich sein, in denen das Codemodul basierend auf dem Status des Schritts dynamisch auf eine Vielzahl von Daten zugreift.  Die Verwendung von Schrittparametern kann in diesem Fall zu einer langen Liste von Parametern führen, von denen nur einige unter verschiedenen Bedingungen verwendet werden.

Der Moduladapter liest oder schreibt Schrittvariablen in die Ein- und Ausgaben von Codemodulen und sucht nach Fehlern

Der Zugriff auf Schritteigenschaften aus LabVIEW mithilfe der TestStand-API bietet keine Überprüfung von Parameterfehlern zur Bearbeitungszeit

Entladen von Modulen während der Bearbeitung

Beachten Sie beim Entwickeln und Testen von Codemodulen für Unterschritte eines benutzerdefinierten Schritttyps, dass TestStand das Codemodul lädt und im Arbeitsspeicher reserviert, wenn der Unterschritt ausgeführt wird. Dadurch wird die Leistung verbessert, da das Modul für nachfolgende Ausführungen geladen bleibt. Sie können das Codemodul jedoch erst bearbeiten, wenn TestStand es entlädt. Sie können das Codemodul auf zwei Arten entladen:

1. Wählen Sie File (Datei) » Unload All Modules (Alle Module entladen), um alle derzeit im Arbeitsspeicher reservierten Module zu entladen.
2. Wählen Sie im Konfigurationsbereich für Unterschritte die Schaltfläche „Edit“ (Bearbeiten) aus, um das Modul zu entladen und in der entsprechenden Entwicklungsumgebung zu öffnen.

Bewährte Methoden für die Verwaltung benutzerdefinierter Schritttypen

Speichern und Verteilen von benutzerdefinierten Schritttypen

Überlegen Sie sich, wie die von Ihnen erstellten benutzerdefinierten Schritte gespeichert und verteilt werden. Es wird empfohlen, alle Schritttypen in einer Typpalettendatei und nicht in einer Sequenzdatei zu erstellen, da TestStand die Typpalettendateien beim Laden einer Sequenzdatei nach Schritttypaktualisierungen durchsucht. TestStand unterstützt auch die Wiederverwendung von Schritten, indem eine Kopie jedes verwendeten Schritttyps in einer Sequenzdatei aufbewahrt wird. Wenn Sie die Sequenzdatei ohne die Typpalettendatei bereitstellen, enthält die Sequenzdatei weiterhin eine Kopie des Schritttyps.   

Als Framework-Entwickler werden Ihre Schritttypen häufig von mehreren Testentwicklern verwendet.  Das kann eine Herausforderung sein, da Schritttypen mit vielen Dateien verknüpft sind.  Verwenden Sie die folgenden Verzeichnisse zum Speichern der Dateien für Ihren Schritttyp, um die Verwaltung der Schritttypdateien zu erleichtern:

• Typpalettendatei mit der Typdefinition <TestStand Public>/Components/TypePalettes/
• Unterschritt-Codemoduldateien <TestStand Public>/Components/StepTypes/[typeName]
• Benutzerdefiniertes Symbol <TestStand Public>/Components/Icons/[typeName]

Mithilfe dieser Verzeichnisse können Sie die erforderlichen Dateien auf alle Testentwicklersystemen im öffentlichen TestStand-Verzeichnis verteilen.  Wenn Sie Ihren Typ in einer neuen Typpalettendatei definiert haben, können Sie TestStand so konfigurieren, dass die Typpalette automatisch importiert wird. Fügen Sie dazu das Präfix „Install_“ vor dem Dateinamen der Typpalettendatei hinzu.  Weitere Informationen zu dieser Methode finden Sie im Hilfethema zu Typpalettendateien.

Vermeiden Sie das Umbenennen oder Ändern des Datentyps von Schritteigenschaften

Wenn Sie den Typ einer benutzerdefinierten Eigenschaft ändern müssen, können Sie eine andere Eigenschaft mit dem neuen Typ erstellen und die Eigenschaft mit dem vorherigen Typ beibehalten. Wenn Sie den Namen oder Datentyp einer Eigenschaft ändern, ersetzt TestStand den Wert der Eigenschaft in Schrittinstanzen durch den Standardwert der Eigenschaft. Sie können nicht nur eine neue Eigenschaft mit dem neuen Typ erstellen, sondern auch dem Schritttyp Logik hinzufügen, um Fälle abzudecken, bei denen ein Schritt die alte und die neue Eigenschaft verwendet. Wenn TestStand beispielsweise Grenzwerte als Ausdrücke implementiert hat, wurden zwei neue boolesche Eigenschaften hinzugefügt, um die Verwendung der alten numerischen Grenzwerteigenschaft anzugeben. Die Eigenschaften „UseLowExpr“ und „UseHighExpr“ bestimmen, ob der Schritt die alten numerischen Grenzwerte oder die neuen Ausdrucksgrenzwerte auswertet.

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