Testning av kodkvalitet code-quality-testing

Lär dig hur kodkvalitetstestning av rörledningar fungerar och hur det kan förbättra kvaliteten på dina distributioner.

Introduktion introduction

Under utvecklingsfasen hämtas och jämförs ett antal mätvärden med nyckeltal (KPI) som definieras av företagsägaren eller enligt standarder som fastställs av Adobe Managed Services.

Dessa rapporteras med ett klassificeringssystem med tre nivåer.

Tre nivåindelade omdömen three-tiered-ratings

Det finns tre portar i pipeline:

För var och en av dessa portar finns det en struktur på tre nivåer för problem som identifieras av porten.

Testning av kodkvalitet code-quality-testing-step

I det här steget utvärderas kvaliteten på programkoden, som är huvudsyftet med en pipeline för enbart kodkvalitet, och utförs omedelbart efter byggsteget i alla icke-produktions- och produktionspipelinjer. Se dokumentet Konfigurera icke-produktionsförlopp om du vill veta mer.

Kodkvalitetstestning söker igenom källkoden för att säkerställa att den uppfyller vissa kvalitetskriterier. Detta implementeras genom en kombination av SonarQube-analys, innehållspaketgranskning med OakPAL och dispatchervalidering med Dispatcher Optimization Tool.

Det finns över 100 regler som kombinerar allmänna Java-regler och AEM-specifika regler. Vissa av de AEM specifika reglerna har skapats baserat på bästa praxis från AEM och kallas för Anpassade regler för kodkvalitet.

Resultaten av kodkvalitetstestningen levereras som en klassificering enligt sammanfattningen i denna tabell.

Hantera med falskt positiva dealing-with-false-positives

Kvalitetsskanningsprocessen är inte perfekt och kan ibland felaktigt identifiera problem som inte är problematiska. Detta kallas falskt positivt.

I dessa fall kan källkoden kommenteras med Java-standarden @SuppressWarnings anteckning som anger regel-ID som anteckningsattribut. En vanlig positiv sak är att SonarQube-regeln för att identifiera hårdkodade lösenord kan vara aggressiv om hur ett hårdkodat lösenord identifieras.

Följande kod är ganska vanlig i ett AEM projekt, som har kod för att ansluta till en extern tjänst.

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

SonarQube utlöser då en sårbarhet som kan leda till blockering. Men när du har granskat koden inser du att detta inte är någon sårbarhet och kan kommentera koden med rätt regel-ID.

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

Om koden i själva verket var följande:

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

Den rätta lösningen är sedan att ta bort det hårdkodade lösenordet.

Säkerhetstestning security-testing

Cloud Manager kör de befintliga säkerhetskontrollerna AEM säkerhetshälsa i mellanlagringsmiljön efter distributionen och rapporterar statusen via användargränssnittet. Resultaten sammanställs från alla AEM instanser i miljön.

Samma hälsokontroller kan utföras när som helst via webbkonsolen eller kontrollpanelen för åtgärder.

Om någon av instanserna rapporterar ett fel för en viss hälsokontroll misslyckas hälsokontrollen i hela miljön. Precis som för kodkvalitets- och prestandatestning är dessa hälsokontroller ordnade i kategorier och rapporterade med hjälp av ett system med tre nivåer. Den enda skillnaden är att det inte finns något tröskelvärde när det gäller säkerhetstestning. Alla hälsokontroller godkänns eller misslyckas.

I följande tabell visas hälsokontrollerna.

Prestandatestning performance-testing

AEM Sites aem-sites

Cloud Manager kör prestandatestning för AEM Sites-program. Prestandatestet körs i cirka 30 minuter genom att virtuella användare (behållare) som simulerar att faktiska användare kommer åt sidor i stagningsmiljöer för att simulera trafik snurras. Dessa sidor hittas med en crawler.

Virtuella användare virtual-users

Antalet virtuella användare eller behållare som startas av Cloud Manager styrs av nyckeltal (svarstid och sidvisningar/min) som definieras av användaren med Företagsägare roll while skapa eller redigera programmet. Utifrån definierade KPI:er kommer upp till 10 behållare som simulerar verkliga användare att rensas. De sidor som väljs för testning delas upp och tilldelas varje virtuell användare.

Crawler crawler

Innan testperioden på 30 minuter börjar kommer Cloud Manager att crawla mellanlagringsmiljön med en uppsättning av en eller flera URL:er som konfigurerats av kundens Success Engineer. Med utgångspunkt från dessa URL:er inspekteras HTML på varje sida och länkarna gås igenom på bredden först.

Siduppsättningar för testning page-sets

Sidorna markeras med tre siduppsättningar. I Cloud Manager används åtkomstloggarna från AEM instanser i olika produktions- och stagingmiljöer för att fastställa följande bucklar.

Distribution av trafik mellan valda siduppsättningar distribution-of-traffic

Du kan välja var som helst från en till alla tre uppsättningar på Testning -fliken i pipeline-konfiguration. Trafikfördelningen baseras på antalet valda uppsättningar. Det vill säga, om alla tre är markerade placeras 33 % av det totala antalet sidvisningar mot varje uppsättning. Om två är markerade går 50 % till varje uppsättning. Om du väljer en sådan går 100 % av trafiken till den uppsättningen.

Låt oss titta på det här exemplet.

Under 30 minuters testperiod:

Testning och rapportering testing-reporting

Cloud Manager kör prestandatestning för AEM Sites-program genom att begära sidor som en oautentiserad användare som standard på testpubliceringsservern under en 30-minuters testperiod. Den mäter de värden som genereras av virtuella användare (svarstid, felfrekvens, vyer per minut osv.) för varje sida och olika systemnivåmått (CPU, minne, nätverksdata) för alla instanser.

I följande tabell sammanfattas prestandatestmatrisen med hjälp av ett gating-system med tre skikt.

Se avsnittet Autentiserad prestandatestning om du vill ha mer information om hur du använder grundläggande autentisering för prestandatestning för platser och resurser.

Autentiserad prestandatestning authenticated-performance-testing

Om det behövs kan AMS-kunder med autentiserade webbplatser ange ett användarnamn och lösenord som Cloud Manager ska använda för att få tillgång till webbplatsen under platsens prestandatestning.

Användarnamnet och lösenordet anges som pipeline-variabler med namnen CM_PERF_TEST_BASIC_USERNAME och CM_PERF_TEST_BASIC_PASSWORD.

Användarnamnet ska lagras i en string och lösenordet ska lagras i en secretString variabel. Om båda anges kommer alla begäranden från crawlningen av prestandatestet och de virtuella testanvändarna att innehålla dessa autentiseringsuppgifter som grundläggande HTTP-autentisering.

Om du vill ställa in dessa variabler med Cloud Manager CLI kör du:

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

Se Patch User Pipeline Variables API-dokumentation för att lära dig hur du använder API:t.

AEM Assets aem-assets

Cloud Manager kör prestandatestning för AEM Assets-program genom att överföra resurser upprepade gånger under en 30-minuters testperiod.

Krav för introduktion onboarding-requirement

För prestandatestning av Assets skapar din Customer Success Engineer en cloudmanager användare och lösenord vid introduktionen av författaren till mellanlagringsmiljön. Prestandateststegen kräver en användare som kallas cloudmanager och tillhörande lösenord som har konfigurerats av din CSE. Detta bör varken tas bort från författarinstansen eller dess behörigheter ändras. Om du gör det misslyckas förmodligen prestandatestningen av Assets.

Bilder och resurser för testning assets-for-testing

Kunderna kan överföra egna resurser för testning. Detta kan du göra på Inställningar för pipeline eller Redigera skärm. Vanliga bildformat som JPEG, PNG, GIF och BMP stöds tillsammans med Photoshop-, Illustrator- och Postscript-filer.

Om inga bilder överförs använder Cloud Manager en standardbild och PDF-dokument för testning.

Distribution av resurser för testning distribution-of-assets

Distributionen av hur många resurser av varje typ som överförs per minut anges i Inställningar för pipeline eller Redigera skärm.

Om t.ex. en delning på 70/30 används och det finns 10 resurser överförda per minut, överförs 7 bilder och 3 dokument per minut.

Testning och rapportering testing-and-reporting

I Cloud Manager skapas en mapp på författarinstansen med användarnamnet och lösenordet som konfigurerats av CSE. Resurserna överförs sedan till mappen med hjälp av ett bibliotek med öppen källkod. Testerna som körs i Assets-teststeget skrivs med en open source-bibliotek. Både bearbetningstiden för varje resurs och olika mätvärden på systemnivå mäts under testperioden på 30 minuter. Den här funktionen kan överföra både bilder och PDF-dokument.

Resultatdiagram för prestandatestning performance-testing-results-graphs

Ett antal mätvärden finns i Dialogrutan Prestandatest

Måttpanelerna kan expanderas för att visa ett diagram, ge en länk till en hämtning eller båda.

Den här funktionen är tillgänglig för följande mätvärden.

Optimering av skanning av innehållspaket content-package-scanning-optimization

Som en del av kvalitetsanalysprocessen utför Cloud Manager en analys av innehållspaketen som skapats av Maven-bygget. I Cloud Manager finns optimeringar som snabbar upp den här processen, som är effektiva när vissa paketeringsbegränsningar iakttas. Det viktigaste är optimeringen som utförs för projekt som genererar ett enstaka innehållspaket, som vanligtvis kallas"all"-paket, som innehåller ett antal andra innehållspaket som skapats av bygget och som markeras som överhoppade. När Cloud Manager identifierar detta scenario, i stället för att packa upp"alla"-paketet, skannas de enskilda innehållspaketen direkt och sorteras baserat på beroenden. Ta till exempel följande byggutdata.

Om de enda objekten i myco-all-1.0.0-SNAPSHOT.zip är de två överhoppade innehållspaketen, skannas de två inbäddade paketen i stället för innehållspaketet"all".

För projekt som producerar dussintals inbäddade paket har den här optimeringen visat sig spara upp till 10 minuter per pipeline-körning.

Ett specialfall kan inträffa när innehållspaketet "all" innehåller en kombination av överhoppade innehållspaket och OSGi-paket. Om myco-all-1.0.0-SNAPSHOT.zip innehåller de två inbäddade paketen som tidigare nämnts samt ett eller flera OSGi-paket, och sedan konstrueras ett nytt, minimalt innehållspaket med endast OSGi-paketen. Det här paketet har alltid namnet cloudmanager-synthetic-jar-package och de medföljande paketen placeras i /apps/cloudmanager-synthetic-installer/install.