Inleiding functional-testing-introduction

Meer informatie over de kwaliteitskates in het dialoogvenster as a Cloud Service implementatieproces AEM, de verschillende ingebouwde soorten functionele tests, hoe u kunt bijdragen en hoe u deze optimaal kunt gebruiken in de context van een algemene teststrategie.

Overzicht

Het volgende diagram geeft een overzicht op hoog niveau van de beschikbare pijpleidingen in de context van een algemene teststrategie en de as a Cloud Service implementatieproces AEM.

AEM Cloud Service-implementatiekwaliteitspoorten

Doel

Het doel van de AEM Cloud Service-distributiepijpleidingen is om robuuste en veilige implementaties in verschillende fasen van de ontwikkelings- en AEM levenscyclus van producten te vergemakkelijken. Deze pijpleidingen omvatten veelvoudige kwaliteitsspoorten op verschillende niveaus om de integriteit en de veiligheid van plaatsingen voor zowel uw AEM toepassingsveranderingen als AEM productupdates te verzekeren.

Adobe biedt verschillende ingebouwde kwaliteitspoorten, terwijl andere toepassingen uw interventie vereisen voor implementatie en configuratie. Deze kwaliteitspoorten zijn veelzijdig, waarbij sommige van deze poorten in verschillende fasen van de levenscyclus van toepassing zijn en zelfs geïntegreerd kunnen worden in uw eigen ontwikkelinstellingen en CI/CD-processen.

De ingebouwde kwaliteitspoorten valideren vooral de functionaliteit van het AEM product binnen de context van uw AEM. De aangepaste kwaliteitskates die u instelt, zijn daarentegen ontworpen om te controleren of de kritieke functies en gebruikersinteracties van uw toepassing naar behoren functioneren. Samen werken deze twee sets kwaliteitspoorten samen om robuuste en beveiligde geautomatiseerde implementaties voor zowel uw codewijzigingen als AEM productupdates te garanderen.

Het is belangrijk om op te merken dat deze kwaliteitspoorten niet bedoeld zijn als een uitgebreid testkader voor uw volledige teststrategie. Het AEM product wordt uitgebreid getest voordat het de AEM implementatieproces van de cloudservice binnengaat. Uw toepassing moet ook al van hoge kwaliteit zijn voordat deze de implementatiefase bereikt. Deze aanpak zorgt ervoor dat de kwaliteitsdoelen zich richten op hun primaire doel om het implementatieproces te waarborgen, in plaats van een volledig testregime te vervangen.

Kwaliteitsgates

Het volgende diagram geeft een gedetailleerd overzicht van de beschikbare kwaliteitskates en het gebruik ervan in de algemene teststrategie en de as a Cloud Service implementatieproces AEM.

AEM Cloud Service-implementatiekwaliteitspoorten

Door de klant geleverde kwaliteitsbonnen

Eenheidstests
Aangepast
Functionele tests
Aangepast
UI-tests
Klant
Validaties
Handmatig
Testen
Productiepijpleiding
Ja
Blokkeren
Ja
Blokkeren
60m Time-out
Ja
Blokkeren
60m Time-out
Nee
Nee
Niet-productiepijpleiding
Ja
Blokkeren
Inschakelen
Blokkeren
60m Time-out
Inschakelen
Blokkeren
60m Time-out
Nee
Nee
Interne validatie Adobe
Ja
Blokkeren
Ja
Blokkeren
60m Time-out
Ja
Blokkeren
60m Time-out
Nee
Nee
Klant-CI/CD
Ja
Ja
Ja
Ja
Ja
Lokale ontwikkelaar van klant
Ja
Ja
Ja
Ja
Ja

Eenheidstest

U wordt aangemoedigd om de eenheidstests voor uw AEM toepassing te verstrekken, die de basis van elke teststrategie vormen. Ze zijn bedoeld om snel en vaak te draaien en snel feedback te geven. Ze zijn nauw geïntegreerd in de workflows voor ontwikkelaars, uw eigen CI/CD en de implementatiepijplijnen voor de AEM cloudservice.

Ze worden geïmplementeerd met JUnit en uitgevoerd met Maven. Zie kernmodule van het AEM Project Archetype voor een voorbeeldeenheidstest voor AEM en aan de slag gaan.

Codekwaliteit

Deze kwaliteitspoort is geconfigureerd buiten de box en voert statische codeanalyse uit op uw AEM toepassingscode.

Zie Testen van de codekwaliteit en Aangepaste regels voor codekwaliteit voor meer informatie .

Producttests

De functionele tests van het product zijn een reeks stabiele HTTP integratietests (ITs) van kernfunctionaliteit in AEM zoals creatie en replicatietaken. De Adobe verstrekt en handhaaft hen uit-van-de-doos. Ze zijn bedoeld om te voorkomen dat wijzigingen in aangepaste toepassingscode worden geïmplementeerd als deze de kernfunctionaliteit van het AEM verbreekt.

Ze worden geïmplementeerd met Junit, worden uitgevoerd met Maven en gebruiken de officiële Clients AEM testen. De producttestsuite wordt als een open-source-project, volgt de beste praktijken en kan als een goed uitgangspunt voor de implementatie van uw tests worden beschouwd.

