Qualitäts-Gates beim Testen
Das folgende Diagramm bietet einen detaillierten Überblick über die verfügbaren Qualitäts-Gates und deren Verwendung in der Gesamtteststrategie sowie den AEM as a Cloud Service-Bereitstellungsprozess.
Zusammenfassung zu kundenseitig bereitgestellten Qualitäts-Gates
Komponententests | Benutzerdefinierte Funktionstests | Benutzerdefinierte Benutzeroberflächentests | Kundenvalidierungen | Manuelle Tests | |
---|---|---|---|---|---|
Produktions-Pipeline | Ja Blockieren | Ja Blockieren 60 min Zeitüberschreitung | Ja Blockieren 30 min Zeitüberschreitung | Nein | Nein |
Produktionsfremde Pipeline | Ja Blockieren | Opt-in Blockieren 60 min Zeitüberschreitung | Opt-in Blockieren 30 min Zeitüberschreitung | Nein | Nein |
Interne Adobe-Validierung | Ja Blockieren | Ja Blockieren 60 min Zeitüberschreitung | Ja Blockieren 30 min Zeitüberschreitung | Nein | Nein |
Kunden-CI/CD | Ja | Ja | Ja | Ja | Ja |
Lokaler Entwickler für Kunden | Ja | Ja | Ja | Ja | Ja |
Komponententest
Es wird empfohlen, die Komponententests für Ihre AEM-Anwendung bereitzustellen. Sie bilden die Grundlage jeder Teststrategie. Sie sollten schnell und oft ausgeführt werden und frühzeitig und schnell Feedback geben. Sie sind eng in die Entwickler-Workflows, Ihre eigenen CI/CD- und die AEM Cloud Service-Bereitstellungs-Pipelines integriert.
Sie werden mit JUnit implementiert und mit Maven ausgeführt. Unter Kernmodul des AEM-Projektarchetyps finden Sie ein Beispiel für einen Komponententest für AEM und die ersten Schritte damit.
Code-Qualität
Dieser Qualitätstest ist standardmäßig konfiguriert und führt eine statische Code-Analyse für Ihren AEM-Anwendungs-Code durch.
Unter Testen der Code-Qualität und Qualitätsregeln für benutzerspezifischen Code finden Sie weitere Informationen.
Produkttests
Produktfunktionstests sind stabile HTTP-Integrationstests (ITs) für Kernfunktionen in AEM wie Authoring- und Replikationsaufgaben. Adobe stellt sie standardmäßig bereit und verwaltet sie. Sie sollen verhindern, dass Änderungen an benutzerdefiniertem Anwendungs-Code bereitgestellt werden, wenn dadurch die Kernfunktionalität im AEM-Produkt beeinträchtigt wird.
Sie verwenden JUnit für die Implementierung, werden mithilfe von Maven ausgeführt und stützen sich auf die offiziellen AEM-Test-Clients. Die Produkttestsuite wird als
Open-Source-Projekt verwaltet, folgt Best Practices und kann als guter Ausgangspunkt für die Implementierung Ihrer Tests betrachtet werden.
Benutzerdefinierte Funktionstests
Ähnlich wie die Produkttests sind Kundenfunktionstests HTTP-Integrationstests (ITs) und werden ebenso mit JUnit implementiert, mithilfe von Maven ausgeführt und auf den offiziellen AEM-Test-Clients erstellt.
Um effiziente Pipeline-Ausführungen zu gewährleisten, empfiehlt Adobe, sich auf wichtige Funktionen und die Interaktionsflüsse der primären Benutzenden zu konzentrieren und eine funktionale Testlaufzeit von höchstens 15 Minuten anzustreben. Vollständige Funktionstestsuiten, die diese Dauer überschreiten, sollten im Rahmen der allgemeinen Kundenvalidierungs-Pipelines während des Entwicklungsprozesses ausgeführt werden.
Beispiele finden Sie unter Open-Source-Produkttests oder it.tests-Modul des AEM-Projektarchetyps.
Weitere Informationen finden Sie unter Java-Funktionstests.
Benutzerdefinierte Benutzeroberflächentests
Um die Risikokontrolle für Ihre kundenspezifische Entwicklung zu maximieren, empfiehlt Ihnen Adobe dringend, kritische Benutzeroberflächentests in AEM as a Cloud Service zu erfassen. Beschränken Sie deren Anzahl und konzentrieren Sie sich stattdessen darauf, ihre Wirkung auf das Kundenerlebnis zu maximieren.
Die Tests sind in einem Docker-Image verpackt, das so flexibel wie möglich ist (mit Unterstützung für Cypress, Playwright, Selenium, Java und JavaScript). Sie folgen denselben Merkmalen und Zwecken wie die benutzerdefinierten Funktionstests.
Damit Pipeline-Ausführungen effizient bleiben, empfiehlt Adobe, dass Sie sich auf Schlüsselfunktionen und die wichtigsten Benutzerinteraktionsabläufe konzentrieren. Umfassende Test-Suites der Benutzeroberfläche, die dieses Quality Gate übertreffen, sollten als Teil der allgemeinen Kundenvalidierungs-Pipelines ausgeführt werden. Integrieren Sie sie in den Entwicklungsprozess der Kundin bzw. des Kunden.
Beispiele finden Sie unter Open-Source-Beispieltests oder ui.tests-Modul des AEM-Projektarchetyps.
Weitere Informationen finden Sie unter Testen der benutzerdefinierten Benutzeroberfläche.
Erlebnisprüfung
Der Experience Audit-Qualitätstest führt Google Lighthouse-Audits auf der Webseite des Kunden durch.
Dieser Qualitätstest wird von AEM vordefiniert bereitgestellt, blockiert jedoch nicht die Bereitstellungs-Pipelines. Standardmäßig wird ein Audit für die Stammseite (/
) der Veröffentlichungsinstanz durchgeführt. Sie können einen Beitrag leisten, indem Sie bis zu 25 benutzerdefinierte Pfade konfigurieren, die für Audits berücksichtigt werden.
Weitere Details finden Sie unter Testen mit Experience Audit.
Kundenvalidierungen
Der Qualitätstest für Kundenvalidierungen ist ein Platzhalter für die kundeneigene Teststrategie und den Testaufwand auf Kundenseite. Er wird ausgeführt, bevor die kundenseitigen Anwendungsänderungen die AEM-Cloud-Bereitstellungs-Pipelines erreichen.
Hier können Sie die Tools und Frameworks auswählen, die Sie bevorzugen. Im Gegensatz zu Kundenfunktionstests und benutzerdefinierten Benutzeroberflächentests gibt es keine mit AEM as a Cloud Service zusammenhängenden Beschränkungen. Daher empfiehlt Adobe, hier langwierige Funktions- und Benutzeroberflächentests durchzuführen.
Sie können zwar ein beliebiges Tool und Framework wählen, Adobe empfiehlt jedoch, HTTP-basierte Integrationstests und Benutzeroberflächentests mit den Tools und Frameworks abzustimmen, die für die Qualitäts-Gates benutzerdefinierter Funktions- und Benutzeroberflächentests verwendet werden. Darüber hinaus empfiehlt Adobe, schnelle Entwicklungsumgebungen (Rapid Development Environments, RDE) in Ihre lokale Teststrategie zu integrieren, um AEM Cloud-Umgebungen möglichst genau widerzuspiegeln.