So schaffen Sie Vertrauen in Azure Workloads mit effektiven Tests

Tests sind ein fortlaufender Prozess, der die Änderungen überprüft, die Sie in eine Workload einführen. Sie fängt Regressionen ab und behält die Qualität bei, während sich die Arbeitsauslastung weiterentwickelt.

Dieser Leitfaden baut auf OE:09 Architekturstrategien für Tests auf, die die allgemeinen Prinzipien umfassen, die Sie zuerst überprüfen sollten. Es deckt nicht die Leistung, Zuverlässigkeit und Sicherheitstests im Detail ab. Informationen zu diesen Themen finden Sie im Leitfaden zu Leistungstests, im Leitfaden zu Zuverlässigkeitstests und im Handbuch für Sicherheitstests.

Planen und entwerfen Sie Tests zusammen mit der Architektur, und entwickeln Sie sie, wenn sich die Architektur ändert. Tests haben vier Phasen, die sich überschneiden und durchlaufen, anstatt in strenger Reihenfolge auszuführen:

• Planung: Entscheiden Sie , was überprüft werden soll und warum. Diese Entscheidungen regeln Testkosten und Abdeckung für die Lebensdauer der Workload. Erfassen Sie sie in einer Teststrategie und einem Testplan.
• Vorbereitung: Richten Sie die Bedingungen ein, die reale Szenarien simulieren. Bereitstellen von Umgebungen, Erstellen von Testdaten, Erstellen von Testfällen, Simulierten Abhängigkeiten und Einrichten von Automatisierungsframeworks.
• Ausführung: Integrieren Sie Tests in die CI/CD-Pipeline, führen Sie sie über mehrere Ebenen und Qualitätsabmessungen aus, führen Sie einige Tests in der Produktion sicher aus und testen Sie Fehler.
• Analyse: Analysieren Sie die Ergebnisse und berichten Sie über die Qualität. Verfolgen Sie Fehler, messen Sie die Abdeckung, bewerten Sie Qualitätsmetriken und feeden Sie Verbesserungen zurück in die Entwicklung.

Die Beispiele in diesem Leitfaden folgen einer einzigen E-Commerce-Workload, die Apple Pay als Zahlungsoption für das Auschecken hinzufügt.

Terminologie

Erstellen der Teststrategie

Die Planung beginnt mit einer Strategie, die die Richtung für alles festlegt, was folgt.

Eine Teststrategie ist eine langfristige Vereinbarung über das, was Sie testen und warum, über mehrere Versionen hinweg. Architekten, Ingenieure und Produktbesitzer stimmen sie frühzeitig zu, bevor die Entwicklung beginnt, und überprüfen Sie sie erneut, wenn sich die Arbeitsauslastung weiterentwickelt. Beginnen Sie mit der Erfassung von Geschäftsanforderungen, der Identifizierung kritischer Benutzerflüsse und Risikobereiche und der Entscheidung, wie Ihre Architektur die Validierung im Laufe der Zeit unterstützt.

Eine Strategie deckt diese Elemente in der Regel ab. Die genaue Liste variiert je nach Teamstruktur und Organisationspraktiken.

• Ziele und Umfang. Testen von Zielen, kritischen Benutzerflüssen und slOs, die Akzeptanzkriterien fördern. Definieren Sie, welche Ebenen, Komponenten und Szenarien im Gültigkeitsbereich enthalten sind und welche ausgeschlossen sind.
• Methoden und Techniken. Die testtypen, die Sie ausführen, z. B. Funktion, Sicherheit, Leistung und Benutzerakzeptanz sowie das Gleichgewicht zwischen manuellen und automatisierten Tests.
• Rollen und Zuständigkeiten. Wer besitzt jeden Testtyp und wie Teams koordinieren.
• Umgebungen und Testdaten. Die benötigten Umgebungen, die tests, die jeweils ausgeführt werden, ihre Parität mit der Produktion sowie die Testdatenquellen und Residency-Anforderungen.
• Risiken und Einschränkungen. Mögliche Risiken wie Ressourceneinschränkungen, Umgebungsverfügbarkeit oder Testdatenprobleme.
• Einreise- und Ausgangskriterien. Bedingungen, die erfüllt werden müssen, bevor tests beginnen, und Bedingungen, um sie als abgeschlossen zu betrachten.
• Tools und Prozesse. Tools für die Testverwaltung, Ausführung, Berichterstellung und Fehlernachverfolgung mit Schweregrad- und Prioritätsdefinitionen.

Entwickeln des Testplans

Der Testplan übersetzt die Strategie in ein umsetzbares Dokument für eine bestimmte Version oder einen bestimmten Sprint. Sie richtet sich an das Testteam und die Mitwirkenden, die die Tests ausführen. Erstellen Sie sie nach der Strategie, wenn Anforderungen definiert werden und Testaufgaben Details benötigen.

Der Plan umfasst dieselben Elemente wie die Strategie, aber auf Releaseebene. Sie fügt Meilensteine, Lieferumfang, Zeitachsen und den Abmeldungsprozess hinzu, sodass Sie den Fortschritt und die Endzeit nachverfolgen können.

Beispiel: Teststrategie und -plan

Die Apple Pay-Zahlungsmethode führt bestimmte Anwendungsfälle ein, z. B. Geräteeinrichtung, Authentifizierung und Transaktionsverarbeitung.

Die Teststrategie ändert sich für diese Version nicht viel. Es ist bereits vorgeschrieben, dass Zahlungsflüsse die höchste Testpriorität sind, die Standardtools wie Playwright für UI-Tests und Azure Load Testing für Auslastungstests benennt und das Back-End-Team eigenen Zahlungsintegrationstests und dem Plattformteam zu eigenen Auslastungstests zuweist.

Der Testplan für die Apple Pay-Version füllt die Besonderheiten aus:

Ohne eine Strategie und einen Plan verfolgt jede Version einen Ad-hoc-Ansatz, der zu einer inkonsistenten Abdeckung, verpassten kritischen Flüssen und Last-Minute-Verzögerungen führt. Gemeinsam sorgen sie für konsistente Tests und einen reibungslosen Rollout.

Auswählen der richtigen Umgebung

Die Vorbereitung ist der Ort, an dem Sie die Strategie implementieren. Beginnen Sie mit der Bereitstellung der richtigen Umgebungen, die je nach Testtyp variieren. Stimmen Sie jede Umgebung mit den Tests überein, die Sie ausführen möchten, sowie deren Infrastruktur, Daten und Sicherheitsanforderungen.

• Niedrigere Umgebungen (Dev, Integration): Verwenden Sie kleinere Infrastruktur und simulierte Dienste. Führen Sie hier Komponenten-, Integrations- und Regressionstests aus.
• Vorproduktionsumgebungen: Spiegelung der Produktionsinfrastruktur und Abhängigkeiten so nah wie möglich. Führen Sie hier Leistungs-, Zuverlässigkeits- und Sicherheitstests aus.
• Ephemerale Umgebungen: Erstellen Sie sie bei Bedarf für kurzlebige Anforderungen, z. B. das Validieren eines Featurezweigs oder das Ausführen einer isolierten Testsuite. Zerreißen Sie sie, um Kosten zu kontrollieren.
• Produktionsumgebung: In einigen Fällen führen Sie Tests in der Produktion aus, z. B. das Überprüfen eines neuen Features mit einem kleinen Prozentsatz der Benutzer oder das Ausführen von Stresstests während der Spitzenzeiten. Verwenden Sie Schutzläufe, um den Test zu isolieren und die Belichtung des Benutzers zu begrenzen.

Automatisieren Sie die Bereitstellung der Umgebung für Konsistenz und schnellere Einrichtung. Verwenden Sie Azure Resource Manager(ARM)-Vorlagen, Bicep oder Terraform, um Ihre Testinfrastruktur zu definieren und bereitzustellen. Die Konfigurationsabweichung ist ein Risiko für mehrere Umgebungen. Führen Sie daher eine Pipelinephase aus, die die bereitgestellte Konfiguration mit der Infrastruktur als Codedefinition (IaC) vergleicht, bevor Sie Tests ausführen. Stellen Sie beispielsweise die Infrastruktur bereit, die die Produktion widerspiegelt, aber das Live-Zahlungsgateway durch den Apple Pay-Sandkasten ersetzt.

Strategische Verwendung von Mocks

Ihre Umgebungen replizieren die Produktion selten genau. Verwenden Sie also Modelle, um für echte Abhängigkeiten zu stehen. Modelle replizieren die dienste, die sie ersetzen, einschließlich erwarteter Antworten, Fehlerbedingungen und Latenz. Mit Tools wie WireMock, Mountebank oder Azure API Management simulierten Richtlinien können Sie simulierte Antworten definieren und bedienen, ohne benutzerdefinierten Code zu schreiben.

Gute Kandidaten für die Mocking sind APIs von Drittanbietern, nicht deterministische Dienste und Dienste, die langsam, teuer oder in niedrigeren Umgebungen nicht verfügbar sind. Integrationstests für den Checkout-Dienst können ein simuliertes Zahlungsgateway verwenden, um erfolgreiche und fehlgeschlagene Transaktionen zu simulieren, während Leistungstests das reale Gateway verwenden, um die tatsächliche Latenz und den Durchsatz zu erfassen. Simuliert niemals die Komponente, die Sie tatsächlich testen.

Entwerfen Sie die Testbarkeit, damit Sie Abhängigkeiten ohne Codeänderungen austauschen können. Verwenden Sie z. B. die Abhängigkeitsinjektion, um den echten Apple Pay-Client durch ein Modell während des Tests zu ersetzen.

Tradeoff: Die Abhängigkeitsinjektion kann die Architekturkomplexität erhöhen und code schwieriger zu verstehen machen. Wiegen Sie den Vorteil der Testbarkeit gegen codeklare Klarheit, um langfristige Wartungsprobleme zu vermeiden.

Verwenden Sie Vertragstests, um Modelle genau zu halten. Ein Vertragstest überprüft, ob die Anforderungs- und Antwort-Shapes des Modells mit der API des echten Diensts übereinstimmen. Führen Sie Vertragstests aus, wenn sich die echte Dienst-API ändert. Ohne sie unterscheiden sich Modelle im Hintergrund vom realen Verhalten, was dazu führt, dass Tests in niedrigeren Umgebungen bestehen, aber in der Produktion fehlschlagen.

Erstellen realistischer Testdaten und Verwalten

Testen Sie Ihre Tests, sodass sie die Vielfalt der realen Daten widerspiegeln sollte, einschließlich Edgefälle, Grenzbedingungen und Variationen des Benutzerverhaltens. Betrachten Sie ein Anmeldeszenario und seine positiven, negativen und Edgefälle: ein gültiges Konto, ein ungültiges Kennwort und ein gesperrtes Konto.

Weisen Sie jedem Szenario einen eigenen eindeutigen Datensatz zu. Ein freigegebener Datensatz ist eine häufige Quelle für flackerige Tests. Wenn das gesperrte Konto und gültige Kontotests mit denselben Anmeldeinformationen ausgeführt werden, kann ein Test dazu führen, dass der andere zeitweise fehlschlägt. Mit dedizierten Anmeldeinformationen können Tests parallel ausgeführt werden, ohne sich gegenseitig zu stören.

Erstellen Sie eine Vielzahl von Daten, und parametrisieren Sie sie, sodass die gleiche Testlogik mehrere Verhaltensweisen überprüft. Für das Anmeldeszenario parametrisieren Sie die Anmeldeinformationen so, dass ein Test ein gültiges Konto, ein ungültiges Kennwort, ein gesperrtes Konto, ein abgelaufenes Kennwort und eine nicht überprüfte E-Mail überprüft. Fügen Sie eindeutige Bezeichner wie einen Zeitstempel oder eine GUID an Benutzernamen und E-Mail-Adressen an, um Kollisionen zu vermeiden.

