Skip to main content
Avant le lancement, vous devriez avoir effectué tous les tests applicables à votre environnement. L’assurance qualité est essentielle pour repérer les problèmes avant qu’ils n’aient des répercussions sur vos clients et, selon la nature de votre projet, vous devrez envisager plusieurs types de tests d’assurance qualité dans le cadre de votre intégration avec Auth0 :
  • Votre application est-elle facile à comprendre et à utiliser, y compris pour les personnes en situation de handicap ?
  • Votre application doit-elle fonctionner sur différents navigateurs et appareils ?
  • Votre application doit-elle fonctionner dans des environnements multinationaux ou internationaux ?
  • Comment votre application se comportera-t-elle lorsqu’elle sera soumise à des charges de Production imprévues ?
  • Comment vous assurer que votre application est protégée contre les vulnérabilités de sécurité ?
Auth0 Universal Login et les widgets d’interface utilisateur associés (comme Lock) ont déjà été conçus et développés selon les pratiques exemplaires en matière de convivialité et d’accessibilité, et offrent une prise en charge prête à l’emploi, déjà testée, pour toute une gamme de navigateurs et appareils. La prise en charge de l’internationalisation (I18N) est également offerte prête à l’emploi, avec une extensibilité intégrée conçue pour les contextes personnalisés multilingues et de localisation (L10N). Pour vous assurer que les exigences fonctionnelles sont respectées et que les événements imprévus sont gérés correctement, des directives sont fournies pour tester l’intégration entre vos applications et Auth0, ainsi que pour effectuer les tests unitaires de modules d’extensibilité individuels (comme Rules, Hooks et les scripts de base de données personnalisée). Des directives sont également fournies au sujet de la politique de tests d’intrusion d’Auth0 pour vous aider lors des tests de vulnérabilités de sécurité, ainsi que sur la façon de tirer parti des tests simulation conjointement avec notre politique de tests de charge afin de contribuer à garantir le bon fonctionnement de vos applications sous une charge imprévue.

​
Tests unitaires

L’objectif des tests unitaires est de tester des unités de code individuelles. Si vous créez du code personnalisé dans Auth0 sous forme de Rules, de Hooks et/ou de scripts de base de données personnalisés, vous devriez envisager d’utiliser un framework de test (comme Mocha) pour tester votre code. Les entreprises qui ont le mieux réussi avec Auth0 ont trouvé utile d’exécuter ces tests unitaires avant de déployer automatiquement la configuration du tenant Auth0 et les ressources connexes.

​
Tests d’intégration

Il est recommandé, comme pratique exemplaire, de configurer des tenants distincts pour le développement, les tests et la production, comme indiqué dans les conseils d’architecture sur la prise en charge du SDLC. Auth0 vous permet de configurer des variables accessibles dans l’extensibilité personnalisée; elles peuvent être considérées comme des variables d’environnement pour votre tenant Auth0. Au lieu de coder en dur des références qui changent lorsque le code passe d’un environnement de développement, de test ou de production à un autre, vous pouvez utiliser un nom de variable configuré dans le tenant et référencé par le code d’extensibilité personnalisée. Il est ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents tenants, puisque le code peut référencer des variables qui seront renseignées avec des valeurs propres au tenant au moment de l’exécution :
  • Pour utiliser des variables dans les Rules, voyez comment configurer des valeurs
  • Pour utiliser des variables dans les Hooks, voyez comment configurer des secrets dans l’éditeur
  • Pour utiliser des variables dans les Actions, consultez Explore Flows and Triggers
  • Pour utiliser des variables dans les scripts de base de données personnalisés, consultez les paramètres de configuration

​
Pratique exemplaire

Il est recommandé, comme pratique exemplaire, d’utiliser des variables pour stocker les valeurs propres au tenant ainsi que les secrets sensibles qui ne devraient pas être exposés dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub, l’utilisation d’une variable propre au tenant permet d’éviter l’exposition de valeurs sensibles dans votre dépôt GitHub.

​
Automatisation des tests

Vous pouvez automatiser l’ensemble de votre processus de compilation en y intégrant l’automatisation du déploiement ainsi que l’automatisation des tests. Cela permet de déployer de nouvelles versions de la configuration et/ou du code personnalisé dans Auth0 et d’exécuter des tests automatisés. Si les tests détectent des échecs, les capacités d’automatisation du déploiement peuvent servir à rétablir la dernière version fonctionnelle. Pour en savoir plus, consultez le guide sur l’automatisation du déploiement.

​
Tests avec simulation

Pour trouver un équilibre entre la politique de tests de charge d’Auth0 et le besoin d’effectuer des tests de charge, les clients d’Auth0 remplacent couramment les points de terminaison d’Auth0 par des simulations. C’est une pratique utile pour vérifier que votre application fonctionne avec les interfaces attendues sans devoir limiter vos tests, et des outils comme MockServer, JSON Server ou même Postman peuvent vous aider.

​
Tests d’intrusion (facultatif)

Si vous prévoyez effectuer des tests d’intrusion, vous devriez consulter la politique de tests d’intrusion d’Auth0 et vous y conformer. Les tests d’intrusion exigent qu’Auth0 en soit avisé à l’avance afin que vos activités ne soient pas prises pour une activité malveillante et bloquées.

​
Tests de charge (facultatif)

Si vous prévoyez effectuer des tests de charge, vous devez connaître la politique de tests de charge d’Auth0 et vous y conformer. Les tests de charge exigent de prévenir Auth0 à l’avance. En planifiant vos tests de charge, vous devrez aussi tenir compte des limites de débit de l’API d’Auth0. Les tests de charge exigent l’approbation préalable d’Auth0, comme l’explique la politique de tests de charge d’Auth0. Assurez-vous de prendre en compte le délai requis pour l’examen d’une requête et de prévoir suffisamment de temps à la fois pour cet examen et pour l’exécution des tests. Si votre requête de test de charge a été approuvée, les conseils suivants peuvent vous aider à éviter les erreurs et les résultats de test inexacts.
  • Exécutez une trace HTTP lors d’un test de votre application afin d’identifier tous les appels que votre application ou le test prévu doit effectuer, et assurez-vous que votre test les inclut pour qu’il soit représentatif de ce qui se passera en production.
  • Concevez votre test en tenant compte des limites de débit de l’API Auth0.
  • L’utilisation de code personnalisé dans Auth0 (Actions, Rules, Hooks, scripts de base de données personnalisés, connexions personnalisées) appelle le sandbox de code personnalisé d’Auth0, ce qui peut avoir un coût plus élevé sur le plan des performances. Désactivez les Rules, sauf si elles sont essentielles au test. Si elles sont désactivées, votre débit sera plus élevé que si elles sont activées.
  • Estimez la charge globale prévue pour votre environnement de production ainsi que le pourcentage d’appels vers chaque point de terminaison, puis structurez votre test de performance en conséquence afin d’obtenir un résultat réaliste. Les différents points de terminaison n’ont pas tous le même coût en performance. Si votre test n’est pas représentatif, les résultats seront trompeurs.
  • N’effectuez pas d’appels qui dépendent des résultats d’appels antérieurs sans vérifier que les appels ou les réponses préalables sont terminés. Le simple ajout d’un délai peut ne pas suffire.
  • Assurez-vous de mettre en place une gestion des erreurs adéquate. Une cause fréquente de problèmes pendant les tests est la présence d’erreurs dans le code personnalisé (Actions, Rules, Hooks, scripts de base de données personnalisés, scripts de connexion OAuth personnalisés) causées par des exceptions non gérées dans ce code.
  • Les tests de charge doivent être conçus pour commencer à un faible niveau, puis augmenter graduellement la charge, en recueillant des données à chaque niveau, afin d’obtenir les résultats les plus utiles. Commencer à un niveau élevé et échouer immédiatement donne moins d’information sur ce que le système peut supporter.
  • Il est normal de devoir exécuter un test de performance plusieurs fois, en ajustant au besoin le code testé ou l’environnement/la configuration de test. Assurez-vous de commencer vos tests tôt afin de prévoir suffisamment de temps pour plus d’une itération.
  • Utilisez votre propre compte de fournisseur de courriel et assurez-vous de prévoir à l’avance un quota d’envoi suffisant, sans quoi le fournisseur pourrait limiter votre débit. Désactivez l’envoi de courriels si vous ne l’utilisez pas.
  • Assurez-vous d’utiliser les identifiants de votre propre compte pour toutes les connexions sociales plutôt que les clés de développement Auth0. Dans le , allez à Connections -> Social -> {nom de la connexion}—pour voir les instructions sur la façon d’ajouter à la connexion les identifiants du compte de votre propre fournisseur d’identité sociale. Remarque : certains fournisseurs d’identité sociale n’autorisent pas les tests de charge. Vérifiez la politique de votre ou de vos fournisseurs.
  • Afin d’éviter la limitation du débit et de simuler plus fidèlement une charge réelle, vos tests devront envoyer des requêtes pour différents utilisateurs, et non toutes les requêtes pour le même utilisateur. Si vous n’utilisez qu’un seul utilisateur ou un petit nombre d’utilisateurs, la mise en cache peut réduire la charge effective et ne pas fournir de résultats réalistes.
  • Assurez-vous de respecter les paramètres convenus pour le test ainsi que la politique de tests de charge d’Auth0. Auth0 se réserve le droit d’interrompre tout test de performance ou de charge qui ne respecte pas les limites des paramètres convenus ou qui dépasse la fenêtre de test prévue.

​
Guide de planification de projet

Nous offrons un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification de projet B2B IAM