Analyse der Anwendungsmöglichkeiten von Testautomatisierung

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name des Autors / der Autoren: Die Guten
Titel der Arbeit: "Analyse der Anwendungsmöglichkeiten von Testautomatisierung"
Hochschule und Studienort: FOM Hamburg


Inhaltsverzeichnis



1 Einleitung

Fehler?! Fehler machen nur andere …
Wer gibt schon gerne zu, dass er Fehler macht? Fehler kosten Zeit, Geld und meistens bleibt am Ende ein unzufriedener Kunde auf der Strecke. Helfen kann nur vorheriges testen, jeder sollte es tun, doch kaum jemand macht es, aus Zeitdruck, Unwissenheit, um Kosten zu sparen oder einfach aus Ignoranz. Um dem entgegenzuwirken werden heutzutage immer mehr Produkte automatisiert getestet, was einen wachsenden Markt nach Testautomatisierung mit sich bringt. Doch was genau bedeutet automatisiert testen und welche Anwendungsmöglichkeiten gibt es im Bereich der automatisierten Tests?

Mit diesem Thema befasst sich diese Fallstudie, die an der Fachhochschule für Ökonomie und Management im Rahmen des Studiums zum Dipl. Wirtschaftsinformatiker entsteht.

Es wird auf das Thema Testen im Allgemeinen eingegangen, auf die generelle Erforderlichkeit und dem fundamentalem Testprozess. Verschiedene Testarten werden vorgestellt und es wird erläutert, was Testautomatisierung bedeutet. Betrachtet werden die verschiedenen Einsatzmöglichkeiten der Testautomatisierung in den Bereichen von Hardware und Software, wobei hier der Schwerpunkt auf dem Bereich der Software liegt.

2 Grundlagen

2.1 Test

2.1.1 Definition

Das Wort Test kommt aus dem Englischen und bedeutet übersetzt so viel wie Probe, oder Kontrolle.[1] Mittlerweile ist dieser Begriff aber in den deutschen Sprachgebrauch über gegangen. Der Begriff Test hat viele unterschiedliche Bedeutungen, sowohl im alltäglichen als auch im wissenschaftlichen Sprachgebrauch.
In der Psychologie beispielsweise kann es ein Verfahren zur Untersuchung verschiedener Persönlichkeitsmerkmale sein, der Vorgang selbst, der eine Untersuchung durchführt, oder auch ein mathematisch-statistisches Prüfverfahren.[2]
Die Sportmotorik definiert den Begriff Test als wissenschaftliche Untersuchungs- und Kontrollmethode, welche durch Lösen sportlicher Bewegungsaufgaben unter standardisierten Bedingungen charakteristische Bewegungsparameter erfragt, die dann als Indikatoren für sportmotorische Fähigkeiten und Fertigkeiten dienen.[3]
Im Bereich der Informatik werden beispielsweise im Rahmen der Softwareentwicklung Softwaretests durchgeführt, welche in der IEEE 829 Standard for Software and System Test Documentation genauer spezifiziert werden. Auf Softwaretests wird später im Abschnitt 5.1 näher eingegangen.

Eine allgemeingültige Definition für einen Test ist folgende: „Ein Test ist ein wissenschaftliches Routineverfahren zur Untersuchung eines oder mehrerer empirisch abgrenzbarer Merkmale mit dem Ziel einer möglichst quantitativen Aussage über den relativen Grad der individuellen Merkmalsausprägung.“[4]


2.1.2 Erforderlichkeit

Aus betriebswirtschaftlicher Sicht sind Tests von Bedeutung, da jedes Unternehmen eine gute Qualität seiner Produkte gewährleisten möchte. Ein entsprechender Aufgabenbereich in einem Unternehmen das beispielsweise Software entwickelt oder diese modifiziert ist, dass diese adäquat getestet wird.
Durch das Testen der Software wird erreicht, dass die Fehlerquote im Produkt minimiert wird, dadurch die Kunden weniger reklamieren und die Kundenzufriedenheit steigt. Ein zufriedener Kunde wird gerne wieder bei solch einer Firma Aufträge einreichen, wodurch eine Kundenbindung erreicht wird. Es besteht auch die Möglichkeit, dass ein zufriedener Kunde seine positiven Erfahrungen an andere weiterträgt und so neue Kunden gewonnen werden können und die Marktanteile vergrößert werden[5], wodurch am Ende auch der Umsatz gesteigert werden kann.

Aber nicht nur die Kunden spielen dabei eine Rolle, ein anderer wichtiger Aspekt sind die Kosten. Wenn Fehler korrigiert werden müssen kostet dieses Zeit. Der Fehler muss gefunden werden, eine neue Lösung entworfen und abschließend die Korrektur vorgenommen werden.[6] Das alles ist Arbeitszeit, die bezahlt werden muss und die auch in andere Projekte investiert werden kann.

Daraus lässt sich ein weiterer Aspekt ableiten, die eigene Mitarbeiterzufriedenheit. Wenn Mitarbeiter nicht immer wieder nachbessern müssen, kann man davon ausgehen, dass sie zufriedener sind, weil sie sich neuen Aufgaben widmen können und die Zeit bekommen, um gezielt auf Kundenwünsche und deren Bedürfnisse einzugehen.[7]


2.1.3 Fundamentaler Testprozess

Die Testdurchführung selbst ist nur der grundlegendste Teil des Testens. Der fundamentale Testprozess ist zyklisch und berücksichtigt auch die weiteren Schritte, die zum erfolgreichen Testen gehören. Der Prozess ist in der Abbildung 1 dargestellt und im Einzelnen sind die Phasen:[8]


  • Testplanung und Steuerung
  • Testanalyse und Testdesign
  • Testrealisierung und Testdurchführung
  • Testauswertung und Bericht
  • Abschluss der Testaktivitäten


Im Rahmen der Testplanung werden die Ziele des eigentlichen Testes geplant, der Umfang und eventuelle Risiken definiert, es wird eine Testmethode und eine Teststrategie festgelegt. Zu den Aufgaben in dieser Phase gehört es auch, dass der Testfortschritt dokumentiert wird und beispielsweise Korrekturmaßnahmen eingeleitet werden müssen.[9]

In der zweiten Phase, der Testanalyse, detailliert man die Testziele in konkrete Testbedingungen. Es werden die benötigten Testdaten ermittelt, ein konkreter Testentwurf entwickelt, und die benötigte Infrastruktur, sowie die später im Test zu nutzenden Werkzeuge analysiert.[10]

Der nächste entscheidende Schritt ist die Durchführung. Hier werden die Testdaten erstellt, es wird kontrolliert, ob das Testsystem richtig konfiguriert wurde und anschließend werden die einzelnen Testschritte ausgeführt und deren Ergebnisse protokolliert. Fehler werden aufgenommen und weitergeleitet, und abschließend Regressionstests durchgeführt.[11]

Der vierte Schritt im fundamentalen Testprozess ist die Testauswertung. Hier wird eine Ist-Soll Analyse vorgenommen, und die vorher definierten Ziele mit denen der Testdurchführung abgeglichen und verglichen ob die Endkriterien erfüllt wurden.[12]

In der letzten Phase, Abschluss der Testaktivitäten, werden die Daten der einzelnen Testphasen zusammengetragen, ausgewertet und abschließend archiviert.[13]

2.1.4 Teststufen

Um frühzeitig in den Entwicklungsprozess eingreifen zu können, ist es sinnvoll den Test in mehrere Stufen zu unterteilen. So wird die Komplexität verringert und entstandene Fehler lassen sich frühzeitiger korrigieren.


Typischerweise werden vier Teststufen unterscherschieden:

  • Komponententest
  • Integrationstest
  • Systemtest
  • Abnahmetest

Die Abbildung 2 verdeutlicht, dass die Komplexität der einzelnen Teststufen vom Kleinen zum Großen verläuft. Das bedeutet, dass beispielsweise im Komponententest möglichst kleine, einzelne Bereiche getestet werden und im Abnahmetest das komplette System. Die einzelnen Stufen werden nachfolgend genauer erläutert.

Im Komponententest werden separat testbare Komponenten wie Objekte, Klassen und Module auf Fehler geprüft. Dafür werden die einzelnen Komponenten vom restlichen System isoliert. Da eine Komponente allerdings häufig auf andere Komponenten zurückgreift, werden Platzhalter, sogenannte Stubs beziehungsweise Simulatoren und Testtreiber eingesetzt, und dienen somit als Modul-Dummies und Hilfsprograme für noch nicht existierende Unterfunktionen.[14]
Ziel des Komponententests ist es funktionale und nicht funktionale Aspekte zu testen, beispielsweise Ressourcenengpässe, strukturelle Überprüfungen zu machen und die Systemrobustheit zu prüfen.[15]

Beim Integrationstest wird das korrekte funktionale und technische Zusammenspiel von Hard- und Software überprüft, um Fehler in den Schnittstellen und der Kommunikation zwischen den Komponenten festzustellen und es wird die Behandlung von Ausnahmefällen simuliert, beispielsweise das Anmelden von 1000 Benutzern gleichzeitig an einem Server. Voraussetzung hierfür ist, dass der Komponententest stattgefunden hat und alle dort aufgedeckten Fehler behoben sind.[16]
Um den Integrationstest erfolgreich durchzuführen gibt es zwei unterschiedliche Strategien, das nicht-inkrementelle Vorgehen und das inkrementelle Vorgehen. Das nicht-inkrementelle Vorgehen wird gewählt, wenn unabhängig voneinander alle Module einzeln getestet werden und diese anschließend zur Integration zusammengebunden werden. Vorteilhaft an dieser Methode ist, dass einzelne Module parallel getestet werden können. Nachteilig ist es, dass eventuelle Fehler in Schnittstellen erst sehr spät gefunden werden können. Bei dem inkrementellen Vorgehen wird schrittweise getestet. Man verbindet ein noch nicht getestetes Modul mit einer vorangegangenen, bereits getesteten Komponente. So wird der Integrationstest mit dem Modultest verbunden. Vorteilhaft an der zweiten Methode ist, dass Fehler sehr früh erkannt werden können, dagegen spricht, dass eventuell sehr viele Platzhalter benötigt werden. Bei der inkrementellen Strategie muss noch berücksichtigt werden, in welcher Reihenfolge die Einheiten verbunden werden sollen. Bei der Variante bottom-up werden zuerst die Sachen getestet, die keine weiteren Module benötigen. Beim top-down Verfahren wird ganz oben in der Hierarchie angefangen zu testen und es werden Platzhalten für die Simulation darunter liegender Module entwickelt.[17]

