vault backup: 2025-02-21 16:16:30

This commit is contained in:
2025-02-21 16:16:30 +01:00
parent 046c96d814
commit 39e5a669db
5 changed files with 323 additions and 12 deletions

View File

@@ -6017,6 +6017,12 @@ Prüfungen
Paketierung
Praktiken
Problemmeldungen
Pfade
Prozentsatz
Projektfortschritts
Programmierkenntnisse
Pfadüberdeckung
Path
obj
oV
oYj
@@ -17661,6 +17667,9 @@ Letzter
Life
Lockerung
Laufzeitumgebung
Lines
Logik
Logikfehler
Filter
FlateDecode
Ff
@@ -23681,6 +23690,12 @@ Freigabe
Fachlogik
FATAL
Frameworks
Funktionseinheit
Failure
Fehlerdichte
Funktionstests
Fehlerfindung
Flow
stream
se
sH
@@ -30028,6 +30043,11 @@ systematisch
sichtbarer
statischen
strenger
spiegeln
sobald
spezifizierten
selten
sicherstellen
ZKs
ZN
Zf
@@ -36139,6 +36159,11 @@ Zweigüberdeckung
Zweig
Zyklomatische
Zweige
Zusammenhalts
Zählen
Zustandsübergangstests
Zustandsautomat
Zufallstests
Who
We
WE
@@ -42502,6 +42527,8 @@ Wahrheitswerten
Weighted
Werkzeugen
WARN
Widerstand
Wählen
KI
Kt
KF
@@ -48906,6 +48933,10 @@ Konstanten
Korrektive
Kontrollausgaben
Kontrollflussgraphen
Kommunizieren
Kommunikationsmittel
Kategorien
Konsistenz
bq
bQ
bG
@@ -54967,6 +54998,11 @@ beseitigen
begünstigt
begrenzte
berechnende
bewerten
besser
basierend
besten
bleiben
iZ
ig
iA
@@ -61250,6 +61286,10 @@ iGXL
ieCBi
integrierten
implementiert
interpretiert
identifizieren
interne
ineffizienten
GJe
GAG
GJ
@@ -67256,6 +67296,7 @@ Grundeinstellungen
Grammatikprüfung
Gesamtzahl
Gemeinsame
Graph
AO
Aw
Az
@@ -73753,6 +73794,14 @@ Aktive
Arbeit
Ausgangszustands
Aufwands
Ausgabeoperanden
Ausfällen
Anwendungsbereiche
Anforderungsanalyse
Akzeptanz
Automatisieren
Analysieren
Abdeckung
QV
Qom
QJ
@@ -86114,6 +86163,7 @@ namen
natürlichsprachliche
normaler
neuer
niedrige
YJ
Yb
YwM
@@ -98960,6 +99010,8 @@ Uses
Unterklassen
Unterklasse
Unterteilung
Umfang
Unabhängigkeit
TZ
TF
TP
@@ -105243,6 +105295,11 @@ Teilbedingung
Testzugang
Testware
Teils
Testabdeckung
Trends
Teilen
Tester
Testfallerstellung
gO
gHoVo
gD
@@ -111263,6 +111320,9 @@ groupId
getestet
generische
geplant
garantiert
gewünschtes
genutzten
DMg
Dv
DLg
@@ -117243,6 +117303,12 @@ Depth
Descandants
Datenflussanomalieanalyse
DEBUG
Detaillierte
Defect
Durchschnittliche
Datenflussfehler
Datenflussanalyse
Datenflusses
xU
xM
xK
@@ -128731,6 +128797,11 @@ Hierarchisierung
Hiding
Hauptfehler
Häufige
Höhere
Höheres
Höherer
Herausforderungen
Hoher
zo
zL
zE
@@ -134836,6 +134907,11 @@ zutreffend
zusätzlicher
zustandsverändernder
zusammengesetzt
zusammenhängender
zukünftige
zyklomatische
zufälligen
zeitaufwendig
hr
hAa
hH
@@ -140727,6 +140803,8 @@ hiDO
hUOD
hinzugenommen
hoffe
helfen
hindeuten
pt
ps
pao
@@ -146668,6 +146746,9 @@ predicate
prädikativen
parametrisierte
privater
prozessen
projekte
passen
Ic
IT
Ir
@@ -152764,6 +152845,8 @@ Interfaces
Inheritance
Integrationsprozesses
INFO
Interpretieren
Implementierung
ap
aE
at
@@ -158728,6 +158811,11 @@ atomaren
abstrakte
abstrakter
atomare
abgedeckt
ausschließlich
abdecken
angenommen
auflisten
fb
fVVvD
fh
@@ -164791,6 +164879,7 @@ finale
früh
formale
fehlerträchtigen
frühen
Bs
ByJ
BF
@@ -170485,6 +170574,11 @@ Berichten
Builds
Berichtswesen
Berichte
Betrachtung
Bewerten
Best
Benutzerperspektive
Branch
ek
eP
eVPm
@@ -176961,6 +177055,11 @@ entdecken
engineering
erneutes
else
ermöglichen
erzielen
empfinden
erreicht
entdeckte
tj
tg
tt
@@ -183239,6 +183338,8 @@ thwMz
tnPR
tOKfa
testenden
treffen
tiefes
JFRO
JG
JL
@@ -195528,6 +195629,10 @@ konstruktiven
konsistent
komplett
kompletten
komplexität
komplexeren
komplexere
kostspielig
EU
Evq
Er
@@ -201883,6 +201988,19 @@ Einfacher
Entnahme
Erleichterung
ERROR
Einblicke
Entwicklungen
Entscheidungen
Endbenutzers
Eingabekombinationen
Erfordert
Eingabewerte
Entscheidungstabellentests
Eingabebedingungen
Eingabewerten
Einblick
Effiziente
Entwicklerperspektive
lX
ll
lC
@@ -208085,6 +208203,7 @@ ljsp
laZZ
lokale
logischen
liefern
wG
wd
ws
@@ -214522,6 +214641,9 @@ woXz
wZeUHd
wwwwwwwww
wDph
warten
weiterhin
wider
RmZh
Rp
RJ
@@ -220668,6 +220790,8 @@ Reflection
Rechtschreib
Redefined
Relationssymbole
Ressourcennutzung
Redundanz
vJ
vS
vKDF
@@ -226905,6 +227029,11 @@ verschleißt
vieler
vertauschten
vollautomatischen
versionen
vorherzusagen
voreingenommen
verhalten
vollen
XE
Xd
XRb
@@ -251566,6 +251695,13 @@ Mehrfach
Minimale
Metrik
Mehr
Minimalvokabulars
Messungen
Managern
Messung
Modules
MTTF
Muster
qO
qj
qG
@@ -257651,6 +257787,7 @@ qRix
qtnyh
qevy
qnDo
quantifizieren
yB
yyNs
yQU
@@ -269952,6 +270089,10 @@ uBc
ukuZ
upZFL
unstimmige
untere
unabhängiger
unmöglich
unentdeckt
ma
ml
mB
@@ -282688,6 +282829,8 @@ definitionsfreien
definitionsfrei
definitionsfreier
dynamischen
deutet
deuten
VV
VA
Vsm
@@ -288984,6 +289127,13 @@ Vorbereitende
Versions
Viel
Verknüpfung
Verstehen
Vorhersagen
Vollständigkeit
Verfolgung
Verwenden
Verständnis
Vollständige
SGN
Sg
SrEHO
@@ -295357,6 +295507,16 @@ Schlüsselwörter
Softwaresystems
Systematisches
Sequenz
Schranke
Softwareprodukten
Softwareprodukte
Steuern
Softwareentwicklungsprozessen
Softwaresystem
Softwaredesigns
Schwierige
Strukturtests
Statement
rn
rE
rD
@@ -301711,6 +301871,9 @@ rTwL
repräsentativ
redundanzarm
repräsentiert
ressourcen
relevante
redundante
Cu
CL
Ch
@@ -307303,6 +307466,16 @@ Codierungsrichtlinien
Checkstyle
CodePro
Codebasis
Codezeilen
Classes
Coupling
Cohesion
Codezeile
Coverage
Codierung
Codequalität
Cases
Codeoptimierung
OM
OWR
Os
@@ -313408,6 +313581,7 @@ Oberklasse
Operatoren
Operanden
Objektorientierte
Objektivität
cgl
cj
content
@@ -320042,6 +320216,7 @@ computational
Äquivalenzklassen
Änderungs
Änderungsanträgen
Änderungsfreundlichkeit
äz
äh
äe
@@ -320270,6 +320445,7 @@ computational
üSa
üYB
überprüfbar
überschneiden
ßc
ßI
ßVq

View File

@@ -29,14 +29,12 @@
"id": "dc1bf961d97f0cb4",
"type": "leaf",
"state": {
"type": "markdown",
"type": "pdf",
"state": {
"file": "WS2425/SWT D/Notes.md",
"mode": "source",
"source": false
"file": "WS2425/SWT D/Praktikum/swtd-p-03.pdf"
},
"icon": "lucide-file",
"title": "Notes"
"icon": "lucide-file-text",
"title": "swtd-p-03"
}
}
]
@@ -252,18 +250,18 @@
"obsidian-livesync:Show log": false
}
},
"active": "dc1bf961d97f0cb4",
"active": "b8336cb3c3d06be9",
"lastOpenFiles": [
"Pasted image 20250221131512.png",
"WS2425/SWT D/Vorlesung/swtd_merged.pdf",
"Persistierung.ts.md",
"WS2425/SWT D/Notes.md",
"WS2425/SWT D/Praktikum/swtd-p-03.pdf",
"WS2425/SWT D/Vorlesung/swtd_merged.pdf",
"Pasted image 20250221131512.png",
"Persistierung.ts.md",
"WS2425/SWT D/Praktikum/swtd-p-08.pdf",
"WS2425/SWT D/Praktikum/swtd-p-07.pdf",
"WS2425/SWT D/Praktikum/swtd-p-06.pdf",
"WS2425/SWT D/Praktikum/swtd-p-05.pdf",
"WS2425/SWT D/Praktikum/swtd-p-04.pdf",
"WS2425/SWT D/Praktikum/swtd-p-3.pdf",
"WS2425/SWT D/Praktikum/swtd-p-02.pdf",
"WS2425/SWT D/Praktikum/swtd-p-01.pdf",
"WS2425/SWT D/Uebung/swtd-ue-01.pdf",
@@ -283,7 +281,6 @@
"img/Pasted image 20241206141721.png",
"img/Pasted image 20241206141709.png",
"img/Pasted image 20241206141658.png",
"img/Pasted image 20241206141645.png",
"WS2425/Web Tech/Übung/Notes.md",
"WS2425/Data Science/VL/lecture_08_notes.md",
"WS2425/Data Science/VL/lecture_07_notes.md",

View File

@@ -265,6 +265,144 @@
**Softwaremetriken: Detaillierte Betrachtung**
**1. Was sind Softwaremetriken?**
* **Definition:** Softwaremetriken sind quantitative Messungen, die verwendet werden, um verschiedene Aspekte von Softwareprodukten, -prozessen und -ressourcen zu bewerten und zu verfolgen. Sie liefern Einblicke in die Qualität, Komplexität, Größe, Effizienz und andere wichtige Eigenschaften von Software.
* **Zweck:**
* **Verstehen:** Metriken helfen, die Eigenschaften von Software besser zu verstehen und zu quantifizieren.
* **Vergleichen:** Sie ermöglichen den Vergleich verschiedener Softwareprodukte, -versionen oder -projekte.
* **Vorhersagen:** Metriken können verwendet werden, um zukünftige Entwicklungen, Kosten oder Risiken vorherzusagen.
* **Steuern:** Sie unterstützen die Steuerung von Softwareentwicklungsprozessen und die Optimierung von Ressourcen.
* **Kommunizieren:** Metriken dienen als Kommunikationsmittel zwischen Entwicklern, Managern und anderen Stakeholdern.
**2. Kategorien von Softwaremetriken**
* **Quantitätsmetriken:** Messen die Größe und den Umfang von Software.
* **Beispiele:**
* *Lines of Code (LOC):* Anzahl der Codezeilen in einem Programm.
* *Function Points (FP):* Messung der Funktionalität, die ein Softwaresystem bietet.
* *Number of Classes/Modules:* Anzahl der Klassen oder Module in einem System.
* **Komplexitätsmetriken:** Bewerten die Komplexität von Software.
* **Beispiele:**
* *Cyclomatic Complexity (McCabe):* Messung der Anzahl unabhängiger Pfade durch ein Programm.
* *Halstead Metrics:* Messung der Komplexität basierend auf der Anzahl der Operatoren und Operanden.
* *Coupling and Cohesion:* Messung der Abhängigkeiten zwischen Modulen und des Zusammenhalts innerhalb von Modulen.
* **Qualitätsmetriken:** Bewerten die Qualität von Software.
* **Beispiele:**
* *Defect Density:* Anzahl der Fehler pro Codezeile oder Funktionseinheit.
* *Mean Time To Failure (MTTF):* Durchschnittliche Zeit zwischen Ausfällen eines Systems.
* *Maintainability Index:* Messung der Wartbarkeit von Software.
* *Code Coverage:* Prozentsatz des Codes, der durch Tests abgedeckt wird.
**3. Anwendungsbereiche von Softwaremetriken**
* **Anforderungsanalyse:** Messung der Vollständigkeit und Konsistenz von Anforderungen.
* **Entwurf:** Bewertung der Qualität des Softwaredesigns.
* **Codierung:** Überwachung der Codequalität und -komplexität.
* **Testen:** Messung der Testabdeckung und Fehlerdichte.
* **Wartung:** Bewertung der Wartbarkeit und Änderungsfreundlichkeit von Software.
* **Projektmanagement:** Verfolgung des Projektfortschritts und der Ressourcennutzung.
**4. Beispiele für Softwaremetriken und ihre Berechnung**
* **Lines of Code (LOC):**
* *Berechnung:* Zählen der Anzahl der Codezeilen in einem Programm.
* *Interpretation:* Höhere LOC kann auf größere Komplexität hindeuten, aber auch auf Redundanz.
* **Cyclomatic Complexity (McCabe):**
* *Berechnung:* $V(G) = E - N + 2$, wobei E die Anzahl der Kanten und N die Anzahl der Knoten im Kontrollflussgraphen ist.
* *Interpretation:* Höhere zyklomatische Komplexität deutet auf komplexeren Code hin, der schwieriger zu testen und zu warten ist.
* **Halstead Metrics:**
* *Basisparameter:*
* $t$: Anzahl der unterschiedlichen Operatoren
* $d$: Anzahl der unterschiedlichen Operanden
* $n_t$: Gesamtzahl aller Operatoren im Programm
* $n_d$: Gesamtzahl aller Operanden im Programm
* *Berechnungen:*
* Größe des Vokabulars: $G = t + d$
* Länge des Programms: $N = n_t + n_d$
* Volumen des Programms: $V = N \times log_2 G$
* Level: $L = V^* / V$
* Schwierigkeit: $D = 1 / L$
* Aufwand: $E = V \times D$
* *Interpretation:* Höheres Volumen und höherer Aufwand deuten auf komplexeren Code hin.
* **Weighted Method per Class (WMC):**
* *Berechnung:* $WMC = \sum_{i=1}^{M} v(m_i)$, wobei $v(m_i)$ die Komplexität der Methode $m_i$ ist (z.B. zyklomatische Komplexität).
* *Interpretation:* Höherer WMC deutet auf eine komplexere Klasse hin, die schwieriger zu verstehen und zu testen ist.
**5. Herausforderungen bei der Verwendung von Softwaremetriken**
* **Interpretation:** Metriken müssen im Kontext interpretiert werden. Eine hohe LOC ist nicht immer schlecht, und eine niedrige zyklomatische Komplexität garantiert keine hohe Qualität.
* **Manipulation:** Metriken können manipuliert werden, um ein gewünschtes Ergebnis zu erzielen.
* **Kosten:** Die Erfassung und Analyse von Metriken kann kostspielig sein.
* **Akzeptanz:** Entwickler können Metriken als Bedrohung empfinden, was zu Widerstand führen kann.
**6. Best Practices für die Verwendung von Softwaremetriken**
* **Definieren Sie klare Ziele:** Was soll mit den Metriken erreicht werden?
* **Wählen Sie relevante Metriken:** Welche Metriken sind für die spezifischen Ziele am besten geeignet?
* **Automatisieren Sie die Erfassung:** Verwenden Sie Werkzeuge, um Metriken automatisch zu erfassen.
* **Analysieren Sie die Daten:** Interpretieren Sie die Metriken im Kontext und identifizieren Sie Trends und Muster.
* **Kommunizieren Sie die Ergebnisse:** Teilen Sie die Ergebnisse mit den Stakeholdern und verwenden Sie sie, um Entscheidungen zu treffen.
* **Überprüfen und passen Sie die Metriken an:** Stellen Sie sicher, dass die Metriken weiterhin relevant und nützlich sind.
**Black-Box-Testing (Funktionstests)**
* **Konzept:**
* Der Tester betrachtet das System als "Black Box", d.h. er hat keine Kenntnisse über die interne Struktur, den Code oder die Implementierung des Systems.
* Die Testfälle werden ausschließlich auf Basis der Spezifikation, der Anforderungen oder der Dokumentation des Systems entwickelt.
* Das Ziel ist es, die Funktionalität des Systems aus der Sicht des Endbenutzers zu überprüfen.
* **Vorteile:**
* **Unabhängigkeit:** Tester benötigt keine Programmierkenntnisse.
* **Benutzerperspektive:** Testfälle spiegeln die tatsächliche Nutzung des Systems wider.
* **Frühe Testphase:** Kann bereits in frühen Phasen des Entwicklungsprozesses durchgeführt werden, sobald die Spezifikationen vorliegen.
* **Objektivität:** Tester ist nicht durch die Implementierung voreingenommen.
* **Nachteile:**
* **Begrenzte Abdeckung:** Es ist unmöglich, alle möglichen Eingabekombinationen und Pfade zu testen.
* **Redundanz:** Testfälle können sich überschneiden oder redundante Funktionalität abdecken.
* **Nicht entdeckte Fehler:** Fehler in nicht spezifizierten oder selten genutzten Bereichen können unentdeckt bleiben.
* **Schwierige Testfallerstellung:** Erfordert ein tiefes Verständnis der Spezifikationen und Anforderungen.
* **Gängige Techniken:**
* **Äquivalenzklassenbildung:** Aufteilung der Eingabewerte in Äquivalenzklassen, von denen angenommen wird, dass sie sich gleich verhalten.
* **Grenzwertanalyse:** Testen von Werten an den Grenzen der Äquivalenzklassen.
* **Entscheidungstabellentests:** Erstellung von Tabellen, die alle möglichen Kombinationen von Eingabebedingungen und den entsprechenden Ausgaben auflisten.
* **Zustandsübergangstests:** Modellierung des Systems als Zustandsautomat und Testen aller Zustandsübergänge.
* **Use-Case-Tests:** Entwicklung von Testfällen basierend auf den Use Cases des Systems.
* **Zufallstests:** Generierung von zufälligen Eingabewerten und Überprüfung der Ausgaben.
* **Property-based Testing:** Prüfung, ob ein Prädikat erfüllt ist: $\forall x.P(x, f_{SUT}(x))$.
**Glass-Box-Testing (White-Box-Testing, Strukturtests)**
* **Konzept:**
* Der Tester hat vollen Einblick in die interne Struktur, den Code und die Implementierung des Systems.
* Die Testfälle werden auf Basis des Codes entwickelt, um sicherzustellen, dass alle Teile des Codes ausgeführt werden.
* Das Ziel ist es, die interne Logik des Systems zu überprüfen und Fehler in der Implementierung zu finden.
* **Vorteile:**
* **Vollständige Abdeckung:** Kann sicherstellen, dass alle Teile des Codes getestet werden.
* **Effiziente Fehlerfindung:** Kann Fehler in der Implementierung, wie z.B. Logikfehler oder Datenflussfehler, aufdecken.
* **Codeoptimierung:** Kann helfen, ineffizienten oder unnötigen Code zu identifizieren.
* **Nachteile:**
* **Hoher Aufwand:** Erfordert detaillierte Kenntnisse des Codes und der Implementierung.
* **Komplexität:** Kann sehr komplex und zeitaufwendig sein, insbesondere bei großen Systemen.
* **Entwicklerperspektive:** Testfälle spiegeln möglicherweise nicht die tatsächliche Nutzung des Systems wider.
* **Nicht entdeckte Spezifikationsfehler:** Kann keine Fehler in den Spezifikationen oder Anforderungen aufdecken.
* **Gängige Techniken:**
* **Anweisungsüberdeckung (Statement Coverage):** Sicherstellen, dass jede Anweisung im Code mindestens einmal ausgeführt wird.
* **Zweigüberdeckung (Branch Coverage):** Sicherstellen, dass jeder Zweig (z.B. if-else) im Code mindestens einmal ausgeführt wird.
* **Bedingungsüberdeckung (Condition Coverage):** Sicherstellen, dass jede Bedingung in einem Zweig mindestens einmal true und einmal false ist.
* **Pfadüberdeckung (Path Coverage):** Sicherstellen, dass jeder mögliche Pfad durch den Code mindestens einmal ausgeführt wird.
* **Datenflussanalyse (Data Flow Analysis):** Analyse des Datenflusses durch den Code, um sicherzustellen, dass Variablen korrekt definiert, verwendet und gelöscht werden.
# Note Notes
**Glass-Box-Test (White-Box-Test) / Strukturtest:**