Passer au contenu principal
Avant le lancement, vous devriez avoir effectué tous les tests pertinents pour 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, il existe plusieurs types de tests d’assurance qualité à envisager dans le cadre de votre intégration avec 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 pouvez-vous vous assurer que votre application est protégée contre les vulnérabilités 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 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 un large é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 scénarios multilingues et de localisation (L10N) personnalisés. Pour vous assurer que les exigences fonctionnelles sont respectées et que les situations imprévues sont correctement gérées, des conseils sont fournis pour tester l’intégration entre vos applications et Auth0, ainsi que pour les tests unitaires des modules d’extensibilité individuels (comme les Rules, les Hooks et les scripts de base de données personnalisée). Des conseils sont également fournis concernant la politique relative aux tests d’intrusion d’Auth0 afin de vous aider lors des tests de vulnérabilités de sécurité, ainsi que sur la façon dont les tests Mock peuvent être utilisés conjointement avec notre politique sur les tests de charge pour aider à garantir que 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 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 obtenu le plus de succès avec Auth0 ont constaté qu’il est 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

Il est recommandé, comme pratique exemplaire, de configurer des locataires distincts pour le développement, les tests et la production, comme indiqué dans les recommandations 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. Au lieu de coder 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 devient 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, 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 Explorer les flux et les déclencheurs
  • Pour utiliser des variables dans les script de base de données personnalisé, consultez les paramètres de configuration

​
Pratique exemplaire

Il est recommandé, comme pratique exemplaire, d’utiliser des variables pour stocker les valeurs propres au locataire ainsi que tout secret sensible qui ne devrait pas être exposé 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 génération en intégrant l’automatisation du déploiement et l’automatisation des tests. Vous pouvez ainsi déployer de nouvelles versions de la configuration et/ou du code personnalisé vers Auth0 et exécuter des tests automatisés. Si les tests détectent des échecs, les capacité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 simulés

Pour trouver un équilibre entre la politique sur les tests de charge d’Auth0 et le besoin d’effectuer des tests de charge, les clients d’Auth0 ont couramment recours à la simulation des points de terminaison d’Auth0. Il s’agit d’une pratique utile pour vérifier que votre application fonctionne avec les interfaces prévues sans devoir restreindre vos tests. 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 qu’Auth0 en soit avisé à l’avance 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 sur les tests de charge d’Auth0 et vous y conformer. Les tests de charge doivent être annoncés à l’avance à 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 expliqué dans la politique d’Auth0 sur les tests de charge. Assurez-vous de tenir compte du délai nécessaire au traitement d’une demande et de prévoir suffisamment de temps pour son examen ainsi que pour l’exécution des tests. Si votre demande 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és, connexions personnalisées) invoquera le bac à sable de code personnalisé d’Auth0, ce qui peut entraîner un coût de performance plus élevé. 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 attendue 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 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 antérieurs sans vérifier que les appels ou réponses préalables requis sont terminés. Le simple ajout d’un délai peut ne pas suffire.
  • Assurez-vous d’implémenter 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 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 donne moins d’information sur ce que le système peut soutenir.
  • Il est normal de devoir exécuter un test de performance plusieurs fois, possiblement en ajustant le code testé ou l’environnement/la configuration de test. Assurez-vous de commencer vos tests tôt afin de prévoir assez de temps pour plus d’une itération.
  • Utilisez votre propre compte de fournisseur de messagerie et assurez-vous de prévoir à l’avance un quota d’envoi de courriels suffisant, sinon votre fournisseur pourrait 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 l’, accédez à Connections -> Social -> {nom de la connexion}—pour voir les instructions sur la façon d’ajouter les identifiants de votre propre compte de fournisseur social à la connexion. Remarque : certains fournisseurs sociaux n’autorisent pas les tests de charge. Vérifiez la politique de votre ou vos fournisseurs
  • Afin d’éviter les limites de débit et de simuler plus fidèlement une charge réelle, vos tests devront envoyer des demandes pour différents utilisateurs, et non toutes les demandes pour le même utilisateur. Si vous n’utilisez qu’un ou quelques 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 d’Auth0 sur les tests de charge. Auth0 se réserve le droit d’interrompre tout test de performance/de charge qui ne respecte pas les paramètres convenus ou qui dépasse la fenêtre de test planifiée.

​
Guide de planification du 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 du projet B2B IAM