Hier volgt een overzicht van veelvoorkomende gereedschapscategorieën en voorbeelden:

1. Testframeworks: Deze bieden de structuur en organisatie voor geautomatiseerde tests.

* Google-test (gtest): Een veelgebruikt C++-testframework dat bekend staat om zijn eenvoud en uitbreidbaarheid. Vaak gebruikt in ingebedde projecten die C++ gebruiken.

* Eenheid: Een lichtgewicht, platformonafhankelijk raamwerk voor het testen van eenheden, geschikt voor C- en C++-projecten. Populair in embedded systemen vanwege de kleine footprint.

* CppUTest: Nog een C++ unit-testframework dat speciaal is ontworpen voor embedded systemen, waarbij de nadruk ligt op minimaal bronnengebruik.

* CUnit: Een unit-testframework voor C.

* Test voltooid: Een commercieel raamwerk dat scripting in verschillende talen ondersteunt en GUI-tests kan automatiseren (hoewel dit minder gebruikelijk is in bare-metal embedded systemen)

2. Testuitvoeringsomgevingen/hardlopers: Deze beheren de uitvoering van testsuites en de rapportage van resultaten.

* Veel IDE's bevatten testlopers: Eclipse CDT kan bijvoorbeeld worden geïntegreerd met frameworks zoals Google Test.

* Aangepaste scripts: Vaak schrijven embedded-systeemteams hun eigen scripts (bijvoorbeeld met behulp van Python of Bash) om de testuitvoering te orkestreren, met name voor integratie- en tests op systeemniveau.

* Systemen voor continue integratie/continue implementatie (CI/CD): Jenkins, GitLab CI, Azure DevOps, enz. worden vaak gebruikt om het bouw- en testproces te automatiseren, ook voor embedded systemen. Deze integreren vaak met de testframeworks en runners.

3. Hardwarespecifieke tools: Deze tools overbruggen vaak de kloof tussen de testautomatiseringssoftware en de embedded hardware.

* JTAG-foutopsporingsprogramma's: Tools zoals die van Segger, Lauterbach of ARM bieden interfaces om de hardware op een laag niveau te debuggen en te testen. Ze kunnen ook tests activeren en resultaten vastleggen.

* In-Circuit-emulators (ICE's): ICE's maken geavanceerdere testscenario's mogelijk dan JTAG, vaak inclusief realtime tracerings- en emulatiemogelijkheden. Dit zijn doorgaans high-end oplossingen.

* Hardware-in-the-loop (HIL)-simulators: Dit zijn geavanceerde systemen die de externe omgeving van het ingebedde systeem simuleren, waardoor de interactie van het systeem met de echte wereld grondig kan worden getest zonder dat er fysieke componenten of potentieel gevaarlijke situaties nodig zijn.

* CAN/LIN/Ethernet-busanalysatoren: Deze tools registreren en analyseren de communicatie op auto- en industriële bussen, wat cruciaal is voor het testen van ingebedde systemen die via deze protocollen communiceren.

* Oscilloscoop/Logische analysers: Voor direct onderzoek van hardwaresignalen.

4. Hulpmiddelen voor analyse van dekking testen: Deze meten hoe grondig de testsuite de code afdekt.

* gcov (GCC): Een ingebouwde tool binnen de GCC-compiler die informatie over de codedekking biedt.

* Commerciële hulpmiddelen: Geavanceerdere tools bieden gedetailleerde dekkingsrapporten, waaronder filiaaldekking, conditiedekking en MC/DC (Modified Condition/Decision Coverage), wat vaak verplicht wordt gesteld door veiligheidsnormen (zoals ISO 26262).

5. Testbeheertools: Deze helpen bij het organiseren en beheren van het testproces.

* Jira, Azure DevOps, TestRail: Dit zijn veelgebruikte hulpmiddelen voor het beheren van testgevallen, het opsporen van bugs en het rapporteren van testresultaten.

Welke tools bedrijven gebruiken: De keuze is sterk afhankelijk van factoren als:

* Begroting: Open-sourcetools zoals Google Test en Unity zijn vanwege de kosten aantrekkelijk. Commerciële tools bieden meer geavanceerde functies, maar hebben een prijskaartje.

* Projectcomplexiteit: Eenvoudige projecten hebben wellicht alleen een unit-testframework nodig, terwijl complexe systemen een uitgebreider pakket aan tools vereisen.

* Veiligheidsnormen: Veiligheidskritische toepassingen (automobiel, lucht- en ruimtevaart, medisch) vereisen vaak het gebruik van tools die voldoen aan specifieke normen en geavanceerde dekkingsanalyses bieden.

* Hardwareplatform: De beschikbare debugging-interfaces en hardware zullen de keuze van de tools beïnvloeden.

* Teamexpertise: De vaardigheden van het technische team zullen de haalbaarheid van het adopteren en gebruiken van bepaalde tools bepalen.

Samenvattend maken systeembedrijven die betrokken zijn bij de ontwikkeling van embedded systemen gebruik van een breed scala aan tools, waarbij ze vaak open source en commerciële opties combineren om een ​​op maat gemaakte testinfrastructuur te bouwen die voldoet aan hun specifieke behoeften en projectvereisten. De trend is richting meer automatisering en integratie met CI/CD-pijplijnen.