May 25, 2023

STP038: Software-Tests

1 hour 22 minutes

Nach der Episode über die Fehler, spechen wir heute darüber, wie man sie vermeidet. Wie nicht anders zu erwarten, ist auch dies ein Thema, bei dem reichhaltige Meinungsdiskurse geführt werden.

Shownotes

Warum testen? -> siehe STP037

Anforderungen an Tests

reproduzierbar: nicht abhängig von unerwarteten äußeren Einflüssen oder menschlicher Intervention

fokussiert: im Fehlerfall soll möglichst klar sein, wo das Problem liegt

schnell: damit man beim Ändern des Systems schnelles Feedback bekommt (siehe auch XKCD 303)

realitätsnah: überprüft eine Funktion, die der Benutzer so tatsächlich benötigt

manuelle Tests

kostenintensiv: Online-Shooter braucht(e) 200 Tester (das Spiel erlaubt Matches mit bis zu 60 Teilnehmern)

erfüllt von den obigen Anforderungen nur die Realitätsnähe

wenn's geht, lieber automatisieren

gängige Strategie: manuelle Tests zur Fehlersuche, im Zweifelsfall durch die Kunden ;) – dann Nachstellung des gefundenen Problems

automatisierte Tests am Beispiel der Testpyramide

Unit Tests: Überprüfung einer einzelnen Komponente in Isolation

besonders wertvoll, wenn die Komponenten auf besonders reproduzierbare Weise arbeiten (zum Beispiel pure Berechnungen; Vorgänge, die nicht Netzwerkzugriff/Festplattenzugriff/etc. erfolgen)

Problem: es reicht nicht, wenn jede Komponente für sich genommen funktioniert, aber sie nicht zusammen passen

Bewertung: reproduzierbar, fokussiert, schnell, aber nicht realitätsnah

Integration Tests: Überprüfung des Zusammenspiels mehrerer Komponenten eines Gesamtsystems

nach Möglichkeit Eingrenzung äußerer Faktoren, z.B. statt Kommunikation mehrerer Komponenten über ein reales Netzwerk Simulation einer Netzwerkstruktur im Programm oder mittels Containern/VMs (siehe STP023)

Bewertung: tendenziell weniger reproduzierbar, etwas langsamer, weniger fokussiert, aber realitätsnäher

End-to-End-Tests (E2E): Überprüfung des Verhaltens eines Gesamtsystems

analog zu den manuellen Tests, aber nach festem Algorithmus

höchster Aufwand in der Umsetzung, siehe insbesondere UI-Tests mittels Headless Browser etc.

Bewertung: am wenigsten reproduzierbar (aufgrund der Vielzahl an Variablen), am unfokussiertesten, am langsamsten, aber am nächsten an der Realität

allgemeine Empfehlung: ganz viele kleine Unit Tests und einige mittelgroße Integrationstests für die schnelle Feedbackschleife, dazu einige wenige große E2E-Tests für den Abgleich mit der Realität

alternative Teilung: Blackbox-Tests vs. Whitebox-Tests

Blackbox: Umsetzung eines Tests ohne innere Kenntnis der Struktur des Systems, z.B. anhand einer Spezifikation

Vorteil: ein Blackbox-Test durch ein anderes Team kann Missverständnisse des ursprünglichen Teams aufdecken

Nachteil: kann nur E2E sein

die reine Lehre: Test Driven Development (Testgetriebene Entwicklung)

neue Funktionalität darf man nur bauen, wenn es Testabdeckung dafür gibt

erst fehlschlagenden Test schreiben; dann Funktionalität einbauen, sodass der Test erfolgreich durchläuft; dann aufräumen

Xyrill macht lieber "Data Driven Development" und hat Bedenken

Kann man die Qualität eines Tests bewerten? -> Idee: Code Coverage

Welcher Anteil des Programmcodes wird von meinem Test tatsächlich abgedeckt?

Was heißt eigentlich "Anteil"?

Beispiel: if (a or b or c) { return "Kredit abgelehnt" } (einfach bei Zeilenabdeckung, schwierig bei Bedingungsabdeckung)

Beispiel: "Kommt ein Software-Tester in eine Bar."

Problem: Goodharts Gesetz, "Sobald eine Metrik zu einem Ziel wird, hört sie auf, eine gute Metrik zu sein."

Problem: für manche Zeilen sind Tests wichtiger als andere (wichtig für vertrackte Logik, weniger wichtig für Sofortabbruch bei unerwarteten Fehlern)

Tests muss man trotzdem noch schreiben. Kann man das wegautomatisieren?

Statische Analyse: automatische Suche nach bedenklichen Mustern (z.B. Datei wurde zum Schreiben geöffnet, wird aber am Ende nicht geschlossen -> Risiko des Datenverlusts; z.B. Verwendung veralteter kryptografischer Primitiven)

Fuzzing: anstatt eines Tests mit festen Werten ("bei Eingabe X wird Ausgabe Y erwartet") nur Vorgabe einer Struktur ("wenn hier ein Text reingesteckt wird, kommt da eine Zahl raus"), dann automatische Suche nach Absturzbedingungen

Machen Tests die Sache immer besser?

Heisenbug: "ein Softwarefehler, der zu verschwinden oder sein Verhalten zu verändern scheint, wenn man versucht, ihn zu untersuchen"

im Gespräch erwähnt:

ISO9001

FG034 zu Werner Heisenberg

...more

View all episodes

By Xyrillian Noises

May 25, 2023

STP038: Software-Tests

1 hour 22 minutes

Nach der Episode über die Fehler, spechen wir heute darüber, wie man sie vermeidet. Wie nicht anders zu erwarten, ist auch dies ein Thema, bei dem reichhaltige Meinungsdiskurse geführt werden.

