Back-to-Back-Testing: Was ist das?
Der Back-to-Back-Test zählt, wie der Regressionstest, zu den dynamischen Software Testverfahren und bezeichnet eine Test-Ausführungsmethodik, bei der zwei Varianten einer Software miteinander verglichen werden. Dabei ist eine Variante der Prüfling und die andere Variante die Referenz. Die Referenz ist beim Back-to-Back-Testing die Grundlage für die automatisierte Bewertung, mit der entschieden wird, ob ein Testfall als erfolgreich oder fehlgeschlagen gilt.
Die Varianten dieser Ausführungsmethodik können in zwei Grundarten unterschieden werden:
- Änderungen an einer Software ohne Veränderung der Ausführungsplattform, z.B. C-Code wird mit neuen Funktionalitäten erweitert, Fehlerbehebungen werden durchgeführt (Bugfix) oder die Softwarestruktur wird umgebaut (Refactoring).
- Änderungen an einer Software für eine Veränderung der Ausführungsplattform – in den meisten Fällen werden dabei neue Dateien erzeugt, z.B. bei der Übersetzung eines Simulink oder Targetlink Models in C-Code mittels automatischer Codegenerierung oder Kompilierung von C-Code für eine Zielprozessor-Architektur.
Das grundsätzliche Ziel eines Back-to-Back Tests ist, die Auswirkungen der Softwareänderungen erkennen zu können. Dabei wird das Verhalten einer geänderten Software gegen eine andere Variante der Software verglichen, um Fehler bei der Implementierung oder Generierung aufzudecken.
Empfehlung zur Auswahl von Referenzen beim Back-to-Back Testing
Es ist sehr wichtig, dass eine Referenz im Back-to-Back Testing vertrauenswürdig ist, weil sie die Quelle der Wahrheit ist und damit die Grundlage für alle Bewertungen des Testlaufs beim Back-to-Back-Test. Das Vertrauen kann durch Tests, Reviews, Erprobung oder in manchen Ausnahmefällen auch durch Erfahrung und Monitoring im produktiven Umfeld („proven-in-use“ Ansatz) hergestellt werden.
Ein erfolgreicher Back-to-Back-Test bedeutet Gleichheit zwischen den Varianten einer Software.
Eine Aussagekraft hinsichtlich der Compliance zu Anforderungen und Funktionalität ist nur gegeben, wenn diese Aussage bereits für die Referenz gilt und ein Back-to-Back-Test mit einer vollständigen Stimulation durchgeführt wurde. Eine unzureichende Stimulation kann dazu führen, dass Fehler oder versteckte Funktionalitäten in der Referenz oder im Prüfling nicht entdeckt werden.
Wir empfehlen daher beim Back-to-Back-Test die Codeabdeckung sowohl für die Referenz, als auch für den Prüfling zu messen.
Die Modified Condition Decision Coverage (MC/DC) ist eine der striktesten Codeabdeckungsmetriken und somit sehr gut für den Back-to-Back-Test geeignet. Eine ausreichende Abdeckung ist mit einem Wert von 100% MC/DC annehmbar.
Für die Erreichung der 100% Code Abdeckung (MC/DC) noch nicht vorhandenen Testfälle können für einen Back-to-Back-Test auch auf beliebige Art generiert werden. Die Testfälle müssen keine inhaltliche Aussagekraft in Bezug auf Anforderungen oder Funktionalität besitzen, da der Erwartungswert durch die Referenz vorgegeben wird.
Typische Anwendungsbereiche von Back-to-Back-Test sind:
- Vergleich von Modell (MiL) und Software-Code (SiL): Prüfung, ob eine Software das gleiche Verhalten wie das Modell aufweist. Konkrete Beispiele sind:
-
- Simulink Modell vs. Autosar SW-Komponente (Watch the video)
- Targetlink Modell vs. generierte Software
-
- Modelle vs. Handcodierte Software
- Vergleich von Modell (MiL) und Target Software (PiL): Prüfung, ob die Software auf Zielarchitektur und Prozessor das gleiche Verhalten wie das Modell aufweist
- Vergleich von Software (SiL) und Target Software (PiL): Prüfung, ob die Software auf der Zielarchitektur und Prozessor das gleiche Verhalten wie die Software auf dem Host aufweist
- Vergleich von Software in verschiedenen Versionen: Prüfung, ob eine Version das gleiche Verhalten wie eine Vorgängerversion aufweist (Test von Refactoring Maßnahmen)
- Vergleich in Bezug auf einen Referenz-Testlauf (MiL/SiL): Prüfung, ob das Verhalten einem geprüften Testlauf entspricht, z.B. bei komplexen Regelkreisen
Forderung der Nutzung von Back-to-Back-Tests in Standards/Normen:
Die international gültige Sicherheitsnorm im Automobilbereich, ISO 26262, empfiehlt die Anwendung des Back-to-Back-Tests für hoch sicherheitskritische Funktionen, wie ASIL C und ASIL D, bei der Software unit verification und verification of software integration zwischen Code und Modellen.
Wie ist Back-to-Back-Testing in TPT möglich?
Ein Back-to-Back-Test ist in TPT sehr einfach aufgesetzt. Er kann mit wenigen Handgriffen ausgeführt werden. Die Methodik steht für alle Ebenen (Unit-Test, Integrationstest bis zur Produktebene) und Plattformen zur Verfügung. Die Testfälle können aus vorherigen Tests auch im Back-to-Back-Testing wiederverwendet oder auf Knopfdruck mit unserem Testgenerator erstellt werden. Über unsere Co-Simulationsplattform FUSION können beliebige Anbindungen selbstständig und einfach angebunden.
Wie ein Back-to-Back-Test in TPT from scratch aufgesetzt wird, können Sie in unserem Video Back-to-Back-Testing von AUTOSAR vs. MATLAB Modell nachvollziehen.
Nach der Testausführung wird automatisch ein Testreport erstellt. Dieser beinhaltet:
- alle Signalverläufe aller Ein- und Ausgänge Ihres Prüflings, sowie alle Messwerte
- Hilfssignale für eine einfachere Analyse von Abweichungen
- Eine Bewertung des Verhaltens Ihres Prüflings anhand aller Signale mit konfigurierbaren Toleranzen
Alle Testdurchführungsergebnisse werden in TPT gespeichert. So kann das Verhalten jederzeit im Signal Viewer von TPT analysiert und nachvollzogen werden.
Ein Testfall gilt immer dann als erfolgreich, wenn das Verhalten des Prüflings gegenüber der Referenz im Rahmen der Toleranzen für bestimmte Ein- und Ausgänge identisch ist.
Die Toleranzen von Signalen können für eine Testausführung global festgelegt werden. Das ist sinnvoll, wenn z.B. Abweichungen bei Fließkommazahlen Berechnungen erwartet werden.
