Entwicklung und Anpassung von TestStand-Prozessmodellen

Das Erstellen eines Tests mit vollem Funktionsumfang für ein Produkt erfordert mehr als nur das Ausführen einer Reihe von Testfällen. In der Regel muss das Testsystem vor, während und nach der Ausführung der eigentlichen Testsequenz eine Reihe weiterer Schritte ausführen. Zu den allgemeinen Operationen, die den Testprozess definieren, gehören das Identifizieren des Prüflings, das Benachrichtigen des Bedieners über den Bestanden-/Fehlerhaft-Status, das Protokollieren der Ergebnisse und das Generieren eines Testberichts. Der Gesamtsatz dieser Operationen und ihre Ausführungsreihenfolge wird als „Prozessmodell“ bezeichnet. In TestStand ist die Ebene des Prozessmodells in Sequenzdateien implementiert und unterscheidet sich von der TestStand-Engine. Diese Modularität ermöglicht Ihnen, die Prozessmodelle anzupassen, ohne dass dies Auswirkungen auf den Test Executive selbst hat.

Prozessmodelle bieten eine zusätzliche Ebene, die sowohl vom Test Executive als auch vom Testcode getrennt ist, um so gemeinsame Testfunktionen zu implementieren

TestStand unterscheidet sich eben durch diese Prozessmodelle von den meisten proprietären Test Executives. In der Regel verfügen diese Anwendungen nicht über das Konzept eines Prozessmodells. Hier bietet entweder die Testsequenz oder der Test Executive selbst den Mechanismus für allgemeine Testaufgaben.  Keiner dieser Ansätze ist ideal:

• Wenn der Testcode für diese allgemeinen Vorgänge verantwortlich ist, muss jeder neu erstellte Testsatz diesen Code wiederholen.
• Wenn allgemeine Operationen direkt im Test Executive implementiert werden, muss bei Änderungen an den allgemeinen Testoperationen der gesamte Text Executive aktualisiert werden.

Die Verwendung eines Prozessmodells zur Ausführung allgemeiner Tasks ermöglicht eine erhöhte Modularität und Wiederverwendbarkeit, da Sie Änderungen an allgemeinen Operationen nur an einer Stelle vornehmen müssen und diese dennoch vom zugrunde liegenden Test Executive trennen können.

Die TestStand-Prozessmodelle werden durch die Plug-in-Architektur darüber hinaus noch weiter modularisiert.  Die Prozessmodelle rufen Plug-in-Sequenzdateien zur Implementierung der Ergebnisverarbeitung auf, z. B. die Protokollerstellung und Datenbankprotokollierung.  Sie können diese Plugins ändern oder eigene Plugins erstellen, um die Funktionalität des Prozessmodells zu erweitern, ohne die Prozessmodelle selbst zu ändern.

Das Prozessmodell ruft Plugins für die Durchführung der Ergebnisverarbeitung auf, einschließlich Protokollerstellung und Datenbankprotokollierung.  Sie können auch benutzerdefinierte Plugins erstellen, um benutzerdefinierte Protokollierungsmechanismen zu implementieren.

Mit den TestStand-Prozessmodellen können Sie eine äußerst leistungsfähige und flexible Testanwendung erstellen. Die modulare Implementierung des Prozessmodells minimiert die Anzahl der Codeänderungen, die Sie beim Aktualisieren der Framework-Funktionalität vornehmen müssen. Die Verwendung der TestStand-Prozessmodellarchitektur zur Entwicklung eines vollständigen Testsystems kann Zeit sowie Entwicklungs- und Wartungskosten sparen.

In TestStand werden Prozessmodelle als Sequenzdateien mit aktivierter Prozessmodelloption implementiert, sodass sie zusätzliche Typen modellspezifischer Sequenzen enthalten können.  Der Sequenzdateityp wird auf der Registerkarte „Advanced“ (Erweitert) im Dialog „Sequence File Properties“ (Sequenzdatei-Eigenschaften) konfiguriert. Diese Sequenztypen haben jeweils ein spezifisches Verhalten:

