|
|
|
unit tests / Komponententest |
|
| Bluesmaster |
Forum-Century
|
 |
Beiträge: 203
|
|
|
|
Anmeldedatum: 13.11.11
|
|
|
|
Wohnort: Gera
|
|
|
|
Version: 2012a
|
|
|
|
 |
|
Verfasst am: 06.02.2013, 13:10
Titel: unit tests / Komponententest
|
 |
|
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 06.02.2013, 15:06
Titel: Re: unit tests / Komponententest
|
|
| |
 |
 |
Hallo Bluesmaster,
Ich habe mir nicht alle Links angeschaut. Denn es gibt eine grundsätzliche Antwort: Es ist egal, welches Framework Du zum Testen verwendest! Das eine mag vielleicht ein wenig effizienter sein, aber es geht immer darum, ob Du Monate benötigst um einen Bug in 200'000 Zeilen Matlab-Code zu finden, oder eben 2 Minuten, bzw. 2 Minuten und 30 Sekunden.
Ein guter Komponenten-Test kann auch mit handgemachtem Code erfolgen, solange man sich an gewisse Standards hält. Wichtig ist dabei:
1. Die ordnungsgemäße Behandlung von Standard-Inputs muss getestet werden.
2. In Known-Answer-Tests wird der Rückgabe-Wert in möglichst umfassenden bekannten Fällen überprüft. Zudem sind Random-Input-Tests hilfreich Fälle zu finden, an die man einfach noch nicht gedacht hat.
3. Es muss kontrolliert werden, dass die Funktion sinnvoll auf falsche Inputs reagiert (am besten mit einem Fehler): Falsche Anzahl von Inputs, falscher Type, falsche Dimension
4. Die Tests müssen automatisch ablaufen, damit man sie auch wirklich regelmäßig durchführt.
5. Die Ergebnisse der Tests müssen extrem einfach zu druchschauen sein. Wenn der Programmierer 120kB Text-Output durchsuchen muss um Fehler wahrzunehmen, wird das nicht funktionieren. Am besten ist eine Liste mit allen gescheiterten Funktionen. Solange diese dann nicht leer ist, ist das Programm-Paket nicht erfolgreich getestet.
6. Wenn ein Fehler auftritt, muss die Ausgabe so verständlich wie irgend möglich sein. Ein ellenlanger Fehler-Report bringt nicht viel, wenn man nicht weiß, wo man was verbessern muss.
7. Ein Loggin ist essentiell. Natürlich wird irgendwann ein Fehler auftreten, und dann muss man wissen, wann die Funktion zuletzt erfolgreich getestet wurde und was sich seit dem verändert hat.
8. Zudem sind noch Integration-Tests hilfreich: Auch aus 1000 exzellent getesteten Matlab Funktionen kann man ein Programm konstruieren, das Fehler enthält.
9. Die Unit-Tests dienen der Qualitätskontrolle. Damit diese überhaupt ein Ergebnis hat, muss man die Qualität messen (egal wie) und protokollieren.
Ich selbst bevorzuge manuell erstellte Unit-Tests, da ich die leicht mit Code ausliefern kann, den ich z.B. im FileExchange veröffentliche. Dann kann der Downloader mit dem Unit-Test herausfinden, ob der Code auch unter seiner Matlab Rxyz/64bit/Linux-Version so funktioniert, wie ich mir das vorgestellt habe. Wenn er dazu erst ein eigenes Test-Framework installieren muss, wird das im Allgemeinen am Aufwand scheitern.
Wenn sich dagegen TMW entschließen könnte, eines der Test-Frameworks in Matlab zu integrieren, würde ich sofort darauf umsteigen.
Gruß, Jan
|
|
|
|
| Bluesmaster |
Themenstarter
Forum-Century
|
|
Beiträge: 203
|
|
|
|
Anmeldedatum: 13.11.11
|
|
|
|
Wohnort: Gera
|
|
|
|
Version: 2012a
|
|
|
|
|
|
|
Verfasst am: 06.02.2013, 18:12
Titel:
|
|
Danke Jan für die sehr umfangreiche Antwort.
Da ich nicht aus dem informatischen Bereich komme, war mir
bis vor kurzem gar nicht klar, dass es beim Thema
Testen solche systemischen Lösungen gibt.
Deine lange Antwort macht mir klar dass Unit und Integrationstests
anscheinend eine sehr hohe Relevanz haben.
Besonders das Thema "Logging" interessiert mich.
Geht es dabei eher um Code-logging ( Versionsverwaltung/svn/cvs)
oder um das loggen der Ein- und Ausgabewerte?
Und wenn letzteres wieso sollten die sich ändern, die Tests
sollten doch unabhängig voneinander sein? (Wikipedia > Anfänger)
Und da ich oft Oberflächen entwickle: Wie kann ich deren Verhalten
testen? Diese haben ja nicht direkt eine "known-answer"
Über Antworten freue ich mich ( gern natürlich auch weitere Erfahrungen)
Gruß
Blues
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 07.02.2013, 12:14
Titel:
|
|
| |
|
|
Hallo Bluesmaster,
Bei der Entwicklung großer Programme gibt es eine magische Grenze von 100'000 Zeilen Code, die ein einzelner Programmiere noch überschauen kann. Wenn ein Programm größer wird oder mehrere Programmierer daran arbeiten kommt man um eine ordentliche Dokumentation aller Einzel-Funktionen und automatische Tests nicht herum. Andernfalls is die Komplexität so groß, dass die kleinste Änderung, z.B. auch ein Bugfix, zu unkontrollierbaren Effekten auch an ganz anderen Stellen führen kann. Objekt-Orientierte Programmierung ist dann eine große Hilfe, weil hier einzelne Teile voneinander gekapselt werden, aber eine einfache Patent-Lösung ist dies trotzdem nicht.
Große Software-Projekte, die an der explodierenden Komplexität scheitern, gibt es in großen Massen. Google findet (zu) viele herrliche Beispiele von grandiosen Fehlplanungen, bei denen z.B. eine deutsche Krankenkasse mal eben eine Milliarde (nicht Million!) Entwicklungskosten in den Sand gesetzt hat.
Man benötigt sehr dringend eine Versionsverwaltung des Codes, um Änderungen zu protokollieren und kontrollieren zu können. Andererseits muss das Testen ebenfalls damit verbunden sein. Wird für eine Funktion ein neues Feature entwickelt, muss man auch testen, ob alle anderen Funktionen auch damit klarkommen.
Die Tests sollen unabhängig voneinander sein, aber die Funktionen hängen voneinander im Allgemeinen ab. Wenn ich eine effizientere SQRT-Funktion implementiere, muss diese zunächst der Unit-Test geprüft werden. Meine 2-Norm-Funktion kann dann aber trotzdem noch unerwartete Änderungen erfahren, so dass auch diese Funktion neu geprüft werden muss. Nun sind die Tests voneinander unabhängig, die Funktionen aber nicht.
Ich hatte einmal große Schwierigkeiten mit einem Test-Durchlauf, weil ich einen Bug in "isEqualTol" hatte, welches die Gleichheit mit einer relativen und absoluten Toleranz testet. Durch Rundungsfehler kann sich ja das Ergebnis einer M- und C-Implementierung unterscheiden, ohne dass die Funktionen grundsätzlich nicht equivalent sind. Nun riefen aber fast 100 Testfunktionen isEqualTol auf um Ergebnisse zu vergleichen und der Bug darin führte zu hunderten Seiten Fehlermeldungen. Das war also ein grober Design-Fehler.
Die GUIs lassen sich testen, wenn man dies von vornherein im Design berücksichtigt. Dazu muss die Benutzeroberfläche streng von den eigentlichen Berechnungen getrennt sein. GUIDE macht das strukturierte Vorgehen viel schwerer, darum verzichte ich grundsätzlich darauf ausser um testweise die Buttons hin-und-her zu schubsen um zu beurteilen, was hübscher aussieht. Ein GUI-Known-Answer-Test wäre dann das Setzen bestimmter Werte (String in Edit-Felder, Values von Check-Boxen und Toggle-Buttons etc) in den UICONTROLs, dann das Auslösen von Callbacks (das geht ja eben auch per Programm) z.B. eines Start-Buttons. Dann wird nicht das eigentliche Programm aufgerufen, sondern mit einer Liste der Argumente eine eigene Test-Funktion. Dazu benötigt das GUI also einen "Test-Mode", der sich möglichst nur in dem Punkt vom normalen Mode unterscheiden darf, dass die Ausgabe getestet wird, statt die Berechnung zu starten. Der GUI-Test testet also wirklich nur das GUI, während die Berechnung ein ganz getrennter und eigenständig getesteter Punkt ist.
Eine solche Funktionialität lässt sich kaum im Nachhinein ein ein GUI hineinpfriemeln.
Gruß, Jan
|
|
|
|
| Bluesmaster |
Themenstarter
Forum-Century
|
|
Beiträge: 203
|
|
|
|
Anmeldedatum: 13.11.11
|
|
|
|
Wohnort: Gera
|
|
|
|
Version: 2012a
|
|
|
|
|
|
|
Verfasst am: 07.02.2013, 19:04
Titel:
|
|
Das sind wirklich wertvolle Einblicke, und ich danke dir dass du dir die Zeit genommen hast.
Komplexität ist ein Risiko. Und das Beispiel mit der Krankenkasse ist wirklich
brutal, immerhin gibt es Länder, die haben noch nicht einmal so ein Bruttoinlandsprodukt.
Aber Komplexität ist auch ein eine einzigartige Chance, gerade weil sienicht jeder beherrscht.
Ein Flaschenhals durch den auch der gewichtigste Konzern nicht einfach hindurchschlüpfen kann egal wieviel Geld er in die Hand nimmt, wenn er
nicht die richtigen Leute mit den richtigen Methoden hat.
Auf jedenfall ein lohnendes Gebiet mit dem ich mich weiter beschäftigen werde.
Gruß
Blues
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.492
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 30.03.2013, 22:38
Titel:
|
|
|
|
|
| Bluesmaster |
Themenstarter
Forum-Century
|
|
Beiträge: 203
|
|
|
|
Anmeldedatum: 13.11.11
|
|
|
|
Wohnort: Gera
|
|
|
|
Version: 2012a
|
|
|
|
|
|
|
Verfasst am: 31.03.2013, 09:21
Titel:
|
|
Jup, das habe ich auch schon bemerkt.
Damit erübrigt sich denke ich auch die Qual der Wahl zwischen
den ganzen 3rd-Party Angeboten.
Zumindest sobald ich sobald ich wieder was übrig habe
für eine neue Lizenz 
Gruß
Blues
|
|
|
|
| Super8film |
Forum-Fortgeschrittener
|
|
Beiträge: 57
|
|
|
|
Anmeldedatum: 13.06.12
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 12.10.2016, 08:54
Titel:
|
|
Ist zwar ein älterer Beitrag, aber ich dachte es vllt doch recht aktuelles Thema immer noch.
Habt ihr bereits Erfahrung mit den Testing Frameworkhttp://de.mathworks.com/help/matlab.....-unit-test-framework.html gesammelt? Kann man es auch für Simulinkmodelle verwenden? Ich habe bisher noch keine Zeit in ein eigenes Beispiel für mich persönlich reingesteckt.
Ich würde gerne etwas verwenden wo das Framework stimmig ist und ich nicht noch das Framework selbst abtesten muss. Deswegen möchte ich nicht wieder selbst Skripte nehmen, sondern meine bisherigen Sachen gerne in ein bestehendes Framework übernehmen.
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2024
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
