Vad är Embedded Testing in Software Testing?

⚡ Smart sammanfattning

Inbyggd testning kontrollerar det funktionella och icke-funktionella beteendet hos programvara och hårdvara tillsammans, eftersom de två i ett inbyggt system är tätt sammankopplade och ingen av dem kan valideras ordentligt på egen hand.

  • 🔘 Tät koppling: Hårdvara byggs parallellt med programvaran, så den riktiga testmiljön kommer ofta sent.
  • ☑️ Fem nivåer: Testning av programvaruenhet, integration, systemenhet, systemintegration och systemvalidering riktar sig var och en mot en annan modulgräns.
  • Säkerhetsinsatser: Medicinska produkter, järnvägsprodukter, flygprodukter och fordonsprodukter behöver strikt dokumenterad testning innan certifiering kan beviljas.
  • 🧪 Grå ruta-preferens: Systemenhetstestning observerar interna resurser och RTOS-meddelanden, så gråboxmetoder passar bäst för det.
  • 🛠️ Huvudsakliga hinder: Begränsad hårdvaruåtkomst, komponenter med öppen källkod, blandade programvaru- och hårdvarufel och defekter som motstår reproduktion.

Inbyggd testning av mjukvara och hårdvara i ett inbyggt system

Vad är inbyggda system?

Inbyggda system är elektroniskt styrda enheter där programvara och hårdvara är tätt sammankopplade. Inbyggda system kan innehålla en mängd olika datorenheter. Dessa är datorer som är inbyggda i andra enheter för att utföra applikationsspecifika funktioner. Slutanvändaren är vanligtvis inte ens medveten om deras existens.

Inbäddad testning

Inbäddad testning är en testprocess för att kontrollera funktionalitet och icke-funktionell attribut hos både programvara och hårdvara i ett inbyggt system, och säkerställa att slutprodukten är felfri. Huvudsyftet med inbyggd testning är att verifiera och validera om slutprodukten av inbyggd hårdvara och programvara uppfyller kundens krav eller inte.

Testning av inbyggd programvara kontrollerar och säkerställer att den aktuella programvaran är av god kvalitet och uppfyller alla krav den ska uppfylla. Testning av inbyggd programvara är ett utmärkt sätt att garantera säkerhet i kritiska applikationer som medicinsk utrustning, järnvägar, flyg, fordonsindustri etc. Rigorösa och noggranna tester är avgörande för att bevilja programvarucertifiering.

Hur man utför testning av inbyggd programvara

I allmänhet testar du av fyra skäl:

  • För att hitta buggar i programvara
  • Hjälper till att minska risken för både användare och företaget
  • Minska utvecklings- och underhållskostnaderna
  • För att förbättra prestandan

Vid inbäddad testning utförs följande aktiviteter:

  1. Programvaran har vissa ingångar.
  2. En del av programvaran körs.
  3. Programvarans tillstånd observeras och utdata kontrolleras för förväntade egenskaper, som om utdata matchar det förväntade resultatet, överensstämmelse med kraven och frånvaro av systemkrascher.

Testtyper för inbäddad programvara

I grund och botten finns det fem testnivåer som kan tillämpas på inbäddad programvara.

Programvaruenhetstestning

Enhetsmodulen är antingen en funktion eller en klass. Enhetstestning utförs av utvecklingsteamet, främst utvecklaren, och genomförs vanligtvis i en peer-review-modell. Testfall utvecklas baserat på modulens specifikation.

Integrationstestning

Integrationstest kan delas in i två segment:

  • Integrationstestning av programvara
  • Testning av mjukvaru-/hårdvaruintegration

Slutligen testas samspelet mellan hårdvarudomänen och mjukvarukomponenterna. Detta kan innefatta att undersöka samspelet mellan inbyggda kringutrustningar och mjukvara.

Utveckling av inbyggd programvara har en unik egenskap: den faktiska miljön där programvaran körs skapas vanligtvis parallellt med programvaran. Detta orsakar olägenheter vid testning, eftersom omfattande tester inte kan utföras under simulerade förhållanden.

Systemenhetstestning

Nu är modulen som ska testas ett komplett ramverk som består av komplett programkod plus allt realtidsoperativsystem (RTOS) och plattformsrelaterade delar som avbrott, uppgiftsmekanismer, kommunikation och så vidare. Point of Control-protokollet är inte längre ett anrop till en funktion eller ett metodanrop, utan snarare ett meddelande som skickas eller tas emot med hjälp av RTOS-meddelandeköerna.

Systemresurser observeras för att utvärdera systemets förmåga att stödja exekvering av inbäddade system. För denna aspekt, grå boxtestning är den föredragna testmetoden. Beroende på organisationen är systemenhetstestning antingen utvecklarens eller ett dedikerat systemintegrationsteams uppgift.

Systemintegrationstestning

Modulen som ska testas utgår från en uppsättning komponenter inom en enda nod. Kontroll- och observationspunkterna (PCO:er) är en blandning av nätverksrelaterade kommunikationsprotokoll och RTOS-händelser, såsom nätverksmeddelanden. Förutom att vara en komponent kan en virtuell testare också fungera som en nod.

Systemvalideringstestning

Modulen som ska testas är ett delsystem med en komplett implementering, eller det kompletta inbyggda systemet. Syftet med detta slutliga test är att uppfylla funktionella krav för externa enheter. Observera att en extern enhet kan vara en person, en enhet i ett telekomnätverk, eller båda.

Skillnad: Inbäddad testning och mjukvarutestning

Tabellen nedan jämför inbyggd testning med konventionell mjukvarutestning.

Test av programvara Inbäddad testning
Programvarutestning är endast relaterad till programvara. Inbäddad testning är relaterad till både mjukvara och hårdvara.
I genomsnitt är 90 % av testerna som utförs i världen helt manuella svartbox testning. Inbyggd testning utförs på inbyggda system eller chips, och det kan vara svarta lådor eller vit box testning.
Primära områden för testning är GUI-kontroller, funktionalitet, validering och en viss nivå av databastestning. Primära testområden är hårdvarans beteende för antalet ingångar som ges till den.
Programvarutestning utförs huvudsakligen på klient-server, webb- och mobilbaserade applikationer. Inbyggd testning utförs vanligtvis på hårdvaran.
t.ex, Google Mail, Yahoo Mail, Android tillämpningar. t.ex. maskiner inom hälso- och sjukvården, mikrokontroller som används i datorer.

Utmaningar: Testning av inbyggd programvara

Några av de utmaningar man kan stöta på vid testning av inbäddad programvara:

Hårdvaruberoende

Hårdvaruberoende är bland de största svårigheterna vid testning av inbyggd programvara på grund av begränsad tillgång till hårdvara. Emulatorer och simulatorer kanske dock inte exakt representerar den faktiska enhetens beteende och kan ge en felaktig uppfattning om systemprestanda och applikationens användbarhet.

Open Source Software

Majoriteten av de inbäddade programvarukomponenterna är av öppen källkod till sin natur, skapas inte internt och det finns ingen komplett testsvit tillgänglig för dem. Det finns ett brett utbud av testkombinationer och resulterande scenarier.

Programvara kontra maskinvarufel

En annan aspekt är när programvara utvecklas för nyskapad hårdvara. Under denna process kan en hög andel hårdvarufel identifieras. Felet som upptäcks är inte begränsat till programvara. Det kan också vara relaterat till hårdvara.

Reproducerbara defekter

Fel är svårare att reproducera eller återskapa i fallet med ett inbyggt system. Det tvingar den inbyggda testproceduren att värdera varje felförekomst betydligt högre än i ett standardfall, och att samla in så mycket data som rimligen kan krävas för att hitta grundorsaken till felet.

Kontinuerliga programuppdateringar

Inbyggda system kräver regelbundna programuppdateringar som kärnuppgraderingar, säkerhetsfixar, olika drivrutiner etc. Begränsningar i samband med programuppdateringar gör det svårt att identifiera buggar. Dessutom ökar det betydelsen av bygg- och distributionsproceduren.

Vanliga frågor

Typiska stackar kombinerar statisk analys, enhetstest-härvor för C och C++, bussanalysatorer, trace-kapabla felsökare och hårdvarubaserade riggar, plus testautomation så regressionssviter körs obevakade.

Hardware-in-the-loop (HIL) kör riktig firmware på den riktiga styrenheten medan en simulator tillhandahåller de signaler som den omgivande anläggningen skulle producera, vilket utövar feltillstånd som är osäkra att skapa fysiskt.

En simulator modellerar beteende och kör en värdbygge; en emulator reproducerar målinstruktionsuppsättningen så att den riktiga binärfilen körs. Ingen av dem reproducerar analoga effekter och tidseffekter exakt.

IEC 61508 är den generiska standarden för funktionell säkerhet. Sektorversioner inkluderar ISO 26262 för vägfordon, DO-178C för luftburen programvara, IEC 62304 för medicintekniska produkter och EN 50128 för järnvägsstyrning.

AI-modeller prioriterar den stora stocken och tracvolymerna som en rigg producerar, klustra upprepade fel och rangordna vilka regressionstester som ska köras först på knapp hårdvara. Säkerhetsbedömningen ligger kvar hos ingenjören.

GitHub Copilot utkasttestselar och stubbar för C eller C++ moduler och snabbar upp repetitiv hånning. Registerbeteende och tidsbegränsningar som den aldrig sett behöver fortfarande kontrolleras.

Genom värsta tänkbara analys av exekveringstiden, instrumenterade trace på målet, och stressen körs vid toppbelastning. Deadlinemissar och avbrottslatens mäts på verklig hårdvara, vilket värdbyggen inte kan reproducera.

Läser C och C++, bekvämlighet med scheman och logiska analysatorer, förtrogenhet med RTOS-koncept och bussprotokoll, plus skriptning. Relaterat arbete som IoT-testning bygger på samma grund.

Sammanfatta detta inlägg med: