EmbC-Test: How to Speed Up Embedded Software Testing Using LLMs and RAG

Dit paper introduceert EmbC-Test, een RAG-gebaseerde aanpak die de tijd voor het handmatig schrijven van tests voor ingebouwde C-software met tot 66% verkort door automatisch gegenereerde tests te produceren die 100% syntactisch correct zijn en voor 85% slagen in runtime-validatie.

De kern

EmbC-Test: Hoe een slimme assistent het testen van ingebouwde software versnelt

Stel je voor dat je een enorme fabriek hebt waar robots en slimme apparaten worden gebouwd. De software die deze machines aanstuurt (zoals in een tractor of een industriële pomp) moet perfect werken. Als er een foutje in zit, kan dat leiden tot gevaarlijke situaties. Daarom moeten ingenieurs elke regel code grondig testen.

Het probleem? Dit handmatig doen is als het proberen te vullen van een zwembad met een theelepel. Het kost enorm veel tijd, is saai, en als je te snel werkt, maak je fouten.

Dit artikel vertelt over een nieuwe manier om dit proces te versnellen, met behulp van een slimme computerassistent (een 'Large Language Model' of LLM) die wordt geholpen door een slim zoeksysteem (RAG).

Hier is hoe het werkt, vertaald naar alledaagse taal:

1. Het Probleem: De "Dwaze" Computer

Stel je voor dat je een beginnende kok vraagt om een recept te schrijven voor een gerecht dat jij al jaren maakt. Als je de kok niets vertelt over je eigen keuken, je specifieke ingrediënten of je favoriete smaakmakers, zal hij waarschijnlijk iets verzinnen dat er raar uitziet. Hij gebruikt misschien ingrediënten die je niet hebt, of vergeet een stap die cruciaal is voor de smaak.

