# 1.6 Prüfungen kontrolliert durchführen und Ergebnisse bewerten

Eine gute Hypothese ist nur dann nützlich, wenn sie mit einem kontrollierten und aussagekräftigen Test geprüft wird.

Dabei gilt:

> Gleicher Ausgangszustand, gleicher Test, nur eine veränderte Variable und ein vorher festgelegtes erwartetes Ergebnis.

Wer mehrere Dinge gleichzeitig verändert, kann die Wirkung später keiner einzelnen Maßnahme zuordnen.

---

**Ziel dieser Seite**

Nach diesem Arbeitsschritt sollten:

- Prüfziel und Hypothese eindeutig feststehen,
- Ausgangszustand und Vergleichswerte dokumentiert sein,
- Risiken und mögliche Auswirkungen des Tests bekannt sein,
- Erfolgskriterien und Abbruchkriterien definiert sein,
- möglichst nur eine Variable verändert werden,
- Befehle, Ausgaben und Rückgabewerte gesichert sein,
- Ergebnisse reproduzierbar sein,
- unklare Tests nicht als Bestätigung interpretiert werden,
- der Zustand nach dem Test erneut geprüft sein.

---

**1. Kennzeichnung der Befehle**

| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | Read-only: liest Informationen aus |
| `[TEST]` | Führt eine aktive Prüfung aus und kann Netzwerkverkehr oder Protokolleinträge erzeugen |
| `[FILE]` | Erstellt oder überschreibt eine Datei |
| `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte |
| `[CHANGE]` | Verändert Konfiguration oder Betriebszustand |
| `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen |
| `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten |

Auch ein `[RO]`- oder `[TEST]`-Befehl ist nicht vollständig spurlos. Er startet mindestens einen Prozess und kann in Protokollen, Shell-Historien, Firewalls oder SIEM-Systemen erscheinen.

---

**2. Der kontrollierte Prüfablauf**

| Phase | Tätigkeit |
|---|---|
| 1. Prüfziel | Welche Frage soll der Test beantworten? |
| 2. Hypothese | Welche mögliche Ursache wird geprüft? |
| 3. Ausgangszustand | Welche Messwerte liegen vor dem Test vor? |
| 4. Vorhersage | Welches Ergebnis wird erwartet? |
| 5. Risiko | Welche Nebenwirkungen kann der Test haben? |
| 6. Abbruchkriterium | Wann muss der Test sofort beendet werden? |
| 7. Durchführung | Exakten Befehl oder Ablauf verwenden |
| 8. Aufzeichnung | Zeit, Ausgabe und Rückgabewert sichern |
| 9. Wiederholung | Ergebnis bei Bedarf kontrolliert reproduzieren |
| 10. Rückkehr | Ausgangszustand wiederherstellen |
| 11. Vergleich | Vorher- und Nachher-Ergebnis vergleichen |
| 12. Bewertung | Hypothese bestätigen, stützen, offenlassen oder widerlegen |

---

**3. Testarten nach Eingriffsrisiko**

| Testart | Beschreibung | Beispiel | Risiko |
|---|---|---|---|
| Passive Abfrage | Liest vorhandenen Zustand | Prozessliste, Logs, Routingtabelle | Sehr niedrig |
| Aktiver Funktionstest | Sendet eine kontrollierte Anfrage | DNS-, Ping-, TCP- oder HTTP-Test | Niedrig |
| Vergleichstest | Vergleicht betroffenes und funktionierendes System | Client A gegen Client B | Niedrig |
| Wiederholungstest | Prüft, ob das Ergebnis reproduzierbar ist | fünf identische TCP-Tests | Niedrig bis mittel |
| Isolationstest | Verändert nur den Testkontext | bestimmtes Backend mit `curl --resolve` | Niedrig bis mittel |
| Reversible Änderung | Verändert vorübergehend eine Einstellung | freigegebene Testregel | Mittel |
| Dienstbezogener Test | Startet oder beendet einen Dienst | Dienstneustart | Hoch |
| Failover-Test | Verlagert produktiven Betrieb | Wechsel auf zweiten Server | Hoch |
| Lasttest | Erzeugt zusätzliche Last | viele parallele Anfragen | Hoch |
| Wiederherstellungstest | Setzt Konfiguration oder Version zurück | Rollback | Hoch |
| Destruktiver Test | Kann Daten oder Zustand zerstören | Löschen, Zurücksetzen, Neuinstallation | Sehr hoch |

Passive, aktive und vergleichende Tests sollten normalerweise vor verändernden oder potenziell störenden Tests durchgeführt werden.

---

**4. Prüfung und Reparatur nicht vermischen**

**Reine Prüfung**

`[TEST] Test-ComputerSecureChannel -Verbose`

Dieser Befehl prüft auf einem Windows-Domänenmitglied den sicheren Kanal.

**Verändernde Reparatur**

`[CHANGE] Test-ComputerSecureChannel -Repair`

Der Parameter `-Repair` verändert den Zustand und ist keine reine Prüfung mehr.

Ein ähnlicher Unterschied besteht bei vielen Werkzeugen:

| Prüfung | Veränderung |
|---|---|
| `Get-Service` | `Restart-Service` |
| `systemctl status` | `systemctl restart` |
| `ipconfig /displaydns` | `ipconfig /flushdns` |
| `Get-NetRoute` | `New-NetRoute` oder `Remove-NetRoute` |
| `journalctl` | Löschen oder Rotieren von Logs |
| `diff` | Überschreiben der Konfiguration |
| Firewall-Log ansehen | Firewall-Regel ändern |
| Zertifikat anzeigen | Zertifikat ersetzen |
| Updateverlauf anzeigen | Update installieren oder entfernen |

Prüfung und Reparatur sollten im Ticket als getrennte Schritte dokumentiert werden.

---

**5. Prüfziel präzise formulieren**

**Ungeeignet**

`Ich teste das Netzwerk.`

**Besser**

`Es wird geprüft, ob Client PC-030 aus VLAN 30 am 30.07.2026 um 15:30 Uhr eine TCP-Verbindung zu server.example auf Port 443 herstellen kann.`

**Noch besser**

`Hypothese H1: Eine ACL blockiert TCP 443 aus VLAN 30. Erwartet wird, dass der TCP-Test aus VLAN 30 fehlschlägt und derselbe Test aus VLAN 40 erfolgreich ist.`

Ein präzises Prüfziel enthält:

- Hypothesennummer,
- Quellsystem,
- Quell-IP oder Quellnetz,
- Zielsystem,
- Ziel-IP,
- Protokoll,
- Port,
- Benutzerkontext,
- Zeitpunkt und Zeitzone,
- erwartetes Ergebnis,
- widerlegendes Ergebnis.

---

**6. Ausgangszustand als Baseline erfassen**

Eine Baseline ist der dokumentierte Zustand vor dem Test.

**Typische Baseline-Werte**

- aktuelle Uhrzeit,
- Systemzustand,
- Dienststatus,
- Prozess-ID,
- CPU- und Speicherauslastung,
- Netzwerkverbindungen,
- IP-Konfiguration,
- DNS-Ergebnis,
- Routingweg,
- Anwendungsergebnis,
- Antwortzeit,
- Fehlercode,
- Ereignisprotokolle,
- Monitoringzustand.

**Beispiel**

| Messwert | Vor dem Test |
|---|---|
| Zeitpunkt | 2026-07-30 15:30:00 CEST |
| Quelle | PC-030 |
| Quell-IP | 192.0.2.30 |
| Quell-VLAN | VLAN 30 |
| Ziel | server.example |
| Ziel-IP | 198.51.100.20 |
| Zielport | TCP 443 |
| DNS-Auflösung | erfolgreich |
| TCP-Test | fehlgeschlagen |
| HTTP-Test | keine Verbindung |
| Ping | keine Antwort |
| Andere Ziele | erreichbar |
| Vergleichsclient aus VLAN 40 | funktioniert |

Die IP-Adressen aus den Netzen `192.0.2.0/24` und `198.51.100.0/24` sind für Dokumentationsbeispiele reserviert.

---

**7. Nur eine Variable verändern**

**Ungeeigneter Test**

Gleichzeitig werden:

- Client neu gestartet,
- DNS-Cache geleert,
- Netzwerkkabel gewechselt,
- Firewall deaktiviert,
- Update installiert,
- Dienst neu gestartet.

Wenn der Fehler danach verschwunden ist, bleibt unklar, welche Maßnahme wirksam war.

**Besseres Vorgehen**

1. Ausgangszustand sichern.
2. DNS-Auflösung prüfen.
3. TCP-Verbindung prüfen.
4. Vergleichsclient testen.
5. anderes Kabel oder anderen Port testen.
6. nach jedem Schritt denselben Funktionstest wiederholen.
7. erst danach eine freigegebene Konfigurationsänderung durchführen.

---

**8. Kontrollvariable und Vergleichssystem verwenden**

Ein Vergleichssystem hilft zu erkennen, ob eine Ursache:

- benutzerbezogen,
- clientbezogen,
- netzwerkbezogen,
- serverbezogen oder
- anwendungsbezogen ist.

| Test | Konstante Werte | Veränderte Variable |
|---|---|---|
| Gleicher Benutzer, anderer Client | Benutzer, Ziel, Funktion | Client |
| Anderer Benutzer, gleicher Client | Client, Ziel, Funktion | Benutzer |
| Gleicher Client, anderes VLAN | Client, Benutzer, Ziel | Netzwerkpfad |
| Gleiches VLAN, anderer Client | Netzwerk, Ziel | Client |
| Gleiches Ziel, direkter Porttest | Client, Netzwerk, Ziel | Anwendungsebene |
| Gleiche URL, bestimmtes Backend | Client, URL, Hostname | Backend |
| Gleiche Datei, anderes Konto | Datei, Client, Pfad | Berechtigung |
| Gleicher Dienst, localhost | Server, Dienst, Port | Netzwerkpfad entfällt |

Je weniger Variablen sich zwischen den Testfällen unterscheiden, desto aussagekräftiger ist der Vergleich.

---

**9. Testzeitpunkt dokumentieren**

**Windows**

`[RO] Get-Date -Format o`

**UTC-Zeit**

`[RO] (Get-Date).ToUniversalTime().ToString("o")`

**Linux**

`[RO] date --iso-8601=seconds`

**macOS**

`[RO] date "+%Y-%m-%dT%H:%M:%S%z"`

Der Zeitpunkt sollte unmittelbar vor und nach dem Test erfasst werden. Dadurch kann die Ausgabe mit Server-, Firewall-, Proxy- und SIEM-Protokollen verglichen werden.

---

**10. PowerShell-Sitzung protokollieren**

PowerShell kann Befehle und Konsolenausgaben einer Sitzung in einer Transkriptdatei aufzeichnen.

**Protokollierung starten**

`[FILE][SENSITIV] Start-Transcript -Path "<Zielpfad>\Testprotokoll.txt" -IncludeInvocationHeader -NoClobber`

**Protokollierung beenden**

`[FILE] Stop-Transcript`

`-IncludeInvocationHeader` ergänzt Zeitinformationen zu den ausgeführten Befehlen.

`-NoClobber` verhindert, dass eine bereits vorhandene Datei überschrieben wird.

**Zu beachten**

- Das Transkript kann Benutzernamen, interne Pfade und Befehlsparameter enthalten.
- Zugangsdaten oder Token dürfen nicht direkt in Befehle geschrieben werden.
- GUI-Aktionen werden nicht erfasst.
- Nicht jede externe Anwendung wird vollständig abgebildet.
- Die Datei muss an einem freigegebenen Speicherort abgelegt werden.

---

**11. Linux- und macOS-Terminalsitzung protokollieren**

Das Werkzeug `script` erstellt eine Aufzeichnung der Terminalsitzung.

**Aufzeichnung starten**

`[FILE][SENSITIV] script "<Zielpfad>/Testprotokoll.txt"`

Anschließend werden die vorgesehenen Diagnosebefehle ausgeführt.

**Aufzeichnung beenden**

`exit`

Alternativ kann die Sitzung mit `Strg + D` beendet werden.

**Zu beachten**

- Die Datei kann Steuerzeichen enthalten.
- Eingaben und Ausgaben können sensible Informationen enthalten.
- Interaktive Programme werden nicht immer als sauberer Text dargestellt.
- Der genaue Funktionsumfang unterscheidet sich zwischen Linux und macOS.
- Die lokale Dokumentation kann mit `man script` aufgerufen werden.

---

**12. Einzelne PowerShell-Ausgabe in Datei und Konsole schreiben**

`Tee-Object` zeigt die Ausgabe auf der Konsole an und speichert sie gleichzeitig in einer Datei.

`[FILE] Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"`

