Microsoft AZ-400: Teststrategie und Quality Engineering — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Teststrategie und Quality Engineering in Azure DevOps zielen darauf ab, durch schnelles, deterministisches Feedback während des gesamten Lieferzyklus Vertrauen in die Software aufzubauen. Dabei werden die nativen Funktionen der Plattform genutzt, um Quality Gates und Nachverfolgbarkeit zu erzwingen. Effektive Strategien kombinieren eine ausgewogene Testpyramide, frühzeitige und kontinuierliche Validierung (TDD/BDD), robuste Automatisierung in Pipelines, diszipliniertes Testdatenmanagement und fortgeschrittene Techniken wie Lasttests, Chaos Engineering, Barrierefreiheitsprüfungen und durch Codeabdeckung erzwungene Deployments. Azure Test Plans, Azure Pipelines, Azure Load Testing und Azure Chaos Studio bieten Ihnen die Werkzeuge, um diese Praktiken im großen Maßstab umzusetzen.

Grundlagen der Teststrategie

Eine pragmatische Testpyramide reduziert Risiken durch schnelle, kostengünstige Tests an der Basis und eine geringere Anzahl hochpräziser Tests an der Spitze:

Unit-Tests validieren isolierte Logik und sollten den Großteil der Testsuite ausmachen. Streben Sie eine schnelle Ausführung und hohe Deterministik an. Setzen Sie für die meisten Produkte Ziele für die Unit-Test-Abdeckung im Bereich von 70–90 % für kritische Dienste, wobei zu beachten ist, dass die Abdeckung eine Ersatzmetrik und keine Qualitätsgarantie ist.
Integrationstests überprüfen die Verträge zwischen Komponenten (z. B. Datenbank, Messaging, externe Dienste) unter Verwendung realistischer Grenzen und kurzlebiger Abhängigkeiten. Führen Sie sie nach Möglichkeit parallel in containerisierten oder Sandbox-Umgebungen aus und zielen Sie darauf ab, 30–60 % der kritischen Codepfade durch Szenarien auf Integrationsebene abzudecken.
End-to-End-Tests (E2E) validieren User Journeys über den gesamten Stack. Halten Sie sie minimal und konzentrieren Sie sich auf die wertvollsten Pfade (typischerweise 5–15 % der Suite), um fragiles, langsames Feedback zu vermeiden.

Shift-Left-Testpraktiken reduzieren Fehler frühzeitig:

Test-Driven Development (TDD) erzwingt Red-Green-Refactor-Zyklen, beeinflusst das Design und erhöht das Vertrauen auf Unit-Ebene. Machen Sie TDD praxistauglich, indem Sie Entwicklern schnelle, lokale Test-Runner zur Verfügung stellen und Tests hermetisch und deterministisch halten.
Behavior-Driven Development (BDD) erfasst die Absicht in einem gemeinsamen Vokabular mithilfe von Gherkin. .NET-Teams können SpecFlow verwenden; Java- und JavaScript-Teams nutzen oft Cucumber. Verknüpfen Sie BDD-Szenarien mit Akzeptanzkriterien in Azure Boards und veröffentlichen Sie deren Ergebnisse zur Nachverfolgbarkeit in Azure Test Plans.

Testdatenmanagement eliminiert Nicht-Determinismus:

Synthetische Daten liefern deterministische, datenschutzsichere Datensätze für Unit- und Integrationstests. Generieren Sie diese mit sprachspezifischen Faker-Bibliotheken und Seed-Werten, die eine Reproduzierbarkeit ermöglichen.
Datenmaskierung ermöglicht realistische Testdatensätze, ohne persönliche oder sensible Informationen preiszugeben. Verwenden Sie Datenbank-Maskierungstools oder Datenpipelines, die irreversible Transformationen anwenden. Für Azure SQL Database exportieren Sie Snapshots in eine Staging-Subscription und wenden Sie die Maskierung vor der Testnutzung an.
Umgebungsparität stellt sicher, dass Testergebnisse aussagekräftig sind. Provisionieren Sie Testumgebungen mit Infrastructure as Code (ARM/Bicep/Terraform), sodass Systemkomponenten, Konfiguration und Netzwerktopologie so genau wie möglich mit der Produktion übereinstimmen. Halten Sie Schemamigrationen über alle Umgebungen hinweg synchron.