In de softwarewereld noemen we dit "hallucineren". Een slimme computer kan code schrijven die er perfect uitziet, maar die in werkelijkheid niet werkt of fouten bevat. In de wereld van veiligheidskritische machines (zoals medische apparatuur of auto's) is dit gevaarlijk.

2. De Oplossing: De "Slimme Bibliotheek" (RAG)

De auteurs van dit papier hebben een oplossing bedacht die ze RAG noemen. Je kunt dit vergelijken met het geven van een open boek-examen in plaats van een examen uit je hoofd.

In plaats van de computer te laten raden, geven we hem een slimme bibliotheek (een kennisbank) met precies de juiste informatie:

• De handleidingen van de machine.
• De oude, bewezen recepten (bestaande tests).
• De specifieke regels van de keuken (de code van het bedrijf).

Wanneer de computer een nieuwe test moet schrijven, kijkt hij eerst in deze bibliotheek. Hij zoekt naar de juiste stukjes informatie en gebruikt die om zijn antwoord te bouwen. Hierdoor maakt hij veel minder fouten en blijft hij trouw aan de regels van het bedrijf.

3. Hoe het in de praktijk werkt (De "Snijmachine")

Om de computer de juiste informatie te geven, moeten ze de grote stapels documenten en code eerst in kleine, overzichtelijke stukjes knippen. Dit noemen ze "chunking".

• Slechte manier: Je knipt een tekst willekeurig door midden, waardoor een zin of een zinnetje in tweeën wordt gesneden. De computer raakt de draad kwijt.
• Slimme manier (AST-based): Je knipt de tekst op de natuurlijke grenzen, bijvoorbeeld na een volledige zin of een complete paragraaf. Zo blijft de betekenis intact.

De computer slaat deze stukjes op in een database. Wanneer er een nieuwe test nodig is, zoekt de computer niet alleen op woorden (zoals Google), maar ook op betekenis. Het is alsof je niet alleen zoekt op "rode auto", maar ook op "snel voertuig met rode lak".

4. De Resultaten: Van 1 naar 270 tests per uur

De proeven bij het bedrijf Hydac Software (waar deze technologie is getest) gaven fantastische resultaten:

• Snelheid: Een menselijke ingenieur maakt ongeveer 1 test per uur. Met deze nieuwe assistent kunnen ze 270 tests per uur genereren. Dat is als het verschil tussen het lopen en het vliegen.
• Kwaliteit: 100% van de gegenereerde tests was grammaticaal correct (ze "kraakten" niet). 85% werkte direct goed zonder aanpassingen.
• Tijdwinst: Voor een project met 57 eisen duurde het handmatig schrijven van tests ongeveer 57 uur. Met de assistent was dit in 19 uur klaar. Dat is een tijdwinst van 66%.

5. Wat betekent dit voor de mensen?

Je zou denken: "Maar doen ze de ingenieurs dan niet hun baan af?" Nee, integendeel.

Stel je voor dat een architect niet meer urenlang hoeft te tekenen aan de basis van een huis, maar dat een robot dat voor hem doet. De architect kan zich dan richten op de mooie details, de veiligheid en het ontwerp van de dakkapel.

Door deze slimme assistent te gebruiken, hoeven ingenieurs niet meer saai en repetitief tests te schrijven. Ze kunnen zich richten op het controleren van wat de computer heeft gemaakt, het verbeteren van de moeilijkste gevallen en het denken over hoe ze het product nog veiliger kunnen maken.

Kortom:
Dit papier laat zien dat je AI kunt gebruiken om de saaie, tijdrovende klusjes in de softwareontwikkeling over te nemen. Door de AI te koppelen aan de eigen kennis van het bedrijf, krijg je een assistent die niet alleen snel is, maar ook slim en betrouwbaar. Het is niet langer een experiment, maar een werktuig dat al in de fabriek wordt gebruikt om tijd te besparen en kwaliteit te verhogen.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "EmbC-Test: How to Speed Up Embedded Software Testing Using LLMs and RAG" in het Nederlands.

Probleemstelling

De ontwikkeling van ingebouwde (embedded) C-software versnelt door frequentere release-cycli en het gebruik van AI voor codegeneratie. Echter, de verificatie en het testen van deze software vormen een kritieke bottleneck.

• Huidige situatie: Het handmatig schrijven van automatische tests voor embedded C-code is tijdrovend, schaalt slecht en verbruikt schaarse testbronnen.
• Beperkingen van bestaande AI-oplossingen: Eenvoudige "zero-shot" generatie met Large Language Models (LLMs) levert vaak onbetrouwbare resultaten. Deze tests bevatten hallucinaties (uitvinden van API's of functies), volgen niet de projectspecifieke conventies, en kunnen valse zekerheid creëren door impliciete afhankelijkheden of onvolledige mocking. In veiligheidskritieke omgevingen is dit onacceptabel.

Methodologie: De EmbC-Test RAG-pijplijn

Het paper introduceert een Retrieval-Augmented Generation (RAG) pijplijn die specifiek is ontworpen voor het genereren van unit-tests voor embedded C-software. In plaats van alleen te vertrouwen op de algemene training van een LLM, wordt het model "geground" in projectspecifieke artefacten.

De architectuur bestaat uit twee fasen:

1. Offline Fase (Knowledge Base Constructie):

   • Bronnen: C-headerbestanden, broncode, bestaande Python-tests en documentatie worden verzameld.
   • Chunking-strategieën: Om de context goed te behouden, worden vier strategieën geëvalueerd:
     • Fixed-size: Simpel, maar riskeert het splitsen van functies.
     • Brace-aware: Splitst op basis van haakjes-niveau (0-depth), behoudt functies intact.
     • AST-based (Abstract Syntax Tree): Parseert de code naar een syntactische boomstructuur. Dit blijkt de meest effectieve methode om logische eenheden (functies, enums, types) te groeperen zonder ze te splitsen.
     • Test unit chunking: Splitsing per test-eenheid.
   • Embedding: De chunks worden omgezet in vectorrepresentaties via een lokaal gehoste embedding-modellen en opgeslagen in een vectordatabase.

2. Online Fase (Generatie):

   • Hybride Retrieval: Voor een specifieke software-eis worden de meest relevante chunks opgehaald via een combinatie van:
     • Dense search: Semantische zoekopdracht (cosine similarity).
     • Sparse search (BM25): Lexicale zoekopdracht met code-bewuste tokenisatie voor exacte woordovereenkomsten.
     • De resultaten worden gefuseerd via Reciprocal Rank Fusion (RRF).
   • Prompt Engineering: De opgehaalde context (headers, broncode, legacy tests) wordt gecombineerd met een systeemprompt en de specifieke software-eis in een prompt voor een cloud-gehost LLM.
   • Output: De LLM genereert tests die direct compatibel zijn met het bestaande testframework.

Belangrijkste Bijdragen

1. Pragmatische Referentiearchitectuur: Een volledig werkend RAG-systeem voor embedded C, inclusief strategieën voor chunking (waarbij AST-based chunking als superieur wordt aangetoond), hybride retrieval en prompt-ontwerp.
2. Industriële Validatie: Het systeem is niet alleen theoretisch, maar daadwerkelijk geïmplementeerd en gebruikt bij Hydac Software GmbH.
3. Multidimensionale Evaluatie: Een evaluatieframework dat verder kijkt dan alleen code-coverage, en ook kijkt naar syntactische correctheid, runtime-validatie, ophaalkwaliteit (Precision/Recall) en menselijke beoordeling.
4. Shift in Expertise: Het paper benadrukt dat het doel niet is om menselijke experts te vervangen, maar hun tijd te verschuiven van repetitief schrijven naar hoogwaardige activiteiten zoals risico-analyse en exploratief testen.

Resultaten

De evaluatie omvatte 44 configuraties en vergeleek RAG met baselines (willekeurige chunk-retrieval en geen retrieval).

• Correctheid:
  • Syntactische validatie: 100% van de gegenereerde tests was syntactisch correct.
  • Runtime validatie: 84,5% van de tests slaagde de runtime-validatie (vergeleken met 62,4% voor willekeurige retrieval en 50,5% zonder retrieval).
• Code Coverage: De RAG-systemen bereikten tot 43% branch-coverage en 67% line-coverage in één enkele run (zonder iteratieve verbetering). Ter vergelijking: handmatige test suites bereikten na maanden van iteratie 76% branch- en 93% line-coverage.
• Menselijke Evaluatie: Twee domeinexperts beoordeelden de tests op een 5-puntsschaal. De beste configuratie scoorde:
  • Relevantie: 4,33
  • Correctheid van asserties: 4,61
  • Volledigheid randgevallen: 4,06
  • Leesbaarheid: 4,83
  • Gebruikswaarde: 94,4% van de tests was direct acceptabel of vereiste slechts kleine aanpassingen.
• Efficiëntie en Tijdwinst:
  • Snelheid: Het systeem genereert ongeveer 270 tests per uur. Handmatig schrijven kostte ongeveer 1 test per uur.
  • Tijdsbesparing: Voor een bibliotheek met 57 software-eisen daalde de testinspanning van 57 uur naar 19,2 uur, wat neerkomt op een tijdwinst van 66%.

Significantie en Conclusie

Het paper toont aan dat RAG een oplossing biedt voor de "hallucinatie"-problematiek bij het genereren van tests voor ingebouwde systemen. Door het LLM te koppelen aan projectspecifieke kennis (legacy tests, API's, documentatie), worden tests gegenereerd die direct in het bestaande ecosysteem passen.

De belangrijkste implicatie is dat deze technologie de verificatiecyclus aanzienlijk versnelt zonder in te leveren op kwaliteit. Het stelt testingenieurs in staat om zich te concentreren op complexe taken zoals randgevalanalyse en kwaliteitsborging, terwijl de RAG-tool het zware werk van het initiële opstellen van testcases overneemt. Dit maakt het een waardevol instrument voor industriële adoptie, mits er een "Human-in-the-Loop" aanpak wordt gehanteerd waarbij menselijke experts de gegenereerde tests reviewen en valideren.