**Mit Zeitstempel**

    Get-Date -Format o |
        Tee-Object -FilePath "<Zielpfad>\tcp-test.txt"

    Test-NetConnection server.example -Port 443 -InformationLevel Detailed |
        Tee-Object -FilePath "<Zielpfad>\tcp-test.txt" -Append

`-Append` fügt die Ausgabe an die vorhandene Datei an.

---

**13. Einzelne Linux- oder macOS-Ausgabe sichern**

**Ausgabe und Fehlermeldungen in eine Datei schreiben**

`[FILE] <Befehl> > "<Zielpfad>/test-output.txt" 2>&1`

**Ausgabe gleichzeitig anzeigen und speichern**

`[FILE] <Befehl> 2>&1 | tee "<Zielpfad>/test-output.txt"`

> Bei einer Pipeline mit `tee` kann der direkt danach angezeigte Rückgabewert zur letzten Komponente der Pipeline gehören. Wenn der ursprüngliche Rückgabewert wichtig ist, sollte der Befehl zunächst ohne Pipeline ausgeführt und anschließend die Datei angezeigt werden.

**Rückgabewert zuverlässig sichern**

    started_at=$(date "+%Y-%m-%dT%H:%M:%S%z")
    curl --connect-timeout 5 --max-time 15 https://server.example/ > "<Zielpfad>/curl-test.txt" 2>&1
    test_rc=$?
    ended_at=$(date "+%Y-%m-%dT%H:%M:%S%z")

    echo "Start: $started_at"
    echo "Ende: $ended_at"
    echo "Exit-Code: $test_rc"
    cat "<Zielpfad>/curl-test.txt"

Der Rückgabewert muss unmittelbar nach dem geprüften Befehl in einer Variablen gesichert werden.

---

**14. Rückgabewerte unter Windows auswerten**

**PowerShell-Cmdlets**

`$?` zeigt an, ob die unmittelbar vorherige PowerShell-Operation erfolgreich abgeschlossen wurde.

`[RO] $?`

Mögliche Werte:

- `$true`
- `$false`

**Native Programme**

`$LASTEXITCODE` enthält den Rückgabewert des zuletzt ausgeführten nativen Programms.

    curl.exe --connect-timeout 5 --max-time 15 https://server.example/
    $curlExitCode = $LASTEXITCODE
    "curl Exit-Code: $curlExitCode"

**Windows-Eingabeaufforderung**

`[RO] echo %ERRORLEVEL%`

> Der Rückgabewert muss direkt nach dem betreffenden Programm geprüft werden. Ein nachfolgender Befehl kann den gespeicherten Wert verändern.

---

**15. Rückgabewerte unter Linux und macOS auswerten**

`$?` enthält den Rückgabewert des zuletzt ausgeführten Befehls.

    curl --connect-timeout 5 --max-time 15 https://server.example/
    test_rc=$?
    echo "Exit-Code: $test_rc"

Unter Unix-artigen Systemen bedeutet üblicherweise:

| Rückgabewert | Allgemeine Bedeutung |
|---:|---|
| `0` | Programm meldet Erfolg |
| ungleich `0` | Programm meldet Fehler oder besonderen Zustand |

Die genaue Bedeutung hängt vom jeweiligen Programm ab und muss in dessen Dokumentation geprüft werden.

---

**16. Erfolg des Werkzeugs und Erfolg der Funktion unterscheiden**

Ein Rückgabewert `0` bedeutet nicht automatisch, dass die vom Benutzer benötigte Funktion erfolgreich war.

**Beispiel mit curl**

Ohne zusätzliche Option kann curl eine HTTP-Antwort `404`, `403` oder `500` empfangen und trotzdem mit Exit-Code `0` enden. Die Netzwerkübertragung war erfolgreich, obwohl die Anwendung einen Fehlerstatus zurückgab.

Deshalb müssen mindestens zwei Ebenen getrennt werden:

| Ebene | Beispiel |
|---|---|
| Werkzeugausführung | curl konnte eine HTTP-Antwort empfangen |
| Fachliche Funktion | Benutzer konnte sich erfolgreich anmelden |
| Anwendungsstatus | Server antwortete mit HTTP 200 |
| Inhaltliche Richtigkeit | Gelieferte Daten sind vollständig und korrekt |

**HTTP-Fehler als curl-Fehler behandeln**

`[TEST] curl --fail --connect-timeout 5 --max-time 15 https://server.example/`

Die Option `--fail` lässt curl bei HTTP-Statuscodes ab 400 einen Fehler melden. Dabei wird der Antworttext normalerweise nicht ausgegeben.

Für eine Diagnose ist es häufig besser, zunächst HTTP-Status und Ausgabe separat zu dokumentieren.

---

**17. Zeitbegrenzungen verwenden**

Tests sollten nicht unbegrenzt warten.

**Windows**

`[TEST] curl.exe --connect-timeout 5 --max-time 15 https://server.example/`

**Linux**

`[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/`

**macOS**

`[TEST] curl --connect-timeout 5 --max-time 15 https://server.example/`

| Option | Bedeutung |
|---|---|
| `--connect-timeout 5` | maximal fünf Sekunden für die Verbindungsphase |
| `--max-time 15` | maximal 15 Sekunden für den gesamten Transfer |

Zur Verbindungsphase gehören bei curl unter anderem DNS-Auflösung sowie TCP-, TLS- oder QUIC-Verbindungsaufbau.

---

**18. HTTP-Zeiten gezielt messen**

curl kann einzelne Zeitabschnitte einer HTTP-Verbindung ausgeben.

**Windows PowerShell**

`[TEST] curl.exe -sS -o NUL -w 'code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' --connect-timeout 5 --max-time 15 https://server.example/`

**Linux und macOS**

`[TEST] curl -sS -o /dev/null -w "code=%{http_code} remote=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" --connect-timeout 5 --max-time 15 https://server.example/`

**Bedeutung der Werte**

| Wert | Bedeutung |
|---|---|
| `http_code` | empfangener HTTP-Status |
| `remote_ip` | tatsächlich verwendete Ziel-IP |
| `time_namelookup` | Zeit bis zum Abschluss der Namensauflösung |
| `time_connect` | Zeit bis zum TCP-Verbindungsaufbau |
| `time_appconnect` | Zeit bis zum Abschluss des TLS-Handshakes |
| `time_starttransfer` | Zeit bis zum ersten empfangenen Byte |
| `time_total` | gesamte Übertragungszeit |

Die Zeitwerte werden in Sekunden ausgegeben.

---

**19. HTTP-Zeitwerte interpretieren**

| Beobachtung | Mögliche Ursache |
|---|---|
| `time_namelookup` hoch | DNS-Server, Resolver oder Weiterleitung langsam |
| `time_connect` hoch | Netzwerkpfad, Firewall, Überlastung oder Server |
| `time_appconnect` deutlich höher | TLS-Handshake, Zertifikat oder Kryptografie |
| `time_starttransfer` hoch | Anwendung oder Backend benötigt lange |
| `time_total` hoch, erstes Byte schnell | langsame Datenübertragung oder große Antwort |
| wechselnde `remote_ip` | DNS-Rotation, Load Balancer oder mehrere Backends |
| wechselnder HTTP-Status | unterschiedliche Backends oder instabiler Dienst |
| `http_code=000` | keine gültige HTTP-Antwort empfangen |

Ein einzelner Messwert reicht bei sporadischen Fehlern nicht aus. Mehrere Messungen mit Zeitstempel sind aussagekräftiger.

---

**20. Tests wiederholen, ohne unnötige Last zu erzeugen**

**Windows-Ping**

`[TEST] ping -n 10 <IP-Adresse>`

**Linux und macOS**

`[TEST] ping -c 10 <IP-Adresse>`

**Wiederholter TCP-Test unter Windows**

    1..5 | ForEach-Object {
        $result = Test-NetConnection server.example -Port 443 -InformationLevel Detailed

        [pscustomobject]@{
            Time          = Get-Date -Format o
            RemoteAddress = $result.RemoteAddress
            SourceAddress = $result.SourceAddress
            Success       = $result.TcpTestSucceeded
        }

        Start-Sleep -Seconds 2
    }

**Wiederholter TCP-Test unter Linux und macOS**

    for test_number in 1 2 3 4 5
    do
        date "+%Y-%m-%dT%H:%M:%S%z"
        nc -vz -w 3 server.example 443
        sleep 2
    done

Vor Wiederholungstests ist zu prüfen:

- Wie viel Last erzeugt eine Anfrage?
- Kann ein Konto gesperrt werden?
- Greift ein Rate Limit?
- Wird ein Alarm im SIEM ausgelöst?
- Kann die Anwendung Daten verändern?
- Ist der Test in der Produktion zulässig?

---

**21. Sporadische Fehler richtig untersuchen**

Ein sporadischer Fehler kann übersehen werden, wenn nur ein einzelner Test durchgeführt wird.

Zu dokumentieren sind:

- Anzahl der Tests,
- zeitlicher Abstand,
- Anzahl erfolgreicher Tests,
- Anzahl fehlgeschlagener Tests,
- genaue Fehlercodes,
- verwendete Ziel-IP,
- verwendetes Backend,
- Antwortzeiten,
- Zeitpunkt jedes Fehlers.

**Beispiel**

| Versuch | Uhrzeit | Ziel-IP | TCP | HTTP | Gesamtzeit |
|---:|---|---|---|---:|---:|
| 1 | 15:30:00 | 198.51.100.20 | erfolgreich | 200 | 0,21 s |
| 2 | 15:30:05 | 198.51.100.21 | erfolgreich | 503 | 4,92 s |
| 3 | 15:30:10 | 198.51.100.20 | erfolgreich | 200 | 0,19 s |
| 4 | 15:30:15 | 198.51.100.21 | erfolgreich | 503 | 5,01 s |
| 5 | 15:30:20 | 198.51.100.20 | erfolgreich | 200 | 0,22 s |

Das Muster deutet auf ein Problem mit dem Backend `198.51.100.21` hin.

---

**22. Bestimmtes HTTPS-Ziel ohne DNS-Änderung testen**

Der Aufruf einer HTTPS-Seite direkt über ihre IP-Adresse kann zu falschen Ergebnissen führen, weil:

- der HTTP-Host-Header verändert wird,
- TLS-SNI nicht zum erwarteten Hostnamen passt,
- das Zertifikat nicht für die IP-Adresse ausgestellt ist,
- ein anderer virtueller Host antwortet.

Mit `curl --resolve` kann für einen einzelnen Test ein bestimmter Hostname einer bestimmten IP-Adresse zugeordnet werden, ohne DNS oder Hosts-Datei zu verändern.

**Windows**

`[TEST] curl.exe --resolve "server.example:443:<IP-Adresse>" -v -o NUL https://server.example/`

**Linux und macOS**

`[TEST] curl --resolve "server.example:443:<IP-Adresse>" -v -o /dev/null https://server.example/`

Dadurch bleiben erhalten:

- URL-Hostname,
- HTTP-Host-Header,
- TLS-SNI,
- normale Zertifikatsprüfung.

Nur die Ziel-IP wird für diesen curl-Aufruf vorgegeben.

**Beispiel für zwei Backends**

`[TEST] curl --resolve "server.example:443:198.51.100.20" -v -o /dev/null https://server.example/`

`[TEST] curl --resolve "server.example:443:198.51.100.21" -v -o /dev/null https://server.example/`

> Das direkte Testen eines Backends kann Load Balancer, WAF oder andere Schutzsysteme umgehen. Es darf nur erfolgen, wenn dieser Test technisch vorgesehen und autorisiert ist.

---

**23. Lokalen Dienst und Netzwerkpfad getrennt testen**

**Windows-Server**

`[TEST] Test-NetConnection localhost -Port <Port>`

`[TEST] Test-NetConnection <Eigene-Server-IP> -Port <Port>`

`[TEST] Test-NetConnection <Servername> -Port <Port>`

---

**Linux-Server**

`[TEST] nc -vz -w 3 localhost <Port>`

`[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>`

`[TEST] nc -vz -w 3 <Servername> <Port>`

---

**macOS-Server**

`[TEST] nc -vz -w 3 localhost <Port>`

`[TEST] nc -vz -w 3 <Eigene-Server-IP> <Port>`

`[TEST] nc -vz -w 3 <Servername> <Port>`

**Interpretation**

| localhost | Eigene IP | Remote-Client | Möglicher Fehlerbereich |
|---|---|---|---|
| erfolgreich | erfolgreich | erfolgreich | Netzwerkgrundfunktion vorhanden |
| erfolgreich | erfolgreich | fehlgeschlagen | Netzwerkpfad oder Firewall |
| erfolgreich | fehlgeschlagen | fehlgeschlagen | Listener-Bindung oder lokale Firewall |
| fehlgeschlagen | fehlgeschlagen | fehlgeschlagen | Dienst oder Anwendung |
| fehlgeschlagen | erfolgreich | erfolgreich | besondere Proxy-, Container- oder Weiterleitungskonfiguration |

---

**24. Test mit und ohne Namensauflösung**

**DNS-basierter Test**

`[TEST] Test-NetConnection server.example -Port 443`

**Direkter TCP-Test zur bekannten IP**

`[TEST] Test-NetConnection <IP-Adresse> -Port 443`

Unter Linux und macOS:

`[TEST] nc -vz -w 3 server.example 443`

`[TEST] nc -vz -w 3 <IP-Adresse> 443`

**Interpretation**

| Name | IP | Möglicher Fehlerbereich |
|---|---|---|
| erfolgreich | erfolgreich | DNS und TCP-Grundfunktion vorhanden |
| fehlgeschlagen | erfolgreich | DNS oder Namensauswahl |
| erfolgreich | fehlgeschlagen | Testfehler oder unterschiedliche Zieladresse prüfen |
| fehlgeschlagen | fehlgeschlagen | Netzwerk, Firewall, Dienst oder Zielsystem |

Der direkte IP-Test ist für TCP geeignet. Für HTTPS sollte wegen Host-Header, SNI und Zertifikatsprüfung `curl --resolve` verwendet werden.

---

**25. Anwendungstest und Benutzerfunktion trennen**

Ein technischer Test kann erfolgreich sein, obwohl die Benutzerfunktion weiterhin fehlschlägt.

| Prüfebene | Beispiel |
|---|---|
| DNS | Hostname wird aufgelöst |
| Netzwerk | Ziel-IP ist erreichbar |
| Transport | TCP-Port ist erreichbar |
| TLS | Zertifikat und Handshake funktionieren |
| HTTP | Server liefert eine Antwort |
| Authentifizierung | Benutzer kann sich anmelden |
| Autorisierung | Benutzer darf die Funktion verwenden |
| Anwendung | gewünschte Aktion wird verarbeitet |
| Datenebene | Datenbank speichert oder liefert korrekte Daten |
| Geschäftsprozess | gesamter Arbeitsablauf funktioniert |

**Beispiel**

- TCP 443 erreichbar
- TLS erfolgreich
- HTTP 200 auf Startseite
- Anmeldung erfolgreich
- Datei-Upload schlägt fehl

Die Ursache liegt dann nicht in der grundlegenden Erreichbarkeit, sondern möglicherweise in:

- Upload-Berechtigung,
- Dateigrößenlimit,
- Reverse Proxy,
- WAF,
- Speicherplatz,
- Anwendung,
- Datenbank,
- Backend-Storage.

---

**26. Vorher- und Nachher-Test identisch durchführen**

Nach einer Maßnahme muss derselbe definierte Test erneut ausgeführt werden.

**Ungeeigneter Vergleich**

- Vorher: Benutzer berichtet, dass es nicht funktioniert.
- Nachher: Administrator pingt den Server.

Diese Ergebnisse prüfen unterschiedliche Funktionen.

**Geeigneter Vergleich**

- Vorher: `curl` gegen dieselbe URL mit dokumentiertem Benutzerkontext.
- Maßnahme: eine freigegebene Konfiguration wird geändert.
- Nachher: derselbe `curl`-Befehl vom selben Client.
- Danach: ursprünglicher Benutzerablauf wird wiederholt.

---

**27. Vorher-Nachher-Protokoll**

| Feld | Vorher | Nachher |
|---|---|---|
| Zeitpunkt |  |  |
| Quellsystem |  |  |
| Quell-IP |  |  |
| Benutzer |  |  |
| Zielsystem |  |  |
| Ziel-IP |  |  |
| Protokoll und Port |  |  |
| DNS-Ergebnis |  |  |
| TCP-Ergebnis |  |  |
| TLS-Ergebnis |  |  |
| HTTP-Status |  |  |
| Antwortzeit |  |  |
| Anwendungsfunktion |  |  |
| Fehlermeldung |  |  |
| Monitoringstatus |  |  |
| Rückgabewert |  |  |

---

**28. Erfolgskriterien definieren**

Ein Erfolgskriterium muss messbar sein.

**Ungeeignet**

`Das System läuft wieder normal.`

**Besser**

- TCP-Verbindung ist bei fünf aufeinanderfolgenden Tests erfolgreich.
- HTTP-Status ist fünfmal `200`.
- Antwortzeit liegt unter dem vereinbarten Schwellenwert.
- Benutzer kann sich anmelden.
- Datei kann hochgeladen und wieder heruntergeladen werden.
- Monitoring meldet für 30 Minuten keinen neuen Fehler.
- Ereignisprotokoll enthält keine neuen relevanten Fehler.
- Vergleichssystem und betroffenes System zeigen dasselbe Ergebnis.

Schwellenwerte dürfen nicht frei erfunden werden. Sie müssen aus:

- SLA,
- Monitoring-Baseline,
- Herstellerangabe,
- Anwendungsanforderung oder
- dokumentiertem Normalzustand

abgeleitet werden.

---

**29. Abbruchkriterien definieren**

Ein Test muss abgebrochen werden, wenn beispielsweise:

- Datenintegrität gefährdet ist,
- unerwartete Systeme betroffen sind,
- Fehlerrate stark ansteigt,
- CPU-, RAM- oder I/O-Auslastung kritisch steigt,
- Benutzer produktiv beeinträchtigt werden,
- Monitoring neue kritische Alarme meldet,
- eine Sicherheitswarnung auftritt,
- eine Rückfallmaßnahme nicht funktioniert,
- der Test außerhalb des genehmigten Umfangs wirkt,
- das erwartete Zeitfenster überschritten wird.

**Abbruchvorlage**

| Feld | Eintrag |
|---|---|
| Abbruchbedingung |  |
| Messgröße |  |
| Grenzwert |  |
| Verantwortliche Person |  |
| Sofortmaßnahme |  |
| Rückfallmaßnahme |  |
| Kommunikationsweg |  |

---

**30. Testergebnisse klassifizieren**

| Status | Bedeutung |
|---|---|
| Bestanden | Definiertes Erfolgskriterium vollständig erreicht |
| Nicht bestanden | Definiertes Erfolgskriterium nicht erreicht |
| Teilweise bestanden | Nur ein Teil der Kriterien erreicht |
| Nicht eindeutig | Ergebnis lässt mehrere Erklärungen zu |
| Nicht reproduzierbar | Fehler trat bei Wiederholung nicht erneut auf |
| Abgebrochen | Abbruchkriterium wurde erreicht |
| Nicht durchgeführt | Test konnte nicht ausgeführt werden |
| Ungültig | Testbedingungen oder Messung waren fehlerhaft |

„Nicht eindeutig“ ist ein gültiges Ergebnis. Es ist besser als eine unberechtigte Bestätigung.

---

**31. Hypothese nach dem Test bewerten**

| Testergebnis | Bewertung der Hypothese |
|---|---|
| Vorhersage vollständig eingetroffen | Hypothese wird gestützt |
| Vorhersage mehrfach reproduziert | Hypothese wird stark gestützt |
| Gegenprobe erfolgreich | Ursache möglicherweise bestätigt |
| Ergebnis teilweise passend | Hypothese bleibt offen |
| Ergebnis mehrdeutig | neuer trennschärferer Test erforderlich |
| Vorhersage nicht eingetroffen | Hypothese wird geschwächt |
| Widerlegendes Ergebnis eingetroffen | Hypothese gilt als widerlegt |
| Testbedingungen fehlerhaft | keine Bewertung möglich |

> Ein fehlgeschlagener Test bestätigt nicht automatisch die untersuchte Ursache. Er zeigt zunächst nur, dass die getestete Funktion unter den verwendeten Bedingungen fehlgeschlagen ist.

---

**32. Falsch positive Ergebnisse**

Ein Test meldet einen Fehler, obwohl die eigentliche Funktion verfügbar ist.

**Beispiele**

| Test | Falsch positives Ergebnis |
|---|---|
| Ping | keine Antwort, weil ICMP blockiert ist |
| Traceroute | Sternchen, obwohl Ziel erreichbar ist |
| Portscanner | Port wirkt gefiltert, weil Sicherheitskomponente reagiert |
| DNS-Test | anderer Load-Balancer wird als „falsche IP“ interpretiert |
| Zertifikatstest | direkter IP-Aufruf erzeugt absichtlich Namensfehler |
| Dienststatus | Dienst ist gestoppt, weil er socket-aktiviert gestartet wird |
| HTTP-HEAD | Server lehnt `HEAD` ab, verarbeitet aber `GET` |
| Monitoring | veralteter Alarm bleibt nach Wiederherstellung aktiv |

---

**33. Falsch negative Ergebnisse**

Ein Test meldet Erfolg, obwohl die Benutzerfunktion weiterhin gestört ist.

**Beispiele**

| Test | Falsch negatives Ergebnis |
|---|---|
| Ping erfolgreich | Anwendung oder Port kann trotzdem ausgefallen sein |
| TCP-Port erreichbar | Anwendung kann fehlerhafte Antworten liefern |
| HTTP 200 | Anmeldung oder Fachfunktion kann trotzdem fehlschlagen |
| Dienststatus „Running“ | Prozess kann intern hängen |
| DNS-Auflösung erfolgreich | zurückgegebene Adresse kann falsch sein |
| Einzelner Test erfolgreich | sporadischer Fehler wird nicht erfasst |
| Testkonto funktioniert | normales Benutzerkonto kann weiterhin falsche Rechte haben |
| Ein Backend funktioniert | anderes Backend kann fehlerhaft sein |
| Speicherplatz vorhanden | Inodes oder Quota können trotzdem erschöpft sein |

---

**34. Testwerkzeug und Testpunkt dokumentieren**

Ein Ergebnis ist nur verständlich, wenn bekannt ist, wo und wie gemessen wurde.

**Zu dokumentieren**

- Werkzeugname,
- Werkzeugversion,
- Betriebssystem,
- genauer Befehl,
- Quellsystem,
- Quell-IP,
- Quell-VLAN,
- Benutzerkontext,
- Zielname,
- Ziel-IP,
- Protokoll,
- Port,
- Zeitpunkt,
- Zeitzone,
- Wiederholungsanzahl,
- vollständige Ausgabe,
- Rückgabewert.

**Werkzeugversionen anzeigen**

**PowerShell**

`[RO] $PSVersionTable`

**curl**

`[RO] curl --version`

**OpenSSL**

`[RO] openssl version -a`

**Linux-Kernel**

`[RO] uname -a`

**macOS**

`[RO] sw_vers`

Unterschiedliche Werkzeugversionen können verschiedene Optionen, Protokolle oder Standardwerte verwenden.

---

**35. Produktivumgebung gegen Testumgebung abwägen**

| Umgebung | Vorteil | Nachteil |
|---|---|---|
| Produktionssystem | reales Fehlerbild | Risiko für Benutzer und Daten |
| Testsystem | geringeres Risiko | möglicherweise nicht identische Konfiguration |
| Staging | produktionsähnlich | möglicherweise andere Daten oder Last |
| isolierter Client | einzelne Variable kontrollierbar | nicht jeder Netzwerkpfad wird abgebildet |
| Snapshot-Kopie | Zustand kann untersucht werden | flüchtige Informationen fehlen möglicherweise |
| Labor | Tests gut reproduzierbar | Produktionsabhängigkeiten fehlen |

Ein Testsystem ist nur dann aussagekräftig, wenn relevante Unterschiede zur Produktion dokumentiert sind.

---

**36. Änderungen in der Produktion absichern**

Vor einer verändernden Prüfung sollten geklärt sein:

- Freigabe,
- Wartungsfenster,
- betroffene Systeme,
- betroffene Benutzer,
- Backup oder Konfigurationssicherung,
- Rückfallplan,
- Abbruchkriterien,
- Monitoring,
- Kommunikation,
- verantwortliche Person,
- erwartete Testdauer,
- Beobachtungszeit nach der Änderung.

**Freigabevorlage**

| Feld | Eintrag |
|---|---|
| Ticketnummer |  |
| Hypothese |  |
| geplante Änderung |  |
| betroffene Systeme |  |
| erwartete Auswirkung |  |
| Risiko |  |
| Wartungsfenster |  |
| Backup vorhanden | Ja / Nein |
| Rückfallplan |  |
| Abbruchkriterium |  |
| Freigabe durch |  |
| ausführende Person |  |
| beobachtende Person |  |

---

**37. Tests mit Anmeldungen vorsichtig durchführen**

Anmeldetests können:

- Konten sperren,
- MFA-Anfragen auslösen,
- Sicherheitsalarme erzeugen,
- Sitzungen beenden,
- Token erzeugen,
- Lizenzplätze belegen,
- Änderungen im Benutzerprofil auslösen.

Vor einem Anmeldetest prüfen:

- Ist das Kennwort sicher bekannt?
- Wie viele Fehlversuche sind erlaubt?
- Existiert ein freigegebenes Testkonto?
- Wird MFA ausgelöst?
- Darf das Konto auf diesem System verwendet werden?
- Kann die Sitzung wieder sauber beendet werden?
- Werden durch den Test Daten verändert?
- Wird ein SIEM-Alarm erwartet?

Kennwörter, Token und API-Schlüssel dürfen nicht in Protokolldateien, Terminaltranskripten oder Befehlszeilen erscheinen.

---

**38. Beispiel eines kontrollierten Tests**

**Störung**

Eine Webanwendung liefert sporadisch HTTP `503`.

**Hypothesen**

- H1: DNS liefert zeitweise eine falsche IP-Adresse.
- H2: Eines von zwei Backends ist fehlerhaft.
- H3: Der TLS-Handshake schlägt sporadisch fehl.
- H4: Der Client verliert zeitweise die Netzwerkverbindung.

**Prüfplan**

| Schritt | Test | Erwarteter Erkenntnisgewinn |
|---:|---|---|
| 1 | DNS mehrfach abfragen | verwendete Zieladressen bestimmen |
| 2 | curl-Zeitmessung wiederholen | HTTP-Status, Ziel-IP und Zeitstufe erfassen |
| 3 | Backends einzeln mit `--resolve` testen | fehlerhaftes Backend identifizieren |
| 4 | TCP- und TLS-Ergebnisse vergleichen | Netzwerk- und TLS-Ursachen bewerten |
| 5 | Serverlogs zum Zeitpunkt prüfen | Backendfehler bestätigen |

**Ergebnis**

- DNS liefert abwechselnd `198.51.100.20` und `198.51.100.21`.
- Anfragen an `.20` liefern HTTP `200`.
- Anfragen an `.21` liefern HTTP `503`.
- TCP- und TLS-Verbindung funktionieren zu beiden Adressen.
- Backendprotokoll von `.21` zeigt eine nicht erreichbare Datenbank.

**Bewertung**

- H1 wird widerlegt: Beide DNS-Adressen sind vorgesehen.
- H2 wird stark gestützt: Der Fehler ist an Backend `.21` gebunden.
- H3 wird widerlegt: TLS funktioniert bei beiden Backends.
- H4 wird widerlegt: TCP-Verbindungen sind stabil.
- Als nächste Hypothese wird die Datenbankverbindung von Backend `.21` geprüft.

---

**39. Testprotokoll-Vorlage**

| Feld | Eintrag |
|---|---|
| Ticketnummer |  |
| Testnummer |  |
| Hypothesennummer |  |
| Prüfziel |  |
| Datum |  |
| Startzeit |  |
| Endzeit |  |
| Zeitzone |  |
| ausführende Person |  |
| Quellsystem |  |
| Quell-IP und VLAN |  |
| Zielsystem |  |
| Ziel-IP |  |
| Protokoll und Port |  |
| Benutzerkontext |  |
| Werkzeug und Version |  |
| exakter Befehl |  |
| Ausgangszustand |  |
| erwartetes Ergebnis |  |
| widerlegendes Ergebnis |  |
| tatsächliches Ergebnis |  |
| Rückgabewert |  |
| Ausgabedatei |  |
| Hypothesenbewertung |  |
| Nebenwirkungen |  |
| Rückfall durchgeführt | Ja / Nein / Nicht erforderlich |
| Zustand nach dem Test |  |
| nächster Schritt |  |

---

**Kurzcheckliste**

- [ ] Prüfziel eindeutig formuliert
- [ ] Hypothese und Vorhersage dokumentiert
- [ ] Widerlegendes Ergebnis festgelegt
- [ ] Ausgangszustand gesichert
- [ ] Quell- und Zielsystem dokumentiert
- [ ] Benutzerkontext dokumentiert
- [ ] Risiko bewertet
- [ ] Freigabe bei veränderndem Test eingeholt
- [ ] Rückfallplan vorhanden
- [ ] Abbruchkriterien definiert
- [ ] Möglichst nur eine Variable verändert
- [ ] Vergleichssystem verwendet
- [ ] Start- und Endzeit dokumentiert
- [ ] Exakten Befehl dokumentiert
- [ ] Vollständige Ausgabe gesichert
- [ ] Rückgabewert gesichert
- [ ] Test bei Bedarf kontrolliert wiederholt
- [ ] Werkzeugversion dokumentiert
- [ ] Vorher- und Nachher-Test identisch durchgeführt
- [ ] Benutzerfunktion zusätzlich technisch geprüft
- [ ] Falsch positive Ergebnisse berücksichtigt
- [ ] Falsch negative Ergebnisse berücksichtigt
- [ ] Hypothesenstatus aktualisiert
- [ ] Zustand nach dem Test kontrolliert
- [ ] Ergebnis im Ticket dokumentiert

---

**Ergebnis dieses Arbeitsschrittes**

Am Ende dieses Schrittes liegt ein nachvollziehbares und reproduzierbares Testergebnis vor.

Ein brauchbares Testergebnis beantwortet:

- Was wurde geprüft?
- Welche Hypothese wurde untersucht?
- Von welchem System wurde getestet?
- Unter welchem Benutzerkontext wurde getestet?
- Wann wurde getestet?
- Welcher genaue Befehl wurde verwendet?
- Was wurde vorher erwartet?
- Was wurde tatsächlich beobachtet?
- Welcher Rückgabewert wurde erzeugt?
- Welche Hypothese wird dadurch gestützt oder widerlegt?
- Wurde der Ausgangszustand wiederhergestellt?
- Welcher nächste Schritt ergibt sich daraus?

**Nächste Seite:**  
**1.7 Ursache bestätigen und alternative Erklärungen ausschließen**

---

**Offizielle Hersteller- und Projektdokumentation**

- [Microsoft Learn – Start-Transcript](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.host/start-transcript)
- [Microsoft Learn – Tee-Object](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/tee-object)
- [Microsoft Learn – Automatische PowerShell-Variablen](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_automatic_variables)
- [Microsoft Learn – PowerShell-Fehlerbehandlung](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_error_handling)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html)
- [curl – Exit-Codes](https://curl.se/docs/manpage.html#EXITCODES)
- [util-linux – script(1), technischer Manual-Spiegel](https://man7.org/linux/man-pages/man1/script.1.html)
- [GNU Bash – Exit Status](https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html)