• Mit Ausführungseintrittspunkten können Benutzer Tests mit einer gewünschten Prozessmodellsequenz ausführen.
• Konfigurationseinstiegspunkte bieten eine Benutzeroberfläche, über die Benutzer Prozessmodelleinstellungen konfigurieren und diese Einstellungen speichern können.
• Mit Modell-Callbacks kann die Testsequenzdatei das Verhalten des Prozessmodells überschreiben.
  

Verwenden Sie im Dialog „Sequence Properties“ (Sequenzeigenschaften) die Registerkarte „Model“ (Modell), um die Sequenztypen zu konfigurieren, die eine Prozessmodelldatei enthalten kann.

Ausführungseintrittspunkt-Sequenzen

Ausführungseintrittspunkte bieten Benutzern die Möglichkeit, ihren Testcode über das Prozessmodell auszuführen. Das standardmäßige TestStand-Prozessmodell hat zwei Ausführungseintrittspunkte: „Test UUTs“ und „Single Pass“. Jeder dieser Eintrittspunkte ist in einer Sequenz in der Prozessmodell-Sequenzdatei implementiert. Im Sequenzeditor listet das Menü „Execute“ (Ausführen) Ausführungseintrittspunkte auf, wenn das aktive Fenster eine Sequenzdatei enthält, die das Prozessmodell verwendet.

Das sequentielle Prozessmodell verwendet die Einstiegspunkte „Single Pass“ und „Test UUTs Execution“. Beide Ausführungseintrittspunkte rufen die MainSequence-Sequenz der Client-Sequenzdatei auf, um Tests für jeweils einen Prüfling auszuführen. Die Eintrittspunkte verwenden darüber hinaus auch andere Aktionen gemeinsam, z. B. das Generieren von Testprotokollen und das Speichern von Datenergebnissen in einer Datenbank.

Eintrittspunktfluss von „Single Pass“ und „Test UUT Execution“ im sequentiellen Prozessmodell

Der Ausdruck für den Eintrittspunktnamen ist der Name, der im Sequenzeditor oder in einer Benutzeroberfläche bei Verwendung des Eintrittspunkts angezeigt wird. Verwenden Sie im Dialog „Sequence Properties“ (Sequenzeigenschaften) auf der Registerkarte „Model“ (Modell) das Textfeld „Entry Point Name Expression“ (Ausdruck für den Einstiegspunktnamen), um diesen Wert zu bearbeiten. Das Textfeld „Entry Point Name Expression“ (Ausdruck für den Einstiegspunktnamen) ist nur sichtbar, wenn die von Ihnen ausgewählte Sequenz ein Eintrittspunkt für die Ausführung ist. Ein Standardwert wie ResStr („MODEL“, „TEST_UUTS“) verwendet die ResStr-Funktion, die die TestStand-Lokalisierung bietet. Ersetzen Sie den Wert durch einen anderen lokalisierten Wert, oder verwenden Sie einen konstanten Zeichenfolgenausdruck, der den Eintrittspunkt aus Sicht eines Benutzers beschreibt.  

Die Verwendung von Lokalisierungszeichenfolgen anstelle einer Konstante bietet den Vorteil, dass Sie Änderungen am Zeichenfolgenwert vornehmen können, ohne das Prozessmodell selbst ändern zu müssen. Weitere Informationen zur Verwendung von TestStand-Ressourcenzeichenfolgen für die Lokalisierung finden Sie im Lernprogramm Localizing TestStand to Different Languages (Lokalisieren von TestStand in verschiedene Sprachen).

Konfigurationseintrittspunkte

Konfigurationseintrittspunkte bieten Benutzern die Möglichkeit, die Einstellungen für das Prozessmodell zu konfigurieren.  Die Standardmodelle enthalten die Modelloptionen- und Ergebnisverarbeitungs-Eintrittspunkte.  Ähnlich wie bei Ausführungseintrittspunkten werden Konfigurationseintrittspunkte in einer Sequenz in der Prozessmodelldatei implementiert und im Menü „Configure“ (Konfigurieren) im Sequenzeditor aufgelistet.  Um Einstellungen zu speichern, schreiben die Modelleintrittspunkte Daten in Konfigurationsdateien im TestStand-Konfigurationsverzeichnis.

Modell-Callbacks

Mit Modell-Callbacks können Testentwickler bestimmte Aspekte des Prozessmodells für ihren jeweiligen Test anpassen, ohne Änderungen am Prozessmodell selbst vornehmen zu müssen.  Das Prozessmodell definiert Callback-Sequenzen, die die Eintrittspunkte an verschiedenen Ausführungspunkten aufrufen.  Beispielsweise ruft der Eintrittspunkt „Test UUTs“ vor Beginn des Tests die Callback-Sequenz „PreUUT“ auf, um den Benutzer zur Eingabe einer Seriennummer aufzufordern.  Wenn ein Testentwickler eine bestimmte Änderung dieser Funktionalität benötigt, kann er den Callback in seiner Testsequenzdatei überschreiben.  In diesem Fall wird, wenn das Modell die PreUUT-Sequenz aufruft, die Sequenz in der Testsequenzdatei anstelle der PreUUT-Sequenz in der Prozessmodelldatei aufgerufen.

Eine ausführliche Beschreibung der Callbacks von Prozessmodellen finden Sie im Dokument Using Callbacks in NI TestStand (Verwenden von Callbacks in NI TestStand).

Die Testsequenzdatei kann Callback-Sequenzen im Prozessmodell überschreiben, um benutzerdefiniertes Verhalten zu definieren.

Prozessmodell-Plugins

Die standardmäßigen Prozessmodelle nutzen zur Implementierung der Ergebnisverarbeitung eine Plugin-Architektur, einschließlich Protokollerstellung und Datenprotokollierung.  Jedes Plugin wird in einer separaten Sequenzdatei implementiert, die Plugin-Eintrittspunktsequenzen enthält, die an verschiedenen Stellen in den Eintrittspunkten des Hauptprozessmodells aufgerufen werden.  Die Prozessmodelle verfügen über einen Dialog für die Plugin-Konfiguration, in dem Testentwickler die aktiven Plugins und Plugin-Einstellungen konfigurieren können.  

Weitere Informationen zur Plugin-Architektur des TestStand-Prozessmodells finden Sie im Hilfethema Process Model Plug-in Architecture (Prozessmodell – Plugin-Architektur).  

Weitere Engine-Callbacks

Prozessmodell-Sequenzdateien bieten zusätzliche Engine-Callbacks, die in Standardsequenzdateien nicht verfügbar sind.  Diese Callbacks, die das Präfix „ProcessModel“ aufweisen, werden nur für Schritte in der aktuellen Client-Sequenzdatei des Prozessmodells ausgeführt, in dem Sie sie definieren.  Beispielsweise wird der Callback „ProcessModelPostStep“ nach jedem in der Testsequenz ausgeführten Schritt ausgeführt, jedoch nicht nach Schritten im Prozessmodell selbst.

Diese Callbacks werden häufig bei der benutzerdefinierten Fehlerbehandlung angewendet.  In der Regel möchten Testentwickler so viele Informationen wie möglich aus Fehlern ableiten und das Systemverhalten steuern, wenn Fehler auftreten. In anderen Anwendungsfällen erfordern vollautomatische Umgebungen mit Unteraufträgen normalerweise Start-/Stopp-Eingaben und Rot-/Grün-Ausgaben mit entsprechender Debugging-Protokollierung, um die vorherigen Systemaktivitäten zu verfolgen und Fehler zu testen.

Sie können die auf Prozessmodellebene definierten Engine-Callbacks „ProcessModelPostStepFailure“ und „ProcessModelPostStepRuntimeError“ verwenden, um Fehler aller Client-Sequenzdateien allgemein zu behandeln, sodass für den Programmierer der Testsequenz kein zusätzlicher Aufwand anfällt. Diese Callbacks werden ausgeführt, wenn in der Client-Sequenzdatei ein Fehler auftritt.

In vielen Fällen müssen Sie die Funktionalität der mit TestStand gelieferten Prozessmodelle möglicherweise erweitern oder ändern.  Zu den allgemeinen Änderungen an den Prozessmodellen gehören Änderungen an Reports, Testwiederholungsstrategien, Fehlerbehandlung und -protokollierung, Stationskalibrierungsroutinen und Mechanismen zur Prüflingsauswahl.

Hinzufügen neuer Funktionen mithilfe von Prozessmodell-Plugins

Die standardmäßigen Prozessmodelle nutzen Plugins zur Implementierung der Ergebnisverarbeitungsfunktion, einschließlich Protokollerstellung und Datenprotokollierung.  Plugins sind jedoch nicht auf die Ergebnisverarbeitung beschränkt.  Wenn Sie dem Prozessmodell Funktionen hinzufügen müssen, können Sie ein Plugin erstellen, das diese Funktionen implementiert, ohne die Prozessmodelle an sich zu ändern.  Dieser Ansatz hat viele Vorteile:

• Sie können Ihre Plugins problemlos in die Sequenz-, Batch- und parallelen Modelle integrieren und müssen keine Änderungen an den einzelnen Modellen vornehmen.
• Sie müssen kein benutzerdefiniertes Prozessmodell pflegen und bereitstellen.
• Sie können bei zukünftigen Änderungen an den Prozessmodellen Anpassungen integrieren.
• Plugins können gemeinsam genutzt werden, ohne dass Änderungen des Prozessmodellcodes vorgenommen werden müssen.

Standardmäßig müssen Benutzer Instanzen von Plugins erstellen, damit das Modell sie ausführen kann.  Dieser Ansatz einer aktiven Auswahl ist nützlich, wenn die neu hinzugefügten Funktionen nur in bestimmten Fällen erforderlich sind.  Wenn die Funktionen immer ausgeführt werden sollen, wie der Code im Prozessmodell selbst, können Sie ein Prozessmodell-Plugin als Zusatzpaket verwenden.   Modell-Plugin-Zusatzpakete werden wie standardmäßige Plugins implementiert, jedoch im Zusatzpakete-Unterordner im Plugins-Verzeichnis gespeichert.  Sie werden nicht im Plugin-Konfigurationsdialog angezeigt, und sie werden immer ausgeführt.

Erstellen neuer Plugins

Sie können benutzerdefinierte Plugins erstellen, um das Modell zusätzlich zur benutzerdefinierten Ergebnisverarbeitung auf verschiedene Weise zu erweitern.  Ein Beispiel für eine Funktion, die Sie einem Prozessmodelle anhand eines benutzerdefinierten Plugins hinzufügen können, ist die Teststationskalibrierung.  Sie möchten möglicherweise die Gültigkeit der Stationskalibrierung überprüfen, bevor Sie Testsequenzdateien auf einer Teststation ausführen. Diese Routinen überprüfen in der Regel, ob die Testausrüstung basierend auf einem Ablaufdatum kalibriert ist. Der Ablauf der Kalibrierung löst einen Fehlerzustand aus, warnt den Bediener und verhindert, dass der Test ausgeführt wird.

Durch die Implementierung der Funktion in einem benutzerdefinierten Modell-Plugin können Benutzer die Kalibrierung bei Bedarf deaktivieren und über den Dialog zur Ergebnisverarbeitung eine Konfigurationsschnittstelle für Testentwickler bereitstellen.  Informationen zur Implementierung finden Sie im Thema Erstellen von Prozessmodell-Plugins.

Um das direkt im Prozessmodell implementierte erhalten zu ändern, wie z. B. die Verfolgung der Seriennummer des Prüflings, müssen Sie Änderungen direkt am Modell vornehmen. Verwenden Sie eine Kopie des Prozessmodells als Ausgangspunkt für die Entwicklung neuer Prozessmodelle oder das Anpassen vorhandener Prozessmodelle, damit Sie die bereits im Standardprozessmodell implementierte fein abgestimmte Logik zum Großteil wiederverwenden können.    

Erstellen Sie vor dem Ändern der Prozessmodelle eine Kopie des gesamten Modellverzeichnisses unter <TestStand>/Components/Models am entsprechenden Speicherort im öffentlichen TestStand-Verzeichnis <TestStand Public>/Components/Models.  Nehmen Sie die Änderungen nur an den Dateien im öffentlichen Speicherort von TestStand vor.

Ändern von Modelleintrittspunkten

