Test af software er noget, de fleste forbinder med at oprette brugere, logge ind, få vist noget data og trykke på nogle knapper. Det kunne være i en mobil app, på en hjemmeside eller et program på computeren. Det er meget klassisk og noget, de fleste udviklere og testere har arbejdet med på et eller andet tidspunkt i deres karriere. Det er også noget der er nemt at forholde sig til, da det det foregår på enheder, vi allerede bruger meget i dagligdagen.
Men hvad hvis knapperne er fysiske, og der ikke er nogen brugerflade? Måske stikker der en masser ledninger ud af den enhed, du kigger på? Måske er din enhed forbundet til andre enheder?
Hvor man før i tiden havde flere mekaniske enheder, der manuelt skulle overvåges, er mulighederne i dag næsten uendelig. Det er muligt at lave elektroniske komponenter så små og smarte, at de findes stort set over det hele, i alle typer produkter og inden for alle brancher. Det kunne f.eks. være inden for præcis måling og dosering af væsker, til overvågning og styring af større strømanlæg. Fælles for disse enheder er, at mange af dem også indeholder software. Muligvis uden en skærm eller andre måder at fysisk interagere med enheden på.
Hvordan laver man test af fysiske enheder – også kaldet “embedded software test”? Opgaven er jo umiddelbart den samme som alle andre opgaver, der indebærer test af software. ”Når man gør sådan og sådan, skal der ske sådan og sådan.” Udfordringen kan være, at det kræver lidt mere teknisk kunnen af den, der udfører testene. Det kunne f.eks. være gennem en terminal eller kommando prompt, eller måske et API.
Hos Key2Quality har vi arbejdet på flere opgaver, som indebar test fysiske enheder. Her er nogle eksempler på, hvordan vi har hjulpet kunder godt videre med deres projekter.
Penetration test
En kunde ønskede hjælp med et allerede eksisterende setup af computere og hardwareenheder. De ville gerne have det lavet sådan, at hver gang en udvikler lavede en ændring på kodebasen, så blev der bygget en ny firmware, som blev lagt på hardwareenheden og testet. Testen i dette tilfælde var en penetration test kørt ved hjælp af et 3. partssoftware. De havde over flere gange forsøgt at få deres setup af hardwareenheder, computere og byggeagenter til at virke, men det sandede hurtigt til, hvorefter det holdt op med at virke. Pga. tidspres var der ikke overskud til at få det til at køre igen.
Vores opgave hos Key2Quality var at hjælpe kunden med at lave så stabilt et setup som muligt. Det skulle kunne køre som en template fra GitLab, så andre pipelines kunne bruge det. Skulle der ske en ændring, der gjorde, at scriptet begyndte at fejle, skulle det være nemt at finde fejlen, lave en rettelse og få det til at virke igen.
Sammen med kunden fik vi hurtigt styr på de fysiske dele. Det indebar en computer, der skulle fungere som byggeagent, diverse netværksopsætning samt opsætning af deres hardwareenheder. Herefter gik vi i gang med at lave de scripts, der skulle til for at hente og uploade den nye firmware til enheden og starte en penetration test på den. Alt sammen via kommandoer, man normalt vil køre fra en kommandoprompt. Her var altså ingen hjælp fra en grafisk brugerflade. Stille og roligt fik vi bygget alle deres ønsker ind i vores scripts. Vi fik tjekket og oprettet data, hvor det var nødvendigt, så testen altid ville kunne køre igen, skulle den fejle. Vi lavede også tests til vores templates, så det var nemt at teste både template og scripts. Alle filer blev løbende udfyldt med kommentarer, og dokumentation omkring brugen af det blev også løbende opdateret.
Under hele projektet var der en god dialog med kunden, som var med til lave review af koden. Kunden var hele tiden var med i processen, og vi kunne løbende rette til, hvis der var ønsker til ændringer. Til sidst var der et overdragelsesmøde, hvor kunden gav udtryk for, at de var rigtigt glade for det endelige resultat.
Cyber security test i henhold til IEC62443
Dette er endnu et eksempel på en opgave, som ikke indebar test af ”almindelig” software.
Kunden havde nogle enheder, som de selv havde kodet noget software i, og ønskede, at vi hos Key2Quality hjalp med at lave et proof-of-concept (POC) på en sikkerhedsopgave.
Hver gang kunden skulle lave en endelig release af deres enhed, skulle de samtidig kunne dokumentere, at den overholdt IEC62443-standarden, som indeholder flere punkter i forhold til cyber security. Punkterne i testen kunne sagtens udføres manuelt, men det er en langsommelig og tidskrævende proces, og derfor ville de gerne have den automatiseret, i det omfang det var muligt. Kunden havde i forvejen et framework og et fortrukket kodesprog, vi skulle fortsætte vores POC i. Der var ingen brugerflade, og der var en blanding af SSH kald og brug af kommandoprompten.
Vi fik lavet en komponent til kunden, som var logisk bygget op i forhold til de enkelte punkter i standarden, som vi kunne udføre. Det kunne f.eks. være at logge ind med en forkert bruger, og bagefter hente auditloggen ud. Resultatet blev en komponent, som kunne tjekke seks forskellige ting og skrive en kort status i loggen. Ved at køre det automatisk tog det ingen tid at udføre testen, i forhold til hvis vi skulle gøre det manuelt. Risikoen for fejl var også væsentlig minimeret.
Ud over koden, som løbende blev udfyldt med kommentarer, lavede vi også dokumentation og en god overdragelse. Kunden var meget tilfreds, da de overtog projektet for selv at arbejde videre med det.
Cloud-baseret automatiseringstest
Et sidste eksempel på software test af fysiske enheder er en kunde, som havde behov for at få designet et testframework for en cloud-baseret løsning bestående af tre hovedkomponenter: en webportal, en gateway, og en doseringspumpe.
Systemkomponenter:
- Gateway enhed: Forbinder systemet til en skybaseret platform via mobilnetværket og muliggør fjernstyring og overvågning.
- Brugerinterface: Inkluderer en mobilapplikation og en webportal, der tillader brugere at konfigurere og overvåge systemet i realtid.
- Datahåndtering: Samler og synkroniserer operationelle data til skyen, hvilket muliggør generering af tilpassede rapporter og alarmer.
Her implementerede vi automatiserede tests til at simulere og verificere telemetri data gennem API’er, og vi anvendte også manuelle tests for at kontrollere, at data blev afspejlet korrekt både på webportalen og på doseringspumpen. Denne dobbelte tilgang sikrede både nøjagtighed og effektivitet i systemets drift.
Dette er blot nogle få eksempler på, hvad software test også kan være.
Med fysiske enheder kan det give mening med testautomatisering. Det kan være en effektiv måde at spare tid på og få testet sin software løbende.
Til trods for at fysiske enheder kan være mere teknisk krævende, så er det en sjov opgave at få til at virke. Og når der først er hul igennem, så er testopgaven ofte den samme.
Skal vi hjælpe dig med embedded software test?
Vil du høre mere om, hvordan vi kan hjælpe med embedded software test, så kontakt områdeleder for teknisk test og hybrid intelligens, Jacob Fisker, på jacob@key2quality.dk eller 4940 7579.