update

2025-05-05 15:31:24 +02:00
parent 8fffe1762e
commit b87fab26d6
11 changed files with 190 additions and 20 deletions
--- a/Engineering/02_TestingForContinuousQuality.md
+++ b/Engineering/02_TestingForContinuousQuality.md
@ -0,0 +1,182 @@
+# Testing for continuous Quality
+![image_556.png](image_556.png)
+
+## Quadrant 1: Technologie-fokussierte Tests, die das Development leiten
+- Developer Tests:
+    - Unit tests
+        - Verifizieren Funktionalität eines kleinen Subsets des Systems
+        - Unit Tests sind die essenzielle Basis einer guten Test-Suite
+            - Verglichen mit anderen, sind sie einfach zu erstellen und warten
+            - Viele Unit-Tests :)
+    - Component-/Integration Tests:
+        - Verifizieren Verhalten eines größeren Teils
+- Tests sind nicht für den Kunden
+- [**Implementierung**](01_ImplementingForMaintainability.md)
+
+## Quadrant 2: Business-fokussierte Tests, die das Development leiten
+- definiert Qualität/Features, die der Kunde möchte
+- Funktionale Tests, die von [User-Storys](RequirementsAnalysis.md#user-stories) abgeleitet werden
+    - bspw. _GUI-Tests, Integration-Tests_
+    - (_Mock-Up-Tests, Simulationen_) → wird nicht behandelt
+        - GUI-Designs mit User validieren, nicht automatisiert
+- Sollten zum Großteil automatisiert als Teil der CI/CD-Pipeline laufen
+  - am besten auf Production-Code
+- **Implementierung**
+  - Direkte Kommunikation zwischen Kunden/Developer
+  - TDD umsetzen
+    - Erst simplen Happy-Path-Test implementieren
+    - Dann Code
+    - Dann mehr Tests
+    - mehr Code
+  - Sobald ein Test ein erstes Mal erfolgreich ist, sollte er nicht mehr fehlschlagen
+    - Es sei denn: Anforderungen haben sich geändert
+
+### Q2: Service Testing
+- Production Code durch externe Schnittstellen testen
+  - bspw: _Extern sichtbare Interfaces(Klassen/Funktionen, aufgebaut nach Facade Pattern), API, Event-Gesteuerte Interfaces (Kafka, MQTT)_
+- Vorteile:
+  - weniger fragil als UI-Tests
+  - sehr günstig zu warten
+- Tests bieten eine "lebende Dokumentation", wie das System sich verhält
+
+#### Implementierung Service Tests
+- API-level Test-Frameworks unterstützen
+  - ![image_794.png](image_794.png)
+    - Test-Framework
+      - unterstützt restliche Teile bei Test-Definition und -Ausführung
+    - SystemUnderTest
+      - Zeigt auf die Komponente, die durch das Interface gezeigt wird
+    - Tests/Beispiele
+      - Test-Szenarien, technologie-unabhängig
+    - Test-Methode
+
+#### Beispiel Service Testing
+![image_793.png](image_793.png)
+- Tests adressieren Endpunkte der drei Komponenten
+- sollten alle automatisch ausgeführt werden
+
+- ![image_795.png](image_795.png)
+  - 2 Tests: 
+    - happy-path
+    - invalid username
+  - Input wird der Test-Methode `TestLogin` gegeben
+  - Dann weiter als Variable in den Production-Code
+  - Erwartetes Ergebnis wird mit dem tatsächlichen Ergebnis verglichen
+  - _Wie Daten hin und zurück kommen, müssen Tester und Coder besprechen_
+
+### Q2: User Interface Testing
+- Production-Code durch UI testen
+- Simulieren Nutzer-Verhalten
+  - ist dennoch möglich zu automatisieren
+
+#### Beispiel UI-Testing (mit Selenium)
+- Selenium ist ein Framework für automatisierte UI-Tests
+  - ![image_796.png](image_796.png)
+  - ![image_797.png](image_797.png)
+- Tests sind sehr fragil
+  - Vor allem, die Teile, bei denen Elemente auf der Webseite ausgewählt werden
+  
+
+## Quadrant 3: Business-fokussierte Tests, die das Projekt kritisieren/evaluieren
+- manchmal sind Anforderungen nicht gut genug, um gewünschtes Produkt zu designen
+    - Tests evaluieren, ob Software Erwartungen genügt
+        - Emulation von User-Interaktionen
+- Manuelles Testen, das nur ein Mensch ausführen kann
+- Typen:
+  - User Acceptance Testing (UAT)
+    - neue Features austesten lassen
+  - Usability Testing
+    - Fokus-Gruppen werden studiert und interviewt, während sie die Anwendung nutzen
+    - Wissen, wie die Nutzer Systeme nutzen, ist ein Vorteil, wenn man die Nutzbarkeit testet
+  - Exploratory testing
+    - Tester denken sich selbst neue Tests aus, die sie dann auch durchführen
+      - benötigt viel Kreativität und Intuition
+    - wird von einer Strategie geleitet und durch Guidelines eingegrenzt
+    
+
+## Quadrant 4: Technologie-fokussierte Tests, die das Projekt kritisieren/evaluieren
+- Tests, die Charakteristiken wie Performance, Robustheit, Sicherheit sicherstellen
+- Sollten in jedem Schritt des SDLC beachtet werden
+
+### Q4: Security Testing
+- Technologie fokussierte Tests von einem wichtigen, [nicht-funktionalen Aspekt](IntroductionOOAD.md#requirements-in-software-engineering)
+- Sicherheits-Bugs sind sehr kostenintensiv, wenn sie erst spät im SDLC gefunden werden
+- Security-Testing: Denken wie ein Hacker
+
+#### Tools und Techniken für Security Testing in verschiedenen Stages
+- Static Application Security Testing (SAST)
+  - _bspw. nicht-verschlüsselte Passwörter_ darstellen
+- Software Composition Analysis (SCA)
+  - Identifiziert Schwachstellen in 3rd-Party-Abhängigkeiten
+  - kann in CI/CD integriert werden
+- Image Scanning
+  - Scannt Container-Images
+  - kann in CI/CD integriert werden
+- Dynamic Application Security Testing (DAST)
+  - Analysiert, wie die Anwendung auf spezifisch angepasste Anfragen reagiert
+  - kann in CI/CD integriert werden
+    - brauchen teilweise länger in der Ausführung
+- Manual exploratory testing
+- Penetration (pen) -Testing
+  - beinhaltet einen professionellen Security-Tester
+  - sollte nah am Ende des Auslieferungs-Kreislaufs geschehen
+- Runtime Application Self Protection (RASP)
+  - Anwendung durchgängig auf mögliche Attacken beobachten und diese verhindern
+  - _bspw. durch automatische Beendung von Prozessen_
+
+### Q4: Performance Testing
+- **Performance** kann anhand **verschiedener Faktoren gemessen** werden
+  - Antwort-Zeit
+    - _WebApplikationen bspw. sollten max. 3 Sekunden für eine Antwort brauchen_
+  - Durchsatz/Parallelität
+    - Anzahl an Anfragen, die innerhalb einer Zeitspanne unterstützt werden können
+  - Verfügbarkeit
+- **Faktoren, die Performance beeinflussen**:
+  - Architektur-Design
+    - bspw. _Caching-Mechanismen_
+  - Wahl des Tech-Stacks
+    - Technologien sind unterschiedlich schnell
+  - Code-Komplexität
+  - Datenbank-Wahl und -Design
+  - Netzwerk-Latenz
+    - Alle Komponenten kommunizieren darüber
+    - Falls schlechtes Netz → langsame Anwendung
+  - Physischer Ort der Nutzer
+    - Distanz spielt eine Rolle
+  - Infrastruktur
+    - CPU, RAM, etc. 
+  - 3rd Party Integrationen
+    - Sind meistens außerhalb der Kontrolle
+    - Sollten auch anhand von Performance-Werten ausgewählt werden
+
+#### Typen von Performance Tests
+- Load/Volume Tests
+  - Verifizieren, dass das System den benötigten Durchsatz liefert
+  - werden meist mehrfach durchgeführt → Durchschnitt
+- Stress Tests
+  - Womit kommt die Anwendung noch klar?
+    - bspw. viele User
+  - Exakte Messungen werden benötigt, um die Infrastruktur anhand der Ergebnisse zu planen
+- Soak Tests
+  - Wird die Performance über Zeit schlechter?
+  - Hält die Anwendung durchgängig unter einem konstanten Workload
+
+
+## Testing Automation Pyramide
+![image_798.png](image_798.png)
+![image_799.png](image_799.png)
+
+- Unit Tests
+  - Verifizierung von einem kleinen Subset des Systems
+- Integration Tests
+  - Testen einer Gruppe von Klassen
+- Contract Tests
+  - API-Tests für Module, die gerade entwickelt werden
+- Service Tests
+  - API-Tests, die individuelle Module testen
+- UI-Tests
+  - Simulieren Nutzer-Verhalten für bestimmte Features
+- End-to-end-Tests
+  - Simulieren Nutzer-Verhalten für eine komplette Interaktion (inkl. externe Systeme)
+
+**Achtung: Nicht-Funktionale Tests werden hier nicht beachtet!**