Tests effectués (commerce de détail)

Avant le lancement, vous devez avoir effectué tous les tests qui s’appliquent à votre environnement.

L’Assurance Qualité est importante pour identifier les problèmes avant qu’ils n’affectent vos clients, et en fonction de la nature de votre projet, il existe plusieurs types différents de tests d’assurance qualité que vous voudrez envisager dans le cadre de votre intégration avec Auth0 :

• Votre application est-elle facile à comprendre et utiliser, même pour les personnes ayant un handicap?

• Votre application doit-elle fonctionner sur différents navigateurs et appareils?

• Votre application doit-elle fonctionner dans des environnements multinationaux et/ou internationaux?

• Comment votre application se comportera-t-elle lorsque soumise à des charges de production inattendues?

• Comment pouvez-vous garantir que votre application est protégée contre les vulnérabilités liées à la sécurité?

La connexion universelle Auth0 et les widgets d’interface utilisateur associés (tels que Lock) ont déjà été conçus et développés en suivant les meilleures pratiques en matière de convivialité et d’accessibilité, et offrent une prise en charge prête à l’emploi testée pour toute une gamme de navigateurs et appareils. Un soutien à l’internationalisation (I18N) est également incluse en standard, avec une extensibilité intégrée conçue pour des situations personnalisées de multilinguisme et de localisation (L10N).

Pour garantir que les exigences fonctionnelles sont respectées et que les événements inattendus sont gérés correctement, des conseils sont fournis pour tester l’intégration entre votre ou vos applications et Auth0, et pour des tests unitaires de modules d’extensibilité individuels (comme les Règles, les Hooks et les scripts de base de données personnalisés). Des conseils sont également fournis concernant la politique de test de pénétration d’Auth0 pour vous aider lors des tests de vulnérabilité de sécurité, ainsi que sur la manière dont les tests simulés peuvent être exploités en conjonction avec notre politique de test de charge pour garantir que vos applications fonctionnent sous une charge inattendue.

L’objectif du test d’unité est de tester les unités individuelles de code. Si vous créez un code sur mesure avec Auth0 sous la forme de règles, de hooks et/ou de scripts DB sur mesure, vous devriez considérer un cadre de test (comme Mocha) pour tester votre code. Les entreprises qui ont eu le plus de succès avec Auth0 ont trouvé utile d’exécuter ces tests d’unités avant de déployer automatiquement la configuration et les garanties du client Auth0.

Il est recommandé comme bonne pratique d’établir plusieurs clients pour le développement, les tests et la production, tel que discuté dans le Guide sur l’architecture pour SDLC support. Auth0 vous permet de configurer des variables qui sont disponibles à partir d’extensibilité; elles peuvent être pensées comme variables d’environnement pour votre client Auth0. Plutôt que des références en code fixe qui changent lorsque le code est déplacé entre les développements, les tests, et les environnements de production, vous pouvez utiliser un nom variable configuré dans le client et référencé par le code d’extensibilité personnalisée. Ceci vous rend la tâche plus facile pour faire foncitionner le même code personnalisé, sans changements, pour différents clients; le code peut référencier les variables, lesquelles seront présentes avec des valeurs spécifiques aux clients pour des temps d’exécution :

• Pour l’utilisation de variables dans les Règles, consultez comment configurer les valeurs

• Pour l’utilisation de variables dans les hooks, consultez comment configurer les secrets dans l’éditeur

• Pour l’utilisation de variables dans les actions, voir Explorer les flux et les déclencheurs

• Pour l’utilisation de variables dans les Scripts de base de données personnalisés, consultez les paramètres de configuration

Vous pouvez automatiser votre processus global d’automatisation en incorporant une automatisation de déploiement de même qu’une automatisation de test. Ceci peut être utilisé pour déployer de nouvelles versions de configuration et/ou du code personnalisé Auth0, et exécuter des tests automatisés. Si les tests dévoilent des défaillances, les capacités d’automatisation de déploiement peuvent être utilisées pour revenir vers la dernière version fonctionnelle. Pour plus d’informations, consultez le guide d’automatisation du déploiement fourni.

Pour trouver un équilibre entre la politique de test de charge d’Auth0 et le désir de réaliser des tests de charge, les clients d’Auth0 simulent souvent les points de terminaison d’Auth0. Cette pratique est précieuse pour garantir que votre application fonctionne avec les interfaces attendues sans avoir à restreindre vos tests, et des outils tels que MockServer, JSON Server ou même Postman peuvent être utilisés à cette fin.

Si vous effectuez des tests de pénétration, vous devez connaître la Politique de tests de pénétration d’Auth0 et la respecter. Les tests de pénétration nécessitent un préavis à Auth0 afin que vos tests ne soient pas confondus avec une activité malveillante et qu’ils s’arrêtent.

Si vous effectuez des tests de charge, vous devez connaître laPolitique de test de charge d’Auth0 et la respecter. Les tests de charge nécessitent un préavis à Auth0. Lors de la planification de vos tests de charge, vous devrez également connaître les limites anti-attaques d’API d’Auth0.

Les tests de charge nécessitent l’approbation préalable d’Auth0, comme expliqué dans la politique de test de charge d’Auth0. Assurez-vous de noter le délai d’examen d’une demande et de prévoir suffisamment de temps pour l’examen ainsi que pour la réalisation des tests. Si votre demande de test de charge a été approuvée, les conseils suivants peuvent vous aider à éviter des erreurs et des résultats de test erronés.

• Exécutez une trace HTTP sur une exécution de test de votre application pour identifier tous les appels que votre application ou que le test prévu doit effectuer, et assurez-vous que votre test les inclut afin qu’il soit représentatif de ce qui se passera en production.

• Concevez votre test pour être conscient des limites anti-attaques API d’Auth0.

• L’utilisation de tout code personnalisé dans Auth0 (actions, règles, hooks, scripts de base de données personnalisés, connexions OAuth personnalisées) invoquera le sandbox de code personnalisé d’Auth0, ce qui peut coûter plus cher en termes de performances. Désactivez les règles qui ne sont pas essentielles au test. Cela accélérera ainsi le débit.

• Estimez la charge globale attendue pour votre environnement de production et 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. Le fait de ne pas concevoir un test représentatif entraînera des résultats trompeurs.

• Ne faites pas d’appels qui dépendent des résultats d’appels antérieurs sans vous assurer que ces appels ou les réponses préalables sont terminés. L’élaboration du code avec l’ajout d’un simple délai peut ne pas être suffisante.

• Assurez-vous de mettre en œuvre une gestion adéquate des erreurs. Une cause fréquente de problèmes pendant les tests est liée aux erreurs dans le code personnalisé (actions, règles, 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 écrits de manière à commencer à un niveau bas et à augmenter la charge progressivement, en capturant les données à chaque niveau, pour obtenir les résultats les plus utiles. Le fait de commencer à un niveau élevé et d’échouer immédiatement donnerait en effet moins d’informations sur ce que le système peut réellement supporter.

• Il est normal de devoir exécuter un test de performance plusieurs fois, potentiellement en ajustant le code testé, le faisceau ou la configuration de test. Assurez-vous de commencer votre test rapidement pour avoir suffisamment de temps pour effectuer plusieurs itérations.

• Utilisez votre propre compte de fournisseur de messagerie et assurez-vous d’organiser à l’avance un quota d’envoi de courriels suffisant pour ne pas être limité par le fournisseur de messagerie. Désactivez l’envoi de courriels si vous n’utilisez pas cette fonctionnalité.

• Assurez-vous d’utiliser vos propres identifiants de compte pour toutes les connexions sociales plutôt que les clés de développement Auth0. Dans l’Auth0 Dashboard, accédez à Connexions -> Réseaux sociaux -> {nom de la connexion}— pour voir comment ajouter vos propres identifiants de compte de fournisseur de réseaux sociaux à la connexion. Remarque : Certains fournisseurs de réseaux sociaux n’autorisent pas les tests de charge. Vérification auprès de votre (vos) fournisseur(s) pour connaître sa (leur) politique

• Afin d’éviter une limite anti-attaques et de simuler plus précisément la 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 seulement quelques-uns, la mise en cache pourrait réduire la charge effective et ne pas fournir de résultats réalistes.

• Veillez à respecter les paramètres convenus pour le test et la Politique de test de charge d’Auth0. Auth0 se réserve le droit de mettre fin à tout test de performance ou de charge qui ne reste pas dans les limites des paramètres convenus ou qui s’étend au-delà de la fenêtre de test programmée.

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées.