Der Systemtest
Ein Systemtest wird durch folgende beide Punkte definiert [RBI04]:
- 1. Testphase, bei der das gesamte System gegen die Spezifikation getestet wird.
- 2. Test eines Gesamtsystems gegen seine Anforderungen.
Entsprechend der Qualitätseigenschaften kann der Systemtest in zwei Gruppen unterteilt werden. Im Folgenden werden diese zwei Gruppen, bezogen auf einzelne Qualitätseigenschaften eines Softwaresystems, näher betrachtet.
Funktionaler Systemtest
Der funktionale Systemtest dient zur Überprüfung eines Systems bezüglich dessen funktionalen Qualitätsmerkmalen Korrektheit und Vollständigkeit.
Unter Korrektheit wird die Einhaltung der Erwartungen an ein Softwaresystem verstanden. In diesem Zusammenhang ist Korrektheit ein subjektiver Aspekt der
Qualitätsmerkmale. Spezifikationen und schriftliche Festlegungen, die ein System erfüllen muss, ermöglichen es, die Korrektheit eines Systems zu objektivieren. vgl. [LIG00] (S. 8)
Basierend auf den Spezifikationen und schriftlichen Festlegungen kann festgestellt werden, ob ein System als vollständig umgesetzt gilt. Kann ein System diese festgelegten Normalfälle und Fehlersituationen behandeln, gilt es als funktional vollständig. vgl. [LIG00] (S. 9)
Bei klassischen Softwareentwicklungsprozessen finden funktionale Systemtests vor der Auslieferung eines Systems statt. In moderneren Konzepten werden Systeme in mehreren Iterationen entwickelt. Am Ende jeder Iteration wird hierbei ein Systemtest durchgeführt. Dies kann dazu führen, dass extrem viele Systemtests notwendig werden. Werden diese Tests nicht in einer stark automatisierten Art und Weise definiert bzw. durchgeführt, überwiegen die entstehenden Kosten dieser Tests meist dem Nutzen den sie erbringen. vgl. [MAR03].
Nicht funktionaler Systemtest
Nicht funktionale Qualitätsmerkmale, wie z.B. die Sicherheit oder die Zuverlässigkeit eines Systems, werden über den nicht funktionalen Systemtest einer Prüfung unterzogen.
Bei einem Softwaresystem umfasst der Begriff Sicherheit die Eigenschaft eines Systems, unbefugten Datenzugriff und Informationsverluste zu vermeiden. vgl. [LIG00] (S. 9) Für Systemtests, die sich mit der Sicherheit eines Systems befassen, ist ein Tester mit hoher Fachkompetenz von Nöten.
Von modernen Softwaresystemen wird erwartet, auf fehlerhafte Eingaben nicht mit einem Totalausfall zu reagieren. Vielmehr muss sich ein Softwaresystem auf fehlerhafte oder diskrepante Eingabedaten entsprechend seiner Spezifikation verhalten. Dieses Verhalten wird als Qualitätsmerkmal Robustheit verstanden und bedarf einer Prüfung. vgl. [LIG00] (S. 11)
Ein wichtiges nicht funktionales Qualitätsmerkmal stellt die Zuverlässigkeit eines Softwaresystems dar. Unter Zuverlässigkeit wird die Fähigkeit eines Systems verstanden, während einer festgelegten Zeitdauer ohne Ausfälle ausführbar zu sein. Die Zeitspanne eines Systems bis zum Ausfall wird als Mean Time to Failure (MTTF) angegeben. Handelt es bei dem zu testenden Softwaresystem um ein reparierbares System, wird in diesem Zusammenhang die Zeitspanne zwischen zwei Ausfällen als Mean Time between Failure (MTBF) gemessen. vgl. [LIG00] (S. 10)
Basierend auf der aus der Prüfung der Zuverlässigkeit gewonnen MTBF und der Mean Time to Repair (MTTR) ist es möglich, die Verfügbarkeit eines Softwaresystems festzustellen. Dazu kann der Quotient
MTBF / (MTBF + MTTR) (2.1)
als Maß für die Verfügbarkeit verwendet werden. Ziel ist es, einen Verfügbarkeitswert von annähernd eins zu erreichen. Dazu kann zum einen versucht werden die Zuverlässigkeit des Systems zu steigern und dadurch die Zeitspanne bis zum Ausfall eines Systems zu erhöhen. Zum anderen kann versucht werden, die Mean Time to Repair zu senken. vgl. [LIG00] (S. 10,11)
Die Benutzbarkeit, die Interoperabilität, der Konfigurationstest und die Prüfung der Dokumentation kann nicht automatisiert erfolgen. Für derartige nicht funktionale Systemtest wird die Bewertung durch einen Menschen vorausgesetzt. Aus diesem Grund werden die Qualitätsmerkmale Benutzbarkeit, Interperabilität, der Konfigurationstest und die Prüfung der Dokumentation nicht näher betrachtet.
Referenzen
[LIG00] Liggesmeyer, Peter: Qualitätssicherung softwareintensiver technischer Systeme, Spektrum Akad. Verlag, Heidelberg, Berlin, 2000, ISBN 3-8274-1085-1
[MAR03] Marick, Brian: When Should a Test Be Automated?, o.O, 2003, http:www.testing.com/writings/automate.pdf, Abfragedatum 22.02.2004
[RBI04] R&B IT-Services: Glossar, o.O., o.D., http://www.softwarelifecycle.de/glossar.htm Abfragedatum 22.02.2004