Erkennung und Management von Flaky Tests schützen Feedback-Schleifen:

Ursachen sind Timing-Races, externe Abhängigkeiten, Kopplung der Testreihenfolge und Ressourcenkonflikte. Verwenden Sie den Visual Studio Test-Task von Azure Pipelines mit aktiviertem rerunFailedTests, um vorübergehendes Rauschen während der Untersuchung zu reduzieren.
Stellen Sie nicht-deterministische Tests unter Quarantäne, um Pipelines grün zu halten, indem Sie sie taggen und in eine separate Suite isolieren, die zwar ausgeführt wird und berichtet, aber den Build nicht fehlschlagen lässt. Verfolgen Sie diese „Quarantäne-Schulden“ mit Work Items in Azure Boards.
Die Ursachenanalyse erfordert Instrumentierung. Erfassen Sie während der Ausführung Protokolle, Zeitmetriken und Umgebungsdetails; reproduzieren Sie den Fehler lokal mit demselben Seed und denselben Abhängigkeiten; beseitigen Sie die Abhängigkeit von nicht gemockten Systemuhren, Netzwerken und Dateisystemen; und beheben Sie den Nicht-Determinismus an der Quelle.

Azure DevOps und Testmöglichkeiten in Azure

Azure Test Plans bietet erstklassige manuelle und explorative Tests sowie Nachverfolgbarkeit:

Testfälle definieren Schritte, erwartete Ergebnisse und Parameter; gemeinsam genutzte Schritte und parametrisierte Testfälle reduzieren Duplizierung. Anforderungsbasierte Suiten richten Fälle an Product Backlog Items oder User Stories aus, während statische und abfragebasierte Suiten Tests zur Ausführung gruppieren.
Testläufe weisen Testern Suiten und Konfigurationen zu, zeichnen Ergebnisse und Dauer auf und erfassen Diagnosedaten. Umfangreiche Fehlerberichte umfassen Screenshots, Videos, Umgebungsdaten und Aktionsprotokolle.
Exploratives Testen verwendet die Browser-Erweiterung „Test & Feedback“, um während der Ad-hoc-Erkundung Charters, Sitzungsnotizen und Artefakte zu erfassen. Verknüpfen Sie Ergebnisse mit Arbeitselementen und analysieren Sie die Abdeckung von Anforderungen und Testsitzungen.

Automatisierte Tests lassen sich direkt in Pipelines integrieren:

Verwenden Sie den Visual Studio Test-Task (VsTest), um MSTest-, NUnit- und xUnit-Tests auszuführen und TRX-Ergebnisse zu veröffentlichen. Für .NET ist

undefined

mit dem entsprechenden Logger (trx, junit) üblich.

Führen Sie für Java JUnit über Maven oder Gradle aus und veröffentlichen Sie JUnit XML mit dem Task „Publish Test Results“. Konfigurieren Sie für JavaScript Runner (Jest, Mocha) so, dass sie JUnit XML ausgeben.
„Publish Test Results“ konsolidiert Ergebnisse und Trends über mehrere Läufe hinweg. Standardisieren Sie die Ergebnisformate (TRX oder JUnit XML), um das Reporting zu vereinheitlichen und die Analyse von „flaky“ Tests zu ermöglichen.
Verknüpfen Sie automatisierte Testläufe mit Azure Test Plans, indem Sie Testfälle automatisierten Testmethoden zuordnen, um eine durchgängige Nachverfolgbarkeit von der Anforderung über die Ausführung bis zum Fehler sicherzustellen.

Code Coverage ist eine messbare Leitplanke für Qualität:

Erfassen Sie die Abdeckung mit Coverlet (für .NET), JaCoCo (Java) oder Cobertura/lcov (JavaScript). Konvertieren Sie sie in Formate, die Azure DevOps versteht, und veröffentlichen Sie sie über „Publish Code Coverage Results“, um Trends und Deltas aufzuzeigen.
Setzen Sie Mindestschwellenwerte zur Build-Zeit durch. Verwenden Sie für .NET die Schwellenwert-Schalter von Coverlet, um den Build fehlschlagen zu lassen, wenn die Zeilen- oder Zweigabdeckung unter die Richtlinie fällt. Alternativ können Sie die Erweiterung „Build Quality Checks“ verwenden, um abdeckungs- und trendbasierte Richtlinien durchzusetzen.
Durch Code Coverage gesteuerte Deployments verhindern den Fortschritt, wenn die Qualität sinkt. Lassen Sie in YAML die Qualitätsstufe fehlschlagen, wenn die Abdeckung unter dem Zielwert liegt; verwenden Sie bei klassischen Releases Gates, die eine Azure Function oder eine REST-Prüfung aufrufen, um die gemessene Abdeckung vor der Heraufstufung (Promotion) zu validieren.

Performance, Chaos und Resilienz

Last- und Performancetests validieren nicht-funktionale Anforderungen frühzeitig und kontinuierlich:

Azure Load Testing orchestriert JMeter-basierte Last im großen Maßstab und korreliert dabei Backend-Telemetriedaten von Application Insights. Importieren Sie JMX-Testpläne, legen Sie Pass/Fail-Kriterien fest (z. B. p95-Latenz, Fehlerrate) und bringen Sie die Ergebnisse in die Pipelines ein. Verwenden Sie das Azure Monitor Gate oder Umgebungsprüfungen, um den Fortschritt zu blockieren, wenn die Baselines nicht erfüllt werden.
Apache JMeter bleibt eine vielseitige Wahl für Lasttests auf Protokollebene. Halten Sie Thread-Gruppen und Assertions für die CI parametrisiert. Speichern Sie JMX- und CSV-Datensätze mit dem Code und versionieren Sie sie zusammen mit den Szenarien.
k6 ermöglicht entwicklerfreundliche Lasttests als Code. Führen Sie k6 in Azure Pipelines über einen Container oder eine Node-Laufzeitumgebung aus, erfassen Sie die Ergebnisse und exportieren Sie sie zur Veröffentlichung nach JUnit oder JSON. Verwenden Sie Schwellenwert-Ausdrücke in k6-Skripten, um Läufe deterministisch fehlschlagen zu lassen.
Das Management von Baselines ist entscheidend. Verfolgen Sie Latenz-, Durchsatz- und Ressourcenauslastungstrends pro Umgebung. Legen Sie SLOs fest und stellen Sie sicher, dass Tests unter repräsentativen Datenmengen und Konfigurationen ausgeführt werden.

Chaos Engineering überprüft die Resilienz unter Fehlerbedingungen:

Azure Chaos Studio injiziert Fehler in Azure-Ressourcen mit kontrolliertem Explosionsradius (Blast Radius) und Schutzmaßnahmen. Zu den Experimenttypen gehören CPU-/Speicherdruck auf VMs, Netzwerklatenz/-Blackhole, das Beenden von Prozessen (Process Kill) und die Drosselung von Diensten (Service Throttling).
Führen Sie Experimente zuerst in der Vorproduktionsumgebung durch und instrumentieren Sie sie mit Application Insights und Azure Monitor, um Fehlermodi, Fehlerbudgets und das automatische Wiederherstellungsverhalten zu erfassen.
Die Resilienzvalidierung koppelt Chaos mit Health Probes und synthetischen Transaktionen, um sicherzustellen, dass für Benutzer kritische Pfade verfügbar bleiben oder sich kontrolliert verschlechtern (graceful degradation). Führen Sie eine Heraufstufung (Promotion) nur dann durch, wenn die Resilienz-Hypothesen bestätigt sind und die Warnmeldungen (Alerts) wie vorgesehen funktionieren.

Barrierefreiheit, Compliance und Governance

Barrierefreiheit und Compliance sind grundlegende Qualitätsmerkmale:

Halten Sie für öffentlich zugängliche Anwendungen mindestens WCAG 2.1 AA ein. Übersetzen Sie Anforderungen in Akzeptanzkriterien in Azure Boards und Azure Test Plans mit dedizierten Testfällen für die Barrierefreiheit.
Automatisieren Sie Prüfungen mit axe-core, das in UI-Test-Frameworks wie Playwright, Cypress oder Selenium integriert ist. Lassen Sie Builds fehlschlagen, wenn kritische Verstöße erkannt werden, und veröffentlichen Sie Berichte zur Barrierefreiheit als Pipeline-Artefakte.
Ergänzen Sie die Automatisierung durch manuelle Audits (Tastaturnavigation, Screenreader-Unterstützung, Farbkontrast in dynamischen Kontexten) und erfassen Sie die Ergebnisse in explorativen Sitzungen mit der Test & Feedback-Erweiterung.
Compliance- und Qualitäts-Governance in Azure Pipelines nutzen Umgebungsprüfungen und Gates. Fragen Sie für Leistung und Verfügbarkeit vor der Bereitstellung Baselines von Azure Monitor oder Azure Load Testing ab. Für die Überwachung der Abdeckung oder Barrierefreiheit rufen Sie eine Funktion oder eine REST-Prüfung auf, die veröffentlichte Berichte analysiert und pass/fail zurückgibt.
Dies erzwingt nicht-funktionale Qualität als Voraussetzung für ein Release und nicht als nachträgliche Überlegung.

Die Veröffentlichung von Testergebnissen und Analysen schließt den Kreis:

Standardisieren Sie Ergebnisformate und Abdeckungsberichte, um Test Analytics zu füllen, Erfolgsquoten zu verfolgen und instabile („flaky“) Tests automatisch aufzudecken.
Verwenden Sie Build-Richtlinien und Branch-Schutzmaßnahmen, um erfolgreiche („grüne“) Tests und eine angemessene Abdeckung vor dem Mergen zu fordern. Sorgen Sie für schnelles Feedback; parallelisieren Sie Testphasen, teilen Sie große Suiten auf (Sharding) und cachen Sie Abhängigkeiten, um die Zykluszeit zu verkürzen.

Praktisches Problemszenario

Adobe modernisiert eine Plattform zur Dokumentenverarbeitung zu Microservices auf Azure. Die technische Leitung fordert eine schnellere Release-Kadenz ohne Regressionen, nachweisbare Leistungs-Baselines, Resilienz gegenüber regionalen Netzwerkausfällen und die Einhaltung von WCAG 2.1 AA. Die aktuellen Pipelines leiden unter instabilen („flaky“) E2E-Tests und inkonsistenten Testdaten.

Etablieren der Testpyramide und Shift-Left-Praktiken

Führen Sie TDD für Kernbibliotheken und -dienste ein, um eine große, deterministische Basis von Unit-Tests zu schaffen, unter Verwendung von NUnit und xUnit für .NET-Komponenten und JUnit für Java. BDD mit SpecFlow und Cucumber erfasst teamübergreifende Akzeptanzkriterien als ausführbare Spezifikationen. Dies gewährleistet schnelles Feedback und ein gemeinsames Verständnis.

Automatisieren von Tests und Veröffentlichen der Ergebnisse in Azure Pipelines

Verwenden Sie VsTest für .NET und Maven/Gradle für Java, um Unit- und Integrationstests auszuführen. Veröffentlichen Sie Ergebnisse mit „Publish Test Results“ und die Abdeckung mit „Publish Code Coverage Results“, um das Reporting zu zentralisieren und die Analyse instabiler („flaky“) Tests zu ermöglichen. Integrierte Tasks bieten eine enge Azure DevOps-Integration und reduzieren den Bedarf an benutzerdefinierten Werkzeugen.

Durchsetzen von Schwellenwerten für die Codeabdeckung und Steuern von Bereitstellungen mit Gates

Konfigurieren Sie Schwellenwerte für Coverlet und JaCoCo, damit Builds fehlschlagen, wenn die Abdeckung für kritische Dienste unter 80 % Zeilen- und 60 % Branch-Abdeckung fällt. Fügen Sie eine Release-Prüfung hinzu, die eine Azure Function aufruft, um das neueste Abdeckungsartefakt zu lesen und pass/fail zurückzugeben, wodurch eine Bereitstellung bei unzureichender Abdeckung verhindert wird. Dies formalisiert Quality Gates ohne menschliches Eingreifen.

Implementieren eines Testdatenmanagements für Deterministik

Generieren Sie synthetische Datensätze für Unit- und Integrationstests mithilfe von Faker-Bibliotheken. Klonen Sie für Systemtests maskierte Kopien von Azure SQL-Datenbanken über eine automatisierte Pipeline mit Data Factory, um eine irreversible Maskierung anzuwenden. Stellen Sie Umgebungen mit Bicep bereit, um Parität zu gewährleisten. Dies beseitigt Datenschutzrisiken und datenbedingte Instabilität.

Eindämmen und Beseitigen von instabilen („flaky“) Tests

Aktivieren Sie rerunFailedTests in VsTest, um vorübergehende Fehler zu entschärfen, und markieren Sie instabile Spezifikationen mit einem Quarantäne-Marker, der sie aus der blockierenden Suite ausschließt, während sie weiterhin ausgeführt und gemeldet werden. Erstellen Sie Azure Boards Work Items für jeden unter Quarantäne gestellten Test. Führen Sie eine Ursachenanalyse durch, indem Sie Zeit- und Netzwerkprotokolle sammeln und nicht-deterministische Wartezeiten entfernen. Dies hält die Pipelines zuverlässig und treibt gleichzeitig dauerhafte Korrekturen voran.

Validieren der Leistung mit Azure Load Testing und k6

Modellieren Sie Schlüssel-Journeys als JMeter-Pläne und führen Sie sie nach der Bereitstellung in der Staging-Umgebung in Azure Load Testing aus, mit Pass/Fail-Kriterien für p95-Latenz und Fehlerraten. Führen Sie für Entwicklertests auf API-Ebene k6-Skripte in der CI mit integrierten Schwellenwerten aus. Fügen Sie ein Azure Monitor Gate hinzu, um die Produktion zu blockieren, wenn die Staging-Baselines nicht erfüllt werden. Diese Werkzeuge bieten eine skalierbare, messbare Durchsetzung der Leistung, die auf das QA-Gate-Konzept abgestimmt ist.

Nachweisen der Resilienz mit Azure Chaos Studio

Entwerfen Sie Experimente, die Netzwerklatenz und CPU-Druck auf ausgewählte Microservices in der Staging-Umgebung injizieren, während Application Insights Fehlerbudgets und die Wiederherstellung verfolgt. Fordern Sie, dass alle Resilienz-Experimente die SLOs erfüllen, bevor sie in die nächste Stufe befördert werden. Die Governance-Kontrollen von Chaos Studio entsprechen Adobes Bedarf an einem kontrollierten „Blast Radius“ und auditierbaren Experimenten.

Sicherstellen von Barrierefreiheit und Compliance

Integrieren Sie axe-core in Playwright UI-Tests, um Verstöße gegen WCAG 2.1 AA auf Kernbildschirmen automatisch zu erkennen. Veröffentlichen Sie Berichte über Verstöße als Build-Artefakte und lassen Sie den Build bei kritischen Problemen fehlschlagen. Planen Sie explorative Barrierefreiheitssitzungen mit Azure Test Plans und der Test & Feedback-Erweiterung zur manuellen Überprüfung. Dies kombiniert automatisierte Abdeckung mit auf den Menschen ausgerichteten Prüfungen.

Bereitstellen von Nachverfolgbarkeit und Analysen

Verknüpfen Sie automatisierte Tests gegebenenfalls mit Azure Test Plans, gleichen Sie Suiten mit Anforderungen ab und nutzen Sie Test Analytics, um Erfolgsquoten zu verfolgen, instabile („flaky“) Tests zu identifizieren und die Behebung zu fokussieren. Dies ermöglicht es der Führungsebene, Qualitätstrends und die Release-Reife auf einen Blick zu erkennen.

Jede Wahl betont native Azure DevOps- und Azure-Dienste für eine erstklassige Integration, Governance durch Umgebungsprüfungen und Gates sowie eine ausgewogene Teststrategie, die Feedback-Geschwindigkeit, Zuverlässigkeit und Compliance optimiert.

← Sicherheit · Alle Domänen · Monitoring →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →