Test - In mechatronischen Produkten werden Funktionalität und Flexibilität zu einem immer größeren Anteil durch die Software erbracht. Deshalb stellen sich neue Anforderungen an die Qualitätssicherung, insbesondere an den abschließenden Applikationstest.
In der industriellen Praxis erfolgt der Applikationstest am Ende einer Entwicklung zumeist mit Hilfe programmierbarer Testautomaten. Grund dafür ist die sehr hohe Zahl notwendiger Testfälle, die zudem nach einer Fehlerfindung in Form eines Regressionstests erneut vollständig durchzuführen sind. Nur so können unbeabsichtigte, aber bei Änderungen an eingebetteter Software stets drohende Wechselwirkungen und Seiteneffekte ausgeschlossen werden. Ein weiterer Grund liegt in der oftmals technischen Notwendigkeit eines Testautomaten bei kontinuierlichen Systemen. So wird z.B. beim Test des Anlaufverhaltens eines Antriebs eine echtzeitfähige Testumgebung benötigt. Ein händischer Test ist in diesem Fall nicht möglich. Auch ein testsystemabhängiges Testskript als Spezifikationsmittel ist ungeeignet: Für das Verständnis wäre neben dem eigentlichen Applikationswissen zusätzlich Expertenwissen über das verwendete Testsystem inklusive der angebundenen Komponenten erforderlich. Zudem ist ein Quelltext generell wenig als intuitiv begreifbares Spezifikationsmittel geeignet. Eine informale Testspezifikation ist, wegen des erheblichen Mehraufwandes, ebenfalls keine Lösung. Im Projekt TeCom (Testfallcompiler für den Funktionstest eingebetteter Systeme), am Lehrstuhl für Informationstechnik im Maschinenwesen an der Technischen Universität München, wird aus diesem Grund ein Ansatz verfolgt, der es ermöglicht, Testfälle grafisch intuitiv, aber dennoch formal zu spezifizieren.
Im Mittelpunkt der Spezifikation steht das Systemverhalten an den Schnittstellen des Produkts. Das verwendete Testsystem spielt dagegen keine Rolle. Dadurch wird die Testspezifikation kompakt, gut verständlich und gut wartbar. Dennoch können auf der Basis dieser Testspezifikation testsystemspezifische Erweiterungen vorgenommen werden, woraufhin ein auf dem verwendetem Testautomaten ablauffähiges Testprogramm automatisiert erzeugt werden kann. Damit sind die Hürden für eine frühzeitige Testspezifikation deutlich abgesenkt und die Vorteile werden nutzbar. Im Testeditor entwirft der Testdesigner während der Spezifikationsphase auf Basis seines Applikationswissens mit Hilfe einer flussdiagrammartigen Beschreibungssprache zunächst Architektur und Umfang der Testsuite. Damit sind alle weiteren Schritte vordefiniert und der Testaufwand abschätzbar. Die einzelnen Testfälle werden danach in Form von Sequenzdiagrammen detaillierter spezifiziert. Dabei wird die Abfolge von Stimulationen sowie der erwarteten Reaktionen angegeben. Auf Basis dieser nun vollständigen Testspezifikation können bereits automatisiert die ersten Testskripte erzeugt werden.
Diese Aufgabe übernimmt der Testskriptgenerator, der dazu auf den Sprachschatz der im Testsystem integrierten Skriptsprache ausgelegt sein muss. Dieses Testskript ist allein noch nicht ablauffähig, da die testsystemspezifische Umsetzung der einzelnen spezifizierten Stimulations- und Reaktionsfunktionen fehlt. Diese Aufgabe kann am besten von einem Testsystemexperten bewerkstelligt werden, der im Übrigen dazu kaum noch Wissen über die Systemspezifikation des zu testenden Produkts benötigt. Schließlich existieren bereits durch die Testspezifikation genaue Vorgaben. Damit kann alleinig die testsystemspezifische Umsetzung im Mittelpunkt stehen. Bei seiner Arbeit wird er durch einen Konfigurator unterstützt, der die Testspezifikation einliest, eine Aufgabenliste ableitet und das Versions- und Änderungsmanagement übernimmt. In Summe entsteht auf systematische und effiziente Weise ein vollständig ablauffähiges Testprogramm, das der Testspezifikation entspricht und diese mit den spezifischen Möglichkeiten des verwendeten Testsystems umsetzt.
Bernhard Kausler/Martin Pöschl,
TU München, itm
