Wir hatten eben schon die Reviews, den Tests gegenübergestellt,
jetzt geht es weiter mit dem Testen und wir können auch
da einsetzen von den Sachen, die sie schon wissen.
Ja, dynamische Analyse hatten wir schon gerade gesagt,
es geht hier um das Testen von Software,
das wird das Testobjekt, wird ausgeführt, Ergebnisse werden ermittelt,
aber worauf ich jetzt besonders hinweisen möchte,
wir können nur Stichproben machen.
Ja, wir können das System nicht komplett ausführen und dann
anschließend vergleicht man das Ganze, ist Werte,
was erhalten, dass wir sich das gesinne Verhalten mit den
Erwarteten vorher verhalten
Ganz wichtig ist, wir können nicht korrekt halt nachweisen.
Ja, wir können nur sagen, ja,
das und das, was wir geprüft haben,
dort sind die und die Fehler oder das Leben keine Fehler.
Und wir können nicht sagen, dass sonst noch irgendein Fehler sind.
Noch viel weniger können wir durch testen, Qualität erzeugen.
Wir können nur die Abwesenheit von Fehlern in bestimmten Bereich
zeigen, nämlich nur in diesen Testfilmen. So,
Ziele des Testens sind das Nachweisen von Fehlermürgungen,
Qualität bezüglich Korrektheit und am Ende, was wir erreichen können,
Vertrauen, ich schaffe Vertrauen, der Anwender,
Vertrauen des Abnehmers, des Kunden, der am Ende bezahlt.
Und natürlich, indem wir einen Bereich getestet haben,
verhindern wir, dass Fehler zu Folgefehlern führen,
die woanders dann das Problem darstellen
Diese Frage der Vollständigkeit möchte ich mal genauer betrachten.
Und zwar habe ich hier ein ganz einfaches Beispiel mitgebracht.
Dieses ganz einfache Beispiel hat hier eins, zwei, drei, vier Verzweigungen.
Und hier unten gibt es noch einige, was wieder hochgeht.
Fünf Verzweigungen. Ja, vier Verzweigungen und die Zählschleife.
Das sind am Ende fünf sogenannte Zweige. Das haben wir
hier unten in der Definition. Zweige ist ein Pfad,
eine Kante im Kontrollflussgrafen. Pfad ist ein anderer Begriff.
Und wenn wir die Verzweigungen voneinander unabhängig durchlaufen wollen,
also alle möglichen Kombinationen dann ist erst mal die Frage,
wie viel Schleifen durchläuft.
Sagen wir mal, wir machen maximal zehn Schleifen.
Und dann können wir ermitteln, wie viel solche Kombinationen es gibt.
Ja, das ist hier diese Pfad,
der Begriff Pfad ist die Kombination dieser Wege durch den Kontrollfürstgrafen.
Und dann kommen wir auf diese nette Zahl hier mit 15 Stellen.
Ja, das ist die Anzahl der Pfade. Und wenn
wir das mal einfach mal in einem Taschenrechner mal ausgeben,
anderen werden die gigantische Geschwindigkeit für 100.000 Testfällen pro Sekunde,
würden wir immer noch für das Pesten dieses einfachen Programms
mit allen Varianten
38 Jahre brauchen
Dieses kleine Beispiel soll uns zeigen, vollständiger Test ist nicht möglich.
Und es geht da darum, Vertrauen zu erzeugen,
möglichst viel von diesen Tests zu machen. Und wie viel wir
davon machen können, das wollen wir durch eine Abdeckung feststellen.
Abdeckung ist also ein Ausdruck, Abdeckungsmaß ist ein Ausdruck dafür,
wie viel der möglichen Tests haben wir denn gemacht.
Und das bezieht sich immer darauf, wie will es denn möglich.
Wir fangen mal an mit dieser Pfadabdeckung, die hatten wir
auf der Kehlfahrt in der Fehlfolie, das ist gar nicht möglich.
Also wenn wir jetzt mal nur dieses sehr einfache Programm hier nehmen,
Stellen Sie sich mal vor, wie kompliziert das erst wäre,
mit einem Betriebssystem wie Hindows 10 oder mit Microsoft Office oder einfach nur einem roten Pandlungsprogramm,
da haben das so viele zwei Umfalle drin,
das können Sie einfach vergessen.
Keine länger als das Universum dauert. Also Pfadabdeckung ist nicht
möglich. Wenn wir jetzt sagen,
diese Zweige im Vorgehen bilden uns fünf Zweige,
das wäre möglich, kein Problem, 100 Prozent können wir erreichen.
Aber es wäre sehr wenig. Wir prüfen nur die Logik
der Entscheidungen, wenn dann mehr nicht.
Wir können nicht den kompletten Wertebereich der Daten
Es wäre die Möglichkeit, drei wäre,
dass wir Anforderungen prüfen. Dass wir sagen, okay,
es gibt die Anforderung, was weiß ich,
Benutzerdaten zu verwalten, Nutzer hinzuzufügen und Nutzer zu löschen,
die eine Zeit damit so darzustellen.
Sie gucken, wie aktiv ist die einzelne Mutter und sowas.
Das können wir machen, aber wir haben nur wenig Vertrauen und
natürlich auch nur wenig Aufwand, wenn die Anforderungen relativ grob beschrieben sind.
Wenn die Anforderungen sind, detailliert beschrieben sind, könnten wir das tun.
Punkt vier, man könnte als Maß nehmen,
die Zustände eines Programms. Und dann gibt es Zustandsübergänge.
Ja, wenn wir zuständsorientierte Systeme haben, kann man das
tatsächlich gut machen
Aber es gibt ja Folgen von Dingen, wo wir durch so
eine Zustandsfolge durchlaufen. Wie ist denn das? Wie viel
, da gibt es ja auch wieder wahrscheinlich Fehler.
Fast unendlich viele. Also das wäre auch für mich möglich.
Es können jemanden auf die Idee kommen, ich messe die
Anzahl der Tests danach, ob ich die Bedingungen alle abgedecke.
Jeweils in jeder Bedingung, den war in dem Falschzweig.
Das wäre am Ende genau das, was wir mit den Zweigen hier oben haben.
Und damit wäre es eigentlich wenig. Bedingungskombinationen,
also wir nehmen da den Fall A und da den Fall B
und da den Fall False, dann wird das schon besser.
Wir müssen die Frage, wie viele. Ja,
und dann gibt es noch gibt es noch diese Äquivalenzklassen,
also jeder Datenbereich, der zum gleichen Verhalten führt.
Das ist eine Äquivalenzklasse, der wird einmal getestet,
das wäre auch noch möglich. Am Ende müssen wir sagen,
der Testaufwand ist immer sehr hoch. Wir wollen versuchen,
den Testaufwand zu verringern, indem wir weniger testen,
aber wir wollen immer noch wissen, wie viel wir machen.
Jetzt wechseln wir langsam, nähern wir uns langsam dem,
was das mit dem Vertragsmodell zu tun hat und mit uns zu tun hat.
In SE2 haben Sie schon kennengelernt, dass es Testfälle,
dass die Testfälle, die Ausgabedaten und die Eingabedaten ins Verhältnis zueinandersetzen und dass wir Positivtests haben,
indem wir die erwarteten, beziehungsweise gültigen Werte testen.
Und damit das Vertrauen in die Korrektheit am Ende erzielen.
Negativtests kamen da nicht so stark vor, sie wurden erwähnt,
ich hoffe, sie ändern sich noch dran, dass wir unerwartete oder ungültige Eingabe gerne testen.
Eigentlich erwarten wir jetzt eine Fehlermeldung. Und wenn wir wissen,
diese Fehlermeldung kommt, und das ist eine sinnvolle Weise,
dann wissen wir ja, okay, das Programm ist auch nicht so anfällig gegen Fehler.
Zusätzlich dürfen wir nicht vergessen, man braucht unbedingt auch ein Lasttest,
lasst es, macht man nicht so,
nehmen wir einfach nur mal 10.000 Fälle durchrechnet in so und so vielen Sekunden,
sondern indem man Die Menge, die Belastung,
das können Anzahl der Hits pro Sekunde sein,
das kann die Menge der Datensätze, die ich verarbeite, sein.
Das wird die immer weiter erhöhen, bis das Programm in die Knie geht.
Und bei dieser Grenze, wo es in die Knie geht,
das können also andere Datensätze sein oder andere Hits pro Sekunde,
da wissen wir, okay, da sollen wir möglichst weit weg sein.
Und wenn wir jetzt ein Programm haben,
was zum Beispiel bei 100.000 Hits in einer Sekunde das noch geschafft,
und wir sind oder gerade in die Knie geht,
und wir sind dann im Normalfall bei 3000, dann sagen wir,
okay, wir sind so weit weg, wir sind safe.
So, hier unten, der Kasten beißt sie noch auf einen Begriffsbildung,
hier Progriffsproblem hin, positive Negativtests hat nichts mit Tun und vorzutun.
Positive Tests waren diese mit den gültigen Eingabewerten,
Negativtests,
die mit den Fehlermeldungen
So, jetzt, was Ganze mit dem Vertragsmodell?
Das trifft auch zu auf die Frage 7, die wir hier haben,
wie kann das Vertragsmodell bei der Erstellung von Tests helfen?
Das Vertragsmodell hilft uns, indem es die Zuständigkeiten klarer trennt.
Und damit können wir Testfälle sowohl für den Klienten,
für den Aufruffall als auch für den Dienstleister,
für die Durchführung einer Operation benennen.
Das Vertragsmodell liefert die Testfälle, eigentlich lief es nicht wirklich
die Testfälle, sondern nur Hinweise auf Testfälle.
Ja, also die Vorbedingungen sind dort drin,
die Nachbedingungen und wir können die Testfälle daraus aufstellen
In SE1 haben wir besprochen darüber,
dass Positivtests unbedingt erstellt werden und Negativtests eventuell,
wenn man Zeit hat, wenn man Lust hat,
wenn man sie benötigt.
So, das heißt, Korrektheit war ein Muskriterium und eine
Robustheit war nur noch ein Kann.
Wenn wir konsequent nach dem Vertragsmodell arbeiten, dann sollten wir Negativtests vermeiden.
Das ist jetzt unsere Empfehlung in SE2.
Ich möchte Ihnen sagen, diese Empfehlung fällt uns nicht leicht
Von Negativtests etwas Wichtiges sind. Vertrauen für das Prüfen,
auch eine Fehlermeldung, wirklich kommt, ist wichtig.
Aber um das tun zu können, müssten sie
Assert-Prüfungen ausschalten können. Müssen sie die tatsächlich auch ausschalten.
Und wenn sie die ausschalten, er würde das bedeuten,
wir haben, wir benutzen sie nicht mehr.
Und das wäre für den gesamten Testablauf, in wie wir
das hier mit Testfirst machen wollen, doch relativ schwierig.
Und deswegen empfehlen wir ihnen das nicht.
Aber eigentlich muss man sagen, ja,
außerhalb von Assi zwei Negativtests
sind etwas Wichtiges
Lassen Sie uns zu dem Punkt zu einem Begriff kommen,
den wir hier in dem Zusammenhang brauchen, Testbarkeit.
Testbarkeit ist ein Punkt, wo es darum geht,
Barkeit, sprich, das sind immer so Eigenschaftswörter,
die bezüglich eigentlich Aufwand sich beziehen.
Also wir hatten Benutzbarkeit, das ist der Aufwand für die Benutzung,
Marktbarkeit ist der Aufwand Veränderungen. Und Testbarkeit ist der Aufwand
für das Testen. Und zwar Teilaufwende des Testens sind,
wir müssen erstmal einen bestimmten Anfangszustand eines Exemplars,
eines Objekts erreichen, bevor wir einen Test machen.
Zum Beispiel, Sie wollen irgendwas mit einer Datenbank machen,
wollen es hinzufügen eines Elements beobachten, bewerten.
Da müssen Sie erstmal die Datenbank aufsetzen,
ein paar Datenfelder rein, die Beziehung herstellen.
Bevor Sie das hinzufügendes Element machen können
Diese Ausführung einer Operation wollen wir uns Eingaben machen.
Und das ist ein Teil der Aufwand des Aufwands.
Und dann wollen wir den Zustand danach ermitteln. Ganz klar,
der mittlere Punkt ist völlig da, aber der erste und der
dritte Punkt sind etwas schwieriger, wenn wir Kapselung haben.
Das ist bei Objekte und Tieren typisch. Wir haben diese privaten Operationen,
nein, sorry, die privaten Attribute, die bereiten Member.
Und dann, wir können nicht einfach nur den Anfangszustand
dadurch machen, dass wir einen Wert schreiben.
Mit Set schreiben wir da im Wert rein.
Das haben wir in den meisten Fällen nicht,
sondern wir müssen eine Folge von Operationen durchführen,
um das zu machen
Auch das Prüfen von Nachbedingungen wird uns gekapselt,
zum Beispiel beim Vertragsmodell, in dem Fehlerwirkungen nicht sichtbar werden,
weil wir eben das Vertragsmodell umgesetzt haben.
Die Vorbedingungen können wir prüfen von Assert,
aber in der Negativtests machen würden, würde die Vorbedingungen ja schon das verhindern,
dass wir die Formulierung einer Vorbedingung würde finden,
was für eine Aufregung überhaupt stattfinden lassen können.
Und was noch ein ganz großes Problem wäre,
was wir vermeiden müssen, sind tygische Benutzbeziehungen,
Informatiken generell, sollten Zyklen vermeiden, sollten Zyklen hassen.
Deswegen hier haben wir noch ein Beispiel mit den Zyklen.
Wir gehen nicht ganz drauf ein. Sie kennen diesen Keks
schon. Das ist das Weiterführende,
was wir Ihnen dann als Hausaufgabe lassen für Leute,
die interessiert sind, die das noch ein bisschen genauer wissen.
Wir wollen nur sagen, nur so viel für alle anderen
reicht es zu wissen, zügliche Abhängigkeiten sind schlecht. Fürständlichkeit,
Testbarkeit, Änderbarkeit und dieses Beispiel sagt noch mal anhand der Sachen,
die hier im Kasten steht, wie kriege ich denn raus,
wenn das, was die Ursache wirklich ist?
Ja, wenn Zeile Bremen ja feststeht,
das ist diese Methode, bieke ich denn raus,
wie er hier von wem abhängt oder was nicht das
Werfen geben,
sondern wo die Ursache liegt
So, das, ja, Punkt, und jetzt möchte ich noch zum Test-First-Ansatz kommen.
Der Test-First-Ansatz, den haben wir hier auf der Frage,
bei der Frage 8, nennen Sie Argumente für den Test-First-Einsatz.
Test-First hat, spielt eine besondere Rolle bei agilen Entwicklungsmethoden,
agile Entwicklungsmethoden sind ja Weltenmethoden, die es leicht machen, Änderungen durchzuführen.
Ja, wir haben nicht erwarten, nicht wasserfallmäßig,
zuerst die Antwortungen, da werden die abgeprüft und dann sind die fest,
immer wenn sie unveränderbar gestellt,
dann macht man den Entwurf und dann wieder unveränderbar.
Und dann, nein, wir machen das immer in kleinen Zyklen,
in diesen Sprints bei Scrum. Und wir haben Änderungen dadurch
leichter. Aber wenn wir so viele Änderungen haben,
haben wir auch, das ist ein großes Risiko für Fehler.
Und deswegen versuchen wir für jede Testklasse, für jede Klasse eine Testklasse zu schreiben.
Und der Test First-Einsatz, den wir ihnen dringend naheliegen,
den wir hier unterrichten und den wir ihnen vermitteln,
und dass er Auftrag ist, bedeutet,
dass ich für jede Testen gibt, Testklasse zuerst schreibe.
Sie schreiben also die Testklasse vor, der zu testen lasse.
Dann betrachten wir pro Methode Problemlösung, Handbedingungen in dem Testfall.
Und wir haben dadurch, dass wir den Testfall schon geschrieben haben,
können wir eine neue Methode beziehungsweise eine neue Klasse sofort testen,
wenn wir sie geschrieben haben.
Auch wenn wir das Ganze integrieren, mit anderen Sachen zusammenbauen,
das ist ja das Integrieren, mehrere Klassen zusammensetzen,
mehrere Module zusammensetzen, können wir Testfälle sofort durchlaufen.
Und später, wenn wir Veränderungen vornehmen,
können wir die Tests einfach automatisiert nochmal durchführen und dann
haben wir uns leicht Änderungen durchzuführen
Wenn wir mit Praktikern sprechen, kriegen wir manchmal Widerspruch gegen Testfürst.
Es gibt Leute, die der Meinung sind, ach nein,
viel zu vieler Aufwand. In der Tat ist,
oder sie sagen ihnen, schau dir doch mal diese Testklasse an,
dieses Dreimal oder vielleicht sogar zehnmal so auf,
wenn ihr zehnmal so viele Zeilen, wie die eigentliche Klasse.
Das ist doch Schwachsinn, mache ich nicht. Tatsächlich ist es so,
dass der Testaufwand generell höher ist als der Entwicklungsaufwand.
Man spricht von Faktor 3, manchmal in manchen Fällen sogar
von Faktor 10, die in der Testaufwand höher ist.
Und der Testaufwand spiegelt sich natürlich hier in der Größe
der Testklassen wieder
Aber behindert mich denn diesen Aufwand? Ich muss sie sowieso leisten, wenn ich einen Test mache. Ja, dann kann ich den Test auch vorher machen. Weil,
indem ich mir vorher Gedanken mache, was für Randbedingungen bestehen,
die ich in den Testfall aufnehme,
weiß ich viel genauer, wie das Verhalten sein soll,
als dass ich mal irgendwie erst mal was programmiere und dann habe ich einen Test,
ich mache einen Testfall und dann merke ich, oh,
das gibt es ja noch den Sonderfall,
in dem Sonderfall, in dem Sonderfall fragt den Auftraggeber,
die Experten des Kunden,
wie geht denn das Ganze?
Nein, es ist viel besser,
wenn ich mir vorher Gedanken mache über die Testfälle,
über die Test,
über die Testklasse schreiben,
schon eine
sehr genaue Verhaltensbeschreibung aufstellen
Der weitere Vorteil ist, wenn ich automatisierte Tests habe,
habe ich die Möglichkeit, bei späteren Veränderungen sehr viel sicherer heranzugehen.
Eine von diesen, bei agilen Methoden, eines der Prinzipien ist Mut, Mut zur Veränderung.
Und diese Mut für zur Veränderung ist viel leichter,
wenn ich weiß, ich werde abgesichert durch Testfinden.
Und deswegen, ich habe das als Projektleiter selbst bemerkt,
ab dem Zeitpunkt, an dem der automatisierende Tests haben,
waren die Entwickler bereit, auch nochmal was umzustrukturieren,
eine Tabelle zu zerlegen, eine Klasse zu zerlegen,
was sie vorher nie gemacht haben.
Never touch a running system, dieses Entwickler sind bei
großen Systemen
sehr risikobewusst
Und Risiko vermeiden, was ja gut ist.
Aber wir müssen manchmal verbessern, um die Struktur zu erhalten,
um lassen die nichts miteinander zu tun haben,
auch wirklich zu trennen und solche Sachen.
Und das wird überhaupt erst ermöglicht,
so ein systematisches Refactoring, wenn wir Tests haben.
Damit literaturhinweise brauchen wir jetzt nicht die Sendung,
wo Sie zum Plan lesen,
damit sind wir am Ende der zweiten Vorlesung
und wir sehen uns gleich zu den Fragen