Show Menu
THEMEN×

Grundlegendes zu Testergebnissen – Cloud Services

Cloud Manager für Cloud Services -Pipeline-Ausführungen unterstützen die Ausführung von Tests, die für die Staging-Umgebung ausgeführt werden. Dies steht im Gegensatz zu Tests, die während des Build- und Unit-Testschritts ausgeführt werden, die offline ohne Zugriff auf eine laufende AEM-Umgebung durchgeführt werden. In diesem Zusammenhang werden zwei Typen von Tests durchgeführt:
  • Vom Kunden geschriebene Tests
  • Von Adobe geschriebene Tests
Beide Testtypen werden in einer Container-Infrastruktur ausgeführt, die für diese Testtypen entwickelt wurde.

Testen der Codequalität

Im Rahmen der Pipeline wird der Quellcode gescannt, um sicherzustellen, dass Bereitstellungen bestimmte Qualitätskriterien erfüllen. Derzeit ist dies durch eine Kombination aus SonarQube und der Prüfung auf Inhaltspaketebene mithilfe von OakPAL implementiert. Es gibt über 100 Regeln, die generische Java-Regeln und AEM-spezifische Regeln kombinieren. In der folgenden Tabelle finden Sie eine Zusammenfassung der Testkriterienbewertung:
Name
Definition
Kategorie
Fehlerschwellenwert
Sicherheitsbewertung
A = 0 Schwachstellen
B = mindestens 1 kleinere Schwachstelle
C = mindestens 1 größere Schwachstelle
D = mindestens 1 kritische Schwachstelle
E = mindestens 1 Schwachstelle der Kategorie „Blocker“
Kritisch
< B
Zuverlässigkeitsbewertung
A = 0 Fehler
B = mindestens 1 kleinerer Fehler
C = mindestens 1 größerer Fehler
D = mindestens 1 kritischer Fehler E = mindestens 1 Fehler der Kategorie „Blocker“
Wichtig
< C
Wartbarkeitsbewertung
Wenn die ausstehenden Kosten zur Code-Smell-Behebung …
  • <= 5 % der Zeit ausmachen, die bereits in die Anwendung investiert wurde, lautet die Bewertung A.
  • zwischen 6 und 10 % dieser Zeit ausmachen, lautet die Bewertung B.
  • zwischen 11 und 20 % dieser Zeit ausmachen, lautet die Bewertung C.
  • zwischen 21 und 50 % dieser Zeit ausmachen, lautet die Bewertung D.
  • mehr als 50 % dieser Zeit ausmachen, lautet die Bewertung E.
Wichtig
< A
Abdeckung
Mix aus Zeilen- und Bedingungsabdeckung mit dieser Formel:
Coverage = (CT + CF + LC)/(2*B + EL)
Dabei gilt Folgendes: CT = Bedingungen, bei denen die Auswertung während der Durchführung von Unit-Tests mindestens einmal „true“ ergeben hat
CF = Bedingungen, bei denen die Auswertung während der Durchführung von Unit-Tests mindestens einmal „false“ ergeben hat
LC = abgedeckte Zeilen = abzudeckende_Zeilen - nicht_abgedeckte_Zeilen
B = Gesamtanzahl der Bedingungen
EL = Gesamtzahl ausführbarer Zeilen (abzudeckende_Zeilen)
Wichtig
< 50%
Übersprungene Unit-Tests
Zahl der übersprungenen Unit-Tests
Info
> 1
Offene Probleme
Allgemeine Problemtypen – Schwachstellen (Vulnerability), Fehler (Bug) und Code-Smells (Code Smell)
Info
> 0
Duplizierte Zeilen
Anzahl der Zeilen, die an duplizierten Blöcken beteiligt sind.
Voraussetzungen, damit ein Codeblock als dupliziert gilt:
  • Nicht-Java-Projekte:
  • Es sollte mindestens 100 aufeinanderfolgende und duplizierte Token geben.
  • Diese Token sollten sich mindestens wie folgt verteilen:
  • 30 Codezeilen für COBOL
  • 20 Codezeilen für ABAP
  • 10 Codezeilen für andere Sprachen
  • Java-Projekte:
  • Unabhängig von der Anzahl der Token und Zeilen sollte es mindestens 10 aufeinanderfolgende und duplizierte Anweisungen geben.
Unterschiede bei Einzügen sowie Zeichenfolgenliteralen werden beim Erkennen von Duplizierungen ignoriert.
Info
> 1%
Kompatibilität mit Cloud Service
Anzahl der festgestellten Kompatibilitätsprobleme mit Cloud Service.
Info
> 0
Genauere Definitionen finden Sie unter Metrikdefinitionen .
Sie können hier eine Liste der Regeln herunterladen: code-quality-rules.xlsx .
Weitere Informationen zu den benutzerdefinierten Regeln zur Code-Qualität, die von Cloud Manager ausgeführt werden, finden Sie unter Benutzerspezifische Regeln für Code-Qualität .

Umgang mit falsch positiven Werten

Das Verfahren zur Qualitätsprüfung ist nicht perfekt. Mitunter werden fälschlicherweise Probleme identifiziert, die eigentlich nicht problematisch sind. Dies wird als „falsch positiv“ bezeichnet.
In diesen Fällen kann der Quellcode mit der standardmäßigen @SuppressWarnings -Java-Anmerkung kommentiert werden. Dabei wird die Regel-ID als Anmerkungsattribut angegeben. Ein häufiges Problem besteht etwa darin, dass die SonarQube-Regel zur Erkennung hartcodierter Kennwörter in Bezug auf die Identifizierung eines hartcodierten Kennworts „aggressiv“ sein kann.
Sehen wir uns ein konkretes Beispiel mit Code an, der in AEM-Projekten relativ häufig vorkommt, wenn eine Verbindung zu einem externen Dienst hergestellt werden soll:
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube weist dann auf eine Schwachstelle der Kategorie „Blocker“ hin. Nach Prüfung des Codes erkennen Sie, dass es sich nicht um eine Schwachstelle handelt, und kommentieren dies mit der entsprechenden Regel-ID.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Aber was wäre bei diesem Code?
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

Dann bestünde die richtige Lösung darin, das hartcodierte Kennwort zu entfernen.
Obwohl sich möglichst spezifische @SuppressWarnings -Anmerkungen bewährt haben, also nur eine bestimmte Anweisung oder den Block zu kommentieren, der das Problem verursacht, können Anmerkungen auf Klassenebene hinzugefügt werden.

Schreiben von Funktionstests

Vom Kunden geschriebene Funktionstests müssen als separate JAR-Datei verpackt werden, die vom gleichen Maven-Build wie die Artefakte erstellt wird, die in AEM bereitgestellt werden sollen. Im Allgemeinen wäre dies ein separates Maven-Modul. Die resultierende JAR-Datei muss alle erforderlichen Abhängigkeiten enthalten und wird im Allgemeinen mithilfe des maven-assembly-Plug-ins mit dem Deskriptor jar-with-dependencies erstellt.
Darüber hinaus muss für die JAR-Datei der Manifest-Header „Cloud-Manager-TestType“ auf „integration-test“ eingestellt sein. In Zukunft werden voraussichtlich weitere Header-Werte unterstützt. Eine Beispielkonfiguration für das maven-assembly-Plug-in ist:
<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

Innerhalb dieser JAR-Datei müssen die Klassennamen der tatsächlich auszuführenden Tests in „IT“ enden.
Beispielsweise würde eine Klasse mit dem Namen com.myco.tests.aem.ExampleIT ausgeführt, eine Klasse mit dem Namen com.myco.tests.aem.ExampleTest jedoch nicht.
Die Testklassen müssen normale JUnit-Tests sein. Die Testinfrastruktur ist so konzipiert und konfiguriert, dass sie mit den Konventionen der Testbibliothek von aem-testing-clients kompatibel ist. Entwicklern wird dringend empfohlen, diese Bibliothek zu verwenden und ihre Best Practices zu befolgen. Weitere Informationen finden Sie unter Git-Link .

Benutzerdefinierte Funktionstests

Der Schritt für benutzerdefinierte Funktionstests in der Pipeline ist immer vorhanden und kann nicht übersprungen werden.
Wenn jedoch keine Test-JAR vom Build erzeugt wird, wird der Test standardmäßig erfolgreich durchgeführt. Dieser Schritt wird derzeit unmittelbar nach der Staging-Implementierung ausgeführt.
Über die Schaltfläche Protokoll herunterladen können Sie auf eine ZIP-Datei zugreifen, die die Protokolle für das detaillierte Formular zur Testausführung enthält. Diese Protokolle enthalten nicht die Protokolle des eigentlichen AEM-Laufzeitprozesses – auf diese kann über die reguläre Download- oder Longtail-Protokollfunktionalität zugegriffen werden. Weitere Informationen finden Sie unter Zugreifen auf und Verwalten von Protokollen .

Lokale Testausführung

Da es sich bei den Testklassen um JUnit-Tests handelt, können sie von standardmäßigen Java-IDEs wie Eclipse, IntelliJ, NetBeans usw. ausgeführt werden.
Wenn diese Tests jedoch unbedingt ausgeführt werden müssen, müssen verschiedene Systemeigenschaften festgelegt werden, die von den aem-testing-clients (und den zugrunde liegenden Sling Testing Clients) erwartet werden.
Die Systemeigenschaften lauten wie folgt:
  • sling.it.instances - should be set to 2
  • sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
  • sling.it.instance.runmode.1 - should be set to author
  • sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
  • sling.it.instance.adminPassword.1 - should be set to the author admin password
  • sling.it.instance.url.2 - should be set to the author URL, for example, http://localhost:4503
  • sling.it.instance.runmode.2 - should be set to publish
  • sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
  • sling.it.instance.adminPassword.2 - should be set to the publish admin password