Bei einem Systemtest wird das System als Ganzes geprüft. Relevanz hat vor allem die Prüfung, ob das System so umgesetzt wurde, wie es anfangs definiert wurde und ob alle Qualitätskriterien eingehalten sind. Der Systemtest stellt die umfangreichste der vier Teststufen dar. Die Problematik in diesem Test ist, dass wenn Fehler gefunden werden, diese schwer zu lokalisieren und zu beheben sind, da nicht mehr in einzelnen Modulen getestet wird. Der Systemtest sollte möglichst in einer produktionsnahen Umgebung durchgeführt werden, allerdings nicht auf dem Produktionssystem selbst, um Systemausfälle und Datenverluste zu vermeiden. Ziele des Systemtestes sind im funktionalen Bereich beispielsweise: prüfen, ob alle funktionalen Anforderungen erfüllt sind, zum Beispiel mit dem Blackbox-Verfahren, Bewertung der Testfälle auf Vollständigkeit durch Einsatz verschiedener Metriken. Im nicht-funktionalen Bereich sind beispielsweise die Benutzerfreundlichkeit, die Sicherheit und Fehlertoleranz oder auch die Performance zu testen.[18]

Einige Möglichkeiten diese nicht-funktionalen Eigenschaften zu testen, werden kurz näher erläutert.

Einer dieser angesprochenen Tests ist der Massentest. Mit ihm sollen die Grenzen der Belastbarkeit eines Systems ermittelt werden, dies geschieht durch viele, und große zu verarbeitende Daten über einen längeren Zeitraum hinweg. Durch diesen Test können Instabilitäten, wie beispielsweise Speicherfehler, am System festgestellt werden. Häufig wird die Anzahl der Daten schrittweise erhöht, so können mögliche Engstellen frühzeitig erkannt werden.[19]

Eine zweite Möglichkeit nicht-funktionale Eigenschaften zu testen ist der Recovery-Test. Hier wird geprüft ob das System nach einem Programmabsturz oder Hardwarefehler wieder hergestellt werden kann und ob alle Daten noch vollständig und konsistent sind.[20]

Im Usability-Test wird geprüft, ob die zukünftige Benutzergruppe mit dem entwickelten System alle geforderten Aufgaben effizient und effektiv durchführen kann. Dieser Test wird meist sehr frühzeitig durchgeführt, da die Benutzerfreundlichkeit sehr stark vom Entwurf und Design des Systems abhängt. So können beispielsweise Bedienelemente oder für den Anwender unnötige Zwischenschritte korrigiert werden.[21]

Die letzte Phase im Stufenkonzept ist der Abnahmetest. Es ist ein Gesamttest unter realen Einsatzbedingungen und prüft, ob die geforderten Funktionalitäten entwickelt wurden und funktionsfähig sind. Der Test wird meistens vom Auftraggeber unter Einsatz von Echtdaten durchgeführt. Es geht bei dem Test nicht mehr darum direkt darum Fehler zu finden, sondern um die Erhöhung und Bewertung der Akzeptanz des neuen Produktes. Typischerweise beinhaltet der Abnahmetest folgende Punkte: Prüfung der Anwender auf Funktionalität, beispielsweise ob die Dokumentation brauchbar ist, Abnahme des Systems durch den Administrator und einer vertraglichen Abnahme, bei der geprüft wird, ob alle im Vertrag enthaltenen Kriterien erfüllt sind.[22]


2.2 Testautomatisierung

2.2.1 Definition

Bei der automatisierten Testmethode werden Kontrollen automatisch gemäß einem vorgegebenen Plan über systemgesteuerte Regeln getestet. Testautomatisierung ist die Verwendung eines Testwerkzeugs, um Tests zu erleichtern. Ein Testwerkzeug ist ein Hilfsmittel, das eine oder mehrere Testaktivitäten unterstützt.[23]

Das Ziel, Tests zu automatisieren, liegt im Idealfall darin, manuelle Tests überflüssig zu machen. Leider ist dieses nicht immer möglich, weshalb an dieser Stelle auf kleinere Teilziele eingegangen wird.[24]

  • Arbeitsintensive Aufgaben automatisieren
Die Aufgaben im Testumfeld sind meist wenig abwechslungsreich und trotzdem arbeitsintensiv. Beispielhaft ist hier die Aufgabe der Testdateneingabe. Wird den Testern diese Arbeit abgenommen, wirkt sich das positiv auf die Motivation aus.
  • Effektive Gestaltung des Testprozesses
Oftmals sind Testwerkzeuge bereits in die Entwicklungsumgebung eingebettet, so dass auch eine Strukturierung einzelner Vorgänge notwendig ist. Der Einsatz von Testwerkzeugen ist dann sinnvoll, wenn die Testabläufe strukturiert und optimiert sind und diese mit den Werkzeugen abgebildet werden können. Dadurch sind diese Abläufe wiederholbar, die Testplanung kürzer und das Testen ist schneller und effektiver.
  • Höhere Fehlererkennungsrate
Durch den Einsatz von Testwerkzeugen können Mitarbeiter bei Routinetätigkeiten entlastet werden und so mehr Zeit in die Planung und Entwicklung investieren. Dadurch werden zwar nicht automatisch weniger Fehler gemacht, allerdings kann die Fehleranfälligkeit verringert werden.
  • Kosteneinsparungen
Die Einsparungen die sich aus der Testautomatisierung ergeben, sollen über denen der Anschaffungs- und Implementierungskosten der Testwerkzeuge liegen.


2.2.2 Entstehung und Entwicklung des automatisierten Testens

Tests können, oder wurden in der Vergangenheit immer vom Menschen selbst ausgeführt. Automatisierte Tests werden für routine Arbeiten genutzt und führen eine Tätigkeit selbständig aus. [25]

Wirkungsvolle Testprogramme brauchen einen eigenen Lebenszyklus für die Durchführung von Analyse-, Design-. Entwicklung-, Ausführungs-, und Bewertungstätigkeiten.

Softwareprojektmanager sowie Softwareentwickler haben heute immer engere Terminvorgaben und immer weniger Ressourcen. 90% der Entwickler haben schon einmal einen Liefertermin überschritten, 67% sehen Terminüberschreitung sogar schon Routineergebnis. Unternehmen und Regierungsstellen stehen unter dem Druck, ihre Kosten minimieren zu müssen. Das Ziel, Rationalisierung und Automatisierung von Geschäftsprozessen, kann mit Hilfe von neuen, kostengünstigen Softwareanwendungen realisiert werden. Die Bemühung der Softwareentwickler die Entwicklungszeit auf ein Minimum zu reduzieren erfordert häufig ein inkrementelles Software-Builds. Dem Kunden liefert das inkrementelle Build etwas Greifbares, dennoch erhöht sich die Notwendigkeit die Builds zu kombinieren um den Umfang und die Komplexität der Testarbeiten zu verringern.[25]

Bei Client/Server-Anwendungs-Tests wird vom Client ein Dienst angefordert, welchen der Server nach Abschluss zurück meldet. Normalerweise werden solche Tests über das Netzwerk durchgeführt, dabei kann sich der Client sowie der Server auf dem selben Rechner befinden. Für die Testingenieure heißt das, dass sie sich nicht mehr nur mit den Client und Server auseinander setzen müssen, sondern auch mit dem Netzwerk, was ein mögliches Fehlerpotenzial mehr darstellt. Die neue Komplexität die dadurch entstanden ist wirkt sich auch auf die Merkmale von GUI-Bildschirmen aus. Der Ersatz von zeichenbasierten Anwendungen durch grafische Benutzeroberflächen macht es den Anwendern leichter mit den Applikationen zu arbeiten. Die Notwendigkeit die Befehle zu kennen und zu verstehen wurde durch die grafischen Benutzeroberflächen reduziert. Die Software arbeitet im Hintergrund. Es sind Objekte auf dem Bildschirm die als Symbole dargestellt werden. Die Symbole können jede beliebige Position oder Größe annehmen. Der ereignisgesteuerte Ansatz der Umgebung unterscheidet sich wesentlich mit dem der bei Großrechnern basierenden Umgebung.[25]

Capture and Replay ist eine Testmethode für Benutzer, die dank der Verbreitung von GUI-Anwendungen, erst möglich wurde. Die Fähigkeiten der automatisierten Testwerkzeuge ist gereift und sie verfügen über die Möglichkeit Prozesse vom Bildschirm aufzuzeichnen und wiederzugeben.[25]

Wichtige Kriterien der Testautomatisierung sind:

  • Vollständigkeit
Wie gründlich wurden die Anforderungen definiert und bewertet
  • Konsistenz
Die einzelnen Anforderungen dürfen sich nicht widersprechen
  • Machbarkeit
Lassen sich die Kenntnisse der Projektmitarbeiter, die Zeit, die Hardwarespezifikationen und die Anforderungen mit den verfügbaren Technologien tatsächlich implementieren
  • Aussagefähigkeit der Tests
In welchem Ausmaß kann eine Testmethode belegen, dass sie erfolgreich implementiert wurde [25]

2.2.3 Automatisierbare Aktivitäten

Leider kann man im Bereich des automatisierten Testens nicht alles abdecken. Der nächste Abschnitt geht auf die automatisierbaren Testvorgänge ein und erläutert diese.

  • Testfallerstellung
Je nachdem welches Format für die Beschreibung des Testfalles verwendet wird, kann man die Testfallerstellung automatisieren. Dazu müssen genaue Testspezifikationen in das Format übertragen werden. Für Testdaten und Funktionsaufrufe kann dies in Tabellen geschehen, durch Scriptsprachen, objektorientierte Ansätze oder auch imperative Sprachen wie zum Beispiel C, je nachdem was für ein Abstraktionsgrad notwendig ist. Wenn die Testspezifikationen in einem Ablaufplan vorliegen, welches beispielsweise des UML Standards entspricht, so können diese mit den entsprechenden Werkzeugen in automatisierbare Testfälle umgewandelt werden.[26]
  • Testdurchführung
Zum automatisieren der Testdurchführung können unter anderem Lasttestsysteme, HiL-Prüfstände, verschiedene Testsysteme zum Testen grafischer Benutzeroberflächen eingesetzt werden.[27]
  • Testdaten- und Testskripterstellung
Die Eingabedaten und Abläufe müssen gemäß der zu erzielenden Testabdeckung gewählt werden, da diese häufig sehr groß sind. Bei der Erstellung der Testdaten, kann auf das Datenmodell der Software zurückgegriffen werden und zur Testskripterstellung auf das Verhaltensmodell der Software. Es gibt zur Testdatenerstellung sogenannte Datengeneratoren, die automatisch Testdaten generieren.[28]
  • Testauswertung
Um Tests automatisch auswerten zu können, müssen die erwarteten Ergebnisse bekannt sein und diese werden mit den erzielten Testergebnissen verglichen. Wenn mehrere Testergebnisse bekannt sind, zum Beispiel aus verschiedenen Testzyklen, können diese miteinander kombiniert werden um so Tendenzen zu ermitteln und Statistiken zu erhalten. Ein sehr einfaches Beispiel für automatische Testauswertung ist die der Multiple-Choice Tests. Es gibt einen erwarteten Wert, und einen tatsächlichen und ein Programm stellt die Gemeinsamkeiten und Unterschiede fest und liefert das Ergebnis zurück.[29]
  • Testdokumentation
