Software-Prüfläufe beschleunigen
Auf die Reihung kommt es an
Fortsetzung des Artikels von Teil 1
Test-Impact-Analyse
Ohne Zweifel haben in iterativen Projekten jene Systemtests das größte Potenzial Fehler aufzudecken, die neuen beziehungsweise geänderten Code durchlaufen. Um einen Zusammenhang der (Black Box)-Systemtests mit dem SUT herzustellen, wird typischerweise bei Werkzeugen zur Test-Impact-Analyse der Code zunächst instrumentiert. Das heißt, es werden dem SUT automatisch spezielle Erweiterungen hinzugefügt, die gestatten, die durchlaufenen Quellcode-Zeilen zu rekonstruieren.
Auf die Weise wird die Code-Coverage der Systemtests beim Ausführen »vermessen«. Wenn sich der zu prüfende Code ändert, sind die »Impacted Tests« mithilfe der Messungen zu ermitteln. Es sind jene, die von der Änderung betroffene Code-Teile durchlaufen. Genauer gesagt durchliefen – denn die Vermessung ist mit dem letzten Ändern nicht mehr aktuell.
Die Ausführungen gemäß einer Test-Impact-Analyse zu reihen ist ein gutes Konzept. Es gibt jedoch Arten von Softwareänderungen, bei der das Vorgehen nicht funktioniert:
- Daten/Konfigurations-Änderungen
- Änderungen des Software-Builds
Zudem gibt es Systeme, für die das Verfahren schlecht oder gar nicht anwendbar ist:
- Wenn das SUT aus vielen Executables besteht – also in Form von Micro Services implementiert ist oder ein verteiltes System ist.
- Für eingebettete (Echtzeit-)Systeme, bei denen Code-Instrumentierung unmöglich ist, lässt sich die Technik nur mit erheblichen Schwierigkeiten einsetzen.
- Das Konzept ist nicht einfach beim Verwenden von Hardware-Beschreibungssprachen anwendbar. Wer FPGAs verwendet, muss sich also nach einer alternativen Anwendung umsehen.
Das SUT des Wiener Teams ist ein verteiltes Echtzeitsystem mit FPGAs. An eine Out-of-the-box-Verwendung eines Werkzeugs zur Test-Impact-Analyse ist nicht zu denken.
Jobangebote+ passend zum Thema
Näherungsverfahren
Eine Stärke der Test-Impact-Analyse ist, die Impacted-Tests mit der Vermessung dieser und der Analyse der Code-Änderungen zu ermitteln und eine optimale Reihung vorzuschlagen. Zum Beispiel ist das eine Reihung gemäß Abdeckung von neuem Code dividiert durch die Laufzeit. Ein Entwickler kann sich der optimalen Reihung jedoch genauso mithilfe von Statistiken nähern und folgenden Tests höhere Priorität als anderen geben:
- Tests, die erst seit kurzem existieren. Sie prüfen vermutlich neue Features und somit neuen Code.
- Tests, die in der jüngsten Vergangenheit fehlschlugen. Aufgedeckte Bugs könnten ausgebessert sein. Sie sind für den Regressionstest heiße Kandidaten, denn es wird eventuell veränderter Code durchlaufen.
- Tests, die immer schon erfolgreicher als andere beim Aufdecken von Bugs waren [3].
Mit den genannten Mitteln ist die Reihung effektiver als eine reine Zufallsreihung. Jedoch erlauben die zuvor erwähnten Rahmenbedingungen weitere Ideen zu implementieren. Idee Nummer eins ist das Zuordnen von Quellcode des SUT zu Systemprüfungen auf Basis von mit dem Bug Tracker gesammelten Daten.
Wie erwähnt, und in Bild 1 beispielhaft zu sehen, lässt sich eine moderne Quellcode-Verwaltung mit dem Bug Tracker integrieren. Es besteht also eine Verbindung vom Bug Ticket, das den Fix getriggert hat, zum Quellcode, wo der Fix implementiert wurde. Im Bug Ticket steht jedoch die ID des Tests, der den Bug aufgedeckt hat. Somit hat das Team aus dem Bug Tracker unzählige Verknüpfungen von Prüfungen zum Code gesammelt, ganz ohne Instrumentierung, siehe Bild 2. Die große Datenmenge (es waren viele Bugs) versetzt das Team in eine ähnlich günstige Lage, wie sie die Vermessung der Test-Impact-Analyse erlaubt. Über eine Programmierschnittstelle kann das System von der Versionsverwaltung die letzten Code-Änderungen abfragen. Aus der Liste der Verknüpfungen kann es dann jene Tests suchen, die in den geänderten Code-Blöcken schon einmal einen Bug aufgedeckt haben. Es sind Prüfungen, die bevorzugt laufen müssen.
Mit der Art des Ermittelns von Impacted Tests gibt es keine Garantie einer Vollständigkeit. Vorteilhaft ist jedoch, dass es ebenso für FPGA-Code sinnvoll anwendbar ist. Insgesamt kommen schon vier Kriterien parallel zum Einsatz, die beim Start der Umgebung statisch Prioritäten vergeben: das Alter des Tests, Fehlschläge in jüngster Vergangenheit, historisch erfolgreiche Tests und Prüfungen, die im gerade geänderten Code schon einmal einen Fehler fanden.
Auf Basis der Kriterien erhöht die Testumgebung beim Start eines nächtlichen Prüflaufs automatisch die Prioritätszahl. Prüfungen mit gleich hoher Priorität reiht die Umgebung zufällig. Ganz ausgereizt wurde das Potenzial der gesammelten Daten jedoch noch nicht. Ein wenig »Intelligenz« kann man der Reihung noch verleihen, indem der Anwender eine dynamische Komponente hinzufügt.
Re-Priorisieren zum Steigern der Effizienz
Riedel Communications prüft mehrere Varianten einer Produktfamilie. Wenn das Team nach einem nächtlichen Prüflauf einen gefundenen Fehler mit den Entwicklern durchspricht, ist oft eine der ersten Fragen der Entwickler, welche anderen Produktvarianten vom gleichen Problem betroffen sind. Vor dem Umsetzen der vorgestellten Idee hatte das Team nicht immer eine Antwort parat, denn die Prüfungen waren zufällig gereiht und es konnte durchaus sein, dass ein fehlgeschlagener Test lediglich für eine einzige Produktvariante über Nacht lief. Um besser aufgestellt zu sein, hat das Team nach Impulsen in wissenschaftlicher Literatur gesucht.
In [3] wird beschrieben, dass ein Prüfsystem auf Basis eines Testurteils die verbleibenden, noch nicht ausgeführten Tests, neu reiht. Es werden Korrelationen der Ergebnisse dafür herangezogen um beim Ergebnis »Failed« mit hoher Wahrscheinlichkeit einen neuen Test zu wählen, der ebenfalls fehlschlägt, siehe Tabelle 1. Die Motivation der entsprechenden akademischen Publikationen ist es jedoch nicht, automatisiert bessere Daten für eine sinnvolles Bewerten eines Bugs zu liefern – die Autoren wollen bessere Werte für APDF erreichen (und waren mit ihrer Strategie erfolgreich). Für beide Ziele ist der Weg jedoch gleich: Schlägt eine Prüfung fehl, sollte man anderen Tests (dynamisch) eine höhere Priorität geben, die aufgrund dieses Fehlschlags voraussichtlich ebenso eher fehlschlagen.
Bei einem Testfehlschlag für eine Produktvariante A, macht es Sinn, den gleichen Test für eine andere Produktvariante laufen zu lassen oder zumindest einen möglichst ähnlichen. Um diesbezüglich eine »intelligente« Auswahl zu treffen, muss ein Testsystem die Ähnlichkeit von Tests feststellen können. Demnach muss man sich nicht auf die Korrelation historischer Testergebnisse, wie in Tabelle 1 gezeigt, verlassen, sondern mit handfesten Daten arbeiten. Mit sogenannten Similarity-Metriken kann die textuelle Beschreibung, der Quellcode sowie der durchlaufende Code von Tests verglichen werden. Allerdings sind die dabei zu vergleichende Strings sehr lang und die in der wissenschaftlichen Literatur für solche Vergleiche verwendeten Metriken sehr komplex. Die Berechnungen können daher sehr zeitaufwendig werden und sind für den industriellen Einsatz manchmal nicht praktikabel [4]. Doch das Implementieren eines schnellen Testvergleichs für eingebettete Systeme ist oft einfacher als gedacht.
- 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
