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 une incidence sur vos clients et, selon la nature de votre projet, plusieurs types de tests d’assurance qualité méritent d’être pris en compte dans le cadre de votre intégration à Auth0 :
  • Votre application est-elle facile à comprendre et à utiliser, même pour les personnes en situation de handicap ?
  • Votre application doit-elle fonctionner dans différents navigateurs et sur différents 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 pouvez-vous vous assurer que votre application est protégée contre les failles de sécurité ?
Le Universal Login d’Auth0 et les widgets d’interface utilisateur associés (comme Lock) ont déjà été conçus et développés conformément aux meilleures pratiques en matière de convivialité et d’accessibilité, et offrent une prise en charge prête à l’emploi pour tout un éventail 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 s’assurer que les exigences fonctionnelles sont respectées et que les situations imprévues sont correctement gérées, des directives sont fournies pour tester l’intégration entre votre ou vos application(s) et Auth0, ainsi que pour effectuer les tests unitaires de modules d’extensibilité individuels (tels que les Rules, les Hooks et les scripts de base de données personnalisée). Des directives sont également fournies concernant la politique relative aux tests d’intrusion d’Auth0 afin de vous aider lors des tests visant à détecter des failles de sécurité, ainsi que sur la façon dont les tests Mock peuvent être mis à profit conjointement avec notre politique de tests de charge afin de contribuer à garantir que votre ou vos application(s) fonctionnent bien sous une charge imprévue.

​
Tests unitaires

L’objectif des tests unitaires est de vérifier des unités de code individuelles. Si vous créez du code personnalisé dans Auth0 sous forme de Rules, de Hooks et/ou de Custom DB scripts, vous devriez envisager d’utiliser un framework de test (comme Mocha) pour tester votre code. Les entreprises qui ont obtenu le plus de succès avec Auth0 ont jugé utile d’exécuter ces tests unitaires avant de déployer automatiquement la configuration du tenant Auth0 et les ressources associées.

​
Tests d’intégration

Comme bonne pratique, il est recommandé de configurer des tenants distincts pour le développement, les tests et la production, comme indiqué dans les directives d’Architecture sur la prise en charge du cycle de vie du développement logiciel. Auth0 vous permet de configurer des variables accessibles depuis votre extensibilité personnalisée; elles peuvent être considérées comme des variables d’environnement pour votre tenant Auth0. Au lieu d’inscrire 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 l’utilisation de variables dans les Rules, consultez comment configurer des valeurs
  • Pour l’utilisation de variables dans les Hooks, voyez comment configurer des secrets dans l’éditeur
  • Pour l’utilisation de variables dans les Actions, consultez Explore Flows and Triggers
  • Pour l’utilisation de variables dans les Custom DB Scripts, consultez les paramètres de configuration

​
Bonne pratique

Comme bonne pratique, il est recommandé d’utiliser des variables pour contenir les valeurs propres au tenant ainsi que tout secret qui ne devrait pas être exposé dans votre code personnalisé. Si votre code personnalisé est déployé sur 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 génération en intégrant l’automatisation du déploiement ainsi que l’automatisation des tests. Cela permet de déployer vers Auth0 de nouvelles versions de la configuration et/ou du code personnalisé, puis d’exécuter des tests automatisés. Si les tests révèlent des échecs, les capacités d’automatisation du déploiement peuvent servir à revenir à la dernière version fonctionnelle. Pour en savoir plus, consultez le guide sur l’automatisation du déploiement.

​
Tests simulés

Pour concilier la politique de tests de charge d’Auth0 avec le besoin d’effectuer des tests de charge, il est courant chez les clients d’Auth0 de simuler les endpoints d’Auth0. C’est une pratique utile pour s’assurer que votre application fonctionne avec les interfaces prévues sans avoir à limiter vos tests, et des outils comme MockServer, JSON Server ou même Postman peuvent vous y aider.

​
Tests d’intrusion (facultatif)

Si vous prévoyez effectuer des tests d’intrusion, vous devriez prendre connaissance de la politique relative aux tests d’intrusion d’Auth0 et vous y conformer. Les tests d’intrusion exigent qu’Auth0 en soit avisé à l’avance afin que vos tests ne soient pas pris pour des activités malveillantes et interrompus.

​
Tests de charge (facultatif)

Si vous prévoyez effectuer des tests de charge, vous devez prendre connaissance de la politique de tests de charge d’Auth0 et la respecter. Les tests de charge exigent un préavis auprès d’Auth0. Lorsque vous planifiez vos tests de charge, vous devez aussi tenir compte des limites de débit de l’API d’Auth0. Les tests de charge nécessitent l’approbation préalable d’Auth0, comme l’explique la politique de tests de charge d’Auth0. Assurez-vous de bien noter le délai de traitement d’une requête et de prévoir suffisamment de temps pour l’examen ainsi que 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’une exécution de 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 produira en production.
  • Concevez votre test en tenant compte des limites de débit de l’API Auth0.
  • L’utilisation de tout code personnalisé dans Auth0 (Actions, Rules, Hooks, scripts de base de données personnalisée, connexions personnalisées) déclenchera le sandbox de code personnalisé d’Auth0, ce qui peut avoir un coût supplémentaire sur le plan des performances. Désactivez les Rules, à moins qu’elles ne soient 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 endpoint, puis structurez votre test de performance en conséquence afin d’obtenir un résultat réaliste. Les différents endpoints ont des coûts de performance différents. Si vous ne concevez pas un test représentatif, vous obtiendrez des résultats trompeurs.
  • N’effectuez pas d’appels qui dépendent des résultats d’appels précédents sans vérifier que les appels ou réponses préalables sont terminés. Le simple fait d’ajouter un délai pourrait 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ée, scripts de connexion OAuth personnalisés) causées par des exceptions non gérées dans le code personnalisé.
  • Les tests de charge doivent être conçus pour commencer à un faible niveau et 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 fournit moins d’information sur ce que le système peut soutenir.
  • Il est normal de devoir exécuter un test de performance plusieurs fois, en ajustant au besoin le code testé ou le harnais de test/la configuration. 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 de courriels suffisant, sinon votre fournisseur pourrait vous imposer une limitation de 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 , accédez à Connections -> Social -> {name of connection}—pour voir les instructions expliquant comment ajouter à la connexion les identifiants de votre propre compte de fournisseur d’identité sociale. Remarque : certains fournisseurs d’identité sociale n’autorisent pas les tests de charge. Vérifiez la politique de votre ou vos fournisseurs
  • Afin d’éviter la limitation de 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 pas toutes les requêtes pour le même utilisateur. Si vous n’utilisez qu’un seul utilisateur ou qu’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 se prolonge au-delà de la période de test prévue.

​
Guide de planification de projet

Nous mettons à votre disposition un guide de planification au 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 B2C IAM