Empfohlene Methoden für die Verwaltung von TestStand-Typen

TestStand greift für das Speichern von Informationen und das Definieren des Verhaltens von Schritten auf verschiedene Typenkategorien zurück.  In Datentypen werden Informationen während der Entwicklung und Ausführung eines Testsystems gespeichert. Schritttypen definieren das Verhalten eines Schritts und die Ergebnisse, die der Schritt während der Ausführung sammelt.  Sowohl Daten- als auch Schritttypen können integriert und im Lieferumfang von TestStand enthalten sein, die Benutzer können jedoch auch eigene Typen entwickeln.

TestStand-Typen werden in Schritttypen, benutzerdefinierte Datentypen und Standarddatentypen unterteilt.

Datentypen

In vielen Fällen müssen Sie für das Management der Testdaten komplexe Datenstrukturen definieren.  Mithilfe von Datentypen können Sie diese Datenstrukturen an einem zentralen Ort verwalten.  Datentypen definieren die Struktur von TestStand-Eigenschaften oder -Variablen, z. B. globale Variablen für Sequenzdateien, lokale Variablen für Sequenzen und Schritteigenschaften.  Alle Datentypen bestehen aus den folgenden Bausteinen:

• Typname: Hiermit wird der Typ eindeutig identifiziert.  In TestStand können nicht mehrere Typen desselben Namens in den Speicher geladen werden.
• Version: Hiermit werden Versionen von Typen verwaltet und Typkonflikte gelöst.
• Daten: Die Struktur der im Typ definierten Eigenschaften.
• Standardwerte: Die Eigenschaftswerte, die Sie im Bereich „Types“ (Typen) definieren, dienen als Standardwerte für Instanzen des Typs.

In der Regel kommen Datentypen zum Einsatz, wenn Sie einen Satz zusammengehöriger komplexer Daten definieren, die verschiedene Eigenschaften und Container enthalten.  Ein Fehlerdatentyp kann beispielsweise aus drei Eigenschaften bestehen: einer booleschen Eigenschaft im Typ, aus der hervorgeht, ob ein Fehler aufgetreten ist, einer Zeichenfolgenwerteigenschaft mit der Fehlermeldung und einer Ganzzahleigenschaft mit dem Fehlercode.

Greifen Sie beim Verwalten komplexer Daten immer auf einen Datentyp zurück, da beim Ändern der Struktur eines Datentyps alle Instanzen dieses Datentyps aktualisiert werden und die neue Datentypstruktur widerspiegeln.  So können Sie die Struktur Ihrer Daten an einem zentralen Ort verwalten.  

Standarddatentypen

Standarddatentypen sind bestimmte Datentypen, die im Lieferumfang von TestStand enthalten sind und ein Standardformat zum Speichern gängiger Datentypen wie Fehler, Pfad oder Wellenform definieren.  Sie können die meisten Standarddatentypen nicht ändern. Eine Änderung ist zwar bei einigen Typen möglich, aber Sie sollten dies nur tun, wenn dies unbedingt erforderlich ist, da andere TestStand-Komponenten häufig auf diese Typen zurückgreifen.  

Schritttypen

So wie Sie eine Variable oder Eigenschaft aus einem benutzerdefinierten Datentyp erstellen können, erstellen Sie einen Schritt aus einem Schritttyp.  Jeder Schritttyp besteht aus einem eindeutigen Namen, integrierten und benutzerdefinierten Schritttypeigenschaften sowie Standardwerten für Eigenschaften und Operationen.  Alle Schritttypen haben einen gemeinsamen Satz von Eigenschaften, die die grundlegende Funktionsweise und die Daten für alle Schritte definieren.  Im Dialogfeld „Step Type Properties“ (Eigenschaften des Schritttyps) können Sie diese allgemeinen Eigenschaften bearbeiten.

In diesem Dokument geht es vornehmlich um Konzepte, die für alle Typen gelten, einschließlich Schritt- und Datentypen.  Weitere Informationen zu den empfohlenen Methoden für Schritttypen finden Sie im Dokument Best Practices for Custom Step Type Development (Empfohlene Methoden für die Entwicklung benutzerdefinierter Schritttypen).

