cleared cache because workspace.json is abnoxious
This commit is contained in:
@@ -1,186 +0,0 @@
|
||||
Softwaretest (Was ist klausurrelevant?)
|
||||
Klausur besteht aus zwei Teilen:
|
||||
Ankreuzen (30 Fragen, 1 Punkt, immer nur eine richtig)
|
||||
Freitextaufgaben (Begründen oder unterscheiden usw. aber immer nur kurze Texte, zwischen 2 und 6 Punkte pro Aufgabe)
|
||||
14 - 15:30 am 15.07.
|
||||
|
||||
Kapitel 0
|
||||
Folien:
|
||||
Die Tatsache das es unmöglich ist eine Software vollständig zu testen und Fehlerfreiheit zu garantieren.
|
||||
|
||||
Kapitel 1
|
||||
Folien:
|
||||
- [x] 7 Fehler und Mangel Unterschied
|
||||
- [x] 12 Begriffe und deren Zusammenhang
|
||||
- [x] 15 Validierung Verifikation
|
||||
- [x] 17 Unterscheidungen zwischen funktionalen- und nichtfunktionalen Anforderungen sollte klar sein und mit Beispielen belegen
|
||||
- [x] 17 - … Qualitätsmerkmale Beispiele benennen können oder was dazu sagen können (aber nicht im Detail) Nur eine Vorstellung davon haben, was das bedeutet.
|
||||
- [x] 30 Zwischen analytischer- und konstruktiver Qualitätssicherung unterscheiden können.
|
||||
- [x] 33 Grundsätze kennen, nicht auswendig wiedergeben aber zumindest verstehen was damit gemeint ist.
|
||||
- [x] 48 Faktoren die den Testprozess beeinflussen können (Keine Detailfragen)
|
||||
- [x] 50 Rückverfolgbarkeit (Horizontal und Vertikal)
|
||||
- [x] 51 Aktivitäten des Testprozesses sollten klar sein und wer das durchführt.
|
||||
- [x] 54 Grob wissen was die Testüberwachung und -Steuerung beinhaltet. Sachen einordnen können.
|
||||
- [x] Folgefolien: Grob verstehen was die einzigen Aktivitäten sind.
|
||||
- [x] 69 Da ist sie ja wieder die Rückverfolgbarkeit
|
||||
- [x] 73 Unterschied zwischen abstrakten und konkreten Testfällen (Testentwurf immer abstrakt bsp. Äquivalenzklassen, Realisierung ist dann konkret weil da müssen wir dann ja Werte einfügen)
|
||||
- [x] 74 Testspezifikation (Wie viele Testfälle brauchen wir hier)
|
||||
- [x] 76 Das Testorakel
|
||||
- [ ] 81 Entwicklertests bei Psychologie des Testens
|
||||
- [ ] 82 Vor und Nachteile vom unabhängigen Testen nochmal durchlesen und verstehen.
|
||||
- [ ] 83 Abstufungen
|
||||
- [ ] 91 Fragen sollte man beantworten können (Sind da wirklich alle wichtig?) Der Begriff Fehlermaskierung sollte klar sein genauso wie der Unterschied zwischen Testen und Debugging.
|
||||
|
||||
Kapitel 2
|
||||
Folie:
|
||||
- [x] 10 Verschiedene Teststufen sollten bekannt sein.
|
||||
- [x] 15 Validierung
|
||||
- [x] 16 Verifizierung (Bilder oben in der Ecke sind falschrum. Validierung links, Verifizierung rechts)
|
||||
- [x] 17 Nochmal Unterschied zwischen Validierung und Verifizierung
|
||||
- [x] 25 Continuous Integration (wissen was das ist)
|
||||
- [x] Auf agiles Testen wird nicht eingegangen
|
||||
- [x] 27 Testaktivitäten, Tester früher einbinden
|
||||
- [x] Folgende Folien Verschiedene Teststufen kennen, Testbasen kennen
|
||||
- [x] 40 Isoliert wird getestet, Test driven Development
|
||||
- [x] 51 Ingegrationstest Fehlerzustände und Fehlerwirkungen nochmal lesen und verstehen (Vom Prinzip her)
|
||||
- [x] 56 Nochmal das Gleiche nur im Unit Test
|
||||
- [x] 71 Systemtest, Betrachtung des System als ganzen
|
||||
- [x] 73 Testziele, welche Aspekte sind relevant?
|
||||
- [x] 76 Fehlerzustände und Fehlerwirkungen lesen
|
||||
- [x] 82 Verständnis für nichtfunktionale Anforderungen
|
||||
- [x] 91 Einfach nochmal durchlesen (eventuell keine Frage dazu, aber kann man mit nachdenken ein Beispiel benennen)
|
||||
- [x] 95 Spezielle Form des Systemtests
|
||||
- [x] 106 Unterschied Alpha und Beta Test (Alpha intern, Beta - Software wird nach außen gegeben)
|
||||
- [x] 111 Funktionale, Nichtfunktionale, Strukturelle und Änderungsbezogene Tests. Fehlernach und Regressionstest
|
||||
- [x] 112 Teststufen und Testarten
|
||||
- [x] 113 Funktionale Tests
|
||||
- [x] 114 Nichtfunktionale Tests
|
||||
- [x] 115 White-Box Tests
|
||||
- [ ] 123 Testarten und Teststufen (Bankanwendung mal durchlesen)
|
||||
- [ ] Verschiedene Anlässe für Wartungen
|
||||
- [ ] 130 Typische Wartungsanlässe sollen grob klar sein. Additive Wartung und andere drei Begriffe sollten klar sein.
|
||||
- [ ] 140 Könnte man sich nochmal anschauen um einen Überblick zu bekommen
|
||||
- [ ] 142 Fragen sollten beantwortet werden können.
|
||||
|
||||
Kapitel 3
|
||||
Folie:
|
||||
- [ ] 6 Software-Qualitätssicherung
|
||||
- [ ] 18 Grundlegende Arbeitsschritte Reviews sollte so wiedergegeben werden können.
|
||||
- [ ] 20 Sollte soweit klar sein.
|
||||
- [ ] 27 Grob was da steht aber nicht jedes Detail
|
||||
- [ ] 39 Ablauf eines Reviewprozesses sollte grundlegend klar sein.
|
||||
- [ ] 41 Rollen
|
||||
- [ ] 42 Reviewarten und sortieren können und grob wissen was das jeweils bedeutet und wo die Unterschiede sind. (Wenn ein Reviewprozess sehr formell durchgeführt wird, was könnte das für ein Prozess sein?)
|
||||
- [ ] 56 Reviewarten zusammengefasst sollte verstanden werden. Alles außer Frage 3 wichtig
|
||||
- [ ] 84 Datenflussanalyse und
|
||||
- [ ] 89 Datenflussanomalien kennen und wissen was das ist (benennen)
|
||||
- [ ] 94 Begriffe verstehen und erklären können
|
||||
- [ ] 98 Zyklomatische Zahl
|
||||
- [ ] 99 Maßtypen
|
||||
- [ ] 100 Wie berechnet man die zyklomatische Zahl
|
||||
|
||||
Kapitel 4.1
|
||||
Folie:
|
||||
- [ ] 5 Blackbox von Whitebox unterscheiden können
|
||||
- [ ] 7 Statischen vom Dynamischen Test abgrenzen können.
|
||||
- [ ] 8 Begriffe sollten alle klar sein
|
||||
- [ ] 13 Rückverfolgbarkeit
|
||||
- [ ] 17 Aufbau eines Testrahmens
|
||||
- [ ] 18 Begriffe
|
||||
- [ ] 24 Blackbox
|
||||
- [ ] 44 Heuristiken und wie man damit die Testfälle minimiert.
|
||||
- [ ] 64 Begriffe
|
||||
- [ ] 66 Zustandsübergangstabelle sollte klar sein
|
||||
- [ ] 69 Der Ablauf sollte klar sein
|
||||
- [ ] 85 Entscheidungstabellentest Beispiel
|
||||
- [ ] 109 Fragen beantworten können
|
||||
|
||||
Kapitel 4.1
|
||||
Folie:
|
||||
- [ ] 3 Begriffe und Zusammenhänge verstehen
|
||||
- [ ] 5 Blackbox Whitebox immer in Kombination, Fokus auf Blackbox. Erfahrungsbasierte können zusätzlich gemacht werden als Ergänzung
|
||||
- [ ] Kontrollflusstest und Bedingungstest sollten klar sein.
|
||||
- [ ] 7 Das ist sowieso wichtig
|
||||
- [ ] 9 Begriffe
|
||||
- [ ] 10 Arten von Kontrollflusstests und welchen Sinn die haben (wichtig) -> in Folie 11 besser dargestellt.
|
||||
- [ ] Anweisungsüberdeckung und Entscheidungsüberdeckung
|
||||
- [ ] 13 Sollte klar sein, wie sie sich unterscheiden.
|
||||
- [ ] 16/17 Anweisungsüberdeckung und was man da beachten sollte - Wenn Coverage nicht erreicht wird, dann müssen neue Tests geschrieben werden.
|
||||
- [ ] 30 Grenze-Inneres-Überdeckung
|
||||
- [ ] 33 Pfadüberdeckung - theoretische Metrik...
|
||||
- [ ] 39 Instrumentierung sollte klar sein.
|
||||
- [ ] 41 Datenflusstest - Definitionen, c-user und p-use Unterschiede sollten klar sein.
|
||||
- [ ] 47 Bedingungstest - und die anderen die vorher/nacher sind sollte man auch kennen. Unterscheidungen sollen klar sein und auch Beispiel sollte man geben können?
|
||||
- [ ] 49 und fortfolgend, Verschiedene Arten von Bedingungsüberdeckung sollten klar sein.
|
||||
- [ ] 58 Lazy Evaluation sollte erklärt werden können und was das für die Praxis bedeutet.
|
||||
- [ ] 61 Mächtigkeit der White-Box-Testverfahren (Welcher der Aussagen ist richtig) - Prinzip soll verstanden sein.
|
||||
- [ ] 65/66 Erfahrungsbasierte Testverfahren
|
||||
- [ ] 67 Intuitive Testfallermittlung
|
||||
- [ ] 69 Exploratives Testen - Keine Details fragen
|
||||
- [ ] 73 Begriffe sollten klar sein.
|
||||
- [ ] Nur auf höherer Ebene, nicht auf Unit-Ebene
|
||||
- [ ] 83 Zusammenfassung dynamischer Tests
|
||||
- [ ] Und dann halt die Zusammenfassung von dem Kapitel kann man sich am Ende des Foliensatzes auch nochmal anschauen.
|
||||
|
||||
Kapitel 5
|
||||
Folie:
|
||||
- [ ] 3 Was man nach dem Kapitel wissen sollte.
|
||||
- [ ] 8 Vor und Nachteile des unabhängigen Testen
|
||||
- [ ] 15 Aufgaben von Mitarbeiterqualifikationen einzelne Begriffe kennen.
|
||||
- [ ] 17/18/19/20 Aufgabenunterteilung sollte bekannt sein. Unterschiede sollen klar sein.
|
||||
- [ ] 21 Aufgaben des Testers
|
||||
- [ ] 26 Wann soll mit dem Testen begonnen werden?
|
||||
- [ ] 28 Aktivitäten der Testplanung - Eine Vorstellung davon haben, was das ist.
|
||||
- [ ] 33 Soll klar sein
|
||||
- [ ] 34 Sollte klar sein
|
||||
- [ ] 37 Das Bild fast die Einflussfaktoren einmal ganz gut zusammen.
|
||||
- [ ] 45 Fragen sollten beantwortet werden können. (Wie in jedem Kapitel, sind gut um sich auf die Prüfung vorzubereiten)
|
||||
- [ ] 50 Schätzung des Testaufwands
|
||||
- [ ] 51 und folgend: Grob die Verfahren kennen, aber muss nicht auswendig gelernt werden. Begriffe kennen, unterscheiden können.
|
||||
- [ ] 59 Testmetriken - Fehlerbasierte und Testfallbasierte Metriken
|
||||
- [ ] 61/62 Begriffe sollten klar sein und soll erklärt werden können, was damit gemeint ist.
|
||||
- [ ] 64 Sinn sollte klar sein
|
||||
- [ ] 67 Eingangs- und Endekriterien sollen klar sein.
|
||||
- [ ] 71 Testfortschritts- und Testabschlussbericht wissen was das ist
|
||||
- [ ] 73 ISO-Norm kennen, aber halt nur erklären können und nicht auswendig
|
||||
- [ ] 74 Sollte klar sein was da steht.
|
||||
- [ ] 75 Teststeuerung, Punkte nochmal durchlesen zum verinnerlichen was für Maßnahmen zur Teststeuerung man machen kann.
|
||||
- [ ] 82 Gleichung kennen und Unterscheidung zwischen Produkt und Projektrisiken kennen.
|
||||
- [ ] 89 Produktrisiken
|
||||
- [ ] 97 Risikoorientierte Testplanung Tabelle mit den Inhalten verstehen. "Zahlen die da genannt werden sind haarsträubend"
|
||||
- [ ] 99 Fragen beantworten können
|
||||
- [ ] 101 Fehler- und Abweichungsmanagement
|
||||
- [ ] 102 Testprotokoll: Ursachenalayse ist Aufgabe der Entwickler
|
||||
- [ ] 103 Fehlermeldung Grundprinzip Ziele sollte man verstanden haben.
|
||||
- [ ] 105 Fehlerbericht - einheitliches Schema kennen.
|
||||
- [ ] 109 Bedeutung der Klassen mal anschauen und kennen.
|
||||
- [ ] 110 Priorität für die auf 109 beschriebenen Klassen
|
||||
- [ ] 112 Fehlerstatusmodell
|
||||
- [ ] 121 Begriffe kennen und Unterschiede kennen
|
||||
- [ ] 125/126 Fragen sollte man beantworten können.
|
||||
- [ ] 151 Fehler und Folgefehler
|
||||
- [ ] 155 Diese Folien mal merken
|
||||
|
||||
Kapitel 6
|
||||
Folie:
|
||||
- [ ] 6 Werkzeugunterstützung für das Testen (Bild betrachten)
|
||||
- [ ] 7 Bild nochmal
|
||||
- [ ] 11-14 Wichtig sind: Fehlermanagementwerkzeuge, Anforderungsmanagement, Fehlermanagementwerkezuge,
|
||||
- [ ] 16 Typen von Testwerkzeugen
|
||||
- [ ] 17 Review Werkzeuge
|
||||
- [ ] 18 Statische Analysewerkzeuge
|
||||
- [ ] 27-29 Testausführungswerkzeuge - 28 Unten die Unterschiedlichen Ansätze zur Automatisierung der Testdurchführung sollen bekannt sein. - Komparatoren uns sowas 29 soll auch bekannt sein.
|
||||
- [ ] 30 Ausführung und Protokollierung Bild mal anschauen
|
||||
- [ ] 31/32 Capture/Replay-Werkzeuge, sollte bekannt sein.
|
||||
- [ ] 35 Mal anschauen
|
||||
- [ ] 36 Überdeckungswerkzeuge
|
||||
- [ ] 39 Simulatoren
|
||||
- [ ] 48 Werkzeuge für Gebrauchstauglichkeitstest
|
||||
- [ ] 51 Werkzeuge für IT-Sicherheitstest
|
||||
- [ ] 57 Risiken von Testwerkzeugen ("Vielleicht könnten ein zwei Beispiele erfragt werden")
|
||||
- [ ] 59 Lernkurveneffekt
|
||||
- [ ] 62 Einführungsreihenfolge vielleicht ganz gut zu wissen
|
||||
- [ ] 65 Schritte sollen bekannt sein und was da zu tun ist.
|
||||
- [ ] 71 Grafik mal anschauen
|
||||
- [ ] 76 Vielleicht einmal durchlesen und verstehen um was es da geht.
|
||||
- [ ] 81/82 Fragen beantworten können (Statische Analyse, welche... "Die Frage könnte drann kommen") 82 - Vielleicht zwei Beispiele benennen können
|
||||
@@ -1,13 +0,0 @@
|
||||
# Durchlesen der Zusammenfassungen
|
||||
- [ ] Kap 0
|
||||
- [ ] Kap 1
|
||||
- [ ] Kap 2
|
||||
- [ ] Kap 3
|
||||
- [ ] Kap 4-1
|
||||
- [ ] Kap 4-2
|
||||
- [ ] Kap 5
|
||||
- [ ] Kap 6
|
||||
|
||||
## Bearbeitung der Aufgaben
|
||||
|
||||
## Zusammensuchen von Klausuren und Tests
|
||||
@@ -1,5 +0,0 @@
|
||||
- Stumpfes auswendiglernen ist nicht
|
||||
- Begrifflichkeiten und logik müssen sitzen
|
||||
|
||||
- blackbox first, danach whitebox (um kenntnisse von internen vorg. zu meiden
|
||||
- )
|
||||
@@ -1,23 +0,0 @@
|
||||
## English
|
||||
|
||||
https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_v4.0_Sample-Exam-A-Questions_v1.6.pdf
|
||||
|
||||
https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
|
||||
|
||||
https://www.gtb.de/wp-content/uploads/2023/11/ISTQB_CTFL40_Sample-Exam-Questions_SET-A_v2.1_engl.pdf
|
||||
|
||||
https://www.processexam.com/files/processexam/download/CTFL-ISTQB-Certified-Tester-Foundation-Level.pdf
|
||||
|
||||
https://astqb.org/assets/documents/ISTQB_CTFL_Sample-Exam-Answers_v4.0.pdf
|
||||
|
||||
https://isqi.org/media/69/47/e5/1734010610/ISTQB_CTFL40_Sample-Exam-Answers_SET-A_v2.1_GTB-edition_engl_EN_.pdf
|
||||
|
||||
https://www.gtb.de/wp-content/uploads/2024/09/ISTQB_CTFL40_Sample-Exam-Questions_SET-E_v1.0_GTB-edition_engl.pdf
|
||||
|
||||
https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
|
||||
## German
|
||||
https://isqi.org/media/8a/d4/a5/1713444247/GTB-CTFL-AcT_Sample-Exam-Answers_v2019_DE_.pdf
|
||||
|
||||
https://assets.brightest.org/media/resources/ISTQB_CTFL_2018_Sample_Exam_Questions_German.pdf
|
||||
|
||||
https://swisstestingboard.org/wp-content/uploads/2024/11/GTB-CTFL-FA_2015A_Sample_Exam_Paper_v20_DE.pdf
|
||||
@@ -1,97 +0,0 @@
|
||||
## 🎯 ZIELE DER LEHRVERANSTALTUNG
|
||||
|
||||
- Vermittlung von **Grundlagen im Softwaretesten**
|
||||
- Verständnis für **Begriffe, Aufgaben, Methoden & Verfahren**
|
||||
- Vorbereitung auf die **CTFL-Prüfung** (international anerkannt)
|
||||
|
||||
---
|
||||
|
||||
## 🧪 WARUM SOFTWARETEST?
|
||||
|
||||
### Beispiele schwerwiegender Softwarefehler:
|
||||
|
||||
- ❌ Ariane 5: Absturz durch Reuse fehlerhafter Lageregelungssoftware
|
||||
- ❌ T-Mobile (2009): Netzstörung durch Fehler im HLR
|
||||
- ❌ Deutsche Bank / BAföG / GM / Roche: Fehler mit realen Konsequenzen
|
||||
|
||||
➡️ Softwarefehler führen zu:
|
||||
|
||||
- **wirtschaftlichen Schäden**
|
||||
- **Lebensgefahr (z. B. Medizintechnik, Automotive)**
|
||||
- **Imageverlust**
|
||||
|
||||
---
|
||||
|
||||
## 💥 BEGRIFFE: Fehler, Bug, Defekt
|
||||
|
||||
- **Fehler (Defect)**: Abweichung vom erwarteten Verhalten
|
||||
- **Bug**: oft als Synonym genutzt
|
||||
- **Erster dokumentierter Bug**: Motte im Relay (1947)
|
||||
|
||||
---
|
||||
|
||||
## 🧠 TESTBARENGRUNDLAGEN
|
||||
|
||||
- Vollständiges Austesten ≠ realistisch möglich
|
||||
- Beispiel 1: 3 Eingabewerte à 16 Bit → 2⁴⁸ Kombinationen → **ca. 90 Jahre**
|
||||
- Beispiel 2: Schleifen + Verzweigungen → 10¹⁴ Testfälle → **38 Jahre**
|
||||
|
||||
➡️ **Testen ist selektiv & risikobasiert notwendig!**
|
||||
|
||||
---
|
||||
|
||||
## 🔍 TESTKATEGORIEN (am Beispiel „Dreieckprogramm“)
|
||||
|
||||
### Testziele:
|
||||
|
||||
- **Funktionalität prüfen**: korrektes Verhalten bei Eingaben
|
||||
- **Fehlerhafte Eingaben erkennen**: negative Zahlen, zu viele/wenige Werte etc.
|
||||
- **Grenzwerte testen**: z. B. `0`, `Max_Int`
|
||||
|
||||
### Beispiel-Testfälle:
|
||||
|
||||
- Gleichseitig: 2,2,2
|
||||
- Ungleichseitig: 2,3,4
|
||||
- Ungültig: -5, 0, Zeichen, zu viele Werte
|
||||
- Spezialfälle: Kombinationen nahe Grenzwerten
|
||||
|
||||
➡️ **Testdaten ≠ zufällig**, sondern **gezielt konstruiert**
|
||||
|
||||
---
|
||||
|
||||
## 🚗 PARALLELEN ZUR INDUSTRIE
|
||||
|
||||
**Automobilindustrie**:
|
||||
|
||||
- Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
|
||||
|
||||
➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
|
||||
|
||||
---
|
||||
|
||||
## 💬 FAZIT / MERKSPRÜCHE
|
||||
|
||||
- **„Testen zeigt die Anwesenheit von Fehlern, nicht ihre Abwesenheit.“**
|
||||
- **„Ein Test ohne definiertes Ziel ist Zeitverschwendung.“**
|
||||
- **„Keine Software ist fehlerfrei.“**
|
||||
- **„Vollständiges Austesten ist meist unmöglich.“**
|
||||
|
||||
---
|
||||
|
||||
## 📚 LITERATUR & WEITERFÜHRENDES
|
||||
|
||||
- Lehrbuch: **Spillner/Linz** – _Basiswissen Softwaretest_
|
||||
- Weitere: Beizer, Myers, Liggesmeyer, TMap, ISO 29119
|
||||
- Fachzeitschriften & Konferenzen: _GTB_, _EuroSTAR_, _ICST_
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE KERNAUSSAGEN
|
||||
|
||||
|Thema|Prüfungstauglicher Merksatz|
|
||||
|---|---|
|
||||
|Fehlerauswirkungen|Kleine Fehler können große Folgen haben|
|
||||
|Austestbarkeit|Testabdeckung muss begrenzt & gezielt sein|
|
||||
|Dreieck-Programm|Guter Einstieg zur **Testfallerstellung**|
|
||||
|Zertifizierung|ISTQB CTFL ist international anerkannt|
|
||||
|Test ist wichtig|Auch einfache Programme sind schwer zu testen|
|
||||
@@ -1,88 +0,0 @@
|
||||
## 📘 KAPITEL 1: GRUNDLAGEN DES TESTENS
|
||||
|
||||
---
|
||||
|
||||
### 1.1 Warum ist Testen notwendig?
|
||||
|
||||
- Softwarefehler können **Kosten, Sicherheitsprobleme, Rufschädigung** verursachen.
|
||||
- Gründe für Fehler:
|
||||
- Missverständnisse, Zeitdruck, komplexe Systeme, neue Technologien.
|
||||
- **Testen reduziert Risiken**, aber **kann Fehler nicht vollständig beseitigen**.
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Was ist Testen?
|
||||
|
||||
- Testen = **Planung, Vorbereitung, Durchführung & Bewertung** von Softwaretests.
|
||||
- Ziel:
|
||||
- Fehler finden
|
||||
- Vertrauen schaffen
|
||||
- Konformität mit Anforderungen prüfen
|
||||
- Grundlage für Qualität liefern
|
||||
|
||||
---
|
||||
|
||||
### 1.3 Allgemeine Testziele
|
||||
|
||||
|Zieltyp|Beschreibung|
|
||||
|---|---|
|
||||
|**Fehlervorbeugung**|Schon in frühen Phasen vermeiden|
|
||||
|**Fehlererkennung**|Möglichst früh entdecken|
|
||||
|**Verifikation**|Korrektheit prüfen: „bauen wir es richtig?“|
|
||||
|**Validierung**|Zweck prüfen: „bauen wir das Richtige?“|
|
||||
|
||||
---
|
||||
|
||||
### 1.4 Testen und Debuggen
|
||||
|
||||
- **Testen**: Fehler _finden_
|
||||
- **Debuggen**: Fehler _analysieren und beheben_
|
||||
|
||||
➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Sieben Prinzipien des Testens (💡 Prüfungsrelevant)
|
||||
|
||||
1. **Testen zeigt Anwesenheit von Fehlern, nicht deren Abwesenheit**
|
||||
2. **Vollständiges Testen ist nicht möglich**
|
||||
3. **Frühes Testen spart Zeit und Geld**
|
||||
4. **Fehlerhäufung in bestimmten Bereichen (Pareto-Prinzip)**
|
||||
5. **Testwiederholungen → Testfälle anpassen (Testfallverfall)**
|
||||
6. **Testen ist kontextabhängig (z. B. sicherheitskritisch vs. Webshop)**
|
||||
7. **Trugschluss Fehlerfreiheit ≠ Gebrauchstauglichkeit**
|
||||
|
||||
---
|
||||
|
||||
### 1.6 Testprozess (Phasenmodell)
|
||||
|
||||
1. **Testplanung und -steuerung**
|
||||
2. **Testanalyse und -design**
|
||||
3. **Testrealisierung und -durchführung**
|
||||
4. **Testauswertung und -abschluss**
|
||||
|
||||
➡️ Unterstützt durch **Testüberwachung, Metriken & Dokumentation**
|
||||
|
||||
---
|
||||
|
||||
### 1.7 Psychologie des Testens
|
||||
|
||||
- Zielkonflikt Entwickler vs. Tester:
|
||||
- Entwickler: „Software funktioniert!“
|
||||
- Tester: „Software hat Schwächen!“
|
||||
|
||||
🧠 Gute Zusammenarbeit & Kommunikation sind entscheidend:
|
||||
|
||||
- **Objektivität, Kritikfähigkeit, keine Schuldzuweisungen**
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Testzweck|Fehler _finden_, nicht beseitigen|
|
||||
|Prinzipien|7 Prinzipien **verstehen & benennen können**|
|
||||
|Test vs. Debugging|Zwei **getrennte Prozesse**|
|
||||
|Testprozesse|Test hat **strukturierte Phasen**|
|
||||
|Testpsychologie|**Konstruktives Konfliktmanagement** notwendig|
|
||||
@@ -1,83 +0,0 @@
|
||||
## 📘 KAPITEL 2: TESTEN IM SOFTWARELEBENSZYKLUS
|
||||
|
||||
---
|
||||
|
||||
### 2.1 Softwareentwicklungsmodelle
|
||||
|
||||
**Testen muss in den gesamten Entwicklungsprozess integriert sein!**
|
||||
|
||||
#### a) Sequenzielle Modelle (klassisch, Wasserfall, V-Modell)
|
||||
|
||||
- **Vorteil**: frühzeitige Planung, klare Phasen
|
||||
- **Nachteil**: späte Fehlererkennung, wenig flexibel
|
||||
|
||||
#### b) Iterative/inkrementelle Modelle (z. B. Agile)
|
||||
|
||||
- **Testen** = integraler Bestandteil jeder Iteration
|
||||
- Kontinuierliches Feedback, frühe Tests
|
||||
- Flexibler, aber aufwändiger
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Teststufen (💡 Prüfungsrelevant)
|
||||
|
||||
|Teststufe|Fokus|Testbasis|Ziel|
|
||||
|---|---|---|---|
|
||||
|**Komponententest**|Einzelprogramme/Funktionen|Source Code, Design Specs|Fehler in Modulen erkennen|
|
||||
|**Integrationstest**|Zusammenspiel von Komponenten|Schnittstellenspezifikation|Fehler in Modulen & Interfaces|
|
||||
|**Systemtest**|Gesamtsystem|Anforderungen|Anforderungen erfüllt?|
|
||||
|**Abnahmetest**|Validierung mit Nutzer|Businessanforderungen|Auslieferungsreife prüfen|
|
||||
|
||||
🔄 **Statische Tests** (Reviews) ergänzen die Teststufen
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Testarten (Was wird getestet?)
|
||||
|
||||
#### Funktionale Tests
|
||||
|
||||
- Verhalten & Funktionen
|
||||
- z. B. Geschäftslogik, Benutzerinteraktion
|
||||
|
||||
#### Nicht-funktionale Tests
|
||||
|
||||
- **Leistung**, **Benutzbarkeit**, **Zuverlässigkeit**, **Sicherheit**
|
||||
- Beispiel: Lasttests, Sicherheitstests
|
||||
|
||||
#### Strukturbezogene Tests
|
||||
|
||||
- Interne Struktur (z. B. Codeabdeckung, Verzweigungspfad)
|
||||
|
||||
#### Änderungsbezogene Tests
|
||||
|
||||
- **Re-Tests**: Prüfen behobener Fehler
|
||||
- **Regressionstests**: Prüfen unbeabsichtigter Nebeneffekte
|
||||
|
||||
---
|
||||
|
||||
### 2.4 Wartungstest
|
||||
|
||||
- Tests im Produktivsystem nach Änderungen (Fehlerbehebung, Anpassung)
|
||||
- Besonders wichtig:
|
||||
- **Regressionstest**
|
||||
- **Impact-Analyse**
|
||||
- Testdaten und Testumgebung **aktuell halten**
|
||||
|
||||
---
|
||||
|
||||
### 2.5 Teststufen & Testarten kombinieren
|
||||
|
||||
- Beispiel: Im **Systemtest** können **funktionale Tests** UND **nicht-funktionale Tests** durchgeführt werden.
|
||||
- Jeder Teststufe können verschiedene **Testziele** zugeordnet werden.
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Prüfungswissen|
|
||||
|---|---|
|
||||
|V-Modell|Testaktivitäten sind klar definiert & gekoppelt mit Entwicklungsphasen|
|
||||
|Teststufen|**Komponente → Integration → System → Abnahme** (Reihenfolge merken!)|
|
||||
|Testarten|Funktional, Nicht-funktional, Struktur-, Änderungsbezogen|
|
||||
|Wartungstest|Regression und Impact-Analyse notwendig|
|
||||
|Agile Modelle|**Test = Teil jeder Iteration**|
|
||||
@@ -1,88 +0,0 @@
|
||||
## 📘 KAPITEL 3: STATISCHES TESTEN
|
||||
|
||||
---
|
||||
|
||||
### 3.1 Was ist statisches Testen?
|
||||
|
||||
- **Statisches Testen** = Analyse **ohne Programmausführung**
|
||||
- Ziel: **Frühzeitiges Erkennen** von Fehlern und Schwächen
|
||||
- Ergänzt dynamisches Testen (mit Programmausführung)
|
||||
|
||||
**Beispiele:**
|
||||
|
||||
- Dokumentation, Code, Testfälle, Anforderungen prüfen
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Arten statischer Tests
|
||||
|
||||
|Art|Merkmale|
|
||||
|---|---|
|
||||
|**Statische Analyse**|Automatisierte Tools analysieren Code-Struktur|
|
||||
|**Reviews (manuell)**|Menschen analysieren Dokumente & Artefakte|
|
||||
|
||||
---
|
||||
|
||||
### 3.3 Statische Analyse durch Tools
|
||||
|
||||
#### Ziele:
|
||||
|
||||
- Automatisierte Prüfung von Quellcode
|
||||
- **Vermeidung technischer Schulden**
|
||||
|
||||
#### Erkennbar durch Tools:
|
||||
|
||||
- **Syntaxfehler**
|
||||
- **Nicht initialisierte Variablen**
|
||||
- **Dead Code / nicht erreichbarer Code**
|
||||
- **Verletzungen von Codierstandards**
|
||||
- **Sicherheitslücken (z. B. Buffer Overflow)**
|
||||
|
||||
➡️ **Ergänzung, kein Ersatz für Reviews!**
|
||||
|
||||
---
|
||||
|
||||
### 3.4 Reviewarten (💡 Prüfungsrelevant)
|
||||
|
||||
|Reviewtyp|Beschreibung & Merkmale|
|
||||
|---|---|
|
||||
|**Informell**|z. B. Peer Review, keine Dokumentation|
|
||||
|**Walkthrough**|Autor führt Gruppe durch Dokument|
|
||||
|**Technisches Review**|Fokus auf Inhalte, nicht auf Format|
|
||||
|**Inspektion**|Strukturiert, mit Rollen, Protokollierung, Prüfprotokollen|
|
||||
|
||||
➡️ **Inspektion ist die formalste & effektivste Methode.**
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Rollen in einem Review
|
||||
|
||||
|Rolle|Aufgabe|
|
||||
|---|---|
|
||||
|**Autor**|Ersteller des Prüflings|
|
||||
|**Moderator**|Leitung & Organisation|
|
||||
|**Prüfer**|Suchen nach Defekten|
|
||||
|**Protokollant**|Dokumentiert Ergebnisse|
|
||||
|**Manager**|Review-Rahmenbedingungen schaffen|
|
||||
|
||||
---
|
||||
|
||||
### 3.6 Reviewprozess (z. B. Inspektion)
|
||||
|
||||
1. **Planung** (Teilnehmer, Artefakt, Reviewziel)
|
||||
2. **Kick-off** (Einführung, Zielklärung)
|
||||
3. **Einzelprüfung** (Teilnehmer sichten Artefakt individuell)
|
||||
4. **Review-Meeting** (gemeinsame Sichtung, Diskussion)
|
||||
5. **Nachbearbeitung** (Fehlerbehebung, Follow-up)
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Statisches Testen|Testen ohne Ausführen des Programms|
|
||||
|Reviewtypen|**Inspektion** = formal, **Walkthrough** = moderiert, informell|
|
||||
|Toolbasierte Analyse|Ergänzung zu manuellen Reviews, keine Ablösung|
|
||||
|Reviewrollen|Moderator ≠ Autor, Protokollant dokumentiert|
|
||||
|Nutzen|Frühes Feedback spart spätere Kosten|
|
||||
@@ -1,94 +0,0 @@
|
||||
## 📘 KAPITEL 4.1: TESTTECHNIKEN – GRUNDLAGEN
|
||||
|
||||
---
|
||||
|
||||
### 4.1 Einleitung: Warum Testverfahren?
|
||||
|
||||
- Systematisches Vorgehen → bessere **Testabdeckung**
|
||||
- Unterstützung bei der Erstellung **guter Testfälle**
|
||||
- Ziel: Fehler früh entdecken & reproduzierbar testen
|
||||
|
||||
---
|
||||
|
||||
## 🧪 HAUPTKATEGORIEN VON TESTVERFAHREN
|
||||
|
||||
|Kategorie|Merkmale & Grundlage|
|
||||
|---|---|
|
||||
|**Black-Box**|Anforderungen / Spezifikation|
|
||||
|**White-Box**|Programmstruktur / Code|
|
||||
|**Erfahrungsbasiert**|Intuition, frühere Fehler, Exploratives Testen|
|
||||
|
||||
---
|
||||
|
||||
### 🔲 1. BLACK-BOX-VERFAHREN (💡 Prüfungsrelevant)
|
||||
|
||||
Nutzen **Eingabe-Ausgabe-Beziehung**, ohne Quellcode zu betrachten.
|
||||
|
||||
#### a) Äquivalenzklassenbildung
|
||||
|
||||
- Eingaben in gültige/ungültige **Klassen** einteilen
|
||||
- **Aus jeder Klasse → 1 Testfall**
|
||||
|
||||
#### b) Grenzwertanalyse
|
||||
|
||||
- Grenzwerte sind **fehleranfällig**
|
||||
- Testfälle **am Rand** der Äquivalenzklassen
|
||||
|
||||
#### c) Entscheidungstabellen
|
||||
|
||||
- Repräsentieren **Regeln & Bedingungen**
|
||||
- Kombinationen aus Bedingungen → Aktionen
|
||||
|
||||
#### d) Zustandsbasierter Test
|
||||
|
||||
- Bei **zustandsbehafteten Systemen** (z. B. Automaten)
|
||||
- Zustände, Übergänge, Events → modellieren & testen
|
||||
|
||||
#### e) Use Case Test
|
||||
|
||||
- **Szenarien aus Benutzersicht** abdecken
|
||||
- Ziel: reale Nutzungspfade testen
|
||||
|
||||
---
|
||||
|
||||
### 🔳 2. WHITE-BOX-VERFAHREN
|
||||
|
||||
Berücksichtigen **interne Struktur** des Systems/Programms
|
||||
|
||||
#### a) Anweisungsüberdeckung
|
||||
- Jede Anweisung im Code muss mindestens **einmal ausgeführt** werden
|
||||
|
||||
#### b) Zweigüberdeckung
|
||||
|
||||
- Jeder Entscheidungspunkt (z. B. `if`, `else`) → **jede Richtung** wird getestet
|
||||
|
||||
➡️ Für Entwicklernahe Tests (z. B. Komponententest)
|
||||
|
||||
---
|
||||
|
||||
### 💡 3. ERFAHRUNGSBASIERTE VERFAHREN
|
||||
|
||||
- Beruhen auf **Intuition, Erfahrung, Bauchgefühl**
|
||||
- Beispiele:
|
||||
- **Fehlerbasiertes Testen**
|
||||
- **Checklisten**
|
||||
- **Exploratives Testen**
|
||||
|
||||
Einsatz besonders:
|
||||
|
||||
- wenn wenig Dokumentation vorhanden ist
|
||||
- bei Timeboxing (agile Projekte)
|
||||
- als Ergänzung zu strukturierten Verfahren
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Black-Box|Tests basieren auf **Spezifikationen**, nicht auf Code|
|
||||
|White-Box|Ziel: **Codepfade** und **Verzweigungen** abdecken|
|
||||
|Äquivalenzklassen|Jede Klasse mit **einem repräsentativen Testfall**|
|
||||
|Grenzwertanalyse|Fehler liegen oft **an den Rändern**|
|
||||
|Entscheidungs- & Zustandsbasierte Tests|gut bei komplexem Verhalten & Bedingungen|
|
||||
|Erfahrungsbasiert|Ergänzend, flexibel, intuitiv, explorativ|
|
||||
@@ -1,128 +0,0 @@
|
||||
## 📘 KAPITEL 4.2: BLACK-BOX-TESTVERFAHREN (DETAIL)
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Ziel
|
||||
|
||||
- Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
|
||||
- Fokus: **funktionales Verhalten** (ohne Quellcode)
|
||||
|
||||
---
|
||||
|
||||
## 1. ✅ ÄQUIVALENZKLASSEN-BILDUNG
|
||||
|
||||
### Ziel:
|
||||
|
||||
- Eingaberaum in **repräsentative Klassen** aufteilen (gültig + ungültig)
|
||||
|
||||
### Vorgehen:
|
||||
|
||||
1. Klassen identifizieren (z. B. Wertebereiche)
|
||||
2. Gültige & ungültige Klassen bilden
|
||||
3. Pro Klasse → 1 Repräsentant
|
||||
|
||||
**Beispiel: Eingabe 1–10**
|
||||
- Gültig: 1–10 → z. B. Testwert 5
|
||||
- Ungültig: <1, >10 → z. B. Testwert 0 und 11
|
||||
|
||||
---
|
||||
|
||||
## 2. ⚠️ GRENZWERTANALYSE
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Fehler an Grenzen** von Wertebereichen erkennen
|
||||
|
||||
### Vorgehen:
|
||||
|
||||
- Testfälle an & um die Grenze: `Grenze - 1`, `Grenze`, `Grenze + 1`
|
||||
|
||||
**Beispiel: Bereich 1–10**
|
||||
|
||||
- Testfälle: 0, 1, 2 | 9, 10, 11
|
||||
|
||||
➡️ Ergänzt Äquivalenzklassen
|
||||
|
||||
---
|
||||
|
||||
## 3. 🧾 ENTSCHEIDUNGSTABELLEN
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Regelbasierte Entscheidungen** systematisch testen
|
||||
|
||||
### Bestandteile:
|
||||
|
||||
- Bedingungen (z. B. "Kunde zahlt bar?")
|
||||
- Aktionen (z. B. "Rabatt gewähren")
|
||||
- Tabelle listet alle möglichen **Kombinationen**
|
||||
|
||||
### Vorteile:
|
||||
|
||||
- Gute Testabdeckung bei **Kombinatorik**
|
||||
- Auch für Geschäftsregeln & Konfigurationen geeignet
|
||||
|
||||
---
|
||||
|
||||
## 4. 🔄 ZUSTANDSÜBERGANGSTEST
|
||||
|
||||
### Ziel:
|
||||
|
||||
- Testen von Systemen mit **internen Zuständen**
|
||||
|
||||
### Elemente:
|
||||
|
||||
- **Zustände** (z. B. „angemeldet“, „abgemeldet“)
|
||||
- **Ereignisse/Übergänge** (z. B. „Login“, „Logout“)
|
||||
- **Aktionen** (z. B. „Zugriff erlaubt“)
|
||||
|
||||
### Arten von Tests:
|
||||
|
||||
- Alle Übergänge
|
||||
- Alle Zustände
|
||||
- Ungültige Übergänge
|
||||
|
||||
➡️ Modellierung über **Zustandsdiagramme** sinnvoll
|
||||
|
||||
---
|
||||
|
||||
## 5. 👤 USE CASE TEST
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Benutzerverhalten / Interaktionen** mit dem System testen
|
||||
|
||||
### Merkmale:
|
||||
|
||||
- Abbildung typischer **Szenarien**
|
||||
- Fokus auf **End-to-End-Abläufe**
|
||||
- Kann auch **nicht-funktionale Aspekte** einbeziehen
|
||||
|
||||
### Beispiele:
|
||||
|
||||
- "Benutzer meldet sich an"
|
||||
- "Benutzer gibt Bestellung auf"
|
||||
|
||||
---
|
||||
|
||||
## ✅ ZUSAMMENFASSUNG DER BLACK-BOX-VERFAHREN
|
||||
|
||||
|Verfahren|Fokus|Typische Anwendung|
|
||||
|---|---|---|
|
||||
|Äquivalenzklassen|Eingaberaum abdecken|Wertebereiche, Formate|
|
||||
|Grenzwertanalyse|Fehler an Bereichsgrenzen|Zahlen, Datumswerte|
|
||||
|Entscheidungstabellen|Regeln & Kombinationen prüfen|Rabattlogik, Konditionen|
|
||||
|Zustandsübergänge|Zustandssysteme abbilden|Automaten, Sitzungen|
|
||||
|Use Cases|Nutzerverhalten simulieren|Geschäftsprozesse, UI|
|
||||
|
||||
---
|
||||
|
||||
## 📝 KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Äquivalenzklassen|Pro Klasse genau **ein Testfall**|
|
||||
|Grenzwertanalyse|Teste **an, vor und nach** der Grenze|
|
||||
|Entscheidungstabellen|**Alle Regelkombinationen** prüfen|
|
||||
|Zustandsbasierte Tests|Übergänge & Reaktionen prüfen, auch **ungültige**|
|
||||
|Use Case Tests|Nutzer-Szenarien, oft End-to-End|
|
||||
@@ -1,104 +0,0 @@
|
||||
## 📘 KAPITEL 5: TESTMANAGEMENT
|
||||
|
||||
---
|
||||
|
||||
### 5.1 Testorganisation
|
||||
|
||||
* Testverantwortung kann in **Entwicklung integriert** oder **getrennt organisiert** sein.
|
||||
* Rollen können je nach Projektform variieren:
|
||||
|
||||
* **Testmanager**
|
||||
* **Tester**
|
||||
* **Testanalyst / Technical Test Analyst**
|
||||
* **Testautomatisierer**
|
||||
|
||||
---
|
||||
|
||||
### 5.2 Testplanung und -steuerung
|
||||
|
||||
#### Testplanung
|
||||
|
||||
* Definition von:
|
||||
|
||||
* **Zielen**
|
||||
* **Strategie**
|
||||
* **Umfang**
|
||||
* **Aufwand & Ressourcen**
|
||||
* **Zeitplan**
|
||||
|
||||
#### Teststeuerung
|
||||
|
||||
* **Vergleich** von Ist- und Sollwerten
|
||||
* **Anpassung** des Testvorgehens bei Abweichungen
|
||||
|
||||
---
|
||||
|
||||
### 5.3 Testfortschritt und -abschluss
|
||||
|
||||
#### Testfortschrittskennzahlen (Metriken)
|
||||
|
||||
* Anzahl durchgeführter Tests
|
||||
* Anzahl gefundener Fehler
|
||||
* Testabdeckung
|
||||
* Aufwand vs. Fortschritt
|
||||
|
||||
#### Abschlussaktivitäten:
|
||||
|
||||
* Fehlerstatus prüfen
|
||||
* Lessons Learned
|
||||
* Testabschlussbericht erstellen
|
||||
|
||||
---
|
||||
|
||||
### 5.4 Konfigurationsmanagement
|
||||
|
||||
* Sicherstellen, dass:
|
||||
|
||||
* **Testobjekte eindeutig versioniert** sind
|
||||
* **Änderungen nachvollziehbar** bleiben
|
||||
* Tools zur Verwaltung von:
|
||||
|
||||
* Anforderungen
|
||||
* Testfällen
|
||||
* Codeversionen
|
||||
|
||||
---
|
||||
|
||||
### 5.5 Risikomanagement im Test
|
||||
|
||||
| Begriff | Bedeutung |
|
||||
| ------------------------ | ------------------------------------------------------------------ |
|
||||
| **Risiko** | Möglichkeit eines negativen Ereignisses |
|
||||
| **Risikobasierter Test** | Priorisierung nach Schadenspotenzial & Eintrittswahrscheinlichkeit |
|
||||
|
||||
#### Risikoarten:
|
||||
|
||||
* **Produktrisiko**: betrifft Software (z. B. Datenverlust)
|
||||
* **Projektrisiko**: betrifft Projekt (z. B. Terminüberschreitung)
|
||||
|
||||
---
|
||||
|
||||
### 5.6 Fehler- und Abweichungsmanagement
|
||||
|
||||
* **Fehlermanagementprozess**:
|
||||
|
||||
1. Fehler identifizieren
|
||||
2. Fehler dokumentieren (z. B. Reproduktionsschritte)
|
||||
3. Status verfolgen (neu, in Bearbeitung, gelöst …)
|
||||
4. Abschluss prüfen
|
||||
|
||||
* Abweichung ≠ immer Fehler (z. B. unvollständige Anforderungen)
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
| Thema | Merksatz |
|
||||
| ------------------------ | ------------------------------------------------------ |
|
||||
| Testplanung | Definiert **Was, Wie, Wer, Wann** |
|
||||
| Teststeuerung | Vergleicht **Planung ↔ Realität**, passt an |
|
||||
| Fortschrittsmetriken | Basis für **objektive Steuerung** |
|
||||
| Konfigurationsmanagement | Kontrolliert Versionen & Änderungen |
|
||||
| Risikobasiertes Testen | Priorisiert **nach Schadenshöhe & Wahrscheinlichkeit** |
|
||||
| Fehlermanagement | Fehler dokumentieren & nachverfolgen bis Abschluss |
|
||||
|
||||
@@ -1,99 +0,0 @@
|
||||
## 📘 KAPITEL 6: TOOLUNTERSTÜTZUNG IM TESTPROZESS
|
||||
|
||||
---
|
||||
|
||||
### 6.1 Einsatzmöglichkeiten von Testwerkzeugen
|
||||
|
||||
#### Ziele:
|
||||
|
||||
- Effizienz steigern
|
||||
- Wiederholbarkeit sicherstellen
|
||||
- Fehler vermeiden
|
||||
|
||||
#### Typische Tool-Einsatzbereiche:
|
||||
|
||||
|Einsatzbereich|Beispiele für Werkzeuge|
|
||||
|---|---|
|
||||
|**Testmanagement**|Testplanung, Fortschrittsverfolgung|
|
||||
|**Anforderungsmanagement**|Rückverfolgbarkeit von Anforderungen|
|
||||
|**Statische Analyse**|Code-Analyse, Einhaltung von Codestandards|
|
||||
|**Testfallerstellung**|manuell oder generiert|
|
||||
|**Testdurchführung & Auswertung**|Automatisierte Tests, Logging, Reports|
|
||||
|**Defektmanagement**|Bug-Tracking, z. B. Jira, Bugzilla|
|
||||
|**Testdaten- & Umweltverwaltung**|Konsistente Testdaten, Containerisierung|
|
||||
|
||||
---
|
||||
|
||||
### 6.2 Vorteile und Risiken von Tools
|
||||
|
||||
#### ✅ Vorteile:
|
||||
|
||||
- Automatisierung → **Zeitersparnis**
|
||||
- **Konsistenz & Reproduzierbarkeit**
|
||||
- **Skalierbarkeit** bei Regressionstests
|
||||
|
||||
#### ⚠️ Risiken:
|
||||
|
||||
- **Einführungsaufwand** hoch
|
||||
- **Wartung & Pflege** der Tools notwendig
|
||||
- Gefahr von **Tool-Gläubigkeit** („Tool löst alle Probleme“)
|
||||
- **Falsche Anwendung** kann schaden
|
||||
|
||||
---
|
||||
|
||||
### 6.3 Toolklassifizierung nach ISTQB
|
||||
|
||||
|Tooltyp|Beschreibung|
|
||||
|---|---|
|
||||
|**Statische Analyse-Tools**|z. B. Lint, SonarQube|
|
||||
|**Testdesign-Tools**|z. B. Testdaten-Generatoren|
|
||||
|**Testautomatisierung**|z. B. Selenium, JUnit|
|
||||
|**Defektmanagement-Tools**|z. B. Bugzilla, Jira|
|
||||
|**Performance-Testtools**|z. B. JMeter|
|
||||
|**Coverage-Tools**|z. B. Jacoco|
|
||||
|
||||
---
|
||||
|
||||
### 6.4 Auswahl & Einführung von Tools
|
||||
|
||||
#### Auswahlkriterien:
|
||||
|
||||
- Projekt- & Teamgröße
|
||||
- Integration in bestehende Infrastruktur
|
||||
- Schulungsbedarf
|
||||
- Support & Lizenzmodell
|
||||
|
||||
#### Einführungsprozess:
|
||||
|
||||
1. **Bedarf klären**
|
||||
2. **Tool evaluieren & auswählen**
|
||||
3. **Pilotphase**
|
||||
4. **Rollout**
|
||||
5. **Wartung & kontinuierliche Verbesserung**
|
||||
|
||||
---
|
||||
|
||||
### 6.5 Automatisierung sinnvoll einsetzen
|
||||
|
||||
#### Typische Einsatzszenarien:
|
||||
|
||||
- **Regressionstests**
|
||||
- **Build-Verifikation (CI/CD)**
|
||||
- **Performance-Messung**
|
||||
- **Datengetriebenes Testen**
|
||||
|
||||
➡️ **Automatisierung ≠ universell sinnvoll**
|
||||
|
||||
- Bei **explorativem Testen**, UX-Tests oder stark ändernden UIs → lieber manuell
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Toolnutzen|**Effizienz & Konsistenz**, aber kein Allheilmittel|
|
||||
|Risiken|**Falsche Erwartungen**, hoher Einführungsaufwand|
|
||||
|Toolauswahl|Nach **Projektkontext & Integration** wählen|
|
||||
|Automatisierung|Gut für **wiederholbare, stabile Tests**|
|
||||
|Defektmanagement|Erlaubt **systematische Fehlerverfolgung**|
|
||||
Reference in New Issue
Block a user