Codekwaliteitstests code-quality-testing

Leer hoe het testen van de codekwaliteit van pijpleidingen werkt en hoe het de kwaliteit van uw plaatsingen kan verbeteren.

Inleiding introduction

Tijdens pijpleidingsuitvoering, vangt de software een aantal metriek. Deze metriek worden dan vergeleken met de Belangrijkste Indicatoren van Prestaties (KPIs) die door de bedrijfseigenaar worden bepaald. Of ze worden vergeleken met normen die door Adobe Managed Services zijn vastgesteld.

Deze resultaten worden gerapporteerd met behulp van een drieledig ratingsysteem.

Driegelaagde ratings three-tiered-ratings

Er liggen drie poorten in de pijplijn:

Voor elk van deze poorten is er een structuur met drie lagen voor problemen die door de poort worden geïdentificeerd.

Codekwaliteitstests code-quality-testing-step

Deze testende stap evalueert de kwaliteit van uw toepassingscode, die het belangrijkste doel van een code kwaliteit-slechts pijpleiding is. Het wordt uitgevoerd onmiddellijk na de bouwstap in alle niet-productie- en productiepijpleidingen. Meer leren, ga Vormend niet-Productiepijpleidingen.

Testen van de codekwaliteit scant de broncode om ervoor te zorgen dat deze aan bepaalde kwaliteitscriteria voldoet.

De software implementeert deze met behulp van een combinatie van SonarQube-analyse, inhoudspakketonderzoek met OakPAL en Dispatcher-validatie met het Dispatcher Optimization Tool.

Er zijn meer dan 100 regels die generieke Java-regels en AEM-specifieke regels combineren. Sommige van de AEM-specifieke regels worden gecreeerd gebaseerd op beste praktijken van AEM Techniek en worden bedoeld als Regels van de Kwaliteit van de Code van de Douane.

De resultaten van het testen van de codekwaliteit worden geleverd als classificatie zoals samengevat in deze lijst.

Omgaan met valse positieven dealing-with-false-positives

Het kwaliteitscontroleproces is niet perfect en identificeert soms problemen die eigenlijk niet problematisch zijn. Dit scenario wordt een vals positief scenario genoemd.

In deze gevallen kan de broncode worden geannoteerd met de standaard Java @SuppressWarnings -annotatie die de regel-id opgeeft als het annotatiekenmerk. Bijvoorbeeld, één gemeenschappelijk vals positief is dat de regel SonarQube om hardcoded wachtwoorden te ontdekken agressief kan zijn over hoe een hard - gecodeerd wachtwoord wordt geïdentificeerd.

De volgende code is vrij gemeenschappelijk in een AEM project, dat code heeft om met één of andere externe dienst te verbinden.

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube vergroot vervolgens een kwetsbaarheid voor blokkers. Maar na het herzien van de code, erkent u dat deze kwestie geen kwetsbaarheid is en kan de code met aangewezen regelidentiteitskaart annoteren.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Nochtans, als de code eigenlijk het volgende was:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

Dan is de correcte oplossing het hardcoded wachtwoord te verwijderen.

Beveiligingstest security-testing

Cloud Manager stelt de bestaande Controle van de Gezondheid van de Veiligheid van de Veiligheid op het opvoeren milieu na plaatsing in werking en meldt de status door UI. De resultaten worden samengevoegd van alle AEM in de omgeving.

Deze zelfde gezondheidscontroles kunnen op elk ogenblik door de Console van het Web of het Dashboard van Verrichtingen worden uitgevoerd.

Als een van de gevallen melding maakt van een mislukking voor een bepaalde gezondheidscontrole, mislukt het hele milieu die gezondheidscontrole. Net als bij het testen van de kwaliteit en de prestaties van de code, worden deze gezondheidscontroles in categorieën ingedeeld en gerapporteerd met behulp van het driegistaire gatingsysteem. Het enige verschil is dat er geen drempel is als er veiligheidstests zijn. Alle gezondheidscontroles worden wel of niet uitgevoerd.

In de volgende tabel staan de gezondheidscontroles.

Prestatietests performance-testing

AEM Sites aem-sites

