update

Writerside/in.tree

@@ -109,7 +109,7 @@
         <toc-element toc-title="Software Engineering">
             <toc-element topic="00_Introduction.md"/>
             <toc-element topic="01_ImplementingForMaintainability.md"/>
-            <toc-element topic="99_Praktikum1Vorbereitung.md"/>
+            <toc-element topic="02_TestingForContinuousQuality.md"/>
         </toc-element>
         <toc-element toc-title="Theoretische Informatik">
             <toc-element toc-title="Übungen">

Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md

@@ -35,21 +35,7 @@
 > Black-/White-Box-Testing sind Konzepte, die auf verschiedene Test-Typen angewendet werden können
 
 
-## Testing Quadrants Matrix
+## [](02_TestingForContinuousQuality.md)
-![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
-
 
 
 ## Goals of Testing during Implementation

Writerside/topics/04/Software 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!**

Writerside/topics/04/Theoretische Informatik/Hausaufgaben/ti_hausufgabe3.md

@@ -1,9 +1,11 @@
 # Übungsblatt 3
+> Wenzel Schwan (1125033), Paul Kneidl (1125219), David Schirrmeister (1125746), Michelle Klein (1126422)
+
 ## Übung 1
 Betrachten Sie den nichtdeterministischen Automaten $N$ aus Abbildung 1 über dem
 Alphabet $Σ = \{ 0, 1 \}^*$.
 
-![image_784.png](image_784.png)
+![Abbildung 1](image_784.png)
 Automat $N$ für Worte aus $\{ 0, 1 \}^*$, deren drittletztes Zeichen eine `0` ist.
 
 ### 1(a)
@@ -49,7 +51,7 @@ haben.
 
 ```plantuml
 @startuml
-scale 0.75
+scale 0.3
 
 top to bottom direction
 skinparam dpi 150
@@ -189,7 +191,7 @@ Betrachten Sie den nichtdeterministischen Automaten N aus Abbildung 2 über dem
 Alphabet $Σ = \{ x, y, z \}^*$. Weiterhin seien die Zeichenketten $s_1 = zzx$, $s_2 = xxyz$,
 $s_3 = yyy$, $s_4 = xxz$ und $s_5 = xxzxxzxxzxxz$ definiert.
 
-![image_792.png](image_792.png)
+![Abbildung 2](image_792.png)
 
 ### 2(a)
 Geben Sie für jedes $s_i (i ∈ \{ 1, 2, . . . , 5 \})$ an, ob es eine Berechnung (Bearbeitungspfad) für den Automaten N gibt, welche die Zeichenkette si vollständig liest (also
@@ -310,7 +312,7 @@ geben Sie ein Beispiel für das die Konstruktion scheitert.
 
 ## Übung 4
 Betrachten Sie die beiden deterministischen endlichen Automaten $A_1$ und $A_2$ aus Abbildung 3
-![image_786.png](image_786.png)
+![Abbildung 3](image_786.png)
 
 ### 4(a)
 Beschreiben Sie den Aufbau von Worten $w$ aus der Sprache $L(A_1) ∪ L(A_2)$ (formal