Zur automatischen Erstellung von Dokumentationen gibt es Programme, die aus erzeugten Testberichten, eine übersichtliche Dokumentation erstellen.[30]

3 Anwendungsmöglichkeiten

3.1 Benchmarking

Eine Überprüfung der Leistungsverhältnisse von EDV gestützter Computerechnologie, mit Hilfe von eigens zu diesem Zweck konstruierter Software [31]

3.1.1 Geforderte Merkmale von Benchmark Tests

  • Wiederholbarkeit: Der Benchmark sollte bei allen Ausführungen mit gleichen Bedingungen die gleichen Ergebnisse erzeugen.

Bei Systemen die komplex sind ist die Wiederholbarkeit oft nicht gegeben. Das kann durch das Betriebssystem geschehen oder beispielsweise durch den Cache-Controller. Wenn einer oder mehrere Umstände das Ergebnis verfälschen könnten, so wird der Benchmark wiederholt oder ein Durchschnittswert ermittelt.

  • Repräsentativität: Bei den Benchmarks geht es im Unterschied zu den Software-Tests um möglichst typische und häufig wiederkehrende Anwendungsfälle. Die Leistung steht bei qualitätssichernden Tests nicht im Mittelpunkt, sondern die Funktionalität der Software. Der Benchmark simuliert das Verhalten eines Benutzers.
  • Einfachheit: Durch die einfache Installation der Benchmark Umgebung und die einfache Bedienung wird ein verständliches Ergebnis gewährleistet.
  • Verifizierbarkeit: Die Benchmark Durchläufe müssen nachvollziehbar und überprüfbar sein[32]

3.1.2 Standard-Benchmarks für Hardware- und Software-Systeme

Zur Vergleichbarkeit von Evaluierungsaufgaben haben sich Standard-Benchmarks weltweit etabliert. (z.B. TPC Benchmark, SPEC Benchmarks, SAP Standard Applikation Benchmark). Bei Verwendung von Standard–Benchmarks sind folgende Dinge zu beachten:

Benchmark-Programme können sehr alt sein und sind nicht mehr auf dem neuesten Stand der Technik.

Verwendete Referenzen sind meistens nicht mehr aktuell, so dass das neue Systeme beim Benchmark deutlich bessere Ergebnisse liefern könnte.

Compiler-Optimierungen könnten für den Benchmark geschrieben worden sein, was das Ergebnis verfälscht.

Bei zu groben Metriken können die Leistungsunterschiede leicht verdeckt werden.

Compiler-Autoren kann es leicht fallen die Codeerzeugung und die Auswahl der Optimierung für sich zu nutzen.

Das Speichersystem kann nicht realistisch gemessen werden da die Benchmark-Programme sehr klein sind und fast vollständig aus dem Cache-Speicher heraus ausgeführt werden.[32]

3.1.3 Hardware-Benchmark-Test

Dies ist ein Test zur Ermittlung und Vergleichbarkeit von Hardware. Die Ausgabe von Bildpunkten bei grafikintensiven Spielen wird mit Hilfe von Benchmark-Tests automatisch ermittelt. Als Ergebnis kommt heraus, dass die Hardware das Spiel in einer gewissen Zeit, mit einer gewissen Anzahl von Bildpunkten wiedergibt. Somit haben wir eine Vergleichbarkeit zu anderer, ebenfalls mit dieser Software, eingesetzter Hardware. Was bei diesen Tests nicht ausser acht zu lassen ist, ist dass es Hersteller gibt, die die Treiber zu den Benchmark-Tests hin optimiert auf den Markt bringen. Das bedeutet, dass zwar die vorab Version hervoragend mit dem Banchmark-Test umgehen kann, aber im schlimsten Fall, die Hardware und die Treiber die wirklich ausgeliefert werden, sich doch erheblich von der Testversion unterscheiden.[33]

EEMBC- Benchmarks zur Plattformbewertung Zur Plattformanalyse gibt es eine Reihe von Benchmarks des Embedded Mikroprozessor Benchmark Konsortiums (EEMBC). Das EEMBC-Konsortium wurde 1997 gegründet und sieht seine Aufgabe in sinnvollen Performance-Benchmarks für Hard- und Software. Durch die Mitarbeit der namhaften Mikroprozessor-Hersteller (ARM, IBM, TI und Infineon) konnten die EEMBC-Benchmarks zu einem de-facto Standard für Evaluierung gemacht werden.[34]

3.2 Hardware in the Loop

Hardware in the Loop, kurz HiL, bezeichnet ein System um Steuergeräte zu simulieren. Die realen elektronischen Steuergeräte werden in eine Simulationsumgebung eingebunden.
Die in Echtzeit generierten Sensorsignale werden dabei von einem Aktorsignal erzeugt.[35]

Durch den Einsatz der Simulationen kann der Bedarf an Ressourcen und Entwicklungszeiten reduziert werden. Bei der Simulation mittels HiL bietet sich die Möglichkeit, reale Komponenten aus dem Gesamtsystem herausgelöst zu testen.[36]
Moderne Steuergeräte erwarten physikalisch sinnvolle Eingangsgrößen. Für einen allgemeinen Überprüfungsalgorithmus ist ein statischer Ansatz nicht praktikabel. Daher müssen die Eingangsgrößen von einer Simulationsumgebung in Echtzeit zur Verfügung gestellt werden. Die Ausgangsgrößen des realen Systems werden zurückgeführt und fließen in die Simulation ein. HiL Systeme leisten einen großen Beitrag zur Qualitätssicherung in den frühen Entwicklungsphasen der Steuergeräteentwicklung.[37]


