Einige häufige Fragen im Fachgespräch rund um das Thema
Softwaretest sind Inhalt der vierundneunzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Für dein Fachgespräch als
Fachinformatiker:in Anwendungsentwicklung empfehle ich dir,
Testverfahren anhand fester Fragen einzuordnen: Was wird getestet,
wie und von wem, mit welchen Kenntnissen, zu welchem Zeitpunkt und
mit welchem Ziel? Dazu gehören auch Blackbox- und Whitebox-Tests
sowie statische und dynamische Verfahren. Mit der Testabdeckung
beschreibst du, welche Anweisungen oder Wege durch deinen Code
geprüft wurden; bei komplexem Code wächst der Aufwand dafür. Tests
zeigen Fehler und bestätigen das Verhalten für geprüfte Fälle,
wobei ein vollständiger Nachweis der Fehlerfreiheit durch Testen
praktisch unerreichbar bleibt. Kapitelmarken [00:00:01] Einstieg
und Informationen zum Fachgespräch [00:00:37] Testen als Thema im
Fachgespräch [00:02:37] Offene Prüfungsfragen strukturiert
beantworten [00:03:26] Testverfahren anhand fester Fragen einordnen
[00:05:10] Komponenten-, Integrations- und Systemtests [00:06:29]
Funktionale und nicht funktionale Anforderungen [00:08:13] Manuelle
und automatische Tests [00:09:38] Wer führt Tests durch? [00:10:17]
Blackbox- und Whitebox-Tests [00:12:03] Test First, Test Last und
Test-Driven Development [00:13:28] Alpha- und Beta-Tests [00:14:12]
Dynamische und statische Testverfahren [00:15:34] Testziele und
Grenzen erschöpfenden Testens [00:17:48] Anweisungsüberdeckung: C0
[00:19:04] Zweigüberdeckung: C1 [00:20:02] Pfadüberdeckung: C2
[00:21:23] Zyklomatische Komplexität [00:23:48] Abnahmetest und
User Acceptance Test [00:25:03] Lasttest [00:26:33] Smoke-Test
[00:28:24] Exploratives Testen [00:30:27] Rückblick auf die
Testverfahren [00:32:59] Links und Literatur zu Softwaretests
[00:34:36] Projektpräsentation und Rückengesundheit im Blog
[00:35:44] Fachartikel zu WireMock [00:36:19] Newsletter und
Materialien zur Projektarbeit [00:37:15] Fragen für Episode 100 und
Ausblick Inhalt Wie lassen sich Testverfahren klassifizieren? Was
wird getestet? Komponente, Integration mehrerer Komponenten oder
das ganze System. Funktionale oder nicht-funktionale Anforderungen.
Wie werden sie durchgeführt? Durch den Menschen (manuell) oder eine
Maschine (automatisch). Wer führt sie durch? Entwickler oder
Fachbereich. Welche Kenntnisse sind für die Erzeugung von
Testfällen nötig? Nur das nach außen sichtbare Verhalten
(Black-Box) oder auch der Sourcecode (White-Box). Wann werden die
Tests erstellt? Test first vs. test last. Alpha-/Beta-Test. Wird
die Software für den Test ausgeführt (dynamisch) oder nicht
(statisch)? Welches Ziel verfolgen die Tests? Z.B. Regression
verhindern, Last simulieren. Was ist der Unterschied zwischen
Black- und White-Box-Test? Bei Black-Box-Tests kennt der Tester
nicht die interne Struktur der Software, sondern sieht nur das nach
außen sichtbare Verhalten. Beim White-Box-Test wird der Sourcecode
mit einbezogen, um z.B. bestimmte Testfälle zu definieren. Was sind
Anweisungs-, Zweig- und Pfadüberdeckung? Alle sind Maße für die
Testabdeckung des Codes. Bei der Anweisungsüberdeckung (C0) wird
jede Anweisung im Code mind. einmal durchlaufen. Bei der
Zweigüberdeckung (C1) wird jeder Zweig im Code mind. einmal
durchlaufen. Das heißt, bei if-Anweisungen wird sowohl der if-Zweig
als auch der else-Zweig durch einen Test abgedeckt. Sie inkludiert
die Anweisungsüberdeckung. Bei der Pfadüberdeckung (C2) werden alle
Pfade durch den Code getestet. Das heißt, dass z.B. alle möglichen
Wege durch Schleifen abgedeckt sein müssen. Sie inkludiert die
Zweigüberdeckung. Was ist die zyklomatische Komplexität? Ein Maß
für die Anzahl der möglichen Pfade durch den Code. Welche sonstigen
Testverfahren gibt es noch? Abnahmetest oder Akzeptanztest (User
Acceptance Test): Finaler Test des Kunden, der das Projekt
offiziell beendet. Lasttest: Das System wird unter hohe Last
gesetzt, um z.B. den gleichzeitigen Zugriff vieler Benutzer zu
simulieren. Smoketest: Erster grober Test der Software, um
entscheiden zu können, ob weitere detaillierte Tests überhaupt
sinnvoll sind. Exploratives Testen: einfaches "Ausprobieren" durch
erfahrene Benutzer. Literaturempfehlungen Wenn du dich wirklich
intensiv mit Softwaretests auseinandersetzen willst (oder musst)
und auch etwas akademischer werden möchtest, gibt es eigentlich nur
eine Empfehlung: Software-Qualität: Testen, Analysieren und
Verifizieren von Software* von Peter Liggesmeyer. Das Buch hat mich
persönlich bei meiner eigenen Masterarbeit zum Thema
Test-Driven-Development begleitet und liefert knackige Definitionen
für alle möglichen Begriffe aus dem Umfeld der Softwaretests. Es
geht aber auch weit über das Testen hinaus und erklärt z.B. auch
statische Codeanalyse und Code-Review-Verfahren. * Links Permalink
zu dieser Podcast-Episode RSS-Feed des Podcasts Links Smoke testing
– Wikipedia Softwaretest – Wikipedia Kontrollflussorientierte
Testverfahren – Wikipedia McCabe-Metrik – Wikipedia Testabdeckung –
Wikipedia Zusammenfassung Testverfahren im Fachgespräch einordnen
Bei einer offenen Frage wie "Welche Testverfahren kennst du?"
erwarte ich eine strukturierte Antwort. Als IT-Azubi kannst du dich
an diesen Fragen orientieren: Was wird getestet? Eine einzelne
Komponente, das Zusammenspiel mehrerer Komponenten oder das gesamte
System? Welche Anforderungen werden geprüft? Wie werden die Tests
durchgeführt? Manuell durch einen Menschen oder automatisch durch
den Computer? Wer führt sie durch? Entwickler:innen, der
Fachbereich, eine Testabteilung oder Kund:innen? Welche Kenntnisse
brauchst du für die Testfälle? Kennst du den Quellcode oder
betrachtest du das Verhalten über Eingaben und Ausgaben? Wann
werden die Tests erstellt? Vor oder nach dem Produktivcode? In
welcher Phase des Projekts finden sie statt? Wird die Software
ausgeführt? Das bestimmt, ob das Verfahren dynamisch oder statisch
ist. Welches Ziel haben die Tests? Beispielsweise Fehler finden,
Regressionen erkennen, Last simulieren oder die Software abnehmen.
Ein Testverfahren lässt sich mehreren Kategorien zuordnen. Ein
Unit-Test prüft etwa eine einzelne Komponente, läuft meist
automatisch und wird von Entwickler:innen geschrieben. Weil dabei
Code ausgeführt wird, gehört er zu den dynamischen Verfahren. Der
Testcode kann vor oder nach dem Produktivcode entstehen. Was du
testest Komponenten- oder Unit-Test: Du prüfst die kleinste zu
testende Einheit deiner Software, häufig eine Methode. Sie wird
üblicherweise isoliert getestet. Integrationstest: Du prüfst, wie
mehrere Komponenten zusammenarbeiten, beispielsweise eine Klasse
mit einer Datenbankklasse. Systemtest: Du prüfst das gesamte
System. Ein Beispiel ist eine Aktion über die Oberfläche, die bis
zur Datenbank reicht. Bei einem Taschenrechner kannst du prüfen, ob
die Addierfunktion das erwartete Ergebnis liefert. Damit testest du
eine funktionale Anforderung. Zu den nicht funktionalen
Anforderungen gehören unter anderem Performance und Sicherheit
sowie Ausfallsicherheit oder Effizienz. Für einen Performance-Test
brauchst du messbare Erwartungen, etwa eine zulässige Antwortzeit
und einen Toleranzbereich. Die Frage, ob eine Antwort schnell genug
kommt, setzt voraus, dass du festgelegt hast, welche Zeit
akzeptabel ist. Wie und durch wen getestet wird Wenn ein:e
Tester:in die Anwendung bedient und Ergebnisse protokolliert,
kostet das Arbeitszeit. Wiederholte manuelle Tests verursachen
entsprechend laufenden Aufwand. Automatische Tests lassen sich
schnell und mit geringen Kosten pro Durchlauf wiederholen. Das ist
bei neuen Releases relevant, weil Änderungen auch bereits
vorhandene Funktionen beschädigen können. Entwickler:innen
schreiben beispielsweise Unit-Tests und bringen ihr Wissen über den
Code ein. Im Fachbereich stehen fachliche Abläufe im Mittelpunkt;
dort werden häufig manuelle Tests durchgeführt. Auch Kund:innen
oder eine eigene Testabteilung können die Software prüfen. Blackbox
und Whitebox Beim Blackbox-Test leitest du Testfälle aus dem von
außen sichtbaren Verhalten ab. Du gibst Werte ein und prüfst die
Ausgabe, während die interne Struktur für dich verborgen bleibt.
Für einen Whitebox-Test kennst du den Quellcode. Dadurch kannst du
Testfälle gezielt auf Verzweigungen oder Schleifen ausrichten. Wenn
du etwa eine Grenze im Code erkennst, kannst du einen Wert
außerhalb dieser Grenze ausprobieren. Dieses Wissen hilft auch
dabei, Sonderfälle zu finden, die bei alltäglichen fachlichen
Abläufen selten auftreten. Wann Tests entstehen Beim Test First
schreibst du den Test vor dem zugehörigen Produktivcode. Dieser
Ansatz gehört zum Test-Driven Development, bei dem die Tests auch
das Design und die Implementierung vorantreiben. Ich empfehle dir,
Tests zuerst zu schreiben. Bei Test Last entstehen die Tests nach
dem Produktivcode. Wenn sich das Projektende nähert und Zeit knapp
wird, besteht das Risiko, dass die geplanten Tests entfallen. Auch
die Projektphase spielt eine Rolle: Ein Alpha-Test kann mit einer
ersten lauffähigen Version prüfen, ob die Software grundsätzlich
das Gewünschte tut. Ein Beta-Test findet nahe am Release
beziehungsweise vor der ersten verkaufsfähigen Version statt, um
verbliebene Fehler aufzuspüren. Dynamische und statische Verfahren
Während eines dynamischen Tests wird die Software ausgeführt,
beispielsweise bei einem Unit-Test. Bei statischen Verfahren wird
der Code untersucht. Dazu gehören Code-Reviews, bei denen ein
Mensch den Quellcode liest, und Werkzeuge zur statischen
Codeanalyse. Genannte Beispiele sind FindBugs und PMD für Java
sowie FxCop für .NET. Auch mathematische Verfahren, mit denen sich
die Korrektheit von Code beweisen lässt, werden angesprochen. Was
Tests nachweisen können Mit Tests findest du Fehler und bestätigst,
dass sich die Software in den geprüften Fällen wie erwartet
verhält. Eine Aussage über sämtliche denkbaren Fälle würde
erschöpfendes Testen voraussetzen. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.