Testen der Code-Qualität

Beim Testen der Code-Qualität wird die Qualität Ihres Programm-Codes bewertet. Dabei handelt es sich um das Kernziel einer reinen Code-Qualitäts-Pipeline, die unmittelbar nach dem Erstellungsschritt in allen Nichtproduktions- und Produktions-Pipelines ausgeführt wird.

Weitere Informationen zu den verschiedenen Pipelines finden Sie unter Konfigurieren Ihrer CI/CD-Pipeline.

Grundlegendes zu Regeln für die Code-Qualität

Beim Testen der Code-Qualität wird der Quell-Code gescannt, um sicherzustellen, dass er bestimmte Qualitätskriterien erfüllt. 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. Einige der AEM-spezifischen Regeln werden auf der Grundlage der Best Practices von AEM Engineering erstellt und werden als benutzerspezifische Code-Qualitätsregeln bezeichnet.

HINWEIS

Sie können die vollständige Liste der Regeln hier herunterladen.

Dreistufige Akzeptanztests

Bei diesem Schritt zum Testen der Code-Qualität gibt es eine dreistufige Struktur für die identifizierten Probleme:

  • Kritisch: Hierbei handelt es sich um vom Test identifizierte Probleme, die zu einem sofortigen Pipelinefehler führen.

  • Wichtig: Hierbei handelt es sich um vom Test identifizierte Probleme, durch die die Pipeline angehalten wird. Implementierungs-Manager, Projekt-Manager oder Business Owner können die Probleme außer Kraft setzen. In diesem Fall wird die Pipeline fortgesetzt. Sie können die Probleme aber auch akzeptieren. In diesem Fall stoppt die Pipeline mit einem Fehler.

  • Info: Hierbei handelt es sich um vom Test identifizierte Probleme, die ausschließlich zu Informationszwecken bereitgestellt werden und keine Auswirkungen auf die Pipelineausführung haben.

Die Ergebnisse dieses Schritts werden als Bewertung bereitgestellt.

In der folgenden Tabelle sind die Bewertungen und Fehlerschwellenwerte für die einzelnen Kategorien „Kritisch“, „Wichtig“ und „Information“ zusammengefasst:

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
HINWEIS

Genauere Definitionen finden Sie unter Metrikdefinitionen.

HINWEIS

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 Quell-Code 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 Service 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.

HINWEIS

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.

HINWEIS

Es gibt zwar keinen expliziten Schritt für Sicherheitstests, aber beim Code-Qualitätsschritt werden sicherheitsbezogene Regeln für die Code-Qualität evaluiert. Weitere Informationen zur Sicherheit in Cloud Service finden Sie in der Sicherheitsübersicht für AEM as a Cloud Service.

Auf dieser Seite