Testdurchführung

Sie wollen sicher sein, dass die neue Software einfach nur funktioniert und tut, was sie soll? Wir auch. Deshalb legen wir bei DLS besonderen Wert auf das richtige Testen der Software. Was wir getestet haben, das funktioniert und der Anwender ist zufrieden. Was nicht getestet wurde, kann vielleicht fehlerfrei funktionieren oder auch nicht. Oft wird die Bedeutung des richtigen Testens unterschätzt und die vermeintlich hohen Kosten des Testvorgangs werden wiederholt kritisiert. Das Testen braucht eben seine Zeit und kostet Geld. Aber dieses Geld ist gut investiert. Fehler in der Software, welche erst beim Einsatz im Feld festgestellt werden, kosten in der Regel wegen der Umstände bei der dringenden Fehlerbehebung deutlich mehr als der reguläre Testaufwand vor der Auslieferung.

Das weite Gebiet der Software-Tests lässt sich recht gut wie folgt einteilen:

• Modultest (auch als Unittest oder Komponententest bezeichnet),
• Integrationstests,
• Systemtests (auch mit Performance-Tests) und
• Abnahmetests.

Für alle Tests gilt der Grundsatz: So viel wie notwendig und mit möglichst geringen Kosten. Wer richtig (d.h. intelligent) testet, hat im Wettbewerb die Nase vorn. Ein guter Testplan sichert die gewünschte Qualität der Software und hilft, den Testaufwand zu minimieren.

Wie Sie den Testplan optimal gestalten, hängt von der Größe, von der Komplexität und von der gewünschten Wartbarkeit der Software ab. Wir beraten Sie gerne darüber, ob in Ihrem Projekt mit händischen Tests das Auslangen zu finden ist oder ob Sie mit automatisierten Tests besser dran sind.

In der Softwaretechnik werden die Tests anhand der Spezifikationen oder anhand des Software-Quellcodes definiert. Es ergibt sich, dass die Testabdeckung für unterschiedliche Bereiche unterschiedlich ermittelt wird. Dies ist bei Gesprächen über die Testabdeckung immer zu berücksichtigen.

Vielfach ist eine eindeutige Angabe des Testabdeckungsgrades nicht möglich, da die Anzahl der Testfälle für eine 100 prozentige Testabdeckung nicht immer bestimmt werden kann. Je nach getesteten Bereich geht es um die Abdeckung des Codes, der Daten oder der Fachlichkeit.

Entscheidend für den Testaufwand ist die gewünschte (oder vom Letztanwender oder von allfälligen Zulassungsstellen verlangte) Vollständigkeit im Testvorgang. Folgende Faktoren beeinflussen zusätzlich den Testaufwand:

• Konfigurierbarkeit der Software,
• Testbarkeit der Testobjekte,
• benötigte Testinfrastruktur,
• Mitarbeiter-Qualifikation im Testteam,
• Organisation des Testablaufs und
• Qualitätsziele und Teststrategie.

Es gibt verschiedene Verfahren, mit denen der Testaufwand beschränkt werden kann und gleichzeitig eine möglichst umfangreiche Funktionsprüfung von Software und System sichergestellt wird. Mit der richtigen Teststrategie lassen sich oft unnötige Kosten beim Testen vermeiden. Fragen Sie uns einfach danach, was in Ihrem Projekt optimal ist.

Sehr oft wird versucht, die Durchführung der Tests zu automatisieren, um die Reproduzierbarkeit von Testergebnissen sicherzustellen und gleichzeitig den langfristigen Testaufwand zu minimieren. Es gibt zwar zu Beginn den Aufwand zur Herstellung der Testumgebung, auf der die automatisierten Tests laufen sollen. Je öfter Sie aber gezwungen sind, den Testvorgang zu wiederholen, umso früher rechnet sich die Anfangsinvestition. Wir können Ihnen sagen, wann und wo sich automatisierte Tests kaufmännisch bezahlt machen und welche Alternativen eventuell möglich sind.

Auch durch die richtige Auswahl der verwendeten Testwerkzeuge und durch ein qualifiziertes Testteam kann der Testaufwand reduziert werden. Schließlich spielen für die Kosten eine wesentliche Rolle der Testplan und die Anwendung von unterschiedlichen Testfall-Katalogen. Ein guter Testplan enthält die richtigen Tests und nicht einfach alle möglichen und vorstellbaren Tests.

Modultests zählen zu den "White-Box-Tests", da bei der Definition der Testfälle der zu testende Quellcode bekannt ist.

DLS hat für die Durchführung von Modultests im Bereich von hochsicherer Software ein eigenes Werkzeug namens „Testfallgenerator“ geschaffen. Mit Hilfe des DLS-Testfallgenerators kann die Anforderung der minimalen Mehrfachbedingungsüberdeckung im Testgeschehen vollständig und zugleich kostengünstig erfüllt werden.

Zu den Vorteilen der Modultests zählen,

• dass Fehler frühzeitig erkannt und behoben werden;
• dass im Falle eines Fehlers dieser ganz genau eingegrenzt werden kann;
• dass die Tests rasch wiederholt werden können und dadurch Regressionen im Bereich der Software-Entwicklung vermieden werden können.

Es ist schwer zwischen Modultest und Komponententests zu unterscheiden. In englischsprachigen Werken wird zwischen "Unit tests" und "Component tests" unterschieden. Für die deutschsprachige Wikipedia sind diese Begriffe Synonyme.

Eine zu testende Einheit kann ein ganzes Software-Modul oder auch nur eine individuelle Funktion (oder Methode) sein.

Unter dem Begriff "Modultests" verstehen wir den Test einzelner Funktionen (oder Methoden). Unter dem Begriff "Komponententest" verstehen wir den Tests von ganzen Modulen (oder Objekten).

Integrationstests können wahlweise als "White-Box-Tests" oder als "Black-Box-Tests" ausgeführt werden.

Über Software-Integrationstests wird nachgewiesen, dass nach Zusammenführung von Software-Komponenten des Systems, sowohl diese Komponenten für sich noch spezifikationsgemäß funktionieren, als auch der Datenaustausch über die gemeinsame(n) Schnittstelle(n) spezifikationsgemäß funktioniert.

Bei sehr kleinen Software-Projekten ist ein manueller Test denkbar. In aller Regel sind die Integrationstests aber (auch) aus Kostengründen zu automatisieren.

Bei einem Systemtest wird das gesamte System gegen die gesamten Anforderungen (funktionale und nicht-funktionale Anforderungen) getestet. Der Test soll auf einer eigenen Testumgebung stattfinden, die in ihrem Aufbau und ihrer Funktionalität dem finalen System entspricht.

Der Abnahmetest ist ein "Black-Box-Test" bei dem Sie als Kunde das Verhalten der Software bei spezifizierten Vorgängen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung etc.) überprüfen.

Im Rahmen von Abnahmetests soll nicht nur das Verhalten der Software im Regelfall geprüft werden. Wichtig ist es auch sicherzustellen, dass die Software auch auf mögliche Fehlbedienungen durch den Anwender wie gefordert reagiert.