vault backup: 2025-07-03 16:57:46
This commit is contained in:
fzzinchemical
@@ -1,11 +1,8 @@
|
||||
## 🎯 ZIELE DER LEHRVERANSTALTUNG
|
||||
|
||||
- Vermittlung von **Grundlagen im Softwaretesten**
|
||||
|
||||
- Verständnis für **Begriffe, Aufgaben, Methoden & Verfahren**
|
||||
|
||||
- Vorbereitung auf die **CTFL-Prüfung** (international anerkannt)
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -14,42 +11,30 @@
|
||||
### 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!**
|
||||
|
||||
@@ -60,22 +45,15 @@
|
||||
### 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**
|
||||
|
||||
@@ -86,7 +64,6 @@
|
||||
**Automobilindustrie**:
|
||||
|
||||
- Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
|
||||
|
||||
|
||||
➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
|
||||
|
||||
@@ -95,24 +72,17 @@
|
||||
## 💬 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_
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -5,30 +5,20 @@
|
||||
### 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -46,9 +36,7 @@
|
||||
### 1.4 Testen und Debuggen
|
||||
|
||||
- **Testen**: Fehler _finden_
|
||||
|
||||
- **Debuggen**: Fehler _analysieren und beheben_
|
||||
|
||||
|
||||
➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
|
||||
|
||||
@@ -57,32 +45,21 @@
|
||||
### 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**
|
||||
|
||||
@@ -91,16 +68,12 @@
|
||||
### 1.7 Psychologie des Testens
|
||||
|
||||
- Zielkonflikt Entwickler vs. Tester:
|
||||
|
||||
- Entwickler: „Software funktioniert!“
|
||||
|
||||
- Tester: „Software hat Schwächen!“
|
||||
|
||||
- Tester: „Software hat Schwächen!“
|
||||
|
||||
🧠 Gute Zusammenarbeit & Kommunikation sind entscheidend:
|
||||
|
||||
- **Objektivität, Kritikfähigkeit, keine Schuldzuweisungen**
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -9,18 +9,13 @@
|
||||
#### 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -42,52 +37,38 @@
|
||||
#### 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.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -5,16 +5,12 @@
|
||||
### 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -32,22 +28,15 @@
|
||||
#### 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!**
|
||||
|
||||
@@ -81,15 +70,10 @@
|
||||
### 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)
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -5,11 +5,8 @@
|
||||
### 4.1 Einleitung: Warum Testverfahren?
|
||||
|
||||
- Systematisches Vorgehen → bessere **Testabdeckung**
|
||||
|
||||
- Unterstützung bei der Erstellung **guter Testfälle**
|
||||
|
||||
- Ziel: Fehler früh entdecken & reproduzierbar testen
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -30,37 +27,27 @@ 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -69,14 +56,11 @@ Nutzen **Eingabe-Ausgabe-Beziehung**, ohne Quellcode zu betrachten.
|
||||
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)
|
||||
|
||||
@@ -85,24 +69,16 @@ Berücksichtigen **interne Struktur** des Systems/Programms
|
||||
### 💡 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -5,9 +5,7 @@
|
||||
### 🎯 Ziel
|
||||
|
||||
- Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
|
||||
|
||||
- Fokus: **funktionales Verhalten** (ohne Quellcode)
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -16,23 +14,16 @@
|
||||
### 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
|
||||
|
||||
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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -41,17 +32,14 @@
|
||||
### 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
|
||||
|
||||
@@ -62,23 +50,17 @@
|
||||
### 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -87,25 +69,18 @@
|
||||
### 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
|
||||
|
||||
@@ -116,23 +91,17 @@
|
||||
### 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"
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -6,12 +6,9 @@
|
||||
|
||||
#### Ziele:
|
||||
|
||||
- Effizienz steigern
|
||||
|
||||
- Effizienz steigern
|
||||
- Wiederholbarkeit sicherstellen
|
||||
|
||||
- Fehler vermeiden
|
||||
|
||||
|
||||
#### Typische Tool-Einsatzbereiche:
|
||||
|
||||
@@ -32,22 +29,15 @@
|
||||
#### ✅ 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -69,26 +59,17 @@
|
||||
#### 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**
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -97,18 +78,13 @@
|
||||
#### 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -8,4 +8,6 @@
|
||||
- [ ] Kap 5
|
||||
- [ ] Kap 6
|
||||
|
||||
## Bearbeitung der Aufgaben
|
||||
## Bearbeitung der Aufgaben
|
||||
|
||||
## Zusammensuchen von Klausuren und Tests
|
||||
23
Semester 6/SWTEST/Liste Exams.md
Normal file
23
Semester 6/SWTEST/Liste Exams.md
Normal file
@@ -0,0 +1,23 @@
|
||||
## 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
|
||||
Reference in New Issue
Block a user