Powtarzalne testy zaczynają się od starannie udokumentowanego środowiska testowego. W systemach Windows samo podanie „Windows 11” w zgłoszeniu błędu zwykle nie wystarcza. Wersja builda, tryb oprogramowania układowego, funkcje zabezpieczeń, sterownik graficzny i sprzęt mogą wpływać na to, czy błąd wystąpi i czy da się go odtworzyć na drugim urządzeniu. Ten poradnik pokazuje, jak zebrać najważniejsze dane techniczne urządzenia testowego Windows za pomocą wbudowanych narzędzi – bez dodatkowego oprogramowania diagnostycznego.
Jakie informacje powinny znaleźć się w dokumentacji urządzenia testowego Windows?
W wielu scenariuszach QA i wsparcia technicznego szczególnie istotnych jest sześć grup danych: system operacyjny i build, procesor i pamięć operacyjna, tryb oprogramowania układowego, stan TPM, stan Secure Boot oraz dane karty graficznej i sterownika. W zależności od zastosowania dochodzą do tego rozdzielczość ekranu, dostępna pojemność pamięci masowej, język, strefa czasowa i zainstalowane komponenty środowiska uruchomieniowego.
Celem nie jest zebranie jak największej ilości danych. Celem jest mały, spójny odcisk systemu (fingerprint), zbierany w ten sam sposób na każdym urządzeniu testowym. Dzięki temu różnice między działającym a wadliwym środowiskiem można rozpoznać znacznie szybciej.
1. Odczyt wersji i builda Windows za pomocą winver
Naciśnij klawisz Windows + R, wpisz winver i potwierdź. Okno pokazuje zainstalowaną wersję Windows oraz build systemu operacyjnego. Obie wartości powinny zostać uwzględnione w zgłoszeniu błędu.
Sama edycja jest zbyt niedokładna. Dwa urządzenia mogą mieć zainstalowanego Windows 11, ale różne buildy lub poziomy poprawek. Zachowanie, które pojawia się po aktualizacji, można więc sensownie zbadać tylko wtedy, gdy build jest udokumentowany.
Mimo to zawsze zanotuj również edycję. To, czy urządzenie testowe działa pod kontrolą Windows 11 Home, Windows 11 Pro czy Windows 11 Enterprise, decyduje o tym, czy funkcje takie jak BitLocker, zasady grupy czy Hyper-V są w ogóle dostępne – a tym samym wpływa również na zachowanie podczas testów.
2. Odczyt kluczowych danych systemowych za pomocą msinfo32
Otwórz polecenie msinfo32 za pomocą klawisza Windows + R. Informacje o systemie zbierają wiele danych przydatnych do testów i analizy błędów. Szczególnie istotne są:
- Nazwa i wersja systemu operacyjnego
- Producent i model systemu
- Typ systemu
- Procesor
- Zainstalowana pamięć fizyczna
- Wersja i data BIOS
- Tryb BIOS
- Stan „bezpiecznego rozruchu” (Secure Boot)
Dla powtarzalnych procesów QA warto prowadzić te pola w stałym szablonie. Dzięki temu nie powstają zgłoszenia błędów, w których jeden tester dokumentuje wersję BIOS-u, a drugi tylko edycję Windows.
3. Sprawdzenie UEFI i Secure Boot
W msinfo32 pole dotyczące trybu BIOS pokazuje, czy urządzenie uruchomiło się w trybie UEFI, czy w starszym trybie Legacy. Pole dotyczące bezpiecznego rozruchu pokazuje, czy Secure Boot jest aktywny. Microsoft wymienia obsługę UEFI i Secure Boot jako część wymagań systemowych Windows 11.
Podczas poszukiwania błędów ta informacja jest przydatna także wtedy, gdy testowana aplikacja nie korzysta bezpośrednio z Secure Boot. Różnice w konfiguracji oprogramowania układowego i stanie zabezpieczeń mogą wyjaśniać, dlaczego zachowanie instalacji, sterowników lub urządzeń różni się między dwoma poza tym podobnie wyposażonymi komputerami.
Nie zmieniaj ustawień oprogramowania układowego tylko na potrzeby jednego testu bez zrozumienia skutków. Jeśli zmiana jest konieczna, udokumentuj stan przed i po zmianie oraz postępuj zgodnie z instrukcją producenta urządzenia lub płyty głównej.
4. Kontrola wersji TPM za pomocą tpm.msc
Naciśnij klawisz Windows + R, wpisz tpm.msc i otwórz zarządzanie TPM. Jeśli moduł Trusted Platform Module jest dostępny i gotowy do pracy, znajdziesz tam informacje o producencie i wersję specyfikacji. Dla Windows 11 TPM 2.0 jest wymaganiem minimalnym.
Jeśli Windows nie pokazuje zgodnego modułu TPM, nie musi to oznaczać, że sprzęt go nie posiada. Microsoft zwraca uwagę, że na niektórych urządzeniach TPM może być wyłączony w oprogramowaniu układowym UEFI. W zależności od platformy może on występować pod nazwami takimi jak Intel PTT lub AMD fTPM.
Do dokumentacji testowej zwykle wystarczą trzy wartości: TPM obecny: tak/nie, wersja specyfikacji i stan. Wrażliwe klucze lub dane tożsamości nie powinny znajdować się w zwykłym zgłoszeniu błędu.
5. Dokumentowanie DirectX i sterownika graficznego za pomocą dxdiag
Otwórz polecenie dxdiag za pomocą klawisza Windows + R. Narzędzie diagnostyczne DirectX pokazuje, obok danych systemowych, także informacje o karcie graficznej i sterowniku. Na karcie Ekran widoczne są m.in. nazwa GPU, wersja sterownika, data sterownika, obsługa DirectX oraz tryb wyświetlania.
Te dane są szczególnie ważne przy błędach wyświetlania, awariach związanych z akceleracją sprzętową, problemach z wieloma monitorami lub różnicach między wirtualnymi a fizycznymi maszynami testowymi. Microsoft podaje dla Windows 11 kartę graficzną zgodną z DirectX 12 ze sterownikiem WDDM 2.0 jako wymaganie minimalne.
6. Jednolite rejestrowanie CPU, RAM i typu systemu
Procesor, zainstalowaną pamięć RAM i typ systemu znajdziesz również w msinfo32 lub w Ustawienia → System → Informacje. W przypadku procesora zapisz w miarę możliwości dokładne oznaczenie modelu zamiast tylko „Intel” lub „AMD”. W przypadku pamięci RAM wystarczy zainstalowana pojemność, o ile nie badasz problemu z pamięcią.
Do testów wydajności lub obciążeniowych warto dodatkowo zanotować, czy równolegle działają inne procesy intensywnie korzystające z zasobów. Wynik testu bez kontekstu obciążenia sprzętu może zostać łatwo błędnie zinterpretowany.
7. Sprawdzenie wolnego miejsca na dysku
Urządzenie może spełniać formalne wymagania Windows, a mimo to mieć za mało wolnego miejsca na aktualizację, tymczasowe dane testowe lub większą aplikację. Dlatego przy błędach instalacji i aktualizacji dokumentuj nie tylko rozmiar dysku, ale też ilość wolnego miejsca przed testem.
Windows 11 wymaga według Microsoftu nośnika pamięci masowej o pojemności co najmniej 64 GB. Jednak dla powtarzalnych testów aplikacji bardziej miarodajnym wskaźnikiem jest faktycznie dostępne wolne miejsce.
Zalecany odcisk systemu do zgłoszeń błędów
Kompaktowy szablon może wyglądać przykładowo tak:
System: Windows 11 [edycja]
Wersja/build: [winver]
Model urządzenia: [msinfo32]
CPU: [dokładny model]
RAM: [GB]
Tryb BIOS: UEFI/Legacy
Secure Boot: Wł./Wył./Nieobsługiwany
TPM: obecny, wersja [x.x]
GPU: [model]
Sterownik graficzny: [wersja + data]
DirectX/WDDM: [dxdiag]
Ekran: [rozdzielczość / skalowanie]
Wolne miejsce: [GB]
Czas testu: [data/godzina]Przy porównywaniu dwóch maszyn należy użyć tego samego szablonu dla obu systemów. Różnice stają się dzięki temu od razu widoczne, bez konieczności przeglądania przez programistów wielu zrzutów ekranu.
Jakie dane nie powinny trafiać do publicznych zgłoszeń błędów?
Diagnostyka systemu może zawierać informacje, które nie są potrzebne do analizy technicznej. Nie publikuj więc numerów seryjnych, kluczy produktu, danych konta, identyfikatorów urządzeń, prywatnych danych sieciowych ani innych danych osobowych lub poufnych. Sprawdź wyeksportowane raporty diagnostyczne przed ich udostępnieniem.
W firmach obowiązują dodatkowo wewnętrzne zasady dotyczące dzienników i danych telemetrycznych. Dobry odcisk systemu zawiera tylko dane, które przyczyniają się do odtworzenia błędu.
Dlaczego ta dokumentacja poprawia powtarzalność
Błąd, który pojawia się tylko na jednym urządzeniu testowym, nie jest automatycznie przypadkowy. Często środowisko różni się w jednym szczególe: inny build Windows, inny sterownik graficzny, odmienna konfiguracja oprogramowania układowego, mniej wolnego miejsca lub inny sprzęt. Gdy te różnice są rejestrowane w sposób usystematyzowany, z „u mnie działa” można zrobić sprawdzalną hipotezę.
Ta metoda jest szczególnie cenna przy testach regresyjnych. Zapisz odcisk systemu razem z przebiegiem testu. Jeśli wynik zmieni się po aktualizacji Windows, oprogramowania układowego lub sterownika, można prześledzić, która zmienna środowiskowa uległa zmianie między przebiegami.
Podsumowanie
Rzetelna dokumentacja testowa Windows nie wymaga rozbudowanych narzędzi firm trzecich. Za pomocą winver, msinfo32, tpm.msc i dxdiag można spójnie zebrać najważniejsze cechy systemu. Decydująca nie jest ilość danych, lecz powtarzalny szablon, stosowany identycznie na wszystkich urządzeniach testowych.