Shownotes

Warum testen? -> siehe STP037

Anforderungen an Tests

reproduzierbar: nicht abhängig von unerwarteten äußeren Einflüssen oder menschlicher Intervention

fokussiert: im Fehlerfall soll möglichst klar sein, wo das Problem liegt

schnell: damit man beim Ändern des Systems schnelles Feedback bekommt (siehe auch XKCD 303)

realitätsnah: überprüft eine Funktion, die der Benutzer so tatsächlich benötigt

manuelle Tests

kostenintensiv: Online-Shooter braucht(e) 200 Tester (das Spiel erlaubt Matches mit bis zu 60 Teilnehmern)

erfüllt von den obigen Anforderungen nur die Realitätsnähe

wenn's geht, lieber automatisieren

gängige Strategie: manuelle Tests zur Fehlersuche, im Zweifelsfall durch die Kunden ;) – dann Nachstellung des gefundenen Problems

automatisierte Tests am Beispiel der Testpyramide

Unit Tests: Überprüfung einer einzelnen Komponente in Isolation

besonders wertvoll, wenn die Komponenten auf besonders reproduzierbare Weise arbeiten (zum Beispiel pure Berechnungen; Vorgänge, die nicht Netzwerkzugriff/Festplattenzugriff/etc. erfolgen)

Problem: es reicht nicht, wenn jede Komponente für sich genommen funktioniert, aber sie nicht zusammen passen

Bewertung: reproduzierbar, fokussiert, schnell, aber nicht realitätsnah

Integration Tests: Überprüfung des Zusammenspiels mehrerer Komponenten eines Gesamtsystems

Bewertung: tendenziell weniger reproduzierbar, etwas langsamer, weniger fokussiert, aber realitätsnäher

End-to-End-Tests (E2E): Überprüfung des Verhaltens eines Gesamtsystems

analog zu den manuellen Tests, aber nach festem Algorithmus

höchster Aufwand in der Umsetzung, siehe insbesondere UI-Tests mittels Headless Browser etc.

Bewertung: am wenigsten reproduzierbar (aufgrund der Vielzahl an Variablen), am unfokussiertesten, am langsamsten, aber am nächsten an der Realität

alternative Teilung: Blackbox-Tests vs. Whitebox-Tests

Blackbox: Umsetzung eines Tests ohne innere Kenntnis der Struktur des Systems, z.B. anhand einer Spezifikation

Vorteil: ein Blackbox-Test durch ein anderes Team kann Missverständnisse des ursprünglichen Teams aufdecken

Nachteil: kann nur E2E sein

die reine Lehre: Test Driven Development (Testgetriebene Entwicklung)

neue Funktionalität darf man nur bauen, wenn es Testabdeckung dafür gibt

erst fehlschlagenden Test schreiben; dann Funktionalität einbauen, sodass der Test erfolgreich durchläuft; dann aufräumen

Xyrill macht lieber "Data Driven Development" und hat Bedenken

Kann man die Qualität eines Tests bewerten? -> Idee: Code Coverage

Welcher Anteil des Programmcodes wird von meinem Test tatsächlich abgedeckt?

Was heißt eigentlich "Anteil"?

Beispiel: if (a or b or c) { return "Kredit abgelehnt" } (einfach bei Zeilenabdeckung, schwierig bei Bedingungsabdeckung)

Beispiel: "Kommt ein Software-Tester in eine Bar."

Problem: Goodharts Gesetz, "Sobald eine Metrik zu einem Ziel wird, hört sie auf, eine gute Metrik zu sein."

Problem: für manche Zeilen sind Tests wichtiger als andere (wichtig für vertrackte Logik, weniger wichtig für Sofortabbruch bei unerwarteten Fehlern)

Tests muss man trotzdem noch schreiben. Kann man das wegautomatisieren?

Machen Tests die Sache immer besser?

Heisenbug: "ein Softwarefehler, der zu verschwinden oder sein Verhalten zu verändern scheint, wenn man versucht, ihn zu untersuchen"

im Gespräch erwähnt:

ISO9001

FG034 zu Werner Heisenberg

...more

More shows like Schlüsseltechnologie

View all

Freak Show

11 Listeners

Methodisch inkorrekt!

16 Listeners

Lage der Nation - der Politik-Podcast aus Berlin

228 Listeners

c’t uplink - der IT-Podcast aus Nerdistan

9 Listeners

Chaosradio

7 Listeners

heiseshow

3 Listeners

Logbuch:Netzpolitik

6 Listeners

Jung & Naiv

45 Listeners

Holger ruft an

2 Listeners

Die Wochendämmerung - Der stabile Wochenrückblick

14 Listeners

Sicherheitshalber

46 Listeners

Bit-Rauschen: Der Prozessor-Podcast von c’t

0 Listeners

Legion

7 Listeners

Haken dran – das Social-Media-Update der c't

2 Listeners

Passwort - der Podcast von heise security

3 Listeners

Share STP038: Software-Tests

Sign up to save your podcasts

STP038: Software-Tests

STP038: Software-Tests

More shows like Schlüsseltechnologie

Freak Show

Methodisch inkorrekt!

Lage der Nation - der Politik-Podcast aus Berlin

c’t uplink - der IT-Podcast aus Nerdistan

Chaosradio

heiseshow

Logbuch:Netzpolitik

Jung & Naiv

Holger ruft an

Die Wochendämmerung - Der stabile Wochenrückblick

Sicherheitshalber

Bit-Rauschen: Der Prozessor-Podcast von c’t

Legion

Haken dran – das Social-Media-Update der c't

Passwort - der Podcast von heise security