Resumen Técnico: Generación Continua de Casos de Prueba para Modelos de Lenguaje Grande con Memoria de Proyecto

1. Declaración del Problema

En sistemas de software a gran escala que atraviesan iteraciones ágiles y entrega continua, mantener una cobertura de pruebas efectiva es un desafío debido a la evolución de los requisitos, las actualizaciones de interfaces y los defectos recurrentes. Los scripts de pruebas automáticas convencionales y los enfoques estándar de Modelos de Lenguaje Grande (LLM) suelen fallar al no poder reutilizar eficazmente los datos de fallos históricos o cubrir riesgos emergentes. La literatura existente destaca limitaciones específicas:

• Déficits de Contexto: Los LLM estándar tienen dificultades con las aserciones inestables y la falta de contexto [1].
• Estancamiento de la Cobertura: Los modelos preentrenados pueden mejorar las pruebas basadas en búsqueda, pero siguen enfrentando mesetas de cobertura [2].
• Negligencia Histórica: Los enfoques que mejoran la cobertura suelen fallar al no reutilizar suficientemente los defectos históricos a nivel de proyecto [3].
• Desequilibrio de Estrategia: Las estrategias de generación única luchan por equilibrar la cobertura con la capacidad de activar defectos [4].
• Brechas de Memoria: Las aplicaciones de desarrollo guiado por pruebas (TDD) de los LLM a menudo carecen de mecanismos para la memoria de evolución de versiones a largo plazo [5].

El problema central se define como una Tarea de Optimización de Cobertura de Riesgo Restringida en la Evolución de Versiones, donde el objetivo es seleccionar un conjunto óptimo de casos de prueba que maximice la cobertura ponderada de las rutas de negocio modificadas y los activadores de defectos históricos, minimizando al mismo tiempo los casos inválidos y la duplicidad semántica.

2. Metodología

La solución propuesta introduce un marco de Memoria de Proyecto, tratando la memoria no como un simple apéndice de Generación Aumentada por Recuperación (RAG), sino como una capa de control que evoluciona con cada lanzamiento. La metodología consta de tres etapas principales:

2.1 Construcción de la Base de Conocimientos de la Memoria de Proyecto

El sistema agrega activos de prueba de múltiples fuentes a una granularidad de evento, integrando:

• Fuentes de Datos: Documentos de requisitos, descripciones de interfaces (OpenAPI), commits de código, reportes de problemas/defectos y scripts de prueba existentes.
• Limpieza de Datos: Eliminación de texto de plantillas y logs inválidos; conversión de datos sensibles (p. ej., números de orden, SKUs) en tokens irreversibles o marcadores genéricos.
• Segmentación Semántica: Los datos se etiquetan por release_id, business_path_id, api_chain, state_pair, risk_tag y trigger_condition.
• Representación Vectorizada: Se construye un vector de estado de memoria heterogéneo utilizando un índice HNSW. El vector $\mathbf{m}_i$ para una unidad de memoria es una fusión ponderada de:
  • Embedding semántico ($\mathbf{e}_{sem}$)
  • Embedding de tipo (requisitos, interfaz, defecto, script)
  • Embedding de versión
  • Embedding de etiqueta de riesgo
  • Pesos: $\alpha=0.45$ (semántico), $\beta=0.15$ (tipo), $\gamma=0.15$ (versión), $\delta=0.25$ (riesgo).

2.2 Mecanismo de Actualización Incremental de la Memoria

La memoria evoluciona basándose en commits, cambios de interfaz o transiciones de defectos. Un Analizador de Diferencias (Diff Parser) extrae los cambios y, si se supera un umbral (0.35), la memoria se versiona; de lo contrario, se actualizan los pesos. La fórmula de actualización de pesos incorpora:

• Coeficiente de retención histórica ($\eta = 0.72$)
• Frecuencia de recurrencia de defectos
• Nivel de riesgo de negocio
• Similitud semántica con los cambios actuales
• Decaimiento por distancia de versión

2.3 Pipeline Generativo

El proceso de generación utiliza Llama3.1-70B-Instruct guiado por los siguientes pasos:

1. Recuperación de Memoria Relacionada con el Riesgo: Se construye un vector de consulta a partir de los cambios solicitados y los diffs de la API. HNSW recupera las 50 unidades de memoria superiores, que luego son re-clasificadas por un controlador de retroalimentación de riesgo basado en la recurrencia de defectos, importancia de la ruta y distancia de versión.
2. Construcción de Prompt: Los 12 recuerdos de riesgo superiores, los diffs de la interfaz actual y las aserciones de fallos históricos se formatean en fragmentos JSON. El prompt incluye campos para Escenario, Cadena de API, Precondiciones, Límites de Entrada, Memoria de Riesgo, Aserciones Esperadas y Casos Negativos.
3. Generación y Validación: El modelo genera candidatos con parámetros restringidos (Temperatura=0.2, Top-p=0.85).
4. Deduplicación y Verificación de Consistencia: Los casos generados se someten a:
   • Deduplicación Semántica: Utilizando Sentence-BERT con un umbral de similitud de coseno de 0.86.
   • Verificación de Aserción y Estado: Comprobación de nuevos valores límite o ramas de excepción.
   • Validación de Esquema y Máquina de Estados: Garantizar la conformidad con OpenAPI y transiciones de estado válidas (p. ej., evitar Pagado $\to$ Creado).

3. Contribuciones Clave

• Modelado de Memoria Heterogénea Versionada: Más allá del RAG estático, un sistema de memoria dinámico que rastrea la evolución de la versión y el riesgo.
• Retroalimentación de Activación de Defectos: Un mecanismo que pondera la recuperación de la memoria basándose en la recurrencia de defectos históricos y el riesgo de negocio.
• Selección de Contexto Consciente del Riesgo: Una estrategia de re-clasificación que prioriza las rutas densas en defectos sobre los flujos normales.
• Deduplicación Semántica con Preservación de Límites: Un proceso de filtrado que elimina casos redundantes mientras retiene variaciones críticas de límites y ramas de excepción.
• Verificación de Consistencia de Estado: Módulos de validación que aseguran que los casos de prueba generados se adhieran a las transiciones de estado válidas y las restricciones de esquema.

4. Resultados Experimentales

El método fue evaluado en un Sistema de Órdenes de Comercio Electrónico real que contiene 214 APIs de backend, más de 9,600 scripts históricos y 3,180 defectos históricos durante un ciclo de 14 meses.

Métricas de Rendimiento (vs. Prompting sin Memoria):

• Tasa de Casos de Prueba Efectivos: Alcanzó un 88.7% (±1.1%), comparado con el 28.1% para el prompting sin memoria.
• Reducción de Duplicidad: Redujo la duplicidad en un 8.9% (±0.7%).
• Cobertura de Rutas de Alto Riesgo: Alcanzó un 91.3%.
• Descubrimiento de Defectos: Identificó 61 defectos, una mejora del 19.6% sobre la línea base sin memoria (51 defectos).

Análisis Comparativo:

• El método propuesto superó a las líneas base, incluyendo RAG simple, CODAMOSA, CAT-LM, plantillas de reglas y pruebas suplementarias humanas.
• Estudios de Ablación: Eliminar la memoria de proyecto redujo la eficiencia al 66.1% y la cobertura de alto riesgo al 73.4%. Eliminar la re-clasificación de riesgo bajó la cobertura al 82.1%. Eliminar la deduplicación aumentó la duplicidad al 21.4%.
• Tamaño del Modelo: Aunque el modelo de 70B mostró un rendimiento superior en el razonamiento de cadenas de llamadas largas y reparación de aserciones, los modelos más pequeños (Llama3.1-8B, Qwen2.5-14B) se mantuvieron competitivos (80.4% y 83.6% respectivamente), sugiriendo que el marco no depende enteramente de conteos masivos de parámetros.

5. Significado y Reivindicaciones

El artículo afirma que la Memoria de Proyecto mejora significativamente la capacidad de un LLM para comprender reglas de negocio a largo plazo, dependencias entre interfaces y patrones de fallos históricos. Al tratar la memoria como una capa de control que evoluciona con cada lanzamiento en lugar de un apéndice estático, el enfoque aborda con éxito el "estancamiento" de la cobertura de pruebas en entornos de entrega continua.

Los autores señalan que el método es particularmente efectivo para detectar fallos sensibles a la regresión, como reversiones entre interfaces, problemas de recuperación de cupones, violaciones de idempotencia y desajustes de nombres de campos.

Limitaciones Reconocidas:
El enfoque depende de la disponibilidad de registros de errores exhaustivos, patrones de interfaz claros y una arquitectura de backend específica (sistema de órdenes de comercio electrónico). Los autores advierten que una documentación deficiente o arquitecturas complejas podrían reducir la recuperación de la memoria y la portabilidad. El marco se presenta como una solución específica para la generación continua de casos de prueba en sistemas de software en evolución, con datos y scripts anonimizados proporcionados para validación posterior.