Kodkvalitetstestning 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 pipeline-körningen hämtar programvaran ett antal mätvärden. Dessa mått jämförs sedan med nyckeltal (KPI) som definieras av företagsägaren. Eller så jämförs de med de standarder som Adobe Managed Services har fastställt.

Dessa resultat rapporteras med ett klassificeringssystem med tre nivåer.

Betyg med tre nivåer 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.

Kodkvalitetstestning code-quality-testing-step

I det här teststeget utvärderas kvaliteten på programkoden, som är huvudsyftet med en pipeline som enbart innehåller kod. Den utförs omedelbart efter byggsteget i alla icke-produktions- och produktionspipelinor. Om du vill ha mer information går du till Konfigurera icke-produktionsförlopp.

Kodkvalitetstestning söker igenom källkoden för att säkerställa att den uppfyller vissa kvalitetskriterier.

Programmet implementerar det med en kombination av SonarQube-analys, innehållspaketgranskning med OakPAL och Dispatcher-validering med Dispatcher Optimization Tool.

Det finns mer än 100 regler som kombinerar allmänna Java-regler och AEM-specifika regler. Vissa av de AEM reglerna skapas 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 falskt positiva dealing-with-false-positives

Kvalitetsskanningsprocessen är inte perfekt och identifierar ibland felaktigt problem som inte är problematiska. Detta scenario kallas för falskt positivt.

I dessa fall kan källkoden antecknas med Java @SuppressWarnings-standardanteckningen 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 sedan en sårbarhet som kan leda till blockering. Men när du har granskat koden inser du att det här problemet 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 AEM säkerhetshälsokontroller i mellanlagringsmiljön efter distributionen och rapporterar statusen via grä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 om det finns säkerhetstester. 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

Cloud Manager snurrar upp virtuella användare eller behållare baserat på nyckeltal (svarstid och sidvisningar/min) som angetts av rollen Affärsägare. Dessa KPI:er anges när skapar eller redigerar programmet.

Utifrån definierade KPI:er rensas upp till tio behållare som simulerar verkliga användare. De sidor som väljs för testning delas upp och tilldelas varje virtuell användare.

Crawler crawler

Innan testperioden på 30 minuter inleds crawlar Cloud Manager testmiljön med en uppsättning av en eller flera URL:er som konfigurerats av kundens Success Engineer. Från dessa URL:er granskas HTML på varje sida och länkar gås igenom på bredden först.

Siduppsättningar för testning page-sets

Tre siduppsättningar markerar sidorna. Cloud Manager använder åtkomstloggarna från de AEM instanserna i olika produktions- och stagingmiljöer för att fastställa följande bukområden.

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å fliken Testing i din pipeline-konfiguration. Trafikfördelningen baseras på antalet valda uppsättningar. Det innebär att om alla tre är markerade placeras 33 % av det totala antalet sidvisningar i 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:

Testa och rapportera 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å publiceringsservern för testperioden i 30 minuter. Den mäter de värden som genereras av virtuella användare (svarstid, felfrekvens, vyer per minut och så vidare) för varje sida och olika värden på systemnivå (processor, minne, nätverksdata) för alla instanser.

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

Mer information om hur du använder grundläggande autentisering för prestandatestning för platser och Assets finns i Autentiserad prestandatestning.

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 använder för att få tillgång till webbplatsen under webbplatstestningen.

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

Användarnamnet lagras i en string-variabel och lösenordet lagras i en secretString-variabel. Om båda dessa variabler anges innehåller varje begäran från crawlern för prestandatestning och de virtuella testanvändarna 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 Laga användarens pipeline-variabler 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 i 30 minuter.

Krav på registrering onboarding-requirement

För prestandatestning i Assets skapar din Customer Success Engineer en cloudmanager-användare och ett lösenord när författaren kommer till mellanlagringsmiljön. Prestandateststegen kräver en användare med namnet cloudmanager och det associerade lösenordet som har konfigurerats av din CSE.

Den här metoden ska vara kvar i författarinstansen med sina behörigheter oförändrade. Om du ändrar eller tar bort den kan Assets prestandatestning misslyckas.

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

Kunderna kan överföra egna resurser för testning. Den här processen kan utföras från skärmen Inställningar för pipeline eller Redigera. 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 Assets för testning distribution-of-assets

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

Om exempelvis 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.

Testa och rapportera testing-and-reporting

Cloud Manager skapar en mapp på författarinstansen med det användarnamn och lösenord som CSE-installationen använder. Assets överförs sedan till mappen med ett bibliotek med öppen källkod. Testen som körs av Assets teststeg har skrivits med ett bibliotek med öppen källkod. 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 är tillgängliga 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 gör Cloud Manager en analys av de innehållspaket som skapats av Maven-bygget. Cloud Manager erbjuder optimeringar som snabbar upp denna process, som är effektiv när vissa paketeringsbegränsningar iakttas.

Nyckeloptimeringen är för projekt som genererar ett enda"all"-paket som innehåller andra innehållspaket som skapats av bygget, som markeras som överhoppade. När Cloud Manager identifierar detta scenario, i stället för att packa upp"all"-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 till exempel innehåller de två inbäddade paketen som nämndes tidigare och ett eller flera OSGi-paket, skapas ett nytt, minimalt innehållspaket med endast OSGi-paketen. Det här paketet har alltid namnet cloudmanager-synthetic-jar-package och de inkluderade paketen placeras i /apps/cloudmanager-synthetic-installer/install.