Passer au contenu principal
Avant le lancement, vous devriez avoir terminé 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. Selon la nature de votre projet, vous devrez envisager plusieurs types de tests d’assurance qualité 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 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 meilleures pratiques en matière de convivialité et d’accessibilité, et offrent une prise en charge prête à l’emploi éprouvée pour un large éventail de navigateurs et d’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 besoins personnalisés de multilinguisme et de localisation (L10N). Pour s’assurer que les exigences fonctionnelles sont respectées et que les événements imprévus sont correctement gérés, des directives sont fournies pour tester l’intégration entre votre ou vos applications et Auth0, ainsi que pour les tests unitaires des modules d’extensibilité individuels (comme Rules, 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 pour vous aider à effectuer des tests de vulnérabilité de sécurité, ainsi que sur la façon dont les tests avec simulation peuvent être utilisés conjointement avec notre politique relative aux tests de charge afin de contribuer à garantir que votre ou vos applications 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 scripts de base de données personnalisés, vous devriez envisager d’utiliser un cadre de test (comme Mocha) pour tester votre code. Les entreprises qui ont le mieux réussi avec Auth0 ont constaté qu’il était utile d’exécuter ces tests unitaires avant de déployer automatiquement la configuration du locataire Auth0 et les ressources connexes.

​
Tests d’intégration

Comme bonne pratique, il est recommandé de configurer des locataires distincts pour le développement, les tests et la production, comme indiqué dans les directives d’architecture sur la prise en charge du SDLC. Auth0 vous permet de configurer des variables accessibles depuis l’extensibilité personnalisée; vous pouvez les considérer comme des variables d’environnement pour votre locataire Auth0. Plutôt que d’intégrer en dur des références qui changent lorsque vous déplacez le code entre les environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le locataire et référencé par le code d’extensibilité personnalisé. Il est ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents locataires, puisque le code peut référencer des variables qui seront renseignées avec des valeurs propres au locataire au moment de l’exécution :
  • Pour utiliser des variables dans les Rules, consultez comment configurer des valeurs
  • Pour utiliser des variables dans les Hooks, consultez comment configurer les secrets dans l’éditeur
  • Pour utiliser des variables dans les Actions, consultez Explorer les flux et les déclencheurs
  • Pour utiliser des variables dans les scripts de base de données personnalisés, consultez les paramètres de configuration

​
Bonne pratique

Comme bonne pratique, il est recommandé d’utiliser des variables pour stocker les valeurs propres au locataire 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 locataire 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 build en y intégrant l’automatisation du déploiement ainsi que l’automatisation des tests. Cela peut servir à déployer de nouvelles versions de la configuration et/ou du code personnalisé dans Auth0, puis à exécuter des tests automatisés. Si les tests détectent des échecs, les fonctionnalités d’automatisation du déploiement peuvent être utilisées pour rétablir la dernière version fonctionnelle. Pour en savoir plus, consultez le guide sur l’automatisation du déploiement.

​
Tests avec simulation

Pour concilier la politique relative aux tests de charge d’Auth0 et le souhait d’effectuer des tests de charge, il est courant chez les clients d’Auth0 de simuler les points de terminaison d’Auth0. Il s’agit d’une pratique utile pour vous 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 devez prendre connaissance de la politique relative aux tests d’intrusion d’Auth0 et vous y conformer. Les tests d’intrusion exigent un préavis à Auth0 afin qu’ils ne soient pas pris pour une activité malveillante et interrompus.

​
Tests de charge (facultatif)

Si vous prévoyez effectuer des tests de charge, vous devez prendre connaissance de la politique relative aux tests de charge d’Auth0 et vous y conformer. Les tests de charge exigent un avis préalable à 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 exigent l’approbation préalable d’Auth0, comme l’explique la politique d’Auth0 relative aux tests de charge. Assurez-vous de tenir compte du délai de traitement nécessaire à l’examen d’une demande et de prévoir suffisamment de temps pour cette révision ainsi que pour l’exécution des tests. Si votre demande de test de charge a été approuvée, les directives suivantes 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 de repérer tous les appels que votre application ou le test prévu doit effectuer, et assurez-vous de les inclure dans votre test 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 code personnalisé dans Auth0 (Actions, Rules, Hooks, scripts de base de données personnalisés, connexions personnalisées) invoquera le bac à sable du code personnalisé d’Auth0, ce qui peut avoir un coût accru 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 coûts de performance varient d’un point de terminaison à l’autre. 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 ajout d’un délai peut ne pas suffire.
  • Assurez-vous de mettre en œuvre une gestion adéquate des erreurs. 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.
  • Les tests de charge doivent être conçus pour commencer à un faible niveau et augmenter graduellement la charge, en capturant 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 supporter.
  • Il est normal de devoir exécuter un test de performance plusieurs fois, en ajustant au besoin le code testé ou le harnais/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 auprès du fournisseur de courriel et assurez-vous de prévoir à l’avance un quota d’envoi suffisant, sinon le fournisseur pourrait vous imposer une limite 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 consulter les instructions expliquant comment ajouter à la connexion les identifiants de votre propre compte auprès du fournisseur social. Remarque : certains fournisseurs sociaux 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 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 et la politique d’Auth0 relative aux tests de charge. Auth0 se réserve le droit d’interrompre tout test de performance/de charge qui ne respecte pas les limites des paramètres convenus ou qui dépasse la fenêtre de test planifiée.

​
Guide de planification du projet

Nous mettons à votre disposition des conseils 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 du projet B2C IAM