Wir haben bereits verschiedene Bereiche der Softwareentwicklung und Systementwicklung kennengelernt,
bei dem Modelle helfen können, Korrektheit zu erzeugen,
den Aufwand zu reduzieren oder Komplexität zu beherrschen.
Testen in Kapitel 9 ist auch ein weiteres Gebiet und insbesondere deswegen wichtig,
weil, wie Sie vermutlich schon wissen,
testen einen viel größeren Aufwand erfordert als zum Beispiel Softwareentwicklung allein.
Wir werden uns damit beschäftigen,
wie man Modelle einsetzen kann und in verschiedenen Bereichen und dann das Human,
nein, das ist der falsche falsche Stift hier.
Das UML Tasting Profile besprechen. Ja, das wird ein Teil der Zeit,
wo wir wieder eine Modellierungsnotation, eine Modellierungssprache kennenlernen.
Es gibt ja noch eine Seite mit Materialien, die Sie auch im Model finden.
Doch zunächst lassen Sie uns starten damit, warum überhaupt testen.
Das ist eine Wiederholung dessen, was in der Grundlagenausbildung zu Software-Engineering schon gesagt wurde.
Wichtig ist, testen ist nicht etwas, was die Ausnahmen beschäftigt,
sondern Fehler sind quasi die Regeln und wir wollen versuchen,
Fehler durchtesten, solche Fehler aufzudecken.
Aber wir können nicht beweisen, dass wir fehlerfreie Systeme und
Software haben, sondern wir können nur das Vertrauen steigern.
Das hat damit zu tun, dass Tests immer nur Stichproben darstellen aus dem Gesamtverhalten.
Ja, und diese Stichproben können dazu dienen, Refactorings,
also Veränderungen im System zu unterstützen und nachzuweisen,
dass diese nun in bestimmten Bereichen, nämlich genau im Bereich der Stichprobe,
nicht zu Veränderungen führen.
Das Gleiche trifft zu Veränderungen,
aber auch diese Tests beschreiben ja das Verhalten eben für
diesen Bereich der Stichprobe
Und damit können sie auch als Verhaltensbeschreibung gesehen werden. Gleichzeitig zeigen sie uns,
wo Code wirklich auch wirksam ist oder welcher Code wirksam ist,
kann man daraus ableiten, wenn man die Testfälle ausführt.
Gleichzeitig helfen sie im Entwicklungsprozess,
wenn man mal die Reihenfolge des Entwicklungsprozesses betrachtet,
wenn wir frühzeitig Test definieren, nämlich vor dem Einsatz bereits,
dann haben diese Tests die Möglichkeit,
den Vorteil,
dass sie uns die Schnittstellen definieren,
bevor wir sie entwickeln und bevor wir das System entwickeln und
deswegen haben sie eine positive Wirkung auf die Gestaltung dieser Schnittstellen
Wir haben in der Grundlagenausbildung, das besondere bei SE2,
kennengelernt, das Test First, ein ganz wichtiges Paradigma, ein ganz wichtiges Grundprinzip ist.
Der Vorteil von diesem Test First Paradigma ist,
dass die Entwickler sich sehr stark auf Tests konzentrieren,
weil sie halt die Testfälle zuerst entwickeln und danach erst die Implementierung eher,
das sollte ich vielleicht nochmal sagen, für diejenigen,
die es vielleicht nicht mehr so kennen oder gar nicht kennen,
bei Test First geht es darum,
dass wir zuerst die Tests entwickeln und danach ein System entwickeln,
was diese Tests erfüllt.
Das heißt, wir machen uns zuerst Gedanken darauf,
Was soll das System überhaupt leisten im Normalfall, in einem Sonderfall?
Das heißt, wenn dort etwas nicht genau definiert ist und
Anforderungen fehlen, wert das, wird das früher klar.
Und damit entwickelt man weniger als Entwickler,
verfüllt man genau das, was dort in dieser Testspezifikation steht.
Es wird weniger Sachen entwickelt, die da nicht gefordert sind, überflüssiger Kult.
Und es gibt weniger Änderungen nachträglich, nachdem der Auftraggeber merkt,
oh, ich will ja das eigentlich anders.
Oder diese Fehlerreaktion sollte eigentlich so sein.
Nehmen wir
das frühzeitig klärt
Die Systeme, die man da nach diesem Paradigma, nach diesem Ansatz entwickelt,
werden automatisch so entwickelt, dass sie gut testbar sind,
weil eben die Tests als erstes gemacht werden und im Fokus sind.
Und das wirkt sich insbesondere auf Entkopplung hinaus. Entkopplung,
wenn Sie sagen, auch es ist ein alter Hut,
kenne ich längst, immer wieder, gebetsmüllig und artig wiederholt,
ja, Modularität ist so wichtig, ja, und Modul mit innerer,
höherer, innerer Festigkeit und loser Kopplung nach außen, ja.
Aber diese lose Kopplung ist in bestimmter Weise noch zu betrachten,
wenn wir Autogo-Testbau-System machen wollen, nämlich,
dass wir dann dafür Proxys einsetzen,
dass wir Sachen die sich schlecht testen lassen,
wie zum Beispiel mal schnell eine Datenbank aufsetzen.
Das würden wir versuchen zu vermeiden. Nämlich, weil wir
uns auf diese Tests orientieren und dann würden wir versuchen,
mit Testdaten zu arbeiten. Also bessere Testbarkeit. Ja,
das ist also ein Punkt. Testbarkeit war ein Qualitätsmerkmal,
wenn Sie sich erinnern, was zur Wartbarkeit dazugehört. So,
und natürlich erreichen wir auch, dass die Tests gut das System abdecken,
weil die Tests halt zuerst da waren und wer umfangreichere Tests erstellen.
Ja, und damit ist es uns klarer, was dort wie zusammenhängt.
Und gleichzeitig schaffen wir die Voraussetzung dafür,
dass man mit geringer Angst und mit mehr Sicherheit an Refactorings
rangeht und Refactoring deswegen mit verminderten Risiko durchführt.
Soweit erstmal zu Tests allgemein. Wir kommen gleich nochmal zu
dem Aufbau von Testsystemen, doch nun erstmal zu Testautomatisierung.
Diese Testautomatisierung ist hier, sind Sie in Stufen genannt,
Stufen, wie man das automatisieren könnte,
aber Automatisierung hat vor allen Dingen was damit zu tun,
mit Aufwand, die nicht reinstecke.
Also hier, das soll heißen wenig und das soll heißen viel Aufwand.
Und Und natürlich interessiert uns auch, wie schnell geht denn das?
Die Empfehlung, die hier aus der Pyramide spricht und die
hier von Cohen formuliert worden ist, ist die,
dass man zunächst erstmal Unitests automatisiert.
Ja, verantwortlich ist der Entwickler, das ist das,
was, wann man bei Test First eben macht.
Damit deckt man ziemlich 100 Prozent des Quellcodes ab.
Es ist nicht immer exakt 100 Prozent,
weil es manchmal Quellcode gibt,
den ich nicht erreiche durch Tests an der Schnittstelle
Ja, also wenn ich zum Beispiel Sonderfälle,
die eigentlich nicht auftreten können, trotzdem nochmal abteste,
ein zweites Mal abteste und beim ersten Mal werden sie schon abgefangen,
dann kommt dieses in den kurzer Fehlerbandlung beim zweiten Mal,
da kommt man eigentlich nie hin.
Deswegen erreicht man die 100 Prozent nicht immer. Aber prinzipiell,
wir gehen mal davon aus, so ungefähr,
außer dieser Sonderfälle, decken wir 100 Prozent ab.
Zusätzlich gibt es, oder die weitere, die nächste Ebene
ist dann auf gesamten, auf der Ebene von Komponenten.
Also eine Komponente besteht aus mehreren Klassen, möglicherweise,
vielleicht sogar mehrere Pakete. Und die sind durch Schnittstellen erreichbar,
stellen Services zur Verfügung einer API oder so etwas
Und dafür kann es sein, dass der Entwicklertest schreibt,
dass die Qualitätssicherung auf Basis von Testfallbeschreibungen, Spezifikationentests zur Verfügung stellt.
Also das ist der Bereich, wo Black Wind Whitebox Tests
kombiniert werden, während das hier vor allen Dingen Whitebox-Tests sind.
Man erreicht ja typischerweise keine 100 Prozent Testabdeckung, ganz einfach,
weil man ganz viel für Fehler abfangen im Fehlerbehandlung im System tut.
Das heißt, Fehler wird man gar nicht erst ausgeführt,
das ist der Fehlerbrennungs-Code, ist gar nicht zu 100 Prozent erreichbar im Normalfall.
So, das sind die Komponenten und die nächste Ebene drüber.
Ja, und hier ist es so,
dass die Kosten schon deutlich höher sind als die Testkosten
Unitors und auch die Ausführungsgeschwindigkeit schon höher sind,
weil wir mehr als Vorkehrungen treffen müssen,
weil wir mehr Sachen machen müssen, um den Test auszuführen.
Die nächste Ebene ist die des Gesamtsystems. Integrationstest meint,
den Test nach dem Zusammenbau. Systemtest meint quasi das Gleiche
. Also ich teste das ganze System in beiden Fällen.
Beide Fälle sind das bezeichnet. Das ganze System oder Anlass
ist ein bisschen ein unterschiedlicher. Wir können hier Testfälle anwenden,
die das gesamte Systemverhalten umfassen, zum Beispiel entsprechend Use Cases,
wo wichtige Geschäftsvorfälle dargestellt werden
Durchgelaufen, durchgeführt werden. Und deswegen haben wir hier keine komplette Testabdeckung.
Das ist einfach nicht erreichbar. Dazu sind diese Testfälle nicht
speziell detailliert genug. Hier, die Kosten auf der Kostenkurve
sind wir hier schon deutlich höher. Das heißt,
der Aufwand, den ich treiben muss, pro Test,
das ist nicht nur ein Knopfdruck und zehn Sekunden warten,
sondern muss ich einiges an Vorkehrungen bauen, treffen,
System zusammenbauen, Testdaten bereitstellen.
Das ist vielleicht sogar noch mit Menschen,
die das zusammenwirken, beobachten oder externe Systeme.
Das ist also schon sehr viel höher und entsprechend brauche ich
auch länger,
wenn wir
diese Zeitkurve hier sehen
Ja, dann gibt es noch Tests, die wirklich schwieriger sind,
wenn ich dann versuche, das Verhalten zu erkunden, insbesondere in heterogenen Umgebungen.
Also ich selbst kenne aus meiner Projektleiter-Tätigkeit Fälle, wo man wirklich lange gebraucht hat,
bis man wirklich die Ursache gefunden hat. Manchmal zwei,
drei Wochen an Tests und natürlich Behebungen versucht man,
man hat eine Hypothese, daran können es liegen,
man versucht das Szenario irgendwie zu bauen und dann stellt man fest,
das ist scheinbar doch nicht die Ursache des Tests und dann macht man es nochmal und nochmal,
das ist dann äußerst aufwendig, man braucht sehr lange,
das hat damit zu tun, dass man einerseits das Zusammenwirken testet,
andererseits auch einen großen Bereich hat, in dem man Fehler suchen muss.
In diese Fehlersuche gehört ja mit dazu, während man Tests entwickelt.
Also das ist dann entsprechend Aufwendigung. So,
also wir wollen versuchen, und jetzt sagt uns diese Pyramide,
Testautomatisierung, vor allen Dingen auf dieser unteren Ebene,
zu erreichen mit 100% Prozent Techtabdeckung und auf den höheren Ebenen,
je nachdem, wie weit wir uns die Kosten leisten können.
Das hängt ja immer mit dem Risiko zusammen,
das hängt immer damit zusammen,
wie viel ist der Kunde bereit für Qualität
zu bezahlen
Okay, soweit zu Tests, soweit zur Automatisierung.
Doch jetzt kommen wir endlich zu den Modellen. Diese Modelle,
ach so, vielleicht sollte ich, ich springe erst mal,
bevor wir dazu kommen, doch mal zurück zu den Fragen.
Wir haben mittlerweile die Frage beantwortet, welche Aussagen Tests liefern.
Das war auf der Folie 4. Ja, also das sind die Aussagen,
die uns Tests liefern und die Vorteile des Testfirst-Ansatzes waren auf der Folie 5.
Die haben wir also schon besprochen. Und das,
was wir jetzt, was wir jetzt sagen werden,
Zum modellbasierten Testen, das ist das,
was jetzt auf der nächsten Folie kommt, die wir jetzt gleich besprechen.
Ja, Modelle können uns in verschiedener Weise helfen.
Wir müssen natürlich immer davon ausgehen, das Erstellen von Modellen des Arbeitenmodellen,
das Verstehen und insbesondere das Aktualisieren von Modellen ist nicht ohne Aufwand.
Das heißt, es ist immer die Frage, lohnt sich das?
Wir fangen mal damit an, dass es ums Verstehen geht.
Beim Verstehen hatten wir ja gesagt, wir haben Modelle für jede Sicht,
für jeden Stakeholder, können wir Modelle erstellen.
Die sind eine abstraktere Darstellung, helfen uns im komplexeren Umfeld etwas zu verstehen.
Und das könnte man insbesondere beim Nehmen bei der Analyse der
Anforderungen mit den Fachleuten aus dem Anwendungsgebiet, aus der Domäne.
Also mit den Domänen-Experten können wir diskutieren,
wie ist denn der Ablauf, in dem man den Use-Case,
wie wird denn was für Zustände hat denn unser System,
was für Zustände haben die verschiedenen Artefakte, die Datenstrukturen,
wie beschätzen die sich zusammen, wie sind Grenzwerte,
was machen wir im Fehlerfall, das ist ein wichtiges Mittel,
um Anforderungen genauer zu verstehen,
um sie zu präzisieren und Widersprüche aufzudecken.
Soweit zum Verstehen
Zum Testen. Ja, wenn wir ein Systemmodell haben,
also ein Modell des Gesamtsystems, also nicht nur der Softwareteil,
sondern auch der organisatorische und vielleicht wartwertere Hardwareteile,
die drumherum stehen, so helfen die uns,
das Zusammenwirken zu prüfen.
Ja, und dabei können wir durchaus Modelle verwenden,
die erstmal Workflows darstellen, Use Cases abbilden, Regeln,
die Regeln an ihre Grenzen führen, an den Grenzen testen.
Zusätzlich helfen uns Modelle, wenn die Systeme sehr komplex sind,
weil wir Dinge ausblenden können,
weil wir Dinge in Modelle auslagern können oder in Modellen
überhaupt erstmal explizit sichtbar machen können
Geschäftsregeln sind ein typisches Beispiel dafür, ich jetzt eine
große Vielfalt von Use-Cases habe. Es ist doch einfacher,
eine Geschäftsregel als logischer Ausdruck zu beschreiben und sagen,
wenn das Limit bis dahin ist und die Bedingungen sind sowieso,
dann kommt ein Jahr raus, zum Beispiel,
ich schließe einen Kredit ab oder ich erlaube eine Transaktion oder ich führe eine Überweisung aus und andererseits vielleicht ein Nein.
Und solche Regeln abstrakt zu formulieren, ermöglicht es viel genauer
zu sagen, ist das richtig oder ist das falsch?
Wichtiger Punkt. Und jetzt, wenn wir noch Systeme betrachten,
die in einer Umgebung eingebettet sind, Beispiel ein System,
was Software ist, aber eigentlich ein Hardware-System steuert.
Wir hatten bei SISML zur Einführung so einen Kran,
der durch eine Steuereinheit gesagt gekriegt,
jetzt dahin fahren und hochheben und was anhaken oder wie auch immer.
Wenn ich da ein System testen will, ein Use-Case testen will,
dann muss ich auch ein Stück der Hardware haben.
Und wenn ich diese Hardware nicht zur Verfügung habe, kann ich nicht testen.
Ein Ausweg wäre, dass ich die Umgebung,
nämlich dieses Stück Hardware, nachbaue durch ein Modell, sorry.
Das Modell stellt, dann hat dann das gleiche Verhalten
wie dieses Stück System, wie dieses Stück Hardware.
Und damit kann ich dann die Software, die da mit Zusammenarbeit durchaus testen,
die das Modell der Umgebung ist dann so wie der Art Proxy.
Es stellt das Verhalten zur Verfügung, es stellt die Schnittstellen
zur Verfügung, aber es ist nicht wirklich das System.
Eben ein Modell. Ja, und natürlich kann ich,
und das ist hier last but not least,
ich kann durchaus auch noch ganz viel Aufwand dadurch sparen,
indem ich aus Modellen Testdaten, wir sagen häufig Testfälle,
killerieren lasse,
schreiben ruhig die Testdaten,
noch mit dazu
So, also das sind die Möglichkeiten, das sind die Vorteile,
die Tests hier haben und das ist die Antwort auf die Frage 3.
Soweit zu diesen Vorteilen, jetzt ein bisschen was zur Begrifflichkeit
und was wir da alles brauchen. Zunächst haben wir,
ach so, nein, das wollte ich,
das Bild wollte ich noch nicht bringen,
das ist ein bisschen wenig verständlich, ich wollte erstmal eins malen.
Wir nehmen mal ein leeres Blatt und fügen hier erstmal ein leeres Blatt ein,
bei mir auch, quer unliniert und ich möchte gerne ihnen
dieses Aufbau von Test- und Testumgebung darstellen.
Testgegenstand, Testumgebung Und Testsystem bezeichne ich mal das jetzt,
was zur Automatisierung beiträgt. Wenn wir mal anfangen, ich denke,
das kennen Sie alles, wir fangen mal an mit den Sachen,
die wir auf jeden Fall alle kennen,
so betrachten wir erst mal den Testgegenstand.
Ich male am Ende das ganze Blatt voll,
deswegen teilen Sie es vielleicht genauso ein wie ich hier.
Das ist seit der Testgegenstand. Das ist vielleicht eine Komponente
oder so etwas. Es könnte auch eine Klasse sein,
es könnte auch ein Subsystem sein, ein ganzes System,
irgend sowas.
Und das wird häufig bezeichnend als System Undertext an der Test
Und einschlägig ist UT als Abkürzung. Also das ist
der Testgegenstand. Mit dem fangen wir mal an.
Wenn das eine Klasse ist oder eine Komponente,
dann können die CD als solches gar nicht betreiben.
Sie können sie nicht statten, sie können sie nicht aufrufen,
damit ich überhaupt etwas damit machen kann,
brauche ich so etwas wie eine Umgebung.
Ja, ich male die einfach deswegen mal drumherum und
ich nehme mal eine andere Farbe.
So, so, so
Soweit, das soll die Testumgebung sein. Und zu dieser Umgebung gehört etwas,
was hier das System startet und was Eingaben liefert.
Eingabedaten. Zusätzlich muss es etwas geben,
was die Ausgabedaten empfängt
Also, wenn Sie eine Klasse testen wollen,
dann müssen Sie wenigstens etwas haben, was ein Objekt,
eine Instanz dieser Klasse erzeugt.
Das wäre jetzt das hier. Und was beim Aufruf
die Eingabedaten übergibt oder gar eine Sequenz von Eingabedaten.
Und was in irgendeiner Form den Returnwert nach Aufrufen wieder entgegennimmt.
Also das ist das Mindeste, was wir brauchen,
aber ganz häufig brauchen wir noch weitere Sachen,
nämlich wir brauchen so etwas wie Dienste,
die aufgerufen werden
Weil das Testsystem die halt braucht. Und manchmal gibt es
auch noch Dinge in der Umgebung. Ich hatte dieses Beispiel
mit der Hardware gesagt, wo man Signale nach draußen sendet.
Signale und dann gibt es Ereignisse. Die Liefer werden wieder zurückgeliefert.
Also das ist so, was drumherum passiert. Zum Beispiel,
wenn wir diesen Kran testen wollen und da hätten wir jetzt
hier drin die Kransteuerung, dann muss der Kran,
müsste ja gerade irgendwie einen Motor an oder etwas hochheben oder den Greifer schließen oder so etwas.
Dazu brauchte er Signale und er liefert Ereignisse zurück.
Es ist ein Anschlag erreicht worden oder das Seil ist jetzt überlastet.
Da löst ein Sensor aus, der sagt,
da hängt zu viel Kraft dran oder so etwas.
Das ist erstmal notwendig, um überhaupt diesen Testgegenstand,
dieses System an der Test damit etwas zu machen.
Damit reden wir noch nicht von einem Testautomatisierung,
sondern das kommt jetzt erstmal außenrum und das Da nehme ich mal rot dazu,
ja, und da mache ich wieder noch so einen Kasten drumherum.
So, und da brauche ich etwas, was die Testdaten bereitstellt, ja. Und ich brauche etwas,
wenn das in der ganzen nicht nur einmal statisch,
ich habe einmal Daten,
sondern ich habe eine ganze Folge von Ereignissen,
Folge von Daten, Volk auf den Eingaben,
dann brauche ich auch noch so etwas wie einen Zeitgeber,
ich nenne es mal jetzt Catular,
weil das auf anderen Bildern vorkommt,
der irgendwie sagt,
dann mache ich das
Dann mache ich das, dann mache ich das.
Also so eine zeitliche Steuerung, der mit diesem Testgegenstand quasi spielt.
So, und dann brauchen wir hier auch noch was,
was diese Ausgabendaten auswertet. Ja. Was sagt,
ist es denn richtig oder ist es falsch?
Da gibt es den Begriff Abitter dafür.
Manchmal wird das auch als Orakel bezeichnet, das Regelsystem,
was sagt, wahr oder falsch.
Das dient der Auswertung dieser Daten. Ja,
und das ist das System zur Testautomatisierung
So, und dieses Testsystem schauen wir uns in der Folge
genauer an. Das ist auch das, wo wir dann
uns darauf beziehen, was ist denn das eigentlich?
Was wollen wir eigentlich modellieren? Ich springe aber mal wieder darauf zurück.
Das ist jetzt eine Darstellung, die ich ganz verständlich finde.
Vielleicht finden Sie ja noch eine bessere irgendwo in der Literatur,
dann lass uns nämlich die gerne zukommen, dann beziehe ich mich lieber auf einen Standard.
Aber ich hoffe, dass Sie mir so folgen können.
Wir haben hier zum Beispiel die Frage 8,
auf die wir uns gleich mal beziehen wollen,
worauf was davon vor diesem System an der Test und der Umgebung könnten nennen durch das Madlab Simulink-Zeugs dargestellt werden.
Ja, wir hatten Stateful für Zustände. Und da würde ich sagen,
naja, auf jeden Fall diese Umgebung, ja,
das, was wir hier grün haben,
das könnten wir gut durch so ein,
zum Beispiel den Portalkran, den wir da als Beispiel hatten,
den Madlab Simu in den Kapitel, den können wir gut damit darstellen,
ja, oder wir könnten einen zustandsbehaftetes System, was drumherum ist.
Zum Beispiel, sie haben ein Buchhaltungssystem, für das wir
eine Komponente schreiben und das Buchhaltungssystem hat bestimmte Zustände in Sehensgrad.
Betriebsweisen, denen das gerade ist, die könnte man auch mit
einem zustandsorientierten System nachbilden. Und dann sagen, okay,
da passieren gerade das und das oder auf die Signale,
auf diese Aufrufe wird jetzt gerade reagiert und wird jetzt nicht reagiert oder passiert jetzt gerade nie um die Reaktion.
Das alles wäre denkbar, das heißt,
auf jeden Fall könnten wir hier das, was hier grün ist,
nämlich die Umgebung des Systems gut durch sowas Madlab Simulink darstellen.
Das wäre ein Beispiel. Andere Sachen natürlich auch,
aber das wäre erstmal das, was ich hier präferieren würde
Jetzt habe ich hier noch ein Bild, was so verschiedene
Dinge noch darstellt, die als Begriff hier zusammengestellt werden.
Also zunächst haben wir hier die Testumgebung.
Die Testumgebung umfasst verschiedene Testfälle. Das wäre das,
was wir vorher, was wir hier in Rot haben.
Ja, also hier gibt es verschiedene Testfälle. Diese ist
in dieser Testumgebung abgebildet. Also dafür gibt es jeweils eine Auswertung.
Diese Auswertung, die ist dann hier in diesem Abitur spezifiziert,
wenn es etwas mit einer Reihenfolge gibt,
dann ist die durch diesen Cat-Juler vorgegeben, steuerbar.
Und vielleicht gehören zu dieser Umgebung auch noch verschiedene Komponenten,
die zum Test beitragen, zum Beispiel etwas,
so ein Proxy für ein Datenbanksystem, ein Proxy für ihre Netzwerkumgebung,
irgend so etwas, was mit dazugehört.
Aber ganz wichtig, der eigentliche Testgegenstand und das ist das,
was wir, nein, andersrum, was wir hier schwarz haben.
Ja, also das alles könnte hier dazugehören, dass,
wenn wir jetzt mal hier die Grünen, die Testumgebung,
das wäre jetzt das hier,
das war das,
was wir Grün dargestellt haben
Ich finde auch, die Testumgebung mit dazugehören,
das könnte aber auch das Rote sein, auf jeden Fall das.
Und das gehört zu dem Roten. Und die Testdaten gehören
auch zu dem Roten. Soweit erstmal zu dem,
zu dem, zu dem Aufbau, zu den Begrifflichkeiten.
Jetzt komme ich, das habe ich eingefügt,
weil ich ja gerne mit Ihnen darüber sprechen wollte,
wo wir denn mit Modellen was machen.
Also wir hatten ja dieses, zwei Folien vorher gesagt,
was ist denn hier mit Modellen, was können wir denn hier machen,
die verschiedenen Sachen, die wir mit Modellen machen.
Und da möchte ich gern mit Ihnen verschiedene Szenarien durchgehen.
Plus und Minus, das ist nicht das Rote Kreuz hier,
sondern das ist das Pro von positiven Punkten.
Und wir wollen jetzt mal verschiedene Szenarien uns vorstellen.
Wir stellen uns vor, wir haben ein komplexes System und
dieses komplexe System erlaubt eine Code-Generierung. Ja,
also wir haben ein System, was das System quasi aus der Spezifikation,
aus der Beschreibung der Datenstrukturen, aus der Beschreibung der Abläufe,
können wir ein System generieren.
Und jetzt ist die Idee, okay,
dann können wir aus dem gleichen System auch doch
die Tests generieren
Nachteil dieser Sache ist,
wenn wir einen Fehler im Modell haben, zum Beispiel,
wir haben etwas falsch verstanden, das wird uns nicht auffallen,
weil es kommt ja beides aus dem gleichen Modell und da wird das prinzipiell allein übereinstimmen müssen.
Aber es hat eine ganze Reihe Vorteile, die Sie sehen,
die Liste der Vorteil ist viel länger. Zum Beispiel,
wir sparen Aufwand,
weil wir brauchen nur einmal ein Modell und da muss alle Daten enthalten,
alle Informationen für die Implementierung und ganz viele Informationen reichen dann auch schon aus für den Test.
Wir haben das Ganze nur einmal, das heißt,
wir müssen nicht ständig prüfen, wenn ich da was ändere,
habe ich dort auch geändert.
Also die doppelte Wartung muss ich nicht machen. Wir können auch tatsächlich den Generator mitprüfen,
Weil wenn der bei der Kurt-Genre irgendwas falsch wird,
läuft, dann kann es sein,
bei der Testgenerierung ist das anders und dann fällt uns so ein Fehler auf.
Ganz viele von den Generatoren haben irgendwelche kleinen Wachs,
weil sie einfach sehr komplex in die Bilde sind.
Und das würde uns dabei auffallen. Gleichzeitig sind in Systemen,
in Software immer Annahmen über die Umgebung. Und das würde
uns ebenfalls dabei auffallen, wenn wir es bei Integrationstests aufsitzen.
Gleichzeitig ist es möglich, Performance-Tests zu machen, lasst es
zu machen. Und natürlich, das ist fast selbstverständlich,
es ist klar, es entstehen Tests.
Sie werden nicht vergessen oder zu spät gemacht
oder wie auch immer
Das ist das Szenario 1. Es gibt ein zweites,
wir vermeiden diesen Nachteil, den wir eben hatten,
das ist das gleiche Modell und deswegen könnte es ja sein,
wir haben da Fehler im Modell und das passt nicht.
Wir machen verschiedene Modelle für Code und für Tests.
Ich zeige schon mal ein Bild, was wir dann
gleich bei UTP, im UMA Testing Profile haben werden.
Ja, also wir haben ein Systemmodell und daraus können wir
Code ableiten und wir haben ein Testmodell und daraus können wir Testcode ableiten.
Soweit, das wäre das,
so sieht das dann im Bild aus und das bedeutet natürlich,
wir müssen
mehr Aufwand reinstecken
Und wir haben das Problem, dass wir zwei Modelle haben.
Redundanz führt dazu, dass wir immer prüfen müssen.
Ist denn das Österkonsistenz noch da? Ja. So. Es
gibt aber auch ein paar Vorteile. Der Vorteil ist,
wir sind nicht so ganz genau unter Implementierung. Ja,
das Modell, das der Priorität,
das Modell in dem Szenario 1, das war ja so,
dass man direkt daraus implementieren konnte.
Das heißt, das war sehr detailliert.
Sehr viele technische Details drin. Während hier können wir durchaus
ein fachliches Modell machen für den Test,
was nur auf der fachlichen Ebene bleibt
Ja, gerade mal Datenstrukturenereignisse müssen wir noch nennen.
Aber nicht dieses Implementierungsdetail muss da drin stehen.
Also es sind auch Obstraktionsmögliche wie möglich,
die besser verständlich, bessere Verständlichkeit für den Auftraggeber,
für den Domänenexperten.
Besser Verständlichkeit führen Domänenexperten
Ja, und natürlich, wir haben die Möglichkeit, verschiedene Sichten darzustellen.
Und auch das trägt dazu bei, dass es besser verständlich ist. Ja,
das ist, wir haben also für den Test ein Modell,
was dessen Bedürfnissen derjenige, der die Fachlichkeit versteht, super repräsentiert.
Und genauso weit die Details liefert, bis der Detail eben untergeht,
die Implementierungsdetails enthält, wie wir sie brauchen, damit wir Testfälle machen können.
Soweit zum zweiten, ja, und hier können wir natürlich
das noch sagen, es gibt wahrscheinlich noch ein drittes Szenario.
Das dritte Szenario könnte sein, Die Entwicklung macht jemand anders,
egal wie, und wir sind für den Test verantwortlich,
ja, das heißt, wir haben, das war wieder der falsche Stift,
wir haben wieder nur Modelle für das Testen. So,
Nachteil ist, nehmen wir an,
wir haben eine Firma in der technischen Republik oder in Indien oder wo auch immer,
die für uns den Code macht, die Auftrag,
die den Auftrag bekommen hat, und wir sind diejenigen,
die vor Ort hier in Deutschland beim Anbieter,
beim Anwender, die Abnahme machen müssen, ja,
und wir müssen natürlich jedes Mal,
wenn die den Code ändern,
müssen wir prüfen,
passt denn das noch
Wir können bei dem Code modellbasierte Entwicklung nicht möglich machen,
ja. Die sind ja technisch die Tests, ja,
das ist erst mal, kann man positiv oder negativ sehen.
Der große Vorteil ist, diese Testmodelle sind das Abnahmekriterium.
Wir können sie auch hingeben. Nach China, nach Tschechien
. Und sie sind deswegen so definiert, sie können so
definiert sein, dass sie für den Kunden gerichtig sind.
Das ist das Gleiche, was wir eben im Szenario haben.
Und wir haben die Abstraktion und den Test unabhängig vom Code.
Das heißt eigentlich, das hier ist nur ein bisschen eine
andere Formulierung als das, was wir hier vorher hatten.
Das ist letztlich
das Gleiche
Soweit. Erstmal dazu, was sind, was trifft,
was sind solche Szenarien, wie können wir uns die Anwendung von Modellen vorstellen.
Damit machen wir erstmal Schluss und das nächste
kommt in einer nächsten Einheit