View a markdown version of this page

Automatice la generación de eventos de pruebas de Lambda con Amazon Bedrock AgentCore - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaTools (Herramientas)Prácticas recomendadasEpicsResolución de problemasRecursos relacionados

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Automatice la generación de eventos de pruebas de Lambda con Amazon Bedrock AgentCore

Ishita Gupta y Kriti Gupta, de Amazon Web Services

Resumen

Este patrón ofrece un AI-powered enfoque para generar automáticamente casos de prueba completos para AWS Lambda funciones que utilizan las capacidades de inteligencia artificial generativa de Amazon Bedrock. Este patrón implementa una arquitectura de tres agentes (Analyzer, Generator y Validator) implementada en Amazon Bedrock AgentCore que analiza el código real de las funciones de Lambda para extraer input/output patrones y generar escenarios de prueba positivos, negativos y extremos con datos realistas.

La arquitectura establece un flujo de trabajo inteligente en el que el agente analizador obtiene y analiza el código Lambda con Amazon Bedrock, el agente generador crea casos de prueba basados en patrones aprendidos y el agente validador garantiza la calidad mediante la deduplicación y la clasificación. Un almacén de DynamoDB-based memoria de Amazon permite un aprendizaje continuo a partir de los comentarios de los usuarios, lo que mejora la precisión de la generación de pruebas con el tiempo. Amazon Cognito proporciona una autenticación de usuario segura con una autorización de API basada en JSON Web Token (JWT). Los Guardrails de Amazon Bedrock permiten filtrar rápidamente los ataques, redactar información confidencial y garantizar la seguridad del contenido en todas las llamadas a la API de Amazon Bedrock. Capacidades clave:

  • Multi-Language Soporte: funciones de Python, Java, C# y Ruby Lambda JavaScript/TypeScript

  • Fragmentación inteligente de código: divide automáticamente bases de código grandes en fragmentos manejables para su análisis

  • Procesamiento paralelo: la API simultánea de Amazon Bedrock exige una generación de pruebas más rápida (5 procesos simultáneos para el análisis del código, generación de pruebas en paralelo por fragmento)

  • Target-Specific Análisis: concéntrese en funciones, clases o archivos específicos del código Lambda

  • Aprendizaje de patrones: almacén de DynamoDB-based memoria de Amazon con almacenamiento de patrones global y específico para cada destino

  • Prevención del rechazo: aprende de los casos de prueba rechazados para evitar errores comunes

  • Mecanismo de continuación: gestiona las respuestas incompletas de Amazon Bedrock con la continuación automática.

  • Ignore los patrones: excluya del análisis los archivos de prueba, las dependencias y los archivos sin código.

  • Implementación sin servidor: se ejecuta en Amazon Bedrock con autenticación AgentCore Cognito-based

  • Barreras de seguridad: Amazon Bedrock garantiza el filtrado rápido de los ataques, la redacción de la información de identificación personal (PII), la seguridad del contenido y la denegación del bloqueo de temas en todas las llamadas mediante IA

    Este patrón es ideal para los equipos de desarrollo y las organizaciones que desean acelerar las pruebas de Lambda, mejorar la cobertura de las pruebas y mantener una alta calidad del código durante la generación de las pruebas. AI-assisted Este patrón utiliza los servicios gestionados de AWS para simplificar la creación de pruebas, mejorar la calidad mediante el aprendizaje y adaptarse a las cambiantes necesidades de las pruebas.

Requisitos previos y limitaciones

Requisitos previos

Para implementar correctamente este patrón, asegúrese de que se cumpla lo siguiente:

  • Una cuenta de AWS activa: una cuenta de AWS con permisos para acceder a las funciones de Lambda, invocar modelos de Amazon Bedrock, crear tablas de DynamoDB, administrar grupos de usuarios de Cognito e implementar agentes de Amazon Bedrock. AgentCore

  • Acceso al modelo Amazon Bedrock: Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) habilitado en su región de AWS. Para obtener instrucciones de configuración, consulte el acceso al modelo en la documentación de Amazon Bedrock. https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html

  • Un entorno de desarrollo que consiste en:

    - Python 3.11 o superior

    - La CLI de AWS instalada y configurada

    - Git para clonar el repositorio

  • Funciones de AWS Lambda: al menos una función de Lambda implementada con código fuente accesible para su análisis. La función debe incluir los archivos fuente (.py, .js, .java, .cs, .rb) en el paquete de implementación, no solo el código de bytes compilado.

  • Tiempos de ejecución de Lambda compatibles:

    - Python 3.x (todas las versiones)

    - Node.js (JavaScript/TypeScript)

    - Java 8, 11, 17, 21 (requiere los archivos fuentes.java en el paquete de implementación)

    - .NET Core/.NET 6+ (C#) (requiere los archivos fuentes.cs en el paquete de implementación)

    - Ruby 2.7, 3.2

Limitaciones

  • Esto requiere el acceso al modelo Amazon Bedrock en la región us-east-1 para Claude Sonnet 4.6. Las funciones de AWS Lambda pueden estar en cualquier región.

  • Los datos de patrones de Amazon DynamoDB caducan a los 90 días (se pueden configurar mediante Time to Live (TTL)) para mantener la relevancia y controlar los costos.

  • Las funciones Lambda de Java y C# deben incluir los archivos fuente (.java, .cs) en los paquetes de implementación. Compiled-only los paquetes (.class, .dll) no se pueden analizar.

  • El sistema implementa un límite de velocidad de memoria por usuario (5 solicitudes cada 60 segundos). En el caso de las implementaciones distribuidas con varias AgentCore instancias, la limitación de velocidad debería trasladarse a DynamoDB o Redis para mantener la coherencia.

  • Algunos servicios de AWS no están disponibles en todas las regiones de AWS. Para obtener información sobre la disponibilidad en regiones, consulte AWS services by Region. Para ver los puntos de conexión específicos, consulte la página Service endpoints and quotas y elija el enlace del servicio.

Versiones de producto

Arquitectura

Arquitectura de destino

El siguiente diagrama muestra la arquitectura y el flujo de trabajo de este patrón:

En este flujo de trabajo:

  1. El usuario proporciona información: el desarrollador interactúa con la interfaz de usuario de Streamlit (app.py) que se ejecuta localmente, proporciona el nombre de la función de Lambda, instrucciones personalizadas opcionales para la generación de pruebas, un filtro de destino para centrarse en functions/classes /files específicos e ignora los patrones para excluir los archivos de prueba o las dependencias.

  2. Autenticación de Cognito: la aplicación autentica la solicitud con Cognito y devuelve el JWT (token) a Streamlit. ID/Access

  3. AgentCore Invocación de la API: Streamlit invoca la AgentCore API con el token del portador y la carga útil (nombre de la función, filtros, instrucciones, ignora patrones).

  4. Validación de JWT: la AgentCore API valida JWT mediante la firma del token de Cognito.

  5. Enrutamiento de solicitudes: la AgentCore API dirige la solicitud al flujo de trabajo del generador de pruebas de Lambda (tiempo de ejecución). AgentCore

  6. Solicitud de análisis de código: Analyzer Agent inicia una solicitud para obtener el código y los metadatos de la función Lambda de destino.

  7. Autenticación de AWS para Lambda Access: Boto3 se autentica en AWS mediante la función de ejecución y solicita permisos de acceso de AgentCore lectura.

  8. Recuperación y procesamiento del código Lambda de AWS: el rol de IAM autoriza el acceso y obtiene el código de la función de Lambda en forma de archivo ZIP, extrae los archivos fuente, filtra las dependencias (node_modules, venv, etc.) y los archivos que no son de código, aplica patrones de omisión definidos por el usuario y divide el código en partes manejables.

  9. Autenticación de Amazon Bedrock: Boto3 El cliente de Amazon Bedrock se autentica con AWS IAM para acceder a Amazon Bedrock y solicita los permisos de invocación del modelo para usar Anthropic Claude Sonnet 4.6.

  10. AI-Powered Análisis de código: el rol de IAM autoriza y envía fragmentos de código a Amazon Bedrock (us-east-1) mediante Anthropic Claude Sonnet 4 (us.anthropic.claude-sonnet-4-6) con Amazon Bedrock Guardrail aplicado para filtrar rápidamente los ataques y proteger el contenido. Amazon Bedrock realiza análisis mejorados con Regex + LLM para extraer patrones de entrada reales (p. ej., eventos ['body'], encabezados ['Authorization']), patrones de salida (p. ej., StatusCode, estructura del cuerpo de la respuesta), dependencias, patrones de gestión de errores y casos extremos del código.

  11. Los resultados del análisis se empaquetan: Analyzer Agent empaqueta los resultados del análisis en un AnalysisResult objeto que contiene fragmentos de código, patrones de entrada, patrones de salida, dependencias, patrones de error y metadatos, y luego los pasa al Generator Agent.

  12. Comienza el proceso de generación de pruebas: Generator Agent recibe los resultados del análisis e inicia una solicitud para generar casos de prueba. En primer lugar, consulta el almacén de memoria de DynamoDB en busca de patrones históricos de los que aprender.

  13. Autenticación de Amazon DynamoDB para el acceso a la memoria: el cliente Boto3 de DynamoDB se autentica con AWS IAM para obtener permisos de acceso de lectura para recuperar los patrones almacenados.

  14. Los patrones históricos se recuperan de la base de datos: el rol de IAM autoriza y consulta la tabla de almacenamiento de memoria de DynamoDB (lambda-testcase-memory) para buscar los patrones previamente aceptados y los patrones rechazados (pruebas fallidas por motivos de rechazo) para la función de Lambda específica.

  15. Autenticación de Amazon Bedrock para la generación de pruebas: Boto3 El cliente de Amazon Bedrock se autentica de nuevo con AWS IAM para acceder a Amazon Bedrock a fin de generar casos de prueba.

  16. Generación de casos de prueba con IA: la función de IAM autoriza y envía los resultados de los análisis combinados con los patrones de memoria a Amazon Bedrock. Amazon Bedrock genera esquemas de casos de prueba con eventos de entrada realistas basados en patrones de código reales, lo que genera pruebas positivas (35%), negativas (35%) y casos extremos (30%). La generación se realiza por fragmento en paralelo para mejorar la eficiencia, aplica los patrones aprendidos de la memoria, evita los patrones rechazados y la generación de fragmentos si es necesario para bases de código de gran tamaño. Todas las llamadas converse () de Bedrock incluyen GuardrailConfig para filtrar rápidamente los ataques, redactar la PII y denegar el cumplimiento de los temas.

  17. Comienza la validación de las pruebas: Generator Agent pasa los casos de prueba candidatos generados al Validator Agent para el control de calidad, la deduplicación y la selección final.

  18. El proceso de validación está configurado: el agente de validación recibe a los candidatos para la prueba e inicia el proceso de validación, solicitando el acceso al almacén de memoria de DynamoDB para obtener la puntuación y la validación.

  19. Autenticación de DynamoDB para la validación: el cliente Boto3 de DynamoDB se autentica con AWS IAM para acceder de lectura a los patrones de memoria de consulta y así obtener la puntuación de la validación.

  20. La calidad de las pruebas se evalúa: el rol de IAM autoriza y usa el almacenamiento de memoria de DynamoDB para puntuar los casos de prueba en función de los patrones anteriores, las tasas de éxito, la cobertura de las funciones y la complejidad del código. Validator realiza la validación estructural, la deduplicación mediante el hash de patrones, la puntuación de calidad con mejoras de confianza para las funciones del controlador y la gestión de errores, la selección de la diversidad para cubrir diferentes fragmentos y tipos de pruebas, y selecciona los N casos de prueba más diversos y de mayor calidad.

  21. Casos de prueba finales devueltos a AgentCore: Validator Agent devuelve los casos de prueba validados finales con metadatos (puntuaciones de confianza, descripciones, eventos de entrada, categorías) al orquestador principal, que los formatea y los devuelve a la AgentCore API de Amazon Bedrock

  22. Los resultados se entregan a la interfaz de usuario: la AgentCore API devuelve las pruebas generadas a la interfaz de usuario de Streamlit para mostrarlas con el resumen del análisis, los metadatos de generación y los detalles de los casos de prueba.

  23. El usuario revisa y proporciona comentarios: el desarrollador revisa los casos de prueba que se muestran en la interfaz de usuario de Streamlit, evalúa la calidad y relevancia de cada prueba, acepta los casos de prueba buenos o rechaza los malos con motivos de rechazo específicos (missing_auth_headers, wrong_status_code, unrealistic_data, missing_required_fields, incorrect_event_source, etc.) y notas personalizadas opcionales que explican el rechazo, y luego envía comentarios.

  24. Los comentarios se envían al sistema: la interfaz de usuario de Streamlit envía los comentarios recopilados (accepted/rejected estado, motivos de rechazo, notas personalizadas) a la AgentCore API (save_feedback).

  25. AgentCore canaliza los comentarios: la AgentCore API llama al agente validador, que contiene la lógica para almacenar los comentarios en DynamoDB.

  26. Comienza el proceso de almacenamiento de comentarios: el agente de validación inicia el proceso para almacenar los comentarios.

  27. El acceso de escritura de DynamoDB está autenticado: el cliente Boto3 de DynamoDB se autentica con AWS IAM (AgentCore función de ejecución) para obtener permisos de acceso de escritura a fin de almacenar los patrones de comentarios.

  28. Los patrones de aprendizaje se almacenan: la función de IAM autoriza y almacena los comentarios de los usuarios en la tabla de almacenamiento de memoria de DynamoDB. Cada patrón se almacena con una clave de partición compuesta (function_name #target_function o function_name #GLOBAL), una clave de clasificación compuesta (FEEDBACK# accepted/rejected #PATTERN #hash), un hash de patrón para la deduplicación, el tipo de prueba, la estructura del patrón de entrada, el estado de los comentarios, el motivo del rechazo (si se rechaza), las notas personalizadas, el recuento de uso, la tasa de éxito, la marca de tiempo y un TTL de 90 días para la limpieza automática. Estos datos almacenados permiten al sistema aprender de los comentarios de los usuarios y mejorar la generación de pruebas futuras.

Automatización y escala

Este patrón se escala automáticamente mediante los servicios gestionados de AWS. Amazon Bedrock gestiona la inferencia de IA bajo demanda con una ventana de contexto de 200 000 tokens y una salida de 64 000 tokens por llamada, y Amazon DynamoDB utiliza la facturación bajo demanda que se ajusta automáticamente a los patrones de tráfico. El sistema utiliza el procesamiento paralelo para aumentar la velocidad. El agente analizador realiza 5 llamadas simultáneas de Bedrock para analizar fragmentos de código (ThreadPoolExecutor con max_workers=5), mientras que el agente generador procesa los fragmentos en paralelo con 5 trabajadores simultáneos. Un mecanismo de continuación gestiona las respuestas incompletas reintentando automáticamente las solicitudes. La limitación de velocidad (5 solicitudes cada 60 segundos por usuario) evita que las llamadas excesivas a la API de Bedrock generen costos.

La optimización de costes incluye la TTL-based limpieza, que elimina los patrones que tienen más de 90 días, las consultas de claves compuestas con begins_with () para realizar búsquedas instantáneas sin necesidad de escanear las tablas, y BatchWriteItem las operaciones que reducen las operaciones de escritura de DynamoDB en aproximadamente un 90%. El rendimiento depende del tamaño de la función, las funciones pequeñas (menos de 10 archivos) generan 10 casos de prueba en 30 a 60 segundos, las funciones medianas (10 a 50 archivos) tardan de 1 a 3 minutos y las funciones grandes (más de 50 archivos) tardan de 3 a 5 minutos, aunque el uso de filtros de destino para centrarse en secciones de código específicas reduce el tiempo entre un 50 y un 70%.

Tools (Herramientas)

Servicios de AWS

  • Amazon Bedrock: proporciona capacidades de inteligencia artificial generativa a través del Anthropic Claude Sonnet 4 para el análisis de código, la generación de pruebas, la validación y el resumen de rechazos. Utiliza siempre la región us-east-1 para acceder a los modelos.

  • Amazon Bedrock AgentCore : proporciona un tiempo de ejecución de agentes sin servidor para implementar y alojar el backend de generación de pruebas con escalado, OAuth-based autorización y observabilidad automáticos. CloudWatch

  • Amazon Bedrock Guardrails: ofrece filtros de ML-based seguridad en todas las llamadas a la API de Bedrock, lo que incluye la detección inmediata de ataques (alta potencia), el filtrado de contenido, la anonimización de la PII (correo electrónico, teléfono, nombre), el bloqueo de los keys/private keys/JWT tokens de acceso a AWS y la denegación de la aplicación de temas (generación de código de explotación, salida de código fuente sin procesar). Se implementa mediante. CloudFormation

  • AWS CloudFormation: automatiza el aprovisionamiento completo de la infraestructura, incluida la tabla de DynamoDB, el grupo de usuarios de Cognito, Amazon Bedrock Guardrail con control de versiones y la función de ejecución de IAM para. AgentCore

  • Amazon Cognito: proporciona autenticación de usuarios con registro por correo electrónico, emisión de tokens de JWT y autorización segura de API para el backend. AgentCore

  • Amazon DynamoDB: almacena los patrones de prueba aceptados y rechazados junto con las estadísticas de uso para el aprendizaje y la mejora continuos. Utiliza claves compuestas (function_target, pattern_sk) para las consultas sin necesidad de escanear y para almacenar patrones específicos para cada destino.

  • AWS Lambda: fuente del código de función para su análisis, la API recupera el código y la configuración. GetFunction La herramienta es compatible con los tiempos de ejecución de Python Node.js, Java, .NET y Ruby.

Otras herramientas

  • Python 3.11+: entorno de ejecución para la orquestación de aplicaciones y agentes.

  • Streamlit: interfaz Web-based de usuario para la autenticación, la generación de pruebas, la recopilación de comentarios y la supervisión del estado del sistema.

  • Boto3: el SDK de AWS para Python permite interactuar con los servicios de Lambda, Amazon Bedrock, DynamoDB y Cognito.

Repositorio de código

El código de este patrón está disponible en Github: Lambda Test Event Generator. https://github.com/aws-samples/sample-lambda-test-event-generator

Prácticas recomendadas

Este patrón implementa las siguientes prácticas recomendadas:

  • Utiliza políticas de IAM con privilegios mínimos para el acceso a AWS Lambda (solo lectura), Amazon Bedrock (invocación), Amazon DynamoDB () y Amazon Cognito (autenticación). query/write

  • Implemente el aprendizaje de patrones específicos para cada objetivo con un respaldo global para mejorar la precisión de las pruebas.

  • Habilite DynamoDB TTL para eliminar automáticamente los patrones antiguos (90 días) a fin de controlar los costos de almacenamiento.

  • Utilice consultas de escaneo cero con claves compuestas (function_target, pattern_sk) para recuperar patrones rápidamente.

  • Aplica patrones de omisión para excluir del análisis los archivos de prueba, las dependencias y los archivos que no son de código.

  • Utilice la fragmentación de código en varios idiomas con el análisis del árbol de sintaxis abstracta (AST) (Python) y los patrones de expresiones regulares (Java, C#, JS, Ruby).

  • Almacene los patrones con valores reales (no solo con la estructura) para lograr una verdadera deduplicación.

  • Implemente el backend en Amazon Bedrock AgentCore para lograr una infraestructura gestionada y de escalado sin servidores.

  • Autentique a los usuarios mediante Amazon Cognito validando el token de JWT en cada solicitud de API.

  • Aplica Amazon Bedrock Guardrails en todas las llamadas de Converse () para filtrar rápidamente los ataques, redactar la PII y bloquear datos confidenciales (claves de AWS, claves privadas, JWT) y denegar la aplicación de temas.

  • Desinfecte los resultados del análisis antes de devolverlos a los usuarios: todos los fragmentos de código fuente sin procesar se eliminan de las respuestas, lo que garantiza que el código fuente de Lambda nunca supere el límite de tiempo de ejecución. AgentCore

  • Valide todas las entradas de la API con patrones de expresiones regulares y límites de longitud (nombre de la función como máximo 170 caracteres, instrucciones personalizadas como máximo 2000 caracteres, máximo 50 patrones de omisión) para evitar la inyección y el abuso.

  • Implemente un límite de frecuencia por usuario (5 solicitudes cada 60 segundos) para evitar que las llamadas excesivas a la API de Bedrock supongan un abuso de costes.

  • Elimine los mensajes de error antes de enviarlos a los usuarios: las rutas de los archivos internos, los detalles del SDK de AWS y la información de la infraestructura nunca se exponen en las respuestas de error.

Tenga en cuenta las siguientes prácticas recomendadas adicionales:

  • Da tu opinión sobre los motivos específicos cuando rechaces los casos de prueba para mejorar la precisión del aprendizaje.

  • Genere pruebas de forma iterativa (2 a 3 veces) para la misma función a fin de permitir que el sistema aprenda y mejore.

  • Proporcione instrucciones personalizadas cuando necesite escenarios de prueba o formatos de datos específicos.

  • Habilite IAM Access Analyzer para supervisar los permisos de los recursos e identificar los accesos no deseados.

  • Comience con pequeñas funciones de Lambda para comprender el sistema antes de analizar bases de código grandes.

  • Revisa las políticas de IAM con regularidad y elimina los permisos no utilizados.

  • Utilice políticas de contraseñas seguras y habilite Cognito AdvancedSecurityMode para la detección de amenazas.

Epics

TareaDescripciónHabilidades requeridas

Clonar el repositorio.

Clona el GitHub repositorio en tu sistema local y navega hasta el directorio del proyecto:

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

cd sample-lambda-test-event-generator

Este repositorio contiene la aplicación, la CloudFormation plantilla y los archivos de configuración de Python.

Desarrollador de aplicaciones

Configure las credenciales de AWS.

Configure sus credenciales de AWS para permitir que la CLI de AWS interactúe con su cuenta de AWS y para que la aplicación acceda a las funciones de Lambda que desea probar.

Puede hacerlo mediante el comando de configuración de la CLI de AWS:

aws configure

Cuando se le pida, proporcione la siguiente información:

  • ID de clave de acceso a AWS: su clave de acceso a AWS

  • Clave de acceso secreta de AWS: su clave de acceso secreta de AWS

  • Nombre de región predeterminado: la región de AWS en la que desea implementar los recursos (p. ej.,us-east-1)

  • Formato de salida predeterminado: el formato de salida preferido (p. ej.,json)

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Implemente la infraestructura utilizando CloudFormation.

  1. Implemente la infraestructura de backend completa (funciones de DynamoDB, Cognito e IAM) mediante la plantilla proporcionada. CloudFormation Ejecute el siguiente comando en la 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. Espere a que se complete el despliegue de la pila:

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

  3. Recupera todas las salidas:

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

Qué se crea:

  • Tabla de DynamoDB con TTL habilitado, recuperación puntual y cifrado del lado del servidor.

  • Grupo de usuarios de Cognito con autenticación por correo electrónico, FORCED, MFA opcional ( AdvancedSecurityMode TOTP) y creación de usuarios solo para administradores.

  • Amazon Bedrock Guardrail con filtrado rápido de ataques, redacción de PII, filtrado de contenido y bloqueo de temas denegados.

  • Función de ejecución de IAM para políticas AgentCore con privilegios mínimos, incluida la base: el permiso. ApplyGuardrail

nota

La pila crea todos los recursos necesarios. Asegúrese de que la CloudFormation plantilla se complete correctamente antes de continuar con el siguiente paso.

Desarrollador de aplicaciones

Exporte las variables de configuración.

Exporte todos los valores de las salidas de la CloudFormation pila como variables de entorno:

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)

Estas variables se utilizan en los pasos siguientes para la AgentCore configuración y la creación del archivo.env.

Administrador de AWS
TareaDescripciónHabilidades requeridas

Cree un entorno virtual.

  1. Cree y active un entorno virtual de Python para aislar las dependencias del proyecto:

    python3 -m venv venv

source venv/bin/activate

  2. Instale los paquetes de Python necesarios desde el archivo de requisitos:

    pip install -r requirements.txt

    De este modo, se instalan todas las bibliotecas necesarias, incluidas boto3 para el SDK de AWS, python-dotenv para la configuración del entorno, bedrock-agentcore-runtime para la integración y Streamlit para la interfaz de usuario. AgentCore

    nota

    El entorno virtual debe activarse (utilizando) cada vez que abra una nueva sesión de terminal para ejecutar la aplicación. source venv/bin/activate

Desarrollador de aplicaciones

Configurar e implementar AgentCore.

  • Configure el AgentCore agente:

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

  • Cuando se le solicite:

    1. Tipo de implementación: 1 (implementación directa de código, no se necesita Docker)

    2. Versión de Python: 2 (PYTHON_3_11 o seleccione su versión de Python en particular)

    3. Bucket S3: pulsa Entrar (creación automática)

    4. Autorizador de OAuth: sí

    5. URL de descubrimiento: pegue el valor $DISCOVERY_URL

    6. ID de cliente: pegue el valor $CLIENT_ID

    7. Público: presione Entrar (déjelo vacío)

    8. Ámbitos: Pulse Entrar (dejar en blanco)

    9. Reclamaciones personalizadas: pulsa Entrar (deja en blanco)

    10. Encabezados de solicitud: sí

    11. Encabezados: Autorización

    12. Memoria: s (omitir: usar DynamoDB)

  • Despliegue el 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

  • Obtenga el ID AgentCore de tiempo de ejecución y el punto final:

    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"
Desarrollador de aplicaciones

Cree un archivo.env para el desarrollo local.

Cree un archivo.env en el directorio raíz del proyecto con todos los valores de configuración:

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

Pruebe la conectividad con los servicios de AWS:

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

Ambos comandos deberían arrojar respuestas correctas. Si se producen errores de permisos, compruebe que las políticas de IAM estén configuradas correctamente.

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Cree un nuevo usuario de Cognito.

Por motivos de seguridad, el grupo de usuarios de Cognito está configurado para que solo los administradores puedan crear usuarios, por lo que los usuarios no pueden registrarse automáticamente. Cree un usuario mediante la CLI de AWS con el ID del grupo de Cognito y el ID de cliente exportados desde los resultados de la pila. CloudFormation Cree un usuario nuevo (sustitúyalo por user@example.com su correo electrónico):

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

Establezca una contraseña permanente (8 caracteres como mínimo, debe incluir mayúsculas, minúsculas y un número):

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 estas credenciales para iniciar sesión a través de la interfaz de usuario de Streamlit en el siguiente paso.

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Inicie Streamlit UI.

Iniciar la aplicación:

streamlit run app.py

La interfaz de usuario se abrirá en tu navegador predeterminado en http://localhost:8501

Inicia sesión con las credenciales creadas en el paso anterior

Desarrollador de aplicaciones

Configure las opciones de generación

En la interfaz de usuario, configure las siguientes opciones:

  1. Nombre o ARN de la función Lambda: introduzca el identificador de la función Lambda de destino

  2. Filtro de destino (opcional): especifique una función, clase o archivo en el que centrarse (por ejemplo,,validate_user) UserService auth.py

  3. Ignorar patrones (opcional): añada patrones de archivos o carpetas para excluirlos, uno por línea:

    • tests/- Ignorar el directorio de pruebas

    • *.test.js- Ignora los archivos de prueba

    • mock_data/- Ignore los datos simulados

  4. Instrucciones personalizadas (opcionales): añada requisitos de prueba específicos

Desarrollador de aplicaciones

Genere casos de prueba.

Haga clic en el botón «Generar casos de prueba». El sistema hará lo siguiente:

  1. Autentica AgentCore con el token JWT de Cognito.

  2. Obtenga código Lambda de AWS.

  3. Aplica patrones de omisión para excluir archivos no deseados.

  4. Fragmenta el código utilizando estrategias específicas para cada idioma.

  5. Aplica el filtro de destino si se especifica.

  6. Analice el código con Amazon Bedrock.

  7. Consulte DynamoDB para ver los patrones aprendidos.

  8. Genere casos de prueba.

  9. Valide y clasifique los casos de prueba.

Desarrollador de aplicaciones

Revise las pruebas generadas.

Revise cada caso de prueba generado, que incluye:

  • Tipo: positivo (entradas válidas), negativo (entradas no válidas) o perimetral (condiciones límite)

  • Descripción: Qué valida la prueba

  • Datos de prueba: la carga útil real del evento de prueba

DevOps ingeniero, desarrollador de aplicaciones

Proporcione comentarios.

Para cada caso de prueba, envía tus comentarios:

Para aceptar un caso de prueba:

  • Haz clic en el botón «Aceptar»

Para rechazar un caso de prueba:

  1. Haz clic en el botón «Rechazar»

  2. Selecciona un motivo de rechazo en el menú desplegable o añade un motivo personalizado

  3. Haz clic en el botón «Enviar rechazo»

Ingeniero de pruebas

Guarda los comentarios en la memoria.

Tras revisar todos los casos de prueba:

  1. Haga clic en el botón «Guardar todos los comentarios en la memoria»

  2. El sistema valida que todos los casos rechazados hayan presentado sus motivos

  3. Los comentarios se envían a la AgentCore API, que se dirige al agente validador.

  4. Los comentarios se almacenan por lotes en DynamoDB con un hash de patrón para la deduplicación.

  5. Vea el resumen de comentarios que muestra los recuentos accepted/rejected

Ingeniero de pruebas

Repite para mejorar.

Genere pruebas de 2 a 3 veces más para la misma función a fin de mejorar la calidad:

  • El sistema recupera los patrones aprendidos de DynamoDB

  • La calidad mejora con cada iteración en función de sus comentarios

  • Usa el filtro de destino para realizar pruebas específicas en componentes específicos

  • Utilice patrones de omisión para excluir el código irrelevante y mejorar la calidad de la generación

nota

El sistema de aprendizaje se vuelve más efectivo con el uso repetido. Cada ciclo de comentarios ayuda a la IA a entender tus preferencias de prueba y a generar casos de prueba más relevantes para tus funciones de Lambda.

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Invoca la AgentCore API directamente.

Para la automatización y la integración, invoca el AgentCore backend directamente mediante llamadas a la API con la autenticación de Cognito.

Consigue un token de Cognito:

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

Invoca la generación de pruebas:

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}'
Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Supervise los patrones de DynamoDB y realice un seguimiento de los costos.

  1. Consulte la tabla de DynamoDB para revisar los patrones aceptados y comprender lo que ha aprendido el 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-functionSustitúyalo por el nombre real de su función de Lambda para ver los patrones específicos de esa función.

  2. Realice un seguimiento del consumo de recursos para optimizar los costos:

    • AWS Cost Explorer: supervise el gasto total en los servicios de Bedrock, DynamoDB y Lambda

    • Amazon Bedrock: revise el uso de los tokens y las métricas de llamadas a la API en la consola de Bedrock

    • DynamoDB: compruebe las métricas de las solicitudes, la capacidad consumida y el uso del almacenamiento.

    • AgentCore: Supervise las métricas de tiempo de ejecución de los agentes y los recuentos de invocaciones en CloudWatch

  3. Utilice CloudWatch los registros para diagnosticar problemas y supervisar el comportamiento del sistema:

    • AgentCore registros: 

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

    • Errores de aplicación: revise los errores y excepciones a nivel de aplicación

    • Respuestas de la API de Bedrock: analice las respuestas del modelo de IA y el consumo de tokens

    • Operaciones de DynamoDB: supervise los read/write patrones y los eventos de limitación

nota

La supervisión regular ayuda a identificar las oportunidades de optimización de costos y garantiza que el sistema siga aprendiendo de manera eficaz. La configuración de TTL de su tabla de DynamoDB elimina automáticamente los patrones antiguos, lo que ayuda a administrar los costos de almacenamiento a lo largo del tiempo.

Administrador de AWS
TareaDescripciónHabilidades requeridas

Elimine los recursos desplegados.

Para eliminar todos los recursos desplegados:

Elimine el AgentCore agente:

agentcore destroy

Elimine la CloudFormation pila (elimina la tabla de DynamoDB, el grupo de usuarios de Cognito y la función de IAM):

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

Resolución de problemas

ProblemaSolución

Error de «acceso denegado» al recuperar el código Lambda

  • Verifique que los permisos de IAM incluyan lambda:GetFunction y lambda:GetFunctionConfiguration para la función Lambda de destino

  • Compruebe sus credenciales de la CLI de AWS

    aws sts get-caller-identity

«Errores de escritura en DynamoDB»

  • Compruebe que el nombre de la tabla del .env archivo coincide con el nombre de la tabla implementada

  • Compruebe CloudFormation las salidas:

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

  • O verifique directamente:

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

No se generaron casos de prueba

Posibles causas y soluciones:

  • No se puede acceder al código de función de Lambda: compruebe los permisos de IAM para acceder a Lambda

  • El paquete de implementación de Lambda solo contiene código compilado: .class .dll los archivos sin archivos fuente no se pueden analizar

  • Todos los archivos filtrados por patrones de ignoración: revise y ajuste sus patrones de ignoración

  • Las instrucciones personalizadas son demasiado restrictivas: simplifica o elimina las instrucciones personalizadas

  • Compruebe que la función Lambda existe:

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

Java/C# Lambda muestra el mensaje «No se encontró ningún código fuente»

Las Lambdas de Java y C# requieren archivos fuente en el paquete de implementación:

Java (Maven):

  1. Agregue la configuración de inclusión de código fuente a pom.xml (consultedocs/JAVA_SETUP.md)

  2. Reconstruya y vuelva a implementar la función de Lambda

C# (.NET):

  1. Incluya .cs archivos en la configuración de compilación (consultedocs/CSHARP_SETUP.md)

  2. Reconstruya y vuelva a implementar la función de Lambda

Errores de escritura en DynamoDB

  • Compruebe los permisos de DynamoDB y el estado de la tabla:

  • Verifique que la política de IAM incluya y dynamodb:PutItem dynamodb:BatchWriteItem

  • Compruebe el estado de la tabla: 

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

    El nombre de la tabla incluye el sufijo del nombre de la pila. Usa el valor de tus CloudFormation salidas o del archivo.env.

  • Habilite CloudWatch los registros de DynamoDB para ver los mensajes de error detallados

Generación lenta de pruebas

Optimice la velocidad de generación:

  1. Utilice el filtro de destino para centrarse en funciones específicas (50-70% más rápido)

  2. Agregue patrones de omisión para excluir los archivos de prueba, las dependencias y el código irrelevante

  3. Reduzca el tamaño del código filtrando los archivos innecesarios antes del análisis

AgentCore: «No se encontró el agente»

Verifique que el agente esté desplegado:

agentcore status

agentcore configure list

AgentCore: «Permiso denegado» en tiempo de ejecución

Verifique que el rol de ejecución tenga las políticas correctas:

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

Cognito: «Nombre de usuario o contraseña no válidos»

Compruebe que sus credenciales son correctas. Puede crear un nuevo usuario mediante el flujo «Crear cuenta» de la interfaz de usuario de Streamlit o mediante la CLI de 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

En los registros aparece la advertencia «Bedrock Guardrail no está configurado»

Las variables de verificación BEDROCK_GUARDRAIL_ID y BEDROCK_GUARDRAIL_VERSION entorno están configuradas en la implementación. AgentCore

Compruebe CloudFormation los resultados: 

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

Error «Se ha superado el límite de velocidad»

El sistema se limita a 5 solicitudes cada 60 segundos por usuario. Espere el tiempo indicado antes de volver a intentarlo. Para un uso en producción con necesidades de mayor rendimiento, realice los ajustes RATE_LIMIT_MAX_REQUESTS y las RATE_LIMIT_WINDOW constantes en main.py.

Recursos relacionados

Documentación de AWS