Wenn Sie neue Typen erstellen, ist es wichtig, den Speicherort der Typen auf der Festplatte zu berücksichtigen. TestStand kann Typen in Sequenzdateien oder in Typpalettendateien speichern.  In den meisten Fällen sollten alle von Ihnen erstellten Typen in einer Typpalettendatei gespeichert werden. Eine Typpalette bietet die folgenden Vorteile:

• Typpalettendateien bieten einen zentralen Speicherort für Typen in Dateien mit mehreren Sequenzen.
• Typpalettendateien können so konfiguriert werden, dass sie beim Starten von TestStand in den Speicher geladen werden, damit die Typen für alle neuen Sequenzdateien verfügbar sind.
• Durch einen zentralen Speicherort für Typen können Typkonflikte vermieden werden, die unter Umständen auftreten, wenn mehrere Entwickler Änderungen an Typen vornehmen, die an mehreren Speicherorten gespeichert sind.
• Standardmäßig aktualisiert TestStand keine Typen in einer Typpalette automatisch und bietet so Schutz vor einer unerwünschten Typweitergabe.

Wenn Sie einen Typ aus einer Typpalettendatei in einer Sequenzdatei verwenden, wird eine Kopie des Typs in der Datei gespeichert, damit er auch ohne die Typpalettendatei funktioniert. Sie sollten jedoch nur an der Version in der Typpalette Typänderungen vornehmen.  Wenn Sie Ihre Testsequenz bereitstellen, müssen Sie keine Typpalettendateien in die Bereitstellung einbeziehen.  Durch das Einfügen der Typpalettendatei können Sie jedoch einfacher inkrementelle Aktualisierungen am Testsystem vornehmen.  Wenn für bestimmte Typen Aktualisierungen erforderlich sind, können Sie eine neue Version der Typpalettendatei erstellen und bereitstellen, ohne Änderungen an Sequenzdateien vornehmen zu müssen.

Wenn Sie Typen für mehrere Entwickler freigeben, müssen Sie dafür sorgen, dass jedem Entwickler dieselbe, neueste Version der Typdefinition zur Verfügung steht. Sie müssen auch dafür sorgen, dass Entwickler keine separaten Änderungen an demselben Typ vornehmen, da das Zusammenführen von Änderungen an Typen schwierig ist.  Mit den folgenden Techniken können Sie gemeinsam genutzte Typen effektiv verwalten:

• Definieren eines Eigentümers für Typpalettendateien
• Einsatz der Versionsverwaltung für Typpaletten

Definieren des Eigentums an Typpalettendateien

Um Änderungen an Typen zu steuern, ist es wichtig, für jeden Typ einen eindeutigen Eigentümer festzulegen, der Änderungen an Typen entweder implementiert oder genehmigt.  In einer großen Organisation ist es häufig sinnvoll, verschiedene Personen in der Gruppe als Eigentümer festzulegen.  Um diese Vorgehensweise zu vereinfachen, erstellen Sie separate Typpalettendateien, um Typen in logischen Gruppen zu organisieren. Sie können beispielsweise projektspezifische Typen in einer Typpalette mit dem Projektnamen speichern, allgemeinere Typen hingegen, die Sie in mehreren Projekten einsetzen, in einer gemeinsam genutzten Typpalettendatei.  Sie können dann für jede Typpalettendatei einen Eigentümer festlegen.

Durch das Organisieren von Typpalettendateien in logischen Gruppen können Sie jeder Typpalettendatei einfacher Typeigentümer zuweisen.

Beschränkung von Änderungen an Typpalettendateien mithilfe der Versionsverwaltung

Um darüber hinaus Änderungen an Typversionen zu steuern, sorgen Sie mit einer Lösung zur Versionsverwaltung dafür, dass nur ausgecheckte Dateien bearbeitet werden können.  Sie können mit Versionsverwaltungsberechtigungen dafür sorgen, dass nur der Eigentümer einer bestimmten Typpalettendatei Änderungen einchecken kann.  Der Eigentümer der Typpalette sollte mindestens Benachrichtigungen für die Dateien aktivieren, damit er über alle Aktivitäten im Zusammenhang mit der Datei informiert ist.

Benutzer haben zwar weiterhin die Möglichkeit, Typen auf ihrem lokalen Computer zu ändern, aber die Versionsverwaltung verhindert, dass TestStand diese Änderungen auf der Festplatte oder in der freigegebenen Version der Datei speichert.  

Vermeiden von Konflikten zwischen nicht verwandten Typen

Ein Grund für Typkonflikte sind versehentliche Namensdopplungen bei nicht verwandten Typen. Die Namen von Typen sind eine eindeutige Kennung im System. Stellen Sie daher beim Entwickeln neuer Typen dem Typnamen eine eindeutige Organisations-ID voran.  Beispielsweise beginnen alle Namen der Schritttypen aus dem Lieferumfang von TestStand mit dem Präfix „NI“.  Bei dieser Vorgehensweise stehen Ihre Typen nicht mit außerhalb Ihrer Organisation erstellten Typen in Konflikt, wenn Code von Gruppen gemeinsam genutzt wird.

TestStand lädt jeweils nur eine Version eines Typs mit einem bestimmten Namen, damit für alle auf der Station geladenen Dateien dieselben Typinformationen gelten.  Wenn Sie versuchen, eine Sequenzdatei zu öffnen oder eine Typpalette zu laden, die einen Typ mit demselben Namen wie der bereits geladene aufweist, kommt es zu einem Typkonflikt, bei dem TestStand festlegen muss, ob der aktuelle Typ geladen bleiben oder durch den neuen ersetzt werden soll.  

Ein Typkonflikt tritt auf, wenn Sie versuchen, eine Datei zu laden, die eine andere Typdefinition enthält, als derzeit in TestStand geladen ist.  Der Konflikt muss gelöst werden, bevor die neue Datei geladen werden kann.

Wenn Entwickler darauf achten, eindeutige Typnamen und Typen in einer einzigen kontrollierten Typpalettendatei zu verwalten, kann TestStand korrekt mit Typkonflikten umgehen.  Typkonflikte können jedoch zu falschen Änderungen an Ihren Dateien führen, wenn automatische Regeln zur Lösung von Typkonflikten angewendet werden oder die Entwickler falsche Entscheidungen treffen. Dies kann eine unerwünschte Weitergabe von Typversionen zur Folge haben.  

Unerwünschte Weitergabe der Typversion

Die unerwünschte Typweitergabe beschreibt den Fall, dass die Lösung eines Typkonflikts zu unerwünschten Änderungen an Dateien mit einer anderen Version eines Typs führt. Wenn Dateien mit dem falschen Typ freigegeben werden, können andere Entwickler unwissentlich die falsche Version des Typs laden.  Je mehr Entwickler die Dateien gemeinsam nutzen, desto stärker breitet sich der neue Typ auf die Dateien aus. In einem solchen Fall kann es schwierig sein, jede Datei mit dem falschen Typ zu finden.
Zu dieser Situation kann es bei der Lösung von Konflikten kommen, die in den folgenden Situationen auftreten:

• Laden eines Typs in einer früheren TestStand-Version, in der der Typ Kompatibilitätsprobleme verursacht
• Erstellen mehrerer nicht verwandter Typen mit demselben Namen
• Parallel von mehreren Entwicklern vorgenommene Änderungen an einem Typ

Mit den Techniken aus diesem Abschnitt können Sie die Zahl der Fälle, in denen Typkonflikte falsch behandelt werden, minimieren und die Weitergabe unerwünschter Typversionen verhindern.

Pflege des Felds für die Typversion

Bei TestStand-Typen ist im Versionsfeld angegeben, welche Version eines Typs aktuell ist.  Wenn die neueste Version des Typs in den Speicher geladen wird und Sie eine Sequenzdatei mit einer älteren Version des Typs laden, kann TestStand die Datei abhängig von den Stationseinstellungen automatisch so aktualisieren, dass die neuere Typversion verwendet wird.  Standardmäßig löst TestStand automatisch alle Konflikte, bei denen keine Typen in Typpalettendateien aktualisiert werden.

Damit die Typversionen aktualisiert werden, verfolgt TestStand die von Ihnen bearbeiteten Typen mithilfe des Flags „Modified type“ (Geänderter Typ).  Wenn Sie einen Typ speichern, bei dem dieses Flag aktiviert ist, zeigt TestStand in einer Warnung an, dass Änderungen vorgenommen wurden.  

TestStand gibt eine Warnung aus, wenn Sie Änderungen an Typen vornehmen. Damit wird vor dem Speichern geprüft, ob die Änderungen beabsichtigt sind.

In diesem Fall sollten Sie die Typversionen inkrementieren. Dadurch werden die von Ihnen vorgenommenen Änderungen beim Laden in TestStand auf andere Dateien, die auf den Typ verweisen, übertragen.  Sie sollten jedoch nicht die Option zum Speichern der Einstellungen ohne Eingabeaufforderung wählen, da die Aufforderung wie eine Warnung vor der Speicherung unerwünschter Änderungen an Typen funktioniert.  Wenn Sie sich bei der Änderung nicht sicher sind, können Sie im Dialogfeld den Speichervorgang abbrechen und den Typ daraufhin überprüfen, ob die Änderungen gültig sind.

Konfigurieren der automatischen Lösung von Typkonflikten

In einigen Fällen kann TestStand automatisch bestimmen, welcher Typ im Falle eines Typkonflikts geladen werden soll.  Eine automatische Konfliktlösung ist nur unter folgenden Bedingungen möglich:

• Die Typversionen sind bei den beiden Typen unterschiedlich.
• Das Flag „modified“ (geändert) ist für keinen der beiden Typen gesetzt.

Bei der TestStand-Einstellung „Allow Automatic Type Conflict Resolution“ (Automatische Typkonfliktlösung zulassen) können Sie bestimmen, in welchen Fällen TestStand diese Konflikte automatisch löst.  So rufen Sie diese Einstellung auf:

1. Klicken Sie im Sequenzeditor auf Configure » Station Options (Konfigurieren »Stationsoptionen).
2. Wählen Sie die Registerkarte File (Datei).

Mit TestStand können Sie konfigurieren, in welchen Fällen Typkonflikte automatisch behandelt werden und in welchen Fällen der Entwickler aufgefordert wird, die zu speichernde Typversion auszuwählen.

In den meisten Fällen sollten Sie die Standardeinstellung beibehalten, d. h. nur dann eine Eingabeaufforderung anzeigen, wenn eine Typpalettendatei geändert wird.  Bei dieser Einstellung entscheidet sich TestStand automatisch für den Typ mit der höheren Version, solange der Typ mit der niedrigeren Version nicht in einer Typpalettendatei gespeichert ist.  Bei dieser Einstellung wird die Eingabeaufforderung für Typkonflikte nur angezeigt, wenn die Gefahr einer unerwünschten Typweitergabe besteht.  Außerdem werden harmlose Konflikte wie das Laden einer älteren Sequenzdatei mit älteren NI-Typen in einer neuen Version von TestStand automatisch gelöst und der Benutzer muss keine Entscheidung treffen.

Beispiel: Entwickler A aktualisiert den Schritttyp „RunCalibration“, einen Typ, der in der Unternehmenstyp-Palettendatei „Company_types.ini“ gespeichert ist.  Nach einem Gespräch mit dem Eigentümer der Typpalettendatei wird die Änderung am Typ gespeichert und die Typversion auf 1.0.1.0 erhöht.  Anschließend wird die aktualisierte Typpalette im Versionsverwaltungs-Repository gespeichert.  Entwickler B führt später eine Synchronisierung mit dem Repository durch und erhält die Version von „Company_types.ini“ mit dem aktualisierten Typ.  Anschließend öffnet er TestStand und lädt eine Sequenzdatei, die auf den Typ verweist.  Da die Sequenzdatei immer noch auf die vorherige Typversion verweist, wird die Referenz in der Sequenzdatei automatisch aktualisiert. Dies ist das gewünschte Verhalten.

Ein dritter Entwickler C verfügt jedoch auch über eine Sequenzdatei mit dem Schritt „RunCalibration“ und nimmt versehentlich eine separate Änderung am Schritttyp „RunCalibration“ vor, ohne den Typeigentümer zu konsultieren, und aktualisiert seine lokale Instanz auf Version 1.1.0.0.  Wenn dieser Entwickler die Typpalettendatei des Unternehmens synchronisiert und dann die Sequenzdatei in TestStand lädt, fordert TestStand ihn auf, den Typkonflikt zu lösen, da der Typ geändert wird, wenn die neuere Version verwendet wird.  Entwickler C weiß, dass die Typpalettendatei aktualisiert wurde, und wendet sich entweder an den Eigentümer der Typpalette oder setzt seine lokal vorgenommenen Änderungen zurück.

Wenn TestStand den Typkonflikt nicht automatisch lösen kann, werden Sie zur Entscheidung aufgefordert:

Im Dialogfeld „Type Conflict in File“ (Typkonflikt in Datei) lösen Sie Typkonflikte, die nicht automatisch behoben werden können.

Um den Typkonflikt zu lösen, können Sie einen der beiden Typen laden, einen der Typen umbenennen oder das Öffnen der Datei abbrechen.  Wenn Sie die zu verwendende Version auswählen, konvertiert TestStand alle Instanzen im Speicher so, dass sie dem von Ihnen ausgewählten Typ entsprechen. Wenn Sie einen der Typen umbenennen, ändert TestStand die Instanzen im Speicher so, dass sie auf den geladenen Typ verweisen, und die Instanzen in der neuen Datei so, dass sie auf den Typ in der Datei verweisen.

Einstellungstypspezifische Einstellungen für die Konfliktlösung

In einer streng kontrollierten Umgebung könnten Sie versucht sein, die Option „Always prompt the user to resolve the conflict“ (Immer den Benutzer zur Lösung des Konflikts auffordern) zu wählen, um die automatische Typkonfliktlösung in allen Fällen zu deaktivieren. In diesem Fall wird der Benutzer bei jedem Typkonflikt zur Konfliktlösung aufgefordert, sodass Sie die volle Kontrolle darüber haben, welche Typen geladen werden.  Dadurch stehen beim Entwicklungsprozess jedoch zusätzliche Entscheidungen an, was dazu führen kann, dass Entwickler die vielen Dialogfelder, mit denen sie konfrontiert werden, nicht richtig lesen und falsche Entscheidungen treffen.  

Eine bessere Herangehensweise ist die typspezifische Einstellung für Typen, die eine strenge Kontrolle erfordern.  Auf der Registerkarte „Version“ der Typeinstellungen können Sie angeben, ob der Typkonflikt automatisch gelöst werden kann.  Diese Einstellung verhindert unnötige Benutzerinteraktionen bei Typkonflikten mit geringem Risiko, z. B. beim Laden einer älteren Sequenzdatei mit älteren NI-Typen in einer neuen Version von TestStand, und ermöglicht gleichzeitig die vollständige Kontrolle über streng kontrollierte benutzerdefinierte Typen.

Deaktivieren Sie die automatische Typkonfliktlösung für bestimmte Typen, die eine strengere Kontrolle erfordern

Vermeiden der unerwünschten Weitergabe von Typversionen an frühere TestStand-Versionen

Da Sie Sequenzdateien in früheren Versionen von TestStand speichern können, einige Typen jedoch in früheren Versionen von TestStand möglicherweise nicht ordnungsgemäß ausgeführt werden, können Sie die früheste Version von TestStand angeben, in der ein Typ ausgeführt werden kann. Aktivieren Sie die Option Set Earliest TestStand Version that can Use this Type (Früheste TestStand-Version, die diesen Typ nutzen kann) auf der Registerkarte Version des Dialogfelds Type Properties (Typeigenschaften) und legen Sie als früheste Version die aktuelle Version von TestStand fest. Dadurch wird verhindert, dass die aktuelle Version eines Typs in einer früheren TestStand-Version verwendet oder versehentlich an diese weitergegeben wird.

Wenn ein Typ in früheren TestStand-Versionen verfügbar sein muss, erstellen Sie verschiedene Versionen des Typs, die dann in verschiedenen TestStand-Versionen ausgeführt werden. Wenn Sie eine Sequenz für eine frühere Version von TestStand speichern, sucht TestStand in einer Reihe von Kompatibilitätsverzeichnissen die Typversion, die mit der früheren Version, für die Sie die Sequenzdatei speichern möchten, kompatibel ist. TestStand speichert die Typen aus den Typpalettendateien in den Verzeichnissen <TestStand Public>\Components\Compatibility\<Versionsnummer> und <TestStand Public>\Components\Compatibility\<Versionsnummer> in der Sequenzdatei. Sie können Typpalettendateien aus früheren Versionen von TestStand im Verzeichnis <TestStand Public> \Components\Compatibility\<Versionsnummer> ablegen, damit TestStand die richtige Version der Typen mit der Sequenzdatei speichert.

Entwickler sollten beim Anpassen integrierter Datentypen, einschließlich Standarddatentypen und Prozessmodelldatentypen, vorsichtig sein.  Viele integrierte Typen, wie z. B. „CommonResults“, werden häufig von anderen TestStand-Schritttypen oder Datentypen verwendet, wodurch das Potenzial für eine unerwünschte Typausbreitung erhöht wird.

Überlegungen zur Anpassung von Standarddatentypen

Passen Sie integrierte Typen nicht an, wenn Sie Sequenzdateien oder Palettendateien erstellen, die als Produkte von Drittanbietern verteilt oder in mehreren Organisationen eingesetzt werden. Dateien mit geänderten integrierten Typen sollten in einer einzigen Organisation verbleiben, in der die Typänderungen bekannt sind.  Wenn Ihre Sequenzdateien oder Typpaletten verteilt werden, übernehmen andere Organisationen entweder Ihre Typanpassungen oder es treten Konflikte auf, wenn die Version dieser Typen aus der anderen Organisation in Ihre Dateien geladen wird.  

Da sich eine Änderung an integrierten Typen auf jede Teststation auswirkt, an der sie verwendet werden, übertragen Sie einem zentralen Entwickler oder Architekten mit Kenntnis der Testarchitektur des Unternehmens die Aufgabe zur Absegnung der Änderungen, damit weniger Probleme mit der Typverwaltung auftreten.

Überlegungen zur Anpassung von Prozessmodelldatentypen

Die TestStand-Prozessmodelle und Plugin-Sequenzen greifen für die Definition von Prozessmodelldatenstrukturen auf verschiedene Datentypen zurück.  Beispielsweise enthält der Datentyp für den Prüfling Daten wie die Seriennummer, die Teilenummer und den Test-Socket-Index.  Sie können diese Typen zwar anpassen, sollten dies jedoch nur tun, wenn es wirklich notwendig ist.  Prozessmodelltypen werden nur in Sequenzdateien definiert und verfügen nicht über eine zentrale Typpalette.  Aus diesem Grund kann eine unerwünschte Typweitergabe bei diesen Typen leichter auftreten, da TestStand diese Typen mit den Standardeinstellungen für die automatische Konfliktlösung automatisch aktualisieren kann.
Wenn Sie dem Datentyp „UUT“ (Prüfling) oder „NI_StationInfo“ zusätzliche Daten hinzufügen müssen, können Sie den Instanzen des Typs mit der Eigenschaft „AdditionalData“, einem im Typ definierten unstrukturierten Container, zur Laufzeit zusätzliche Daten hinzufügen.  Weitere Informationen zu dieser Herangehensweise finden Sie im Hilfethema Storing Additional Information for UUTs and Test Stations in Process Models (Speichern zusätzlicher Informationen für Prüflinge und Teststationen in Prozessmodellen).

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