diff --git a/Writerside/images/image_793.png b/Writerside/images/image_793.png new file mode 100644 index 0000000..91ef38f Binary files /dev/null and b/Writerside/images/image_793.png differ diff --git a/Writerside/images/image_794.png b/Writerside/images/image_794.png new file mode 100644 index 0000000..03edf16 Binary files /dev/null and b/Writerside/images/image_794.png differ diff --git a/Writerside/images/image_795.png b/Writerside/images/image_795.png new file mode 100644 index 0000000..63d68e9 Binary files /dev/null and b/Writerside/images/image_795.png differ diff --git a/Writerside/images/image_796.png b/Writerside/images/image_796.png new file mode 100644 index 0000000..b3e533c Binary files /dev/null and b/Writerside/images/image_796.png differ diff --git a/Writerside/images/image_797.png b/Writerside/images/image_797.png new file mode 100644 index 0000000..c90f82d Binary files /dev/null and b/Writerside/images/image_797.png differ diff --git a/Writerside/images/image_798.png b/Writerside/images/image_798.png new file mode 100644 index 0000000..aee5ad2 Binary files /dev/null and b/Writerside/images/image_798.png differ diff --git a/Writerside/images/image_799.png b/Writerside/images/image_799.png new file mode 100644 index 0000000..903f01c Binary files /dev/null and b/Writerside/images/image_799.png differ diff --git a/Writerside/in.tree b/Writerside/in.tree index a7a32cf..b453aa0 100644 --- a/Writerside/in.tree +++ b/Writerside/in.tree @@ -109,7 +109,7 @@ - + diff --git a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md b/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md index 260e31f..33eed5a 100644 --- a/Writerside/topics/04/Software Engineering/01_ImplementingForMaintainability.md +++ b/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 -![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 - +## [](02_TestingForContinuousQuality.md) ## Goals of Testing during Implementation diff --git a/Writerside/topics/04/Software Engineering/02_TestingForContinuousQuality.md b/Writerside/topics/04/Software Engineering/02_TestingForContinuousQuality.md new file mode 100644 index 0000000..69b6eff --- /dev/null +++ b/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!** \ No newline at end of file diff --git a/Writerside/topics/04/Theoretische Informatik/Hausaufgaben/ti_hausufgabe3.md b/Writerside/topics/04/Theoretische Informatik/Hausaufgaben/ti_hausufgabe3.md index a5d94fb..549aca6 100644 --- a/Writerside/topics/04/Theoretische Informatik/Hausaufgaben/ti_hausufgabe3.md +++ b/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