Da die hardwarenahe Software eben direkt an der Hardware hängt, komme ich mit Unit Tests nicht sehr weit. Zum Testen komme ich also um Hardware nicht herum.
Aber erst einmal definiere ich, was ich unter „Test“ verstehe: Überprüfen, ob eine vorgegebene Funktion aus einer Systemanforderung auch erfüllt wird.
Dafür brauche ich eine Testspezifikation, die direkt aus den Systemanforderungen erstellt wird. Sie enthält eine Beschreibung, was getestet wird und wann ein Test als bestanden gilt.
Testgeräte
sind z.B.
- Oszilloskop
- Logic Analyzer
- Multimeter
- serielle Ports mit Ausgabe auf Terminal oder Display
- eine oder mehrere LED’s
- ein oder mehrere Taster
- Funktionsgenerator
Testsystem
Denkbar ist auch ein weiteres hardwarenahes System, das die komplette externe Hardware simuliert und die Ausgaben als Eingaben auswertet und damit für den automatischen Test geeignet ist. So etwas wird auch in der Industrie angewendet für den „End Of Line“ Test in der Serienproduktion. Warum nicht also einfach eine Software auf einem Uno mit einer Software auf einem weiteren Uno testen?
Entwicklungstest
Dafür wird der serielle Monitor in der Arduino Entwicklungsumgebung benutzt, das läßt sich aber auch mit einem eigenen seriellen Terminalprogramm machen.
Integrations-, System- und Abnahmetest
Erst in diesem Stadium wird das eingebettete System in seiner Zielumgebung geprüft. Das hat Vor- und Nachteile. Kritisch wird es einen Fehlerfall zu testen, da man dafür das System in einen Fehlerfall bringen muss. Vorteilhafter wäre es, das System schon während der Entwicklung ausgiebig zu Testen. Der Fachbegriff dazu heißt „Test Driven Development“.
Testablauf Protokollieren
Nimmt man ein Serielles Terminalprogramm für die Kommunikation mit dem Board, dann kann man sämtliche Ausgaben im Terminalfenster auch in einer Datei abspeichern lassen. Hat man also einen kompletten Testablauf programmiert, der vielleicht noch mit Startkommando gestartet wird, ist auch direkt ein Protokoll damit vorhanden. Eingestellt wird das unter Einstellungen oder Optionen als Log oder Capture.
Die Testspezifikation
An der oberen und unteren Grenze kann es vorkommen, das ein „Außer Bereich!“ auftaucht, beziehungsweise, wo ein „Außer Bereich!“ auftauchen sollte, ein Messwert zu sehen ist. Das passiert dann, wenn ein Messwert durch Schwankungen in der Berechnung oder der Messung innerhalb oder außerhalb des Fensters ist. Die Messwerte werden alle etwas schwanken.
Testfall 1
Vorgabe: 30 Hz
Erwartete Ausgabe: außer Bereich!
Testfall 2
Vorgabe: 31 Hz
Erwartete Ausgabe: f = 31 Hz
Testfall 3
Vorgabe: 60 Hz
Erwartete Ausgabe: f = 60 Hz
Testfall 4
Vorgabe: 90 Hz
Erwartete Ausgabe: f = 90 Hz
Testfall 5
Vorgabe: 99 Hz
Erwartete Ausgabe: f = 99 Hz
Testfall 6
Vorgabe: 100 Hz
Erwartete Ausgabe: außer Bereich!
Testfall 7
Vorgabe: Reset am Reset Pin
Erwartete Ausgabe:
Starte Frequenz messen
F min = 31 Hz
F max = 99 Hz
Teststrategie
Die Ausgabe auf dem LCD wird ebenfalls auf einer speziellen Testadresse über I2C gesendet und für den Test ausgewertet. Dafür bekommt das Testsystem eine eigene Adresse als I2C Slave. Die Ausgaben des Testsystems werden über den USB Bus im Terminal dargestellt und als Log- oder Capturefile zur Dokumentation aufgezeichnet und abgelegt.
Ergänzung
Sollte im einen oder anderen Testfall ein NOK (Nicht Ok) vorkommen, dann ist es ratsam diesen Testfall von Hand nachzustellen, um sicher zu gehen, warum die Aussage so ist. Eventuell ist es auch besser, den Testfall anzupassen.
Das Testsystem im Einsatz
Der Sketch
Das zu testende System ist das „Frequenz messen mit dem Uno“
Das Testsystem
Die Testsuite
Mit den programmierten Testfällen, die dann automatisch ablaufen, kommt man sehr nahe an das Unit – testen heran. Mit dem dabei entstandenem Log- oder Capturefile habe ich dann direkt ein Testprotokoll zur Auswertung und Dokumentation.
Ein Testprotokoll
Links
Frequenzgenerator mit PWM auf einem Uno
https://www.arduinoclub.de/2017/06/14/pwm_signal_generieren_und_auslesen/2/
Serial Terminal Basics
https://learn.sparkfun.com/tutorials/terminal-basics/all#coolterm-windows-mac-linux
Introduction to Test driven Development
http://www.agiledata.org/essays/tdd.html
Spezifikationen schreiben
https://blog.softwareentwicklung-als-prozess.de/spezifikationen-schreiben
Unit Tests
https://blog.softwareentwicklung-als-prozess.de/unit-testing
Testspezifikation vom Messtechnik1 Projekt
https://blog.softwareentwicklung-als-prozess.de/systemtest-basisfunktionen
Frequenz messen mit dem Uno
https://blog.softwareentwicklung-als-prozess.de/frequenz-messen-mit-dem-uno
