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 "\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 "/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 "\tcp-test.txt" Mit Zeitstempel Get-Date -Format o | Tee-Object -FilePath "\tcp-test.txt" Test-NetConnection server.example -Port 443 -InformationLevel Detailed | Tee-Object -FilePath "\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] > "/test-output.txt" 2>&1 Ausgabe gleichzeitig anzeigen und speichern [FILE] 2>&1 | tee "/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/ > "/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 "/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 Linux und macOS [TEST] ping -c 10 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:" -v -o NUL https://server.example/ Linux und macOS [TEST] curl --resolve "server.example:443:" -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 [TEST] Test-NetConnection -Port [TEST] Test-NetConnection -Port Linux-Server [TEST] nc -vz -w 3 localhost [TEST] nc -vz -w 3 [TEST] nc -vz -w 3 macOS-Server [TEST] nc -vz -w 3 localhost [TEST] nc -vz -w 3 [TEST] nc -vz -w 3 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 -Port 443 Unter Linux und macOS: [TEST] nc -vz -w 3 server.example 443 [TEST] nc -vz -w 3 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 Microsoft Learn – Tee-Object Microsoft Learn – Automatische PowerShell-Variablen Microsoft Learn – PowerShell-Fehlerbehandlung Microsoft Learn – Test-NetConnection curl – Offizielle Befehlsreferenz curl – Exit-Codes util-linux – script(1), technischer Manual-Spiegel GNU Bash – Exit Status