Cloud Manager voert prestatietests voor AEM Sites-programma's uit. De prestatietest wordt ongeveer 30 minuten in werking gesteld door virtuele gebruikers (containers) te draaien die daadwerkelijke gebruikers simuleren om tot pagina's in het opvoeren milieu's toegang te hebben om verkeer te simuleren. Deze pagina's worden gevonden gebruikend een kruipper.

Virtuele gebruikers virtual-users

Cloud Manager spint omhoog virtuele gebruikers of containers die op KPIs (reactietijd en pagina's/min) worden gebaseerd die door de rol van de BedrijfsEigenaar worden geplaatst. Deze KPIs wordt geplaatst terwijl creërend of het uitgeven van het programma.

Op basis van de gedefinieerde KPI's worden maximaal tien containers gesponnen die werkelijke gebruikers simuleren. De pagina's die voor het testen zijn geselecteerd, worden gesplitst en toegewezen aan elke virtuele gebruiker.

Crawler crawler

Vóór het begin van de testperiode van 30 minuten kruipt Cloud Manager de testomgeving met behulp van een set van een of meer zaadURL's die door de Klantsuccesingenieur zijn geconfigureerd. Vanaf deze URL's wordt de HTML van elke pagina geïnspecteerd en worden koppelingen in de breedteeerste modus doorlopen.

Paginasets voor testen page-sets

Drie paginasets selecteren de pagina's. Cloud Manager gebruikt de toegangslogboeken van de AEM instanties over productie en het opvoeren milieu's om de volgende emmers te bepalen.

Verdeling van verkeer over geselecteerde paginasets distribution-of-traffic

U kunt overal van één tot alle drie reeksen op het Testen lusje van uw pijpleidingsconfiguratiekiezen. De verdeling van verkeer is gebaseerd op het aantal geselecteerde reeksen. Als alle drie zijn geselecteerd, wordt 33% van de totale paginaweergaven in elke set geplaatst. Als er twee zijn geselecteerd, gaat 50% naar elke set. Als één wordt geselecteerd, gaat 100% van het verkeer naar die reeks.

Laten we dit voorbeeld bekijken.

Gedurende de testperiode van 30 minuten:

Testen en rapporteren testing-reporting

Cloud Manager voert het testen van de prestaties voor AEM Sites-programma's uit door pagina's standaard voor een testperiode van 30 minuten als niet-geverifieerde gebruiker op de testpublicatieserver aan te vragen. Het meet de virtuele user-generated metriek (reactietijd, foutentarief, meningen per minuut, etc.) voor elke pagina en diverse systeem-vlakke metriek (cpu, geheugen, voorzien van een netwerkgegevens) voor alle instanties.

In de volgende tabel wordt een overzicht gegeven van de prestatietestmatrix met behulp van het driegrafeerde gatsysteem.

Zie Voor authentiek verklaarde prestaties het testenvoor meer details bij het gebruiken van basisauthentificatie voor prestaties het testen voor Plaatsen en Assets.

Geverifieerde prestaties testen authenticated-performance-testing

Indien nodig kunnen AMS-klanten met geverifieerde sites een gebruikersnaam en wachtwoord opgeven die door Cloud Manager worden gebruikt om toegang te krijgen tot de website tijdens het testen van de prestaties van sites.

De gebruikersnaam en het wachtwoord worden opgegeven als pijpleidingvariabelen met de namen CM_PERF_TEST_BASIC_USERNAME en CM_PERF_TEST_BASIC_PASSWORD .

De gebruikersnaam wordt opgeslagen in een string -variabele en het wachtwoord wordt opgeslagen in een secretString -variabele. Als beide variabelen worden gespecificeerd, bevat elk verzoek van de kruipper van de prestatietest en de test virtuele gebruikers deze geloofsbrieven als Basisauthentificatie van HTTP.

Voer de volgende handelingen uit om deze variabelen in te stellen met de Cloud Manager CLI:

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Zie de variabelen van de gebruikerspijpleiding van het PatchAPI documentatie leren hoe te om API te gebruiken.

AEM Assets aem-assets

Cloud Manager voert prestatietests uit voor AEM Assets-programma's door elementen herhaaldelijk gedurende 30 minuten te uploaden.

Verplichting aan boord onboarding-requirement

Voor het testen van Assets-prestaties maakt uw Customer Success Engineer een cloudmanager gebruiker en wachtwoord tijdens het instappen van de auteur in de testomgeving. Voor de teststappen voor prestaties is een gebruiker vereist met de naam cloudmanager en het bijbehorende wachtwoord dat door de CSE is ingesteld.

Deze methode zou in de auteursinstantie met zijn toestemmingen onveranderd moeten blijven. Het wijzigen of verwijderen ervan kan ertoe leiden dat Assets-prestatietests mislukken.

Afbeeldingen en Assets voor testdoeleinden assets-for-testing

Klanten kunnen hun eigen middelen uploaden om te testen. Dit proces kan van de Opstelling van de Pijpleiding worden gedaan of ​ ​scherm uitgeven. Algemene afbeeldingsindelingen, zoals JPEG, PNG, GIF en BMP, worden ondersteund in combinatie met Photoshop-, Illustrator- en Postscript-bestanden.

Als er geen afbeeldingen zijn geüpload, gebruikt Cloud Manager een standaardafbeelding en PDF-documenten voor het testen.

Distributie van Assets voor tests distribution-of-assets

De distributie van hoeveel activa van elk type per minuut worden geupload wordt geplaatst in de Opstelling van de Pijpleiding of geeft scherm uit.

Als bijvoorbeeld een splitsing van 70/30 wordt gebruikt en er 10 elementen per minuut worden geüpload, worden 7 afbeeldingen en 3 documenten per minuut geüpload.

Testen en rapporteren testing-and-reporting

Cloud Manager maakt een map op de auteurinstantie met de gebruikersnaam en het wachtwoord die door de CSE-instelling worden ingesteld. Assets wordt vervolgens geüpload naar de map met behulp van een opensource-bibliotheek. De tests die door Assets worden in werking gesteld worden het testen stap geschreven gebruikend een open bronbibliotheek. Zowel de verwerkingstijd voor elk element als de verschillende metingen op systeemniveau worden over de testduur van 30 minuten gemeten. Met deze functie kunt u zowel afbeeldingen als PDF-documenten uploaden.

Prestatietestresultaten performance-testing-results-graphs

Een aantal metriek is beschikbaar in de de dialoogdoos van de Test van Prestaties.

De metrische deelvensters kunnen worden uitgevouwen om een grafiek weer te geven, om een koppeling naar een download te bieden of om beide weer te geven.

wordt uitgebreid

Deze functionaliteit is beschikbaar voor de volgende metriek.

Optimalisatie van scannen van inhoudspakketten content-package-scanning-optimization

In het kader van het kwaliteitsanalyseproces voert Cloud Manager een analyse uit van de inhoudspakketten die door de Maven-build worden geproduceerd. Cloud Manager biedt optimalisaties om dit proces te versnellen, dat effectief is wanneer bepaalde verpakkingsbeperkingen worden nageleefd.

De belangrijkste optimalisatie is voor projecten die één enkel "all"pakket uitvoeren, dat andere inhoudspakketten bevat die door de bouwstijl worden geproduceerd, die als overgeslagen worden gemerkt. Wanneer Cloud Manager dit scenario detecteert in plaats van het "all"-pakket uit te pakken, worden de afzonderlijke inhoudspakketten direct gescand en gesorteerd op basis van afhankelijkheden. Neem bijvoorbeeld de volgende build-uitvoer.

Als de enige items binnen myco-all-1.0.0-SNAPSHOT.zip de twee overgeslagen inhoudspakketten zijn, worden de twee ingesloten pakketten gescand in plaats van het "all"-inhoudspakket.

Voor projecten die tientallen ingebedde pakketten produceren, is deze optimalisering getoond om naar boven van 10 minuten per pijpleidingsuitvoering te besparen.

Een speciaal geval kan voorkomen wanneer het "alle"inhoudspakket een combinatie overgeslagen inhoudspakketten en bundels OSGi bevat. Als myco-all-1.0.0-SNAPSHOT.zip bijvoorbeeld de twee eerder vermelde ingesloten pakketten en een of meer OSGi-pakketten bevat, wordt een nieuw, minimaal inhoudspakket samengesteld met alleen de OSGi-bundels. Dit pakket krijgt altijd de naam cloudmanager-synthetic-jar-package en de opgenomen bundels worden in /apps/cloudmanager-synthetic-installer/install geplaatst.