View a markdown version of this page

Automatizza la generazione di eventi di test Lambda utilizzando Amazon Bedrock AgentCore - Prontuario AWS
RiepilogoPrerequisiti e limitazioniArchitectureTools (Strumenti)Best practiceEpicheRisoluzione dei problemiRisorse correlate

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Automatizza la generazione di eventi di test Lambda utilizzando Amazon Bedrock AgentCore

Ishita Gupta e Kriti Gupta, Amazon Web Services

Riepilogo

Questo modello offre un AI-powered approccio per la generazione automatica di casi di test completi per le AWS Lambda funzioni utilizzando le funzionalità di intelligenza artificiale generativa di Amazon Bedrock. Questo modello implementa un'architettura a tre agenti (Analyzer, Generator e Validator) distribuita su Amazon Bedrock AgentCore che analizza il codice della funzione Lambda effettivo per estrarre input/output modelli e genera scenari di test positivi, negativi e limite con dati realistici.

L'architettura stabilisce un flusso di lavoro intelligente in cui l'Analyzer Agent recupera e analizza il codice Lambda utilizzando Amazon Bedrock, il Generator Agent crea casi di test basati su modelli appresi e il Validator Agent garantisce la qualità attraverso la deduplicazione e il ranking. Un archivio di DynamoDB-based memoria Amazon consente l'apprendimento continuo dal feedback degli utenti, migliorando la precisione della generazione dei test nel tempo. Amazon Cognito fornisce un'autenticazione utente sicura con autorizzazione API basata su JSON Web Token (JWT). Amazon Bedrock Guardrails fornisce un rapido filtraggio degli attacchi, la redazione delle informazioni sensibili e l'applicazione della sicurezza dei contenuti su tutte le chiamate API Amazon Bedrock. Funzionalità chiave:

  • Multi-Language Supporto: funzioni Python, Java, C# e Ruby Lambda JavaScript/TypeScript

  • Intelligent Code Chunking: divide automaticamente le basi di codice di grandi dimensioni in blocchi gestibili per l'analisi

  • Elaborazione parallela: chiamate simultanee all'API Amazon Bedrock per una generazione di test più rapida (5 lavoratori simultanei per l'analisi del codice, generazione parallela di test per blocco)

  • Target-Specific Analisi: concentrati su funzioni, classi o file specifici all'interno del codice Lambda

  • Pattern Learning: Amazon DynamoDB-based memory store con storage di pattern specifico per l'obiettivo e globale

  • Prevenzione del rifiuto: impara dai test case rifiutati per evitare gli errori più comuni

  • Meccanismo di continuazione: gestisce le risposte incomplete di Amazon Bedrock con continuazione automatica.

  • Ignora i modelli: escludi dall'analisi i file di test, le dipendenze e i file non di codice.

  • Distribuzione serverless: viene eseguita su Amazon Bedrock con autenticazione AgentCore Cognito-based

  • Security Guardrails: Amazon Bedrock Guardrails per il rapido filtraggio degli attacchi, la redazione delle informazioni di identificazione personale (PII), la sicurezza dei contenuti e il blocco degli argomenti negati su tutte le chiamate AI

    Questo modello è ideale per i team di sviluppo e le organizzazioni che desiderano accelerare i test Lambda, migliorare la copertura dei test e mantenere un'elevata qualità del codice attraverso la generazione di test. AI-assisted Questo modello utilizza i servizi gestiti di AWS per semplificare la creazione di test, migliorare la qualità attraverso l'apprendimento e scalare per soddisfare le esigenze di test in evoluzione.

Prerequisiti e limitazioni

Prerequisiti

