Technische Samenvatting: E-Test: E'er-improving Test Suites

Probleemstelling

Testsuites zijn inherent imperfect en vereisen voortdurende verrijking om de betrouwbaarheid van software te handhaven. Hoewel testers in theorie nieuwe testgevallen kunnen toevoegen om onverkende executiescenario's te dekken, is het identificeren van deze scenario's — met name die voortkomen uit productgebruik — arbeidsintensief en uitdagend, vooral voor grote, langdurige softwaresystemen. Bestaande benaderingen, zoals regressietesten (die zich richten op het selecteren of prioriteren van bestaande tests) en veldtesten (die software in productie uitvoeren), pakken de kloof tussen de executieruimte die door een testsuite wordt gedekt en de werkelijke executies die in productie worden ervaren, niet volledig aan. Het simpelweg toevoegen van alle geobserveerde productiescenario's aan een testsuite is onpraktisch, omdat dit leidt tot een onbeheersbare explosie in de grootte van de suite. De kernuitdaging is om efficiënt door enorme sets productiescenario's te zeven om te identificeren welke echt "need-test" (onbedekt maar correct) of "error-prone" (onbedekt en falend) zijn, zonder de prohibitieve kosten van het uitvoeren van alle bestaande testgevallen tegen elk nieuw scenario.

Methodologie: E-Test

De auteurs stellen E-Test voor, een benadering die is ontworpen om "e'er-improving" testsuites te creëren die automatisch groeien door nieuwe testgevallen te integreren die afgeleid zijn van productiedata. E-Test werkt door executiescenario's te classificeren in drie categorieën ten opzichte van een bestaande testsuite:

1. Already-tested: De input is equivalent aan een bestaand testgeval (dezelfde partitie).
2. Need-test: De input is niet equivalent aan een bestaande test, de executie slaagt, en het dekt nieuw codegedrag.
3. Error-prone: De input is niet equivalent aan een bestaande test, en de executie faalt (onthult een bug).

E-Test vermijdt de onpraktische uitvoering van alle testgevallen door gebruik te maken van Large Language Models (LLMs) om deze classificatie uit te voeren. Het systeem bestaat uit drie hoofdfasen:

1. PreProcessor

Deze fase construeert een gestructureerde prompt voor de LLM. Het extraheert drie kerncomponenten uit een executiescenario:

• MUT (Method Under Test): De broncode van de methode en de sterk gerelateerde methoden (beperkt tot ~3K tokens).
• MUT Tests: De bestaande testsuite voor de methode (beperkt tot ~4K tokens).
• MUT Input: De specifieke inputparameters en de omliggende contextcode (beperkt tot ~1K tokens).

De PreProcessor instantieert vervolgens een prompttemplate die vijf specifieke queries bevat, ontworpen om de kenmerken van het scenario te beoordelen:

• Q1: Is de input vergelijkbaar met bestaande tests?
• Q2: Dekt de input meer regels of vertakkingen (branches) dan bestaande tests?
• Q3: Zal de methode anders reageren onder deze input?
• Q4: Zal de methode correcte resultaten produceren?
• Q5: Zal de input een bug onthullen?

2. Analyzer

De Analyzer bevraagt een LLM met de geconstrueerde prompt. Om de prestaties te verbeteren, maakt E-Test gebruik van drie specifieke technieken:

• Fine-tuning: De LLM (specifiek GPT-3.5 Turbo in de experimenten) is gefinetuned op een dataset van gelabelde scenario's (already-tested, need-test, error-prone) om de nauwkeurigheid van de classificatie te verbeteren.
• Retrieval-Augmented Generation (RAG): Om de beperkingen van het contextvenster bij grote codebases te overwinnen, wordt RAG gebruikt om relevante codefragmenten gerelateerd aan de prompt op te halen en in te bedden, waardoor deze context aan de LLM wordt gevoed.
• Few-shot Learning: Vaste voorbeelden van elk scenario type worden in de prompt opgenomen om het model te begeleiden.

3. PostProcessor

De PostProcessor aggregeert de antwoorden van de LLM op de vijf queries. Een "Voter"-mechanisme classificeert het scenario op basis van het patroon van Ja/Nee-antwoorden dat het beste overeenkomt met de verwachte waarheidstabel voor elke categorie (bijv. een error-prone scenario wordt verwacht "Nee" te antwoorden op gelijkenis, "Ja" op verschil in dekking, "Ja" op verschillend gedrag, "Néé" op correctheid en "Ja" op het onthullen van een bug). Gelijkspel wordt opgelost door prioriteit te geven aan error-prone > need-test > already-tested om robuustheid te garanderen. Voor scenario's geclassificeerd als need-test of error-prone, genereert een Test Case Generator automatisch JUnit-testgevallen door het gesprek met de LLM voort te zetten.

