Présentation
Découvrez les points de contrôle qualité disponibles dans le processus de déploiement AEM as a Cloud Service et les différents types de tests fonctionnels intégrés. Découvrez comment contribuer et optimiser leur utilisation dans le cadre d’une stratégie de test exhaustive.
A propos des tests fonctionnels
Le diagramme suivant présente un aperçu général des pipelines disponibles dans le cadre d’une stratégie de test globale et du processus de déploiement AEM as a Cloud Service.
Objectif des tests fonctionnels
Les pipelines de déploiement d’AEM Cloud Service ont pour objectif de faciliter des déploiements robustes et sécurisés à différentes étapes de votre développement et d’AEM cycle de vie des versions du produit. Ces pipelines intègrent plusieurs points de contrôle de qualité à différents niveaux afin de garantir l’intégrité et la sécurité des déploiements pour vos modifications d’applications AEM et pour AEM mises à jour de produits.
Adobe fournit plusieurs points de contrôle qualité intégrés, tandis que d’autres nécessitent votre intervention pour la mise en oeuvre et la configuration. Ces points de contrôle qualité sont polyvalents, s’appliquent à différentes étapes du cycle de vie et s’intègrent directement à votre configuration de développement et à vos processus CI/CD.
Les points de contrôle qualité intégrés valident principalement les fonctionnalités du produit AEM dans le contexte de votre application AEM. En revanche, les points de contrôle de qualité personnalisés que vous configurez sont conçus pour vérifier que les fonctionnalités critiques de votre application et les interactions utilisateur fonctionnent comme prévu. Collectivement, ces deux ensembles de points de contrôle de qualité fonctionnent ensemble pour garantir des déploiements automatisés robustes et sécurisés pour vos modifications de code et pour AEM mises à jour de produit.
Il est important de noter que ces points de contrôle qualité ne sont pas destinés à constituer un cadre de test complet pour l’ensemble de votre stratégie de test. Le produit AEM est soumis à des tests approfondis avant d’entrer dans le processus de déploiement du service cloud AEM. De même, votre application doit déjà être de haute qualité avant d’atteindre la phase de déploiement. Cette approche permet de s’assurer que les points de contrôle de qualité se concentrent sur leur principal objectif de protection du processus de déploiement, plutôt que de se substituer à un régime de test complet.
Points de contrôle de qualité dans les tests
Le diagramme suivant fournit une vue détaillée des points de contrôle qualité disponibles et de leur utilisation dans la stratégie de test globale et le processus de déploiement AEM as a Cloud Service.
Points de contrôle qualité fournis par le client récapitulatif
| Tests unitaires | Tests fonctionnels personnalisés | Tests de l’interface utilisateur personnalisés | Validations du client | Test manuel | |
|---|---|---|---|---|---|
| Pipeline de production | Oui Blocking | Oui Blocking 60m Timeout | Oui Blocking Délai d’expiration de 30 m | Non | Non |
| Pipeline hors production | Oui Blocking | Opt-in Blocking Délai d’expiration de 60 m | Opt-in Blocking Délai d’expiration de 30 m | Non | Non |
| Adobe la validation interne | Oui Blocking | Oui Blocking 60m Timeout | Oui Blocking Délai d’expiration de 30 m | Non | Non |
| Customer CI/CD | Oui | Oui | Oui | Oui | Oui |
| Développeur local du client | Oui | Oui | Oui | Oui | Oui |
Test unitaire
Nous vous recommandons de fournir les tests unitaires pour votre application AEM, qui constituent la base de chaque stratégie de test. Ils sont conçus pour fonctionner rapidement et souvent et donner des retours rapides et précoces. Ils sont étroitement intégrés aux workflows des développeurs, à vos propres CI/CD et aux pipelines de déploiement du service cloud d’AEM.
Ils sont implémentés à l’aide de JUnit et exécutés avec Maven. Consultez le module core de l’archétype de projet AEM pour obtenir un exemple de test unitaire pour AEM et pour commencer.
Qualité du code
Ce point de contrôle qualité est configuré prêt à l’emploi et exécute une analyse de code statique sur votre code d’application AEM.
Voir Test de qualité du code et Règles de qualité du code personnalisé pour plus d’informations.
Tests de produit
Les tests fonctionnels du produit sont des tests d’intégration HTTP stables (IT) pour les fonctionnalités de base de l’AEM, y compris les tâches de création et de réplication. Adobe les fournit et les conserve prêts à l’emploi. Elles sont destinées à empêcher le déploiement des modifications apportées au code d’application personnalisé si celui-ci rompt les fonctionnalités de base du produit AEM.
Ils utilisent JUnit pour la mise en oeuvre, exécutent avec Maven et dépendent des clients de test d’AEMofficiels. La suite de tests de produit est conservée en tant que
Un projet open source suit les bonnes pratiques et peut être considéré comme un bon point de départ pour la mise en oeuvre de vos tests.
Tests fonctionnels personnalisés
Tout comme les tests de produit, les tests fonctionnels du client sont les tests d’intégration HTTP (IT) implémentés avec JUnit, exécutés à l’aide de Maven et conçus sur les clients de test d’AEMofficiels.
REMARQUEPour garantir des exécutions de pipeline efficaces, Adobe conseille de se concentrer sur les fonctionnalités clés et les flux d’interaction utilisateur principaux, en vue d’une exécution de test fonctionnel d’environ 15 minutes ou moins. Les suites de tests fonctionnels complètes qui dépassent ce délai doivent être exécutées dans le cadre des pipelines de validation client généraux pendant le processus de développement.
Voir tests de produit Open Source ou le module it.tests de l’archétype de projets AEM pour consulter des exemples.
Pour plus d’informations, consultez Tests fonctionnels Java.
Tests de l’interface utilisateur personnalisée
Pour optimiser le contrôle des risques pour votre développement spécifique au client, Adobe vous encourage à capturer des tests d’interface utilisateur critiques dans AEM as a Cloud Service. Limitez-les, mais ciblez-les sur l’optimisation de leur impact sur l’expérience client.
Les tests sont conditionnés dans une image Docker, conçue pour être aussi volatile que possible (avec prise en charge de Cypress, Playwright, Selenium, Java et JavaScript). Ils suivent les mêmes caractéristiques et objectifs que les tests fonctionnels personnalisés.
REMARQUEPour que les exécutions de pipeline restent efficaces, Adobe recommande de se concentrer sur les fonctionnalités clés et les principaux flux d’interaction utilisateur. Les suites de tests d’interface utilisateur complètes qui dépassent ce point de contrôle qualité doivent être exécutées dans le cadre des pipelines de validation client généraux. Intégrez-les au processus de développement du client.
Pour obtenir des exemples, reportez-vous à la section Exemple de test Open Source ou au module ui.tests de l’AEM’archétype Projets .
Pour plus d’informations, consultez Tests personnalisés de l’interface utilisateur.
Audit d’expérience
Le point de contrôle de la qualité de l’expérience effectue des audits Google Lighthouse sur la page web du client.
Ce point de contrôle qualité est fourni par AEM prêt à l’emploi, mais ne bloque pas les pipelines de déploiement. Par défaut, un audit de la page racine (/) de l’instance de publication est effectué. Vous pouvez contribuer en configurant jusqu’à 25 chemins personnalisés pris en compte pour les audits.
Pour plus d’informations, voir Test d’audit d’expérience .
Validations client
Le point de contrôle qualité des validations client est un espace réservé à la stratégie et aux efforts de test du client, exécuté avant que les modifications de l’application du client n’atteignent les pipelines de déploiement cloud AEM.
Vous pouvez y choisir les outils et les structures que vous préférez. Contrairement aux tests de fonction client et aux tests d’interface utilisateur personnalisés, il n’existe aucune limite liée à AEM as a Cloud Service. Par conséquent, Adobe vous recommande d’effectuer ici des tests fonctionnels et d’interface utilisateur de longue durée.
Bien que vous puissiez choisir n’importe quel outil et structure, Adobe vous suggère d’aligner les tests d’intégration et d’interface utilisateur basés sur HTTP avec les outils et les structures utilisés aux points de contrôle de qualité des tests fonctionnels et d’interface utilisateur personnalisés. En outre, Adobe recommande d’incorporer des environnements de développement rapide (RDE) dans votre stratégie de test locale pour refléter AEM les environnements cloud de près.
Test manuel
Le point de contrôle qualité des tests manuels est un espace réservé pour les clients qui effectuent des tests manuels. Comme les pipelines de cloud AEM ne prennent pas en charge les tests manuels, ils doivent être inclus dans votre stratégie de test locale.
Pour les tests manuels, il peut s’avérer utile de l’intégrer à un environnement de développement AEM Cloud Service supplémentaire.