In vielen Fällen möchten Sie den Ausführungsfluss des Ausführungseintrittspunkts möglicherweise anpassen.  Sie möchten unter Umständen, dass das Testsystem einen Test für einen Prüfling automatisch wiederholt, wenn bestimmte Fehler auftreten, oder Sie möchten die Anzahl der Wiederholungsversuche pro Bediener begrenzen, bevor ein Supervisor eingreifen muss, um zu ermitteln, ob weitere Tests notwendig sind. Bei diese Art von Änderungen müssen Sie die Eintrittspunktsequenz direkt ändern, um Schleifen und andere Bedingungen hinzuzufügen.  Wenn Sie Änderungen an Eintrittspunkten vornehmen, stellen Sie sicher, dass Sie die vorgenommenen Änderungen dokumentieren, damit das Standardverhalten leichter von den Anpassungen unterschieden werden kann.

Ermöglichen, dass Testentwickler das Modellverhalten anpassen

Beim Anpassen der Prozessmodelle ist es wichtig zu berücksichtigen, ob für einen bestimmten Test das von Ihnen definierte Verhalten geändert oder deaktiviert werden sollte.  Verwenden Sie in den Fällen, in denen der Testentwickler Änderungen vornehmen muss, eine vorhandene oder neue Callback-Sequenz, um die Änderungen zu implementieren.  Der Testentwickler kann den Callback dann überschreiben, wenn er das von Ihnen definierte Verhalten ändern muss.  

Neue Funktionen sollten immer in einer separaten Sequenz implementiert werden, die Sie von den Eintrittspunkten aus aufrufen, die sie implementieren. Sie haben zum Implementieren einer Sequenz im Prozessmodell die folgenden Möglichkeiten, basierend auf der Anpassungsstufe, die Sie Testentwicklern bereitstellen möchten:

• Sie möchten Testentwicklern die Möglichkeit geben, das Modell an einem bestimmten Punkt der der Ausführung zu erweitern: Implementieren Sie einen Platzhalter ohne Standardfunktionalität, damit die Client-Sequenzdatei bei Bedarf Funktionen einfügen kann. Sie können optional Parameter an den Callback übergeben, wenn Sie ihn vom Eintrittspunkt aus aufrufen, um dem Testentwickler relevante Daten bereitzustellen.  „ModifyReportHeader“ stellt zum Beispiel keine Standardimplementierung bereit, dafür werden jedoch Parameter, die Report-bezogene Daten enthalten, an den Callback übergeben, damit Testentwickler auf den Report zugreifen und ihn ändern können.
• Sie möchten Funktionen definieren, die von Testentwicklern angepasst oder deaktiviert werden können:  Implementieren Sie das Standardverhalten, damit der Client-Callback den Modell-Callback aufrufen kann, um die Standardimplementierung des Prozessmodells auszuführen, und damit der Client-Callback zusätzliche Funktionen implementieren kann. Standardmäßig implementiert „PostUUT“ Banner, die das Ergebnis der Testsequenz anzeigen. Eine Client-Sequenzdatei kann ein benutzerdefiniertes PostUUT-Verhalten implementieren und das Banner beibehalten, indem der Callback überschrieben und die Implementierung des Prozessmodells weiterhin aufgerufen wird.  In den Sequenzeigenschaften können Sie mit der Option „Copy Step and Locals when Creating an Overriding Sequence“ (Schritt und lokale Variablen beim Erstellen einer Überschreibungssequenz kopieren) festlegen, dass der Inhalt der Sequenz kopiert werden soll, wenn ein Testentwickler den Callback überschreibt.
• Sie möchten generell verhindern, dass Testentwickler die Funktionalität anpassen: Wenn Sie Funktionen definieren, die von Testentwicklern niemals geändert werden sollten, verwenden Sie eine normale Sequenz anstelle eines Callbacks, da diese in Client-Sequenzdateien nicht überschrieben werden kann.

Anpassen des Verhaltens vorhandener Modell-Plugins

Für Framework-Entwickler ist es üblich, das Verhalten der Protokollerstellung anzupassen, um bestimmte Anforderungen an ihr Testsystem zu erfüllen.  Die Anpassung von Protokollen wird im Dokument Best Practices for NI TestStand Report Generation and Customization (Empfohlene Methoden für die Protokollerstellung und -anpassung in NI TestStand) in der Advanced Architecture Series ausführlich behandelt.  Dieses Dokument enthält weitere Informationen zum Implementieren von Anpassungen zur Protokollerstellung in der TestStand-Modellarchitektur.  

Die Standardprozessmodelle definieren Datentypen, die zum Speichern von Informationen über die aktuellen Optionen für Prüfling, Station und Modell dienen.  In einigen Fällen müssen Sie eventuell zusätzliche Daten in diesen Eigenschaften speichern, in der Regel die Prüflingsdaten.  So verfolgt der standardmäßige TestStand-Prüflingsauswahlmechanismus beispielsweise nur eine Seriennummer, wobei Sie möglicherweise auch die Modellnummer beibehalten müssen.  

NI empfiehlt, dass Sie nach Möglichkeit keine Änderungen an den Modelldatentypen vornehmen, da auf diese in vielen TestStand-Dateien verwiesen wird und Aktualisierungen möglicherweise schwierig zu pflegen sind.  Die Prozessmodelle bieten jedoch eine unstrukturierte Eigenschaft in den Datentypen „UUT“ und „NI_StationInfo“, mit der Sie problemlos zusätzliche UUT-Verfolgungsinformationen hinzufügen können, ohne den UUT-Datentyp ändern zu müssen. Sie können eine neue ModelNumber-Eigenschaft im UUT.AdditionalData-Container erstellen, um diese Informationen zu speichern.  Das in TestStand enthaltene Beispiel Adding Custom Data to a Report (Hinzufügen benutzerdefinierter Daten zu einem Bericht) zeigt, wie Sie der Eigenschaft anhand dieser Eigenschaft Felder hinzufügen und sie in das Testprotokoll aufnehmen können.  In diesem Beispiel werden die Aktualisierungen in der Client-Sequenzdatei mithilfe eines Callbacks implementiert. Sie können den gleichen Ansatz jedoch auch direkt im Prozessmodell verwenden.

Sie können einen Callback in der Prozessmodell-Sequenzdatei auch überschreiben, indem Sie in „StationCallbacks.seq“ im Verzeichnis <TestStand Public>\Components\Callbacks\Station eine Sequenz mit dem gleichen Namen, jedoch anderen Funktionen erstellen. TestStand ruft Modell-Callbacks in „StationCallbacks.seq“ auf, anstatt den in einem Modell definierten Callback gleichen Namens aufzurufen. Ein Callback in einer Client-Datei überschreibt den gleichnamigen Callback im Modell und in der Datei „StationCallbacks.seq“.

Wenn Sie auf eine neuere Version von TestStand aktualisieren, müssen Sie alle Änderungen, die Sie an den Standardprozessmodellen vorgenommen haben, mit den von NI in der neuen Version vorgenommenen Änderungen zusammenführen.  Überprüfen Sie dazu mit dem Differenztool von TestStand zunächst die Unterschiede zwischen dem früheren und dem neuen Standardprozessmodell. Das Tool befindet sich im Sequenzeditor unter „Edit » Diff Sequence File Against“ (Bearbeiten » Sequenzdatei vergleichen). Wenn alle Änderungen zentral in neuen Sequenzen in den Prozessmodelldateien oder separat in Plugins implementiert wurden, ist es relativ einfach, Prozessmodellanpassungen in die neue Version des Prozessmodells zu importieren.

Wenn Sie Modelle migrieren, die Sie in TestStand-Versionen vor 2012 erstellt haben, weisen die neuen Modelle wesentliche Änderungen auf, da sie die Plugin-Architektur implementieren.  Weitere Informationen zum Migrieren Ihrer Prozessmodelle in diesem Fall finden Sie unter Migrating Process Model Customizations to TestStand 2012 or Later (Migrieren von Prozessmodellanpassungen auf TestStand 2012 oder höher).

Klicken Sie hier, um weitere Dokumente zur TestStand Advanced Architecture Series (TestStand-Serie der erweiterten Architekturen ) mit interessanten Themen für NI-TestStand-Entwickler anzuzeigen.