- Evaluierung der Rückgabewerte von Bibliothekspackages mit Zeitoptionen
- Sprechende Namen der Bibliothekspackages in Testfällen
ecu.test Release 2024.3
Highlights auf einen Blick
Schlüsselwortbasiertes Testen
Mit Hilfe von Schlüsselwörtern können Testfälle spezifiziert werden, die universell austauschbar sind, da alle dieselbe „Sprache“ verwenden. Durch eine Aufstellung von Schlüsselwörtern, wird eine gemeinsame, rollenübergreifende Sprache festgelegt, die die Erstellung von Testspezifikationen und Implementierungen erleichtert. Mit diesem Release 2024.3 gibt es zwei entscheidende Weiterentwicklungen, die in Summe ein schlüsselwortbasiertes Testen ermöglichen:
Beispiel: Schlüsselwort Sicherheitsgurt (SeatBelt).
Die Abbildung rechts zeigt die Festlegung des Erwartungswertes 1 für den statusSeatBelt. Nachdem das Bibliothekspackage die Stimulation Sicherheitsgurt anlegen bzw. Sicherheitsgurt abgelegen durchgeführt hat, wird der Status des entsprechenden Signals in einem detaillierten Testreport angezeigt und kann evaluiert werden.
Hinweis: Es können auch mehrere Rückgabewerte in der Bibliothek definiert und im aufrufenden Package evaluiert werden.
Die verschiedenen Zeitoptionen ermöglichen es, die Erwartungswerte der Bibliothek an zeitliche Bedingungen zu knüpfen. Das Bibliothekspackage wird dabei so oft wiederholt ausgeführt, bis die Erwartung erfüllt bzw. die Zeitoption abgelaufen ist.
Die Abbildung rechts zeigt die Festlegung des Erwartungswertes 1 für den statusSeatBelt. Nachdem das Bibliothekspackage die Stimulation Sicherheitsgurt anlegen bzw. Sicherheitsgurt abgelegen durchgeführt hat, wird der Status des entsprechenden Signals in einem detaillierten Testreport angezeigt und kann evaluiert werden.
- SUCCESS: alle Rückgabewerte entsprechen den Erwartungswerten
- FAILED: mindestens ein Rückgabewert entspricht nicht den Erwartungen
Hinweis: Es können auch mehrere Rückgabewerte in der Bibliothek definiert und im aufrufenden Package evaluiert werden.
Die verschiedenen Zeitoptionen ermöglichen es, die Erwartungswerte der Bibliothek an zeitliche Bedingungen zu knüpfen. Das Bibliothekspackage wird dabei so oft wiederholt ausgeführt, bis die Erwartung erfüllt bzw. die Zeitoption abgelaufen ist.
Durch eine Parametrierung der Packagemappings können die Aufrufe von Bibliothekspackages deutlich sprechender im Testfall und im Report angezeigt werden. Dies wird durch die Kombination aus Packagenamen, deren Übergabeparametern und den Mappingnamen erreicht.
Am Beispiel Sicherheitsgurt, mit zwei Parametern und einem generischem Mapping für den Status, werden die folgenden Parameter definiert:
Am Beispiel Sicherheitsgurt, mit zwei Parametern und einem generischem Mapping für den Status, werden die folgenden Parameter definiert:
- action: Auswahl Gurt öffnen oder schließen
- position: Auswahl des Sitzes im Fahrzeug
Um das Schlüsselwort zu definieren, wurde das Mapping um die Parametrierung von Übergabeparametern und Testgrößen erweitert.
Die Bildungsvorschrift für das Bibliothekspackages Seatbelt zeigt in der Abbildung beispielhaft, dass mittels der Platzhalter Parameter und Mapping auf die Schnittstellen zur Bibliothek zurückgegriffen werden kann:
${Parameter.action} ${Parameter.position} Seatbelt and check ${Mapping.SeatStatusSignal}
Die Bildungsvorschrift für das Bibliothekspackages Seatbelt zeigt in der Abbildung beispielhaft, dass mittels der Platzhalter Parameter und Mapping auf die Schnittstellen zur Bibliothek zurückgegriffen werden kann:
${Parameter.action} ${Parameter.position} Seatbelt and check ${Mapping.SeatStatusSignal}
Aufzeichnungsschnittstellen für Vector XL und SIL Kit in Wireshark
Während der Einrichtung und Inbetriebnahme von realen oder virtuellen Prüfplätzen entsteht regelmäßig Bedarf für manuelles Testen oder Debuggen. Insbesondere Prüfplatzverantworliche und Integratoren wünschen sich dann, den Netzwerkverkehr von Ethernet und klassischen Bussen live mitlesen und analysieren zu können. Mit Version 2024.3 bietet ecu.test die Möglichkeit, dafür die freie und etablierte Netzwerkanalyse-Software Wireshark zu nutzen.
Über den in ecu.test enthaltenen trace.xplorer lassen sich in Wireshark zusätzliche Aufzeichnungsschnittstellen hinzufügen, um mit diesem Tool Ethernet, CAN und CAN-FD über die verbreitete Vector XL Driver Library zu erfassen. Für Ethernet wird auch das Vector SIL Kit unterstützt. Die Einrichtung dieser Schnittstellen geschieht ganz einfach über einen Dialog im trace.xplorer.
Mit dieser Lösung lassen sich tiefe Einblicke in Busvirtualisierungen gewinnen und Probleme bei neuen oder bestehenden Prüfplätzen schnell diagnostizieren und beheben. Die Nutzung dieses Features erfordert eine trace.xplorer-Lizenz und bei Bedarf eine passende Vector XL-kompatible Messbox.
Über den in ecu.test enthaltenen trace.xplorer lassen sich in Wireshark zusätzliche Aufzeichnungsschnittstellen hinzufügen, um mit diesem Tool Ethernet, CAN und CAN-FD über die verbreitete Vector XL Driver Library zu erfassen. Für Ethernet wird auch das Vector SIL Kit unterstützt. Die Einrichtung dieser Schnittstellen geschieht ganz einfach über einen Dialog im trace.xplorer.
Mit dieser Lösung lassen sich tiefe Einblicke in Busvirtualisierungen gewinnen und Probleme bei neuen oder bestehenden Prüfplätzen schnell diagnostizieren und beheben. Die Nutzung dieses Features erfordert eine trace.xplorer-Lizenz und bei Bedarf eine passende Vector XL-kompatible Messbox.
ecu.test für Linux und Cloud
Um skalierenden Anwendungsbereichen, insbesondere im virtuellen Testen in SiL-Umgebungen oder der Traceanalyse von z. B. Realfahrdaten gerecht zu werden, ist ecu.test als Runner für diverse Zielsysteme verfügbar.
Diese reine Ausführungsvariante ohne grafische Benutzeroberfläche kann über ein ecu.test-deb-Package unter Ubuntu 20.04 sowie Ubuntu 22.04 installiert werden. Um auf Ubuntu basierende Container-Images selber bauen zu können, stehen neben dem deb-Package auch entsprechende Docker-Dateien zur Verfügung.
Analog lässt sich auch weiterhin mit dem ecu.test Installer ein auf Windows basierendes Image erzeugen.
Mit dem Release 2024.3 stellen wir nun erstmals zusätzlich ein fertiges, sofort startbares ecu.test Image zur Verfügung, welches in Containerumgebungen verwendet und via REST-API ferngesteuert werden kann.
Die Fähigkeiten eines Runners reichen nicht, sondern du wünschst dir die Bearbeitung von ecu.test-Artefakten auch unter Linux? Die grafische Benutzeroberfläche für Linux steht als ALPHA-Version zur Verfügung. Bitte kontaktiere uns bei Interesse über support@tracetronic.com. Gerne stellen wir dir diese Variante zur Verfügung.
Diese reine Ausführungsvariante ohne grafische Benutzeroberfläche kann über ein ecu.test-deb-Package unter Ubuntu 20.04 sowie Ubuntu 22.04 installiert werden. Um auf Ubuntu basierende Container-Images selber bauen zu können, stehen neben dem deb-Package auch entsprechende Docker-Dateien zur Verfügung.
Analog lässt sich auch weiterhin mit dem ecu.test Installer ein auf Windows basierendes Image erzeugen.
Mit dem Release 2024.3 stellen wir nun erstmals zusätzlich ein fertiges, sofort startbares ecu.test Image zur Verfügung, welches in Containerumgebungen verwendet und via REST-API ferngesteuert werden kann.
Die Fähigkeiten eines Runners reichen nicht, sondern du wünschst dir die Bearbeitung von ecu.test-Artefakten auch unter Linux? Die grafische Benutzeroberfläche für Linux steht als ALPHA-Version zur Verfügung. Bitte kontaktiere uns bei Interesse über support@tracetronic.com. Gerne stellen wir dir diese Variante zur Verfügung.
Testfall-Coverage
In großen Workspaces stellt sich oft die Frage, welche Packages eigentlich in welchem Umfang verwendet werden. Kommen noch Bibliothekspackages dazu, die eigentlich umfangreich abgesichert werden müssen, besteht die Herausforderung darin, die Qualität sicherzustellen.
ecu.test bietet nun die Möglichkeit zur Erstellung und Integration von Coverage-Metriken für Tests im Rahmen des Qualitätsmanagements (QM) und des Automotive Safety Integrity Level (ASIL). Diese Metriken sind essenziell für die Erstellung detaillierter Berichte zur Testabdeckung. Sie helfen dabei, "tote" Testabschnitte zu identifizieren, sodass die Wartung und Qualitätssicherung von Packages und des gesamten Workspaces verbessert wird. Darüber hinaus ermöglichen sie die Absicherung von User-Bibliotheken und Bibliotheksworkspaces, ähnlich der Code-Coverage in Programmiersprachen.
ecu.test bietet nun die Möglichkeit zur Erstellung und Integration von Coverage-Metriken für Tests im Rahmen des Qualitätsmanagements (QM) und des Automotive Safety Integrity Level (ASIL). Diese Metriken sind essenziell für die Erstellung detaillierter Berichte zur Testabdeckung. Sie helfen dabei, "tote" Testabschnitte zu identifizieren, sodass die Wartung und Qualitätssicherung von Packages und des gesamten Workspaces verbessert wird. Darüber hinaus ermöglichen sie die Absicherung von User-Bibliotheken und Bibliotheksworkspaces, ähnlich der Code-Coverage in Programmiersprachen.
Projektreport ist nun Standard
Nachdem der überarbeitete Projektreport in ecu.test 2024.2 noch manuell aktiviert werden musste, ist er nun standardmäßig aktiv.
Auf Dateiebene werden projektbezogene Informationen in einer .prf-Datei gespeichert, während Package-Ergebnisse in individuellen .trf-Dateien abgelegt werden.
Der Report-Viewer und die Report-API bieten auch weiterhin den gewohnten einheitlichen Zugriff auf alle Informationen.
Auf Dateiebene werden projektbezogene Informationen in einer .prf-Datei gespeichert, während Package-Ergebnisse in individuellen .trf-Dateien abgelegt werden.
Der Report-Viewer und die Report-API bieten auch weiterhin den gewohnten einheitlichen Zugriff auf alle Informationen.