Contatto & aiuto
Test riproducibili iniziano con un ambiente di test documentato in modo pulito. Nei sistemi Windows, l’indicazione «Windows 11» in una segnalazione di bug di solito non basta. La versione del build, la modalità del firmware, le funzioni di sicurezza, il driver grafico e l’hardware possono influire sul verificarsi di un errore e sulla sua riproducibilità su un secondo dispositivo. Questa guida mostra come rilevare i dati tecnici più importanti di un dispositivo di test Windows usando solo gli strumenti integrati – senza software di diagnostica aggiuntivo.
Quali informazioni devono comparire nella documentazione di un dispositivo di test Windows?
Per molti scenari di QA e assistenza, sei gruppi di informazioni sono particolarmente rilevanti: sistema operativo e build, processore e memoria, modalità firmware, stato del TPM, stato del Secure Boot, oltre ai dati su scheda grafica e driver. A seconda dell’applicazione si aggiungono risoluzione dello schermo, capacità di archiviazione disponibile, lingua, fuso orario e componenti di runtime installati.
Lo scopo non è raccogliere quanti più dati possibile. L’obiettivo è un’impronta di sistema piccola e coerente, rilevata allo stesso modo su ogni dispositivo di test. Questo permette di individuare molto più rapidamente le differenze tra un ambiente funzionante e uno difettoso.
1. Rilevare versione e build di Windows con winver
Premere tasto Windows + R, digitare winver e confermare. La finestra mostra la versione di Windows installata e il build del sistema operativo. Entrambi i valori dovrebbero essere riportati in una segnalazione di bug.
L’edizione da sola è troppo imprecisa. Due dispositivi possono usare entrambi Windows 11 ma avere build o livelli di patch diversi. Un comportamento che compare dopo un aggiornamento può quindi essere analizzato in modo utile solo se il build è documentato.
Annotate comunque sempre anche l’edizione. Se un dispositivo di test utilizza Windows 11 Home, Windows 11 Pro oppure Windows 11 Enterprise determina se funzioni come BitLocker, i criteri di gruppo o Hyper-V sono addirittura disponibili – e influisce quindi anche sul comportamento durante i test.
2. Rilevare i dati di sistema principali con msinfo32
Aprite il comando msinfo32 tramite tasto Windows + R. Le informazioni di sistema raccolgono molti dati utili per i test e l’analisi degli errori. Sono particolarmente rilevanti:
- Nome e versione del sistema operativo
- Produttore e modello del sistema
- Tipo di sistema
- Processore
- Memoria fisica installata
- Versione e data del BIOS
- Modalità BIOS
- Stato dell’«avvio sicuro» ossia Secure Boot
Per processi di QA riproducibili è consigliabile tenere questi campi in un modello fisso. Così si evitano segnalazioni di bug in cui un tester documenta la versione del BIOS e un altro solo l’edizione di Windows.
3. Verificare UEFI e Secure Boot
In msinfo32, il campo relativo alla modalità BIOS indica se il dispositivo si è avviato in modalità UEFI o in una modalità Legacy meno recente. Il campo relativo all’avvio sicuro indica se il Secure Boot è attivo. Microsoft indica la capacità UEFI e Secure Boot come parte dei requisiti di sistema di Windows 11.
Per la ricerca degli errori questa informazione è utile anche quando l’applicazione testata non utilizza direttamente il Secure Boot. Differenze nella configurazione del firmware e nello stato di sicurezza possono spiegare perché il comportamento di installazione, driver o dispositivo differisce tra due macchine altrimenti equipaggiate in modo simile.
Non modificate le impostazioni del firmware solo per un test senza comprenderne le conseguenze. Se una modifica è necessaria, documentate lo stato prima e dopo la modifica e seguite le istruzioni del produttore del dispositivo o della scheda madre.
4. Controllare la versione del TPM con tpm.msc
Premere tasto Windows + R, digitare tpm.msc e aprire la gestione del TPM. Se il Trusted Platform Module è disponibile e operativo, qui troverete le informazioni del produttore e la versione della specifica. Per Windows 11, TPM 2.0 è un requisito minimo.
Se Windows non mostra alcun TPM compatibile, ciò non significa necessariamente che l’hardware manchi. Microsoft segnala che su alcuni dispositivi il TPM può essere disattivato nel firmware UEFI. A seconda della piattaforma può comparire con denominazioni come Intel PTT o AMD fTPM.
Per la documentazione dei test bastano di norma tre valori: TPM presente: sì/no, versione della specifica e stato. Chiavi sensibili o dati identificativi non devono comparire in una normale segnalazione di bug.
5. Documentare DirectX e il driver grafico con dxdiag
Aprite il comando dxdiag tramite tasto Windows + R. Lo strumento di diagnostica DirectX mostra, oltre ai dati di sistema, informazioni sulla scheda grafica e sul driver. Nella scheda Display sono visibili, tra l’altro, il nome della GPU, la versione del driver, la data del driver, il supporto DirectX e la modalità di visualizzazione.
Queste informazioni sono particolarmente importanti in caso di errori di visualizzazione, arresti anomali legati all’accelerazione hardware, problemi con più monitor o differenze tra macchine di test virtuali e fisiche. Microsoft indica per Windows 11 una scheda grafica compatibile DirectX 12 con driver WDDM 2.0 come requisito minimo.
6. Rilevare in modo uniforme CPU, RAM e tipo di sistema
Processore, RAM installata e tipo di sistema si trovano anche in msinfo32 oppure in Impostazioni → Sistema → Informazioni. Per la CPU, se possibile, rilevate la denominazione esatta del modello invece di indicare solo «Intel» o «AMD». Per la memoria RAM è sufficiente la capacità installata, a meno che non si stia analizzando un problema di memoria.
Per i test di prestazioni o di carico è opportuno annotare anche se sono in esecuzione in parallelo altri processi che consumano molte risorse. Un risultato di test senza contesto sull’utilizzo dell’hardware può facilmente essere interpretato in modo errato.
7. Verificare lo spazio di archiviazione libero
Un dispositivo può soddisfare i requisiti formali di Windows e avere comunque troppo poco spazio libero per un aggiornamento, dati di test temporanei o un’applicazione più grande. In caso di errori di installazione o aggiornamento, documentate quindi non solo la dimensione dell’unità, ma anche lo spazio libero disponibile prima del test.
Secondo Microsoft, Windows 11 richiede un’unità di archiviazione di almeno 64 GB. Per test applicativi riproducibili, tuttavia, l’indicatore più significativo è lo spazio libero effettivamente disponibile.
Impronta di sistema consigliata per le segnalazioni di bug
Un modello compatto può essere strutturato ad esempio così:
SO: Windows 11 [Edizione]
Versione/Build: [winver]
Modello dispositivo: [msinfo32]
CPU: [modello esatto]
RAM: [GB]
Modalità BIOS: UEFI/Legacy
Secure Boot: Attivo/Disattivo/Non supportato
TPM: presente, versione [x.x]
GPU: [modello]
Driver grafico: [versione + data]
DirectX/WDDM: [dxdiag]
Display: [risoluzione / scalatura]
Spazio libero: [GB]
Data/ora del test: [data/ora]Nel confronto tra due macchine occorre usare lo stesso modello per entrambi i sistemi. Le differenze diventano così immediatamente visibili, senza che gli sviluppatori debbano esaminare più screenshot.
Quali dati non dovrebbero comparire in segnalazioni di bug pubbliche?
La diagnostica di sistema può contenere informazioni non necessarie per l’analisi tecnica. Non pubblicate quindi numeri di serie, chiavi di prodotto, dati dell’account, identificativi del dispositivo, dati di rete privati o altre informazioni personali o riservate. Controllate i report di diagnostica esportati prima di condividerli.
Nelle aziende si applicano inoltre linee guida interne per log e dati di telemetria. Una buona impronta di sistema contiene solo i dati che contribuiscono alla riproduzione dell’errore.
Perché questa documentazione migliora la riproducibilità
Un errore che compare solo su un singolo dispositivo di test non è automaticamente casuale. Spesso l’ambiente differisce in un dettaglio: un build Windows diverso, un driver grafico diverso, una configurazione del firmware diversa, meno spazio libero o hardware diverso. Se queste differenze vengono rilevate in modo strutturato, da un «funziona sul mio computer» si può ricavare un’ipotesi verificabile.
Il metodo è particolarmente utile nei test di regressione. Salvate l’impronta di sistema insieme all’esecuzione del test. Se il risultato cambia dopo un aggiornamento di Windows, del firmware o di un driver, diventa ricostruibile quale variabile ambientale è cambiata tra le esecuzioni.
Conclusione
Per una documentazione di test Windows solida non servono ampi strumenti di terze parti. Con winver, msinfo32, tpm.msc e dxdiag si possono rilevare in modo coerente le caratteristiche di sistema più importanti. Ciò che conta non è la quantità di dati, ma un modello ripetibile, usato in modo identico su tutti i dispositivi di test.
