Moderna produkter blir allt mer mjukvarudrivna. Inbyggd mjukvara samverkar med sensorer, aktuatorer, kommunikationsgränssnitt och fysisk hårdvara, vilket gör testning till en viktig och allt mer komplex del av produktutvecklingen.
Att testa direkt på den färdiga produkten är värdefullt, men kan också vara dyrt, långsamt och svårt att skala. Här kan Software-in-the-Loop (SIL), Hardware-in-the-Loop (HIL) och testautomation göra stor skillnad.
SIL och HIL – vad är skillnaden?
Software-in-the-Loop (SIL) innebär att mjukvaran testas mot en simulerad omgivning utan att den fysiska hårdvaran behöver vara på plats.
Eftersom testerna kan köras utan den kompletta produkten ger SIL snabb återkoppling och gör det möjligt att testa många scenarier tidigt i utvecklingen. Det passar särskilt bra för regressionstester, gränsvärden och för att kontrollera mjukvarans beteende när koden förändras.
Hardware-in-the-Loop (HIL) innebär att riktig hårdvara används i en kontrollerad testmiljö.
Ett typiskt HIL-flöde kan se ut så här:
Testautomation → Stimuli → Riktig hårdvara → Output → Mätning → Testresultat
HIL kan användas för att testa inbyggd mjukvara, hårdvarugränssnitt, kommunikationsprotokoll, sensorer, aktuatorer, timing och felhantering. Det gör det också möjligt att testa situationer som kan vara svåra, dyra eller osäkra att återskapa på en riktig produkt.
Varför använda olika testnivåer?
Det finns ingen testmiljö som är bäst för allt.
SIL är vanligtvis snabbt och enkelt att skala, medan HIL ger en högre grad av realism genom att använda riktig hårdvara. Fysisk testning är sedan viktig för att förstå hur den kompletta produkten fungerar i sin verkliga miljö.
Ett typiskt upplägg kan därför vara:
- SIL för snabb testning av mjukvara
- HIL för hårdvara och inbyggda system
- Fysisk testning för produktens helhet
Målet är inte att ersätta en nivå med en annan, utan att använda varje nivå där den ger störst värde.
Testautomationens roll
Automation kopplar ihop de olika testnivåerna och gör det möjligt att köra tester upprepade gånger och i större skala.
Ett automatiserat testsystem kan konfigurera testmiljön, förbereda systemet, skicka stimuli, samla in mätningar och loggar, utvärdera resultat och skapa rapporter.
Det kan ge flera fördelar:
- Snabbare återkoppling
- Repeterbar testning
- Reproducerbara testmiljöer
- Större testtäckning
- Enklare regressionstestning
- Mindre manuellt arbete
Automation gör det också enklare att koppla testning till CI-flöden. Istället för att vänta på en större testfas kan mindre uppsättningar tester köras kontinuerligt under utvecklingen.
Att designa för testbarhet
Testbarhet bör också vara en del av systemdesignen.
Om viktiga funktioner kan stimuleras och mätas separat blir de enklare att testa och felsöka. Tydliga gränssnitt och bra möjligheter till mätning kan göra stor skillnad när automatiserade tester ska byggas.
Bra testbarhet hjälper också när något går fel. Istället för att bara veta att slutresultatet är fel kan ett väl utformat system ge information som gör det lättare att hitta var problemet uppstod.
Det är också viktigt att inte dölja fel genom upprepade testförsök. Ett retry kan vara användbart vid ett känt tillfälligt problem, men bör inte användas för att få ett oförklarat fel att försvinna.
Från testning till kontinuerlig återkoppling
När SIL, HIL, fysisk testning och automation kombineras kan testning bli en kontinuerlig del av utvecklingen istället för något som sker först i slutet.
En mjukvaruändring kan till exempel först gå igenom snabba automatiserade tester, följt av SIL-tester och utvalda HIL-tester. Mer omfattande HIL- och fysiska tester kan sedan ge ytterligare trygghet när produkten utvecklas.
På så sätt kan team få återkoppling tidigare och samtidigt testa samspelet mellan mjukvara, hårdvara och den fysiska produkten.
Att få helheten att fungera
SIL, HIL och fysisk testning har alla sina styrkor. Tillsammans med testautomation ger de utvecklingsteam fler möjligheter att testa tidigare, testa fler scenarier och få snabbare återkoppling.
Det mest effektiva är därför oftast inte att välja en metod framför en annan, utan att bygga en lagerbaserad teststrategi där de olika nivåerna kompletterar varandra.
I slutändan handlar det om en enkel sak: hitta problem tidigare, få snabbare återkoppling och utveckla bättre produkter med större trygghet.
