andagon Team · 08.06.2022 · 17 Min. Lesezeit
Viele Schwierigkeiten in IT-Projekten entstehen durch Wissensunterschiede zwischen den IT-Experten und Projektmanagern sowie Fachpersonal. Ein Bereich, in dem das immer wieder deutlich wird, ist die Testphase von Software.
Die Bedeutung von Softwaretests
Oftmals haben Testmanager keinen ausgeprägten IT-Hintergrund und können inhaltlich nur schwer mit den Testern kommunizieren. Für sie ist der Testprozess eine Blackbox, in der sie auf die Fähigkeiten der Tester vertrauen müssen. Schildern die Tester wiederum ihre Perspektive, so fällt es ihnen schwer, die Komplexität herunterzubrechen. Das Ergebnis ist ein gemeinsames Ausprobieren und darauf vertrauen, dass am Ende alle Punkte abgedeckt wurden.
Um dieses Vorgehen zu optimieren, ist ein Grundverständnis für die verschiedenen Bereiche des Testens hilfreich. Wenn ein Testmanager oder Projektmanager eine Idee hat, welche Relevanz ein bestimmter Testbereich hat und wie sich dieser von anderen unterscheidet, kann konkreter gehandelt und entschieden werden. Auch die Kommunikation mit den Testern selbst wird so erleichtert.
Die Relevanz von effizienten Tests lässt sich gut am Beispiel eines Autos verstehen. Im vereinfachten Herstellungsprozess findet zuerst die Planung statt. Mit Zeichnungen und Modellen werden die notwendigen Funktionen und das Aussehen konstruiert. Anhand dieser Vorgaben werden die unterschiedlichen Teile gefertigt und schlussendlich zusammengesetzt. Jetzt ist das Auto in der Theorie fertig. In der Praxis muss es jetzt jedoch erst gründlich getestet werden, bevor es verkauft und auf die Straße entlassen wird.
Es wird nicht nur getestet, ob es fährt und die Lenkung und Beschleunigung funktioniert. Ein Auto wird unter unterschiedlichsten Bedingungen, auch in extremen Situationen, ausprobiert, um die Sicherheit im Straßenverkehr sicherzustellen. Wenn im Test etwas nicht funktioniert, dann ist das unangenehm, aber kann mit einigen Kosten korrigiert werden. Stellt sich erst später eine Fehlfunktion heraus, sind die Folgen weitreichend: Rückrufe, hohe Kosten, Neuproduktionen und im schlimmsten Fall lebensbedrohliche Situationen für Menschen.
In Bezug auf Software sind die Folgen weniger anschaulich, das Prinzip ist jedoch das gleiche. Je früher ein Fehler im Prozess korrigiert wird, umso günstiger und unkomplizierter ist dies möglich. Die Tests sind die letzte Chance vor dem Einsatz in der Produktion, mögliche Fehler zu identifizieren und zu beseitigen. Dabei kann der Fokus auf unterschiedliche Bereiche gelegt werden. Neben funktionalen Tests kann die Belastung von Ressourcen und die Reaktion der Software in extremen Situationen festgestellt werden. Solche nicht funktionalen Tests werden in diesem Artikel anschaulich erklärt und verglichen.
Nicht funktionale Tests unter der Lupe
Der Bereich der Softwaretests deckt eine große Bandbreite an unterschiedlichen Tests ab. Die Tests, die meistens zuerst in den Sinn kommen, sind die funktionalen Tests. Macht die Software, was sie soll? Ergibt eine bestimmte Eingabe das erwartete Ergebnis? Arbeiten die Komponenten nicht nur einzeln korrekt, sondern auch zusammen?
Dem gegenüber stehen die nicht funktionalen Tests. Sie sind weniger offensichtlich, aber nicht weniger wichtig. Bei diesen Tests wird das Verhalten in Bezug auf die Ressourcen und deren Verbrauch getestet. Wie lange dauert es, bis eine Funktion ihr Ergebnis ausgibt? Wie viel Arbeitsspeicher benötigt die Software bei unterschiedlicher Belastung? Wie reagiert die Software auf Sicherheitsangriffe?
Ergänzt werden diese beiden Arten durch Regressionstests. Sie dienen dem Erhalt der Software. Das Durchlaufen nach jeder Softwareänderung stellt sicher, dass die bisherigen Funktionen sowie die bisherige Performance nicht beeinträchtigt wurden.
Der Fokus des Artikels liegt auf den nicht funktionalen Tests. Die Kategorien Performancetest, Lasttest und Stresstest werden hier definiert. In anderen Quellen kann auf andere Begriffe oder eine andere Unterteilung getroffen werden. Weniger wichtig als die exakte Bezeichnung ist das Verständnis der unterschiedlichen Bereiche, die in den Test mit einbezogen werden können. In vielen Fällen werden in Unternehmen englische Begriffe im IT-Bereich verwendet. Die deutsche Übersetzung unterscheidet sich oftmals. Daher werden zusätzlich zu der hier verwendeten Übersetzung die originalen Begriffe aus dem Englischen genannt.
Definition Performancetest (performance test)
Unter Performancetests versteht man alle Tests, die sich auf die Leistung beziehen. Der Begriff ist weit gefächert und kann auch als Überbegriff für Lasttests und Stresstests stehen. Hier werden Tests, die mit einer durchschnittlichen Last durchgeführt werden, darunter verstanden. Dabei werden die Skalierbarkeit, die Reaktionsgeschwindigkeit, die Fehlerrate sowie der Ressourcenverbrauch bei unterschiedlicher Last betrachtet. Je nach Software werden diese Tests in unterschiedlichen Testumgebungen und Betriebssystemen durchgeführt. Die erhaltenen Ergebnisse werden gesammelt und miteinander verglichen. Etwaige Fehlerquellen oder Möglichkeiten zur Steigerung der Leistung können so ermittelt werden.
Am Beispiel des Autos: Wie schnell beschleunigt das Auto von 0 auf 100 km/h? Hält das Auto die Spur bei Seitenwind und Regen? Gibt es Unterschiede bei der Fahrt auf Asphalt und der Fahrt auf Sand?
Definition Lasttest (load test)
Bei der Durchführung von Lasttests wird das Ziel einer möglichst realistischen Lasterzeugung verfolgt. Eine Software hat bestimmte Anforderungen an eine maximale Anzahl gleichzeitiger Nutzer oder Anfragen. Genau diese hohe Belastung wird auf das System ausgeübt und das Verhalten wird entsprechend dokumentiert. Diese Tests sind unter anderem auch zur Sicherstellung von Service Level Agreements (SLA) wichtig. Mit Lasttests wird geprüft, ob sich die Software sich auch unter starker Belastung möglichst fehlerfrei verhält. Die primär getestete Eigenschaft ist die Stabilität der Anwendung.
Am Beispiel des Autos: Verändert sich das Fahrverhalten bei 5 Insassen inklusive vollem Kofferraum? Fährt das Auto über längere Zeit ohne Probleme an der Geschwindigkeitsobergrenze? Kommt der Motor auch mit extremen Temperaturen von -20 °C bis +40 °C und einer Höhe über 2000 Meter zurecht?
Definition Stresstest (stress test)
Ein Stresstest soll das System wortwörtlich unter Stress setzen. Es wird einer Last ausgesetzt, für die es eigentlich nicht ausgelegt ist. Dabei wird herausgefunden, bis zu welcher Last das System noch funktioniert und welche Last die Funktionsfähigkeit beeinträchtigt. Im Idealfall stürzt die Software nicht ab, sondern zeigt eine Fehlermeldung an oder reguliert sich selbst. Es wird getestet, ob die Funktionsweise nach einer Überlastung wieder einwandfrei ist oder Schäden zurückbleiben. Zusätzlich können der Anwendung im laufenden Betrieb Verbindungen oder Rechte genommen werden und die Reaktion darauf wird betrachtet. So wird die Robustheit einer Software evaluiert.
Am Beispiel des Autos: Wie stark muss der Aufprall des Autos sein, damit sich der Airbag aufbläst? Was passiert, wenn der Tank vollständig leergefahren wird, gibt es Schäden? Wie verhält sich der Motor, wenn der falsche Kraftstoff getankt wird?
Performancetest, Lasttest und Stresstest im direkten Vergleich
Header | Performancetest | Lasttest | Stresstest |
---|---|---|---|
Ziel | Durch das Testen der Software unter unterschiedlich starker Belastung werden Bottlenecks in der Leistungsfähigkeit erkannt. Außerdem können Kennzahlen für die Leistung der Software definiert werden, die für den Einsatz wichtig sind. | Mit einer realistisch hohen Last soll das Verhalten der Software im Normalbetrieb mit den erwarteten Lastspitzen betrachtet werden. So kann ein stabiler Betrieb auch bei hoher Last gewährleistet werden. | Mit Stresstests wird geprüft, ab welcher Belastung die Software nicht mehr fehlerfrei funktioniert und wie sie darauf reagiert. Ebenso wird geprüft, ob durch unerwartete Situationen Schäden entstehen. |
Getestete Eigenschaften | Leistungsfähigkeit und Skalierbarkeit | Stabilität | Robustheit |
Ausgeübte Last | Durchschnittliche Last | Hohe Last | Extreme, zu hohe Last |
Ergebnis | Übersicht über die Leistungsfähigkeit der Software, mit der ein Standard festgelegt werden kann | SLAs festlegen und Identifikation von Fehlern im Speichermanagement und Ressourcenverbrauch | Identifikation der Belastungsgrenzen und Erkennen von Schäden durch Systemversagen |
Voraussetzung | Funktionalität der Software ist weitestgehend fehlerfrei | Standards wurden durch Performancetests definiert, sodass ein Vergleich bei hoher Last möglich ist | Testumgebung sollte nicht gleichzeitig für funktionale Tests genutzt werden |
Häufigkeit | Vor jedem Softwareupdate | Mindestens vor jedem Release und vor Ereignissen mit besonders hoher Last | Bei komplexen Softwareänderungen und Änderungen der Umgebung wie Datenbank oder Betriebssystem |
Durchführung | Nutzung von Automatisierungstools | Nutzung von Automatisierungstools | Nutzung von Automatisierungstools sowie manuelles Eingreifen |
Die Anwendung nicht funktionaler Tests
Testfälle entstehen aus Anforderungen
Die Grundvoraussetzungen für die Durchführung von Performancetests, Lasttests und Stresstests unterscheiden sich wenig und werden deswegen zusammengefasst betrachtet. Ebenso wie bei funktionalen Tests müssen entsprechende Anforderungen für die Erstellung von Testfällen für nicht funktionale Tests existieren. Für eine saubere und umfangreiche Testphase sind also klar definierte Anforderungen im Pflichtenheft die Voraussetzung. Dies können Angaben zur minimalen Verarbeitung von Aufträgen in der Minute oder das Verhindern eines Datenverlusts bei Systemabsturz sein. Aus diesen Vorgaben kann der Tester konkrete Testfälle ableiten, dessen Ergebnis entweder bestanden oder nicht bestanden ist.
Bei Performancetests, was ebenso die Lasttests und Stresstests mit einbezieht, sollte der Ressourcenverbrauch in Bezug auf Zeit, Speicherplatz und Arbeitsspeicher überwacht werden. Dies ist vor allem zur Überprüfung von Testergebnissen notwendig. Zusätzlich hilft die Gesamtübersicht in Zusammenhang mit der unterschiedlichen Last und der Anzahl von Benutzern dabei, mögliche Schwachstellen aufzudecken. Die Auswertung von Log-Dateien kann ebenfalls Auskunft über Fehler geben, die durch starke Belastung verursacht werden. Diese allgemeine Durchsicht und Analyse ersetzten jedoch keinesfalls das Ausarbeiten von Testfällen.
Einrichtung der Testumgebung
Die Erstellung der Testfälle kann bereits während der Entwicklung stattfinden. Für die Durchführung der Tests ist es jedoch notwendig, dass die Software bereits größtenteils die funktionalen Anforderungen erfüllt. Jede Änderung der Funktionalität kann Auswirkungen auf die Performance haben. Deswegen lohnt sich der Testaufwand am meisten, wenn das Grundgerüst der Funktionen bereits auf einem sicheren Fundament steht.
Es ist empfehlenswert, die Durchführung von funktionalen und nicht-funktionalen Tests in unterschiedliche Testumgebungen zu verlagern. Besonders für Lasttests und Stresstests, jedoch auf bei Performancetests, ist eine produktionsähnliche Umgebung unerlässlich, um relevante Ergebnisse zu erzielen. Wenn die nicht funktionalen Tests getrennt von den funktionalen Tests durchgeführt werden, kann eine gegenseitige Beeinflussung ausgeschlossen werden.
Während funktionale Tests oft nur einen Datensatz betrachten, wird für die Performancetest eine Reihe von Daten in das System geführt. Bei erneuter Durchführung kann das Zurücksetzen der Datenbank sinnvoll sein, während bei funktionalen Tests die Daten weiterhin benötigt werden können. So können verschiedene Tests parallel durchgeführt werden und Einschränkungen werden vermieden.
Automatisierung von Testdurchläufen
Sowohl bei Performancetests, als auch bei Lasttests und Stresstests ist die Verarbeitung von mehreren Aufträgen zur selben Zeit notwendig. Manuell lässt sich dies nur sehr schwer und bei größerer Menge von Aufträgen oder Nutzern gar nicht mehr durchführen. Um eine große Verarbeitungsmenge zu schaffen, sind zwei Punkte genauer zu betrachten: Generierung von Testdaten und Automatisierung manueller Eingriffe.
Für die Generierung von Testdaten gibt es verschiedene Möglichkeiten. Mit dafür geeigneten Tools lassen sich diese Daten automatisch erstellen. Dabei ist es wichtig, ein besonderes Augenmerk auf Datenfelder zu legen, die in der Datenbank nicht doppelt vorkommen dürfen. So müssen ID-Felder zum Beispiel meistens einzigartig sein. Werden Testdaten genau einmal erstellt, so muss nach jedem Testdurchlauf das System in den Originalzustand zurückversetzt werden. Bei dynamischer Generierung im Testablauf können für weitere Tests neue Daten erzeugt werden. Ist eine Software bereits in der Produktion und die Tests werden für Softwareänderungen durchgeführt, so können auch tatsächliche Daten aus der Produktion für die Tests verwendet werden.
Viele Anwendungen erfordern in der Verarbeitung von Daten die Interaktion mit dem Benutzer oder kommunizieren über Schnittstellen mit anderen Systemen. In der Testumgebung fehlt oftmals die Anbindung an andere Systeme und einzelne Tester können die große Datenmenge im Test nicht interaktiv bewältigen. Damit die Tests ohne manuelles Eingreifen durchlaufen und realistische Ergebnisse entstehen, müssen Interaktionen automatisiert werden. Dies kann anhand von Skripten gelöst werden. Skripte fassen eine Reihe von Befehlen zusammen, die nacheinander ausgeführt werden. Sie können Eingaben von Benutzern simulieren oder Daten manipulieren. Soll die Verarbeitungszeit eines angeschlossenen Systems realistisch dargestellt werden, kann im Skript eine Antwortverzögerung inkludiert werden. Sie stellen neben der Automatisierung eine wichtige Stellschraube in der erzeugten Last auf das System dar.
Tooleinsatz im Testmanagement
Schlussendlich wird ein Tool benötigt, das die Tests im Gesamtbild verwaltet. Ein Test hat nur durch die Bewertung des Testergebnisses einen Wert. Gerade im Umfeld von Performancetests, wo nicht nur bestanden und nicht bestanden zählen, sondern Kennzahlen ermittelt werden, ist die Zusammenfassung und Darstellung der Ergebnisse besonders wichtig. Über Schnittstellen können die erhaltenen Daten in Reportingtools exportiert werden. Dies bildet die Grundlage für die Festlegung von SLAs mit dem Kunden.
Dieses Tool wird im Idealfall schon in der Erstellung der Testfälle genutzt. Jeder Testfall sollte sich auf eine nicht funktionale Anforderung des Pflichtenhefts beziehen. Im Testtool lässt sich diese Verknüpfung herstellen und bietet dem Testmanager so einen guten Überblick der Testabdeckung. Je nach Einrichtung der IT-Landschaft in der Testumgebung können die Tests direkt über das Tool gestartet werden. Während der Testphase kann der Fortschritt verfolgt werden. Nicht bestandene Testfälle werden an die entsprechenden Experten weitergeleitet, sodass die Probleme gelöst werden können. Mithilfe eines passenden Tools lässt sich die Testphase sowohl bei Wasserfall-Methoden als auch im agilen Umfeld überwachen und steuern.
Testfälle anhand einer Beispielanwendung
Um die Prioritäten bei Performancetests, Lasttests und Stresstests noch stärker herauszuarbeiten, wird eine Beispielanwendung mit zugehörigen beispielhaften Testfällen beschrieben. Die Anforderungen und Testfälle werden zum besseren Verständnis stark vereinfacht.
Header | Header |
---|---|
Zweck der Anwendung | Buchungssystem für Konzerttickets für Privatkunden |
Art der Anwendung | Webanwendung, lauffähig auf allen Geräten mit allen Browsern |
Durchschnittliche Anzahl gleichzeitiger Nutzer | 500 |
Maximale Anzahl gleichzeitiger Nutzer | 5.000 bei Veröffentlichung Tickets berühmter Künstler |
Verhalten bei Überschreiten der maximalen Anzahl gleichzeitiger Nutzer | Anzeige von Meldung: Die Seite ist aktuell überlastet. Bitte rufen Sie sie später erneut auf. |
Ladezeit der Anwendung | 3 Sekunden; bei hoher Last maximal 10 Sekunden |
Erreichbarkeit | 24/7 an jedem Tag im Jahr |
Schnittstellen | Datenbank der Anwendung, Benutzeroberfläche, zentrales System des Veranstalters zur Ticketverfügbarkeit, Zahlungsdienstleister |
Testfälle für Performancetests
Testfall 1 – Überprüfung der Ladezeit
Die Website wird von einem Nutzer auf einem Windows Rechner mit Google Chrome aufgerufen. Es finden keine weiteren Zugriffe parallel statt.Überwachte Daten: Anzahl und Dauer der Datenbankzugriffe, Dauer des Ladens von Grafiken, InternetgeschwindigkeitErwartetes Ergebnis: Das Laden der Website dauert maximal 3 Sekunden.__Mögliche Ergebnisse und Bewertung: __
- Die Website lädt in 2,5 Sekunden – der Testfall ist bestanden.
- Die Website benötigt 5 Sekunden zum Laden – der Testfall ist nicht bestanden und die Ursachen müssen geprüft werden, wobei die überwachten Daten mit einbezogen werden.
Testfall 2 – Vergleich der Ladezeiten unterschiedlicher Browser
Die Website wird von einem Nutzer auf einem Windows Rechner mit Firefox aufgerufen. Es finden keine weiteren Zugriffe parallel statt. Testfall 1 wurde zuvor durchgeführt.Überwachte Daten: Anzahl und Dauer der Datenbankzugriffe, Dauer des Ladens von Grafiken, InternetgeschwindigkeitErwartetes Ergebnis: Das Laden der Website dauert maximal 3 Sekunden.Mögliche Ergebnisse und Bewertung: Die Website lädt in 1,5 Sekunden – der Testfall ist bestanden. Im Vergleich zu Testfall 1 ist dies jedoch deutlich schneller.Mögliche Auswirkungen der Betriebssysteme und Browser auf die Geschwindigkeit werden geprüft.
Testfall 3 – Überprüfung der Ladezeit bei parallelen Zugriffen
Die Website wird von 100 Nutzern parallel von unterschiedlichen Geräten in unterschiedlichen Browsern aufgerufen. Bei einzelnen Zugriffen wurde die Ladezeit von 3 Sekunden nicht überschritten.Überwachte Daten: Anzahl und Dauer der Datenbankzugriffe, Dauer des Ladens von Grafiken, InternetgeschwindigkeitErwartetes Ergebnis: Das Laden der Website dauert jeweils maximal 3 Sekunden.__Mögliche Ergebnisse und Bewertung: __
- Die Website lädt in bei allen Fällen in weniger als maximal 3 Sekunden – der Testfall ist bestanden.
- Die Website lädt bei 30 von 100 Fällen langsamer als 3 Sekunden – es wird geprüft, ob die höhere Anzahl gleichzeitiger Zugriffe sich auf die Geschwindigkeit auswirkt.
Testfälle für Lasttests
Testfall 1 – Verhalten bei hoher Last durch viele parallele Nutzer
Die Webanwendung wird von 4.000 Nutzern gleichzeitig verwendet. Jeder Nutzer bucht jeweils ein Ticket für dasselbe Konzert am selben Datum. Es stehen ausreichend Tickets zur Verfügung. Unterschiedliche Zahlungsmethoden werden verwendet. Die Aufrufe finden im Abstand von 0,1 Sekunden zueinander statt.
Voraussetzung: Für die Übermittlung der verfügbaren Tickets existiert ein Skript, da die Anbindung an das System nur in der Produktion besteht. Die Kommunikation mit Zahlungsdienstleistern für Kreditkarten und PayPal wird ebenfalls durch ein Skript ersetzt.Überwachte Daten: Log-Dateien von Webanwendung und Datenbank, ArbeitsspeicherErwartetes Ergebnis: Jeder Nutzer bekommt fehlerfreie Daten angezeigt. Die Ladezeiten unterscheiden sich nicht von denen, die bei weniger Nutzern ermittelt wurden. Die Buchung ist erfolgreich.__Mögliche Ergebnisse und Bewertung: __
- Alle Buchungen sind erfolgreich, es treten keine Fehler und lange Wartezeiten auf – der Testfall ist bestanden.
- Bei den letzten 1000 Nutzern lädt die Website jeweils 10 Sekunden – das Ergebnis überschreitet den Maximalwert nicht, Gründe für die Verzögerung sollten trotzdem ermittelt werden.
Testfall 2 – Überprüfung der Funktionsfähigkeit bei maximaler Anzahl Nutzer
Die Webanwendung wird von 5.000 Nutzern gleichzeitig verwendet. Jeder Nutzer bucht jeweils ein Ticket für dasselbe Konzert am selben Datum. Es stehen 4.500 Tickets zur Verfügung. Die Aufrufe finden im Abstand von 0,1 Sekunden zueinander statt.Voraussetzung: Für die Übermittlung der verfügbaren Tickets existiert ein Skript, da die Anbindung an das System nur in der Produktion besteht. Der gleiche Test wurde bei 2.000 parallelen Nutzern bestanden.Überwachte Daten: Log-Dateien von Webanwendung und Datenbank, Arbeitsspeicher, übermittelte Daten von/an TicketsystemErwartetes Ergebnis: Die letzten 500 Nutzer können kein Ticket mehr kaufen, weil diese nicht mehr verfügbar sind.__Mögliche Ergebnisse und Bewertung: __
- Die letzten 500 Nutzer bekommen angezeigt, dass keine Tickets mehr zur Verfügung stehen – der Testfall ist bestanden.
- Insgesamt werden 4600 Tickets gekauft – der Testfall ist nicht bestanden. Die Prozesse im Zusammenhang mit der Ticketschnittstelle laufen unter hoher Last nicht richtig. Log-Dateien und Überlastungen sind zu prüfen.
Testfälle für Stresstests
Testfall 1 – Verhalten bei Überschreitung der maximalen Nutzer
Die Webanwendung wird von 6.000 Nutzern gleichzeitig verwendet. Die Website wird von allen Nutzern parallel aufgerufen.Überwachte Daten: Log-Dateien von Webanwendung, Datenbank und Server, ArbeitsspeicherErwartetes Ergebnis: Jedem Nutzer wird die Meldung „Die Seite ist aktuell überlastet. Bitte rufen Sie sie später erneut auf.“ angezeigt.__Mögliche Ergebnisse und Bewertung: __
- Es wird jedem Nutzer die festgelegte Fehlermeldung angezeigt – der Testfall ist bestanden.
- Die Nutzer erhalten den Statuscode 503 (Service Unavailable) – der Testfall ist nicht bestanden. Die Überlastung der Webanwendung wird nicht erkannt und abgefangen, sondern ungefiltert an den Nutzer weitergegeben. Der Grund dafür muss anhand der überwachten Daten geprüft werden.
Testfall 2 – Reaktion auf das Schließen der Datenbankverbindung
Die Webanwendung wird von 3.000 Nutzern parallel verwendet. Während des Buchungsvorgangs einiger Nutzer wird die Verbindung zur Datenbank geschlossen. Anschließend wird die Verbindung wieder hergestellt.Voraussetzung: Für die Übermittlung der verfügbaren Tickets existiert ein Skript, da die Anbindung an das System nur in der Produktion besteht. Die Kommunikation mit Zahlungsdienstleistern für Kreditkarten und PayPal wird ebenfalls durch ein Skript ersetzt.Überwachte Daten: Datenbank, Log-Dateien der Webanwendung, Daten von/an ZahlungsdienstleisterErwartetes Ergebnis: Die Daten von Kunden, deren Daten bereits an den Zahlungsdienstleister übermittelt wurden, sind weiterhin in der Datenbank vorhanden. Entsprechende Daten über gekaufte Tickets werden nach dem Neustart an das Ticketsystem übermittelt. Ist die Verfügbarkeit nicht mehr vorhanden, so wird der Zahlungsprozess storniert.__Mögliche Ergebnisse und Bewertung: __
- Das erwartete Ergebnis tritt ein und für geleistete Zahlungen werden entweder Tickets zur Verfügung gestellt oder die Zahlungen storniert – der Testfall ist bestanden.
- Kunden, die bereits Geld bezahlt haben, erhalten keine weitere Rückmeldung und kein Ticket – der Testfall ist nicht bestanden. Zu prüfen ist, ob die Kundendaten noch in der Datenbank vorhanden sind. Wenn ja, dann sollte ein Blick auf die Kommunikation mit dem Ticketsystem geworfen werden.
- Beim erneuten Verbinden der Datenbank wird die Anwendung fehlerhaft angezeigt – der Testfall ist nicht bestanden. Möglicherweise sind durch das plötzliche Trennen der Verbindung Daten verloren gegangen. Die Ursache muss geklärt werden und präventive Maßnahmen müssen eingerichtet werden.
Gute Software durch den gezielten Einsatz von Softwaretests
Wie bereits zu Beginn verdeutlicht, sind die Tests ein wichtiger Bestandteil im Prozess der Softwareentwicklung. Anhand der Tests wird festgestellt, ob die in der Theorie beschriebene Anwendung in der Praxis funktioniert. Im Test werden theoretische Anforderungen gegen das tatsächliche Verhalten abgeglichen.Während dieser Abgleich für funktionale Anforderungen schon während des Entwicklungsprozesses durch den Entwickler selbst möglich ist, zeigt sich die erfolgte Umsetzung von nicht funktionalen Anforderungen meistens erst in der Testphase. Erst beim Zusammenspiel aller Komponenten und der Belastung der Anwendung durch mehrere Nutzer werden Auswirkungen auf die Perfomance deutlich.Die Perfomance ergibt sich meistens nicht aus dem, was implementiert wurde, sondern wie es implementiert wurde. Hier zeigt sich unsaubere Arbeit in der Entwicklung. Falsch angelegte Indizes in der Datenbank führen selten bei einer einzelnen Anfrage zu Problemen. Werden die Zugriffe auf die Datenbank jedoch erhöht, machen genau solche Einstellungen den entscheidenden Unterschied in der Performance.
Abschließend wird noch einmal der Vergleich mit dem Auto verwendet. Wenn alle funktionalen Anforderungen (das was) erfüllt werden, dann hat es vier Räder und kann vorwärts und rückwärts fahren. Das allein stellt jedoch den Kunden nicht zufrieden. Genauso wichtig sind die nicht funktionalen Anforderungen (das wie). Wenn der Fahrer aussteigen muss, um vom Vorwärtsgang in den Rückwärtsgang zu schalten oder die Räder sich bei hoher Geschwindigkeit lösen, dann hat das Auto keinen Wert. Nur das Umsetzen der funktionalen und nicht funktionalen Anforderungen führt zu einem guten Produkt.
Mit dem Einsatz von Performancetests für die allgemeine Leistungsfähigkeit der Software, Lasttests zum Sicherstellen der Funktionsfähigkeit bei großer Last und Stresstests zum Prüfen des Umgangs mit Systemversagen stehen gute Werkzeuge zum Testen der nicht funktionalen Anforderungen zur Verfügung. Durch ein grundlegendes Verständnis der Relevanz dieser Tests kann das Testmanagement zielgerichteter durchgeführt werden. Dies hat wiederum besser organisierte Arbeitsabläufe und zufriedenere Kunden zur Folge.