Testautomatisierung mit eingebetteter Hardware

Hatte jemand Erfolg beim Automatisieren von Tests direkt auf eingebetteter Hardware?

Insbesondere denke ich darüber nach, eine Reihe von Komponententests für Hardware-Layer-Module zu automatisieren. Wir müssen mehr Vertrauen in unseren Hardware-Layer-Code haben. Viele unserer Projekte verwenden Interrupt-gesteuerte Timer, ADCs, serielle I/O, serielle SPI-Geräte (Flash-Speicher) usw.

Lohnt sich dieser Aufwand überhaupt?

Wir zielen typischerweise auf:

Prozessor: 8- oder 16-Bit-Mikrocontroller (einige DSP-Sachen)
Sprache: C (manchmal c++).

Sicher. In der Automobilindustrie verwenden wir für jedes neue Produkt speziell angefertigte Tester im Wert von 100.000 US-Dollar, um zu überprüfen, ob Hardware und Software ordnungsgemäß funktionieren.

Die Entwickler bauen jedoch auch einen billigeren (unter 1.000 US-Dollar) Tester, der eine Reihe von USB-I/O, A/D, PWM-Ein/Ausgang usw. enthält und entweder Skripting auf der Workstation oder speziell entwickelte HIL/SIL-Testsoftware verwendet wie MxVDev.

Hardware-in-the-Loop-Tests (HIL) sind wahrscheinlich das, was Sie meinen, und es handelt sich einfach um einige USB-Hardware-I/O, die an die I/O Ihres Geräts angeschlossen sind, während Software auf dem Computer Tests dagegen durchführt.

Ob es sich lohnt, hängt davon ab.

In der Hochzuverlässigkeitsindustrie (Flugzeuge, Automobile usw.) legt der Kunde sehr umfangreiche Hardwaretests fest, sodass Sie sie haben müssen, um das Angebot zu erhalten.

In der Konsumgüterindustrie lohnt es sich bei nicht komplexen Projekten meist nicht.

Bei jedem Projekt, an dem mehr als ein paar Programmierer beteiligt sind, ist es jedoch so Ja wirklich Es ist schön, einen nächtlichen Regressionstest auf der Hardware laufen zu lassen – es ist schwierig, die Hardware in dem Maße korrekt zu simulieren, das erforderlich ist, um sich davon zu überzeugen, dass die Softwaretests ausreichen.

Das Testen zeigt dann sofort, wenn ein Problem in den Build eingedrungen ist.

Im Allgemeinen führen Sie sowohl Black-Box- als auch White-Box-Tests durch – auf dem Gerät wird Diagnosecode ausgeführt, mit dem Sie Signale und Speicher in der Hardware ausspionieren können (was möglicherweise nur ein Debugger ist oder von Ihnen geschriebener Code, der auf Nachrichten reagiert). ein Bus zum Beispiel). Dies wäre ein White-Box-Test, bei dem Sie sehen können, was intern passiert (und sogar einige Dinge verursachen können, z. B. kritische Speicherfehler, die nicht getestet werden können, ohne den Fehler selbst einzuführen).

Wir führen auch eine Reihe von „Black-Box“-Tests durch, bei denen der Diagnosepfad ignoriert wird und nur die E/A stimuliert/gelesen wird.

Für ein viel günstigeres Setup können Sie 100-Dollar-Mikrocontroller-Boards mit USB und/oder Ethernet (wie die Atmel UC3-Familie) erwerben, die Sie an Ihr Gerät anschließen und grundlegende Tests durchführen können.

Es ist besonders nützlich für die Produktwartung – wenn das Projekt abgeschlossen ist, speichern Sie einige Arbeitsplatinen, den Tester und einen kompletten Softwaresatz auf CD. Wenn Sie eine Änderung vornehmen oder ein Problem debuggen müssen, ist es einfach, alles wieder einzurichten und mit etwas Wissen (nach dem Testen) daran zu arbeiten, dass die Hauptfunktionalität von Ihren Änderungen nicht betroffen war.

-Adam

Ja. Ich hatte Erfolg, aber es ist kein einfaches Problem, das es zu lösen gilt. Kurz gesagt, hier ist, was mein Team getan hat:

1. Definierte eine Vielzahl von Unit-Tests mit einem selbstgebauten C-Framework für Unit-Tests. Im Grunde nur eine Menge Makros, von denen die meisten benannt wurden TEST_EQUAL, TEST_BITSET, TEST_BITVLRetc.

2. Einen Boot-Code-Generator geschrieben, der diese kompilierten Tests nahm und sie in einer Ausführungsumgebung orchestrierte. Es ist nur ein kleiner Treiber, der unsere normale Startroutine ausführt – aber anstatt in die Regelschleife zu gehen, führt er eine Testsuite aus. Wenn dies erledigt ist, speichert es die letzte Suite, die im Flash-Speicher ausgeführt werden soll, und setzt dann die CPU zurück. Es wird dann die nächste Suite ausgeführt. Dies dient der Isolierung, falls eine Suite stirbt. (Möglicherweise möchten Sie dies jedoch deaktivieren, um sicherzustellen, dass Ihre Module zusammenarbeiten. Dies ist jedoch ein Integrationstest, kein Komponententest.)

3. Einzelne Tests würden ihre Ausgabe über die serielle Schnittstelle protokollieren. Dies war für unser Design in Ordnung, da die serielle Schnittstelle frei war. Sie müssen einen Weg finden, Ihre Ergebnisse zu speichern, wenn alle Ihre IO verbraucht sind.

Es funktionierte! Und es war großartig, es zu haben. Mit unserem benutzerdefinierten Datenlogger könnten Sie auf die Schaltfläche „Test“ klicken, und ein paar Minuten später hätten Sie alle Ergebnisse. Ich empfehle es sehr.

Aktualisiert um zu verdeutlichen, wie der Testtreiber funktioniert.

Ja.

Die Schwierigkeit hängt von der Art der Hardware ab, die Sie testen möchten. Wie andere bereits gesagt haben, wird das Problem die Komplexität des externen Stimulus sein, den Sie anwenden müssen. Ein externer Stimulus wird wahrscheinlich am besten mit einem externen Prüfstand erreicht (wie Adam Davis beschrieben hat).

Eine Sache, die es zu beachten gilt, ist jedoch exakt was Sie zu überprüfen versuchen.

Es ist verlockend anzunehmen, dass Sie zum Überprüfen des Zusammenspiels von Hardware und Firmware wirklich keine andere Wahl haben, als direkt einen externen Stimulus anzuwenden (dh DACs auf alle Ihre ADC-Eingänge anzuwenden usw.). In diesen Fällen werden die Eckfälle, die Sie wirklich testen möchten, jedoch häufig Timing-Problemen ausgesetzt sein (z. B. Interrupts, die beim Ausführen der Funktion foo() eintreffen), die unglaublich schwierig zu testen sind einen sinnvollen Weg – und noch schwieriger, aussagekräftige Ergebnisse zu erzielen. (dh. Die ersten 100.000 Male, die wir diesen Test durchgeführt haben, war er in Ordnung. Das letzte Mal, als wir ihn ausgeführt haben, ist er fehlgeschlagen. Warum?!?)

Aber die Überprüfung der Hardware sollte separat erfolgen. Sobald dies erledigt ist, sollten Sie davon ausgehen können, dass die Hardware funktioniert, und Ihre Firmware nur testen, es sei denn, es ändert sich regelmäßig (durch herunterladbare FPGA-Images oder ähnliches).

In diesem Fall können Sie sich also darauf konzentrieren, die Algorithmen zu überprüfen, die zur Verarbeitung Ihrer externen Reize verwendet werden. Rufen Sie beispielsweise Ihre ADC-Konvertierungsroutinen mit einem festen Wert auf, als ob sie direkt von Ihrem ADC kämen. Diese Tests sind wiederholbar und daher von Vorteil. Sie erfordern jedoch spezielle Testaufbauten.

Das Testen der Kommunikationspfade Ihres Geräts ist relativ einfach und sollte keine speziellen Code-Builds erfordern.

Wir haben gute Ergebnisse mit automatisierten Tests auf unseren eingebetteten Systemen erzielt. Wir haben Tests in Hochsprachen (einfach zu programmieren und zu debuggen) geschrieben, die auf dedizierten Testmaschinen ausgeführt werden. Diese Tests führen im Allgemeinen Plausibilitätsprüfungen durch oder generieren zufällige Eingaben in die Geräte und prüfen dann auf korrektes Verhalten. Es ist viel Arbeit, diese Tests zu generieren und zu pflegen. Wir entwarfen ein Framework und ließen die Praktikanten dann selbst an den Tests arbeiten.

