Führung im Test: Dienstprüfung
Redaktioneller Hinweis: Willkommen zur Leadership In Test-Serie von Softwaretest-Guru & -Berater Paul Gerrard. Diese Serie soll Testern mit einigen Jahren Berufserfahrung – insbesondere solchen in agilen Teams – helfen, in ihren Rollen als Testleiter und Manager zu glänzen.
Im vorherigen Artikel haben wir uns die sich wandelnde Rolle von Testern angesehen und wie man die Zusammenarbeit mit Kollegen fördert. In diesem Artikel befassen wir uns mit den Grundlagen des Testens von Leistungsfähigkeit, Zuverlässigkeit und Wartbarkeit einer Webanwendung – auch bekannt als Servicetests.
Melde dich für den The QA Lead-Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Serie online gehen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs, den wir sehr empfehlen, um tiefer in dieses und andere Themen einzutauchen. Nutze dabei unseren exklusiven Gutscheincode QALEADOFFER, um $60 Rabatt auf den vollen Kurspreis zu erhalten!
Hallo und willkommen zu einem weiteren Kapitel der Leadership In Test-Serie. Diese Woche schauen wir uns das Service Testing für Webanwendungen an. Wir behandeln:
- Was ist Service Testing?
- Was ist Performance Testing?
- Zuverlässigkeits- / Ausfallsicherheitstests
- Tests zur Serviceverwaltung
Fangen wir an.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Was ist Service Testing?
Die Servicequalität einer Webanwendung könnte so definiert werden, dass sie all ihre Eigenschaften umfasst, wie Funktionalität, Leistung, Zuverlässigkeit, Bedienbarkeit, Sicherheit und so weiter.
Hier unterscheiden wir jedoch drei besondere Serviceziele, die unter die Kategorie „Service Testing“ fallen. Diese Ziele sind:
- Leistung: Der Service muss reaktionsschnell zu den Benutzern sein, während er die aufkommenden Lasten bewältigt.
- Zuverlässigkeit: Wenn die Anwendung darauf ausgelegt ist, ausfallsicher zu sein, muss der Service zuverlässig sein und/oder auch im Fehlerfall weiterhin einen Dienst bereitstellen.
- Wartbarkeit: Der Service muss so verwaltbar, konfigurierbar oder veränderbar sein, dass für Endanwender keine Verschlechterung des Diensts spürbar ist. Wartbarkeit, oder auch Operationstests, sollen zeigen, dass systemadministrative, managementbezogene sowie Backup- und Wiederherstellungsprozeduren wirksam funktionieren.
In allen drei Fällen müssen wir die Nutzerbelastung simulieren, um die Tests effektiv durchzuführen. Zielvorgaben zu Leistung, Zuverlässigkeit und Wartbarkeit existieren im Kontext echter Nutzer, die die Plattform geschäftlich nutzen.
Die Reaktionsgeschwindigkeit (also in diesem Zusammenhang die Zeit, die ein Systemknoten benötigt, um auf eine Anforderung eines anderen Knotens zu reagieren) einer Website steht in direktem Zusammenhang mit den verfügbaren Ressourcen der technischen Architektur.
Je mehr Kunden den Service nutzen, desto weniger technische Ressourcen stehen für die einzelnen Nutzeranfragen bereit und die Antwortzeiten verschlechtern sich.
Offensichtlich ist ein Dienst mit geringer Last weniger anfällig für Ausfälle. Viel von der Komplexität in Software und Hardware besteht deshalb, um bei starker Belastung dem Ressourcenbedarf der technischen Architektur gerecht zu werden.
Wenn eine Website stark (oder übermäßig) ausgelastet ist, müssen konkurrierende Ressourcenanfragen durch verschiedene Infrastrukturkomponenten wie Server- und Netzwerkbetriebssysteme, Datenbankmanagementsysteme, Webserver, Objektanfragemanager, Middleware usw. verwaltet werden.
Diese Infrastrukturkomponenten sind in der Regel zuverlässiger als selbst entwickelte Anwendungscodes, die die Ressourcen anfordern, aber Ausfälle können in beiden Fällen auftreten:
- Infrastrukturkomponenten fallen aus, weil der Anwendungscode (durch schlechte Konzeption oder Umsetzung) überhöhte Anforderungen an Ressourcen stellt.
- Anwendungskomponenten können ausfallen, weil die von ihnen benötigten Ressourcen nicht immer (rechtzeitig) zur Verfügung stehen.
Durch das Simulieren typischer und außergewöhnlicher Produktionslasten über einen längeren Zeitraum können Tester Schwächen im Design oder in der Umsetzung des Systems aufdecken. Werden diese Schwächen behoben, zeigen die gleichen Tests die Belastbarkeit des Systems. QAs können Load Testing Tools nutzen, um viele der unten genannten Prozesse durchzuführen.
Bei allen Services gibt es normalerweise eine Reihe kritischer Managementprozesse, die durchgeführt werden müssen, um einen reibungslosen Betrieb sicherzustellen. Es mag möglich sein, einen Service für Wartungsarbeiten außerhalb der regulären Arbeitszeiten herunterzufahren, aber die meisten Online-Services laufen rund um die Uhr.
Der Arbeitstag des Dienstes endet nie. Unweigerlich müssen Verwaltungsvorgänge während des laufenden Betriebs durchgeführt werden, wenn Benutzer auf dem System sind. Diese Vorgänge müssen getestet werden, während das System unter Last steht, um zu sichern, dass sie den laufenden Dienst nicht – zum Beispiel im Rahmen von Performance Tests – beeinträchtigen.
Was ist Performance Testing?
Performance Testing ist ein entscheidender Bestandteil des Service-Testings. Dabei wird geprüft, wie ein System in Bezug auf Reaktionsfähigkeit und Stabilität unter einer bestimmten Auslastung arbeitet. Hier ist eine Übersicht, wie es funktioniert:
- Performance Testing besteht aus einer Reihe von Tests mit unterschiedlichen Lasten, bei denen das System einen stabilen Zustand erreicht (Lasten und Antwortzeiten auf konstantem Niveau).
- Wir messen für jede Last, simuliert über einen Zeitraum von 15-30 Minuten, die Auslastung und die Antwortzeiten, um eine statistisch signifikante Anzahl von Messwerten zu erhalten.
- Wir überwachen und zeichnen die Vitalwerte für jede simulierte Last auf. Dies sind die verschiedenen Ressourcen in unserem System, z. B. CPU- und Speicherverbrauch, Netzwerkbandbreite, I/O-Raten usw.
Wir stellen die unterschiedlichen Lasten grafisch den Antwortzeiten gegenüber, die unsere „virtuellen“ Benutzer erleben. Die grafische Darstellung sieht dann in etwa so aus wie in der Abbildung unten.
Bei Null-Last, d.h. wenn nur ein einziger Benutzer aktiv ist, kann dieser Nutzer alle Ressourcen für sich beanspruchen und die Antwortzeiten sind schnell. Wenn wir die Lasten erhöhen und Antwortzeiten messen, verschlechtern sie sich zunehmend, bis wir den Punkt erreichen, an dem das System mit maximaler Kapazität arbeitet.
An diesem Punkt ist die Antwortzeit für unsere Testtransaktionen theoretisch unendlich, weil eine der Schlüsselressourcen des Systems völlig ausgelastet ist und keine weiteren Transaktionen verarbeitet werden können.
Wenn wir die Last von null bis zum Maximum erhöhen, überwachen wir auch die Nutzung verschiedener Ressourcentypen, z. B. Prozessorlast, Speicherverbrauch, Netzwerkbandbreite, Datenbank-Locks usw.
Bei höchster Auslastung ist eine dieser Ressourcen zu 100 % ausgelastet. Diese Ressource begrenzt das System, weil sie als erste erschöpft ist. Natürlich sind die Antwortzeiten in diesem Zustand auf ein Niveau gesunken, das vermutlich längst nicht mehr akzeptabel ist.
Das folgende Diagramm zeigt die Nutzung/Verfügbarkeit mehrerer Ressourcen im Vergleich zur Last.
Um die Durchsatzkapazität zu erhöhen und/oder die Antwortzeiten eines Systems zu verkürzen, müssen wir Eines der Folgenden tun:
- Den Bedarf an der Ressource reduzieren, typischerweise indem die Software, die diese Ressource nutzt, effizienter gemacht wird (das ist meist Aufgabe der Entwicklung).
- Die Nutzung der Hardware-Ressource innerhalb der technischen Architektur optimieren, zum Beispiel indem das DBMS so konfiguriert wird, dass mehr Daten im Speicher zwischengespeichert werden, oder indem Prozesse auf dem Applikationsserver priorisiert werden.
- Mehr Ressourcen bereitstellen, in der Regel durch Hinzufügen von Prozessoren, Speicher oder Netzwerkbandbreite usw.
Wie Sie sicher schon ahnen, benötigt man für Performance Testing ein Team, das die Tester unterstützt. Dazu gehören technische Architekten, Server-Administratoren, Netzwerk-Administratoren, Entwickler sowie Datenbank-Designer/Administratoren. Diese technischen Experten sind in der Lage, die mit Monitoring-Tools generierten Statistiken zu analysieren und entscheiden zu können, wie die Applikation angepasst oder das System optimiert bzw. aufgerüstet werden sollte.
Wenn Sie der Tester sind, sollten Sie – sofern Sie nicht selbst Experte auf diesen Gebieten sind – nicht versuchen, diese Statistiken zu interpretieren und eigenständig Optimierungsentscheidungen zu treffen. Sie sollten diese Experten frühzeitig in Ihr Projekt einbinden, um deren Rat und Unterstützung zu erhalten, und sie später während der Tests hinzuziehen, damit Engpässe erkannt und beseitigt werden können.
Im nächsten Artikel sehen wir uns genauer an, wie man Performance Testing steuert.
Zuverlässigkeits-/Failover-Testing
Die fortlaufende Verfügbarkeit eines Service sicherzustellen ist wahrscheinlich ein zentrales Ziel Ihres Projekts. Zuverlässigkeitstests helfen dabei, schwer zu findende Fehler aufzudecken, die zu unerwarteten Ausfällen führen. Failover-Tests stellen sicher, dass die für erwartete Ausfälle vorgesehenen Notfallmechanismen tatsächlich funktionieren.
Failover-Testing
Wo Ausfallsicherheit und/oder Zuverlässigkeit erforderlich sind, werden Sites oft mit zuverlässigen Systemkomponenten entworfen, die Redundanzen und Failover-Funktionen besitzen und im Fehlerfall aktiv werden.
Zu diesen Funktionen gehören unter anderem unterschiedliche Netzwerkpfade, mehrere Server als Cluster, Software-Middleware und verteilte Servicetechnologien zur Lastverteilung sowie Umleitung von Datenverkehr im Störungsfall.
Failover-Tests haben das Ziel, vor dem Go-Live das Verhalten des Systems unter ausgewählten Ausfallszenarien zu erkunden und beinhalten normalerweise Folgendes:
- Identifikation der Komponenten, die ausfallen könnten und einen Ausfall des Dienstes verursachen können (Betrachtung von Ausfällen von innen nach außen).
- Identifikation der Gefahren, die einen Ausfall verursachen und zu einem Dienstausfall führen könnten (Betrachtung von Bedrohungen von außen nach innen).
- Eine Analyse der Ausfallmodi oder Szenarien, in denen sichergestellt werden muss, dass die Wiederherstellungsmaßnahme funktioniert.
- Ein automatisierter Test, mit dem das System belastet wird, um das Verhalten des Systems über einen längeren Zeitraum zu erkunden.
- Der gleiche automatisierte Test kann auch verwendet werden, um das zu testende System zu belasten und das Verhalten des Systems unter Ausfallbedingungen zu überwachen.
Eine Technik namens Fehlerbaumanalyse (Fault Tree Analysis, FTA) kann Ihnen helfen, die Abhängigkeiten eines Dienstes von seinen zugrundeliegenden Komponenten zu verstehen. Fehlerbaumanalysen und Fehlerbaumdiagramme sind eine logische Darstellung eines Systems oder Dienstes und der Möglichkeiten, wie dieses ausfallen kann.
Das einfache Schema unten zeigt das Verhältnis zwischen grundlegenden Ausfallereignissen von Komponenten, den Ausfallereignissen von Zwischensystemen und dem übergeordneten Dienst-Ausfallereignis. Natürlich könnten mehr als drei Ebenen von Ausfallereignissen identifiziert werden.
Diese Tests müssen mit automatisierter Last durchgeführt werden, um das Verhalten des Systems in Produktionssituationen zu untersuchen und Vertrauen in die eingebauten Wiederherstellungsmaßnahmen zu gewinnen. Insbesondere möchten Sie wissen:
- Wie verhält sich die Architektur in Ausfallsituationen?
- Funktionieren die Lastverteilungsmechanismen korrekt?
- Können die Failover-Funktionen die Last aufnehmen, wenn eine Komponente ausfällt?
- Findet die automatische Wiederherstellung statt? Holen neu gestartete Systeme auf?
Letztendlich richten sich die Tests darauf, festzustellen, ob der Dienst für Endnutzer aufrechterhalten wird und ob die Nutzer den Ausfall überhaupt bemerken.
Zuverlässigkeits- (oder Dauer-)tests
Zuverlässigkeitstests zielen darauf ab zu überprüfen, dass unter Last keine Ausfälle auftreten.
Die meisten Hardware-Komponenten sind so zuverlässig, dass ihre mittlere Zeit zwischen Ausfällen in Jahren gemessen werden kann. Für Zuverlässigkeitstests müssen automatisierte Tests auf zwei Arten genutzt (oder wiederverwendet) werden, um zu simulieren:
- Extreme Lasten auf spezifische Komponenten oder Ressourcen in der technischen Architektur.
- Über längere Zeiträume normale (oder extreme) Lasten auf das gesamte System.
Fokussieren wir uns auf einzelne Komponenten, möchten wir diese durch eine unvernünftig große Anzahl von Anforderungen an ihre vorgesehene Funktion belasten. Es ist oft einfacher, kritische Komponenten zuerst isoliert mit vielen einfachen Anforderungen zu testen, bevor eine komplexere Prüfung der gesamten Infrastruktur erfolgt. Es gibt auch speziell entwickelte Stresstest-Tools, die den Ablauf für QAs erleichtern.
Dauer- oder "Soak"-Tests sind Prüfungen, die ein System über einen längeren Zeitraum – etwa 24, 48 Stunden oder länger – einer Last aussetzen, um (meist) schwer auffindbare Probleme zu entdecken. Solche versteckten Fehler zeigen sich oft erst nach längerer Nutzungszeit.
Der automatisierte Test muss dabei nicht unbedingt auf extreme Lasten hochgefahren werden (das übernehmen Stresstests). Besonders interessiert uns die Fähigkeit des Systems, einem kontinuierlichen Betrieb einer Vielzahl unterschiedlicher Transaktionen standzuhalten, um zu ermitteln, ob es nicht offensichtliche Speicherlecks, Sperren oder asynchrone Bedingungen (Race Conditions) gibt.
Service-Management-Tests
Abschließend ein paar Worte zu Service-Management-Tests.
Wird der Dienst in Produktion eingeführt, muss er auch verwaltet werden. Einen Dienst am Laufen zu halten, erfordert Überwachung, Upgrades, Backups und schnelle Fehlerbehebung, wenn etwas schiefgeht.
Die Abläufe, die Service-Manager für Upgrades, Backups, Releases und Wiederherstellungen bei Ausfällen nutzen, sind entscheidend für einen verlässlichen Dienst. Diese müssen getestet werden, insbesondere wenn schnelle Änderungen nach dem Rollout zu erwarten sind.
Zu adressierende Probleme sind insbesondere:
- Prozesse erreichen nicht den gewünschten Effekt.
- Prozesse sind nicht praktikabel oder nicht nutzbar.
- Prozesse stören den laufenden Betrieb.
Die Tests sollten so realitätsnah wie möglich durchgeführt werden.
Ein Denkanstoß
Manche Systeme sind bei bestimmten Ereignissen extremen Lasten ausgesetzt. Zum Beispiel erwartet ein Online-Unternehmen Spitzenlasten unmittelbar nach TV-Werbung für Angebote oder eine nationale Nachrichten-Website kann bei besonders großen Nachrichtenereignissen überlastet werden.
Denken Sie an ein System, das Sie gut kennen, das durch unerwartete Zwischenfälle in Ihrem Unternehmen oder durch nationale Nachrichten betroffen war.
Welche Vorfälle oder Ereignisse könnten Überlastungen in Ihrem System auslösen?
Können (oder könnten) Sie Daten aus Systemprotokollen erfassen, die Ihnen die Anzahl der ausgeführten Transaktionen aufzeigen? Können Sie dieses Ereignis hochskalieren, um ein besonders kritisches Ereignis vorherzusagen, das statistisch einmal in 100 oder sogar 1000 Jahren vorkommt?
Welche Maßnahmen könnten Sie anwenden (oder haben Sie angewendet), um entweder die Wahrscheinlichkeit von Lastspitzen, das Ausmaß dieser Spitzen zu reduzieren oder sie sogar ganz zu beseitigen?
Abonnieren Sie den The QA Lead Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, wenn Sie tiefer in dieses und andere Themen eintauchen möchten. Wenn Sie sich entscheiden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER, um $60 auf den vollen Kurspreis zu sparen!
