Software-Prüfläufe beschleunigen
Auf die Reihung kommt es an
Fortsetzung des Artikels von Teil 2
Unterschriftenvergleich
Tests für eingebette Systeme folgen sehr oft dem gleichen Schema:
- Setze das System in einen definierten Initialzustand
- Setze Parameter im SUT
- Stelle einen Funktionsgenerator und/oder ein Messgerät ein
- Messen
- Setze weitere Parameter im SUT
- Stelle einen Funktionsgenerator und/oder ein Messgerät ein
- Messen und so weiter
Das Setzen von Parametern erfolgt bei Riedel Communications typischerweise über Ethernet mit dem Protokoll Ember+ [5]. Jeder Parameter hat eine ID, zum Beispiel »phaseOffset«. Die ID kann in mehreren Geräten des verteilten Systems vorkommen. Um einen Parameter eines bestimmten Geräts anzusprechen, wird die Geräteadresse mit der Parameter-ID kombiniert. Fast liegt die Antwort auf der Hand: Die Ember+-Schnittstelle wurde so erweitert, dass jeder Test in einem separaten Logfile eine Signatur hinterlässt. Sie besteht aus einer Kette der verwendeten Parameter-IDs samt gesetzten Parameterwerten. Es entsteht ein String, der deutlich kürzer ist als bei den zuvor angedeuteten Verfahren. Gleichzeitig charakterisiert sie die Natur der Prüfung haarscharf. Auf Basis der Signaturen stellt das System die Ähnlichkeit fest.
Es gibt, wie erwähnt, eine ganze Reihe von ausgeklügelten Verfahren, die die Ähnlichkeit von Strings bewerten. Sie werden in Suchmaschinen für das Erkennen von vermutlich gesuchten Begriffen bei Tippfehlern, für Data Mining, für Plagiatsprüfungen, und vielem mehr verwendet. Für den Zweck des Vergleichs von Tests reicht eine ganz einfache Similarity-Metrik: die Jaccobian Similarity (Formel 2).
Jobangebote+ passend zum Thema
Die Maßzahl ist dann 100 Prozent, wenn beide Strings exakt das gleiche Vokabular verwenden. Ein String wird dabei als Menge (im Sinne der Mengenlehre) verstanden. Elemente der Menge sind in den Signatur-Logs die Tupel (Parameter-ID, Parameterwert) – das bedeutet: Wenn zwei Tests A und B die gleichen Parameter auf die gleichen Werte setzen (aber eventuell in anderen Geräten), ist J(A,B) 100 Prozent.
Um dem Scheduler die erwähnte »Intelligenz« zu verleihen, wurde er so adaptiert, dass er dynamisch Prioritäten verändern kann. Nach jedem Ausführen bewertet das System die Prioritäten der noch nicht ausgeführten Prüfungen neu:
- Ist das Ergebnis »Failed«, wird der ähnlichste Test gesucht und dessen Priorität erhöht.
- Ist das Ergebnis »Error«, werden die zehn ähnlichsten Tests gesucht und deren Priorität reduziert. Das geschieht, um keine Zeit mit Fehlern der Testumgebung zu verlieren.
- Ist das Ergebnis »Passed«, wird der ähnlichste Test gesucht. Wenn dessen Priorität nicht mit einer anderen Bewertung hinaufgesetzt wurde, wird sie geringfügig herabgesetzt. Das geschieht um die Diversität im Test-Set zu erhöhen.
Um das Bewerten der Ähnlichkeit gut bei kurzen Prüfungen auszuführen, sind »Gleichanteile« von Tests aus den Signaturen zu entfernen. Bringen alle Ausführungen zuerst alle Geräte in einen Initialzustand, bevor sie ihre eigenen Wege gehen, so ist die Initialisierung der erwähnte Gleichanteil. Ein Streichen der Initialisierung aus allen Signaturen erhöht die Aussagekraft von J(A,B) bei kurzen Prüfungen deutlich.
Schnelleres Testen
Es wurde ein Verfahren vorgestellt, das sich mithilfe von einfach zu ermittelnden Daten einer Test-Impact-Analyse annähert und sie um eine dynamisches Re-Priorisieren erweitert. Die hier vorgestellte Reihung erhebt keinen wissenschaftlichen Anspruch. Im Gegenteil: Sie zeigt, dass selbst ohne KI, ohne multivariane Optimierung und ohne Data-Mining-Algorithmen die Reihung von automatischen Prüfungen deutlich zu verbessern ist.
Doch Vorsicht: Kein automatisches Verfahren sowie keine Test-Impact-Analyse auf Basis von Code-Änderungen, kann Prüfläufe mit 100-prozentiger Gewissheit ausschließen. Eine Regressionplanung für ein Produkt-Release ist daher immer per Hand zu machen.
Literatur
[1] Zhe Yu, Fahmid Fahid, Tim Menzies, Gregg Rothermel, Kyle Patrick, and Snehit Cherian: »TERMINATOR: Better Automated UI Test Case Prioritization«. Proceedings of the 27th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE ’19), August 26–30, 2019, Tallinn, Estonia. ACM, New York, NY, USA. https://doi.org/10.1145/3338906.3340448.
[2] Rothermel, G., Untch, R. H., Chu, C., & Harrold, M. J. (2001). Prioritizing test cases for regression testing. IEEE Transactions on software engineering, 27(10), 929-948.
[3] Dipesh Pradhan, Shuai Wang, Shaukat Ali, Tao Yue, Marius Liaaen: »REMAP: Using Rule Mining and Multi-Objective Search for Dynamic Test Case Prioritization«. 2018 IEEE 11th International Conference on Software Testing, Verification and Validation.
[4] Breno Miranda, Emilio Cruciani, Roberto Verdecchia, and Antonia Bertolino. 2018. FAST Approaches to Scalable Similarity-based Test Case Prioritization. In Proceedings of ICSE ’18: 40th International Conference on Software Engineering, Gothenburg, Sweden, May 27 - June 3, 2018 (ICSE ’18).
[5] https://github.com/Lawo/ember-plus/wiki.
Die Autoren
Christoph Luckeneder ist wissenschaftlicher Mitarbeiter am Institut für Computertechnik der TU Wien. Seine Interessen am Testen und Verifizieren von Cyber-physikalischen-Systemen wurde im Rahmen seines Masterstudiums
geweckt. Seither befasst er sich in Forschungsprojekten mit der Verifikation von Automotive- und Robotiksystemen. Den Fokus setzt er dabei auf die Systemmodellierung zur anschließenden formalen Verifikation und effizienten Generierung von aussagekräftigen Testfällen.
christoph.luckeneder@tuwien.at
Stephan Grünfelder ist Autor des Buchs »Software-Test für Embedded Systems« und Leiter des Testteams bei Riedel Communications Austria. Davor hielt er viele Jahre Seminare für Industrieunternehmen ab und beriet Unternehmen bei Testthemen. (www.methver.webs.com). Seine Freizeit verbringt er am liebsten ganz ohne Computer mit seiner Familie auf einem kleinen Bauernhof im Waldviertel in Niederösterreich.
stephan.gruenfelder@riedel.net
- Auf die Reihung kommt es an
- Test-Impact-Analyse
- Unterschriftenvergleich
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Sicherheit bei der Software-Entwicklung
Welcher Standard ist der Beste?
5G-Mobilfunk
Konformitätstests für Geräte und Basisstationen
Elektronik-Designer als Vorbild
Plattformbasiertes Testen
Testsystem für Cellular V2X
Rohde & Schwarz unterstützt chinesische ITS-Standards
