Ein häufige Anforderung in automatisierten Testsystemen besteht darin, ein vollständiges Protokoll zu erzeugen, das alle Ergebnisinformationen zur Beantwortung der Fragen „Was wird von der Sequenz getestet?“ und „Welche Ergebnisse wurden von jedem Prüfling erreicht?“ umfasst.
Dieses Dokument enthält Informationen zu TestStand-Protokollen, einschließlich Konfiguration verschiedener Protokollformate, Aufnahme zusätzlicher Daten in das Protokoll und Anpassung der Protokolle.
Bevor Sie sich mit den Optionen für die Anpassung von TestStand-Protokollen vertraut machen, müssen Sie zunächst wissen, wie der TestStand-Protokollerstellungsprozess funktioniert.
TestStand wendet einen zweistufigen Ansatz zum Erstellen von Testprotokollen an:
Ein Diagramm dieses Prozesses ist in der folgenden Abbildung dargestellt:
TestStand erfasst Testergebnisse in der ResultList-Variablen. Diese wird vom Protokollgenerator zum Erstellen eines lesbaren Testprotokolls herangezogen.
Während TestStand Sequenzen ausführt, werden Schrittergebnisse und zusätzliche Informationen erfasst, die in das Protokoll aufgenommen werden. Die Ergebniserfassung wird direkt von der TestStand-Engine implementiert und erfolgt unabhängig von der Ergebnisverarbeitung, wie z. B. Protokollerstellung oder Datenbankprotokollierung.
Sequenzen arbeiten mit Locals.ResultList. Diese Eigenschaft wird automatisch zur Speicherung der Ergebnisdaten in allen neuen Sequenzen erstellt. TestStand füllt die ResultList-Eigenschaft während der Sequenzausführung aus und speichert sie im Arbeitsspeicher (RAM).
Die lokale ResultList-Variable ist anfänglich ein leeres Array von Containern. Nach der Ausführung jedes Schritts hängt TestStand ein neues Containerelement an das Ende des Arrays an, um die Ergebnisse des ausgeführten Schritts zu speichern. Dabei werden die Daten mit zwei Quellen gefüllt:
Einige Daten in der ResultList werden aus den Schritteigenschaften abgerufen. Standardmäßig werden nur Eigenschaften im Ergebniscontainer der Schritteigenschaften in die Ergebniserfassung aufgenommen. Zwei wichtige Elemente im Schrittergebniscontainer sind beispielsweise:
Die Schritteigenschaften können je nach Schritttyp variieren. Viele Schritteigenschaften sind nur für bestimmte Schritttypen vorhanden. Beispielsweise gilt die Eigenschaft Step.Result.Numeric speziell für den Schritttyp „Numeric Limit Test“.
TestStand kopiert nicht nur die Schritteigenschaften in die ResultList, sondern fügt auch jedem Schritt noch einen Satz von Standardergebniseigenschaften hinzu. Die TestStand-Engine fügt diese Ergebnisse als Untereigenschaften der Step.Result.TS-Eigenschaft hinzu. Diese Eigenschaften umfassen die Ermittlung von Informationen zum Schritt, wie z. B. den Schrittnamen, den Typ und die Zeitinformationen.
Das folgende Diagramm zeigt, wie die ResultList mit Schrittergebniseigenschaften und Standardergebniseigenschaften gefüllt wird.
Ergebnisdaten werden aus benutzerdefinierten Ergebniseigenschaften generiert, die vom Schritttyp abhängen, sowie aus Standardergebniseigenschaften, die für alle Schritte gleich sind.
Mit der Execution.AddExtraResult-Methode können Sie der ResultList bestimmte Schritteigenschaften hinzufügen. Mit dieser Methode können Sie eine Eigenschaftssuchzeichenfolge angeben (z. B. „Step.myStepData“) und diese Eigenschaft in die Ergebnisliste für alle Schritte in der Ausführung aufnehmen, die über die Eigenschaft verfügen. Außerdem können Sie mit dieser Methode den Namen angeben, der für die Eigenschaft in der ResultList verwendet werden soll.
Beispielsweise ruft das Prozessmodell die Execution.AddExtraResult-Methode auf, um die Werte Step.Limits und Step.Comp in die ResultList aufzunehmen. Da sich diese Eigenschaften nicht im Step.Result-Container befinden, werden sie standardmäßig nicht erfasst. Aufgrund dieses Aufrufs werden diese Eigenschaften der ResultList für alle Schritte in der Ausführung hinzugefügt, die diese Eigenschaften enthalten.
Verwenden Sie AddExtraResult, um der Ergebnisliste zusätzliche Schritteigenschaften hinzuzufügen.
Weitere Informationen zu anderen Protokolleigenschaften finden Sie im Thema Custom Result Properties (Benutzerdefinierte Ergebniseigenschaften) in der TestStand-Hilfe.
Die TestStand-Ergebniserfassung erfolgt unabhängig davon, ob Sie ein Protokoll erstellen oder Daten in einer Datenbank protokollieren. In einigen Fällen möchten Sie möglicherweise die Ergebniserfassung für bestimmte Schritte oder Sequenzen deaktivieren, wenn die Ergebnisse nicht protokolliert werden müssen. Mit den folgenden Einstellungen können Sie steuern, welche Ergebnisse protokolliert werden:
Wenn die Leistung des Testsystems oder die Speicherauslastung des Systems ein Problem darstellt, sollten Sie die Ergebnisaufzeichnung für häufig ausgeführte Schritte deaktivieren, um eine unnötige Speicherung von Ergebnissen zu vermeiden.
Im Gegensatz zum Ergebniserfassungsprozess, der zur TestStand-Engine gehört, wird der Protokollgenerator von den TestStand-Prozessmodellen über das Plug-in zur Protokollerstellung implementiert. Ausführliche Informationen zur Implementierung des Protokollgenerators finden Sie im Artikel Report Generation Explained (Erläuterung der Protokollerstellung).
Der Protokollgenerator verwendet zur Protokollerstellung die Ergebnisdaten in der vom Ergebniserfassungsprozess generierten ResultList-Variablen (weitere Informationen finden Sie im Abschnitt „Ergebniserfassung“ dieses Dokuments). Dieser Abschnitt enthält einen Überblick über den Standardprotokollgenerator in TestStand.
Der Protokollgenerator verwendet die Eigenschafts-Flags der erfassten Ergebniseigenschaften in der ResultList, um zu bestimmen, ob diese in das Protokoll aufgenommen werden sollen. Mit Eigenschafts-Flags können Sie das Verhalten von PropertyObjects konfigurieren, einschließlich der Art und Weise, wie sie in das Testprotokoll aufgenommen werden.
Die Flags eines PropertyObject können auf zwei Arten angezeigt und konfiguriert werden:
Konfigurieren von PropertyObject-Flags im Dialogfeld „Edit Flags“ (Flags bearbeiten)
Jedes Flag hat einen eindeutigen Wert, und der aktuelle Flag-Status einer Eigenschaft ist die Summe aller Flag-Werte. Beispiel: Eine Eigenschaft mit den Flags PropFlags_IsLimit–(Wert: 0x1000) und PropFlags_IncludeInReport–(Wert: 0x2000) hat einen Flag-Wert von 0x3000. Weitere Informationen zu den einzelnen Flags finden Sie im Hilfethema zu PropertyFlags-Konstanten.
Mit den folgenden Flags bestimmt der Protokollgenerator, ob erfasste Ergebnisse zum Protokoll hinzugefügt werden sollen. Weitere Informationen finden Sie unter Property Flags That Affect Reports (Eigenschafts-Flags, die sich auf Protokolle auswirken).
TestStand bietet viele Protokollformate mit jeweils eigenen Vor- und Nachteilen. Der Protokollgenerator ruft formatspezifische Sequenzdateien auf, um den Protokolltext zu erstellen (z. B. ReportGen_ATML.seq). Weitere Informationen zu den einzelnen Protokollformaten finden Sie in der folgenden Tabelle.
Protokollformat | Lesbarkeit | Dateigröße | Leistung | Analyse1 | Anpassung |
---|---|---|---|---|---|
ASCII (.txt) Einfaches Textprotokollformat | Einfacher Text | Sehr klein | Extrem schnell | Moderat – Erfordert einen benutzerdefinierten Parser, aber begrenzte Formatierungsinformationen | Schwierig – Erfordert das Überschreiben oder Ändern von Prozessmodell-Callbacks oder DLLs/td> |
HTML (.html) Rich-Text-Protokollformat | Rich Text | Groß | Mittel | Schwierig – Protokolldaten und -formatierung sind eng miteinander verbunden und erfordern einen benutzerdefinierten Parser | Schwierig – Erfordert das Überschreiben oder Ändern von Prozessmodellsequenzen oder DLLs |
XML (.xml) Nur-Daten-Dateiformat mit XSL-Stylesheet zum Generieren von Rich Text | Rich Text | Extrem groß | Extrem langsam | Einfach – Verwendet ein Standard-XML-Schema, das mithilfe einer API für XML einfach analysiert werden kann | Moderat – Verwenden Sie Stylesheets, um die Formatierung ohne Änderungen des Prozessmodells anzupassen |
ATML (.xml) – Automated Test Markup Language | Rich Text | Mittel | Schnell | Einfach – Verwendet ein Standard-XML-Schema, das mithilfe einer API für XML einfach analysiert werden kann | Moderat – Verwenden Sie Stylesheets, um die Formatierung ohne Änderungen des Prozessmodells anzupassen |
1 Sie können Protokolldateien für die automatisierte Protokollanalyse verwenden, insbesondere XML- und ATML-Protokolldateien. Die Verwendung von Datenbanken für die automatisierte Analyse ist jedoch in der Regel effizienter. Im Hilfethema zur Datenprotokollierung finden Sie weitere Informationen zu TestStand-Komponenten für die Protokollierung in einer Datenbank.
Ab TestStand 2019 erhalten Sie auch die Möglichkeit, für jedes Berichtsformat mit Ausnahme von ASCII (.txt) einen PDF-Report zu erstellen.
Ausführlichere Informationen zur Auswahl der besten Strategie zur Protokollerstellung für Ihre Anwendung finden Sie unter Choosing the Appropriate NI TestStand Report Generation Strategy (Auswahl der geeigneten Strategie für die NI TestStand-Protokollerstellung).
Wenn Sie die Option für die On-The-Fly-Protokollerstellung auf der Registerkarte „Contents“ (Inhalt) des Dialogfelds „Report Options“ (Protokolloptionen) aktivieren, erstellen die Prozessmodelle das Protokoll schrittweise während der Ausführung, anstatt auf den Abschluss des Prüflingstests zu warten. Wenn Sie die On-the-Fly-Protokollerstellung verwenden, können Sie im Ausführungsfenster auf den Protokollbereich klicken, um das Protokoll während der Ausführung anzuzeigen. Da das Protokoll während der Testausführung aktualisiert wird, wird die Protokollansicht bei der Ausführung der Testsequenz regelmäßig mit neuen Ergebnissen aktualisiert.
Die On-the-Fly-Protokollerstellung ist in der Regel eine bessere Wahl für längere Tests, bei denen der Testdurchsatz nicht so wichtig ist wie die Speicherauslastung und das Vermeiden von Datenverlust.
Vorteile | Nachteile |
---|---|
|
|
1Um Speicherzuwachs zu verhindern, ist eine zusätzliche Konfiguration erforderlich. Weitere Informationen zum Verhindern von Speicherzuwachs bei der Protokollerstellung finden Sie unter Addressing Memory Issues with Report Generation in TestStand (Arbeitsspeicherprobleme bei der Protokollerstellung in TestStand beheben).
2Dieses Problem ist in TestStand 2012 und höher gemindert, da dort Einstellungen zum Konfigurieren der Häufigkeit verfügbar sind, mit der der On-the-Fly-Protokollgenerator das Protokoll neu erstellt. Weitere Informationen zu diesen Einstellungen finden Sie im Hilfethema zum Dialogfeld Advanced Result Processing Settings (Erweiterte Einstellungen für die Ergebnisverarbeitung). Standardmäßig erstellt und speichert TestStand 2012 und höher das On-the-Fly-Protokoll nach dem Erfassen von 500 Schrittergebnissen, spätestens jedoch nach 1,5 Sekunden Ausführungszeit. In TestStand 2010 SP1 und früheren Versionen wird das Protokoll nach jedem Schritt neu generiert.
In TestStand 2012 und höher kann der Protokollgenerator (und andere Plug-ins zur Ergebnisverarbeitung) asynchron ausgeführt werden, um den Testdurchsatz zu verbessern. Um diese Option zu konfigurieren, wählen Sie Configure » Result Processing (Konfigurieren > Ergebnisverarbeitung) aus, und aktivieren Sie das Kontrollkästchen Show More Options (Weitere Optionen anzeigen). In der Spalte New Thread (Neuer Thread) wird die aktuelle Einstellung für jedes Plug-in angezeigt.
Wenn Sie diese Funktion verwenden, kann die Ausführung sofort mit dem Testen des nächsten Prüflings beginnen, während das Protokoll für den aktuellen Prüfling erstellt wird (siehe Abbildung unten).
Hinweis: Asynchrone Protokollerstellung ist nicht verfügbar, wenn Sie die On-the-Fly-Protokollerstellung verwenden.
Die asynchrone Ergebnisverarbeitung ermöglicht einen schnelleren Testdurchsatz, da der Test der nächsten Einheit sofort beginnen kann.
Der TestStand-Protokollerstellungsprozess ist in hohem Maße anpassbar, sodass Sie das generierte Protokoll an die Anforderungen Ihrer TestStand-Anwendung anpassen können. Gehen Sie beim Anpassen des Protokolls wie folgt vor:
TestStand-Protokolle können ohne Codeänderungen mithilfe der Protokollerstellungsoptionen angepasst werden, die im Dialogfeld „Report Options“ (Protokolloptionen) verfügbar sind. Um in TestStand 2012 und höher auf das Dialogfeld zuzugreifen, navigieren Sie zu Configure » Result Processing (Konfigurieren > Ergebnisverarbeitung), um das Dialogfeld „Report Options“ (Protokolloptionen) zu öffnen. Wählen Sie dann das Einstellungssymbol für das Plug-in zur Protokollerstellung aus. Wählen Sie in TestStand 2010 SP1 und früheren Versionen Configure » Report Options (Konfigurieren > Protokolloptionen) aus.
Im Dialogfeld „Report Options“ (Protokolloptionen) können Sie das Protokoll folgendermaßen konfigurieren:
In den folgenden Abschnitten werden die einzelnen Konfigurationstypen ausführlich beschrieben.
Dialogfeld „Report Options“ (Protokolloptionen) – Registerkarte „Content“ (Inhalt)
Im Dialogfeld „Report Options“ (Protokolloptionen) können Sie das Format des Protokolls auswählen. Weitere Informationen zu den verfügbaren Protokollformaten finden Sie im Abschnitt „Protokollformat“ des Abschnitts zur Protokollerstellung dieses Dokuments. Einige Protokolloptionen sind nur für bestimmte Protokollformate verfügbar.
ASCII- und HTML-Protokolle können auf zwei Arten erstellt werden:
Im Gegensatz zu HTML-Protokollen enthalten XML- und ATML-Protokolle keine Formatierungsinformationen. Um die Rohdaten des XML-Formats in einem lesbaren Protokoll darzustellen, wird ein XSL-Stylesheet verwendet. Dieses Stylesheet definiert den Stil des Protokolls und ruft Daten aus der XML-Datei ab. Mithilfe eines Stylesheets können Sie das Erscheinungsbild des Protokolls ändern, ohne die XML-Datendatei ändern zu müssen. Die folgenden Abbildungen zeigen ein Beispiel für dasselbe XML-Protokoll mit zwei verschiedenen Stylesheets, die mit TestStand bereitgestellt werden.
TestStand bietet eine Vielzahl von Stylesheets, mit denen Sie XML- und ATML-Protokolldaten auf unterschiedliche Weise anzeigen können. Diese können Sie im Dialogfeld „Report Options“ (Protokolloptionen) angeben. Sie können auch benutzerdefinierte Stylesheets für Ihre TestStand-Protokolle erstellen. Weitere Informationen und Beispiele zur Anpassung von Stilvorlagen finden Sie im Abschnitt XML-Protokolle der TestStand-Hilfe.
ATML-Protokollabschnitt mit dem horizontalen Stylesheet
ATML-Protokollabschnitt mit dem Protokoll-Stylesheet
Sie können im Dialogfeld „Report Options“ (Protokolloptionen) bestimmte Arten von Schrittergebnisinformationen filtern, z. B.:
Darüber hinaus können Sie mithilfe des Ausdrucks für die Ergebnisfilterung benutzerdefinierte Filter erstellen. TestStand wertet diesen Ausdruck für jedes Schrittergebnis aus und nimmt den Schritt in das Protokoll auf, wenn der Ausdruck „True“ ergibt. Wählen Sie mithilfe des Ringelements für die Ergebnisfilterung allgemeine Ausdrücke aus, z. B. das Ausschließen von Schritten der Ablaufsteuerung (siehe Abbildung unten).
Hinweis: Der Ausdruck für die Ergebnisfilterung ist nicht verfügbar, wenn das XML-Format oder das ATML-Format mit TestStand 2010 SP1 oder früheren Versionen verwendet wird. In diesen Fällen können Sie Ergebnisse durch Änderung des Protokoll-Stylesheets filtern.
Das Dialogfeld „Report Options“ (Protokolloptionen) enthält Einstellungen zum Anpassen der Darstellung des Protokolls, darunter:
Hinweis: TestStand-Protokolle erstellen mithilfe eines ActiveX-Steuerelements Graphen aus Array-Daten. Wenn dieses Steuerelement beim Anzeigen des Protokolls nicht verfügbar ist, können die Daten dennoch als Tabelle angezeigt werden.
Auf der Registerkarte Report File Pathname (Protokolldateipfad-/name) im Dialogfeld „Report Options“ (Protokolloptionen) können Sie den Namen der Protokolldatei und den Pfad konfigurieren, unter dem sie gespeichert ist. Verwenden Sie die Datei-/Verzeichnisoptionen, um den Speicherort für das Protokoll auszuwählen. Über das Feld „UUT Report“ (Prüflingsprotokoll) können Sie dann eine Vorschau des Protokolldateinamens basierend auf den ausgewählten Optionen anzeigen.
Sie können den Namen und den Pfad der Protokolldatei weiter steuern, indem Sie im Steuerelement für Datei-/Verzeichnisoptionen die Option Specify Report File Path by Expression (Protokolldateipfad nach Ausdruck angeben) auswählen. Mit dieser Einstellung können Sie einen Ausdruck erstellen, anhand dessen TestStand den Speicherort des Protokolls bestimmt. Dieser Ausdruck kann vordefinierte Makros enthalten, auf die im Menü des Steuerelements für den Protokolldateipfad zugegriffen werden kann.
Hinweis: Zeigen Sie beim Konfigurieren des Protokollausdrucks über das Feld „Evaluated Report File Path“ (Ausgewerteter Protokolldateipfad) und das Vorschaubild das Verhalten des aktuellen Ausdrucks an.
Sie können separate Dateispeicherorte für erfolgreiche und nicht erfolgreiche Protokolle mit dem UUTStatus-Makro im Ausdruck für den Protokolldateipfad erstellen. Sie können dieses Makro beispielsweise in Ihrem Dateipfad zur Erstellung verschiedener Speicherorte für erfolgreiche und nicht erfolgreiche Protokolle einsetzen. Wenn dieses Makro vorhanden ist, wertet TestStand den Ausdruck für den Protokolldateipfad nach Abschluss der Testausführung erneut aus, da der Prüflingsstatus vor diesem Zeitpunkt unbekannt ist.
Konfigurieren eines anderen Protokolldateipfads/-namens basierend auf dem Prüflingsergebnis
Für Tests mit dem Stapelprozessmodell können Sie das Verhalten des Protokolldateipfads für Stapel und einzelne Prüflinge innerhalb des Stapels weiter konfigurieren. Um auf diese Einstellungen zuzugreifen, wählen Sie im Feld „Type of Model“ (Modelltyp) die Option „Batch“ (Stapel) aus. Mit der Option New UUT Report (Neues Prüflingsprotokoll) für jede Stapeleinstellung können Sie beispielsweise eine separate Protokolldatei für jeden Stapel erstellen. Weitere Informationen zu allen verfügbaren Einstellungen finden Sie im Hilfethema zum Dialogfeld Report Options (Protokolloptionen).
In vielen Fällen erfordert eine Testanwendung, dass Sie zusätzliche Daten im Protokoll protokollieren, die über die von TestStand standardmäßig protokollierten Ergebnisse hinausgehen. Um diesem Bedarf gerecht zu werden, bietet TestStand verschiedene integrierte Funktionen, mit denen Sie benutzerdefinierte Daten einfach im Protokoll protokollieren können:
Die folgenden Abschnitte enthalten weitere Details zu diesen Funktionen.
Sie können ganz einfach Parameterdaten für die Testschritte protokollieren, indem Sie das Kontrollkästchen Log (Protokollieren) in der Registerkarte Module (Modul) aktivieren, wenn Sie Codemodulparameter konfigurieren, wie unten dargestellt. Durch Aktivieren dieses Kontrollkästchens wird der ausgewählte Parameter so konfiguriert, dass er ohne weitere Konfiguration automatisch in Protokollen oder Datenbankprotokollen angezeigt wird.
Codemodul – Kontrollkästchen „Enable Log“ (Protokoll aktivieren)
Sie können zusätzliche benutzerdefinierte Daten für alle Schrittergebnisse über den Bereich „Additional Results“ (Zusätzliche Ergebnisse) aufnehmen. Dieser befindet sich auf der Registerkarte „Properties“ (Eigenschaften) des Bereichs „Step Settings“ (Schritteinstellungen) (siehe Abbildung unten).
Konfigurieren zusätzlicher Ergebnisse
TestStand bietet mehrere vorkonfigurierte zusätzliche Ergebnisse zum Protokollieren allgemeiner Eigenschaften, z. B. des Schrittkommentars und der Anforderungsinformationen. Um auf diese vorkonfigurierten Ergebnisse zuzugreifen, klicken Sie auf die Schaltfläche Add Result From List (Ergebnis aus Liste hinzufügen), und wählen Sie ein Element in der Liste aus. Sie können auch einen Bedingungsausdruck für jeden zusätzlichen Ergebniseintrag angeben. Das Ergebnis wird nur protokolliert, wenn der Ausdruck „True“ ergibt.
Weitere Informationen zu den Einstellungen für zusätzliche Ergebnisse finden Sie im Thema Additional Results Edit Tab (Registerkarte zum Bearbeiten zusätzlicher Ergebnisse) in der TestStand-Hilfe.
Result.ReportText ist ein zusätzliches Zeichenfolgenelement im Ergebniscontainer, in dem benutzerdefinierte Informationen für den Schritt gespeichert werden. Wenn die Zeichenfolge nicht leer ist, enthält der Protokollgenerator die ReportText-Zeichenfolge als Feld im Protokoll. Das ReportText-Feld unterstützt HTML-Tags für alle Protokollformate außer ASCII. Sie können mit diesem Feld also Rich-Text-Elemente wie verwandte Bilder oder Hyperlinks einschließen.
Weitere Informationen über das Einfügen von Bildern in einen Report finden Sie unter Einfügen von Bildern in einen TestStand-Report.
Die folgende Abbildung zeigt ein Beispiel für das Einbetten eines Bildes in ein Schrittergebnis mithilfe von HTML in der ReportText-Eigenschaft.
Protokoll, das ein Bild in Result.ReportText anzeigt
Mit TestStand können Sie Ihre eigenen benutzerdefinierten Schritttypen erstellen, um bestimmte Funktionen zu implementieren. In diesem Fall ist es häufig erforderlich, benutzerdefinierte Schritttypdaten zu protokollieren.
Hinweis: Wenn Sie keine Erfahrungen mit benutzerdefinierten Schritttypen in TestStand haben, lesen Sie den Artikel Best Practices for Custom Step Type Development (Best Practices für die Entwicklung benutzerdefinierter Schritttypen), bevor Sie diesen Abschnitt lesen.
Gehen Sie folgendermaßen vor, um eine benutzerdefinierte Schritteigenschaft zu erstellen, die im Protokoll angezeigt wird:
Die Prozessmodelle bieten eine Reihe von Callbacks, die Sie überschreiben können, um die Modellfunktionalität für eine bestimmte Clientsequenzdatei zu ändern. Dieser Mechanismus eignet sich auch zum Anpassen des Protokollgenerators. In diesem Abschnitt werden die folgenden allgemeinen Anpassungsmethoden beschrieben:
Hinweis: Wenn Sie nicht mit Prozessmodell-Callbacks vertraut sind, lesen Sie das Hilfethema Using Callback Sequences to Modify Process Models (Verwenden von Callback-Sequenzen zum Ändern von Prozessmodellen), bevor Sie mit diesem Abschnitt fortfahren.
Zusätzlich zur Verwendung des Dialogfelds „Report Options“ (Protokolloptionen) können Sie Protokolloptionen programmatisch festlegen, indem Sie den ReportOptions-Callback in Ihrer Testsequenz überschreiben. Gehen Sie folgendermaßen vor, um den Callback in Ihrer Sequenzdatei zu überschreiben:
Wenn Sie die Sequenz ausführen, ruft das Prozessmodell diese Callback-Sequenz unmittelbar nach dem Laden der aktuellen Protokolloptionen auf, die im Dialogfeld „Report Options“ (Protokolloptionen) festgelegt wurden. Die aktuellen Protokolloptionen sind in der Variablen Parameters.ReportOptions enthalten. Sie können die Werte dieser Eigenschaften ändern, um die Protokolloptionen für die aktuelle Ausführung zu ändern. Diese Optionen wirken sich nicht auf die Einstellungen im Dialogfeld „Report Options“ (Protokolloptionen) oder andere Ausführungen aus. Um beispielsweise die On-the-Fly-Protokollerstellung für eine Sequenzdatei zu aktivieren, können Sie einen Anweisungsschritt mit dem folgenden Ausdruck erstellen:
Parameters.ReportOptions.UseOnTheFlyReporting =True
Für eine Testanwendung müssen Sie möglicherweise zusätzliche identifizierende Informationen zum Prüfling angeben, z. B. den Standort des Herstellers. Daten zu Prüfling und Station werden vom Prozessmodell in den Variablen Parameters.UUT und Parameters.ModelData.StationInfo gespeichert. Die meisten von Ihnen erstellten Modell-Callbacks enthalten diese Eigenschaften als Parameter, damit Sie im Callback auf diese Daten zugreifen können. In TestStand 2013 und höher enthalten die Eigenschaften UUT und StationInfo eine AdditionalData-Untereigenschaft, bei der es sich um einen unstrukturierten Container handelt. Sie können dieser Eigenschaft zur Laufzeit Daten hinzufügen, ohne Änderungen an den Datentypen UUT und StationInfo vorzunehmen.
Gehen Sie folgendermaßen vor, um mit dem AdditionalData-Container benutzerdefinierte Prüflingsdaten programmatisch zur Kopfzeile hinzuzufügen:
Parameters.UUT.AdditionalData.SetValString("Manufacturer.Name",1,"National Instruments"),
Parameters.UUT.AdditionalData.SetValString("Manufacturer.Location",1,"Debrecen, Hungary"),
Hinweis: Wenn Sie die SetValString-Methode mit 1 als PropertyOption verwenden, wird eine Eigenschaft erstellt, wenn sie nicht vorhanden ist.
Parameters.UUT.AdditionalData.SetFlags("",0,PropFlags_IncludeInReport)
Das folgende Protokoll enthält die benutzerdefinierten Daten im AdditionalData-Container. Der Prozess zum Hinzufügen benutzerdefinierter Stationsdaten ist ähnlich, aber es kommt die Eigenschaft Parameters.ModelData.StationInfo anstelle von Parameters.UUT zum Einsatz.
Hinzufügen von Herstellerinformationen zur Protokollkopfzeile mithilfe des UUT.AdditionalData-Containers
Hinweis: Alternativ können Sie Daten manuell zum IncludeInReport-Flag für den Locals.UUT- oder Locals.ModelData.StationInfo-Container eines Prozessmodell-Eintrittspunkts zur Bearbeitungszeit hinzufügen und dieses aktivieren, um Prüflings- oder Stationsdaten für alle Clientsequenzdateien hinzuzufügen.
Der Protokollgenerator definiert viele Callbacks, die Sie in einer Clientsequenzdatei überschreiben können. Jeder dieser Callbacks wird ausgeführt, nachdem der entsprechende Protokolltext erstellt wurde. Damit können Sie die Standardausgabe des Protokollgenerators ändern. Sie sollten nur dann mit diesen Callbacks benutzerdefinierte Daten hinzufügen, wenn keine der zuvor beschriebenen Methoden möglich ist.
Diese Callbacks werden nur ausgeführt, wenn Sie die Option „Sequence“ (Sequenz) der Option „Select a Report Generator for Producing the Report Body“ (Protokollgenerator zum Erstellen des Protokollhauptteils auswählen) auf der Registerkarte „Contents“ (Inhalt) des Dialogfelds „Report Options“ (Protokolloptionen) aktivieren. Diese Option ist für HTML- und ASCII-Protokolle verfügbar.
Die Methode zum Anpassen der Darstellung des Protokolls hängt stark vom Protokollformat ab. Bei ASCII- und HTML-Protokollen sind die Darstellungsinformationen und die Protokolldaten eng miteinander verbunden. Das Ändern der Protokolldarstellung erfordert daher eine direkte Änderung des Protokollgeneratorcodes. Dazu benötigen Sie wiederum ein grundlegendes Verständnis des Protokollgenerators, was den Rahmen dieses Dokuments sprengt. Weitere Informationen zur Implementierung des Protokollgenerators finden Sie im Artikel Report Generation Explained (Erläuterung der Protokollerstellung).
Wie im Abschnitt „Protokolloptionen“ dieses Dokuments beschrieben verwenden XML- und ATML-Protokolle Stylesheets zur Erstellung eines lesbaren Protokolls aus den Rohprotokolldaten. Sie können die Darstellung dieser Protokolle anpassen, indem Sie das Stylesheet bearbeiten. Änderungen am Protokollgenerator selbst sind nicht erforderlich. Weitere Informationen und Beispiele zur Anpassung von Stilvorlagen finden Sie im Abschnitt XML-Protokolle der TestStand-Hilfe.
Das Anpassen von Protokollen in TestStand ist eine häufige Aufgabe, und TestStand bietet viele Funktionen zum Anpassen des Protokollinhalts, der Funktionalität und des Stils. Anhand des folgenden Ablaufdiagramms können Sie Entscheidungen zur Implementierung benutzerdefinierter Protokolle treffen.
Ablaufdiagramm zur Auswahl des richtigen Verfahrens zum Anpassen von Protokollen Ablaufdiagramm zur Auswahl des richtigen Verfahrens zum Anpassen von Protokollen