Documentarea unui dispozitiv de test Windows: citirea TPM, UEFI, Secure Boot, DirectX și a hardware-ului

Ghid tehnic pentru medii de testare Windows reproductibile: înregistrarea corectă a informațiilor despre sistem, TPM 2.0, UEFI, Secure Boot, DirectX, modelul de driver, CPU, RAM și versiunea de build.

6 min de citit Actualizat la 03/09/2026

Testele reproductibile încep cu un mediu de testare documentat riguros. La sistemele Windows, mențiunea „Windows 11” într-un raport de eroare de obicei nu este suficientă. Versiunea de build, modul firmware, funcțiile de securitate, driverul grafic și hardware-ul pot influența apariția unei erori și posibilitatea de a o reproduce pe un al doilea dispozitiv. Acest ghid arată cum se colectează cele mai importante date tehnice ale unui dispozitiv de test Windows folosind doar instrumentele integrate – fără software de diagnosticare suplimentar.

Ce informații trebuie să conțină documentația unui dispozitiv de test Windows?

Pentru multe scenarii de QA și suport, sunt deosebit de relevante șase grupuri: sistemul de operare și build-ul, procesorul și memoria, modul firmware, starea TPM, starea Secure Boot, precum și datele despre placa grafică și driver. În funcție de aplicație se adaugă rezoluția ecranului, capacitatea de stocare disponibilă, limba, fusul orar și componentele runtime instalate.

Scopul nu este colectarea a cât mai multe date. Obiectivul este o amprentă de sistem mică și consecventă, obținută în același mod pentru fiecare dispozitiv de test. Astfel, diferențele dintre un mediu funcțional și unul defect pot fi identificate mult mai rapid.

1. Determinarea versiunii și build-ului Windows cu winver

Apăsați tasta Windows + R, introduceți winver și confirmați. Fereastra afișează versiunea de Windows instalată și build-ul sistemului de operare. Ambele valori ar trebui incluse într-un raport de eroare.

Ediția, de una singură, este prea imprecisă. Două dispozitive pot rula ambele Windows 11, dar pot avea build-uri sau niveluri de actualizare diferite. Un comportament care apare după o actualizare poate fi investigat util doar dacă build-ul este documentat.

Totuși, notați întotdeauna și ediția. Faptul că un dispozitiv de test rulează Windows 11 Home, Windows 11 Pro sau Windows 11 Enterprise determină dacă funcții precum BitLocker, politicile de grup sau Hyper-V sunt măcar disponibile – influențând astfel și comportamentul din timpul testelor.

2. Citirea datelor centrale de sistem cu msinfo32

Deschideți comanda msinfo32 apăsând tasta Windows + R. Informațiile de sistem reunesc multe date utile pentru testare și analiza erorilor. Sunt deosebit de relevante:

  • Numele și versiunea sistemului de operare
  • Producătorul și modelul sistemului
  • Tipul sistemului
  • Procesorul
  • Memoria fizică instalată
  • Versiunea și data BIOS-ului
  • Modul BIOS
  • Starea „pornirii securizate” (Secure Boot)

Pentru procese QA reproductibile, este recomandat să păstrați aceste câmpuri într-un șablon fix. Astfel se evită rapoartele de eroare în care un tester documentează versiunea BIOS-ului, iar altul doar ediția Windows.

3. Verificarea UEFI și Secure Boot

În msinfo32, câmpul referitor la modul BIOS arată dacă dispozitivul a pornit în modul UEFI sau într-un mod Legacy mai vechi. Câmpul referitor la pornirea securizată arată dacă Secure Boot este activ. Microsoft menționează compatibilitatea UEFI și Secure Boot ca parte a cerințelor de sistem pentru Windows 11.

Pentru depanare, această informație este utilă chiar și atunci când aplicația testată nu utilizează direct Secure Boot. Diferențele din configurația firmware-ului și din starea de securitate pot explica de ce comportamentul de instalare, al driverului sau al dispozitivului diferă între două mașini altfel dotate în mod similar.

Nu modificați setările firmware doar pentru un test, fără a înțelege consecințele. Dacă o modificare este necesară, documentați starea înainte și după ajustare și urmați instrucțiunile producătorului dispozitivului sau al plăcii de bază.

4. Verificarea versiunii TPM cu tpm.msc

Apăsați tasta Windows + R, introduceți tpm.msc și deschideți administrarea TPM. Dacă modulul Trusted Platform Module este disponibil și funcțional, veți găsi acolo informații despre producător și versiunea specificației. Pentru Windows 11, TPM 2.0 este o cerință minimă.

Dacă Windows nu afișează un TPM compatibil, acest lucru nu înseamnă neapărat că hardware-ul lipsește. Microsoft precizează că TPM poate fi dezactivat, la unele dispozitive, în firmware-ul UEFI. În funcție de platformă, poate apărea sub denumiri precum Intel PTT sau AMD fTPM.

Pentru documentația de testare sunt de obicei suficiente trei valori: TPM prezent: da/nu, versiunea specificației și starea. Cheile sensibile sau datele de identitate nu au ce căuta într-un raport de eroare obișnuit.

5. Documentarea DirectX și a driverului grafic cu dxdiag

Deschideți comanda dxdiag apăsând tasta Windows + R. Instrumentul de diagnosticare DirectX afișează, pe lângă datele de sistem, informații despre placa grafică și driver. Pe fila Afișare sunt vizibile, printre altele, numele GPU-ului, versiunea driverului, data driverului, suportul DirectX și modul de afișare.

Aceste informații sunt deosebit de importante în cazul erorilor de afișare, al blocărilor legate de accelerarea hardware, al problemelor cu mai multe monitoare sau al diferențelor dintre mașinile de test virtuale și cele fizice. Microsoft menționează pentru Windows 11, ca cerință minimă, o placă grafică compatibilă DirectX 12 cu driver WDDM 2.0.

6. Înregistrarea unitară a CPU, RAM și a tipului de sistem

Procesorul, memoria RAM instalată și tipul de sistem se găsesc de asemenea în msinfo32 sau în Setări → Sistem → Despre. La procesor, notați, dacă este posibil, denumirea exactă a modelului, nu doar „Intel” sau „AMD”. Pentru memorie, capacitatea instalată este suficientă, cu excepția cazului în care se investighează o problemă de memorie.

Pentru testele de performanță sau de sarcină, ar trebui notat suplimentar dacă alte procese care consumă multe resurse rulează în paralel. Un rezultat de test fără context privind utilizarea hardware-ului poate fi ușor interpretat greșit.

7. Verificarea spațiului de stocare liber

Un dispozitiv poate îndeplini cerințele formale Windows și totuși să aibă prea puțin spațiu liber pentru o actualizare, date de test temporare sau o aplicație mai mare. De aceea, la erorile de instalare și actualizare, documentați nu doar dimensiunea unității, ci și spațiul liber disponibil înainte de test.

Potrivit Microsoft, Windows 11 necesită un dispozitiv de stocare de cel puțin 64 GB. Totuși, pentru teste de aplicații reproductibile, indicatorul mai relevant este spațiul liber efectiv disponibil.

Amprentă de sistem recomandată pentru rapoartele de eroare

Un șablon compact poate arăta, de exemplu, astfel:

SO: Windows 11 [ediție]
Versiune/Build: [winver]
Model dispozitiv: [msinfo32]
CPU: [model exact]
RAM: [GB]
Mod BIOS: UEFI/Legacy
Secure Boot: Activat/Dezactivat/Neacceptat
TPM: prezent, versiune [x.x]
GPU: [model]
Driver grafic: [versiune + dată]
DirectX/WDDM: [dxdiag]
Afișaj: [rezoluție / scalare]
Spațiu liber: [GB]
Data/ora testului: [dată/oră]

La compararea a două mașini, ar trebui folosit același șablon pentru ambele sisteme. Astfel, diferențele devin vizibile imediat, fără ca dezvoltatorii să fie nevoiți să parcurgă mai multe capturi de ecran.

Ce date nu ar trebui să apară în rapoarte de eroare publice?

Diagnosticarea sistemului poate conține informații care nu sunt necesare pentru analiza tehnică. Prin urmare, nu publicați numere de serie, chei de produs, date de cont, identificatori de dispozitiv, date de rețea private sau alte informații personale ori confidențiale. Verificați rapoartele de diagnosticare exportate înainte de a le distribui.

În companii se aplică suplimentar politici interne pentru jurnale și date de telemetrie. O amprentă de sistem bună conține doar datele care contribuie la reproducerea erorii.

De ce această documentație îmbunătățește reproductibilitatea

O eroare care apare doar pe un singur dispozitiv de test nu este automat aleatorie. Adesea mediul diferă printr-un detaliu: un alt build Windows, un alt driver grafic, o configurație firmware diferită, mai puțin spațiu liber sau hardware diferit. Dacă aceste diferențe sunt înregistrate structurat, un „la mine funcționează” poate deveni o ipoteză verificabilă.

Metoda este deosebit de valoroasă la testele de regresie. Salvați amprenta de sistem împreună cu rularea testului. Dacă rezultatul se schimbă după o actualizare Windows, de firmware sau de driver, se poate urmări ce variabilă de mediu s-a schimbat între rulări.

Concluzie

O documentație de testare Windows solidă nu necesită instrumente ample de la terți. Cu winver, msinfo32, tpm.msc și dxdiag pot fi înregistrate consecvent cele mai importante caracteristici de sistem. Decisivă nu este cantitatea de date, ci un șablon repetabil, utilizat identic pe toate dispozitivele de test.

Surse și documentație suplimentară

Distribuie