- 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é?
Tests unitaires
Tests d’intégration
- 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
Meilleure pratique
Automatisation des tests
Tests de simulation
Tests de pénétration (facultatif)
Tests de charge (facultatif)
- 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 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’, 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.