Reproduzierbare Tests beginnen mit einer sauber dokumentierten Testumgebung. Bei Windows-Systemen reicht die Angabe „Windows 11“ in einem Bugreport meist nicht aus. Build-Version, Firmware-Modus, Sicherheitsfunktionen, Grafiktreiber und Hardware können beeinflussen, ob ein Fehler auftritt und ob er auf einem zweiten Gerät reproduzierbar ist. Dieser Leitfaden zeigt, wie Sie die wichtigsten technischen Daten eines Windows-Testgeräts mit integrierten Bordmitteln erfassen – ohne zusätzliche Diagnose-Software.
Welche Informationen gehören in die Dokumentation eines Windows-Testgeräts?
Für viele QA- und Support-Szenarien sind sechs Gruppen besonders relevant: Betriebssystem und Build, Prozessor und Arbeitsspeicher, Firmware-Modus, TPM-Status, Secure-Boot-Status sowie Grafik- und Treiberdaten. Je nach Anwendung kommen Bildschirmauflösung, verfügbare Speicherkapazität, Sprache, Zeitzone und installierte Laufzeitkomponenten hinzu.
Der Zweck ist nicht, möglichst viele Daten zu sammeln. Ziel ist ein kleiner, konsistenter System-Fingerprint, der bei jedem Testgerät auf dieselbe Weise erhoben wird. Dadurch lassen sich Unterschiede zwischen einer funktionierenden und einer fehlerhaften Umgebung schneller erkennen.
1. Windows-Version und Build mit winver erfassen
Drücken Sie Windows-Taste + R, geben Sie winver ein und bestätigen Sie. Das Fenster zeigt die installierte Windows-Version und den Betriebssystembuild. Für einen Bugreport sollten beide Werte übernommen werden.
Die Edition allein ist zu ungenau. Zwei Geräte können beide Windows 11 verwenden, aber unterschiedliche Builds oder Patchstände haben. Ein Verhalten, das nach einem Update auftritt, lässt sich deshalb nur sinnvoll untersuchen, wenn der Build dokumentiert ist.
2. Zentrale Systemdaten mit msinfo32 auslesen
Öffnen Sie über Windows-Taste + R den Befehl msinfo32. Die Systeminformationen bündeln viele Angaben, die für Test- und Fehleranalyse nützlich sind. Besonders relevant sind:
- Betriebssystemname und Version
- Systemhersteller und Systemmodell
- Systemtyp
- Prozessor
- installierter physischer Speicher
- BIOS-Version und -Datum
- BIOS-Modus
- Status von „Sicherer Start“ beziehungsweise Secure Boot
Für reproduzierbare QA-Prozesse empfiehlt es sich, diese Felder in einer festen Vorlage zu führen. So entstehen keine Bugreports, bei denen ein Tester die BIOS-Version dokumentiert und ein anderer nur die Windows-Edition.
3. UEFI und Secure Boot prüfen
In msinfo32 zeigt das Feld zum BIOS-Modus, ob das Gerät im UEFI-Modus oder in einem älteren Legacy-Modus gestartet wurde. Das Feld zum sicheren Start zeigt, ob Secure Boot aktiv ist. Microsoft nennt UEFI und Secure-Boot-Fähigkeit als Bestandteil der Windows-11-Systemanforderungen.
Für die Fehlersuche ist diese Information auch dann nützlich, wenn die getestete Anwendung Secure Boot nicht direkt verwendet. Unterschiede in Firmware-Konfiguration und Sicherheitszustand können erklären, warum Installations-, Treiber- oder Geräteverhalten zwischen zwei ansonsten ähnlich ausgestatteten Rechnern abweicht.
Ändern Sie Firmware-Einstellungen nicht nur für einen Test, ohne die Auswirkungen zu verstehen. Wenn eine Änderung erforderlich ist, dokumentieren Sie den Zustand vor und nach der Anpassung und verwenden Sie die Anleitung des Geräte- oder Mainboard-Herstellers.
4. TPM-Version mit tpm.msc kontrollieren
Drücken Sie Windows-Taste + R, geben Sie tpm.msc ein und öffnen Sie die TPM-Verwaltung. Wenn das Trusted Platform Module verfügbar und betriebsbereit ist, finden Sie dort Herstellerinformationen und die Spezifikationsversion. Für Windows 11 ist TPM 2.0 eine Mindestanforderung.
Zeigt Windows kein kompatibles TPM an, bedeutet das nicht in jedem Fall, dass die Hardware fehlt. Microsoft weist darauf hin, dass TPM auf manchen Geräten in der UEFI-Firmware deaktiviert sein kann. Bezeichnungen können je nach Plattform beispielsweise Intel PTT oder AMD fTPM sein.
Für die Testdokumentation genügen normalerweise drei Werte: TPM vorhanden: ja/nein, Spezifikationsversion und Status. Sensible Schlüssel- oder Identitätsdaten gehören nicht in einen normalen Bugreport.
5. DirectX und Grafiktreiber mit dxdiag dokumentieren
Öffnen Sie über Windows-Taste + R den Befehl dxdiag. Das DirectX-Diagnoseprogramm zeigt neben Systemdaten auch Informationen zur Grafikeinheit und zum Treiber. Auf der Anzeige-Seite sind unter anderem GPU-Bezeichnung, Treiberversion, Treiberdatum, DirectX-Unterstützung und Anzeigemodus sichtbar.
Diese Angaben sind besonders wichtig bei Darstellungsfehlern, Abstürzen mit Hardwarebeschleunigung, Problemen mit mehreren Monitoren oder Unterschieden zwischen virtuellen und physischen Testmaschinen. Microsoft nennt für Windows 11 eine DirectX-12-kompatible Grafikeinheit mit WDDM-2.0-Treiber als Mindestanforderung.
6. CPU, RAM und Systemtyp einheitlich erfassen
Prozessor, installierter RAM und Systemtyp finden Sie ebenfalls in msinfo32 oder unter Einstellungen → System → Info. Erfassen Sie bei der CPU möglichst die genaue Modellbezeichnung statt nur „Intel“ oder „AMD“. Beim Arbeitsspeicher ist die installierte Kapazität ausreichend, sofern kein Speicherproblem untersucht wird.
Für Performance- oder Lasttests sollte zusätzlich festgehalten werden, ob andere ressourcenintensive Prozesse parallel laufen. Ein Testresultat ohne Kontext zur Hardwareauslastung kann leicht falsch interpretiert werden.
7. Freien Speicherplatz prüfen
Ein Gerät kann die formalen Windows-Anforderungen erfüllen und trotzdem zu wenig freien Speicher für ein Update, temporäre Testdaten oder eine größere Anwendung besitzen. Dokumentieren Sie deshalb bei Installations- und Updatefehlern nicht nur die Laufwerksgröße, sondern auch den freien Speicher vor dem Test.
Windows 11 setzt laut Microsoft ein Speichergerät mit mindestens 64 GB voraus. Für reproduzierbare Anwendungstests ist jedoch der tatsächlich verfügbare freie Speicher die aussagekräftigere Kennzahl.
Empfohlener System-Fingerprint für Bugreports
Eine kompakte Vorlage kann beispielsweise so aussehen:
OS: Windows 11 [Edition]
Version/Build: [winver]
Gerätemodell: [msinfo32]
CPU: [genaues Modell]
RAM: [GB]
BIOS-Modus: UEFI/Legacy
Secure Boot: Ein/Aus/Nicht unterstützt
TPM: vorhanden, Version [x.x]
GPU: [Modell]
Grafiktreiber: [Version + Datum]
DirectX/WDDM: [dxdiag]
Display: [Auflösung / Skalierung]
Freier Speicher: [GB]
Testzeitpunkt: [Datum/Uhrzeit]Bei einem Vergleich zwischen zwei Maschinen sollte dieselbe Vorlage für beide Systeme verwendet werden. Unterschiede werden dadurch sofort sichtbar, ohne dass Entwickler mehrere Screenshots durchsuchen müssen.
Welche Daten sollten nicht in öffentliche Bugreports?
Systemdiagnose kann Informationen enthalten, die für die technische Analyse nicht notwendig sind. Veröffentlichen Sie daher keine Seriennummern, Produktschlüssel, Kontodaten, Gerätekennungen, privaten Netzwerkdaten oder andere personenbezogene beziehungsweise vertrauliche Informationen. Prüfen Sie exportierte Diagnoseberichte vor dem Teilen.
In Unternehmen gelten zusätzlich interne Richtlinien für Logs und Telemetriedaten. Ein guter System-Fingerprint enthält nur Daten, die zur Reproduktion des Fehlers beitragen.
Warum diese Dokumentation die Reproduzierbarkeit verbessert
Ein Fehler, der nur auf einem einzelnen Testgerät erscheint, ist nicht automatisch zufällig. Häufig unterscheidet sich die Umgebung in einem Detail: anderer Windows-Build, anderer Grafiktreiber, abweichende Firmware-Konfiguration, weniger freier Speicher oder andere Hardware. Werden diese Unterschiede strukturiert erfasst, lässt sich aus „funktioniert bei mir“ eine prüfbare Hypothese machen.
Besonders wertvoll ist die Methode bei Regressionstests. Speichern Sie den System-Fingerprint zusammen mit dem Testlauf. Wenn sich das Ergebnis nach einem Windows-, Firmware- oder Treiberupdate ändert, ist nachvollziehbar, welche Umgebungsvariable zwischen den Läufen verändert wurde.
Fazit
Für eine belastbare Windows-Testdokumentation sind keine umfangreichen Drittanbieter-Tools notwendig. Mit winver, msinfo32, tpm.msc und dxdiag lassen sich die wichtigsten Systemmerkmale konsistent erfassen. Entscheidend ist weniger die Menge der Daten als eine wiederholbare Vorlage, die auf allen Testgeräten identisch verwendet wird.