Wenn ein Szenario wirklich Produktionsdaten benötigt, anonymisieren Sie es zuerst. Masken Sie alle vertraulichen Informationen, z. B. Namen, Adressen und Zahlungsdetails. Verwenden Sie Tools zur Datengenerierung wie Faker oder Mockaroo, um realistische synthetische Datensätze zu erstellen.

Verwalten Sie Testdaten so, wie sie mit Ihrer Abdeckung wächst:

• Automatisieren Sie die Erstellung und Löschung. Führen Sie einen erforderlichen Schritt aus, der Ihren Test vor der Ausführung in den richtigen Zustand versetzt, und eine Abrissstufe, in der die Daten danach gelöscht werden. Halten Sie Testdaten nur für die Dauer ihrer Testläufe.
• Versionsverwaltung und Sichere persistente Daten. Wenn Daten beibehalten werden müssen, speichern Sie sie in Ihrem Test-Repository unter Versionssteuerung, getrennt von Produktionsdaten. Niemals hartcodieren Sie Anmeldeinformationen, API-Schlüssel oder Zertifikate in Testskripts. Speichern Sie sie in einem sicheren Tresor, und rufen Sie sie zur Laufzeit ab.
• Daten auf dem aktuellen Stand halten. Aktualisieren Sie Testdaten, um Änderungen der Arbeitsauslastung, des Benutzerverhaltens und der Geschäftlichen Anforderungen widerzuspiegeln.

Entwerfen effektiver Testfälle

Fördern Sie Ihre Testszenarien aus Benutzerflüssen und Geschäftlichen Anforderungen. Behandeln Sie funktionales Verhalten, Edgefälle und nicht funktionale Attribute. Bewerten Sie, was anhand der Wahrscheinlichkeit überprüft werden soll, dass ein Fehler auftritt, und die Auswirkungen, wenn sie die Produktion erreicht. Kritische Bereiche wie Anmelde-, Zahlungs- und Checkout-Abläufe verdienen viel mehr Abdeckung als Informationsseiten mit geringem Risiko.

Ausgeglichene Abdeckung über die Ebenen der Testpyramide. Legen Sie Abdeckungsziele für jede Ebene basierend auf den kritischen Funktionen, Risiken und Wartungskosten der Tests fest.

Verwenden Sie die folgenden Kriterien, um zu entscheiden, in welcher Ebene ein Testfall gehört:

Ein einzelner Fluss benötigt in der Regel Tests auf mehr als einer Ebene, wobei jede Ebene einen anderen Teil davon abdeckt. Der Checkout-Ablauf kann Komponententests für die Berechnungslogik des Einkaufswagens, Integrationstests für die Interaktion des Zahlungsdiensts und End-to-End-Tests für die vollständige Benutzerreise verwenden. Verwenden Sie Ihre Abdeckungsziele, um die Abdeckung über kritische Flüsse hinweg zu verteilen, anstatt in ein einzelnes zu investieren.

Sehen Sie sich über die Funktionalität hinaus. Schließen Sie nicht funktionale Fälle wie Leistung, Sicherheit und Zuverlässigkeit ein, und zeichnen Sie die Akzeptanzkriterien der einzelnen Benutzer aus den relevanten Anforderungen. Wenn der Zahlungsablauf eine SLO von 2 Sekunden für die Zahlungsbestätigung unter Spitzenlast aufweist, ist die Annahmekriterien, dass die Zahlungsbestätigung innerhalb von 2 Sekunden für 95% von Anforderungen während einer simulierten Spitzenlast von 5.000 gleichzeitigen Käufern zurückgibt.

