Autoren: Ralf Gerlich, Rainer Gerlich, Dr. Rainer Gerlich BSSE System and Software Engineering<\/p>\n
Manuelle\u00a0Anforderungstests<\/em>\u00a0sind aufw\u00e4ndig: Die Eingabedaten m\u00fcssen die Anforderungen abdecken, und beobachtete Ausgabedaten m\u00fcssen auf ihre Kompatibilit\u00e4t mit den Anforderungen gepr\u00fcft werden. Testf\u00e4lle k\u00f6nnen auch automatisch aus Testmodellen erzeugt werden, die aber zun\u00e4chst manuell erstellt werden m\u00fcssen. Im Kontrast dazu nutzt der hier vorgestellte Ansatz einfachere Formen der Anforderungs\u00adformalisierung, um die Testdaten, die bei automatischen\u00a0Robustheitstests<\/em>\u00a0mit\u00a0massiver Stimulation<\/em>\u00a0erzeugt werden, auf Anforderungen abzubilden und die Ergebnisse auf Korrektheit zu pr\u00fcfen.<\/strong><\/p>\n Bild 1 (siehe\u00a0PDF<\/a>) zeigt die klassische Vorgehensweise der Verifikation von Anforderungen durch Funktionstests (Unit Tests) und manuell erstellte Testf\u00e4lle. Auf der Basis von Anforderungen wird Quellcode erstellt und manuell eine Beziehung zwischen Anforderungen und Funktionen hergestellt. Aus den Anforderungen werden Testf\u00e4lle f\u00fcr den Funktionstest abgeleitet. Eingabedaten und erwartete Ergebnisse werden in Testscripts \u00fcberf\u00fchrt, die den Test ausf\u00fchren und ihn als erfolgreich oder nicht (pass\/fail) bewerten.<\/p>\n In den letzten Jahren wurden verschiedene Ans\u00e4tze entwickelt, aus Modellen Anforderungstests abzuleiten. Dazu wird das gew\u00fcnschte Verhalten modelliert und mit Annotationen zur Bestimmung der Anforderungsabdeckung und der Pr\u00fcfung der Anforderungserf\u00fcllung versehen[1]. Durch Random Walks oder \u00e4hnliche Verfahren werden dann Testsequenzen- und -daten aus diesen Modellen abgeleitet und manuell oder automatisch in Testskripte \u00fcberf\u00fchrt.<\/p>\n Ein Spezifikationsmodell, das mit wenig Ver\u00e4nderung als Testmodell f\u00fcr eine solche Methode verwendet werden kann, ist ideal bei dieser Vorgehensweise. Ist dies nicht der Fall, muss zun\u00e4chst ein solches Modell erstellt und mit der Spezifikation – die meistens nur in Textform vorliegt \u2013 manuell abgeglichen werden.<\/p>\n Automatisierte Robustheitstests \u2013 gelegentlich auch unter dem Begriff „Fuzzing“ zusammengefasst \u2013 werden verwendet, um die Robustheit einer Komponente gegen unerw\u00fcnschte Eingaben zu pr\u00fcfen[2]. Dazu wird eine Komponente etwa mit Zufallsdaten stimuliert, wobei auf Anomalien bei der Ausf\u00fchrung geachtet wird. So k\u00f6nnen teilweise auch funktionale Schwachstellen in der Komponente identifiziert werden. Die einfache Art der Testdatenerzeugung erm\u00f6glicht dabei einen gro\u00dfen Testdurchsatz \u2013 eine\u00a0massive<\/em>\u00a0Stimulation.<\/p>\n Aus den Ergebnissen dieser Tests lassen sich jedoch keine Aussagen \u00fcber Anforderungs\u00aderf\u00fcllung oder -abdeckung ableiten. Eine Abbildung der Testeingaben auf die Anforderungen fehlt.<\/p>\n Ziel des automatischen anforderungsbasierten Testen auf Codeebene ist es, eine Korrelation zwischen Anforderungen und Testf\u00e4llen automatisiert herzustellen, und zugleich zu bestimmen, welche der Funktionen im Code jeweils durch welche Anforderung betroffen sind. Die Testdaten sollen automatisch erzeugt und angewendet werden, so dass sich der manuelle Aufwand drastisch reduziert.<\/p>\n Der gew\u00e4hlte Ansatz verwendet dabei drei Abbildungen[3]:<\/p>\n Dieses Prinzip ist in Bild 2 (siehe\u00a0PDF<\/a>) dargestellt. Maschinenlesbare Anforderungen werden in den Funktionstest integriert und w\u00e4hrend der massiven Stimulation ausgewertet. Somit ist es m\u00f6glich, sowohl die Anforderungsabdeckung als auch die Erf\u00fcllung der Anforderungen f\u00fcr die ausgef\u00fchrten Testf\u00e4lle zu bestimmen. Bei Nichterf\u00fcllung beschreibt der zugeh\u00f6rige Testvektor aus Eingabe- und Ausgabedaten ein Gegenbeispiel.<\/p>\n Letzteres geschieht \u00fcber Orakel. Ein Orakel ist eine ausf\u00fchrbare Funktion, die f\u00fcr eine Eingabe und eine beobachtete Ausgabe ein\u00a0pass\/fail\/don\u2019t know<\/em>-Verdict erzeugt. Dabei ist es m\u00f6glich, dass einzelne Orakel nur Entscheidungen f\u00fcr bestimmte echte Untermengen des Eingaberaums treffen. Idealerweise decken die Orakel gemeinsam aber den gesamten Eingaberaum ab.<\/p>\n Bild 3 (siehe\u00a0PDF<\/a>) zeigt weitere Details des automatischen Ablaufs. Durch die massive Stimulation wird der Eingaberaum \u00fcber eine vorgebbare Anzahl von Testvektoren abgetastet. Auf jeden Testvektor wird das Orakel angewendet und das Ergebnis festgehalten. Auf diese Weise k\u00f6nnen Gegenbeispiele gefunden werden.<\/p>\n Zwischen Anforderungen und Funktionen besteht allgemein eine n:m-Beziehung. So k\u00f6nnen bestimmte Anforderungen, z.B. zur Rechengenauigkeit, auf mehrere Funktionen anzuwenden sein. Ebenso kann eine Funktion mehrere Anforderungen implementieren.<\/p>\n Um die Anforderungen und Funktionen einander zuzuordnen, m\u00fcssen die betroffenen Elemente \u2013 Datenobjekte, Strukturen, Parameter \u2013 aus dem Text der Anforderung extrahiert und ihren Entsprechungen im Code zugeordnet werden. Dies kann durch Namensregeln geschehen, die Namen aus den Anforderungen in Namen im Code \u00fcbersetzen oder direkt verwenden. So kann \u00fcber die Beziehungen Orakel-Anforderung und Anforderung-Funktion eine Zuordnung von Orakeln zu den Funktionen erfolgen, auf die sie angewendet werden m\u00fcssen. Eine aufw\u00e4ndige manuelle Zuordnung kann so vermieden werden.<\/p>\n In Bild 4 (siehe\u00a0PDF<\/a>) wird der logische Fluss im Kontext hierarchischer Anforderungen dargestellt. Top-down werden die Anforderungen detailliert bis zu einer Ebene, auf der sie schlie\u00dflich in Code umgesetzt werden k\u00f6nnen. Erst auf dieser Ebene ist es sinnvoll, Orakel zu definieren. Anforderungen auf h\u00f6heren Abstraktionsebenen sind \u00fcblicherweise nicht f\u00fcr die Verifikation durch Code-Level-Tests bzw. Unit Tests geeignet.<\/p>\n F\u00fcr jede Funktion wird automatisch eine Testumgebung erstellt, \u00fcber die die Funktion dann mit Daten aus dem Wertebereich der Funktionsparameter \u2013 inklusive globaler Variablen \u2013 stimuliert wird[2]. Dabei werden auch Spezialf\u00e4lle wie z.B. -1 oder 0 f\u00fcr Ganzzahlparameter ber\u00fccksichtigt. Auch andere Verfahren zur gezielten Abdeckung bestimmter Programmteile werden eingesetzt. Au\u00dferdem k\u00f6nnen invalide Werte eingespeist und Teile des Codes gezielt erg\u00e4nzt werden, etwa um Speichermangel u.\u00e4. zu simulieren.<\/p>\n Aus dem so betrachteten massiven Satz an Testeingaben und beobachteten Ausgaben werden interessante F\u00e4lle f\u00fcr die Erzeugung von Regressionstestsuites ausgew\u00e4hlt. Dies sind Eingaben, die zur Abdeckung beitragen, Ausnahmebedingungen ausl\u00f6sen oder die Vorgaben eines Orakels erf\u00fcllen oder verletzen. Diese Suites k\u00f6nnen dann auch mit externen Testmanagementwerkzeugen \u2013 z.B. Cantata oder VectorCAST \u2013 erneut ausgef\u00fchrt und ihre Ergebnisse ausgewertet werden.<\/p>\n Weitere Analysen sind m\u00f6glich: Eingabedaten, die zwar Code abdecken, aber keiner Anforderung bzw. Orakel zugeordnet werden k\u00f6nnen, deuten auf fehlende Anforderungen oder unn\u00f6tigen Code hin. Wird f\u00fcr ein Orakel niemals die Vorbedingung im Eingaberaum aller zu testenden Funktionen erf\u00fcllt, handelt es sich um eine nicht abgedeckte Anforderung.<\/p>\n Die Orakel in diesem Ansatz werden als temporale Implikationsbeziehungen dargestellt:\u00a0Wenn<\/em>\u00a0vor dem Aufruf Bedingung A f\u00fcr die Eingabe gilt,\u00a0dann<\/em>\u00a0muss nach dem Aufruf Bedingung B f\u00fcr Ein- und Ausgabe gelten (Bild 5, siehe\u00a0PDF<\/a>). Ist Bedingung A nicht erf\u00fcllt, wird Bedingung B nicht ausgewertet und das Orakel liefert ein\u00a0don\u2019t know<\/em>\u00a0als Ergebnis.<\/p>\n Es ist in dieser Struktur auch m\u00f6glich, eine Tautologie \u2013 also einen immer wahren Ausdruck \u2013 als Vorbedingung zu nutzen. In diesem Fall muss die Bedingung B f\u00fcr jeden Testvektor erf\u00fcllt sein. Beispielsweise k\u00f6nnen so Anforderungen \u00fcber Wertebereichsbeschr\u00e4nkungen der Ergebnisse umgesetzt werden.<\/p>\n \u00dcber bekannte Abh\u00e4ngigkeiten zwischen den Anforderungen kann das Ergebnis zu den Anforderungen auf h\u00f6herer Ebene \u00fcbertragen werden. Auf jeder Ebene kann somit festgestellt werden, welche Funktionen zu einem positiven oder negativen Ergebnis beitragen.<\/p>\n Die Verifikation \u00fcber massive Stimulation basiert auf zwar sehr vielen, aber doch endlich vielen Testvektoren, d.h. eine vollst\u00e4ndige Analyse des Zustandsraumes ist in der Regel nicht m\u00f6glich. Jedoch \u00fcbersteigt die Zahl der automatisch erzeugten Stimuli bei weitem die Zahl der manuell erzeugbaren F\u00e4lle, was insbesondere f\u00fcr das Finden von Gegenbeispielen relevant ist.<\/p>\n Siehe\u00a0\u00a0PDF<\/a>.<\/p>\n Momentan werden die meisten Anforderungen als Freitext beschrieben, der nicht maschinell auswertbar ist. Eine Analyse solcher Anforderungen ergab, dass sie h\u00e4ufig unvollst\u00e4ndig, nicht eindeutig oder inkonsistent und somit f\u00fcr dieses Verfahren ungeeignet sind. Bei der manuellen Verifikation m\u00fcssen diese Schw\u00e4chen dann durch Kreativit\u00e4t ausgeglichen werden.<\/p>\n Voraussetzung ist daher die Anwendung einer geeigneten Notation. Diese kann auch ein f\u00fcr den Anwender besser geeignetes Format als die Orakel-Form haben. Sie muss sich aber \u2013 automatisch \u2013 in die Orakel-Notation \u00fcberf\u00fchren lassen.<\/p>\n Anforderungen, die bereits in einem formalisierten Tabellenformat vorliegen, sind daf\u00fcr gut geeignet.<\/p>\n Wie jeder Code unterliegen auch Orakel der Qualit\u00e4tssicherung. Fehler in den Orakeln k\u00f6nnen sonst dazu f\u00fchren, dass Fehler in der Software \u00fcbersehen werden. Da ein Orakel auf gro\u00dfe Untermengen der Eingabemenge angewendet werden kann, ist es sogar m\u00f6glich, dass Fehler mit gro\u00dfen Auswirkungen nicht erkannt werden, wenn das Orakel nicht korrekt ist. Dieses Risiko besteht aber auch bei der manuellen Erstellung von Testscripts oder Testcode. Dagegen k\u00f6nnen bei der automatischen Extraktion von Orakeln Ma\u00dfnahmen zur Fehlervermeidung eingesetzt werden.<\/p>\n Da keine maschinen-lesbaren Anforderungen vorlagen, basiert die aktuelle Implementierung auf manuell in C-Code implementierten Orakeln, um die Machbarkeit und die Vorteile zu demonstrieren.<\/p>\n In zuk\u00fcnftigen Arbeiten soll eine abstraktere, aber f\u00fcr Anwender akzeptable Notation identifiziert werden. Dazu sollen textbasierte Anforderungen analysiert und in eine geeignete Notation umgesetzt werden, die automatisch in Orakel \u00fcbersetzt werden kann. Dazu ist der enge Kontakt mit Anwendern erforderlich.<\/p>\n Der Inhalt dieses Beitrags ist ein Ergebnis des Projektes \u201cAutomated Source-code-based Testing, Continued\u201d f\u00fcr die European Space Agency (ESA) (ESA Contract No. 4000116014) im Rahmen des General Support Technology Programme (GSTP). Das Budget wurde vom Bundesministerium f\u00fcr Wirtschaft und Energie (BMWi) \u00fcber das Raumfahrtmanagement des Deutschen Zentrum f\u00fcr Luft- und Raumfahrt bereitgestellt. Wir danken unserem Technical Officer, Maria Hernek (ESA), f\u00fcr ihre Unterst\u00fctzung unserer Arbeiten und der Anregung, die massive Stimulation f\u00fcr anforderungsbasiertes Testen einzusetzen.<\/p>\n [1]\u00a0 H.-J. Herpel, G. Willich, J. Li, J. Xie, B. Johansen, K. Kvinnesland, S. Krueger, P. Barrios: \u201cMATTS \u2013 A step towards Model Based Testing\u201d, Eurospace Symposium DASIA\u20192016 \u201cData Systems in Aerospace\u201d, Mai 10-12, 2016, Tallinn, Estland<\/p>\n [2]\u00a0 R. Gerlich, R. Gerlich, M. Prochazka, K. Kvinnesland, B. Johansen: \u201cA Case Study on Automated Source-Code-Based Testing Methods\u201d, Eurospace Symposium DASIA\u20192013 \u201cDAta Systems in Aerospace\u201d, Mai 14-16, 2013, Porto, Portugal<\/p>\n [3]\u00a0 R. Gerlich, R. Gerlich, M. Hernek, J. Ramachandran, A. Pascoe, G. Johnson: \u201cChallenges Regarding Automation of Requirements-based Testing\u201d, Eurospace Symposium DASIA\u20192017 \u201cDAta Systems in Aerospace\u201d, Mai 30 \u2013 Juni 1, 2017, G\u00f6teborg, Schweden<\/p>\n Dr. rer. nat. Dipl.-Inf. Ralf Gerlich<\/strong>\u00a0begann vor 20 Jahren mit der professionellen Softwareentwicklung im Raumfahrtumfeld, zun\u00e4chst mit Schwerpunkt Systemprogrammierung. Inzwischen besch\u00e4ftigt er sich haupts\u00e4chlich mit Methoden der Softwareverifikation in allen Ebenen der Softwareentwicklung (konstruktiv, organisatorisch und analytisch), sowohl manuell als auch werkzeuggest\u00fctzt und vollautomatisch. Dabei gilt sein Interesse sowohl der theoretisch-mathematischen als auch der praktisch-pragmatischen Seite. Er ist seit Gr\u00fcndung der Firma Mitarbeiter bei „BSSE System and Software Engineering“.<\/p>\n Dr. rer. nat. Dipl.-Phys. Rainer Gerlich<\/strong>\u00a0verf\u00fcgt \u00fcber mehr als 35-j\u00e4hrige Erfahrung im industriellen Software Engineering, davon mehr als 30 Jahre in der Raumfahrt, mit Schwerpunkten in den Bereichen Automation im Software-Lifecycle, Requirements Engineering, Verifikation, automatisches Testen, Embedded Systems, sicherheitskritische Anwendungen, Projektmanagement, Werkzeugentwicklung. Seit 1996 ist er Inhaber von \u201eBSSE System and Software Engineering.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nStatus der Verifikation von Anforderungen durch Funktionstests<\/h2>\n
Modellgetriebene Ans\u00e4tze f\u00fcr Anforderungstests<\/h2>\n
Automatisierte Robustheitstests<\/h2>\n
Automatisiertes anforderungsbasiertes Testen<\/h2>\n
\n
Massive Stimulierung und Ableitung von Testvektoren<\/h2>\n
Der Orakel-Ansatz<\/h2>\n
Beispiele<\/h2>\n
Notation der Anforderungen<\/h2>\n
Qualit\u00e4tssicherung der Orakel<\/h2>\n
Ausblick<\/h2>\n
Danksagung<\/h2>\n
Literatur und Quellenverzeichnis<\/h2>\n
Autoren<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n