Die Leistung des Testsystems kann die Produktivität und die Kosten der Fertigungslinie erheblich beeinflussen. Bei langsamen Testsystemen sind unter Umständen kostspielige Duplikate erforderlich, oder es kann weniger getestet werden. Beides kann die Qualität beeinträchtigen. Durch die Optimierung der Leistung Ihrer Testsoftware können Sie die Testdauer erheblich verkürzen und mit weniger Teststationen ausführlicher testen.
In diesem Artikel werden einige empfohlene Methoden zur Optimierung der Leistung von Teststationen erläutert, die mit der TestStand-Software von NI entwickelt wurden. Beachten Sie dabei, dass es keine Universallösung für sämtliche Testsysteme gibt. Bei bestimmten Testsystemen führt eine Herangehensweise zur Reduzierung, in anderen zur Erhöhung der Leistung. Nehmen Sie sich Zeit, um die Testergebnisse vor und nach der Implementierung von Änderungen am System zu vergleichen, damit Sie die potenziellen Vor- und Nachteile kennen.
Die verschiedenen Konfigurationsoptionen von TestStand wirken sich unterschiedlich auf die Leistung aus. In den folgenden Abschnitten werden diese Optionen beschrieben.
Die Sequenzverfolgung liefert sofortiges Feedback und den Status des aktuellen Vorgangs, z. B. „Pass“ (Erfolgreich), „Fail“ (Fehlgeschlagen), „Error“ (Fehler) oder „Skipped“ (Übersprungen). Die Sequenzverfolgung wirkt sich jedoch auf die Leistung aus, weil die Ausführungsgeschwindigkeit verringert wird. Mit den folgenden Herangehensweisen können Sie die Ausführungsgeschwindigkeit erhöhen, ohne die Vorteile der Sequenzverfolgung zu beeinträchtigen.
Um die Leistung bei aktivierter Sequenzverfolgung zu verbessern, legen Sie eine hohe Verfolgungsgeschwindigkeit fest, damit es zwischen den Schritten nicht zu einer zusätzlichen Verzögerung kommt. Auf der Registerkarte „Execution“ (Ausführung) des Dialogfelds „Station Options“ (Stationsoptionen) können Sie die Ablaufverfolgung konfigurieren. Klicken Sie dazu auf Configure » Station Options (Konfigurieren » Stationsoptionen).
Selbst bei der schnellsten Einstellung erhöht die Ablaufverfolgung den Aufwand um einige Millisekunden pro Schritt, weil das Fenster „Execution View“ (Ausführungsansicht) nach jedem Schritt aktualisiert wird. Wenn Sie die Ablaufverfolgung vollständig deaktivieren, erzielen Sie die höchste Leistung. In diesem Fall wird das Fenster „Execution View“ (Ausführungsansicht) bei der Ausführung der Sequenz nicht aktualisiert.
Mit der Eigenschaft Sequence Call Trace Setting (Einstellung für Sequenzaufruf-Ablaufverfolgung) deaktivieren Sie die Ablaufverfolgung in bestimmten Untersequenzen und schaffen einen Ausgleich zwischen der Leistung und den Vorteilen der Ablaufverfolgung im Hinblick auf die Benutzerfreundlichkeit. Wenn Sie so vorgehen wollen, unterteilen Sie Ihre Tests in logische Gruppen und erstellen Sie für diese Gruppen jeweils Untersequenzen. Beispielsweise können in einer Testsequenz für ein Mobilgerät Tests für die einzelnen Komponenten – Daten der Funkzelle, Benutzereingaben und Audiosysteme – in separaten Sequenzen implementiert werden. Deaktivieren Sie für den SequenceCall-Schritt jeder Komponente die Ablaufverfolgung innerhalb des Sequenzaufrufs.
Wenn Sie die Testsequenz auf diese Weise organisieren, können Sie die Sequenzverfolgung für die Sequenz der obersten Ebene nutzen, ohne den Leistungs-Overhead für die Verfolgung jedes Teilschritts in Kauf nehmen zu müssen. Diese Herangehensweise lässt sich auch leicht an parallele Tests anpassen, da jede Untersequenz asynchron aufgerufen werden kann. Weitere Informationen zum Parallelisieren Ihrer Testsequenz finden Sie im Abschnitt Improving Test Performance through Parallel Testing (Verbessern der Testleistung durch paralleles Testen).
Mit Sequenzaufrufschritten bei deaktivierter Ablaufverfolgung verbessern Sie die Leistung und sehen den Ausführungsstatus.
Mit TestStand können Sie konfigurieren, wann Codemodule in den Speicher geladen und aus diesem entfernt werden. Dies kann erhebliche Auswirkungen auf die Speicherauslastung und die Ausführungsgeschwindigkeit einer Testsequenz haben. Wenn Sie Module so konfigurieren, dass sie länger im Speicher bleiben, verkürzt sich die Ausführungsdauer, da die Module bei der Ausführung von Untersequenzen nicht neu geladen werden müssen. Wenn jedoch zu viele Module im Speicher verbleiben, kommt es unter Umständen zur Überschreitung der Anwendungsspeichergrenzen oder des verfügbaren physischen Speichers, was auch die Ausführung verlangsamen kann.
Im Idealfall können Sie Verbesserungen an Ihrem Testsystem vornehmen, damit die Speicherbeschränkungen weniger restriktiv ausfallen, anstatt Speicherplatz über das Entfernen von Codemodulen freizugeben. Zum Beispiel:
Wenn die Speichernutzung weiterhin ein Problem darstellt, können Sie die Optionen zum Laden bzw. Entfernen auf Schritt- oder Sequenzdateiebene festlegen. In den meisten Testsystemen können Sie die Option Preload when opening sequence file (Vorab-Ladevorgang beim Öffnen der Sequenzdatei) oder Preload when execution begins (Vorab-Ladevorgang bei Beginn der Ausführung) mit der Option Unload when sequence file is closed (Beim Schließen der Sequenzdatei entfernen) kombinieren, um eine optimale Leistung zu erzielen.
Ziel | Optimale Einstellungen |
Maximale Ausführungshäufigkeit | Bei den Optionen „Preload when opening sequence file“ (Vorab-Ladevorgang beim Öffnen der Sequenzdatei) und „Unload when sequence file is closed“ (Beim Schließen der Sequenzdatei entfernen) bleiben die Module im Speicher, bis die Sequenz geschlossen wird. Wenn die Module im Speicher geladen bleiben, können nachfolgende Aufrufe schneller ausgeführt werden. |
Geringere Speicherauslastung | Mit den Optionen „Load Dynamically“ (Dynamisch laden) und „Unload after Step Executes“ (Nach Schrittausführung entfernen) entfernen Sie die Module aus dem Speicher, sobald sie nicht mehr benötigt werden. Die Leistung nimmt jedoch ab, da das Modul bei jeder Ausführung eines Schritts neu geladen werden muss. Diese Einstellung birgt zusätzliche Risiken, z. B. das Risiko, dass globale Daten innerhalb eines Codemoduls verloren gehen, wenn dieses Codemodul entfernt wird. |
Das Dateiformat kann sich auf die Geschwindigkeit und Leistung beim Laden großer Sequenzdateien auswirken. Mit TestStand können Sie Sequenzen in den folgenden Dateiformaten speichern: INI, XML und Binärformat.
So legen Sie fest, welches Format für neue Sequenzdateien verwendet werden soll:
So ändern Sie das Format einer vorhandenen Sequenzdatei:
Im Binärdateiformat können Sequenzdateien am schnellsten geladen werden.
Die Konfiguration der Suchverzeichnisse wirkt sich direkt auf die zum Laden von Sequenzdateien und Codemodulen erforderliche Zeit aus, wenn diese mit relativen Pfaden angegeben werden. Die Konfiguration der Suchverzeichnisse wirkt sich auf die Leistung beim ersten Laden und Ausführen der Tests sowie auf nachfolgende Iterationen aus, wenn Module dynamisch geladen werden. Im Dialogfeld für die Konfiguration des Suchverzeichnisses können Sie die Suchverzeichnisse anzeigen und bearbeiten. Mit der Option Configure » Search Directories (Konfigurieren » Suchverzeichnisse) öffnen Sie das Dialogfeld Edit Search Directories (Suchverzeichnisse bearbeiten).
Beim Auflösen des relativen Pfads eines Codemoduls geht TestStand wie folgt vor:
TestStand überprüft die Liste der Suchverzeichnisse, um einen relativen Pfad zu einer Codemoduldatei aufzulösen.
Da für jedes Suchverzeichnis nur ein einziger Pfad berechnet wird, wirkt sich dieser Prozess normalerweise nicht deutlich auf die Leistung aus.
Wenn ein Suchverzeichnis jedoch die Option „Search Subdirectories“ (Unterverzeichnisse durchsuchen) aufweist, wird der Vorgang für jedes Unterverzeichnis innerhalb des angegebenen Pfads wiederholt. Bei einer großen Verzeichnishierarchie im Pfad kann diese Option die Leistung erheblich beeinträchtigen. Wenn darüber hinaus in der Hierarchie mehrere Dateien mit demselben Namen vorhanden sind, kann es vorkommen, dass die falsche Datei geladen wird. Vermeiden Sie daher die Verwendung dieser Option für Suchverzeichnisse, die Sie hinzufügen. Sorgen Sie stattdessen dafür, dass alle Codemodulpfade unter Verwendung eines relativen Pfads zum Basissuchverzeichnis angegeben werden.
Beachten Sie die folgenden Richtlinien, um die Reihenfolge der Suchverzeichnisse weiter zu optimieren:
Ziehen Sie beim Entwerfen der Verzeichnisstruktur für das Testsystem in Betracht, Codemodule in einem Verzeichnis unterhalb des Sequenzdateipfads oder an einem konkreten Codemodulspeicherort zu speichern.
TestStand kann zur Ausführung von Testschritten Codemodule in verschiedenen Entwicklungsumgebungen aufrufen. Die Konfiguration dieser Codemodule und Entwicklungsumgebungen kann sich erheblich auf die Leistung auswirken. In jeder Codemodulumgebung können Sie eine bessere Leistung erzielen, indem Sie nur die erforderlichen Daten an ein Codemodul weitergeben und von dort abrufen. Vermeiden Sie die Weitergabe großer Datenmengen, auf die das Codemodul nicht zugreift bzw. die nicht geändert werden.
Kompilierte Codemodule wie .NET-Assemblys oder C-/C ++-DLLs können die Leistung verringern, wenn Sie eine Debug-Version der DLL anstelle einer Release-Version verwenden. In der Regel nutzen Entwickler in der Entwicklung Debug-DLLs, um Probleme in den Modulen leichter zu finden und zu lösen. Sobald die Testsequenz für die Verteilung bereit ist, erfolgt der Wechsel zu Release-DLLs, die eine bessere Leistung bieten.
Da LabVIEW-VIs direkt ausgeführt werden, können sie entweder in der LabVIEW-Entwicklungsumgebung oder in der LabVIEW Runtime Engine ausgeführt werden. Wenn Sie LabVIEW-VIs in der Entwicklungsumgebung ausführen, können Sie mithilfe von Debugging-Funktionen Probleme mit Codemodulen lösen. Die Ausführungsgeschwindigkeit ist in diesem Fall jedoch geringer. Verwenden Sie bei Produktionstests die LabVIEW Runtime-Engine zum Aufrufen von VIs. Über das LabVIEW-Dialogfeld „Adapter“ können Sie konfigurieren, auf welchem LabVIEW-Server LabVIEW-Code ausgeführt wird:
Um die Ladezeiten für LabVIEW-Code weiter zu optimieren, können Sie Ihre Codemodul-VIs in Packed Project Libraries (PPLs) integrieren. Da PPLs kompilierte Versionen aller VI-Abhängigkeiten von Codemodul-VIs enthalten, kann LabVIEW die Abhängigkeiten schneller in den Speicher laden. Wenn Sie Ihren Code mithilfe des TestStand-Verteilungs-Utility bereitstellen, können alternativ im Rahmen des Verteilungsprozesses PPLs für Ihre VIs erzeugt werden.
Weitere Informationen zur Verwendung von PPLs mit dem TestStand-Verteilungs-Utility finden Sie im Hilfethema Organizing Test Program Files with LabVIEW Packed Project Libraries (Organisieren von Testprogrammdateien mit LabVIEW-PPLs).
Sie können die Testgeschwindigkeit meist steigern, indem Sie mehrere Tests gleichzeitig durchführen. TestStand bietet Funktionen, mit denen Sie das Testen eines einzelnen Prüflings parallelisieren oder mehrere Prüflinge gleichzeitig testen können.
Beim Test eines einzelnen Prüflings können Sie möglicherweise mehrere Teile des Systems gleichzeitig testen. Betrachten Sie beispielsweise die Testsequenz für ein Mobilgerät. Tests für die einzelnen Komponenten – Daten der Funkzelle, Benutzereingaben und Audiosysteme – können in separaten Untersequenzen implementiert werden. Anstatt die einzelnen Sequenzen nacheinander aufzurufen, können Sie den Test beschleunigen, indem Sie den Sequenzaufruf so konfigurieren, dass die Sequenzen asynchron aufgerufen werden.
So legen Sie fest, dass ein Sequenzaufruf asynchron ausgeführt werden soll:
Wenn Sie eine Sequenz in einem neuen Thread aufrufen, können Sie verschiedene Teile eines Prüflings gleichzeitig testen.
Beachten Sie beim Konfigurieren von asynchronen Sequenzaufrufen die Unterschiede zwischen der Verwendung eines neuen Threads und einer neuen Ausführung:
New Thread (Neuer Thread) | New Execution (Neue Ausführung) |
Hat dieselbe Ergebniserfassung und dieselben Berichte wie der Aufrufer | Hat eine eigene Ergebniserfassung und eigene Berichte |
Wird direkt ausgeführt | Kann mit einem Prozessmodell-Eintrittspunkt ausgeführt werden |
Teilt die globalen Werte der Sequenzdatei mit dem Aufrufer | Hat eine neue Kopie der globalen Werte der Sequenzdatei |
Wird vom Aufrufer abgebrochen oder angehalten | Wird unabhängig abgebrochen oder angehalten |
In der Regel sollten Sie die neue Thread-Option für verwandte Tests innerhalb einer Testsequenz verwenden. Eine neue Ausführung eignet sich besser für unabhängigere Funktionen, z. B. einen Statusmonitor, der unabhängig von der Testsequenz ausgeführt werden sollte.
Weitere Informationen zur Frage, ob ein neuer Thread oder eine neue Ausführung verwendet werden soll, finden Sie unter When to Run a Sequence in a New Execution versus in a New Thread (Wann eine Sequenz in einer neuen Ausführung und wann in einem neuen Thread ausgeführt werden sollte).
Um die Ergebnisse der asynchronen Untersequenzen für das Reporting oder die Datenbankprotokollierung abzurufen, nutzen Sie die Warteschritte am Ende der Startsequenz, um auf den Abschluss der asynchronen Sequenzaufrufe zu warten. Sobald der Untersequenz-Thread abgeschlossen ist, hängt TestStand die Ergebnisse der asynchronen Untersequenz an die Ergebnisse der Warteschritte an und stellt sie für das Reporting und die Datenbankprotokollierung zur Verfügung. Um auf eine Sequenzausführung oder einen Thread zu warten, wählen Sie Execution (Ausführung) oder Thread unter Wait (Warten), um festzulegen, auf welche Ausführung bzw. auf welchen Thread Sie warten. Beachten Sie, dass die zusätzliche Wartezeit zu einer Verzögerung der Ausführung führen kann, wenn die aufrufende Sequenz vor dem Thread abgeschlossen ist. Gehen Sie also nur auf diese Weise vor, wenn Sie die Ergebnisse des neuen Threads benötigen.
Rufen Sie mithilfe eines Warteschritts die Ergebnisse eines asynchronen Sequenzaufrufs ab.
TestStand verwendet nicht nur asynchrone Aufrufe in der Testsequenz, sondern ermöglicht es Ihnen auch, mehrere Prüflinge mithilfe der Parallel- und Stapelprozessmodelle gleichzeitig zu testen. Bei diesen Prozessmodellen wird die Testsequenz in mehreren Ausführungen jeweils auf einem separaten Prüfling ausgeführt. Sie können das Prozessmodell für die aktuelle Station oder für eine einzelne Testsequenzdatei ändern.
Mehrere Prüflinge gleichzeitig mit den Parallel- und Stapelprozessmodellen testen
Wie paralleles Testen die Testdauer reduzieren kann, finden Sie in der Parallel Test Strategies Demo (Demo zu parallelen Teststrategien), die in TestStand enthalten ist.
Während das Parallelprozessmodell das Starten und Beenden der Tests von Prüflingen zu unterschiedlichen Zeiten ermöglicht, ist das Stapelprozessmodell so konzipiert, dass die Testsequenz auf allen Prüflingen gleichzeitig gestartet und beendet wird.
Zusätzlich zum gleichzeitigen Starten und Beenden jedes Stapeltests können Sie beim Stapelprozessmodell mit Stapelsynchronisierungsschritten und -einstellungen das Testen von Prüflingen im Stapel weiter synchronisieren. Wenn bestimmte Teile des Tests für alle Prüflinge gleichzeitig ausgeführt werden sollen, können Sie synchronisierte Abschnitte für einen einzelnen Schritt mithilfe der Schritteinstellungen definieren. Für mehrere Schritte benötigen Sie den Schritttyp für Stapelsynchronisierungen.
Sorgen Sie mit einer Stapelsynchronisierung dafür, dass bestimmte Teile des Tests für alle Prüflinge im Stapel synchronisiert werden.
Bei allen Arten von Stapelsynchronisierungsabschnitten betreten und verlassen alle Buchsen den Abschnitt gemeinsam. Sie können die Synchronisierung so konfigurieren, dass sie nacheinander oder nur in einem einzelnen Thread ausgeführt wird.
Weitere Informationen zur Stapelsynchronisierung finden Sie im Beispiel Synchronization Step Types – Batch Synchronization (Synchronisierungsschritttypen – Stapelsynchronisierung).
Wenn mehrere Prüflinge gleichzeitig getestet werden, kann die verfügbare Testhardware zu einem Leistungsengpass werden. Wenn Sie eine gemeinsam genutzte Hardwareressource verwenden, müssen Sie dafür sorgen, dass nie mehrere Threads gleichzeitig auf eine gemeinsam genutzte Hardwareressource zugreifen, damit es nicht zu Ressourcenkonflikten kommt. In der Regel reservieren Sie über die Sperreinstellungen oder über Schritttypen eine gemeinsam genutzte Ressource. Wenn jedoch mehrere Threads für den Abschluss eines Tests auf eine einzelne Ressource warten, kann ein Großteil des Verbesserungspotenzials von parallelen Tests nicht realisiert werden. Damit dies nicht geschieht, können Sie die folgenden Herangehensweisen befolgen:
Beim Schritttyp „Auto Schedule“ (Automatisch planen) können Sie eine Reihe von Tests konfigurieren, die in beliebiger Reihenfolge ausgeführt werden können, um die Testzeit und die Hardwareauslastung zu optimieren. Wenn ein automatisch geplanter Abschnitt unter Verwendung des Parallel- oder Stapelprozessmodells ausgeführt wird, führt jede Buchse den ersten Abschnitt aus, für den keine reservierte Ressource erforderlich ist. Aus diesem Grund kann die Ausführungsreihenfolge zwischen verschiedenen Ausführungen desselben Tests variieren.
Sie können mit der automatischen Planung die Hardwareauslastung optimieren, wenn die Ausführungsreihenfolge nicht wichtig ist.
Befolgen Sie diese Herangehensweise, wenn die Ausführungsreihenfolge von Tests nicht wichtig ist. Nutzen Sie die automatische Planung nicht, wenn für Ihren Test die Testergebnisse in einer bestimmten Reihenfolge dargestellt werden müssen.
Das im Lieferumfang von TestStand enthaltene Ausführungsprofiler-Tool hilft bei der Feststellung, welche Testhardware die Ausführungsgeschwindigkeit des Testsystems begrenzt. Starten Sie den Profiler über den Sequenzeditor mit Tools » Profile Execution (Extras » Profilausführung).
Im Profiler können Sie sehen, wie lange jede Hardwareressource aktiv ist, und fundierte Entscheidungen über die Auswirkungen von zusätzlicher Hardware im Testsystem treffen. Im Beispielprofil unten ist das DMM vollständig ausgelastet, während der Bereich nur zu 66 % ausgelastet ist. Auf der Basis dieses Profils würde eine zweites DMM oder ein DMM mit mehr Kanälen die Testdauer für diese Sequenz verkürzen.
Mit dem Ausführungsprofiler können Sie darstellen, welche Ressourcen potenzielle Engpässe in Ihrer Testkonfiguration darstellen.
Sie können die Testdauer verkürzen, indem Sie dafür sorgen, dass die Schnittstelle zur Hardware so effizient wie möglich eingerichtet ist. In diesem Abschnitt werden Überlegungen zum Verwalten von Hardwarereferenzen und Messtechniken zur Verbesserung der Leistung erörtert.
Bei jeder Hardwarekonfiguration gibt es mehrere allgemeine Faktoren, die die Testeffektivität verringern können. Sie können beispielsweise mit einem Oszilloskop die Anstiegs-, Abfall-, Effektiv- und Spitzenwerte eines Signals messen. Wenn Sie das Oszilloskop so programmieren, dass es die gesamte Wellenform erfasst, die Wellenform an das Testsystem überträgt und dann die Daten nachbearbeitet, um die gewünschten Messungen zu extrahieren, kommt es aufgrund der großen übertragenen Datenmenge zu einer Leistungsminderung. Die Leistung wird auch von der Latenz des Kommunikationsbusses beeinflusst. Sie sollten daher prüfen, ob Ihr Gerät eine hohe Latenz aufweist, z. B. bei einer LAN- oder seriellen Verbindung, oder einen Bus mit niedriger Latenz wie PCI oder PXI nutzt.
Wenn Sie das Oszilloskop so konfigurieren, dass es die Anstiegszeit misst, eine Erfassung auslöst, die Anstiegszeit vom Gerät abruft und dies für jede Messung wiederholt, müssen Sie das Oszilloskop bei jeder Messung neu konfigurieren und erneut triggern. Diese Option ist in der Regel ebenfalls langsam und ineffizient.
Da viele moderne Oszilloskope mehrere Messkanäle haben, können Sie mit den folgenden Schritten die Testausführung beschleunigen:
Das häufige Öffnen und Schließen von Sessions mit der Hardware kann zu einer geringeren Leistung führen: Beim Initialisieren der Kommunikation mit einem Gerät übertragen viele Treiber große Datenmengen zur Prüfung der Kommunikation und Konfigurationen. Aus diesem Grund ist es am besten, die Hardware nur einmal pro Test zu initialisieren, während ein Session-Handle beibehalten wird, das während des Tests den Zugriff auf die Hardware ermöglicht.
Um die Hardware nur einmal bei einem Test zu initialisieren, können Sie den Prozessmodell-Rückruf „ProcessSetup“ vor dem gesamten Testcode ausführen. Bei den Parallel- und Stapelprozessmodellen wird ProcessSetup unabhängig von der Anzahl der Testbuchsen nur einmal ausgeführt. Zum Bereinigen von Referenzen können Sie den ProcessCleanup-Rückruf nach Abschluss aller Tests einmal ausführen. Weitere Informationen zur Erstellung und zum Einsatz von Rückrufen für Prozessmodelle finden Sie unter Using Callbacks in NI TestStand (Verwenden von Rückrufen in NI TestStand).
Der Zugriff auf Hardware-Sessions, die in einem Prozessmodell-Rückruf geöffnet wurden, kann über eine globale Dateivariable erfolgen, die von der Rückrufsequenz und der MainSequence gemeinsam genutzt wird. Alternativ können Sie den Session-Manager verwenden, der die Lebensdauer von Hardware-Sessions mithilfe eines ActiveX-Objekts automatisch verwalten kann. Weitere Informationen zur Verwendung des Session-Managers finden Sie unter Session Manager Examples (Beispiele für den Session-Manager).
Es gibt verschiedene Möglichkeiten, um die Auswirkungen der Ergebniserfassung auf die Systemleistung so niedrig wie möglich zu halten.
Für die integrierten Ergebnisprozessoren können Sie die Option „On-The-Fly“ (Sofort) auswählen, um die Protokollierung während der Ausführung der Sequenz und nicht am Ende der Testsequenz durchzuführen. Berücksichtigen Sie diese Vor- und Nachteile bei der Überlegung, ob Sie diese Einstellung nutzen sollten.
Vorteile der sofortigen Protokollierung:
Nachteile der sofortigen Protokollierung:
Wenn eine gewisse Geschwindigkeitsreduzierung akzeptabel ist, um die Vorteile der sofortigen Protokollierung zu nutzen, können Sie die Auswirkungen auf die Leistung durch Anpassen dieser Einstellungen verringern. So greifen Sie auf diese Einstellungen zu:
Erhöhen Sie zur Verbesserung der Leistung das Verarbeitungsintervall und/oder die maximale Anzahl der Ergebnisse, um die Häufigkeit zu verringern, mit der TestStand die Ergebnisse protokolliert.
Um den Zeitaufwand für die Erzeugung von Ergebnissen zu reduzieren, können Sie Ergebnisdaten in einer Offline-Ergebnisdatei protokollieren. Hierbei handelt es sich um ein schnelles und kompaktes Rohergebnisformat, das alle Informationen enthält, die TestStand zur Erzeugung eines Berichts oder Protokolls in einer Datenbank benötigt. Da die Datei nur Rohdaten enthält, dauert die Verarbeitung weniger lange, was sich positiv auf den Testdurchsatz auswirkt.
Mit dem Utility zur Verarbeitung von Offlineergebnissen können Sie Rohergebnisdateien in einem Testbericht verarbeiten oder die Daten in einer Datenbank protokollieren. Da es sich um ein separates Utility handelt, können Sie es unabhängig vom Testen ausführen, sodass Sie die Ergebnisse zu einem späteren Zeitpunkt oder auf einem anderen Computer verarbeiten können. Das Utility ist in Situationen von Vorteil, bei denen es mehr auf die Leistung des Testsystems als auf die sofortige Protokollerstellung ankommt. Weitere Informationen finden Sie in der Hilfe des TestStand Offline Results Processing Utility.
Lokal auf einer Festplatte gespeicherte Daten werden schneller protokolliert als Daten an einem Netzwerkspeicherort, wobei nicht alle Mechanismen zur Übertragung von Netzwerkdaten gleich schnell sind. Wenn beispielsweise die Kommunikation mit einer Datenbank über Microsoft Message Queues (MSMQ) erfolgt, werden lokale Zwischendatendateien erstellt, die dann über das Netzwerk übertragen werden. Dies ist im Allgemeinen schneller und sicherer als der direkte Schreibvorgang in der Remote-Datenbank. TestStand bietet keine systemeigenen Funktionen für die Verwendung von MSMQ. Es stehen jedoch Tools von Drittanbietern zur Implementierung dieser Art von Kommunikation zur Verfügung.
Ein weiterer zu berücksichtigender Faktor ist die Datenmenge, die im System protokolliert wird. Die Leistung nimmt mit zunehmender Menge an protokollierten Daten ab. Um nur die von Ihnen benötigten Daten zu protokollieren, können Sie die Ergebnisaufzeichnung für bestimmte Schritte oder Sequenzen deaktivieren.
Sie können die Ergebnisaufzeichnung für einzelne Schritte ausschließen, indem Sie die Option Record Result (Ergebnis aufzeichnen) unter Step » Properties » Run Options (Schritt » Eigenschaften » Ausführungsoptionen) deaktivieren. Sie können auch für eine gesamte Sequenz die Ergebnisaufzeichnung mit der Einstellung Disable Result Recording For All Steps (Ergebnisaufzeichnung für alle Schritte deaktivieren) im Dialogfeld Sequence Properties (Sequenzeigenschaften) ausschließen.
In einer Produktionsumgebung müssen Sie möglicherweise nur wissen, dass ein Prüfling einen Test nicht bestanden hat, und nicht unbedingt, welcher Test genau fehlgeschlagen ist. In diesen Fällen können Sie den Test beim ersten Fehler abbrechen, um Systemressourcen freizugeben, und später eine detailliertere Fehleranalyse abrufen.
Abhängig von Ihrem Test können einige Fehler schwerwiegender sein als andere. Möglicherweise möchten Sie den Test nur abbrechen, wenn bestimmte Schritte fehlschlagen. Sie können das Fehlerverhalten für einzelne Schritte oder Sequenzen konfigurieren
So beenden Sie den Test bei einem Fehler während eines bestimmten Schritts:
So beenden Sie den Test bei einem Fehler während einer bestimmten Sequenz:
Sie können diese Einstellung auch für bestimmte Teststationen konfigurieren, z. B. nur beim vorzeitigen Abbruch von Produktionstestmaschinen, wohingegen Sie bei Diagnosemaschinen außerhalb der Produktionslinie den Test immer vollständig abschließen. So konfigurieren Sie bestimmte Testmaschinen so, dass sie bei einem Testfehler abgebrochen werden: