Risiko Unit Test

[Siro]

Hallo zusammen,
ich muss mal etwas fragen zum Thema Unittest.
Wuste jetzt nicht wohin damit, daher hab ich das mal hier eingeparkt.

Der Unittest dient ja dazu, seine Software zu testen und zu beweisen dass die Funktionalität gegeben ist.
Eigentlich sollte dann daran nichts mehr geändert werden...

Es gibt aber Situationen, in denen ich eine Manipulation der eigentlich "fertigen" Unit machen muss
um die Funktionalität zu beweisen.

Beispiel:
Die Unit Timer.c ist fertig und soll getestet werden.

Es soll jede Millisekunde einen Interrupt ausgelöst werden.
Von außen ist dieser Interrupt bzw. die Funktion eigentlich nicht sichtbar.
Also habe ich, lediglich für den Unittest, in meinem Timerinterrupt ein Portbit getoggelt an dem ich dann mit einem
Oszilloskop beweisen kann, dass dieses Bit sich 1ms auf Low und dann 1ms auf High befindet,
Zudem habe ich einen Freqeunzzähler angeschlossen und messe dann 500 Hz.
So habe ich die korrekte Timerfunktionalität bestätigt.

Wenn ich nun vergesse den Testcode wieder rauszunehmen, dann toggelt dieser Pin weiter im Millisekundentakt,
wo später etwas anderes dran hängt.
So doof kann man doch nicht sein..... doch kann man...zumindest ich....
man wird unterbrochen, macht eben was Anderes und.....

Ist jetzt nur ein Beispiel gewesen, hier noch eines:
Um zu prüfen ob meine CPU wirklich auf 100 MHz taktet, habe ich den Clockout aktiviert,
der normalerweise nicht benötigt wird. An diesem Pin liegt beim Endcode ein Fussschalter.
ich muss aber "mehrere" Register umschalten, damit mein Clocksignal an diesem Pin ueberhaupt messbar wird.

Auch hier habe ich wieder die Möglichkeit beim restaurieren des originalen Codes Fehler einzubauen.

Wie macht man das eigentlich am sinnvollsten ?
Ein komplett neues Projekt anlegen und alle Tests darin manipulieren und testen ?
Habe ich dann eigentlich den "richtigen" Code getestet könnte man sich nun fragen....
Man könnte es evtl. auch über ein Flag mittels "conditional compiling" steuern, aber ich finde das teils recht unübersichtlich.

Siro

[HaWe]

Wie macht man das eigentlich am sinnvollsten ?
Ein komplett neues Projekt anlegen und alle Tests darin manipulieren und testen ?
Habe ich dann eigentlich den "richtigen" Code getestet könnte man sich nun fragen....
Man könnte es evtl. auch über ein Flag mittels "conditional compiling" steuern, aber ich finde das teils recht unübersichtlich.

Siro

ich mache es tatsächlich genau so, ohne in Anspruch zu nehmen, es hier zu machen wie Fachleute es tun:
- spezielle Testprogramme für Basis-Teilfunktionen, wenn erfolgreich getestet, dann in Projektcode übernehmen
- #define _DEBUG_ // diverse _DEBUG_x_y_z_ plus #ifdef _DEBUG_ usw. für eng umschriebene Programmzeilen, z.B. temporäre für Variablen- oder Performance-Überprüfung per Konsole; sobald keine Fehler mehr erkennbar, dann komplett wieder rauslöschen wegen Übersichtlichkeit

[shedepe]

Du musst an der Stelle zwischen Unit und Integrationtests unterscheiden.
Das was du schon testen willst, ist die Integration von Code und Hardware.

Unittest sind wesentlich einfacher als Integrationstest. Da verifiziert man nur: Ich gebe in Methode A Daten X rein und erwarte dabei Daten Y als Ausgabe.
Dazu wie man Gesamtfunktionalität testet gibt es unterschiedliche Herangehensweisen. Den goldenen Weg gibt es dabei aber nicht.
Von stückchenweise Funktion sicherstellen wie du das machst, bis hin zu ein komplettes Testsystem entwickeln, dass die Ein und Ausgänge überprüft gibt es viele Möglichkeiten.
Da muss man schauen was für einen pragmatisch ist. Wenn es ein professionelles Projekt ist, hat man hoffentlich im Vorfeld bestimmte Tests definiert die erfüllt werden müssen.

Wenn man wirklich auf Nummer sicher gehen will, kommt man nicht darum komplett die erwarteten Ausgaben auf vor definierte Eingaben zu überprüfen von extern und eventuell auch intern nachzuvollziehen (Bei Space Projekten z.B. bis auf Signallaufbahn-Ebene)

Ich würde in deinem Fall einzelne Komponenten entwickeln (z.B. die Clock Einstellung oder der Timer) diese Testen und in einem funktionsfähigen Zustand in das eigentliche Projekt einpflegen. Das ist ein Kompromis was Aufwand und Testaussagekraft angeht.

[Holomino]

Im Buch "der pragmatische Programmierer" findest Du den Begriff "Prototyp" (hat nix mit Prototying in JS zu tun)
Meint:
- Baue für eine Aufgabenstellung einen funktionierenden Prototypen
- Schmeiß den Prototypen wech
- Baue es ordentlich

Mit etwas Phantasie praktisch übersetzt:
- Reiß nen Projekt auf
- Schreibe Deine Register für nen Timer in die Main und fummel es zurecht, bis es läuft
- Mach nen Modul mit ner Funktion, deren Parameter die möglichen Variablen (Zyklus/Timernummer, mit/ohne Interrupt/Pintoggle) der Aufgabenstellung beschreiben. Nimm den Prototypencode aus der main raus und passe ihn in der Funktion an, bis Du denkst, es läuft.
- Baue nen Header dazu
- Schreib in die main Deinen Test (Funktionsaufrufe über alle Timer mit unterschiedlichen Funktionen und Zykluszeiten) und teste, bis der Arzt kommt.


Dann hast Du ein Testprojekt, aus dem Du die Funktion als Modul/Header entnehmen kannst, dass sich aber auch noch weiter eigenständig pflegen/erweitern lässt.

Die Hauptproblematik dabei: Ansprüche steigen mit der Anzahl der Anwendungen, also mit der Zeit. Wer beim ersten Schuss zu weit daneben liegt, darf rückwirkend Änderungen kompilieren und neu testen oder er betreibt früher oder später Wildwuchs in der Versionitis.

[Siro]

Ersteinmal vielen Dank für eure Informationen.
@HaWe
Das könnte ich also vorerst, teilweise, direkt mit in den Code reinnehmen.
Ich hab ja eh immer eine "Debug" und eine "Release" Version.

@shedepe
Okay, das es noch einen "Integrationstest" gibt wuste ich noch nicht.
Das schaue ich mir auch mal an.

@Holomino
Dann habe ich, unwissentlich, genau nach diesem Buch gearbeitet.
Ich fange ja immer mit den untersten Schnittstellen an und die werden dann entsprechend getestet.
Das man hier sorgfältig sein sollte, habe ich auch leidlich erfahren müssen.
Ein verschobenes Problem (drum rum programmiert) fällt einem irgendwann wieder auf die Füsse.


Ehrlich gesagt, hab ich meine Module (eigentlich die ganze Software) ja schon längst fertig und getestet,
aber es fehlt, wie so oft, die Dokumentation dafür.
Dokumentation kommt eigentlich immer erst wenn das Gerät fertig ist.

Ich mache dies auch zum ersten Mal und merke jetzt schon, dass ich mit der gesamten Dokumentation völlig überfordert bin.
Aber wer sollte das sonst auch machen ? Das kann ja eigentlich nur der Softwareentwickler.

Bisher sind wir ohne Softwaredokumenation ausgekommen, es handelt sich ja um ein Embedded System ohne Schnittstellen nach außen.
Also nur eine Firmware. Es wurde immer, für Risikoanlysen usw., das gesamte Gerät betrachtet.

Nun soll ich, unter vielen anderen Normen, auch nach IEC-62304 alles Dokumentieren.
Muss das eigentlich generell der Softwareentwickler machen ? ohne externe Hilfe dürfte das ziemlich aussichtslos sein.

Siro

[Moppi]

Ach herjemine, außgerechnet nach IEC-62304!

Aus Erfahrung kann ich Dir sagen, dass es am Einfachsten ist, wenn Du Software sofort dokumentierst. Zuerst musst Du Dir klar werden, was zu dokumentieren ist. Ich würde mir so eine Art Inhaltsverzeichnis anlegen und dass dann verifizieren, ob alles vollständig ist. Dazu muss man sich mit den einzelnen Anforderungen und Begrifflichkeiten (IEC-62304) auskennen. Dann hätte ich ein Gerüst zur Doku. Außerdem festgehalten werden Ziele, Voraussetzungen, zu erwartende Probleme und Lösungsansätze grob skizziert. Dann würde ich mit der Software loslegen und mich an meinen "Plan" halten. Habe mal eine "einfache" Projektdoku zu einem Mini-Programm gemacht, für die Prüfung damals. Da gab es aber keine so besonderen Anforderungen, das war noch relativ human. Dort habe ich das aber auch so gemacht. Ich habe mit dem INhaltsverzeichn is der Doku angefangen und das dann mit Inhalt gefüllt, nebenbei die Software geschrieben. Dann wenn Module funktionierten, den PAP dazu erstellt und die notwendigen Anmerkungen dazu gemacht. Eine Dokumentation kann man auch hinterher erstellen. Allerdings ist das nicht minder langwierig. Leider! Bei Änderungen wird die Doku immer wieder ergänzt und geändert, das bleibt nicht aus. Aussichtslos ist so eine Doku sicher nicht, wenn man die hnterher erstellt, man muss nur Ausdauer mitbringen. Bei sehr großen Projekten geht das leider gar nicht anders, als die Doku immer nebenbei zu führen. Das ist auch schon wichtig, weil man in einem Software-Unternehmen selten alleine arbeitet, ist eigentlich immer Teamarbeit und dort wird in Englisch dokumentiert und bevor man seinen Programmcode für andere im Team zugänglich macht gehört ein Mindestmaß an Dokumentation sowieso dazu.

Da hast Du was vor...

Sämtliche Begrifflichkeiten aus der Systemprogrammierung zu kennen ist eigentlich obligatorisch, zumindest, dass man die Sachen schon mal gehört hat und die einsortieren kann. Man muss nicht immer alles wissen, man muss nur wissen wo es steht.

Der Unittest dient ja dazu, seine Software zu testen und zu beweisen dass die Funktionalität gegeben ist.
Eigentlich sollte dann daran nichts mehr geändert werden...

Das ist mit modularer Programmierung und objektorientierter Programmierung möglich. Dabei wird nicht im Programmcode des Moduls getestet und dort drin rumgeschrieben, sondern das Modul bleibt immer "rein". Da es eine Schnittstelle hat, kann man dort die Test-Daten reingeben und schauen, was aus dem Modul zurückkommt. Das reicht eigentlich aus. Funktioniert das Modul, nimmt man Kriterien, nach denen bewiesen werden kann, dass es funktioniert, wie es soll. - Dabei das Dokumentieren nicht vergessen! (was ja nun wohl schon passiert ist). Die Dokumentation hilft während der Entwicklung, dass der Code fehlerfrei ist und die Anforderungskriterien erfüllt sind und man die nicht aus dem Auge verliert.


MfG
Moppi

PS: Kläre mal die Haftungsfrage, falls sich in Zukunft rausstellen sollte, dass mit der Dokumentation was nicht stimmt oder so ähnlich. Das müsste bei Medizingeräten doch eigentlich fachlich alles 1A in Ordnung sein oder? Mir kam nur so der Gedanke, dass das Eisen vielleicht etwas zu heiß ist.