Technische Samenvatting: Continue Generatie van Testgevallen voor Large Language Models met Projectgeheugen

1. Probleemstelling

In grootschalige softwaresystemen die onderhevig zijn aan agile iteraties en continuous delivery, is het handhaven van effectieve testdekking een uitdaging vanwege evoluerende eisen, interface-updates en terugkerende defecten. Conventionele automatische testscripts en standaard Large Language Model (LLM) benaderingen falen vaak in het effectief hergebruiken van historische foutgegevens of het dekken van opkomende risico's. Bestaande literatuur wijst op specifieke beperkingen:

• Contexttekorten: Standaard LLM's worstelen met instabiele asserties en een gebrek aan context [1].
• Stagnatie van de dekking: Pre-trained modellen kunnen zoekgebaseerde tests verbeteren, maar kampen nog steeds met plateaus in de dekking [2].
• Verwaarlozing van historie: Benaderingen die de dekking verbeteren, slagen er vaak niet in om projectniveau historische defecten voldoende te hergebruiken [3].
• Strategische disbalans: Single-generatie strategieën worstelen met het balanceren van dekking versus het vermogen om defecten te triggeren [4].
• Geheugengaten: Toepassingen van LLM's binnen Test-Driven Development (TDD) missen vaak mechanismen voor langetermijngeheugen van versie-evolutie [5].

Het kernproblein wordt gedefinieerd als een Constrained Risk Coverage Optimization Task in Version Evolution, waarbij het doel is om een optimale set testgevallen te selecteren die de gewogen dekking van gewijzigde businesspaden en historische defect-triggers maximaliseert, terwijl ongeldige gevallen en semantische duplicatie worden geminimaliseerd.

2. Methodologie

De voorgestelde oplossing introduceert een Project Memory framework, waarbij geheugen niet wordt behandeld als een eenvoudige Retrieval-Augmented Generation (RAG) appendix, maar als een release-evoluerende controlegelaag. De methodologie bestaat uit drie primaire fasen:

2.1 Constructie van de Project Memory Knowledge Base

Het systeem aggregeert multi-source testactiva op event-granulariteit, waarbij het het volgende integreert:

• Databronnen: Vereisten-documenten, interface-beschrijvingen (OpenAPI), code commits, issue/defect rapporten en bestaande testscripts.
• Data Cleaning: Verwijdering van template tekst en ongeldige logs; conversie van gevoelige gegevens (bijv. ordernummers, SKU's) naar onomkeerbare tokens of generieke placeholders.
• Semantische Segmentatie: Data wordt getagd door release_id, business_path_id, api_chain, state_pair, risk_tag en trigger_condition.
• Vectorisatie: Een heterogene geheugentoestand-vector wordt geconstrueerd met behulp van een HNSW-index. De vector $\mathbf{m}_i$ voor een geheemeneenheid is een gewogen fusie van:
  • Semantische embedding ($\mathbf{e}_{sem}$)
  • Type embedding (vereisten, interface, defect, script)
  • Versie embedding
  • Risicolabel embedding
  • Gewichten: $\alpha=0.45$ (semantisch), $\beta=0.15$ (type), $\gamma=0.15$ (versie), $\delta=0.25$ (risico).

2.2 Incrementeel Geheugen Update Mechanisme

Geheugen evolueert op basis van commits, interface-wijzigingen of defect-transities. Een Diff Parser extraheert wijzigingen, en als een drempelwaarde (0.35) wordt overschreden, wordt het geheugen geversioneerd; anders worden de gewichten bijgewerkt. De formule voor gewichtsuitwerking incorporeert:

• Historische retentiecoëfficiënt ($\eta = 0.72$)
• Defect-recurrente frequentie
• Business risiconiveau
• Semantische gelijkenis met huidige wijzigingen
• Versie afstand-decay

2.3 Generatieve Pipeline

Het generatieproces maakt gebruik van Llama3.1-70B-Instruct, geleid door de volgende stappen:

1. Risico-gerelateerde Geheugen Retrieval: Een query-vector wordt opgebouwd uit verzoekwijzigingen en API diffs. HNSW haalt de top-50 geheemeneenheden op, die vervolgens opnieuw worden gerankt door een risk-feedback controller gebaseerd op defect-recurrence, pad-belangrijkheid en versie-afstand.
2. Prompt Constructie: De top-12 risico-geheugens, huidige interface diffs en historische failure assertions worden geformatteerd in JSON-fragmenten. De prompt bevat velden voor Scenario, API Chain, Preconditions, Input Boundaries, Risk Memory, Expected Assertions en Negative Cases.
3. Generatie & Validatie: Het model genereert kandidaten met beperkte parameters (Temperature=0.2, Top-p=0.85).
4. Deduplicatie & Consistentie Check: Gegenereerde gevallen ondergaan:
   • Semantische Deduplicatie: Gebruikmakend van Sentence-BERT met een 0.86 cosine similarity drempelwaarde.
   • Assertion & State Verificatie: Controleren op nieuwe boundary waarden of exception branches.
   • Schema & State Machine Validatie: Waarborgen van OpenAPI conformiteit en geldige state transities (bijv. het voorkomen van Paid $\to$ Created).

3. Belangrijkste Bijdragen

• Geversioneerde Heterogene Geheugen Modellering: Het gaat verder dan statische RAG door een dynamisch geheugensysteem dat versie-evolutie en risico volgt.
• Defect-Trigger Feedback: Een mechanisme dat geheugen retrieval weegt op basis van historische defect-recurrence en business risico.
• Risico-bewuste Context Selectie: Een re-ranking strategie die defect-rijke paden prioriteert boven normale flows.
• Semantische Deduplicatie met Boundary Preservatie: Een filteringsproces dat redundante gevallen verwijdert terwijl kritieke boundary variaties en exception branches behouden blijven.
• State-Consistentie Verificatie: Validatiemodules die garanderen dat gegenereerde testgevallen voldoen aan geldige state transities en schema-restricties.

4. Experimentele Resultaten

De methode werd geëvalueerd op een real-world E-commerce Order Systeem met 214 backend API's, meer dan 9.600 historische scripts en 3.180 historische defecten over een cyclus van 14 maanden.

Prestatie Metrics (vs. No-Memory Prompting):

• Effectieve Test Case Rate: Bereikte 88.7% (±1.1%), vergeleken met 28.1% voor non-memory prompting.
• Reductie van Duplicatie: Verminderde duplicatie met 8.9% (±0.7%).
• High-Risk Path Coverage: Bereikte 91.3%.
• Defect Discovery: Identificeerde 61 defecten, een verbetering van 19.6% ten opzichte van de no-memory baseline (51 defecten).

Vergelijkende Analyse:

• De voorgestelde methode presteerde beter dan baselines inclusief plain RAG, CODAMOSA, CAT-LM, regel templates en menselijke aanvullende testen.
• Ablatie Studies: Het verwijderen van projectgeheugen liet de efficiëntie dalen naar 66.1% en de high-risk dekking naar 73.4%. Het verwijderen van risk re-ranking verlaagde de dekking naar 82.1%. Het verwijderen van deduplicatie verhoogde de duplicatie naar 21.4%.
• Model Grootte: Hoewel het 70B model superieure prestaties toonde in long call-chain reasoning en assertion repair, bleven kleinere modellen (Llama3.1-8B, Qwen2.5-14B) competitief (respectievelijk 80.4% en 83.6%), wat suggereert dat het framework niet volledig afhankelijk is van enorme parameter-aantallen.

5. Betekenis en Claims

Het artikel claimt dat Project Memory het vermogen van een LLM aanzienlijk verbetert om langetermijn business regels, cross-interface afhankelijkheden en historische foutpatronen te begrijpen. Door geheugen te behanden als een release-evoluerende controlegelaag in plaats van een statische appendix, adresseert de aanpak succesvol de "stagnatie" van testdekking in continuous delivery omgevingen.

De auteurs merken op dat de methode bijzonder effectief is bij het detecteren van regressie-gevoelige fouten, zoals cross-interface rollbacks, coupon recovery issues, idempotency violations en field mismatch problemen bij hernoeming.

Erkende Beperkingen:
De aanpak leunt op de beschikbaarheid van uitgebreide bug records, duidelijke interface patronen en een specifieke backend architectuur (e-commerce order systeem). De auteurs waarschuwen dat slechte documentatie of complexe architecturen de geheugen recall en portabiliteit kunnen verminderen. Het framework wordt gepresenteerd als een specifieke oplossing voor continue test case generatie in evoluerende softwaresystemen, waarbij geanonimiseerde data en scripts worden verstrekt voor daaropvolgende validatie.