Codekwaliteitstests
- Onderwerpen:
- Cloud Manager
Gemaakt voor:
- Beheerder
Leer hoe het testen van de codekwaliteit van pijpleidingen werkt en hoe het de kwaliteit van uw plaatsingen kan verbeteren.
Inleiding
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
Er liggen drie poorten in de pijplijn:
- Codekwaliteit
- Prestatietesten
- Beveiligingstests
Voor elk van deze poorten is er een structuur met drie lagen voor problemen die door de poort worden geïdentificeerd.
- Kritieke - Kwesties die een directe mislukking van de pijpleiding veroorzaken.
- Belangrijk - Kwesties die de pijpleiding veroorzaken om een gepauzeerde staat in te gaan. Een plaatsingsmanager, projectmanager, of bedrijfseigenaar kan of de kwesties met voeten treden. Als ze dat doen, gaat de pijpleiding door zoals bedoeld. Alternatief, kunnen zij de kwesties goedkeuren, veroorzakend de pijpleiding om met een mislukking te stoppen. De opheffing van belangrijke mislukkingen is onderworpen aan a onderbreking.
- Info - Kwesties die puur voor informatiedoeleinden worden verstrekt en geen effect op pijpleidingsuitvoering hebben.
NOTECodekwaliteitstests
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 de Techniek van AEM en worden bedoeld als Regels van de Kwaliteit van de Code van de Douane.
U kunt de huidige volledige lijst van regels downloaden gebruikend deze verbinding.
IMPORTANTDe resultaten van het testen van de codekwaliteit worden geleverd als classificatie zoals samengevat in deze lijst.
B = minstens 1 minder kleine kwetsbaarheid
C = minstens 1 belangrijke kwetsbaarheid
D = minstens 1 kritieke kwetsbaarheid
E = minstens 1 blokkeerkwetsbaarheid
B = minstens 1 minder kleine insect
C = minstens 1 belangrijke insect
D = minstens 1 kritieke insect
E = minstens 1 blocker bugs
Gedefinieerd door de openstaande herstelkosten voor code ruikt als een percentage van de tijd dat al naar de toepassing is gegaan
- A = <=5%
- B = 6-10%
- C = 11-20%
- D = 21-50%
- E = >50%
Gedefinieerd door een combinatie van de dekking van de testlijn en de voorwaarde met de volgende formule:Coverage = (CT + CF + LC) / (2 * B + EL)
CT= Voorwaarden die ten minste één keer alstruezijn geëvalueerd tijdens het uitvoeren van eenheidstestsCF= Voorwaarden die ten minste één keer alsfalsezijn geëvalueerd tijdens het uitvoeren van eenheidstestsLC= Covered lines = lines_to_cover - uncover_linesB= totaal aantal voorwaardenEL= totaal aantal uitvoerbare regels (lines_to_cover)
Gedefinieerd als het aantal regels dat is betrokken bij gedupliceerde blokken. Een codeblok wordt als gedupliceerd beschouwd onder de volgende omstandigheden.
niet-Java Projecten:
- Er moeten ten minste 100 opeenvolgende en gedupliceerde tokens zijn.
- Deze tokens moeten ten minste worden verspreid over:
- 30 regels code voor COBOL
- 20 coderegels voor ABAP
- 10 coderegels voor andere talen
Java-projecten:
- Er moeten minstens tien opeenvolgende en gedupliceerde instructies zijn, ongeacht het aantal tokens en regels.
Verschillen in inspringing en in letterlijke tekenreeksen worden genegeerd wanneer duplicaten worden gedetecteerd.
NOTENOTEOmgaan met valse positieven
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 algemeen in een project van AEM, 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.
NOTE@SuppressWarnings zo specifiek mogelijk te maken. Dat wil zeggen dat u alleen de specifieke instructie of het specifieke blok aanwijst die de uitgave veroorzaakt. Het is echter mogelijk om notities te maken op klasseniveau. Dit maakt een bredere onderdrukking van waarschuwingen mogelijk.Beveiligingstest
Cloud Manager voert de bestaande AEM Security Heath Checks uit op de testomgeving na implementatie en rapporteert de status via de gebruikersinterface. De resultaten worden samengevoegd van alle AEM-instanties 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.
AuthorizableNodeName -implementatie stelt geen machtigbare id beschikbaar in de knooppuntnaam/het pad.Sling standaard GET servlet is beveiligd tegen DOS-aanvallen.Sling Get servletSling JavaScript-handler is op de juiste wijze geconfigureerd.Sling JavaScript HandlerSling JSP Scripthandler wordt op de juiste wijze geconfigureerd.Sling JSP Script-handlerSling Referrer wordt gevormd om aanvallen te verhinderen CSRF.Sling DavEx-bundel en -servlet zijn uitgeschakeld.Sling WebDAV-bundel en -servlet zijn op de juiste wijze geconfigureerd.admin .Prestatietests
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
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
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 doorlopen op een wijze die begint met het doorlopen van de breedte.
- Dit schuifproces is standaard beperkt tot maximaal 5000 pagina's.
- Het maximumaantal te testen pagina's kan worden overschreven door de pijpleidingsvariabele
CM_PERF_TEST_CRAWLER_MAX_PAGESte plaatsen.- Toegestane waarden zijn
2000-7000.
- Toegestane waarden zijn
- De verzoeken van de kruipper hebben een vaste onderbreking van 10 seconden.
Paginasets voor testen
Drie paginasets selecteren de pagina's. Cloud Manager gebruikt de toegangslogboeken van de instanties van AEM over productie en het opvoeren milieu's om de volgende emmers te bepalen.
-
Populaire Levende Pagina's - verzekert dat de populairste pagina's die door levende klanten worden betreden worden getest. Cloud Manager leest het toegangslogboek en bepaalt de hoogste 25 meest toegankelijke pagina's door levende klanten om een lijst van bovenkant te produceren
Popular Live Pages. Het snijpunt van deze pagina's die ook aanwezig zijn in de testomgeving, wordt vervolgens gekropen in de testomgeving. -
Andere Levende Pagina's - verzekert dat de pagina's die buiten de hoogste 25 populaire levende pagina's vallen die niet populair kunnen zijn, maar belangrijk zijn te testen, worden getest. Net als bij populaire live pagina's worden deze uit het toegangslogboek geëxtraheerd en moeten ze ook aanwezig zijn in de testomgeving.
-
Nieuwe Pagina's - test nieuwe pagina's die slechts aan het opvoeren en nog niet aan productie kunnen zijn opgesteld, maar moeten worden getest.
Verdeling van verkeer over geselecteerde paginasets
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.
- Er is een splitsing van 50/50 tussen de populaire live pagina's en nieuwe paginasets.
- Andere actieve pagina's worden niet gebruikt.
- De nieuwe paginaset bevat 3000 pagina's.
- De KPI paginameningen per minuut worden geplaatst aan 200.
Gedurende de testperiode van 30 minuten:
- Elk van de 25 pagina's in de populaire set live pagina's wordt 120 keer weergegeven:
((200 * 0.5) / 25) * 30 = 120 - Elk van de 3000 pagina's in de nieuwe paginaset wordt één keer geraakt:
((200 * 0.5) / 3000) * 30 = 1
Testen en rapporteren
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.
NOTEGeverifieerde prestaties testen
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
Cloud Manager voert prestatietests uit voor AEM Assets-programma's door elementen herhaaldelijk gedurende 30 minuten te uploaden.
Verplichting aan boord
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
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 samen met Photoshop-, Illustrator- en Postscript-bestanden ondersteund.
Als er geen afbeeldingen zijn geüpload, gebruikt Cloud Manager een standaardafbeelding en PDF-documenten om te testen.
Distributie van Assets voor tests
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
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. Deze functie kan zowel afbeeldingen als PDF-documenten uploaden.
TIPPrestatietestresultaten
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.
Deze functionaliteit is beschikbaar voor de volgende metriek.
-
het Gebruik van CPU - een grafiek van het gebruik van CPU tijdens de testperiode
-
Schijf I/O wacht Tijd - een grafiek van schijf I/O wacht tijd tijdens de testperiode
-
Tarief van de Fout van de Pagina - een grafiek van paginafouten per minuut tijdens de testperiode
- Een CSV-bestand met pagina's die een fout hebben veroorzaakt tijdens de test
-
het Gebruik van de Bandbreedte van de Schijf - een grafiek van het gebruik van de schijfbandbreedte tijdens de testperiode
-
Gebruik van de Bandbreedte van het Netwerk - een grafiek van het gebruik van de netwerkbandbreedte tijdens de testperiode
-
Piekresponstijd - Een grafiek van de piekresponstijd per minuut tijdens de testperiode
-
95th Percentile Tijd van de Reactie - een grafiek van 95th percentile reactietijd per minuut tijdens de testperiode
- Een CSV-bestandenlijst met pagina's waarvan de responstijd van 95% de gedefinieerde PKI heeft overschreden
Optimalisatie van scannen van inhoudspakketten
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.
all/myco-all-1.0.0-SNAPSHOT.zip(content-package)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip(overgeslagen-content-package)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip(overgeslagen-content-package)
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.
NOTE- Deze optimalisatie heeft geen invloed op de pakketten die naar AEM worden geïmplementeerd.
- Het afstemmen tussen ingesloten en overgeslagen inhoudspakketten is gebaseerd op bestandsnamen. Deze optimalisatie mislukt als meerdere overgeslagen inhoudspakketten dezelfde bestandsnaam hebben of als de bestandsnaam tijdens het insluiten verandert.