Azure

Azure Load Testing

Allgemeine Infos

Azure Load Testing erzeugt hohe Last auf Webanwendungen, APIs und Datenbanken, ohne dass Du eigene Lastgeneratoren betreibst. Du lädst ein Apache-JMeter- oder Locust-Skript hoch oder legst für einen einzelnen HTTP-Endpunkt einen Schnelltest ohne Skript an, der Dienst verteilt die Last auf Test-Engines und zeigt Ergebnisse live.

Der Dienst testet Anwendungen in Azure, im eigenen Rechenzentrum oder in anderen Clouds. Für private Endpunkte wird er in ein VNet eingebunden. Microsoft führt Azure Load Testing auf der Preisseite unter dem Dach Azure App Testing, zusammen mit Playwright-basiertem Funktionstest.

Abgrenzung: Funktionale UI-Tests prüfen, ob eine Anwendung richtig funktioniert, Lasttests prüfen, ob sie unter vielen gleichzeitigen Zugriffen schnell und stabil bleibt. Azure Chaos Studio ergänzt beides, indem es gezielt Störungen einspeist.

Funktionsweise & Details

Ein Lasttest läuft in diesen Schritten:

  1. Du legst eine Load-Testing-Ressource an und erstellst einen Test aus JMeter-Skript, Locust-Skript oder URL.
  2. Du legst die Anzahl der Test-Engines fest, jede Engine simuliert viele virtuelle Benutzer.
  3. Für Azure-Anwendungen bindest Du serverseitige Metriken aus Azure Monitor, Application Insights oder Container Insights an.
  4. Fehlerkriterien wie durchschnittliche Antwortzeit oder Fehlerquote bewerten den Test automatisch als bestanden oder fehlgeschlagen, Auto-Stop bricht bei Fehlkonfiguration oder Drosselung ab.
  5. Aus Azure Pipelines, GitHub Actions oder per Azure CLI läuft der Test als Schritt in CI/CD, zum Beispiel vor jeder Freigabe in Produktion.

JMeter-Plugins und Locust-Erweiterungen bzw. Python-Bibliotheken lassen sich mitnutzen, andere Frameworks werden nicht unterstützt.

Vorteile & Nutzen

  • Keine eigene Lastinfrastruktur: Test-Engines stellt der Dienst bereit und baut sie nach dem Test ab.
  • Wiederverwendung: Bestehende JMeter- und Locust-Skripte laufen ohne Umbau.
  • Ursachen sichtbar: Client- und Servermetriken in einem Dashboard zeigen, ob Datenbank, App oder Netzwerk bremst.
  • Regressionen früh erkennen: Fehlerkriterien in der Pipeline stoppen langsame Releases vor der Produktion.
  • Kostenbremse: Auto-Stop beendet fehlkonfigurierte Tests, bevor sie unnötig Kosten erzeugen.

Praxisbeispiel

Ein Versandhändler für Gartenbedarf erwartet zum Frühjahrsstart ein Vielfaches der üblichen Besucher. Das Team nimmt die wichtigsten Abläufe (Startseite, Suche, Warenkorb, Checkout) als JMeter-Skript auf und lässt sie mit 2.000 virtuellen Benutzern gegen die Staging-Umgebung laufen. Die Servermetriken zeigen, dass die Datenbank bei der Suche an ihre DTU-Grenze stößt. Nach einem Index und einer höheren Datenbankstufe besteht der Test die Kriterien, und die Pipeline führt ihn seitdem vor jedem größeren Release aus.

Worauf sollte man achten?

  • Teste nur eigene Anwendungen oder solche mit schriftlicher Freigabe, Lasttests gegen fremde Systeme können als Angriff gewertet werden.
  • Teste gegen eine produktionsnahe Staging-Umgebung, nicht gegen die Produktion zu Geschäftszeiten.
  • Bereite Testkonten und Testdaten vor und lagere Zugangsdaten in Key Vault aus statt ins Skript.
  • Informiere Betreiber von WAF, DDoS-Schutz und Drittanbieter-APIs, damit der Test nicht geblockt wird oder Kosten verursacht.
  • Beginne mit kleiner Last und steigere schrittweise, so findest Du den Engpass statt nur den Ausfallpunkt.

Lizenz & Verfügbarkeit

Verbrauchsabrechnung über das Azure-Abonnement, auf der Preisseite unter Azure App Testing geführt. Stand: Oktober 2026.

Fazit

Lasttests gehören vor jeden kritischen Release. Azure Load Testing macht sie mit vorhandenen JMeter- oder Locust-Skripten ohne eigene Infrastruktur möglich.

Weiterführende Links

Verwandte Artikel