nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Software-Qualität - Software-Test

Testen von Software

Um die Qualität eines Softwareprodukts bereits im Entwicklungsprozeß abzusichern, kann Testen als eine wesentliche Form der konstruktiven und der analytischen Qualitätssicherung eingesetzt werden (für eine aktuelle Darstellung vgl. [Spillner 03]).

Testen gehört zu den wichtigen Phasen klassischer Vorgehensmodelle. In agilen Vorgehensweisen läßt sich Testen gut mit dem Vertragsmodell kombinieren.

Grundkonzepte. Testen ist eine Aktivität zur Bewertung der Produktqualität und zum Aufspüren noch vorhandener Fehler. Durch ausgewählte Testfälle wird ein Programm während seiner Ausführung auf fehlerhaftes oder unerwünschtes Verhalten gegenüber seinem erwarteten Verhalten geprüft [SWEBOK 04].

Testen bezieht sich auf unterschiedliche Fragestellungen und Ausschnitte der Software. Eine übliche Unterteilung ist:

  • Ein Unit-Test prüft eine isoliert ausführbare Programmeinheit (z.B. eine Prozedur oder eine Klasse).
  • Ein Integrationstest betrachtet das Zusammenspiel (teil-)selbstständiger Programmelemente (wie Klassen oder Module).
  • Ein Systemtest bewertet das technische oder das fachliche Verhalten der gesamten Software. Technisch werden oft nichtfunktionale Merkmale (wie Reaktionszeit, Verhalten und Last) getestet; fachlich gehört hierher der Akzeptanztest durch die Anwender. Beide Aspekte gemeinsam betrachtet meist der Abnahmetest durch den Auftraggeber.

Beschränkungen des Testens. Dem Nutzen des Testens stehen prinzipielle Begrenzungen gegenüber, die E.W. Dijkstra so formuliert hat: „Testen kann bestenfalls die Anwesenheit von Fehlern, aber niemals ihre Abwesenheit in Programmen zeigen.“

Weitere Einschränkungen sind [SWEBOK 04]:

  • Beim Testen werden traditionell für definierte Eingabewerte die erwarteten mit den tatsächlichen Ergebniswerten verglichen; bei reaktiven vernetzten Programmen kann oft die Reaktion eines Systems auf eine Eingabeaktion nicht deterministisch vorausgesagt werden.
  • Schon einfache Programme lassen sich nicht vollständig testen, da die Menge der möglichen Programmzustände praktisch nicht durch Testfälle abgedeckt werden kann.
  • Sinnvolle Testfälle müssen ausgewählt und die Ergebnisse bewertet werden können. Dies ist bei vielen anwendungsfachlich orientierten Testarten schwierig.

Die objektorientierte Programmierung besitzt gegenüber der klassischen imperativen Programmierung einige strukturelle und dynamische Besonderheiten (Kapselung, Polymorphie, Vererbung), welche bei der Konzeption von Tests zu berücksichtigen sind. Zum Thema Testen von objekt-orientierten Programmen mit seinen zusätzlichen Problemen ist umfangreiche einschlägige Literatur verfügbar ([Binder 99], [Sneed 02], [Spillner 03]).

Testarten und -strategien. Es werden Black-Box und White-Box Test unterschieden. Beim Black-Box Test wird ein Programm nur anhand seiner Spezifikation getestet. Beim White-Box Test wird der innere Aufbau eines Programms mit berücksichtigt. Der White-Box-Test ist besonders beim Komponententest wichtig. Zum Testen objekt-orientierter Programme wird aufgrund der spezifischen Schwierigkeiten oft ein Grey-Box Test empfohlen. Darunter versteht man einen Black-Box Test, bei dem einige Aspekte des inneren Aufbaus des Testobjektes genutzt werden dürfen.

Während Integrationstests bei der Neuentwicklung besonders wichtig sind, stehen bei der Weiterentwicklung (Wartung) und bei iterativ-zyklischen Vorgehensmodellen Regressionstests im Vordergrund. Sie sollen nach Änderungen im Code sicherstellen, daß die Änderungen nicht zu Fehlern geführt haben. Regressionstests sollten zur Unterstützung des Refactoring [Fowler 00] automatisiert werden.