Belangrijkste Bijdragen

Het artikel levert de volgende bijdragen aan de stand van zaken in softwaretesten:

• Conceptueel Kader: Het introduceert het concept van "e'er-improving testsuites", wat de focus verschuift van statische instandhouding naar continue, geautomatiseerde verrijking op basis van productiedata.
• E-Test Benadering: Het definieert een nieuwe benadering die LLM's, prompt engineering, fine-tuning en RAG combineert om executiescenario's te classificeren zonder de volledige testsuite uit te voeren.
• Dataset Creatie: Het biedt een dataset van 1.975 executiescenario's afkomstig van Defects4J en vier hoog gewaardeerde open-source Java-projecten (Spring Boot, Apache ShardingSphere, Apache Dolphinscheduler, Micrometer), gecategoriseerd in de drie doelklassen.
• Testgeneratie: Het presenteert een mechanisme om automatisch JUnit-testgevallen te genereren uit geïdentificeerde scenario's en evalueert hun vermogen om fouten te onthullen.

Experimentele Resultaten

De evaluatie werd uitgevoerd op de dataset van 1.975 scenario's, waarbij E-Test werd vergeleken met state-of-the-art regressietesten (FAST++) en veldtesten (field-ready testing) benaderingen, evenals vanilla LLM's.

• Classificatieprestaties: E-Test behaalde een gemiddelde F1-score van 0,55. Dit presteert aanzienlijk beter dan:
  • State-of-the-art regressietesten (FAST++): F1-score van 0,34 (61,8% relatieve verbetering).
  • Field-ready testing: F1-score van 0,30 (83,3% relatieve verbetering).
  • Vanilla LLM's (zonder fine-tuning of RAG): Maximale F1-score van 0,39.
  • Random classifier: F1-score van 0,33.
• Impact van Fine-tuning: Fine-tuning van GPT-3.5 Turbo was cruciaal, waarbij de totale gemiddelde F1-score met 80% verbeterde ten opzichte van de baseline random classifier.
• Impact van RAG: RAG leverde marginale verbeteringen voor algemene gevallen, maar toonde een significant voordeel (12% F1-score winst) specifief voor scenario's met zeer grote testsuites (>16K tokens) waar de contextlimieten worden overschreden.
• Testgeneratie: Voor Defects4J-bugs genereerde E-Test succesvol testgevallen die fouten onthulden voor 83,2% van de gedocumenteerde fouten. Van de gegenereerde tests waren 99,1% syntactisch correct, 87% compileerbaar en 83,2% triggerm de fout met een gelijke of hogere branch-dekking dan de grondwaarheid.
• Efficiëntie: Er werd vastgesteld dat het bevragen van LLM's aanzienlijk sneller was (0,81–24,97 seconden) dan het direct berekenen van branch-dekking door tests uit te voeren (5,12–168,14 seconden), wat een praktische afweging biedt tussen precisie en kosten.

Betekenis en Claims

De auteurs beweren dat E-Test effectief de kloof overbrugt tussen de executieruimte die door een testsuite wordt verkend en de executies die in productie worden ervaren. Door de identificatie van "need-test" en "error-prone" scenario's te automatiseren, vermindert E-Test de handmatige inspanning die nodig is om testsuites te onderhouden en verhoogt het de betrouwbaarheid van software.

Het artikel benadrukt dat hoewel LLM's alleen (vanilla) onvoldoende zijn voor deze specifieke taak, een zorgvuldig ontworpen pijplijn bestaande uit fine-tuning, gestructureerde prompting en contextretrieval (RAG) prestatieniveaus kan bereiken die de huidige state-of-the-art technieken overtreffen. De resultaten suggereren dat E-Test een levensvatbare component kan zijn voor langdurige softwareproducten, waardoor testsuites continu kunnen evolueren naast productiedata zonder combinatorische explosie. De auteurs merken op dat de benadering momenteel is geïnstantieerd voor unit testing, maar dat zij beogen uit te breiden naar integratie- en systeemtesten door problemen met contextkwaliteit en schaalbaarheid aan te pakken.