Testen van de codekwaliteit 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 de uitvoering van de pijpleiding, wordt een aantal metriek gevangen en vergeleken met of de belangrijkste prestatiesindicatoren (KPIs) die door de bedrijfseigenaar worden bepaald of aan normen die door de Beheerde Diensten van Adobe worden geplaatst.

Deze worden gerapporteerd met behulp van een drieledig ratingsysteem.

Waarderingen met drie lagen 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.

Testen van de codekwaliteit code-quality-testing-step

Deze stap evalueert de kwaliteit van uw toepassingscode, die het belangrijkste doel van een code slechts pijpleiding van de kwaliteit is, en onmiddellijk na de bouwstijlstap in alle niet productie en productiepijpleidingen wordt uitgevoerd. Raadpleeg het document Niet-productiepijpleidingen configureren voor meer informatie.

Testen van de codekwaliteit scant de broncode om ervoor te zorgen dat deze aan bepaalde kwaliteitscriteria voldoet. Dit wordt geïmplementeerd door een combinatie van SonarQube-analyse, inhoudspakketonderzoek met behulp van OakPAL en validatie van verzenders met behulp van het Dispatcher Optimization Tool.

Er zijn meer dan 100 regels die generieke Java-regels en AEM-specifieke regels combineren. Sommige AEM-specifieke regels worden gecreeerd gebaseerd op beste praktijken van AEM Techniek en worden bedoeld zoals Aangepaste regels voor codekwaliteit.

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

Werken met valse positieven dealing-with-false-positives

Het kwaliteitscontroleproces is niet perfect en zal soms ten onrechte problemen identificeren die eigenlijk niet problematisch zijn. Dit wordt als vals positief bedoeld.

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 zal dan een blokkeerkwetsbaarheid veroorzaken. Maar na het herzien van de code, erkent u dat dit 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";

Maar als de code eigenlijk dit 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.

Beveiligingstests security-testing

Cloud Manager stelt de bestaande Controle van de Gezondheid van de Veiligheid van de AEM op het opvoeren milieu na plaatsing in werking en rapporteert 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 drempelwaarde is voor het testen van de veiligheid. Alle gezondheidscontroles worden wel of niet uitgevoerd.

In de volgende tabel staan de gezondheidscontroles.

Prestatietesten 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

Het aantal virtuele gebruikers of containers dat wordt gespun door de Manager van de Wolk wordt gedreven door KPIs (reactietijd en pagina's/min) die door de gebruiker met wordt bepaald Zakelijke eigenaar rol while het programma te maken of te bewerken. Op basis van de gedefinieerde KPI's worden maximaal 10 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, zal de Manager van de Wolk de het opvoeren omgeving kruipen gebruikend een reeks van één of meerdere zaadURLs die door de Ingenieur van het Succes van de Klant wordt gevormd. 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

Pagina's worden geselecteerd door drie paginasets. Cloud Manager gebruikt de toegangslogboeken van de AEM instanties over productie en het opvoeren milieu's om de volgende emmers te bepalen.

Verspreiding van verkeer over geselecteerde paginasets distribution-of-traffic

U kunt kiezen uit een tot alle drie de sets op het tabblad Testen tabblad van uw pijplijnconfiguratie. De verdeling van verkeer is gebaseerd op het aantal geselecteerde reeksen. Als alle drie zijn geselecteerd, wordt 33% van de totale paginaweergaven naar 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 op de testserver voor 30 minuten als niet-geverifieerde gebruiker aan te vragen. Het meet de virtuele user-generated metriek (reactietijd, foutentarief, meningen per minuut, enz.) voor elke pagina en voor alle instanties op systeemniveau (CPU, geheugen, netwerkgegevens).

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

Zie de sectie Geverifieerde prestaties testen voor meer details over het gebruiken van basisauthentificatie voor prestatietests voor Plaatsen en Activa.

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 voor toegang tot de website tijdens het testen van de prestaties van de sites.

De gebruikersbenaming en het wachtwoord worden gespecificeerd als pijpleidingsvariabelen met de namen CM_PERF_TEST_BASIC_USERNAME en CM_PERF_TEST_BASIC_PASSWORD.

De gebruikersnaam moet in een string en het wachtwoord moet in een secretString variabele. Als beide van deze worden gespecificeerd, zal elk verzoek van de kruipper van de prestatietest en de test virtuele gebruikers deze geloofsbrieven als Basisauthentificatie van HTTP bevatten.

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

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

Raadpleeg de Variabelen voor patchgebruikerspijplijn API-documentatie voor meer informatie over het gebruik van de API.

AEM Assets aem-assets

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

Voorschrift aan boord onboarding-requirement

Voor het testen van de prestaties van middelen zal uw Customer Success Engineer een cloudmanager gebruiker en wachtwoord tijdens het instappen van de auteur aan het opvoeren milieu. Voor het testen van de prestaties is een gebruiker vereist, die cloudmanager en het bijbehorende wachtwoord dat door uw CSE is ingesteld. Deze mag niet uit de instantie van de auteur worden verwijderd en de machtigingen mogen niet worden gewijzigd. Dit zal waarschijnlijk mislukken bij het testen van de middelenprestaties.

Afbeeldingen en middelen voor tests assets-for-testing

Klanten kunnen hun eigen middelen uploaden om te testen. Dit kan worden gedaan vanuit de Instellingen pijpleiding of Bewerken scherm. 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 activa voor tests distribution-of-assets

De verdeling van het aantal elementen van elk type dat per minuut wordt geüpload, wordt ingesteld in het dialoogvenster Instellingen pijpleiding of Bewerken scherm.

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 instantie van de auteur met de gebruikersnaam en het wachtwoord die door de CSE zijn ingesteld. Elementen worden vervolgens geüpload naar de map met behulp van een opensource-bibliotheek. De tests die door de teststap Elementen worden uitgevoerd, worden geschreven met behulp van 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.

Resultaten van het testen van prestaties Grafieken performance-testing-results-graphs

Een aantal metriek is beschikbaar in Dialoogvenster Prestaties testen

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.

Deze functionaliteit is beschikbaar voor de volgende metriek.

Optimalisatie van inhoudspakketscannen 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, die effectief zijn wanneer bepaalde verpakkingsbeperkingen worden nageleefd. Het meest significant is de optimalisering die voor projecten wordt uitgevoerd die één enkel inhoudspakket uitvoeren, dat algemeen als "allen"pakket wordt bedoeld, dat een aantal 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 zijn de twee overgeslagen inhoudspakketten , dan 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 bevat de twee ingesloten pakketten die eerder werden vermeld evenals een of meer OSGi-bundels, dan wordt een nieuw, minimaal inhoudspakket samengesteld met alleen de OSGi-bundels. Dit pakket krijgt altijd een naam cloudmanager-synthetic-jar-package en de opgenomen bundels worden in /apps/cloudmanager-synthetic-installer/install.