Großen Einsatz finden HiL Simulationen im Automotivebereich. Gerade dort werden echtzeitfähige und automatisierbare Simulationsumgebungen benötigt, um gefahrlos, unabhängig von Wetterbedingungen und störungsfrei testen zu können.
Die Abbildung drei zeigt einen Prüfstandaufbau, der die Bremsanlage eines Fahrzeuges (Steuergerät, Hydraulikeinheit, Bremsschläuche und Bremsklötze) simulieren soll. Alle benötigten Eingangssignale werden dem Steuergerät von der Simulationsumgebung zur Verfügung gestellt. Zurückgelieferte Größen sind die Signale an die Motorsteuerung und die Bremsdrücke an den Bremsscheiben. Das Ziel dieser Simulation ist es gefährliche Fahrversuche in Grenzsituationen des Fahrverhaltens zu verringern.[38]

Nachteilig an HiL Simulationen ist, dass diese von Spezialisten gebaut werden und diese die Systeme auch betreuen müssen. Deswegen sind sie sehr kostspielig und durch den speziellen Aufbau stehen für umfangreiche Tests meist nur kleine Zeitfenster zur Verfügung. Da HiL Systeme auf die Echtzeitfähigkeit der Simulation angewiesen sind und die Rechenzeit beschränkt ist, muss außerdem häufig mit großen Vereinfachungen der Modelle gearbeitet werden.[39]

4 Fazit

Automatisierte Tests können derzeit manuelle Tests sinnvoll ergänzen, aber diese noch nicht vollständig ersetzen. Gerade in den Bereichen der nicht-funktionalen Tests findet automatisiertes Testen seine Grenzen. Ob ein System benutzerfreundlich ist, ist eben ein subjektives Empfinden und lässt sich nicht mit harten Kriterien definieren. Genauso verhält es sich bei Designfragen oder der Entscheidung ob die Systemdokumentation für die Administratoren verständlich ist.
Software automatisiert zu testen entlastet bei wiederholten Durchläufen die Mitarbeiter und schafft so freie Ressourcen, die dann zum Beispiel wieder in die Entwicklung investiert werden können. Allerdings muss erst investiert werden, sowohl Kosten wie auch Zeit. Diese Aspekte sollte man nicht vernachlässigen. Bevor automatisiert getestet wird, sollte klar sein, was man automatisiert testen möchte, welche Testbereiche betroffen sind, um sich dann nach einem passenden Testwerkzeug zu erkundigen. Für dieses muss Geld bereitgestellt werden, um es zu beschaffen. Eventuell fallen je nach Umfang noch Kosten für die Implementierung an und auf jeden Fall entsteht anfangs ein hoher Workload, da vorhandene Testfälle und Prozesse angepasst werden müssen, man Testdaten im neuen System bereitstellen muss und die einzelnen Testfälle übertragen werden müssen. Auch ist es illusorisch davon auszugehen, dass man einmal eingegebene Testfälle nie wieder ändern braucht. Regelmäßige Überprüfungen der Prozesse im System sind notwendig, und wenn Anpassungen am System durchgeführt wurden, müssen auch die dazugehörigen Testfälle und eventuell auch die Datenbasis angepasst werden.
Und was nicht vergessen werden sollte:
Keine Fehler zu finden, bedeutet nicht, dass keine Fehler vorhanden sind. Und selbst die besten Methoden des automatisierten Testens sind von Anwendern entwickelt und somit niemals 100%ig fehlerfrei.

5 Abkürzungsverzeichnis

AbkürzungBedeutung
HiL Hardware in the Loop

6 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1Fundamentaler Testprozess
2Teststufen
3HiL Simulation

7 Fußnoten

  1. ↑ Vgl. URL:http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&chinese=both&pinyin=diacritic&search=test&relink=on, Stand 27.12.2009
  2. ↑ Vgl. Schumann, Siegfried: Repräsentative Umfrage: Praxisorientierte Einführung in empirische Methoden und statistische Analyseverfahren, Seite 28
  3. ↑ Vgl. Meinel, Kurt; Schnabel, Günther: Bewegungslehre Sportmotorik: Abriss einer Theorie der sportlichen Motorik unter pädagogischem Aspekt, Seite 382
  4. ↑ Vgl. Lienert, Gustav A.; Raatz, Ulrich: Testaufbau und Testanalyse, Seite 1
  5. ↑ Vgl. Hinterhuber, Hans H.; Matzler, Kurt: Kundenorientierte Unternehmensführung. Kundenorientierung - Kundenzufriedenheit - Kundenbindung, Seite 9
  6. ↑ Vgl. Renker, Clemens: Relationship Marketing: Konzepte - Erfolgsfaktoren - Umsetzung, Seite 242
  7. ↑ Vgl. Göbl, Martin: Die Beurteilung von Dienstleistungen, Seite 127
  8. ↑ Vgl. URL:http://www.tester-seminar.net/01-basics/010104.html, Stand 06.01.2010
  9. ↑ Vgl. Wallmüller, Ernest: Software-Qualitätsmanagement in der Praxis: Software-Qualität durch Führung und Verbesserung von Software-Prozessen, Seite 242
  10. ↑ Vgl. Lienert, Gustav A.; Raatz, Ulrich: Testaufbau und Testanalyse, Seite 3
  11. ↑ Vgl. Liggesmeyer, Peter: Software-Qualität: Testen, Analysieren und Verifizieren von Software, Seite 12
  12. ↑ Vgl. Conrad, Mirko: Modell-basierter Test eingebetteter Software im Automobil. Auswahl und Beschreibung von Testszenarien, Seite 119
  13. ↑ Vgl. Elfriede Dustin, Jeff Rashka, und John Paul von Springer: Software automatisch testen: Verfahren, Handhabung und Leistung (Xpert.Press), Seite 259
  14. ↑ Vgl. Grechenig, Thomas; Bernhart, Mario; Breiteneder, Roland; Kappel, Karin: Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Seite 307
  15. ↑ Vgl. Vivenzio, Alberto: Testautomation mit SAP®: SAP Software erfolgreich einführen, Seite 4
  16. ↑ Vgl. Franz, Klaus: Handbuch zum Testen von Web-Applikationen: Testverfahren, Werkzeuge, Praxistipps (Xpert.Press), Seite 95
  17. ↑ Vgl. Elfgen, Stefan: Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren, Seite 37
  18. ↑ Vgl. Frühauf, Karol; Ludewig, Jochen; Sandmayr, Helmut: Software-Prüfung: Eine Anleitung zum Test und zur Inspektion (vdf Lehrbuch), Seite 77
  19. ↑ Vgl. Franz, Klaus: Handbuch zum Testen von Web-Applikationen: Testverfahren, Werkzeuge, Praxistipps (Xpert.Press), Seite 19
  20. ↑ Vgl. Mayr, Herwig: Projekt Engineering: Ingenieurmäßige Softwareentwicklung in Projektgruppen, Seite 198
  21. ↑ Vgl. Anderl, Reiner; Birkhofer, Herbert: Eco Design, Seite 189
  22. ↑ Vgl. Mayr, Herwig: Projekt Engineering: Ingenieurmäßige Softwareentwicklung in Projektgruppen, Seite 290
  23. ↑ Vgl. Pol, Martin; Koomen, Tim; Spillner, Andreas: Management und Optimierung des Testprozesses, Seite 14
  24. ↑ Vgl. Hommes, Werner: Werkzeuge zur Testautomatisierung, Seite 6
  25. ↑ 25,0 25,1 25,2 25,3 25,4 Vgl. Elfriede Dustin, Jeff Rashka, und John Paul von Springer: Software automatisch testen: Verfahren, Handhabung und Leistung (Xpert.Press), Seite 1-10
  26. ↑ Vgl. Efgen, Stefan: Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren, Seite 41
  27. ↑ Vgl. Liggesmeyer, Peter: Software-Qualität: Testen, Analysieren und Verifizieren von Software, Seite 395
  28. ↑ Vgl. Roitzsch, E. H. Peter: Analytische Softwarequalitätssicherung in Theorie und Praxis: Der Weg zur Software mit hoher Qualität durch statisches Prüfen, dynamisches Testen, formales Beweisen, Seite 192
  29. ↑ Vgl. Wiesbrock, Dr. Hans-Werner: Automatische Testauswertung für Steuergerätesoftware, Seite 9
  30. ↑ Vgl. Conrad, Mirko: Modell-basierter Test eingebetteter Software im Automobil. Auswahl und Beschreibung von Testszenarien, Seite 125
  31. ↑ Vgl. Bornemeier, Olaf: Benchmarking in der Gesundheitsversorgung: Möglichkeiten und Grenzen, Seite 58
  32. ↑ 32,0 32,1 Vgl. Heinrich, Lutz J.; Lehner,Franz: Informationsmanagement, Seiten 464,465
  33. ↑ Vgl. Beisecker, Michael: Das Lexikon der PC-Fachbegriffe 2009/2010, Seite 57
  34. ↑ Vgl. Schmitt: Integrierte Simulation und Emulation eingebetteter Hardware /Software-Systeme , Seite 139
  35. ↑ Vgl. Braess, Hans-Hermann; Seiffert, Ulrich: Handbuch Kraftfahrzeugtechnik, Seite 602
  36. ↑ Vgl. Roddeck, Werner: Einführung in die Mechatronik, Seite 426
  37. ↑ Vgl. URL:http://www.etas.com/de/products/applications_ecu_testing.php, Stand 13.01.2009
  38. ↑ Vgl. URL:http://209.85.135.132/search?q=cache:5x0T7wX1XHYJ:www.fahrzeugtechnik-muenchen.de/content/view/71/64/lang,de/+hardware+in+the+loop&cd=2&hl=de&ct=clnk&gl=de, Stand 13.01.2009
  39. ↑ Vgl. Diegmüller, Frank: Probabilistische Methode zur Generierung von Stimuli zum Test zustandsbasierter, reaktiver Elektroniksysteme im Automobil, Seite 98

8 Literatur- und Quellenverzeichnis

Anderl, Birkhofer (2007) Anderl, Reiner; Birkhofer, Helbert: "Eco Design", Springer, Berlin, 2007
Beisecker (2009) Beisecker, Michael: "Das Lexikon der PC-Fachbegriffe 2009/2010", Vnr-Verlag Deutsche Wirtschaft, 2009
Bornemeier (2002) Bornemeier, Olaf: "Benchmarking in der Gesundheitsversorgung: Möglichkeiten und Grenzen", Autorenverlag Scheriau, Berlin, 2002
Braess, Seiffert (2005) Braess, Hans-Hermann; Seiffert, Ulrich "Vieweg Handbuch Kraftfahrzeugtechnik", Vieweg, 2005
Conrad (2004) Conrad, Mirko: "Modell-basierter Test eingebetteter Software im Automobil. Auswahl und Beschreibung von Testszenarien", Vieweg+Teubner, 2004
Diegmüller (2009) Diegmüller , Frank: "Probabilistische Methode zur Generierung von Stimuli zum Test zustandsbasierter, reaktiver Elektroniksysteme im Automobil ", Kassel University Press, 2009
Dustin, Rashka, Paul (2000) Dustin, Elfriede; Rashka, Jeff; Paul, John: "Software automatisch testen: Verfahren, Handhabung und Leistung (Xpert.Press)", Springer, Berlin, 2000
Elfgen (2007) Elfgen, Stefan: "Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren", GRIN Verlag, 2007
Franz (2007) Franz, Klaus: "Handbuch zum Testen von Web-Applikationen: Testverfahren, Werkzeuge, Praxistipps (Xpert.Press)", Springer, Berlin, 2007
Frühauf, Ludewig, Sandmayr (2006) Frühauf, Karol; Ludewig, Jochen; Sandmayr, Helmut : "Software-Prüfung: Eine Anleitung zum Test und zur Inspektion (vdf Lehrbuch)", Vdf Hochschulverlag, 2006
Göbl (2003) Göbl, Martin: "Die Beurteilung von Dienstleistungen", Gabler, 2003
Grechenig, Bernhart, Breiteneder, Kappel (2009) Grechenig, Thomas; Bernhart, Mario; Breiteneder, Roland; Kappel, Karin: "Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten", Pearson Studium, 2009
Hinterhuber, Matzler (2008) Hinterhuber, Hans H.; Matzler, Kurt: "Kundenorientierte Unternehmensführung. Kundenorientierung - Kundenzufriedenheit - Kundenbindung", Gabler, 2008
Hommes (2007) Hommes, Werner: "Software-Qualitätsmanagement in der Praxis: Werkzeuge zur Testautomatisierung", GRIN Verlag, 2007
Lienert, Raatz (1998) Lienert, Gustav A.; Raatz Ulrich: "Testaufbau und Testanalyse", BeltzPVU, 1998
Liggesmeyer (2009) Liggesmeyer, Peter: "Software-Qualität: Testen, Analysieren und Verifizieren von Software", Spektrum Akademischer Verlag, 2009
Mayr (2005) Mayr, Herwig: "Projekt Engineering: Ingenieurmäßige Softwareentwicklung in Projektgruppen", Hanser Fachbuch, 2005
Meinel, Schnabel (2007) Schumann, Siegfried: "Bewegungslehre Sportmotorik: Abriss einer Theorie der sportlichen Motorik unter pädagogischem Aspekt", Meyer & Meyer Sport, 2007
Panther (2005) Panther, Robert: "Das Pocket PC Programmierhandbuch", Franzis Verlag GmbH, 2005
Pol, Koomer, Spillner (2002) Pol, Martin; Koomer, Tim; Spillner, Andreas: "Management und Optimierung des Testprozesses", Dpunkt.Verlag GmbH, 2002
Renker (2005) Renker, Clemens: "Relationship Marketing: Konzepte - Erfolgsfaktoren - Umsetzung", Gabler, 2005
Roddeck (2006) Roddeck, Werner: "Einführung in die Mechatronik", Vieweg+Teubner, 2006
Roitzsch (2005) Roitzsch, E. H. Peter: "Analytische Softwarequalitätssicherung in Theorie und Praxis: Der Weg zur Software mit hoher Qualität durch statisches Prüfen, dynamisches Testen, formales Beweisen", Monsenstein und Vannerdat, 2005
Schmitt (2005) Schumann, Siegfried: "Integrierte Simulation und Emulation eingebetteter Hardware /Software-Systeme", Cuviller, 2005
Schumann (2006) Schumann, Siegfried: "Repräsentative Umfrage: Praxisorientierte Einführung in empirische Methoden und statistische Analyseverfahren", Oldenbourg, 2005
Vivenzio (2009) Vivenzio, Alberto: "Testautomation mit SAP®: SAP Software erfolgreich einführen", Dr. Th. Gabler Verlag, 2009
Wallmüller (2001) Wallmüller, Ernest: "Software-Qualitätsmanagement in der Praxis: Software-Qualität durch Führung und Verbesserung von Software-Prozessen", Hanser Fachbuch, 2001
Wiesbrock Wiesbrock, Dr. Hans-Werner: "Automatische Testauswertung für Steuergerätesoftware"


ohne Verfasser o.V.: "Übersetzung Test", http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&chinese=both&pinyin=diacritic&search=test&relink=on, Stand 27.12.2009
ohne Verfasser o.V.: "Phasen fundamentaler Testprozess", http://www.tester-seminar.net/01-basics/010104.html, Stand 06.01.2010
ohne Verfasser o.V.: "Übersetzung Test", http://http://www.etas.com/de/products/applications_ecu_testing.php, Stand 13.12.2009
ohne Verfasser o.V.: "Übersetzung Test", http://http://209.85.135.132/search?q=cache:5x0T7wX1XHYJ:www.fahrzeugtechnik-muenchen.de/content/view/71/64/lang,de/+hardware+in+the+loop&cd=2&hl=de&ct=clnk&gl=de, Stand 13.12.2009
Von „http://winfwiki.wi-fom.de/index.php/Analyse_der_Anwendungsm%C3%B6glichkeiten_von_Testautomatisierung“
Persönliche Werkzeuge