‚Shift Left‘: Wie man Performance-Tests in der Software-Entwicklung vorverlegt

Tests werden immer früher in die unterschiedlichen Stadien der Software-Entwicklung eingebunden. Im Vergleich mit den Stufen klassischer Methoden findet eine „Linksverschiebung” statt. Wie aber verlegt man Tests sinnvoll vor, wenn man traditionelle Modelle gewohnt ist?

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Microelectronics Consulting & Training GmbH

RTI Real-Time Innovations

Agile Test-Teams müssen die Testfälle in früheren Phasen des Software-Ablieferungszyklus erstellen und ausführen – diese Strategie wird oft als „Shift Left”, also Linksverschiebung bezeichnet und entspricht einer zeitlichen Vorverlegung. Jeder Sprint ist kritisch, und die beim Voranschreiten gefällten Entscheidungen erfolgen blitzschnell. Um den zügigen Feedback-Prozess zu ermöglichen, müssen die Test-Teams ihre Applikationen gründlich und lückenlos validieren, und dies in einem sehr kurzen Zeitrahmen.

Zur Maximierung dieser Bestrebungen können die Test-Teams ihre Herangehensweise an das Testen modernisieren, damit sich die Investitionen in möglichst frühen Phasen optimal rentieren. Die Konzentration auf die API-Schicht einer Applikation kann den Weg zu einer skalierbaren Testpraktik ebnen, die sich als Bestandteil eines beschleunigten Ablieferungsprozesses effizient ausführen lässt. Weil sich diese Praxis in den frühestmöglichen Entwicklungsphasen anwenden lässt, werden die Funktionsprüfungen wirksam vorverlegt.

Bildergalerie

Wie steht es aber mit den Performance-Tests? Wie lassen sich die Voraussetzungen für eine zeitliche Vorverlegung der nicht funktionsbezogenen Tests schaffen? Dieser Beitrag erläutert, was es hiermit auf sich hat und wie sich dies in einem Unternehmen umsetzen lässt.

Linksverschiebung: Was bedeutet die Vorverlegung der Performance-Tests?

Die zeitliche Vorverlegung der Performance-Tests gibt Entwicklern und Testern die Möglichkeit, die Leistungsfähigkeit bereits in sehr frühen Phasen der Entwicklung zu prüfen. Traditionell erfolgen die Performance-Tests erst am Ende der Entwicklungszyklen, da sie eine Reihe spezieller Tools und Fähigkeiten voraussetzen, u.a. kostspielige Hardware in speziellen Umgebungen, die von geschulten Performancetest-Ingenieuren bedient werden muss. Die Shift-Left-Strategie macht es dagegen möglich, Ad-hoc-Performance-Tests von den Testern an einzelnen Komponenten vornehmen zu lassen, sobald diese entwickelt sind.

Damit dies gelingt, müssen die Teams ihre Performance-Tests gemeinsam mit den Modul- und Funktionstests erstellen, sobald die Funktionalität implementiert wird. Die Performance-Tests können anschließend so konfiguriert werden, dass sie automatisch ablaufen, und die Dokumentation lässt sich so anlegen, dass bei Einbrüchen der Leistungsfähigkeit eine Warnung erfolgt. Zur automatischen Ausführung der Tests ist es notwendig, die Verarbeitung der Performance-Tests fest in den CI/CD-Prozess zu integrieren, sodass diese Tests nach jedem Einchecken von Code zusammen mit den Funktions- und Modultests in lokalen Umgebungen ausgeführt werden.

Diese Vorgehensweise ermöglicht es Unternehmen, die subtilen Auswirkungen zu verstehen, die sich durch das Hinzufügen neuer Komponenten auf die Gesamt-Performance ihrer Applikation ergeben. Unter dem Strich lassen sich Performance-bezogene Defekte damit wesentlich früher aufdecken. Hinsichtlich der Unternehmenskultur sorgt eine Vorverlegung der Performance-Tests außerdem für eine stärkere Einbeziehung der Entwickler. In den meisten Fällen können die Entwicklungs-Teams optimierende Verbesserungen bereits innerhalb eines Tages nach Aufdeckung einer Performance-Beeinträchtigung vornehmen, während sonst gewartet werden müsste, bis der Build der gesamten Applikation abgeschlossen ist.

Voraussetzungen auf Unternehmensseite

