Auch wenn wir jetzt festgestellt haben,
dass die statischen Maßnahmen Reviews, Inspektionen sehr viel mehr bringen,
als Tests, fangen wir trotzdem mit den Tests an.
Das hat einen einfachen Grund, der kommt in den Übungen eher dran.
Deswegen starten wir jetzt mit dem, ich springe ein paar Folien weiter,
wir werden hier gleich Fragen anschauen, dazu.
Und diese Folie nehmen wir als Start.
Ich schreibe hier das mal, die neue Gliederungsnummer dran.
Das kriegen wir hoffentlich oben drüber.
Das wäre
Anna, nee, wir nennen das gleich dynamische Maßnahmen.
Namen. Tests kommt auch hier. Rote Linie,
ihr müsst eigentlich zwei rote Linien kriegen. So,
also das soll so die Einführungsfolie sein für diesen Abschnitt.
Und zunächst das, was grundsätzlich, ich denke,
die meisten von ihnen ist das völlig selbstverständlich,
lassen sie uns trotzdem nochmal sagen.
Es geht darum, beim Test,
dass wir eine Software ausführen, indem wir Testdaten verwenden.
Das geht also nicht um Schrittbetrieb für diejenigen. Es gibt ja
manchmal ein paar Leute, die noch nicht programmiert haben,
die dann denken, ach, ich gehe so schrittweise durch.
Nein, das wäre die Bucking. Wir beim Test wird
die Software laufen gelassen. Es wird das Verhalten beobachtet.
So stand das ja hier in dieser Übersichtstabelle.
Das Prüfobjekt wird ausgeführt, das Verhalten beobachtet.
Und das heißt, wir führen die Software mit Testdaten aus.
Für dieses Ausführen, da brauchen wir natürlich in irgendeiner Form
etwas, wo das Ganze laufen kann.
Und das ist ein sogenannter Testrahmen. Ich will das
mal hier so ein bisschen hinskizzieren. Ja, nehmen wir
mal an. Ich mache mir so ein paar Kästchen.
Also das ist der Testgegenstand. Dieser Testgegenstand muss natürlich
in irgendeiner Form aufgerufen werden, gestartet werden.
Ja, und deswegen brauchen wir etwas drumherum
Das ist etwas, wo man das aufrufen kann und starten kann,
wo es dran laufen kann, der meistens,
nennen wir uns mal vorstellen, eine Klasse,
eine Komponente, kann allein nicht laufen.
Ich muss wenigstens was haben, wo ich die Klasse,
ein bisschen Objekt von dieser Klasse instanziere, wo ich das irgendwie aufrufe.
Ja, also ich brauche etwas drumherum, was das aufruft und startet.
Ja, das ist das, was hier steht, Testrahmen erforderlich.
Ja, ein Treiber, wo man das aufrufen kann,
und wir wollen Eingabedatenresultate übergeben,
wenn wir irgendwas Externes haben,
was daran mitwirkt in der Datenbank,
das werden wir
durch was anderes ersetzen müssen
Handelsumgebung, wenn wir eine Maschine haben, die wird da dranhängen.
Normalerweise, dann wird mir das in irgendeiner Form simulieren.
Ja, Stubbs oder Proxys oder wie auch immer wir das nennen, Mox.
Das sind Dinge, die man drum rum nimmt. Ja,
und was wir zusätzlich noch brauchen, ist die Eingabedaten und die Resultate,
die male ich mal hier noch mit dran.
Also wir haben irgendwie Testdaten, mal so ein Action dran
für ein Dokument
Die geben wir hier rein. Und was wir rausbekommen,
sind natürlich irgendwie, das kriege ich jetzt hier kaum noch hin.
Das heißt, ich muss hier mal
den Kopf des Dozenten mal ein bisschen woanders hinschieben.
Das machen wir einfach mal so. Ja, also,
damit sie das hier noch sehen können.
Und das sind die Resultate, die hier unten rauskommen.
Die kriegen auch wieder so ein Äckchen dran für ein Dokument
Ja, also die Eingabedaten, die Testdaten und die Resultate,
die brauchen wir hier auch noch mit.
So, jetzt steht hier noch so ein paar Forderungen auf unserer Folie.
Super Forderung lieben wir ja ganz besonders. Also die Tests,
die müssen irgendwas erfüllen. Sie müssen wiederholbar sein. Ja
, das sehen wir vielleicht ein. Tests müssen wir ja
immer mal wieder machen müssen. Also Regressionstest ist ein Name,
der dafür steht, dass wir die Tests in eingeschränkter Form
immer noch dort machen, wo ein Fehler aufgetreten soll.
Also wir testen erst das ganze System,
dann zeigen sich irgendwo noch einen Fehler in einem bestimmten Bereich,
dann testen wir nur diesen Bereich nochmal und dazu wieder Fehler aufgetreten sind,
reparieren wir die, bis sie wieder nochmal,
bis wirklich keine Fehler mehr auftreten.
Regressionstests, das will man natürlich, diese Teile des Tests wiederholen.
Natürlich müssen die Tests irgendwie nachvollziehbar sein. Das heißt,
man muss in der Lage sein, zu sagen,
was hat denn da jemand getestet?
Das kann man mit den Weiden eines Protokolls machen,
aber am besten wäre es natürlich, wenn es in irgendeiner Form programmtechnisch gelöst wird.
Das ist auch wieder, wenn wir es machen. Sie sollen dokumentiert werden,
dass man also einen Nachweis hat, ja,
der Test wurde an dem Tag von Mareike Müller durchgeführt,
ja, und ich muss natürlich auch in der Form
das kontrollieren können
Wozu das Ganze? Ja, das schreiben wir vielleicht hier
mal mit dazu. Wozu, wir können,
wenn wir sie testen, aufbewahren, das ist ja hier das,
was wir hier gefordert haben, gefordert,
fordern.
Das schreibe ich mal mit dran
Ja, also diese Testdaten, Testergebnisse, auch dieser ganze,
das, was wir hier haben, diesen ganzen Testrahmen,
all das brauche ich ja immer wieder.
Deswegen muss ich das sicherstellen, einchecken, genau wie mein Quellcode,
den ich auch nicht wegschmeiße, nachdem er einmal gelaufen ist.
Und wozu brauche ich das, wenn ich die Tests aufhebe,
aufbewahre, dann fällt es mir leicht,
die nach und nach zu vervollständigen.
Also wenn weitere Bugs auftreten, dann wird der Test,
wird der Test vervollständigt, die Testdaten werden vervollständigt,
dass dieser Bug beim nächsten Durchlauf wieder getestet werden kann.
Also wir schreiben hier noch mit auf,
weil das sollte ich für den Stift machen,
zum Vervollständigen brauchen wir das
Zum Verbessern der Tests natürlich,
indem ich die einfach nochmal durchführe und dann ergänze, verbessere,
das wird, damit decken sie viel bessere Sachen ab.
Und natürlich auch, was wir nicht vergessen sollten,
in Tests steckt eine Menge Arbeit. Die Faustregel lautet,
testen es dreimal so aufwendig wie Programmierung und deswegen ist es so sinnvoll,
dass wir das nochmal machen und dass wir das aufheben.
Also die geleistete Arbeit mehrfach nutzen. Das ist das Ziel,
deswegen leiten wir, wollen wir das unbedingt aufbewahren.
Damit haben wir, glaube ich, eine der Fragen schon beantwortet.
Wir schauen mal hier zurück. Nein, noch nicht wirklich.
Nein, das haben wir noch nicht. Wir machen deswegen
erst mal weiter. Testmethoden. Tatsächlich steht so eine Frage,
Testmethoden hier drin, das ist die erste Frage zu diesem Abschnitt.
Zunächst müssen wir erst mal sagen, grundsätzlich,
wir wollen das Verhalten beobachten.
Ja, das hatten wir ja
schon mehrfach gesagt
Wir wollen es ausführen. Aber wir sollten uns immer
im Klaren sein, wir können nicht Korrektheit nachweisen.
Wir können nur bestimmte Abläufe durchführen und sagen,
in diesen bestimmten Abläufen ist denn das Erwartete passiert.
Am Ende ist es nicht mehr als ein Stichprobe.
Wir können nicht vollständig testen. Das ist mit Testen macht nichts Vollständiges. Trotzdem,
damit wir möglichst viel davon diesen Stichproben haben,
damit die Stichprobe viel Vertrauen erzeugen in die Qualität des Produktes,
versuchen wir möglichst viele Kombinationen von Eingabedaten oder Reihenfolgen von Eingabedaten darzustellen.
Und dazu bedeutet das also, wir brauchen viele Testfälle
Viele Testfälle bedeutet, ein hoher Aufwand.
Ich hatte eben schon davon gesprochen, der Aufwand ist ungefähr
dreimal so hoch wie der für die Entwicklung.
Und diesen hohen Aufwand versuchen wir in irgendeiner Form zu reduzieren.
Den Aufwand reduzieren, ohne das Vertrauen in den Test zu verringern,
das ist ein ganz wichtiges Ziel beim Testen.
Das wollen wir erreichen, Verringerung der Anzahl der Testfälle.
Wir sprechen gleich über Abdeckungsmaße, da ist das,
die haben das zum Ziel zu sagen,
was machen wir dann trotzdem noch
Trotzdem möchte ich, gleich möchte ich drei Arten von Tests
hier darstellen. Der Begriff Testmethoden, der hier drüber steht
, ist leider nicht so ganz eindeutig.
Ja, also wir kommen gleich zu den Testebenen noch.
Das benutzen auch viele für Testmethoden oder Black-on-Whitebox-Tests.
Auch das können Begriffe für Testmethoden sein. Zunächst möchte ich mal
hier unterscheiden, es gibt positiv negativ und lasst es.
Das haben Sie in SE2 schon gehört, von mir vermutlich.
Also Positiv-Tests, die testen das erwartete Verhalten.
Negativ-Tests Wir machen gerade das, was die Software nicht erwartet.
Sie fordern etwas, sie fordern eine Fehlermeldung heraus. In Vertragsmodell,
was sie vermutlich ja kennen, ist das so,
dass man dann irgendwie etwas Unerlaubtes macht,
die Vorbedingungen sind nicht erfüllt und ich möchte eine Fehlermeldung provozieren.
Ich möchte sehen, also hierfür erfüllen wir
das Vertrauen in die Korrektheit und hier prüfen wir,
da wollen wir Vertrauen erzeugen, in die Robustheit ins Programms.
Auch zu den Tests gehören die Lasttests bei Lasttests
prüfen wir Performance. Ja, ich schreibe das Ganze,
die drei Sachen mal treiben,
hier geht es um Korrektheit
Hier geht es um Robustheit. Und hier geht es um
Performance bzw. das Qualitätsmerkmal hieß Effizienz. Ressourceneffizienz. So,
ich wollte noch kurz was dazu sagen, wie solche Lasttests aussehen,
ohne wir gehen hier nicht detaillierter darauf ein.
Bei Lasttests geht es darum, dich nur mal zu sagen,
okay, ich teste jetzt mal mit 10.000 Wartensätzen oder mit 1.000 Qualitätswebseitenanfragen pro Sekunde,
sondern ich prüfe,
ich steigere die Last immer weiter,
bis das System in die Knie geht
Und dann prüfe ich, wie weit bin ich denn weg?
Zum Beispiel, wir haben ein Shop-System, ja,
hier in Hamburg ist Otto, ein großer Händler.
Für die ist das Weihnachtsgeschäft typischerweise eine große Herausforderung.
Und wenn sie im Weihnachtsgeschäft wissen, sie haben so und
so viele 10.000 Anfragen pro Tag oder pro Stunde,
was auch immer, dann wollen sie natürlich,
dass ihr System diese Last aushält.
Und da würde man den Lasttest immer weiter treiben,
immer mehr Anfragen pro Stunde oder pro Minute pro Sekunde.
Und dann sehen, bei welchen Anzahl geht das System in
die Knie? Und dann schaut mal,
wie weit bin ich denn noch weg vom Erwarteten
Wie viel Sicherheitsreserve habe ich und wenn ich da weit weg bin,
davon fühle ich mich sicher, wenn ich mich,
bin ich ganz zufrieden mit der Performance des Systems,
wenn ich nicht so weit weg bin,
dann sollte ich vielleicht noch tun,
weil wir wissen ja nie so ganz genau,
bildet der Test die reale Situation tatsächlich ab?
So, um zu, um sicherzustellen,
dass wir tatsächlich genug Testfälle haben,
obwohl wir ja dafür versorgen,
das zu verringern,
dafür gibt es
diese Abdeckungsmaße
Abdeckungsweise sagen uns, was wir denn,
wie viele Tests wir denn haben oder wie viel denn von
dem Gesamtsystem mit der Funktionalität, von dem Verhalten,
von den Zuständen und Zustandsübergängen, denn so ein Test abdeckt.
Wir haben hier, das ist hier ein bisschen schlecht auf dieser Folie,
wir haben hier drei Arten von Abdeckungen dargestellt.
Und wir fangen an mit Anweisungsabdeckung. Das heißt,
wir wollen erreichen, dass bei den Testen jede Zeile,
jede Anweisung mindestens einmal durchlaufen wird
Da mag der eine oder andere von ihnen sagen,
ja, super, das ist mein ganzes Programm getestet.
Aber dann ist, dann sind die verschiedenen Varianten nicht getestet,
nicht alle Bedingungskombinationen sind getestet.
Das ist noch zu wenig, um zum Beispiel bei einer Schleife,
die wird genau einmal durchlaufen, dann reicht das.
Wir wissen nicht, ob das ist, wenn 9 und 10
die Grenze ist, wie das an der Schleifengrenze aussieht.
Das heißt, das reicht nicht aus.
Ja, also diese Anweisungsabdeckung reicht nicht aus. Zweigeabdeckung,
da durchlaufen wir jeden Zweig, Zweige ist etwas von der
Bedingung abhängiger, durchlaufen wir jeweils einmal.
Und das ist etwas, was schon ein bisschen besser ist,
ja, aber naja,
reicht auch,
ist auch nicht
wirklich viel
Es gibt noch den Begriff Pfad und die Pfadabdeckung kombiniert alle
möglichen und Abläufe eines Testobjekts. Da ist wirklich alles vollständig abgedeckt,
aber wir müssen sagen, das ist nicht möglich.
Ich will kurz erläutern, die unterschiedlichen Begriffe zwischen Zweig und Pfad.
Dazu brauche ich hier ein neues Blatt. Ich mache mal so
einen kleinen Ablauf hier. Wir starten, das wird eine Aktivitätsdiagramm.
Wir starten mit einer Verzweigung machen. Da ist eine Anweisung,
nennen wir es die A1,
dann kommt wieder eine Verzweigung und dann kommt eine Anweisung A2 und wenn wir hier rüber gehen,
sei wieder eine Verzweigung nicht ganz so schön bezeichnet,
sondern eigentlich Kästchen mit abgerundeten Ecken sollen das sein.
Die nennen wir A3, A4,
ich werde leider mal wieder immer kleiner,
weil ich ein bisschen, weil ich am Rand angefangen habe,
sie haben das bei sich bestimmt besser gezeichnet.
So, dann wird das Ganze wieder zusammengeführt.
So, und hier führt wird das auch wieder zusammengeführt.
Und hier gibt es noch eine Bedingung,
das könnte also sein,
es geht wieder hoch
Dahin und andernfalls ist es fertig. Und hier schreiben wir
noch irgendwelche, es gibt hier irgendwelche Bedingungen. Ja,
also hier gibt es eine Verzweigung, entweder geht es hier lang,
Bedingungen werden der UML immer in eckigen Klammern dargestellt,
wie sie sich hoffentlich erinnern.
Ich schreibe aber nicht wirklich eine Bedingung rein. Es gibt ja
einfach bei dem Uni unten gibt es auch noch eine Demo dafür,
dass wir noch nicht fertig sind oder dafür,
dass wir fertig sind
So, das sind jetzt, das sei ein ganz kleines Beispiel sein,
also wir haben ja gerade mal zwei Verzweigungen,
das ist diese hier und hier noch eine, ach,
hier müssen auch noch eine Bedingung unterhalten, das wollen wir natürlich nicht unterschlagen,
eine Verzweigung gehören immer Bedingungen, auch wenn wir hier keine wirklich reinschreiben.
So, wenn wir jetzt mal anschauen,
was wir hier für Zweige haben,
so haben wir der eine Zweig, das ist der von A1,
fangen wir mal für links nach rechts an, ja,
der erste Zweig würde hier lang gehen, A1, A3,
das ist ein Zweig, Ein der nächsten Zweig ist der,
eins, A4. Und Schluss und der nächste Zweig,
den wir haben, ist hier A1, A2 und Schluss.
So, das können wir jetzt noch ein bisschen besser machen,
oder noch weiter, wir führen jetzt jede,
wenn wir jetzt von Anweisungsabdeckung reden,
hätten wir mit diesen drei Durchläufen schon alles erfüllt,
was wir brauchen.
Und wir haben die Schleife zum Beispiel
nicht ein einziges Mal gemacht
Wenn wir zwei Abdeckung haben, ist das schon das Mindestmaß.
Das heißt, wir würden diese Entscheidungen aller jeweils einmal durchlaufen.
Und vielleicht würden wir hier noch,
dass wir den Zweig hier oben noch einmal machen,
in irgendeiner Form hier noch einen hinzunehmen, war eins.
Zum Beispiel A2. Und dann kommt nochmal A1 und nochmal irgendwas.
Ja, ich mache mal so. Das wäre auch ein,
dass wir diesen Zweig hier oben rum auch mal durchlaufen
Das wäre jetzt hier schon genug für die Zweige.
Und jetzt den Begriff Pfad, den wir hier hatten,
wo ich ihnen schon gesagt habe, gerade die Menge aller unterschiedlichen Abläufe.
Das schauen wir uns hier mit unterschiedlichen Abläufen, meine ich,
dass es einmal hier lang geht, wieder hoch,
dein hier lang vielleicht wieder hoch und dann hier lang wieder hoch und dann raus,
das ist ein Pfad.
Und das Gleiche, hier lang, wieder hoch, hier lang,
wieder hoch, ehelang wieder hoch und dann durch A2 und raus.
Das ist wieder ein Pfad. Also alle möglichen Kombinationen,
das sind alles Pfade. Deswegen, ich schreibe das nochmal,
schreibe das einmal hier hin, nur um das zu sagen,
die Pfade wären zum Beispiel eins, A3, eins, A3.
Ein weiterer Fahrt A1 war 3, A1, 4,
wäre ein anderer Pfad. Bei 1 war 3,
Eins, drei, zwei, ist wieder ein Pfad.
Auch wenn wir A1 A2 nehmen, ist ein Pfad.
Ja, und A1 A2, eins, vier,
eins A4 ist ein Pfad.
Und so weiter. Es gibt hier sehr viele mehr
Ja, und das ist der Punkt,
wenn wir alle möglichen Pfade von einem, das ist nur ein
ganz einfaches System, aber es enthält gerade mal eine Schleife.
Und man könnte jetzt ausrechnen, wie viel,
das ist eine kleine Kombinatorikaufgabe, ich habe das jetzt nicht vorbereitet,
wie viele Pfade das sind, das sind jedenfalls sehr, sehr viele.
Und für ein System realistischer Größe,
da müssen wir gar nicht mal das ganze Betriebssystem Windows nehmen,
da wird es schon was relativ Kleines reichen,
da braucht der Test,
wenn wir alle Pfade machen und selbst wenn wir hier
tausend Tests pro Sekunde machen,
dann braucht das länger als das Universum dauert
Also deswegen steht hier, das ist nicht realistisch.
Wir können nicht alle Pfade testen. Das wäre wirklich,
das wäre ein vollständiger Test. Das ist nicht realistisch.
Und deswegen stand hier vorher, wir machen doch nur ein Stichprobenverfahren.
Wir werden gleich noch weitere Testabdeckungsmaße kennenlernen.
Das war sozusagen eine der Antworten, nein hier,
wo waren die Fragen, war das eine Folie vorher, Testabdeckungsmaß.
Also es sind schon mal drei Testabdeckungsmaße da, Anweisungsabdeckung,
zwei Gabdeckung, Fahrtabdeckung, wobei die Fahrtabdeckung nicht wirklich existiert.
Wir werden das, wir machen das nochmal eine separate Folie
Das können wir, das machen wir ein bisschen später.
Ja, lassen Sie uns fortsetzen mit dem Blackbox und dem Whitebox-Test.
Das sind zwei unterschiedliche Herangehensweisen. Wie prüfe ich Software,
insbesondere unterscheiden Sie sich dadurch, wo kommen die Testdaten her?
Zur besseren Gegenüberstellung habe ich mal hier wieder so eine Tabelle gemacht.
Ich möchte Sie gleich mal warnen. Es ist in der Vergangenheit häufig passiert,
dass Leute diese andere Tabelle, die wir vorher hatten,
Ich hole die gleich noch mal davor.
Das war diese hier. Review und Testgegenüberstellung vermischt haben mit der Tabelle Blackbox, Whitebox.
Nur weil sie halt beide zwei Sachen dort gegenüberstellen.
Ja, also deswegen kleine Warnung an See,
böse Falle für die Klausur. Ich habe deswegen,
damit um das nicht, damit das nicht passiert,
habe ich hier noch mal den Ablauf reingeschrieben.
Der Ablauf unterscheidet sich für beide gar nicht.
In beiden Fällen wird der Test, der Testgegenstand ausgeführt,
das Verhalten beobachtet und geschaut, was ist denn rausgekommen.
Das ist für beide
das Gleiche
Lassen Sie uns kurz durchgehen, worum es geht.
Beim Blackbox-Test betrachten wir, wie der Name schon sagt,
die ein Modul, den Testgegenstand als Blackbox.
Wir können nicht hineinschauen. Wir können nur etwas draufgeben
und gucken, was rauskommt. Und dieses etwas draufgeben,
machen wir anhand dessen, was wir erwarten,
was das Teil können soll, was es tun soll,
wie es sich verhalten soll.
Das heißt, wir nehmen die Verhaltensbeschreibung,
die Spezifikation oder die Schnittstellenbeschreibung, konstruieren daraus Testdaten,
die alle diese Sachen abdecken und schauen,
was rauskommt
Blackbox jetzt. Weil wir da Funktionen testen, heißt das
auch, funktionaler Test oder wenn sie wollen, Funktionstest.
Der Whitebox-Test macht sich zur Nutzer Whitebox im Sinne von,
wir können hineingucken in den Kasten, macht sich zunutze,
dass wir die Struktur kennen.
Wir schauen uns also den Quellcode an. Deswegen heißt das Ding
auch Strukturtest und wir nehmen die Testdaten aus der Struktur,
aus der Analyse des Steuerflusses.
Also das, was wir hier hatten. Wir wissen nicht nur,
da geht was rein und da kommt was raus,
sondern wir wissen auch,
hier gibt es
diese drei Zweige
Also das wäre dieses Wissen zu nutzen für Testfälle,
das wäre der Strukturtest der Whitebox-Test. Bitte, trotzdem passiert es
in einem Durchlauf. Manchmal höre ich in Prüfungen oder irgendwo,
dass jemand sagt, ja, das ist ein Schrittbetrieb.
Nein, Schrittbetrieb ist das nicht. In beiden Fällen,
es gibt es einen Durchlauf. Ja,
also das ist mir wichtig, dass sie das verstehen.
Es gibt noch zwei weitere Zeilen hier in dieser Tabelle zum Unterschied.
Vielleicht erstmal die unterste Zeile, wo wendet man das an?
In welchen Phasen der Entwicklung, in welchen Phasen der Entwicklung
eines Systems, machen wir das.
Der Blackbox-Test bezieht sich immer auf größere Einheiten. Größere Einheiten,
deswegen, weil bei kleinen Einheiten, da haben wir keine Spezifikation.
Wir haben eine Spezifikation für einen Teil eines Systems,
aber nicht für eine Methode, meistens nicht.
Und deswegen sind es eher bei großen Einheiten angewendet wie Subsysteme
oder ganze Systeme beim Integrationstest oder beim Abnahmetest.
Man nimmt also ein User-Szenario und macht damit,
führt das System aus dem Buch, mit dem System buchen sie eine Reise.
Oder sie legen einen Nutzer ein oder sie stornieren eine Rechnung
oder was auch immer, sowieso ein Ablauf.
Das macht man als Blackbox-Test. Den Whitebox-Test,
wo ich einzelne Strukturelemente angucke, dem gegenüber,
mache ich deswegen eher, mache ich eher bei kleinen Einheiten,
weil ich möchte in der Lage sein, die kleinen Einheiten auch anzuschauen.
Für ein großes Brustly-System wie Microsoft Office, kriegen Sie das,
kriegen Sie nie in Whitebox-Test hin,
da wäre viel zu komplex, viel zu aufwendig.
Das heißt,
das machen eher
die Entwickler
Die beiden hier gibt es noch eine weitere Sache Art gefundener Fehler.
Tatsächlich beide finden vor allen Dingen Fehler im Verhalten.
Das müssen wir einfach sagen. Das habe ich hier dadurch
ausgedrückt, dass ich hier reingeschrieben habe, falsche Funktionalität.
Das hat mir vorher gegenübergestellt mit den Reviews, mit Inspektionen.
Da war das also bei beiden,
die Tests sind eben beides analytisch-dynamische Maßnahmen und die finden vor
allen Dingen
falsche Funktionalität
Bei dem Blackbox-Test finde ich auch etwas, wenn ich einen
Zweig vergessen habe. Ja, weil wir wissen ja,
die Spezifikation sagt, das und das Verhalten soll rauskommen.
Also wenn ich im Entwurf etwas falsch gemacht habe,
finde ich das dann auch. Oder wenn ich irgendwie etwas
habe mit Schwellwerten und die Schwellwerter sind dann nicht richtig.
Wenn die Anzahl der Durchläufe ist nicht richtig. Datenabhängige Fehler.
Das würde ich hier auch finden. Im Gegensatz dazu,
diese Fehler, nämlich würde ich nicht finden,
wenn ich ein Tente Strukturen arbeite.
Wenn ich also hier anhand dieser Sache, die Testdaten so konstruiere,
dass das hier jeder Zweig einmal durchlaufen wird zum Beispiel,
würden sie
nicht merken,
wenn ein Zweig fehlt
Das heißt, das heißt so etwas wie diese Entwurfsfehler
würden wir hier im Strukturtest im Whitebox-Test nicht merken.
Dafür, wenn wir uns die Pfade genau angucken,
merken wir vielleicht, wenn so etwas wie verborgene Funktionalität da ist.
Irgendwelche verborgenen Schalter, die keiner wissen soll. Oder sowas
wie ein Trojaner oder sowas, das würden wir da merken,
wenn wir sagen, okay, auf einmal haben wir Testdaten,
wo plötzlich was aus dem Internet nachgeladen wird.
Dann denke ich mir so, oi,
was ist denn jetzt hier passiert?
Ja, das passiert dadurch, dass wir wirklich eben
alle Pfade im Steuerfluss analysieren
Soweit die Gegenüberstellung. Und das ist jetzt am besten,
wäre jetzt ja doch von beiden etwas zu haben.
Und tatsächlich macht man das auf den Unternehmen noch,
bevor wir dazu kommen, möchte ich erstmal die Begriffe,
die wir hier eben hatten, nochmal darstellen.
Ach so, vielleicht hier, dazu haben wir eine Frage.
Diese Frage, genau, was sind die Gemeinsamkeiten und Unterschiede
von Black und Whitebox-Test?
Das war die Frage 9, die haben wir mit dieser,
mit dieser Folie beantwortet
Ja, wir hatten eben Begriffe von wegen Modultests und so weiter.
Die möchte ich mit dieser Folie kurz erklären. Im Kleinen,
das Testen im Kleinen, Desten durch den Entwickler,
das machen wir für einzelne Klassen, manchmal sogar für weniger,
für Methoden.
Und das ist deswegen etwas, was der Entwickler meistens macht.
Größere Einheiten? Wie zum Beispiel Subsysteme oder ganze Systeme,
die testen wir nach dem Zusammenbau
Spiel der Integrationstest, den prüfen wir, nachdem wir fertig getestete Module,
die vorher diesen Modultest durchlaufen haben, zusammenbauen und dabei auch das Zusammenspiel testen.
Prüfen, ob die Schnittstellen alle zueinander passen, insbesondere was
sich für das Protokoll betrifft. Und wenn wir den Systemtest durchführen,
das wäre das Verhalten des Systems im Zusammenspiel mit der Umgebung,
das Verhalten des Gesamtsystems, das brauchen wir auch,
wenn wir Laufzeittests, Stresstests,
also Lasttests durchführen wollen oder gar die Benutzbarkeit,
die Benutzerfreundlichkeit prüfen wollen
So, man sollte versuchen, Black und Whitebox-Tests miteinander zu kombinieren.
Und zwar schlage ich ihnen hier auf dieser Folie eine Kombinationsmöglichkeit vor,
diese Möglichkeit, ich schreibe,
erkennen Sie das mal kurz, also dieser funktionsorientierte Test,
das war Blackbox.
Und das war Whitebox-Test
Sollte ich ihn folgenderweise auf die Empfehlung,
ist das in folgender Weise zu kombinieren,
dass ich zunächst erst mal beginne mit den Tests nach der Spezifikation,
also indem ich auf Anwendungsebene Testdaten zusammenstelle, die zum Beispiel,
was ich eben sagte, Anlegen eines Nutzers löschen,
eines Nutzers, Anlegen eines Artikels,
Kaufen eines Artikels, Nachbestellen eines Artikels.
Solche Sachen können sie alle durchführen. Und dann prüfen sie
, wie viel Zweige habe ich denn abgedeckt?
Wie viel Code habe ich denn abgedeckt oder wie viel gibt
es, was noch nicht abgedeckt ist
Wie wir das abdecken, prüfen, sage ich gleich noch was dazu.
Und dabei stelle ich fest, ich habe noch nicht so sehr viel abgedeckt.
70 bis 80 Prozent ist schon eine hohe Zahl.
Manchmal ist es auch deutlich weniger, manchmal auch nur 60 Prozent.
Und dann nehme ich, schaue ich mir, dann mache ich sozusagen den Blick nach innen.
Ich nehme den Whitebox-Test und schaue, was für Tests,
was für Testdaten brauche ich denn, damit ich die noch fehlenden,
die hier nicht erreichten Zweige, dass ich die auch noch abdecke.
Und dafür ergänze ich weitere Testfälle. Das ist für uns eine,
das mit dieser Kombination aus beiden, trägt dann dazu bei,
dass wir eine hohe Testabdeckung haben, also eine,
zum Beispiel beim Zweigabdeckung 100 Prozent erreichen,
beziehungsweise noch deutlich mehr, indem wir Kombinationen auch noch haben.
Ja, also wenn wir nur die Zweigabdeckung haben,
das ist die Minimalbedingung, man kann auch mit dieser Kombination auch mehr erreichen,
wenn wir noch weiters hinzunehmen.
Wer kommt gleich noch zu Zuständen und Zustandsübergingen? Lassen Sie mich kurz etwas dazu sagen,
was hier diese Instrumentierung meint, Instrumentierung Dieser Begriff steht,
also eigentlich muss man sagen, ich möchte ja kontrollieren,
wieso, welche Zweige habe ich denn durchlaufen.
Dieses Kontrollieren macht man dadurch,
dass man Kontrollanweisungen in jeden Zweig hineinbringt und dann die zum Beispiel
ein Logfile schreiben und in dem Logfile dann hinterher aus dem Logfile ausliest,
was davon,
welche Zweige sind denn nicht durchlaufen wollen
So eine Sache mit Anweisungen in den Logfail schreiben,
das macht zum Beispiel ein Profiler, nützt das auch.
Profiler sind ja Programme, die man Werkzeuge,
die man einsetzt, zum Beispiel um zu prüfen,
wo verbringe ich im Programm meine Zeit,
wo geht zieh viel Zeit verloren und Performance-Optimierung zu machen.
Sowas ähnliches können wir auch verwenden, um hier,
also ich ergänze das mal hier so,
ja, also diese Instrumentierung, die ist dazu notwendig,
damit wir eine Kontrolle hinkriegen und die Instrumentierung,
mein Sternchen dran
Diese Kontrollanweisungen dort einfügen, dafür gibt es diesen Begriff Instrumentierung.
Der stammt aus der Automatisierungstechnik, aus der Regelungstechnik,
wo ich Instrumente wie Druckmesser, Durchflussmesser, Temperaturmesser,
eine bestimmte Stellen einer von mir aus Raffinerie,
eine chemische Anlage unterbringe, um genau an den Stellen zu messen,
wo ich gut messen kann, wo ich gut regeln kann.
Also diese Instrumente anordnen, Das nennt man da Instrumentierung,
nur dass sie wissen, wo dieser Begriff jetzt herkommt.
Die Softwareentwicklung haben sich dann bei den Ingenieuren so im Begriff mal geborgt und haben den,
hoffentlich haben sie ihn dann auch zurückgegeben, ja,
aber wir haben hier diese Instrumentierung im Sinne von Kontrollanweisungen einfügen.
Da gibt es Werkzeuge für,
die dann in jedem Zweig identifizieren und in jedem Zweig da
eine Kontrolleinweisung reinfügen und dann auch das Blockfile auswerten,
das wäre das hier mit der Kontrolle.
Also wir führen Äquivalenzklassentests durch, der Begriff,
der kommt gleich gleich, ich nehme den beraten,
verhalten wir das jedenfalls testen
Daten aus der Spezifikation. Und danach ergänzen wir weitere Testdaten aus
den Nicht-Durchlaufenden Zweige, die hier oben nicht abgedeckt wurden.
Ich möchte gleich die Gelegenheit nutzen,
nochmal auf diesen Unterschied zwischen Black- und Whitebox-Test hinzuweisen,
was ich eben schon sagte anhand der Tabelle.
Also es wird passiert bei beiden, das Gleiche,
das Verhalten wird beobachtet beim Durchlaufen mit Testfellen.
Und wenn wir das jetzt nochmal hier bei dieser Integration ansaut,
dann kann das durchaus sein,
dass das beides
zusammen ein Durchlauf ist
Ich habe Testfälle, die ich, Testdaten, die ich
daraus gewinne, aus dem Blackbox, aus dem funktionsorientierten Tests.
Und dann weitere Testdaten, die ich aus dem Strukturentennen,
aus dem Blackbox, aus dem Whitebox-Test gewinne.
Alle diese Testdaten nehme ich zusammen und mache einen Durchlauf.
Es reicht, das zusammenzumachen. Es muss nicht in
mehreren Durchgreifen passieren. Soweit ist das eine gute Integration,
um zu erreichen, dass wir eine hohe Testabdeckung mit
geringem Aufwand schaffen
Nun möchte ich noch mal auf die Fragen eingehen.
Bei den Fragen hatten wir insbesondere eine,
die Frage ist sieben, stellen Sie Testmethoden gegenüber?
Das ist ein bisschen, diese Frage würde ich Ihnen kaufen,
schon mal verreiten, nicht in der Klausur so stellen,
weil es ist nicht so richtig klar, was bezeichnet wir denn mit Testmethoden?
Bei meinen Folien ist das noch relativ klar,
dass hier ist positiv, negativ und Lasttest bezeichnet,
aber es gibt durchaus noch Autoren, die würden jetzt,
nein, die würden Blackbox und Whitebox-Test als Testmethoden,
als zwei Testmethoden bezeichnen oder die würden
Modultest-Integrations- und Systemtest als Testmethoden bezeichnen
Sie, Christin, sind ganz gut, wenn Sie diese Begriffe,
die wir hier verwendet haben, erklären können.
Das ist der Sinn, warum ich die Frage 7 hier eingefügt habe.
Ja, Sie sollten in der Lage sein,
das zu erklären. Wir haben schon gerade darüber gesprochen,
dass wir Pfad um Zweigabdeckung unterschiedlich zu bewerten haben.
Pfadabdeckung ist nicht möglich. Zweigabdeckung ist das Mindestmaß. Wir
werden noch zu weiteren kommen. Wir hatten die Tabelle mit
diesem Black-on-Whitebox-Test und die Kombination hatten wir zu diesen ganzen Sachen.
Und als nächstes werden wir gleich zu den Äquivalenzklassen kommen