Strukturieren Sie jeden Fall eindeutig mit einer Startbedingung (gegeben), einer Aktion oder einem Ereignis (wann) und einem erwarteten Ergebnis (dann). Beispiel: Wenn ein Benutzer mit einem gültigen Apple Pay-Konto und einer Kreditkarte mit unzureichendem Guthaben einen Kauf abschließen möchte, schlägt das Auschecken mit einer entsprechenden Fehlermeldung fehl, und die Bestellung wird nicht verarbeitet.

Erfassen Sie Fälle in Azure Test Plans, TestRail oder einem ähnlichen Tool, damit Sie sie organisieren, nachverfolgen und berichten können. Verknüpfen Sie jeden Fall mit ihrer Anforderung oder Benutzergeschichte, um die Rückverfolgbarkeit und Abdeckung sichtbar zu halten.

Wenn sich Ihre Arbeitsauslastung weiterentwickelt, sollten Sie also Ihre Testfälle berücksichtigen. Szenarien werden veraltet, da sich Benutzerverhalten, Datenverkehrsmuster und Infrastruktur ändern. Überprüfen Sie Ihre Fälle regelmäßig, verrentet diejenigen, die die Arbeitsauslastung nicht mehr widerspiegeln, und falten Sie Lektionen aus Produktionsvorfällen in neue Fälle.

Erstellen Ihres Automatisierungsframeworks

Automatisierte Tests geben Ihnen schnelleres Feedback und führen häufiger als manuelle Tests aus. Sie nehmen vorab Investitionen in das Entwerfen und Warten auf, zahlen sich aber durch schnellere Releases und eine breitere Abdeckung im Laufe der Zeit aus.

Kompromiss: Ein gut gestaltetes Framework benötigt Zeit zum Erstellen. Wiegen Sie die Automatisierungsinvestitionen gegen das Risiko, dass Fehler in die Produktion gelangen. Starten Sie kleine, ausgewogene Automatisierung mit manuellen Tests, und erweitern Sie das Framework, wenn die Arbeitsauslastung wächst.

Entscheiden Sie zunächst, was automatisiert werden soll. Favorisieren Sie Testfälle, die wiederholbar, kritisch und stabil sind. Lassen Sie explorative Arbeit und schnelle UIs zu manuellen Tests.

Wählen Sie basierend auf Ihrer Teststrategie Tools aus, die Ihrer Arbeitsauslastung und Ihrem Team entsprechen. Berücksichtigen Sie Workloadkompatibilität, Lizenzierung, Benutzerfreundlichkeit, Communitysupport, CI/CD-Integration und die Lernkurve. Orientieren Sie sich an etablierten Frameworks, anstatt eigene Frameworks zu erstellen, z. B. Playwright oder Selenium für UI-Tests und Postman oder RestAssured für API-Tests.

Erstellen Sie das Framework unter Berücksichtigung von Wartungsbarkeit, Skalierbarkeit und Sicherheit, damit Sie Tests ohne wichtige Umgestaltung hinzufügen können:

• Struktur für Skalierung. Wenden Sie modulares Design, wiederverwendbare Komponenten und Parametrisierung an. Organisieren Sie Testkonfigurationen, Fälle, Daten, Protokolle und Ergebnisse. Split suites by test type, such as integration, load, and stress, so you can run targeted tests, compare results across runs, and maintain each suite unabhängig. Vermeiden Sie eine monolithische Suite, die langsam ist und die Ursachenanalyse hart macht.
• Testressourcen für die Versionssteuerung. Halten Sie Testdaten, Konfigurationsdateien und Skripts in GitHub oder Azure DevOps. Aktivieren Sie Pull-Anforderungsrichtlinien, Buildüberprüfung und Codeüberprüfung wie Produktionscode, sodass Sie Fehler in den Tests selbst erfassen, bevor sie zusammenführen.
• Fügen Sie klare Assertionen hinzu. Assertionen überprüfen, ob die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen übereinstimmen. Verwenden Sie Assertionsbibliotheken wie JUnit, die klare, beschreibende Fehlermeldungen bereitstellen, um Fehler einfacher zu diagnostizieren.
• Erstellen Sie die Observierbarkeit. Verwenden Sie die Berichterstellung Ihres Frameworks, um strukturierte Protokolle und Metriken zu erfassen. Aufzeichnen von Eingabeparametern, erwarteten und tatsächlichen Ergebnissen und Ausnahmen. Protokollieren Sie keine vertraulichen Informationen, z. B. Authentifizierungstoken, Kennwörter oder Fehlerdetails, die möglicherweise Informationen verloren gehen.
• Entwurf zur Isolierung. Entwerfen Sie Tests, die in beliebiger Reihenfolge ohne gemeinsam genutzten Zustand ausgeführt werden sollen. Jeder Test richtet seine eigenen Voraussetzungen ein und reißt sie auf, sodass Tests parallel ausgeführt werden, ohne zu stören. Erzwingen Sie die sequenzielle Ausführung nur, wenn Abhängigkeiten oder Geschäftsworkflows dies erfordern, indem Sie Frameworkfeatures wie JUnit-Anmerkungen verwenden, um die Reihenfolge zu steuern.
• Sichern Sie das Framework. Automatisierungsframeworks berühren häufig Produktionsdaten und -systeme, wodurch Risiken aus importierten Bibliotheken oder anfälligen Testcode entstehen. Wenden Sie sichere Codierungsmethoden wie Sicherheitsrisikoüberprüfung, Eingabeüberprüfung und ordnungsgemäße geheime Behandlung an, und verwenden Sie Tools wie JFrog Artifactory, um Abhängigkeiten und Artefakte sicher zu verwalten.

Ausführen von Tests in der Pipeline

Führen Sie mit einem Automatisierungsframework kontinuierlich Tests aus, damit Sie frühzeitig Feedback zu jeder Codeänderung erhalten und Fehler erfassen. Die Basis- und Mittelschichten der Testpyramide lassen sich am einfachsten integrieren, da sie minimale Abhängigkeiten aufweisen. Sie benötigen kein vollständiges Framework, um zu beginnen. Beginnen Sie mit einer kleinen Gruppe von Tests, und migrieren Sie sie in ein einheitliches Framework, wenn Ihre Funktionen reif sind.

Verwenden Sie Pipelinephasen, um unterschiedliche Testtypen zu trennen und Qualitätsgates zwischen Phasen zu definieren, damit eine Änderung erst ausgeführt werden kann, wenn sie qualitätskriterien erfüllt. In der E-Commerce-Anwendung führen Sie Tests der Auscheckeinheit für jeden Commit aus, führen Integrationstests für Pullanforderungen nur dann durch, wenn die Komponententests bestehen, und führen Regressionstests aus, wenn die Pullanforderung die Bereitstellungspipeline auslöst.

Richten Sie nightly runs of your full suite in pre-production ein, um flaky Tests und Regressionen abzufangen und das Workloadverhalten im Laufe der Zeit zu überwachen. Diese Ausführung kann längere Tests umfassen, z. B. Auslastungs- und Leistungstests, die für jeden Commit nicht praktisch sind.

Führen Sie eine Mischung aus Testtypen aus, um ein vollständiges Bild zu erhalten. Die Kombination von Tests zeigt Mängel an, die ein einzelner Typ verpassen würde. Ein Stresstest kann zeigen, dass der Checkout-Dienst bei 5.000 gleichzeitigen Käufern während eines Flash-Verkaufs fehlschlägt, während ein 12-stündiger Ausdauertest bei normaler Last einen Speicherverlust im Einkaufswagendienst verfügbar macht, der die Website über Nacht abstürzte. Beide Probleme werden nicht allein von beiden Tests erfasst.

Halten Sie Feedback schnell, indem Sie die Ausführungszeit verwalten. Verwenden Sie nach Möglichkeit parallele Ausführung. Legen Sie maxParallelForks z. B. in Gradle einen Wert fest, der größer als 1 ist. Wenden Sie einen fail-fast Mechanismus für kritische Tests an, damit die Pipeline beendet wird, sobald ein kritischer Test fehlschlägt, ohne die vollständige Regressionssuite auszuführen.

Einige Tests müssen in der Produktion ausgeführt werden. Führen Sie beispielsweise Stresstests für den Checkout-Dienst während der Spitzenzeiten aus, um den Unterbrechungspunkt zu finden und zu bestätigen, dass das System ordnungsgemäß wiederhergestellt wird, oder überprüfen Sie ein neues Feature mit einem kleinen Prozentsatz der Benutzer. Implementieren Sie Schutzläufe, die den Test isolieren und die Benutzerexposition einschränken, z. B. Featurekennzeichnungen für gezieltes Rollout und automatisierte Stopps, wenn Metriken wie Fehlerrate oder Latenzverletzung Ihre SLOs verletzen.

Fehler erneut testen

Ein Fehlerhafter Test signalisiert einen Fehler, der aus Codeänderungen, Konfigurationsabweichungen oder Umweltproblemen kommen kann. Protokollieren Sie jeden Fehler mit einem klaren Titel, Vervielfältigungsschritten, dem Fehlerhaften Test oder der Umgebung sowie unterstützenden Protokollen, Bildern oder Videos. Klassifizieren Sie den Schweregrad (kritisch, hoch, mittel, niedrig), verknüpfen Sie jeden Fehler mit den Auswirkungen des Benutzers und dem Geschäftsrisiko, weisen Sie einen Besitzer zu, und verfolgen Sie ihn zum Schließen.

Deaktivieren Sie nicht die Tests, die Fehler erkennen. Fügen Sie stattdessen Logik hinzu, um den Fehler zu behandeln und den Test fortzusetzen. Fügen Sie z. B. eine bedingte Prüfung hinzu, um einen Test in Dev zu überspringen, aber sie in Pre-Prod auszuführen, sodass Sie andere Bereiche weiter testen können, während der Fehler behoben ist.

Überprüfen Sie nach einem Fix in derselben Umgebung, in der der Fehler gefunden wurde, und führen Sie Regressionstests aus, um zu bestätigen, dass der Fix funktioniert und andere Teile der Workload nicht brechen.

Analysieren der Ergebnisse und Bericht über Qualität

Testergebnisse sind nur dann hilfreich, wenn Sie sie analysieren und über die Qualität berichten. Überprüfen Sie nach jeder Ausführung die Ergebnisse, um folgendes zu beantworten:

• Was haben die Tests über die Arbeitsauslastungsqualität ergeben?
• Wo liegen die Lücken in der Abdeckung?
• Welche Mängel wurden gefunden, und wie kritisch sind sie?
• Wie können wir die Effektivität der Tests verbessern?

Verfolgen Sie Ergebnisse, Ausführungszeit, Fehlertrends und historische Vergleiche, um den Zustand der Suite im Laufe der Zeit zu überwachen. Verwenden Sie die integrierte Berichterstellung in Ihrem Testframework und der CI/CD-Plattform, und informieren Sie die richtigen Personen über Fehler, damit sie schnell untersuchen können. Überwachen Sie nightly runs for new failures, regressions, and recurring patterns to catch flaky tests and instabil areas before they affect release quality.

Fehlerverfolgung

Verwalten Sie ein Fehlerdashboard, das offene Fehler, Schweregrad, Status, Besitz und Alterung anzeigt, und verwenden Sie es, um Korrekturen zu priorisieren. Beheben Sie beispielsweise einen kritischen Fehler im Auscheckvorgang vor einem kosmetischen Problem mit geringem Schweregrad auf der Hilfeseite. Verwenden Sie in Azure DevOps Arbeitsaufgaben, um Fehler nachzuverfolgen, sie mit Testfällen zu verknüpfen und ihren Status in Dashboards zu visualisieren.

Abdeckungsanalyse

Messen Sie die Codeabdeckung, um nicht getestete Pfade zu identifizieren, aber behandeln Sie die Abdeckung als Signal und nicht als Ziel. Eine hohe Abdeckung von Code mit geringem Risiko ist weniger wertvoll als die fokussierte Abdeckung kritischer Flüsse. Verwenden Sie Tools wie SonarQube oder JaCoCo, um Abdeckungsberichte zu generieren und Lücken in Zahlungs-, Checkout- und anderen Risikobereichen zu finden, und fügen Sie dann Fälle hinzu, in denen das Risiko die Wartungskosten rechtfertigt. Wenn ein Fehler in die Produktion entweicht, überprüfen Sie, ob ein Test sie abgefangen haben soll, und fügen Sie die Abdeckung hinzu, wo er enthalten sein sollte.

Qualitätsmetriken und Berichterstellung

Verfolgen Sie einen kleinen Satz von Metriken, die Qualität und Suite-Integrität widerspiegeln.

Melden Sie Metriken an die Zielgruppe, die sie benötigt, und passen Sie jedes Dashboard so an, dass es die Fragen der Zielgruppe beantwortet. Für den Auscheckvorgang dient derselbe Metriksatz verschiedenen Zielgruppen auf unterschiedliche Weise:

Azure DevOps bietet integrierte Dashboards und Widgets für Testergebnisse, Codeabdeckung und Arbeitsaufgaben, die Sie pro Zielgruppe anpassen können.

Feedbackschleifen und kontinuierliche Verbesserung

Erstellen Sie am Ende jeder Version einen Testbericht als Lieferumfang bei der Abmeldung des Testplans. Schließen Sie Releasedetails, Testlaufergebnisse, Fehlerzusammenfassungen und Abdeckungsinformationen ein, um Entscheidungen über die Veröffentlichungsbereitschaft, akzeptable Risiken und zukünftige Prioritäten zu informieren.

Verwenden Sie diese Erkenntnisse, um die Effektivität von Tests zu verbessern. Überprüfen Sie Tests auf einen regelmäßigen Rhythmus, suchen Sie nach Mustern in Fehlertypen und Abdeckungslücken, und verfeinern Sie die Strategie und Die Fälle entsprechend. Da flaky Tests, doppelte Abdeckung und veraltete Tests Konfidenz und langsame Lieferung erodieren, planen Sie regelmäßige Wartungssprints, um testschulden zu reduzieren. Mit jeder Phase erhalten Sie wertvolle Einblicke und verfeinern Ihren Ansatz, um Vertrauen in jede Version zu schaffen.

Vermeiden von Tests von Antipattern

Die folgenden Antipattern untergraben häufig, was Tests für Workloads tun können.

Azure-Unterstützung

Testmanagement und Planung:

• Azure Test Plans bietet browserbasierte Testverwaltung für manuelle Tests, Benutzerakzeptanztests, explorative Tests und Feedback der Beteiligten. Es umfasst Test Analytics , um die Testqualität im Laufe der Zeit nachzuverfolgen.

Testen der Automatisierung und CI/CD-Integration:

• Azure Pipelines ermöglicht die in CI/CD-Workflows integrierte Testautomatisierung mit Unterstützung für parallele Ausführung, Pipelinephasen und Qualitätstore.

• GitHub Actions bietet ähnliche CI/CD-Funktionen, die in GitHub Repositorys und Azure Services integriert sind.

Funktions- und Leistungstests:

• Azure App Testing unterstützt Funktions- und Leistungstests mit Arbeitsbereiche für Dramatiker für End-to-End-Tests und Azure Load Testing zur Leistungsüberprüfung.

Zuverlässigkeitstests:

• Azure Chaos Studio ist ein verwalteter Dienst, der Chaostests verwendet, um Ihre Cloudanwendung und Dienstresilienz zu messen, zu verstehen und zu verbessern.

Verwandte Links

• Empfehlungen für Tests (OE:09)
• Empfehlungen für Leistungstests
• Empfehlungen für Zuverlässigkeitstests
• Empfehlungen für Sicherheitstests