Aangepaste functionele tests

Zoals de producttests, zijn de functionele tests van de klant de integratietests van HTTP (ITs) en worden zo goed uitgevoerd gebruikend Junit, uitgevoerd gebruikend Maven en gebouwd bovenop de officiële Clients AEM testen.

NOTE
Aangepaste functionele tests worden uitgevoerd in de productie- en niet-productiepijpleidingen (opt-in) die worden gebruikt door wijzigingen in de implementatie van AEM toepassing en AEM productpushupdates en die daarom een belangrijke bijdrage leveren aan het goed functioneren van uw toepassing en het verhogen van de veiligheid van de release. De functionele tests van de klant worden ook uitgevoerd in interne pre-releasevalideringspijpleidingen voor elke klant, wat helpt om vroege feedback te geven.

Om pijplijnlooppas efficiënt te houden, adviseren wij zich op zeer belangrijke eigenschappen en belangrijkste gebruikersinteractiestromen te concentreren. Een runtime van ~15 minuten of minder voor functionele tests wordt aanbevolen. Volledige functionele testreeksen die niet in deze kwaliteitspoort passen, worden aanbevolen als onderdeel van algemene klantvalideringsleidingen tijdens de ontwikkelingscyclus van de klant.

Zie open-sourced producttests of de it.tests module van de Archetype van de Projecten van de AEM voor voorbeelden.

Zie Functionele Java-tests voor meer informatie .

Aangepaste UI-tests

Om risicobeheersing voor uw klant-specifieke ontwikkeling te maximaliseren, moedigt de Adobe u sterk aan om kritieke tests UI in AEMCS te vangen. Het is de bedoeling dat ze in aantal beperkt blijven, maar met de grootste invloed op uw klantervaring.

De tests worden verpakt in een Docker-afbeelding - ontworpen om zo vluchtig mogelijk te zijn (met ondersteuning voor Cypress, Selenium, Java en Javascript). Ze hebben dezelfde kenmerken en doeleinden als de aangepaste functionele tests.

NOTE
Aangepaste UI-tests worden uitgevoerd in de productie- en niet-productie (opt-in) pijpleidingen die worden gebruikt door de implementatie van de AEM toepassing en AEM productpush-updates, en vormen daarom een belangrijke bijdrage aan het goed functioneren van uw toepassing en het verhogen van de veiligheid van de release. De tests van de klantengebruikersinterface worden ook uitgevoerd in interne pre-releasebevestigingspijpleidingen voor elke klant, die hulp vroege terugkoppelt verstrekt.

Om pijpleiding efficiënte uitvoeringen te houden, adviseren wij zich op zeer belangrijke eigenschappen en belangrijkste gebruikersinteractiestromen te concentreren. Volledige UI-testsuites die niet in deze kwaliteitspoort passen, worden aanbevolen als onderdeel van algemene klantvalidatiepijpleidingen tijdens de ontwikkelingsstroom van de klant.

Zie open-sourced voorbeeldtests of de ui.tests module van de Archetype van de Projecten van de AEM voor voorbeelden.

Zie Aangepaste UI-tests voor meer informatie .

Experience Audit

Het kwaliteitsgate van de ervaringscontrole wordt uitgevoerd Google Lighthouse op de website van de klant.

Deze kwaliteitspoort wordt geleverd door AEM kant-en-klaar, maar blokkeert de uitrol van pijpleidingen niet. Standaard wordt een controle uitgevoerd op de hoofdpagina (/) van het publicatieexemplaar wordt uitgevoerd. U kunt bijdragen door maximaal 25 douanewegen te vormen die voor controles worden overwogen.

Zie Ervaring controleren testen voor meer informatie .

Klantenvalidaties

De kwaliteitsgate voor klantvalidaties is een plaatsaanduiding voor de eigen teststrategie en -inspanning van de klant, die worden uitgevoerd voordat de wijzigingen in de toepassing van de klant de implementatiepijplijnen van de AEM cloud bereiken.

Hier kunt u de gewenste gereedschappen en frameworks kiezen. In tegenstelling tot de tests van de klantenfunctie en van de douaneUI, zijn er geen AEM as a Cloud Service verwante grenzen, en wij adviseren daarom om de functie en UI het testen hier uit te voeren.

Terwijl u om het even welk hulpmiddel en kader vrij kunt kiezen, adviseren wij u op HTTP-Gebaseerde integratietests en tests UI met de hulpmiddelen en het kader beschikbaar in de de kwaliteitsproeven van de douane functionele tests en van de douanetest UI. We raden u aan om integratie Rapid Development Environment (RDE) in uw lokale teststrategie om zo dicht mogelijk bij AEM cloudomgevingen te testen.

Handmatig testen

De poort voor het handmatig testen van de kwaliteit is een plaatsaanduiding voor klanten die handmatig testen uitvoeren. AEM wolkenpijpleidingen ondersteunen handmatige tests niet en dit moet daarom gebeuren als onderdeel van uw eigen lokale teststrategie.

Voor handmatige tests kan het nuttig zijn om te integreren met een extra AEM Cloud Service-ontwikkelomgeving.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab