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

Ausgangszustand sichern.

DNS-Auflösung prüfen.

TCP-Verbindung prüfen.

Vergleichsclient testen.

anderes Kabel oder anderen Port testen.

nach jedem Schritt denselben Funktionstest wiederholen.

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