Es ist keine perfekte Lösung, und die Tests sind sicherlich fehleranfällig, aber das Wichtigste ist, Ihre bestehenden Abdeckungslücken zu verbessern. Finden Sie das größte Loch und entwerfen Sie etwas, um es auf automatisierte Weise abzudecken, auch wenn es nicht perfekt ist oder nicht das gesamte Merkmal abdeckt. Später, wenn alle Ihre Sachen einigermaßen abgedeckt sind, können Sie zurückkommen und die schlechteste Abdeckung oder die kritischsten Funktionen ansprechen.

Einige Dinge zu beachten:

• Was ist die Strafe für einen Firmware-Bug? Wie einfach ist es, die Firmware vor Ort zu aktualisieren.
• Welche Art von Abdeckung bietet mein Test? Ist es eine einfache Plausibilitätsprüfung? Ist es so konfigurierbar, dass es viele verschiedene Szenarien testen kann?
• Wenn ein Test fehlgeschlagen ist, wie reproduzieren Sie diesen Wert, um ihn zu debuggen? Haben Sie alle Geräte- und Testeinstellungen protokolliert, um so viele Variablen wie möglich zu eliminieren? Gerätekonfiguration, Firmwareversion, Testsoftwareversion, alle externen Eingänge, alle beobachteten Verhaltensweisen?
• Gegen was testest du? Ist die Spezifikation klar genug für das erwartete Verhalten des Geräts, das Sie testen, oder validieren Sie anhand dessen, was der Code Ihrer Meinung nach tun sollte?

Wenn Ihr Ziel darin besteht, Ihren Low-Level-Treibercode zu testen, müssen Sie wahrscheinlich eine Art Testvorrichtung erstellen, die Loopback-Kabel oder mehrere miteinander verbundene Einheiten verwendet, damit Sie jeden Treiber testen können. Wenn Sie ein Board mit bekanntermaßen guter Software mit einem Board koppeln, auf dem ein Entwicklungs-Build ausgeführt wird, können Sie auf Regressionen in Kommunikationsprotokollen usw. testen.

Spezifische Teststrategien hängen von der Hardware ab, die Sie testen möchten. Zum Beispiel können ADCs getestet werden, indem eine bekannte Wellenform präsentiert und eine Reihe von Abtastwerten umgewandelt wird, dann auf den richtigen Bereich, die Frequenz, den Mittelwert usw. geprüft wird.

Ich habe diese Art des Testens in der Vergangenheit als sehr wertvoll empfunden, da sie es mir ermöglichte, Treibercode sicher zu ändern und zu verbessern, ohne befürchten zu müssen, bestehende Anwendungen zu beschädigen.

Ja, ich tue dies, obwohl ich immer einen seriellen Anschluss für Test-E/A zur Verfügung hatte.

Es ist oft schwierig, das Gerät zu verlassen total unverändert. Bei manchen Tests muss eine Zeile auskommentiert oder ein Aufruf hinzugefügt werden, zB um mit einem Watchdog umzugehen.

IMHO, das ist besser als gar keine Komponententests. Und natürlich müssen Sie auch vollständige Integrations-/Systemtests durchführen.

Das Testen von Komponenten eingebetteter Projekte ist ziemlich schwierig, da es normalerweise einen externen Stimulus und eine externe Messung erfordert.

Wir waren erfolgreich bei der Entwicklung eines externen seriellen Protokolls (entweder rs232- oder udp- oder tcpip-Nachrichten) mit grundlegenden Befehlen zum Trainieren der Hardware mit Debug-Protokollierung in den Low-Level-Treibern, die nach fehlerhaften Bedingungen oder sogar leicht anormalen Bedingungen suchen (insbesondere zur Überprüfung von Grenzwerten).

Aber nach der Entwicklung können wir die Tests bei Bedarf nach jedem Build durchführen. Es wird Ihnen definitiv ermöglichen, ein Produkt von besserer Qualität zu liefern.