Per implementare correttamente questo modello, assicurati che siano presenti i seguenti elementi:

  • Un account AWS attivo: un account AWS con autorizzazioni per accedere alle funzioni Lambda, richiamare modelli Amazon Bedrock, creare tabelle DynamoDB, gestire pool di utenti Cognito e distribuire agenti Amazon Bedrock. AgentCore

  • Accesso al modello Amazon Bedrock: Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) abilitato nella tua regione AWS. Per le istruzioni di configurazione, consulta Model Access nella documentazione di Amazon Bedrock.

  • Un ambiente di sviluppo composto da:

    - Python 3.11 o versioni successive

    - AWS CLI installato e configurato

    - Git per la clonazione del repository

  • Funzioni AWS Lambda: almeno una funzione Lambda distribuita con codice sorgente accessibile per l'analisi. La funzione deve includere file sorgente (.py, .js, .java, .cs, .rb) nel pacchetto di distribuzione, non solo bytecode compilato.

  • Runtime Lambda supportati:

    - Python 3.x (tutte le versioni)

    - Node.js (JavaScript/TypeScript)

    - Java 8, 11, 17, 21 (richiede i file sorgente .java nel pacchetto di distribuzione)

    - .NET Core/.NET 6+ (C#) (richiede file sorgente .cs nel pacchetto di distribuzione)

    - Ruby 2.7, 3.2

Limitazioni

  • Ciò richiede l'accesso al modello Amazon Bedrock nella regione us-east-1 per Claude Sonnet 4.6. Le funzioni AWS Lambda possono essere presenti in qualsiasi regione.

  • I dati dei pattern in Amazon DynamoDB scadono dopo 90 giorni (configurabili tramite Time to Live (TTL)) per mantenere la pertinenza e controllare i costi.

  • Le funzioni Java e C# Lambda devono includere file sorgente (.java, .cs) nei pacchetti di distribuzione. Compiled-only i pacchetti (.class, .dll) non possono essere analizzati.

  • Il sistema implementa la limitazione della frequenza in memoria per utente (5 richieste ogni 60 secondi). Per le implementazioni distribuite con più AgentCore istanze, la limitazione della velocità dovrebbe essere spostata su DynamoDB o Redis per motivi di coerenza.

  • Alcuni servizi AWS non sono disponibili in tutte le regioni AWS. Per la disponibilità delle regioni, consulta i servizi AWS per regione. Per endpoint specifici, consulta la pagina Endpoint e quote del servizio e scegli il link per il servizio.

Versioni del prodotto

Architecture

Architettura di destinazione

Il diagramma seguente mostra l'architettura e il flusso di lavoro per questo modello:

In questo flusso di lavoro:

  1. L'utente fornisce input: lo sviluppatore interagisce con Streamlit UI (app.py) in esecuzione localmente, fornisce il nome della funzione Lambda, istruzioni personalizzate opzionali per la generazione dei test, un filtro di destinazione per concentrarsi su functions/classes /files specifici e ignora i pattern per escludere file di test o dipendenze.

  2. Autenticazione Cognito: l'applicazione autentica la richiesta con Cognito e restituisce JWT (token) a Streamlit. ID/Access

  3. AgentCore Richiamo API: Streamlit richiama l' AgentCore API con Bearer Token + payload (nome della funzione, filtri, istruzioni, ignora i modelli).

  4. Convalida JWT: AgentCore l'API convalida JWT utilizzando la firma del token Cognito.

  5. Routing delle richieste: l'AgentCore API indirizza la richiesta al flusso di lavoro Lambda Test Generator (Runtime). AgentCore

  6. Richiesta di analisi del codice: Analyzer Agent avvia una richiesta per recuperare il codice e i metadati della funzione Lambda di destinazione.

  7. AWS Authentication for Lambda Access: Boto3 si autentica con AWS utilizzando il ruolo di esecuzione, richiedendo le autorizzazioni di accesso in lettura. AgentCore

  8. Recupero ed elaborazione del codice AWS Lambda: il ruolo IAM autorizza l'accesso e recupera il codice della funzione Lambda come file ZIP, estrae i file sorgente, filtra le dipendenze (node_modules, venv, ecc.) e i file non di codice, applica modelli di ignoramento definiti dall'utente e suddivide il codice in parti gestibili.

  9. Autenticazione Amazon Bedrock: il client Amazon Bedrock Boto3 esegue l'autenticazione con AWS IAM per l'accesso ad Amazon Bedrock, richiedendo l'invocazione delle autorizzazioni del modello per utilizzare Anthropic Claude Sonnet 4.6.

  10. AI-Powered Analisi del codice: il ruolo IAM autorizza e invia blocchi di codice ad Amazon Bedrock (us-east-1) utilizzando Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) con Amazon Bedrock Guardrail applicato per il filtro degli attacchi tempestivi e la sicurezza dei contenuti. Amazon Bedrock esegue un'analisi avanzata Regex + LLM per estrarre dal codice i pattern di input effettivi (ad esempio, event ['body'], headers ['Authorization']), i pattern di output (ad esempio, StatusCode, struttura del corpo della risposta), le dipendenze, i modelli di gestione degli errori e i casi limite.

  11. I risultati dell'analisi sono impacchettati: Analyzer Agent impacchetta i risultati dell'analisi in un AnalysisResult oggetto contenente blocchi di codice, pattern di input, pattern di output, dipendenze, pattern di errore e metadati, quindi li passa al Generator Agent.

  12. Inizia il processo di generazione dei test: Generator Agent riceve i risultati dell'analisi e avvia una richiesta per generare casi di test, interrogando innanzitutto l'archivio di memoria DynamoDB alla ricerca di modelli storici da cui imparare.

  13. Amazon DynamoDB Authentication for Memory Access: il client Boto3 DynamoDB si autentica con AWS IAM per ottenere le autorizzazioni di accesso in lettura per recuperare i pattern memorizzati.

  14. I pattern storici vengono recuperati dal database: il ruolo IAM autorizza e interroga la tabella di archiviazione della memoria DynamoDB (lambda-testcase-memory) per recuperare i pattern precedentemente accettati e i pattern rifiutati (test falliti con motivi di rifiuto) per la specifica funzione Lambda.

  15. Autenticazione Amazon Bedrock per la generazione di test: il client Amazon Bedrock Boto3 si autentica nuovamente con AWS IAM per l'accesso ad Amazon Bedrock per generare casi di test.

  16. Generazione di casi di test AI: il ruolo IAM autorizza e invia i risultati delle analisi combinati con i modelli di memoria ad Amazon Bedrock. Amazon Bedrock genera schemi di test case con eventi di input realistici basati su modelli di codice effettivi, creando test positivi (35%), test negativi (35%) e casi limite (30%). La generazione avviene per blocco in parallelo per garantire l'efficienza, applica i modelli appresi dalla memoria, evita i modelli rifiutati e la generazione di blocchi, se necessario, per basi di codice di grandi dimensioni. Tutte le chiamate converse () di Bedrock includono GuardrailConfig per il rapido filtraggio degli attacchi, la redazione delle informazioni personali e l'imposizione degli argomenti negati.

  17. Inizia la convalida del test: Generator Agent passa i candidati al test case generati al Validator Agent per il controllo di qualità, la deduplicazione e la selezione finale.

  18. Il processo di convalida è configurato: Validator Agent riceve i candidati al test e avvia il processo di convalida, richiedendo l'accesso all'archivio di memoria DynamoDB per il punteggio e la convalida.

  19. Autenticazione DynamoDB per la convalida: il client DynamoDB Boto3 si autentica con AWS IAM per l'accesso in lettura ai pattern di memoria delle query per il calcolo dei punteggi di convalida.

  20. La qualità dei test viene valutata: il ruolo IAM autorizza e utilizza l'archivio di memoria DynamoDB per valutare i casi di test in base alle percentuali di successo dei pattern precedenti, alla copertura delle funzioni e alla complessità del codice. Validator esegue la convalida strutturale, la deduplicazione mediante pattern hashing, l'assegnazione di punteggi di qualità con sicurezza per le funzioni di gestione e la gestione degli errori, la selezione della diversità per coprire diversi blocchi e tipi di test e seleziona i primi N casi di test più diversi e di più alta qualità.

  21. Casi di test finali restituiti a AgentCore: Validator Agent restituisce i test case convalidati finali con metadati (punteggi di confidenza, descrizioni, eventi di input, categorie) all'orchestrator principale, che li formatta e li restituisce all' AgentCore API Amazon Bedrock

  22. Risultati inviati all'interfaccia utente: l' AgentCore API restituisce i test generati all'interfaccia utente di Streamlit per la visualizzazione con il riepilogo dell'analisi, i metadati di generazione e i dettagli del test case.

  23. Esamina gli utenti e fornisce feedback: lo sviluppatore esamina i casi di test visualizzati nell'interfaccia utente di Streamlit, valuta ogni test per qualità e pertinenza, accetta casi di test validi o rifiuta quelli scadenti con motivi di rifiuto specifici (missing_auth_headers, wrong_status_code, unrealistic_data, missing_required_fields, incorrect_event_source, ecc.) e note personalizzate opzionali che spiegano il rifiuto, quindi subemette un feedback.

  24. Il feedback viene inviato al sistema: Streamlit UI invia il feedback raccolto (accepted/rejected stato, motivi del rifiuto, note personalizzate) all' AgentCore API (save_feedback).

  25. AgentCore indirizza il feedback: AgentCore l'API chiama l'agente Validator che contiene la logica per archiviare il feedback in DynamoDB.

  26. Inizia il processo di archiviazione del feedback: Validator Agent avvia il processo di archiviazione del feedback.

  27. L'accesso in scrittura di DynamoDB è autenticato: il client Boto3 DynamoDB si autentica con AWS IAM (ruolo di AgentCore esecuzione) per ottenere le autorizzazioni di accesso in scrittura per memorizzare i modelli di feedback.

  28. I modelli di apprendimento vengono archiviati: il ruolo IAM autorizza e memorizza il feedback degli utenti nella tabella di memoria di DynamoDB. Ogni modello viene archiviato con una chiave di partizione composita (function_name #target_function o function_name #GLOBAL), una chiave di ordinamento composita (FEEDBACK# accepted/rejected #PATTERN #hash), un pattern hash per la deduplicazione, il tipo di test, la struttura del modello di input, lo stato del feedback, il motivo del rifiuto (se rifiutato), note personalizzate, conteggio degli utilizzi, percentuale di successo, timestamp e TTL di 90 giorni per la pulizia automatica. Questi dati memorizzati consentono al sistema di apprendere dal feedback degli utenti e migliorare la generazione futura dei test.

Automazione e scalabilità

Questo modello si ridimensiona automaticamente utilizzando i servizi gestiti di AWS. Amazon Bedrock gestisce l'inferenza AI su richiesta con una finestra di contesto di 200.000 token e un output di 64.000 token per chiamata, mentre Amazon DynamoDB utilizza la fatturazione su richiesta che si adatta automaticamente ai modelli di traffico. Il sistema utilizza l'elaborazione parallela per aumentare la velocità, Analyzer Agent effettua 5 chiamate Bedrock simultanee per analizzare blocchi di codice (ThreadPoolExecutor con max_workers=5), mentre Generator Agent elabora i blocchi in parallelo con 5 lavoratori simultanei. Un meccanismo di continuazione gestisce le risposte incomplete riprovando automaticamente le richieste. La limitazione della velocità (5 richieste ogni 60 secondi per utente) previene l'abuso dei costi dovuto a chiamate eccessive alle API Bedrock.

L'ottimizzazione dei costi include la TTL-based pulizia che rimuove i pattern più vecchi di 90 giorni, le query a chiave composita con begins_with () per ricerche istantanee senza scansioni delle tabelle e BatchWriteItem le operazioni che riducono le operazioni di scrittura di DynamoDB di circa il 90%. Le prestazioni dipendono dalle dimensioni della funzione, le funzioni piccole (meno di 10 file) generano 10 casi di test in 30-60 secondi, le funzioni medie (10-50 file) richiedono 1-3 minuti e le funzioni grandi (oltre 50 file) richiedono 3-5 minuti, sebbene l'utilizzo di filtri di destinazione per concentrarsi su sezioni di codice specifiche riduca i tempi del 50-70%.

Tools (Strumenti)

Servizi AWS

  • Amazon Bedrock: fornisce funzionalità di intelligenza artificiale generativa tramite Anthropic Claude Sonnet 4 per l'analisi del codice, la generazione di test, la convalida e il riepilogo del rifiuto. Utilizza sempre la regione us-east-1 per l'accesso ai modelli.

  • Amazon Bedrock AgentCore : fornisce un runtime di agenti serverless per la distribuzione e l'hosting del backend di generazione di test con scalabilità, autorizzazione e osservabilità automatiche. OAuth-based CloudWatch

  • Amazon Bedrock Guardrails: fornisce filtri di ML-based sicurezza su tutte le chiamate API Bedrock, incluso il rilevamento tempestivo degli attacchi (HIGH strength), il filtraggio dei contenuti, l'anonimizzazione delle PII (email, telefono, nome), il blocco dei keys/private keys/JWT token di accesso AWS e l'applicazione negata degli argomenti (generazione di codice exploit, output di codice sorgente non elaborato). Distribuito tramite. CloudFormation

  • AWS CloudFormation: automatizza il provisioning completo dell'infrastruttura, tra cui tabella DynamoDB, Cognito User Pool, Amazon Bedrock Guardrail con controllo delle versioni e ruolo di esecuzione IAM per. AgentCore

  • Amazon Cognito: fornisce l'autenticazione degli utenti con registrazione tramite e-mail, emissione di token JWT e autorizzazione API sicura per il backend. AgentCore

  • Amazon DynamoDB: memorizza i modelli di test accettati e rifiutati con statistiche di utilizzo per l'apprendimento e il miglioramento continui. Utilizza chiavi composite (function_target, pattern_sk) per query a scansione zero e archiviazione di pattern specifici per la destinazione.

  • AWS Lambda: fonte del codice funzionale per l'analisi, l'API recupera codice e configurazione. GetFunction Lo strumento supporta i runtime Python, Java Node.js, .NET e Ruby.

Altri strumenti

  • Python 3.11+ — Ambiente di runtime per l'orchestrazione di applicazioni e agenti.

  • Streamlit: interfaccia Web-based utente per l'autenticazione, la generazione di test, la raccolta di feedback e il monitoraggio dello stato del sistema.

  • Boto3 — SDK AWS per Python per interagire con i servizi Lambda, Amazon Bedrock, DynamoDB e Cognito.

Repository di codice

Il codice per questo pattern è disponibile in Github - Lambda Test Event Generator.

Best practice

Questo modello implementa le seguenti best practice:

  • Utilizza politiche IAM con privilegi minimi per l'accesso ad AWS Lambda (sola lettura), Amazon Bedrock (invoke), Amazon DynamoDB () e Amazon Cognito (autenticazione). query/write

  • Implementa l'apprendimento di modelli specifici per obiettivi con fallback globale per una maggiore precisione dei test.

  • Abilita DynamoDB TTL per la pulizia automatica dei vecchi pattern (90 giorni) per controllare i costi di archiviazione.

  • Usa le query zero-scan con tasti compositi (function_target, pattern_sk) per un rapido recupero dei pattern.

  • Applica i pattern di ignoramento per escludere dall'analisi file di test, dipendenze e file non di codice.

  • Usa la suddivisione in più lingue del codice con l'analisi Abstract Syntax Tree (AST) (Python) e i pattern regex (Java, C#, JS, Ruby).

  • Memorizza i modelli con valori effettivi (non solo con la struttura) per una vera deduplicazione.

  • Implementa il backend su Amazon Bedrock AgentCore per scalabilità senza server e infrastruttura gestita.

  • Autentica gli utenti tramite Amazon Cognito con la convalida del token JWT su ogni richiesta API.

  • Applica Amazon Bedrock Guardrails a tutte le chiamate converse () per filtrare tempestivamente gli attacchi, cancellare le informazioni personali, bloccare i dati sensibili (chiavi AWS, chiavi private, JWT) e imporre argomenti negati.

  • Pulisci i risultati delle analisi prima di restituirli agli utenti: tutti i frammenti di codice sorgente non elaborato vengono rimossi dalle risposte, assicurando che il codice sorgente Lambda non esca mai dai limiti di runtime. AgentCore

  • Convalida tutti gli input dell'API con modelli regex e limiti di lunghezza (nome della funzione max 170 caratteri, istruzioni personalizzate max 2000 caratteri, max 50 pattern di ignoramento) per prevenire iniezioni e abusi.

  • Implementa la limitazione della frequenza per utente (5 richieste ogni 60 secondi) per prevenire l'abuso dei costi dovuto a chiamate eccessive alle API Bedrock.

  • Pulisci i messaggi di errore prima di restituirli agli utenti: i percorsi interni dei file, i dettagli dell'SDK AWS e le informazioni sull'infrastruttura non vengono mai esposti nelle risposte agli errori.

Considera le seguenti best practice aggiuntive:

  • Fornisci motivi di feedback specifici quando rifiuti i casi di test per migliorare l'accuratezza dell'apprendimento.

  • Genera test in modo iterativo (2-3 volte) per la stessa funzione per consentire al sistema di apprendere e migliorare.

  • Fornisci istruzioni personalizzate quando hai bisogno di scenari di test o formati di dati specifici.

  • Abilita IAM Access Analyzer per monitorare le autorizzazioni delle risorse e identificare gli accessi non intenzionali.

  • Inizia con piccole funzioni Lambda per comprendere il sistema prima di analizzare basi di codice di grandi dimensioni.

  • Rivedi regolarmente le policy IAM e rimuovi le autorizzazioni non utilizzate.

  • Utilizza politiche di password complesse e abilita Cognito AdvancedSecurityMode per il rilevamento delle minacce.

Epiche

OperazioneDescriptionCompetenze richieste

Clonare il repository.

Clona il GitHub repository sul tuo sistema locale e vai alla directory del progetto:

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

cd sample-lambda-test-event-generator

Questo repository contiene l'applicazione Python, il CloudFormation modello e i file di configurazione.

Sviluppatore di app

Configura le credenziali AWS.

Configura le tue credenziali AWS per consentire all'AWS CLI di interagire con il tuo account AWS e per consentire all'applicazione di accedere alle funzioni Lambda che desideri testare.

Puoi farlo usando il comando di configurazione AWS CLI:

aws configure

Quando viene richiesto, fornire le seguenti informazioni:

  • ID chiave di accesso AWS: la tua chiave di accesso AWS

  • Chiave di accesso segreta AWS: la tua chiave di accesso segreta AWS

  • Nome della regione predefinita: la regione AWS in cui desideri distribuire le risorse (ad es.) us-east-1

  • Formato di output predefinito: il formato di output preferito (ad es.) json

Sviluppatore di app
OperazioneDescriptionCompetenze richieste

Implementa l'infrastruttura utilizzando CloudFormation.

  1. Implementa l'infrastruttura backend completa (ruoli DynamoDB, Cognito, IAM) utilizzando il modello fornito. CloudFormation Esegui il seguente comando nella tua 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. Attendi il completamento della distribuzione dello stack:

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

  3. Recupera tutti gli output:

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

Cosa viene creato:

  • Tabella DynamoDB con TTL abilitato, ripristino point-in-time e crittografia lato server.

  • Pool di utenti Cognito con autenticazione e-mail, AdvancedSecurityMode ENFORCED, MFA opzionale (TOTP) e creazione di utenti solo amministrativi.

  • Amazon Bedrock Guardrail con filtro rapido degli attacchi, redazione delle informazioni personali, filtro dei contenuti e blocco degli argomenti negati.

  • Ruolo di esecuzione IAM per le politiche AgentCore con privilegi minimi, tra cui bedrock: permission. ApplyGuardrail

Nota

Lo stack crea tutte le risorse necessarie. Assicurati che il CloudFormation modello sia completato correttamente prima di procedere alla fase successiva.

Sviluppatore di app

Esporta le variabili di configurazione.

Esporta tutti i valori dagli output CloudFormation dello stack come variabili di ambiente:

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)

Queste variabili vengono utilizzate nei passaggi successivi per la AgentCore configurazione e la creazione di file .env.

Amministratore AWS
OperazioneDescriptionCompetenze richieste

Crea un ambiente virtuale.

  1. Crea e attiva un ambiente virtuale Python per isolare le dipendenze del progetto:

    python3 -m venv venv

source venv/bin/activate

  2. Installa i pacchetti Python richiesti dal file dei requisiti:

    pip install -r requirements.txt

    Questo installa tutte le librerie necessarie, tra cui boto3 per AWS SDK, python-dotenv per la configurazione dell'ambiente, bedrock-agentcore-runtime per l'integrazione e Streamlit per l'interfaccia utente. AgentCore

    Nota

    L'ambiente virtuale deve essere attivato (utilizzando) ogni volta che si apre una nuova sessione di terminale per eseguire l'applicazione. source venv/bin/activate

Sviluppatore di app

Configurazione e distribuzione. AgentCore

  • Configura l' AgentCore agente:

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

  • Quando richiesto:

    1. Tipo di distribuzione: 1 (Direct Code Deploy, non è necessario Docker)

    2. Versione Python: 2 (PYTHON_3_11 o seleziona la tua particolare versione di Python)

    3. Bucket S3: premi Invio (creazione automatica)

    4. Autorizzatore OAuth: sì

    5. URL di scoperta: incolla il valore $DISCOVERY_URL

    6. ID client: incolla il valore $CLIENT_ID

    7. Destinatari: premi Invio (lascia vuoto)

    8. Ambiti: premi Invio (lascia vuoto)

    9. Reclami personalizzati: premi Invio (lascia vuoto)

    10. Intestazioni delle richieste: sì

    11. Intestazioni: Autorizzazione

    12. Memoria: s (salta - usando DynamoDB)

  • Distribuisci l'agente:

    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

  • Ottieni l'ID AgentCore di runtime e l'endpoint:

    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"
Sviluppatore di app

Crea un file .env per lo sviluppo locale.

Crea un file .env nella directory principale del progetto con tutti i valori di configurazione:

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

Verifica la connettività ai servizi AWS:

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

Entrambi i comandi dovrebbero restituire risposte corrette. Se riscontri errori di autorizzazione, verifica che le policy IAM siano configurate correttamente.

Sviluppatore di app
OperazioneDescriptionCompetenze richieste

Crea un nuovo utente Cognito.

Il pool di utenti Cognito è configurato con la creazione di utenti solo come amministratore per motivi di sicurezza, quindi gli utenti non possono registrarsi automaticamente. Crea un utente tramite l'interfaccia a riga di comando di AWS utilizzando l'ID del pool di Cognito e l'ID client esportati dagli output dello stack. CloudFormation Crea un nuovo utente (sostituiscilo user@example.com con la tua email):

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

Imposta una password permanente (minimo 8 caratteri, deve includere lettere maiuscole, minuscole e un numero):

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

Usa queste credenziali per accedere tramite l'interfaccia utente di Streamlit nel passaggio successivo.

Sviluppatore di app
OperazioneDescriptionCompetenze richieste

Avvia l'interfaccia utente Streamlit.

Avvia l'applicazione:

streamlit run app.py

L'interfaccia utente si aprirà nel browser predefinito all'indirizzo http://localhost:8501

Accedi con le credenziali create nel passaggio precedente

Sviluppatore di app

Configura le opzioni di generazione

Nell'interfaccia utente, configura le seguenti opzioni:

  1. Nome o ARN della funzione Lambda: immettere l'identificatore della funzione Lambda di destinazione

  2. Filtro di destinazione (opzionale): specifica una funzione, una classe o un file su cui concentrarti (ad esempio,,) validate_user UserService auth.py

  3. Ignora i modelli (opzionale): aggiungi i modelli di file o cartelle da escludere, uno per riga:

    • tests/- Ignora la directory dei test

    • *.test.js- Ignora i file di test

    • mock_data/- Ignora i dati fittizi

  4. Istruzioni personalizzate (opzionali): aggiungi requisiti di test specifici

Sviluppatore di app

Genera casi di test.

Fai clic sul pulsante «Genera casi di test». Il sistema consentirà di:

  1. Effettua l'autenticazione AgentCore utilizzando il token Cognito JWT.

  2. Recupera il codice Lambda da AWS.

  3. Applica i modelli di ignoramento per escludere i file indesiderati.

  4. Codice in blocchi che utilizza strategie specifiche della lingua.

  5. Applica il filtro di destinazione se specificato.

  6. Analizza il codice con Amazon Bedrock.

  7. Interroga DynamoDB per individuare i modelli appresi.

  8. Genera casi di test.

  9. Convalida e classifica i casi di test.

Sviluppatore di app

Rivedi i test generati.

Esamina ogni test case generato, che include:

  • Tipo: Positivo (input validi), Negativo (input non validi) o Edge (condizioni limite)

  • Descrizione: cosa convalida il test

  • Dati del test: il payload effettivo dell'evento di test

DevOps ingegnere, sviluppatore di app

Fornisci feedback.

Per ogni test case, fornisci un feedback:

Per accettare un test case:

  • Fai clic sul pulsante «Accetta»

Per rifiutare un test case:

  1. Fai clic sul pulsante «Rifiuta»

  2. Seleziona un motivo del rifiuto dal menu a discesa o aggiungi un motivo personalizzato

  3. Fai clic sul pulsante «Invia rifiuto»

Tecnico collaudatore

Salva il feedback in memoria.

Dopo aver esaminato tutti i casi di test:

  1. Fai clic sul pulsante «Salva tutti i feedback in memoria»

  2. Il sistema verifica che tutti i casi respinti abbiano motivato

  3. Il feedback viene inviato all' AgentCore API che viene indirizzata al Validator Agent.

  4. Il feedback viene archiviato in batch in DynamoDB con pattern hash per la deduplicazione.

  5. Visualizza il riepilogo accepted/rejected del feedback che mostra i conteggi

Tecnico collaudatore

Iterate per migliorare.

Genera test altre 2-3 volte per la stessa funzione per migliorare la qualità:

  • Il sistema recupera i pattern appresi da DynamoDB

  • La qualità migliora ad ogni iterazione in base al tuo feedback

  • Utilizza il filtro target per test mirati su componenti specifici

  • Usa i modelli di ignora per escludere codice irrilevante e migliorare la qualità della generazione

Nota

Il sistema di apprendimento diventa più efficace con un uso ripetuto. Ogni ciclo di feedback aiuta l'IA a comprendere le tue preferenze di test e a generare casi di test più pertinenti per le tue funzioni Lambda.

Sviluppatore di app
OperazioneDescriptionCompetenze richieste

Richiama direttamente AgentCore l'API.

Per l'automazione e l'integrazione, richiama il AgentCore backend direttamente utilizzando le chiamate API con l'autenticazione Cognito.

Ottieni un token Cognito:

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

Richiama la generazione del test:

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"] }'

O usando 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}'
Sviluppatore di app
OperazioneDescriptionCompetenze richieste

Monitora i modelli DynamoDB e tieni traccia dei costi.

  1. Interroga la tabella DynamoDB per esaminare i modelli accettati e capire cosa ha appreso il sistema:

    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"}}'

    my-functionSostituiscila con il nome effettivo della tua funzione Lambda per visualizzare i modelli specifici di quella funzione.

  2. Tieni traccia del consumo di risorse per ottimizzare i costi:

    • AWS Cost Explorer: monitora la spesa complessiva per i servizi Bedrock, DynamoDB e Lambda

    • Amazon Bedrock: esamina l'utilizzo dei token e le metriche relative alle chiamate API nella console Bedrock

    • DynamoDB: controlla le metriche delle richieste, la capacità consumata e l'utilizzo dello storage.

    • AgentCore: Monitora le metriche di runtime degli agenti e il conteggio delle chiamate in CloudWatch

  3. Usa CloudWatch i log per diagnosticare i problemi e monitorare il comportamento del sistema:

    • AgentCore registri: 

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

    • Errori dell'applicazione: esamina gli errori e le eccezioni a livello di applicazione

    • Risposte API Bedrock: analizza le risposte del modello AI e il consumo di token

    • Operazioni DynamoDB: monitora i read/write modelli e gli eventi di limitazione

Nota

Il monitoraggio regolare aiuta a identificare le opportunità di ottimizzazione dei costi e garantisce che il sistema continui a imparare in modo efficace. La configurazione TTL sulla tabella DynamoDB elimina automaticamente i vecchi schemi, aiutando a gestire i costi di storage nel tempo.

Amministratore AWS
OperazioneDescriptionCompetenze richieste

Eliminare le risorse distribuite.

Per rimuovere tutte le risorse distribuite:

Eliminare l' AgentCore agente:

agentcore destroy

Elimina lo CloudFormation stack (elimina la tabella DynamoDB, il pool di utenti Cognito e il ruolo IAM):

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

Risoluzione dei problemi

ProblemaSoluzione

Errore «Accesso negato» durante il recupero del codice Lambda

  • Verifica che le autorizzazioni IAM includano lambda:GetFunction e lambda:GetFunctionConfiguration per la funzione Lambda di destinazione

  • Controlla le tue credenziali AWS CLI

    aws sts get-caller-identity

«Errori di scrittura in DynamoDB»

  • Verifica che il nome della tabella nel .env file corrisponda al nome della tabella distribuita

  • Controlla gli CloudFormation output:

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

  • Oppure verifica direttamente:

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

Nessun caso di test generato

Possibili cause e soluzioni:

  • Il codice della funzione Lambda non è accessibile: controlla le autorizzazioni IAM per l'accesso Lambda

  • Il pacchetto di distribuzione Lambda contiene solo codice compilato: i file senza .dll file sorgente non possono essere .class analizzati

  • Tutti i file filtrati in base ai modelli di ignoramento: rivedi e modifica i modelli di ignoramento

  • Le istruzioni personalizzate sono troppo restrittive: semplifica o rimuovi le istruzioni personalizzate

  • Verifica che la funzione Lambda esista:

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

Java/C# Lambda mostra «Nessun codice sorgente trovato»

Java e C# Lambdas richiedono i file sorgente nel pacchetto di distribuzione:

Java (Maven):

  1. Aggiungi la configurazione di inclusione dei sorgenti a pom.xml (vedi) docs/JAVA_SETUP.md

  2. Ricostruisci e ridistribuisci la tua funzione Lambda

C# (.NET):

  1. Includi .cs file nella configurazione della build (vedidocs/CSHARP_SETUP.md)

  2. Ricostruisci e ridistribuisci la tua funzione Lambda

Errori di scrittura in DynamoDB

  • Controlla le autorizzazioni di DynamoDB e lo stato della tabella:

  • Verifica che la politica IAM includa e dynamodb:PutItem dynamodb:BatchWriteItem

  • Controlla lo stato della tabella: 

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

    Il nome della tabella include il suffisso del nome dello stack. Usa il valore dei tuoi CloudFormation output o del file .env.

  • Abilita CloudWatch i log per DynamoDB per visualizzare messaggi di errore dettagliati

Generazione lenta dei test

Ottimizza la velocità di generazione:

  1. Usa il filtro target per concentrarti su funzioni specifiche (50-70% più veloce)

  2. Aggiungi pattern di ignoramento per escludere file di test, dipendenze e codice irrilevante

  3. Riduci le dimensioni del codice filtrando i file non necessari prima dell'analisi

AgentCore: «Agente non trovato»

Verifica che l'agente sia installato:

agentcore status

agentcore configure list

AgentCore: «Autorizzazione negata» in fase di esecuzione

Verifica che il ruolo di esecuzione abbia le politiche corrette:

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

Cognito: «Nome utente o password non validi»

Verifica che le tue credenziali siano corrette. Puoi creare un nuovo utente utilizzando il flusso «Crea account» dell'interfaccia utente di Streamlit o tramite l'interfaccia a riga di comando di AWS:

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

Avviso «Bedrock Guardrail non configurato» nei log

Le variabili di verifica BEDROCK_GUARDRAIL_ID e di BEDROCK_GUARDRAIL_VERSION ambiente sono impostate nella AgentCore distribuzione.

Controlla gli CloudFormation output: 

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

Errore «Limite di frequenza superato»

Il sistema limita a 5 richieste ogni 60 secondi per utente. Attendi il tempo indicato prima di riprovare. Per l'uso in produzione con esigenze di produttività più elevate, aggiustate RATE_LIMIT_MAX_REQUESTS e RATE_LIMIT_WINDOW costanti in main.py.

Risorse correlate

Documentazione AWS