View a markdown version of this page

Test des fonctions Web Lambda - AWS Lambda
Couches de test recommandéesExécutez le serveur HTTP localementTestez le package de déploiementTestez dans un environnement cloud isoléAutorisation des tests et expositionTestez la simultanéité, la mise à l'échelle et la régulationTester les déploiements et les annulations

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Test des fonctions Web Lambda

Les fonctions Web exécutent des serveurs HTTP standard, ce qui vous permet de tester le comportement de la plupart des applications localement à l'aide des outils habituels de votre infrastructure. Des tests dans le cloud sont toujours nécessaires pour valider l'autorisation IAM, l'accès à Amazon S3 et AWS Key Management Service (AWS KMS), les états du cycle de vie des fonctions Web, le dimensionnement, la télémétrie et le comportement multirégional.

Couches de test recommandées

Le tableau suivant décrit chaque couche de test, ce qu'elle valide et où elle s'exécute.

Couche de test Ce qu'il valide Où il fonctionne
Unit Logique métier, validation, décisions d'autorisation, sérialisation et gestion des erreurs. Développement local et environnements de construction.
intégration HTTP Routes, intergiciels, en-têtes, streaming, délais d'attente, déconnexions gracieuses et comportement du framework. Contre un serveur de production exécuté localement.
Package Fichier d'entrée, dépendances de production, mise en page de l'archive, démarrage et utilisation par le serveur deAWS_LAMBDA_HTTP_ENDPOINT. À partir de l'archive exacte que le pipeline de déploiement télécharge.
Intégration dans le cloud IAM, politiques relatives aux compartiments, clés, états du cycle de vie, comportement des terminaux, télémétrie et appels de service en aval AWS . Dans un environnement isolé Compte AWS ou de test.
Charge et résilience Sécurité de la simultanéité, latence, régulation, limites en aval, annulation et comportement régional en cas de défaillance. Dans un environnement cloud de type production avec des contrôles explicites des coûts et du trafic.

Exécutez le serveur HTTP localement

Utilisez une solution de remplacement locale pourAWS_LAMBDA_HTTP_ENDPOINT, comme indiqué dans leMinimale Express vigie. Vous pouvez également définir la variable de manière explicite pour tester le même chemin de démarrage utilisé par Lambda :

AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js

Envoyez des demandes avec votre client HTTP normal et vérifiez les codes d'état, les corps de réponse, les en-têtes, la validation des demandes, le middleware d'authentification, les délais d'expiration, le streaming et la gestion des déconnexions du client.

Exécutez des demandes simultanées lors des tests d'intégration locaux. Vérifiez l'état global de la demande, les caches mutables partagés, l'initialisation en double, les collisions de noms de fichiers et le blocage des boucles d'événements.

Testez le package de déploiement

  1. Installez les dépendances à partir du fichier de verrouillage validé et créez l'archive à l'aide des mêmes commandes que le pipeline de déploiement.

  2. Extrayez l'archive dans un répertoire propre. Exécutez l'application à partir de ce répertoire sans accéder aux dépendances de développement ni aux fichiers source non suivis.

  3. Vérifiez que le fichier d'entrée configuré existe sur le chemin attendu et démarrez le serveur HTTP.

  4. Enregistrez la somme de contrôle de l'archive et l'ID de version de l'objet Amazon S3 utilisés par la révision. Utilisez ces valeurs pour identifier l'artefact exact testé.

Les fonctions Web s'exécutent sur Arm64. Lorsqu'un package contient des dépendances natives, créez et testez ces dépendances pour Linux Arm64 plutôt que de réutiliser les artefacts d'un ordinateur de développement x86-64. Par exemple, vous pouvez installer des dépendances de production dans un conteneur Arm64 :

docker run --rm --platform linux/arm64 \
    --volume "$PWD":/app \
    --workdir /app \
    node:24 \
    npm ci --omit=dev

Testez dans un environnement cloud isolé

  1. Téléchargez l'archive testée dans un compartiment Amazon S3 versionné et créez une révision qui fait référence à la version de l'objet obtenue.

  2. Interrogez la révision jusqu'à ce qu'elle devienne Active ouFailed. Echouez le test avec le rapport stateReason au lieu d'attendre indéfiniment.

  3. Créez ou mettez à jour un point de terminaison de test. Sondage à la fois state etupdateStatus. Pour les PerRegion terminaux MultiRegion et les terminaux, vérifiez chaque statut régional.

  4. Envoyez des demandes au point de terminaison et vérifiez la réponse de l'applicationlambda-web-request-id, les journaux, les métriques et les effets secondaires attendus en aval.

  5. Supprimez le point de terminaison, la fonction, les objets de test, les groupes de journaux et les autres ressources de test une fois le test terminé.

Autorisation des tests et exposition

  • En effetIamAuth, vérifiez que les demandes non signées échouent, que les principaux autorisés réussissent, que les principaux refusés échouent et que l'accès entre comptes nécessite à la fois des politiques d'identité et de ressources.

  • PourApplicationManaged, testez les informations d'identification de l'application manquantes, expirées, mal formées ou insuffisantes. Testez l'autorisation séparément de l'authentification.

  • Testez les demandes de pré-vol du navigateur, les origines autorisées et refusées, les demandes accréditées et les en-têtes de sécurité lorsque les navigateurs appellent le point de terminaison.

  • Lorsqu'une porte d'entrée protège le terminal, vérifiez que les demandes d'origine directe sont refusées et que seuls l'identité de porte d'entrée ou le chemin réseau attendus peuvent l'invoquer.

Testez la simultanéité, la mise à l'échelle et la régulation

  • Augmentez progressivement la charge tout en enregistrant la latence, les réponses 4xx et 5xx, les accélérateurs, les environnements actifs et l'utilisation en aval.

  • Testez le configuré rateLimitmaxEnvironments, et maxConcurrencyPerEnvironment indépendamment. Utilisez l'en-tête de lambda-web-error-type réponse (Platform.EndpointRequestThrottlePlatform.AccountRequestThrottle,Platform.EndpointMaxEnvThrottle,Platform.AccountActiveVCPUArm64Throttle, ouPlatform.EndpointConcurrentInitThrottle) pour confirmer quelle limite a produit chaque réponse HTTP 429. Enregistrez séparément les réponses HTTP 503 qui n'ont pas lambda-web-error-type d'en-tête. Ces réponses peuvent indiquer un délestage temporaire ou une erreur interne. Pour plus de détails, consultez Types d'erreur liés aux fonctions Web.

  • Testez les pics de trafic et les démarrages à froid, et pas uniquement le débit en régime permanent.

  • Utilisez des données de test uniques et des clés d'idempuissance. Ne réessayez pas automatiquement les requêtes non idempotentes lors d'un test de charge.

  • Définissez des limites de trafic, de durée et de coût explicites avant de démarrer un test de charge. Coordonner les tests susceptibles d'affecter les quotas de comptes partagés ou les systèmes en aval.

Tester les déploiements et les annulations

Dans un environnement de test, déployez deux révisions et appliquez la même procédure de routage pondéré que celle utilisée en production. Vérifiez que vos journaux ou vos statistiques personnalisées peuvent attribuer des demandes à chaque révision. Déclenchez délibérément les conditions d'annulation, restaurez tout le trafic à la version précédente et confirmez que son objet de code et ses dépendances restent disponibles.

Pour un point de PerRegion terminaison MultiRegion ou un terminal, testez un échec partiel de mise à jour et vérifiez que l'automatisation de votre déploiement détecte l'échec du statut régional. Testez l'action de restauration et répétez la mise à jour du terminal après avoir corrigé la cause.