View a markdown version of this page

Automatisez la génération d'événements de test Lambda à l'aide d'Amazon Bedrock AgentCore - Recommandations AWS
RésuméConditions préalables et limitationsArchitectureOutilsBonnes pratiquesEpopéesRésolution des problèmesRessources connexes

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.

Automatisez la génération d'événements de test Lambda à l'aide d'Amazon Bedrock AgentCore

Ishita Gupta et Kriti Gupta, Amazon Web Services

Résumé

Ce modèle propose une AI-powered approche permettant de générer automatiquement des scénarios de test complets pour les AWS Lambda fonctions à l'aide des capacités d'IA générative d'Amazon Bedrock. Ce modèle implémente une architecture à trois agents (Analyzer, Generator et Validator) déployée sur Amazon Bedrock AgentCore qui analyse le code réel de la fonction Lambda pour extraire input/output des modèles et génère des scénarios de test positifs, négatifs et marginaux avec des données réalistes.

L'architecture met en place un flux de travail intelligent dans lequel l'agent d'analyse extrait et analyse le code Lambda à l'aide d'Amazon Bedrock, l'agent générateur crée des cas de test sur la base de modèles appris et l'agent de validation garantit la qualité grâce à la déduplication et au classement. Une DynamoDB-based mémoire Amazon permet un apprentissage continu à partir des commentaires des utilisateurs, améliorant ainsi la précision de la génération des tests au fil du temps. Amazon Cognito fournit une authentification sécurisée des utilisateurs grâce à une autorisation d'API basée sur JSON Web Token (JWT). Amazon Bedrock Guardrails permet de filtrer rapidement les attaques, de supprimer les informations sensibles et de renforcer la sécurité du contenu pour tous les appels d'API Amazon Bedrock. Capacités clés :

  • Multi-Language Support  : fonctions Python, Java, C# et Ruby Lambda JavaScript/TypeScript

  • Découpage intelligent du code  : divise automatiquement les grandes bases de code en segments gérables à des fins d'analyse

  • Traitement parallèle  : appels simultanés à l'API Amazon Bedrock pour une génération de tests plus rapide (5 travailleurs simultanés pour l'analyse du code, génération de tests parallèles par bloc)

  • Target-Specific Analyse  : concentrez-vous sur des fonctions, des classes ou des fichiers spécifiques dans le code Lambda

  • Pattern Learning  : stockage de DynamoDB-based mémoire Amazon avec stockage de modèles global et spécifique à une cible

  • Prévention des rejets  : apprend des cas de test rejetés pour éviter les erreurs courantes

  • Mécanisme de continuation  : gère les réponses Amazon Bedrock incomplètes avec une continuation automatique.

  • Ignorer les modèles  : excluez les fichiers de test, les dépendances et les fichiers non liés au code de l'analyse.

  • Déploiement sans serveur  : s'exécute sur Amazon Bedrock avec authentification AgentCore Cognito-based

  • Garde-corps de sécurité : Amazon Bedrock Guardrails pour un filtrage rapide des attaques, la rédaction des informations personnelles identifiables (PII), la sécurité du contenu et le blocage des sujets refusés sur tous les appels IA

    Ce modèle est idéal pour les équipes de développement et les organisations qui souhaitent accélérer les tests Lambda, améliorer la couverture des tests et maintenir une qualité de code élevée grâce à la génération de AI-assisted tests. Ce modèle utilise les services gérés AWS pour simplifier la création de tests, améliorer la qualité grâce à l'apprentissage et évoluer pour répondre à l'évolution des besoins de test.

Conditions préalables et limitations

Prérequis

Pour implémenter ce modèle avec succès, assurez-vous que les éléments suivants sont en place :

  • Un compte AWS actif  : compte AWS autorisé à accéder aux fonctions Lambda, à invoquer des modèles Amazon Bedrock, à créer des tables DynamoDB, à gérer des groupes d'utilisateurs Cognito et à déployer des agents Amazon Bedrock. AgentCore

  • Accès au modèle Amazon Bedrock : Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) est activé dans votre région AWS. Pour les instructions de configuration, consultez la section Accès aux modèles dans la documentation https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html Amazon Bedrock.

  • Un environnement de développement composé des éléments suivants :

    - Python 3.11 ou supérieur

    - L'interface de ligne de commande AWS est installée et configurée

    - Git pour cloner le dépôt

  • Fonctions AWS Lambda  : au moins une fonction Lambda déployée avec un code source accessible à des fins d'analyse. La fonction doit inclure des fichiers source (.py, .js, .java, .cs, .rb) dans le package de déploiement, et pas seulement du bytecode compilé.

  • Runtimes Lambda pris en charge :

    - Python 3.x (toutes les versions)

    - Node.js (JavaScript/TypeScript)

    - Java 8, 11, 17, 21 (nécessite les fichiers source .java dans le package de déploiement)

    - .NET Core/.NET 6+ (C#) (nécessite les fichiers source .cs dans le package de déploiement)

    - Ruby 2.7 et 3.2

Restrictions

  • Cela nécessite l'accès au modèle Amazon Bedrock dans la région us-east-1 pour Claude Sonnet 4.6. Les fonctions AWS Lambda peuvent se trouver dans n'importe quelle région.

  • Les données de modèles dans Amazon DynamoDB expirent au bout de 90 jours (configurables via Time to Live (TTL)) afin de préserver leur pertinence et de contrôler les coûts.

  • Les fonctions Java et C# Lambda doivent inclure des fichiers source (.java, .cs) dans les packages de déploiement. Compiled-only les packages (.class, .dll) ne peuvent pas être analysés.

  • Le système met en œuvre une limitation du débit en mémoire par utilisateur (5 demandes par 60 secondes). Pour les déploiements distribués comportant plusieurs AgentCore instances, la limite de débit devrait être déplacée vers DynamoDB ou Redis pour des raisons de cohérence.

  • Certains services AWS ne sont pas disponibles dans toutes les régions AWS. Pour connaître la disponibilité des régions, consultez la section Services AWS par région. Pour des points de terminaison spécifiques, consultez la page Points de terminaison et quotas du service, puis choisissez le lien correspondant au service.

Versions du produit

Architecture

Architecture cible

Le schéma suivant montre l'architecture et le flux de travail de ce modèle :

Dans ce flux de travail :

  1. L'utilisateur fournit des informations : le développeur interagit avec l'interface utilisateur Streamlit (app.py) exécutée localement, fournit le nom de la fonction Lambda, des instructions personnalisées facultatives pour la génération de tests, un filtre cible pour se concentrer sur des functions/classes fichiers /files spécifiques et ignore les modèles pour exclure les fichiers de test ou les dépendances.

  2. Authentification Cognito : l'application authentifie la demande avec Cognito et renvoie JWT (ID/Access jeton) à Streamlit.

  3. AgentCore Invocation de l'API : Streamlit invoque AgentCore l'API avec Bearer Token et charge utile (nom de la fonction, filtres, instructions, modèles d'ignorance).

  4. Validation JWT : AgentCore l'API valide JWT à l'aide de la signature du jeton Cognito.

  5. Routage des demandes : AgentCore l'API achemine la demande vers le flux de travail Lambda Test Generator (AgentCore Runtime).

  6. Demande d'analyse de code : Analyzer Agent lance une requête pour récupérer le code et les métadonnées de la fonction Lambda cible.

  7. Authentification AWS pour l'accès Lambda : Boto3 s'authentifie auprès d'AWS à l'aide du rôle d' AgentCore exécution, en demandant des autorisations d'accès en lecture.

  8. Récupération et traitement du code AWS Lambda : le rôle IAM autorise l'accès et récupère le code de la fonction Lambda sous forme de fichier ZIP, extrait les fichiers sources, filtre les dépendances (node_modules, venv, etc.) et les fichiers non liés au code, applique des modèles d'ignorance définis par l'utilisateur et divise le code en parties gérables.

  9. Authentification Amazon Bedrock : le client Amazon Bedrock Boto3 s'authentifie auprès d'AWS IAM pour accéder à Amazon Bedrock, en demandant les autorisations d'invocation du modèle pour utiliser Anthropic Claude Sonnet 4.6.

  10. AI-Powered Analyse de code : le rôle IAM autorise et envoie des segments de code à Amazon Bedrock (us-east-1) à l'aide d'Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) avec Amazon Bedrock Guardrail appliqué pour un filtrage rapide des attaques et la sécurité du contenu. Amazon Bedrock effectue une analyse améliorée Regex + LLM pour extraire les modèles d'entrée réels (par exemple, événement [« corps »], en-têtes [« Autorisation »]), les modèles de sortie (par exemple, StatusCode, structure du corps de la réponse), les dépendances, les modèles de gestion des erreurs et les cas limites du code.

  11. Les résultats d'analyse sont regroupés : Analyzer Agent regroupe les résultats d'analyse dans un AnalysisResult objet contenant des morceaux de code, des modèles d'entrée, des modèles de sortie, des dépendances, des modèles d'erreur et des métadonnées, puis les transmet à l'agent générateur.

  12. Le processus de génération des tests démarre : Generator Agent reçoit les résultats de l'analyse et lance une demande pour générer des cas de test, en interrogeant d'abord la mémoire DynamoDB pour les modèles historiques dont il faut tirer des enseignements.

  13. Authentification Amazon DynamoDB pour l'accès à la mémoire : le client DynamoDB Boto3 s'authentifie auprès d'AWS IAM pour obtenir des autorisations d'accès en lecture afin de récupérer des modèles stockés.

  14. Les modèles historiques sont extraits de la base de données : le rôle IAM autorise et interroge la table de stockage de mémoire DynamoDB (lambda-testcase-memory) pour récupérer les modèles précédemment acceptés et les modèles rejetés (tests échoués avec raisons de rejet) pour la fonction Lambda spécifique.

  15. Authentification Amazon Bedrock pour la génération de tests : le client Amazon Bedrock Boto3 s'authentifie à nouveau avec AWS IAM pour accéder à Amazon Bedrock afin de générer des scénarios de test.

  16. Génération de cas de test IA : le rôle IAM autorise et envoie les résultats d'analyse combinés à des modèles de mémoire à Amazon Bedrock. Amazon Bedrock génère des schémas de scénarios de test avec des événements d'entrée réalistes basés sur des modèles de code réels, créant des tests positifs (35 %), des tests négatifs (35 %) et des cas limites (30 %). La génération se fait en parallèle par bloc pour des raisons d'efficacité, applique les modèles appris à partir de la mémoire, évite les modèles rejetés et génère des segments si nécessaire pour les bases de code volumineuses. Tous les appels Bedrock converse () incluent GuardrailConfig pour le filtrage rapide des attaques, la rédaction des informations personnelles et l'application des sujets refusés.

  17. La validation des tests commence : l'agent générateur transmet les scénarios de test candidats générés à l'agent de validation pour le contrôle qualité, la déduplication et la sélection finale.

  18. Le processus de validation est configuré : l'agent de validation reçoit les candidats au test et lance le processus de validation en demandant l'accès à la mémoire DynamoDB à des fins de notation et de validation.

  19. Authentification DynamoDB à des fins de validation : le client DynamoDB Boto3 s'authentifie auprès d'AWS IAM pour accéder en lecture aux modèles de mémoire des requêtes à des fins de notation de validation.

  20. La qualité des tests est évaluée : le rôle IAM autorise et utilise la mémoire DynamoDB pour évaluer les cas de test en fonction des taux de réussite des modèles précédents, de la couverture des fonctions et de la complexité du code. Le validateur effectue une validation structurelle, une déduplication à l'aide du hachage de modèles, un score de qualité avec amélioration de la confiance pour les fonctions de gestion et la gestion des erreurs, une sélection de diversité pour couvrir différents segments et types de tests, et sélectionne les N cas de test les plus divers et de la plus haute qualité.

  21. Scénarios de test finaux renvoyés à AgentCore : Validator Agent renvoie les scénarios de test validés finaux avec leurs métadonnées (scores de confiance, descriptions, événements d'entrée, catégories) à l'orchestrateur principal, qui les met en forme et les renvoie à l'API Amazon Bedrock AgentCore

  22. Résultats transmis à l'interface utilisateur : l' AgentCore API renvoie les tests générés à l'interface utilisateur Streamlit pour les afficher avec le résumé de l'analyse, les métadonnées de génération et les détails des scénarios de test.

  23. Les utilisateurs évaluent et fournissent des commentaires : le développeur examine les cas de test affichés dans Streamlit UI, évalue la qualité et la pertinence de chaque test, accepte les bons cas ou rejette les mauvais pour des raisons de rejet spécifiques (missing_auth_headers, wrong_status_code, unrealistic_data, missing_required_fields, incorrect_event_source, etc.) et ajoute des notes personnalisées facultatives expliquant le rejet, puis soumet des commentaires.

  24. Les commentaires sont soumis au système : Streamlit UI envoie les commentaires collectés (accepted/rejected statut, raisons du rejet, notes personnalisées) à l' AgentCore API (save_feedback).

  25. AgentCore achemine les commentaires : AgentCore l'API appelle l'agent Validator qui contient une logique permettant de stocker les commentaires dans DynamoDB.

  26. Le processus de stockage des commentaires commence : l'agent de validation lance le processus de stockage des commentaires.

  27. L'accès en écriture à DynamoDB est authentifié : le client DynamoDB Boto3 s'authentifie auprès d'AWS IAM (rôle d'AgentCore exécution) pour obtenir les autorisations d'accès en écriture afin de stocker les modèles de commentaires.

  28. Les modèles d'apprentissage sont enregistrés : le rôle IAM autorise et enregistre les commentaires des utilisateurs dans la table de stockage en mémoire DynamoDB. Chaque modèle est stocké avec une clé de partition composite (function_name #target_function ou function_name #GLOBAL), une clé de tri composite (FEEDBACK# accepted/rejected #PATTERN #hash), un hachage de modèle pour la déduplication, un type de test, une structure de modèle de saisie, un statut de feedback, une raison du rejet (en cas de rejet), des notes personnalisées, un nombre d'utilisations, un taux de réussite, un horodatage et un TTL de 90 jours pour le nettoyage automatique. Ces données stockées permettent au système de tirer parti des commentaires des utilisateurs et d'améliorer la génération future de tests.

Automatisation et évolutivité

Ce modèle évolue automatiquement à l'aide des services gérés AWS. Amazon Bedrock gère l'inférence basée sur l'IA à la demande avec une fenêtre contextuelle de 200 000 jetons et une sortie de 64 000 jetons par appel, et Amazon DynamoDB utilise une facturation à la demande qui s'adapte automatiquement aux modèles de trafic. Le système utilise un traitement parallèle pour gagner en rapidité, l'agent Analyzer effectue 5 appels Bedrock simultanés pour analyser des segments de code (ThreadPoolExecutor avec max_workers=5), tandis que l'agent générateur traite des segments en parallèle avec 5 travailleurs simultanés. Un mécanisme de continuation gère les réponses incomplètes en réessayant automatiquement les demandes. La limitation du débit (5 demandes par 60 secondes par utilisateur) empêche les abus de coûts dus à des appels d'API Bedrock excessifs.

L'optimisation des coûts inclut un TTL-based nettoyage qui supprime les modèles datant de plus de 90 jours, des requêtes par clé composite avec begins_with () pour des recherches instantanées sans analyse des tables et des BatchWriteItem opérations qui réduisent les opérations d'écriture dans DynamoDB d'environ 90 %. Les performances dépendent de la taille de la fonction, les petites fonctions (moins de 10 fichiers) génèrent 10 scénarios de test en 30 à 60 secondes, les fonctions moyennes (10 à 50 fichiers) prennent 1 à 3 minutes et les fonctions volumineuses (plus de 50 fichiers) prennent 3 à 5 minutes, mais l'utilisation de filtres cibles pour se concentrer sur des sections de code spécifiques permet de réduire le temps de 50 à 70 %.

Outils

Services AWS

  • Amazon Bedrock — Fournit des fonctionnalités d'IA génératives via Anthropic Claude Sonnet 4 pour l'analyse de code, la génération de tests, la validation et la synthèse des rejets. Utilise toujours la région us-east-1 pour accéder au modèle.

  • Amazon Bedrock AgentCore  : fournit un environnement d'exécution d'agent sans serveur pour le déploiement et l'hébergement du backend de génération de tests avec évolutivité, OAuth-based autorisation et observabilité automatiques. CloudWatch

  • Amazon Bedrock Guardrails — Fournit un filtrage de ML-based sécurité sur tous les appels d'API Bedrock, y compris la détection rapide des attaques (niveau ÉLEVÉ), le filtrage du contenu, l'anonymisation des informations personnelles (e-mail, téléphone, nom), le blocage des keys/private keys/JWT jetons d'accès AWS et le refus d'application des sujets (génération de code d'exploitation, sortie de code source brut). Déployé via CloudFormation.

  • AWS CloudFormation — Automatise le provisionnement complet de l'infrastructure, y compris la table DynamoDB, le groupe d'utilisateurs Cognito, Amazon Bedrock Guardrail avec gestion des versions et le rôle d'exécution IAM pour. AgentCore

  • Amazon Cognito — Fournit l'authentification des utilisateurs grâce à une inscription par e-mail, à l'émission de jetons JWT et à une autorisation API sécurisée pour le backend. AgentCore

  • Amazon DynamoDB — Stocke les modèles de test acceptés et rejetés avec des statistiques d'utilisation pour un apprentissage et une amélioration continus. Utilise des clés composites (function_target, pattern_sk) pour les requêtes sans scan et le stockage de modèles spécifiques à la cible.

  • AWS Lambda — Source du code de fonction pour l'analyse, l' GetFunction API récupère le code et la configuration. L'outil prend en charge les environnements d'exécution Python Node.js, Java, .NET et Ruby.

Autres outils

  • Python 3.11+ — Environnement d'exécution pour l'orchestration des applications et des agents.

  • Streamlit  : interface Web-based utilisateur pour l'authentification, la génération de tests, la collecte de commentaires et la surveillance de l'état du système.

  • Boto3  : kit de développement logiciel AWS pour Python permettant d'interagir avec les services Lambda, Amazon Bedrock, DynamoDB et Cognito.

Référentiel de code

Le code de ce modèle est disponible dans Github - Lambda Test Event Generator.

Bonnes pratiques

Ce modèle met en œuvre les meilleures pratiques suivantes :

  • Utilise les politiques IAM du moindre privilège pour l'accès à AWS Lambda (lecture seule), Amazon Bedrock (appel), Amazon DynamoDB () et Amazon Cognito (query/writeauthentification).

  • Implémentez l'apprentissage de modèles spécifiques à la cible avec une solution de repli globale pour améliorer la précision des tests.

  • Activez DynamoDB TTL pour le nettoyage automatique des anciens modèles (90 jours) afin de contrôler les coûts de stockage.

  • Utilisez des requêtes à balayage zéro avec des clés composites (function_target, pattern_sk) pour une récupération rapide des modèles.

  • Appliquez des modèles d'ignorance pour exclure les fichiers de test, les dépendances et les fichiers non liés au code de l'analyse.

  • Utilisez le découpage de code multilingue avec l'analyse syntaxique abstraite (AST) (Python) et les modèles regex (Java, C#, JS, Ruby).

  • Stockez les modèles avec des valeurs réelles (pas seulement une structure) pour une véritable déduplication.

  • Déployez le backend sur Amazon Bedrock AgentCore pour une évolutivité sans serveur et une infrastructure gérée.

  • Authentifiez les utilisateurs via Amazon Cognito grâce à la validation des jetons JWT à chaque demande d'API.

  • Appliquez Amazon Bedrock Guardrails à tous les appels converse () afin de filtrer rapidement les attaques, de supprimer les informations personnelles, de bloquer les données sensibles (clés AWS, clés privées, JWT) et de refuser l'application des sujets.

  • Nettoyez les résultats d'analyse avant de les renvoyer aux utilisateurs : tous les segments de code source brut sont supprimés des réponses, garantissant ainsi que le code source Lambda ne quitte jamais les AgentCore limites d'exécution.

  • Validez toutes les entrées de l'API avec des modèles regex et des limites de longueur (nom de fonction maximum 170 caractères, instructions personnalisées maximum 2 000 caractères, maximum 50 modèles ignorés) pour éviter les injections et les abus.

  • Implémentez une limite de débit par utilisateur (5 demandes par 60 secondes) pour éviter les abus de coûts dus à des appels d'API Bedrock excessifs.

  • Nettoyez les messages d'erreur avant de les renvoyer aux utilisateurs : les chemins de fichiers internes, les détails du SDK AWS et les informations d'infrastructure ne sont jamais exposés dans les réponses d'erreur.

Tenez compte des meilleures pratiques supplémentaires suivantes :

  • Fournissez des raisons de feedback spécifiques lorsque vous rejetez des cas de test afin d'améliorer la précision de l'apprentissage.

  • Générez des tests de manière itérative (2 à 3 fois) pour la même fonction afin de permettre au système d'apprendre et de s'améliorer.

  • Fournissez des instructions personnalisées lorsque vous avez besoin de scénarios de test ou de formats de données spécifiques.

  • Activez IAM Access Analyzer pour surveiller les autorisations des ressources et identifier les accès involontaires.

  • Commencez par de petites fonctions Lambda pour comprendre le système avant d'analyser de grandes bases de code.

  • Passez régulièrement en revue les politiques IAM et supprimez les autorisations non utilisées.

  • Utilisez des politiques de mots de passe strictes et activez Cognito AdvancedSecurityMode pour la détection des menaces.

Epopées

Sous-tâcheDescriptionCompétences requises

Pour cloner le référentiel.

Clonez le GitHub référentiel sur votre système local et accédez au répertoire du projet :

git clone https://github.com/aws-samples/sample-lambda-test-event-generator.git

cd sample-lambda-test-event-generator

Ce référentiel contient l'application Python, le CloudFormation modèle et les fichiers de configuration.

Développeur d’applications

Configurez les informations d'identification AWS.

Configurez vos informations d'identification AWS pour permettre à l'AWS CLI d'interagir avec votre compte AWS et pour permettre à l'application d'accéder aux fonctions Lambda que vous souhaitez tester.

Vous pouvez le faire à l'aide de la commande de configuration de l'interface de ligne de commande AWS :

aws configure

Lorsque vous y êtes invité, fournissez les informations suivantes :

  • ID de clé d'accès AWS  : votre clé d'accès AWS

  • Clé d'accès secrète AWS  : votre clé d'accès secrète AWS

  • Nom de la région par défaut  : la région AWS dans laquelle vous souhaitez déployer les ressources (par exemple,us-east-1)

  • Format de sortie par défaut  : format de sortie préféré (par exemple,json)

Développeur d’applications
Sous-tâcheDescriptionCompétences requises

Déployez l'infrastructure en utilisant CloudFormation.

  1. Déployez l'infrastructure backend complète (rôles DynamoDB, Cognito, IAM) à l'aide du modèle fourni. CloudFormation Exécutez la commande suivante dans votre CLI :

    aws cloudformation create-stack \
      --stack-name lambda-test-generator-infra \
      --template-body file://cloudformation/complete-infrastructure.yaml \
      --capabilities CAPABILITY_NAMED_IAM \
      --region us-east-1

  2. Attendez la fin du déploiement de la pile :

    aws cloudformation wait stack-create-complete \
      --stack-name lambda-test-generator-infra \
      --region us-east-1

  3. Récupérez toutes les sorties :

    aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs' \
      --output table

Ce qui est créé :

  • Table DynamoDB avec TTL activé, restauration instantanée et chiffrement côté serveur.

  • Groupe d'utilisateurs Cognito avec authentification par e-mail, AdvancedSecurityMode ENFORCED, MFA (TOTP) en option et création d'utilisateurs réservés aux administrateurs.

  • Amazon Bedrock Guardrail avec filtrage rapide des attaques, rédaction des informations personnelles, filtrage du contenu et blocage des sujets refusés.

  • Rôle d'exécution IAM pour les politiques AgentCore dotées du moindre privilège, y compris bedrock : permission. ApplyGuardrail

Note

La pile crée toutes les ressources nécessaires. Assurez-vous que le CloudFormation modèle est correctement rempli avant de passer à l'étape suivante.

Développeur d’applications

Exportez les variables de configuration.

Exportez toutes les valeurs des sorties de la CloudFormation pile en tant que variables d'environnement :

export AGENTCORE_ROLE_ARN=$(aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs[?OutputKey==`AgentCoreExecutionRoleArn`].OutputValue' \
      --output text)

export DISCOVERY_URL=$(aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs[?OutputKey==`DiscoveryUrl`].OutputValue' \
      --output text)

export CLIENT_ID=$(aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs[?OutputKey==`ClientId`].OutputValue' \
      --output text)

export DYNAMODB_TABLE=$(aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs[?OutputKey==`DynamoDBTableName`].OutputValue' \
      --output text)

export COGNITO_POOL_ID=$(aws cloudformation describe-stacks \
      --stack-name lambda-test-generator-infra \
      --query 'Stacks[0].Outputs[?OutputKey==`UserPoolId`].OutputValue' \
      --output text)

export BEDROCK_GUARDRAIL_ID=$(aws cloudformation describe-stacks \
  --stack-name lambda-test-generator-infra \
  --query 'Stacks[0].Outputs[?OutputKey==`BedrockGuardrailId`].OutputValue' \
  --output text)

export BEDROCK_GUARDRAIL_VERSION=$(aws cloudformation describe-stacks \
  --stack-name lambda-test-generator-infra \
  --query 'Stacks[0].Outputs[?OutputKey==`BedrockGuardrailVersion`].OutputValue' \
  --output text)

Ces variables sont utilisées dans les étapes suivantes pour la AgentCore configuration et la création du fichier .env.

Administrateur AWS
Sous-tâcheDescriptionCompétences requises

Créez un environnement virtuel.

  1. Créez et activez un environnement virtuel Python pour isoler les dépendances du projet :

    python3 -m venv venv

source venv/bin/activate

  2. Installez les packages Python requis à partir du fichier d'exigences :

    pip install -r requirements.txt

    Cela installe toutes les bibliothèques nécessaires, notamment boto3 pour le SDK AWS, python-dotenv pour la configuration de l'environnement, bedrock-agentcore-runtime pour l'intégration et Streamlit pour l'interface utilisateur. AgentCore

    Note

    L'environnement virtuel doit être activé (utilisésource venv/bin/activate) chaque fois que vous ouvrez une nouvelle session de terminal pour exécuter l'application.

Développeur d’applications

Configurez et déployez AgentCore.

  • Configurez l' AgentCore agent :

    agentcore configure \
  --entrypoint main.py \
  --name lambda_test_generator \
  --requirements-file requirements.txt \
  --region us-east-1 \
  --execution-role $AGENTCORE_ROLE_ARN

  • Lorsque vous y êtes invité :

    1. Type de déploiement : 1 (déploiement direct de code, aucun Docker n'est nécessaire)

    2. Version Python : 2 (PYTHON_3_11 ou sélectionnez votre version de Python particulière)

    3. Compartiment S3 : appuyez sur Entrée (création automatique)

    4. Autorisateur OAuth : oui

    5. URL de découverte : collez la valeur $DISCOVERY_URL

    6. Identifiants clients : collez la valeur $CLIENT_ID

    7. Public : appuyez sur Entrée (laissez vide)

    8. Champs d'application : appuyez sur Entrée (laissez vide)

    9. Réclamations personnalisées : appuyez sur Entrée (laissez vide)

    10. En-têtes de demande : oui

    11. En-têtes : Autorisation

    12. Mémoire : s (ignorer - à l'aide de DynamoDB)

  • Déployez l'agent :

    agentcore deploy \
  --env DYNAMODB_TABLE_NAME=$DYNAMODB_TABLE \
  --env AWS_REGION=us-east-1 \
  --env BEDROCK_GUARDRAIL_ID=$BEDROCK_GUARDRAIL_ID \
  --env BEDROCK_GUARDRAIL_VERSION=$BEDROCK_GUARDRAIL_VERSION

  • Obtenez l'ID AgentCore d'exécution et le point de terminaison :

    RUNTIME_ID=$(agentcore status | grep "Agent ARN:" | sed 's/.*runtime\///' | sed 's/[│ ].*//')
AGENTCORE_ENDPOINT="https://bedrock-agentcore-runtime.us-east-1.amazonaws.com/agents/${RUNTIME_ID}/endpoints/DEFAULT"
Développeur d’applications

Créez un fichier .env pour le développement local.

Créez un fichier .env dans le répertoire racine du projet avec toutes les valeurs de configuration :

cat > .env << EOF
AWS_REGION=us-east-1
DYNAMODB_TABLE_NAME=$DYNAMODB_TABLE
COGNITO_POOL_ID=$COGNITO_POOL_ID
COGNITO_CLIENT_ID=$CLIENT_ID
COGNITO_REGION=us-east-1
AGENTCORE_ENDPOINT=$AGENTCORE_ENDPOINT
BEDROCK_GUARDRAIL_ID=$BEDROCK_GUARDRAIL_ID
BEDROCK_GUARDRAIL_VERSION=$BEDROCK_GUARDRAIL_VERSION
EOF

Testez la connectivité aux services AWS :

aws dynamodb describe-table --table-name $DYNAMODB_TABLE
aws bedrock list-foundation-models --region us-east-1

Les deux commandes doivent renvoyer des réponses correctes. Si vous rencontrez des erreurs d'autorisation, vérifiez que les politiques IAM sont correctement configurées.

Développeur d’applications
Sous-tâcheDescriptionCompétences requises

Créez un nouvel utilisateur Cognito.

Le groupe d'utilisateurs Cognito est configuré avec la création d'utilisateurs réservés aux administrateurs pour des raisons de sécurité, de sorte que les utilisateurs ne peuvent pas s'enregistrer eux-mêmes. Créez un utilisateur via l'AWS CLI à l'aide de l'ID du pool Cognito et de l'ID client exportés à partir des sorties de la CloudFormation pile. Créez un nouvel utilisateur (remplacez-le user@example.com par votre adresse e-mail) :

aws cognito-idp admin-create-user \
  --user-pool-id $COGNITO_POOL_ID \
  --username user@example.com \
  --user-attributes Name=email,Value=user@example.com Name=email_verified,Value=true \
  --temporary-password '[PASSWORD]!' \
  --region us-east-1

Définissez un mot de passe permanent (au moins 8 caractères, dont des majuscules, des minuscules et un chiffre) :

aws cognito-idp admin-set-user-password \
  --user-pool-id $COGNITO_POOL_ID \
  --username user@example.com \
  --password '[PASSWORD]!' \
  --permanent \
  --region us-east-1

Utilisez ces informations d'identification pour vous connecter via l'interface utilisateur Streamlit à l'étape suivante.

Développeur d’applications
Sous-tâcheDescriptionCompétences requises

Lancez l'interface utilisateur Streamlit.

Démarrez l'application :

streamlit run app.py

L'interface utilisateur s'ouvrira dans votre navigateur par défaut à http://localhost:8501

Connectez-vous avec les informations d'identification créées à l'étape précédente

Développeur d’applications

Configuration des options de génération

Dans l'interface utilisateur, configurez les options suivantes :

  1. Nom de la fonction Lambda ou ARN  : entrez l'identifiant de la fonction Lambda cible

  2. Filtre cible (facultatif) : spécifiez une fonction, une classe ou un fichier sur lequel vous souhaitez vous concentrer (par exemplevalidate_user,UserService,auth.py)

  3. Ignorer les modèles (facultatif) : ajoutez des modèles de fichiers ou de dossiers à exclure, un par ligne :

    • tests/- Ignorer le répertoire des tests

    • *.test.js- Ignorer les fichiers de test

    • mock_data/- Ignorer les données fictives

  4. Instructions personnalisées (facultatif) : ajoutez des exigences de test spécifiques

Développeur d’applications

Générez des cas de test.

Cliquez sur le bouton « Générer des cas de test ». Le système va :

  1. Authentifiez-vous à AgentCore l'aide du jeton JWT Cognito.

  2. Récupérez le code Lambda depuis AWS.

  3. Appliquez des modèles d'ignorance pour exclure les fichiers indésirables.

  4. Code en morceaux utilisant des stratégies spécifiques à la langue.

  5. Appliquez le filtre cible si cela est spécifié.

  6. Analysez le code avec Amazon Bedrock.

  7. Interrogez DynamoDB pour les modèles appris.

  8. Générez des cas de test.

  9. Validez et classez les cas de test.

Développeur d’applications

Passez en revue les tests générés.

Passez en revue chaque scénario de test généré, qui inclut :

  • Type  : Positif (entrées valides), Négatif (entrées non valides) ou Edge (conditions aux limites)

  • Description  : Ce que le test valide

  • Données de test  : charge utile réelle de l'événement de test

DevOps ingénieur, développeur d'applications

Fournissez des commentaires.

Pour chaque cas de test, donnez votre avis :

Pour accepter un scénario de test :

  • Cliquez sur le bouton « Accepter »

Pour rejeter un scénario de test :

  1. Cliquez sur le bouton « Refuser »

  2. Sélectionnez un motif de rejet dans la liste déroulante ou ajoutez un motif personnalisé

  3. Cliquez sur le bouton « Soumettre le rejet »

Ingénieur d'essais

Enregistrez les commentaires dans la mémoire.

Après avoir examiné tous les cas de test :

  1. Cliquez sur le bouton « Enregistrer tous les commentaires en mémoire »

  2. Le système vérifie que tous les cas rejetés ont été motivés

  3. Les commentaires sont envoyés à AgentCore l'API qui est acheminée vers l'agent de validation.

  4. Les commentaires sont stockés par lots dans DynamoDB avec un hachage de modèle pour la déduplication.

  5. Afficher le résumé des commentaires indiquant le accepted/rejected nombre

Ingénieur d'essais

Répétez pour vous améliorer.

Générez des tests 2 à 3 fois de plus pour la même fonction afin d'améliorer la qualité :

  • Le système récupère les modèles appris à partir de DynamoDB

  • La qualité s'améliore à chaque itération en fonction de vos commentaires

  • Utilisez un filtre cible pour des tests ciblés sur des composants spécifiques

  • Utilisez des modèles d'ignorance pour exclure le code non pertinent et améliorer la qualité de génération

Note

Le système d'apprentissage devient plus efficace avec une utilisation répétée. Chaque cycle de feedback aide l'IA à comprendre vos préférences en matière de test et à générer des scénarios de test plus pertinents pour vos fonctions Lambda.

Développeur d’applications
Sous-tâcheDescriptionCompétences requises

Invoquez directement AgentCore l'API.

À des fins d'automatisation et d'intégration, appelez le AgentCore backend directement à l'aide d'appels d'API avec authentification Cognito.

Obtenez un jeton Cognito :

TOKEN=$(agentcore identity get-cognito-inbound-token)

Invoquez la génération de tests :

agentcore invoke --bearer-token "$TOKEN" '{"action": "generate_test_cases", "function_name": "your-lambda-function", "num_test_cases": 10,"custom_instructions": "Focus on authentication scenarios", "target_filter": "validate_user","ignore_patterns": ["tests/", "*.test.js"] }'

Ou en utilisant curl :

curl -X POST "$AGENTCORE_ENDPOINT" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "action": "generate_test_cases", "function_name": "your-lambda-function", "num_test_cases": 10}'
Développeur d’applications
Sous-tâcheDescriptionCompétences requises

Surveillez les modèles DynamoDB et suivez les coûts.

  1. Interrogez la table DynamoDB pour passer en revue les modèles acceptés et comprendre ce que le système a appris :

    aws dynamodb query \
  --table-name $DYNAMODB_TABLE \
  --key-condition-expression "function_target = :ft AND begins_with(pattern_sk, :prefix)" \
  --expression-attribute-values '{":ft":{"S":"my-function#GLOBAL"},":prefix":{"S":"FEEDBACK#accepted"}}'

    Remplacez-le my-function par le nom réel de votre fonction Lambda pour afficher les modèles spécifiques à cette fonction.

  2. Suivez la consommation des ressources pour optimiser les coûts :

    • AWS Cost Explorer  : surveillez les dépenses globales liées aux services Bedrock, DynamoDB et Lambda

    • Amazon Bedrock  : consultez l'utilisation des jetons et les statistiques relatives aux appels d'API dans la console Bedrock

    • DynamoDB  : vérifiez les statistiques relatives aux demandes, la capacité consommée et l'utilisation du stockage.

    • AgentCore: surveillez les statistiques d'exécution des agents et le nombre d'appels dans CloudWatch

  3. Utilisez CloudWatch les journaux pour diagnostiquer les problèmes et surveiller le comportement du système :

    • AgentCore journaux : 

      aws logs tail /aws/bedrock-agentcore/runtimes/lambda_test_generator --follow

    • Erreurs d'application  : passez en revue les erreurs et les exceptions au niveau de l'application

    • Réponses de l'API Bedrock  : analysez les réponses des modèles d'IA et la consommation de jetons

    • Opérations DynamoDB  : surveillez les read/write modèles et les événements de limitation

Note

Un suivi régulier permet d'identifier les opportunités d'optimisation des coûts et garantit que le système continue d'apprendre efficacement. La configuration TTL de votre table DynamoDB supprime automatiquement les anciens modèles, ce qui permet de gérer les coûts de stockage au fil du temps.

Administrateur AWS
Sous-tâcheDescriptionCompétences requises

Supprimez les ressources déployées.

Pour supprimer toutes les ressources déployées :

Supprimez l' AgentCore agent :

agentcore destroy

Supprimez la CloudFormation pile (supprime la table DynamoDB, le groupe d'utilisateurs Cognito et le rôle IAM) :

aws cloudformation delete-stack 
\ --stack-name lambda-test-generator-infra 
\ --region us-east-1
Administrateur AWS

Résolution des problèmes

ProblèmeSolution

Erreur « Accès refusé » lors de la récupération du code Lambda

  • Vérifiez que les autorisations IAM incluent lambda:GetFunction et lambda:GetFunctionConfiguration pour la fonction Lambda cible

  • Vérifiez vos informations d'identification de la CLI AWS

    aws sts get-caller-identity

« Erreurs d'écriture dans DynamoDB »

  • Vérifiez que le nom de la table dans votre .env fichier correspond au nom de la table déployée

  • Vérifiez les CloudFormation sorties :

    aws cloudformation describe-stacks --stack-name lambda-test-generator-infra --query 'Stacks[0].Outputs[?OutputKey=DynamoDBTableName].OutputValue' --output text

  • Ou vérifiez directement :

    aws dynamodb describe-table --table-name $DYNAMODB_TABLE

Aucun cas de test généré

Causes possibles et solutions :

  • Le code de la fonction Lambda n'est pas accessible  : vérifiez les autorisations IAM pour l'accès Lambda

  • Le package de déploiement Lambda contient uniquement du code compilé  : .class les .dll fichiers sans fichiers source ne peuvent pas être analysés

  • Tous les fichiers filtrés par modèles d'ignorance  : passez en revue et ajustez vos modèles d'ignorance

  • Les instructions personnalisées sont trop restrictives  : simplifiez ou supprimez les instructions personnalisées

  • Vérifiez que la fonction Lambda existe :

    aws lambda get-function --function-name <name>

Java/C# Lambda affiche « Aucun code source trouvé »

Les Lambdas Java et C# nécessitent des fichiers source dans le package de déploiement :

Java (Maven) :

  1. Ajouter une configuration d'inclusion de source à pom.xml (voirdocs/JAVA_SETUP.md)

  2. Reconstruisez et redéployez votre fonction Lambda

C# (.NET) :

  1. Inclure .cs des fichiers dans la configuration de compilation (voirdocs/CSHARP_SETUP.md)

  2. Reconstruisez et redéployez votre fonction Lambda

Erreurs d'écriture dans DynamoDB

  • Vérifiez les autorisations DynamoDB et l'état de la table :

  • Vérifiez que la politique IAM inclut dynamodb:PutItem et dynamodb:BatchWriteItem

  • Vérifiez l'état de la table : 

    aws dynamodb describe-table --table-name $DYNAMODB_TABLE

    Le nom de la table inclut le suffixe du nom de pile. Utilisez la valeur de vos CloudFormation sorties ou du fichier .env.

  • Activez CloudWatch les journaux pour que DynamoDB affiche les messages d'erreur détaillés

Génération de tests lente

Optimisez la vitesse de génération :

  1. Utilisez le filtre cible pour vous concentrer sur des fonctions spécifiques (50 à 70 % plus rapide)

  2. Ajoutez des modèles d'ignorance pour exclure les fichiers de test, les dépendances et le code non pertinent

  3. Réduisez la taille du code en filtrant les fichiers inutiles avant l'analyse

AgentCore: « Agent introuvable »

Vérifiez que l'agent est déployé :

agentcore status

agentcore configure list

AgentCore: « Autorisation refusée » lors de l'exécution

Vérifiez que le rôle d'exécution possède les bonnes politiques :

aws iam list-role-policies --role-name agentcore-exec-lambda-test-generator-infra

Cognito : « Nom d'utilisateur ou mot de passe non valide »

Vérifiez que vos informations d'identification sont correctes. Vous pouvez créer un nouvel utilisateur à l'aide du flux « Créer un compte » de l'interface utilisateur Streamlit ou via l'AWS CLI :

aws cognito-idp admin-create-user --user-pool-id <POOL_ID> --username <username> --temporary-password '<password>' --region us-east-1
aws cognito-idp admin-set-user-password --user-pool-id <POOL_ID> --username <username> --password '<password>' --permanent --region us-east-1

Avertissement « Bedrock Guardrail non configuré » dans les journaux

Vérifiez BEDROCK_GUARDRAIL_ID et les variables d'BEDROCK_GUARDRAIL_VERSIONenvironnement sont définies dans le AgentCore déploiement.

Vérifiez les CloudFormation sorties : 

aws cloudformation describe-stacks --stack-name lambda-test-generator-infra --query 'Stacks[0].Outputs[?OutputKey==`BedrockGuardrailId`].OutputValue' --output text

Erreur « Limite de débit dépassée »

Le système limite à 5 demandes par utilisateur toutes les 60 secondes. Attendez le temps indiqué avant de réessayer. Pour une utilisation en production avec des besoins de débit plus élevés, ajustez RATE_LIMIT_MAX_REQUESTS et RATE_LIMIT_WINDOW constatez dans le fichier main.py.

Ressources connexes

Documentation AWS