Wir setzen die Artikelserie zum Testen der Automatisierung eingebetteter Systeme fort. In diesem Artikel erfahren Sie, wie Sie die Fähigkeit, die Leistung des zu testenden Geräts über ein Testskript zu steuern, schnell und relativ einfach integrieren und das Drücken mechanischer Tasten auf einen Befehl über ein Testskript simulieren können.
Also, was wir haben:
- Dutzende von Embedded-Geräten, auf denen Sie die neue FirmWare-Version testen müssen (genauer gesagt, tägliche Firmware-Installation)
- Aufgrund der Art des FW-Startvorgangs müssen Sie möglicherweise die Stromversorgung zurücksetzen (der sogenannte Firmware-Download-Modus im Power On Capture-Modus).
- Ich möchte zu bestimmten Zeitpunkten während der Ausführung des Testskripts das Klicken auf die mechanischen Schaltflächen simulieren, die sich auf der Debug-Karte des eingebetteten Systems befinden
Warum könnte Punkt 3 benötigt werden? In meinem Fall lautet die Aufgabe wie folgt: Im Falle einer kritischen Ausnahme der Codeausführung „steigt“ das System in einen Zustand halb tot, aus dem es erst nach dem Ausschalten beendet wird (ein weiterer Grund für die Energieverwaltung). Das Interessanteste ist jedoch, dass Sie in diesem Modus den speziell für diesen Zweck entwickelten mechanischen Knopf drücken, den sogenannten Ausnahmeprotokoll - Debugging-Informationen, anhand derer versucht werden kann, festzustellen, an welcher Stelle im Code eine Ausnahme aufgetreten ist.
Genau aus diesem Grund war es für die effektive Automatisierung des Testaufbaus erforderlich, die Stromversorgung des Geräts zurückzusetzen und das Drücken der mechanischen Tasten auf der Debug-Karte zu simulieren, um wichtige Informationen zu Exception zu speichern, damit sie nicht bald verloren gehen. Früher oder später versucht ein Testskript, das feststellt, dass das Gerät nicht reagiert, es durch Zurücksetzen der Stromversorgung zu reaktivieren.
Ein kleiner lyrischer Exkurs - manchmal laufen Sie wochenlang hinter dieser Ausnahme her Es tritt nur gelegentlich auf, wenn alle Sterne zusammenlaufen und eine Reihe anderer Bedingungen nicht erfüllt sind. Daher ist jedes solche Debug-Protokoll sehr wichtig und notwendig.
Die Analyse des Board Debugging ergab, dass der Button einfach die GPIO-Leitung schließt, die auf +3,3 V auf GND gezogen wurde. Wenn Sie also an den Knopf „löten“ und das Relais verwenden, um die GPIO-Leitung zum Boden zu schließen, ist es genau das, was Sie brauchen.
Als nächstes stellte sich die Frage nach der Auswahl eines Geräts / Moduls für die Steuerung, an das die folgenden Anforderungen gestellt wurden:
- Die maximale Anzahl von Relais (Sie benötigen 2 Stück pro Gerät und es gibt Dutzende von Geräten)
- Ethernet-Zugang
- URL-Befehle verwalten
- Möglichkeit zum Kopieren und Skalieren des Systems
Aus Tradition stoppten sie auf dem Etherent-Modul des Laurent-128-Relais:
Das Modul hat uns mit allen Parametern gefreut: Wir können 14 Geräte gleichzeitig verwalten (ein Relais für die Stromversorgung, das andere auf Knopfdruck), indem wir URL-Befehle verwenden (sehr praktisch für Skriptsprachen, in denen die Testautomatisierung geschrieben ist).
Das Anschluss- und Kommunikationsdiagramm der Debug-Karte des Prüflings und des Steuermoduls ist in der folgenden Abbildung dargestellt:
Das „Löten“ auf die Kontakte eines mechanischen Tasters am Beispiel eines der getesteten Geräte sieht folgendermaßen aus:
Hurra! Der technische Teil ist erledigt. Sie müssen nur noch den Code der Testverfahren hinzufügen, damit bei Bedarf (Herunterladen des Firmware-Images nach einem Power-Reset oder Debuggen von Aufzeichnungen auf Knopfdruck) ein Befehl zum Ein- / Ausschalten des gewünschten Relais erteilt wird.
Die Syntax der Steuerbefehls-URLs ist einfach und offensichtlich. Um beispielsweise das Relais unter Nummer 4 zu aktivieren, müssen Sie die folgende HTTP-Adresse verwenden:
http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1
Und hier ist eine einfache Funktion in Perl, die vom Haupttestverfahren aufgerufen wird, wenn Sie das Relais "ziehen" müssen:
Ich stelle fest, dass das System sehr zuverlässig funktioniert, ohne dass es abstürzt und einfriert. Laurent-128 und der zuvor verwendete Laurent-112 (für 12 Relais) arbeiteten unter Berücksichtigung der täglichen Arbeit einige Jahre ohne Ausfälle und Unterbrechungen.
Und hier ist ein Beispiel für eine solche Ausnahme, die bei Tests mit einer außergewöhnlichen täglichen Firmware-Assembly festgestellt wurde. Nachdem dem Testskript klar wurde, dass keine Antwort vom Gerät an der seriellen Schnittstelle einging (das heißt, es ist "abgestorben"), wurde versucht, den mechanischen Notfallknopf zu drücken, um das Debugging aufzuzeichnen, und dies funktionierte - der vom Testskript selbst erstellte endgültige Testbericht wurde mit nützlichen Informationen von gefüllt Ort eines möglichen Systemabsturzes zur weiteren Analyse durch das Entwicklungsteam:
