 |
| Hardware- und Softwarestruktur des entwickelten Testkonzepts |
Im Zuge stetig steigender Komplexität mechatronischer Produkte gewinnt der Applikationstest weiter an Bedeutung. In der industriellen Praxis erfolgt dieser meist automatisiert mit Hilfe programmierbarer Testautomaten. Die Gründe liegen vornehmlich in der hohen Zahl durchzuführender Testfälle (oft mehrere Hundert bis mehrere Tausend), in der Notwendigkeit zur Einhaltung von Echtzeitbedingungen sowie im wiederkehrenden Testbedarf nach Änderungen. Test-Suiten blicken häufig auf eine über Jahre von Variante zu Variante gewachsene Historie und stellen einen wertvollen Erfahrungsschatz der Unternehmen dar. Inzwischen droht jedoch der Aufwand der Erstellung, Verwaltung sowie Wartung der Testskripte unakzeptabel hoch zu werden. Testfallimplementierungen bzw. -Anpassungen müssen auf Testskriptebene erfolgen. Komplexe Zusammenhänge wie parallele Abläufe oder Abhängigkeiten über Testfälle hinweg sind auf dieser Ebene jedoch nur erschwert nachvollziehbar. Die Darstellungsform Testskript verschleiert tendenziell die einzelnen Testziele aus Applikationssicht. Mit der erschwerten Verständlichkeit leidet auch die Wiederverwendung existierender Testskripte. Die Beherrschbarkeit der Testkomplexität und darauf aufbauend die Begrenzung der zu leistenden Aufwände gestaltet sich zunehmend kritisch. Ergebnisse: Die Nutzung einer leicht verständlichen, grafischen Testspezifikationssprache sowie die damit verbundene Stärkung der implementierungsunabhängigen Testfallspezifikationsphase kann einen Ausweg aus der skizzierten Problematik zeigen. Vor diesem Hintergrund wird am Lehrstuhl für Informationstechnik im Maschinenwesen an der Definition einer derartigen Testspezifikationssprache gearbeitet. Ziel ist, Implementierungsdetails möglichst zu verdecken, jedoch Struktur und Ablauf der Test-Suite sowie die einzelnen Testfallspezifi- kationen möglichst anwendergerecht und transparent zu gestalten. Dennoch hat die Sprache so formal zu sein, dass automatisiert ein Testskript erzeugt werden kann. Der Vision nach werden Test-Suiten zukünftig in einem grafischen Editor spezifiziert. Unterschiedliche Sichten ermöglichen ein zielgerichtetes, verteiltes Arbeiten und machen die Testkomplexität besser beherrschbar. Auf oberstem Abstraktionsniveau werden Struktur und Ablauf der Testsuite spezifiziert. Einzelne Testfälle erscheinen als Blackbox. Sie werden erst eine Detaillierungsebene tiefer mittels Sequenzdiagrammen spezifiziert. Eine zentrale Datenhaltung parametrierbarer Testfälle vermeidet Redundanzen und erleichtert die Testfall-Wiederverwendung und -Wartung. Einzelne Testfunktionen erscheinen noch als Blackbox. Sie sind Betrachtungsgegenstand des nächst tieferen Abstraktionsniveaus und stellen die Verbindung zur Testbetttreiberebene des Testautomaten her. Derart spezifizierte Test-Suiten werden mit einem Testkonfigurator an das Testobjekt und das verwendete Testsystem adaptiert. Existierende Testskripte können eingebunden werden. Ein Testskriptgenerator führt alle Informationen zu einer auf dem Testautomaten ablauffähigen Testsuite zusammen. In Summe erlaubt das Konzept eine transparente und schrittweise Einführung im Unternehmen auf der Basis der existierenden Testinfrastruktur. Dies begrenzt das Einführungsrisiko, was insbesondere für KMU wichtig ist. Anwendungsreife: Zurzeit entsteht ein Prototyp zur Evaluierung der Tragfähigkeit der vorgestellten Ideen. Er soll ferner die Entwicklung individueller, auf die jeweiligen firmenspezifischen Bedürfnisse zugeschnittener Tools erleichtern. Die Definition offener Schnittstellen zwischen den einzelnen Softwarekomponenten auf Basis von XML ermöglicht zudem deren unabhängige Entwicklung sowie deren Ankopplung an eine bereits vorhandene Tool-Landschaft. Vollbeitrag als PDF |
| |
|
 |
|