Zunächst ist ein bestens etabliertes organisatorisches Engagement notwendig. Ausschlaggebend für die Vorverlegung der Performance-Tests im ganzen Unternehmen ist, das Thema Qualität als einen Prozess und nicht als Reaktion zu betrachten. Die entscheidenden Akteure in diesem Prozess sind die Produktmanager, schließlich gehen die Performance-Tests und die dafür nötige Entwicklungszeit auf Kosten der Implementierung, was den Entwicklungszyklus bremsen kann. Darum müssen die PM-Teams verstehen, weshalb dieser Prozess stattfindet und dass er sich auszahlt, weil die Zahl der mit heißer Nadel gestrickten Nachbesserungen und Performance-Optimierungen zurückgeht.

Außerdem ermöglicht das Definieren von SLAs (Service Level Agreements) auf der Komponenten-Ebene und der Applikations-Ebene ein Feedback in früheren Phasen und hilft Entwicklern dabei, die Auswirkungen von Codeänderungen auf die von ihnen entwickelten Komponenten zu verstehen. Mit diesen feinstufigeren Performance-Tests können die Beteiligten somit leichter nachvollziehen, wo es zu Hotspots kommt.

Wichtig ist es, möglichst viele Testaufgaben vom UI-zentrierten Testen hin zu automatisierten Tests (z. B. API- und Datenbank-Tests) zu verlagern. Derartige Testpraktiken sind nicht nur besser zu pflegen und zu skalieren, sondern lassen sich unmittelbar in Performance-Tests nutzen, können die Grundursache von Performance-Tests einkreisen und sind überaus robust gegenüber Änderungen.

Schließlich müssen Unternehmen die Performance-Tests in den Build-Prozess einbinden, sodass die grundlegenden Performance-Tests nach dem Smoke-Test-Prinzip gleich beim Einchecken des Codes erfolgen, während die vollständige Palette der Performance-Tests über Nacht erfolgt. Hierfür muss die Hardware berücksichtigt werden, denn automatisierte Performance-Tests erfordern mehr Rechner-Ressourcen als Funktionsprüfungen. Die Test-Teams müssen also gerüstet sein. Festzustellen, ob die bestehende Performance-Infrastruktur für die zeitliche Vorverlegung geeignet ist oder eine Modifikation (z. B. Cloud-Agenten) braucht, gehört ebenfalls zu den entscheidenden Aspekten bei der Umstellung auf automatisierte Performance-Tests.

Die Aufgaben von Entwicklern und Testern

Die Entwickler bestimmen über die Leistungsfähigkeit ihrer Applikationen. Sie müssen für Performance-Tests geeignete Applikationen erstellen, indem sie Microservices, REST/SOAP APIs und modulare Designarchitekturen so einsetzen, dass sich die einzelnen Elemente umgehend nach ihrer Entwicklung für Belastungstests eignen. Die Tester können ihre Testfälle an entscheidenden Workflows in der Applikation ausrichten, damit sie sich im Performance-Testprozess nutzen lassen. Konzentriert man sich auf die API-Schichten der Applikation, schafft das mehr Robustheit gegenüber Änderungen und eine leichtere Handhabbarkeit. Beide Teams nutzen Reports, die aus den SLAs für die Applikation herausgefallen sind, um Problembereiche auf Basis des zuletzt eingecheckten Codes zu identifizieren. Dies hilft ihnen beim Identifizieren der zu optimierenden Komponenten.

Integration von Tools als Support

Die Auswahl der richtigen Tools für zeitlich vorverlegte Performance-Tests ist wichtig, aber noch wichtiger ist ihr koordinierter Einsatz in automatisierten Workflows. Tester sollten mit spezialisierten kommerziellen Tools arbeiten, die ihnen beim automatisierten Ausführen von Performance-Tests helfen. Entwickler können ähnliche Tools heranziehen, um ihre Initiativen zu optimieren oder maschinennahe Scripts zu erstellen und so die Automatisierung zu fördern. Die nachfolgend aufgezählten Tools vereinfachen die Wartung, lassen sich auf zentralisierte Weise managen und stellen eine bedienungsfreundliche Benutzeroberfläche zum Verstehen der Ergebnisse dar.

Funktionstest-Tool: Funktionstests sollten bereits ein Bestandteil der Continuous-Testing-Strategie sein. Das für die Automatisierung der Funktionstests ausgewählte Tool sollte sich sowohl auf die API-Schicht der Applikation konzentrieren (um die Ausführung und Pflege der Testfälle zu vereinfachen) als auch auf die UI-Schicht (zur lückenlosen Prüfung der Nutzererfahrung). Funktionstest-Tools dienen zum Erstellen der grundlegenden (wiederverwendbaren) Verarbeitungspfade, ob auf der UI- oder der API-Ebene. Diese Ausführungspfade entsprechen den User-Storys, sodass es eine Korrelation zwischen dem Ergebnis des Performance-Tests und der betroffenen User-Story gibt.

Performance-Test-Tool: Für die Performance-Tests benötigt man ein Tool, das die Funktionstest-Artefakte heranziehen und sie unter Last verarbeiten kann. Diese Tools sollten eine Vielzahl von Parametern zum Variieren der Last bieten (z. B. der Zahl der virtuellen Nutzer oder der Zahl der über die Zeit ausgeführten Transaktionen). Sie sollten ihre Ergebnisse dann an ein zentrales Dashboard übermitteln, um die Ergebnisse gebündelt darzustellen.

Service-Virtualisierungs-Tool: Mit Service-Virtualisierungs-Tools werden die fehlenden Komponenten monolithischer Applikationen in den frühen Phasen vorverlegter Performance-Tests berücksichtigt. Zu den entscheidenden Herausforderungen, mit denen man bei vorverlegten Performance-Tests konfrontiert wird, gehört der Mangel an unterstützender Infrastruktur, weil andere Entwicklungsarbeiten parallel laufen oder Komponenten von Dritten zugeliefert werden. Durch Erstellen einer Ausgangslage für solche abhängigen Systeme und ihre Modellierung mit virtuellen Services lassen sich ähnliche Grundbedingungen für die Produktion schaffen, um sich während der Tests auf die Performance der einzelnen Komponenten konzentrieren zu können.

Continuous-Integration-Tool: Zeitlich vorverlegte Performance-Tests funktionieren am besten als automatisierter Prozess. Bei Nutzung der Automatisierung bestehen die „Performance-Tests“ schlicht aus dem Prüfen bzw. Pflegen der automatisierten Performance-Tests. Das verringert langfristig den Zeitaufwand zum Ausführen der Tests, da der Prozess automatisch und nicht manuell abläuft. Die CI-Tools sollten es ermöglichen, die Performance-Tests als Funktion des Eincheckens von Code auszuführen, damit konsistente Performance-Tests über Nacht laufen können.

Zentralisiertes Dashboard zum Zusammenfassen der Ergebnisse: Ein zentrales Dashboard verschafft den Anwendern die Möglichkeit, die schrittweisen Auswirkungen der Performance-Tests an den Komponenten nachzuvollziehen, indem es Trendinformationen nach Projekt, Komponente, API usw. anzeigt. Es sollte die Fähigkeit bieten, Performance-Tests zu automatisieren, SLAs zu definieren, mit denen sich Performance-Tests zu Pass/Fail-Indikatoren umwandeln lassen und historische Trends zu erkennen. Darüber hinaus sollte es mit Detailinformationen aufwarten, die die Performance-Tests mit den anfänglichen Anforderungen verknüpfen, damit das jeweilige Unternehmen die auftretenden Probleme richtig priorisieren kann. Wünschenswert ist zudem eine abstrakte Pass/Fail-Angabe bei gleichzeitiger Wiedergabe auch der kleinsten Details, mit denen sich die Ursachen der detektierten Ausfälle bestimmen lassen.

Durch die zeitliche Vorverlegung kommen die Entwickler (neben den Managern und Testern) als Nutzer des Dashboards hinzu. Deshalb muss es mit sämtlichen Details aufwarten, auf die die Entwickler schauen, um die Ursachen von SLA-Fehlern effektiv zu untersuchen und zu ermitteln oder um historische Trends zu erkennen.

Zusammenfassung: Performance-Tests bereits frühestmöglich anwenden

Anwender sind es leid, ständig mit Hot Patches und Updates zur Performance-Optimierung konfrontiert zu werden. Stattdessen wünschen sie sich neue Features und Funktionalitäten. Da Performance-Tests traditionell erst am Ende des Zyklus erfolgen, bleiben sie nicht ohne Folgen für die Abliefertermine und werden deshalb in einem negativen Licht gesehen. Indem man die Performance-Tests herausnimmt und agilen Teams die Möglichkeit bietet, sie in einem iterativen Prozess vorzuverlegen (‚Shift Left‘), lassen sich etwaige Probleme früher identifizieren. Das erlaubt es, die technologischen Entscheidungen nicht nur auf eventuelle Performance-Beeinträchtigungen zu untersuchen, sondern unter dem Strich entsteht ein leistungsfähigeres Produkt, weil jeder einzelne Bereich optimiert werden kann und sich der Fokus auf die Performance richten lässt.

Wie Künstliche Intelligenz API-Tests revolutioniert

Quality @ Speed – Fünf notwendige Schritte zur Sicherung der Softwarequalität

Aufwandstreiber und Kostenbewertung im zeitgemäßen Software Engineering

* *Arthur Hicken ist Chief Software Evangelist bei Parasoft Inc.

(ID:45744191)