Für alle an technischen Systemmerkmalen ausgerichteten Testverfahren stellt sich die Frage, wie vollständig oder umfangreich die Tests sind. In der Literatur werden zahlreiche sogenannte Testmaße vorgeschlagen, die alle das Verhältnis der getesteten zur möglichen Anzahl der untersuchten Programmerkmale angeben. In der Praxis werden bei einer Zertifizierung von Software vor allem der Test aller Methoden, aller Fallunterscheidungen oder aller Programmanweisungen gefordert.

Für alle an technischen Systemmerkmalen ausgerichteten Testverfahren stellt sich die Frage, wie vollständig oder umfangreich die Tests sind. In der Literatur werden zahlreiche sogenannte Testmaße vorgeschlagen, die alle das Verhältnis der getesteten zur möglichen Anzahl der untersuchten Programmerkmale angeben. In der Praxis werden bei einer Zertifizierung von Software vor allem der Test aller Methoden, aller Fallunterscheidungen oder aller Programmanweisungen gefordert.

Das Testen nicht-funktionaler Systemeigenschaften, besonders Performance-, Last- oder Streßtests, ist eine komplexe Aufgabe, die in professionellen Organisationen meist von spezialisierten Teams erledigt wird. Dabei werden z.B. eigene Testumgebungen mit Testfallgeneratoren und Replay-Tools genutzt.

Zur Bewertung der Gebrauchsqualität werden neben den meist informellen Akzeptanztests sogenannte Usability Tests herangezogen. Sie beruhen auf Erkenntnissen der Software-Ergonomie sowie der Mensch-Maschine-Kommunikation (engl. Human Computer Interaction, HCI) und werden oft in sogenannten Usability Labors mit eigener technischer Unterstützung durchgeführt.

Bei neuen Software-Produkten oder -Versionen werden in der Praxis oft sogenannte Alpha- und Beta-Tests durchgeführt. Beim Alpha-Test erhalten Anwender der eigenen Organisation Vorabversionen; Beta-Versionen werden an ausgewählte externe Anwendergruppen zum (Pilot-) Einsatz geliefert. Dies wird kritisiert, da statt einer systematischen Teststrategie nur Fehlerreports ausgewertet werden.

Testgetriebene Entwicklungsansätze. Agile Methoden, besonders das eXtreme Programming, empfehlen testgetriebene Entwicklungsansätze. Bekannt ist die „Test first“ Strategie, bei der für jede Klasse zunächst eine eigene Testklasse geschrieben wird. Die Methoden dieser Klasse implementieren die auf Basis der Benutzeranforderungen formulierten Testfälle in ausführbarer Form. Eine derartige Methode auszuführen bedeutet, einen Testfall ablaufen zu lassen. Vor der Implementierung der eigentlichen Klasse soll klar werden, welches Problem mit welchen Randbedingungen verbunden ist. Der Quellcode der Anwendung kann dann so ergänzt werden, daß die Testfälle alle zu korrekten Ergebnissen führen. Durch Refactoring kann anschließend der Quellcode verbessert werden. Die Testfälle erleichtern es, Abweichungen von der korrekten Funktionsweise festzustellen. Testen und Programmieren erfolgen in schnellem Wechsel – jede neue Klasse und Operation wird sofort getestet. Dies wird besonders beim Refactoring gefordert.

Literaturhinweis

[Binder 99] Binder, R.V.: Testing object-oriented systems: models, patterns, and tools. 1st. ed. Addison-Wesley Professional 1999

[Fowler 00] Fowler, M.: Refactoring. Improving the design of existing code. Addison-Wesley 2000

[Sneed 02] Sneed, H.M.; Winter, M.: Testen objektorientierter Software. München: Carl Hanser 2002

[Spillner 03] Spillner, A.; Linz, T.: Basiswissen Softwaretest. dPunkt 2003

[SWEBOK 04] SWEBOK: Guide to the software engineering body of knowledge. IEEE 2004

Informatik-Handbuch, Peter Rechenberg, Gustav Pomberger, 4., aktualisierte und erweiterte Auflage 2006, Hanser Verlag, 1256 Seiten, ISBN 978-3-446-40185-3

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt