Contacto e ajuda
Testes reprodutíveis começam com um ambiente de teste documentado de forma limpa. Nos sistemas Windows, a indicação «Windows 11» num relatório de erro normalmente não é suficiente. A versão de build, o modo de firmware, as funcionalidades de segurança, o controlador gráfico e o hardware podem influenciar se um erro ocorre e se é reprodutível num segundo dispositivo. Este guia mostra como recolher os dados técnicos mais importantes de um dispositivo de teste Windows utilizando apenas ferramentas integradas – sem software de diagnóstico adicional.
Que informações devem constar na documentação de um dispositivo de teste Windows?
Para muitos cenários de QA e suporte, seis grupos de informação são particularmente relevantes: sistema operativo e build, processador e memória, modo de firmware, estado do TPM, estado do Secure Boot, bem como dados gráficos e de controlador. Consoante a aplicação, acrescentam-se a resolução do ecrã, a capacidade de armazenamento disponível, o idioma, o fuso horário e os componentes de runtime instalados.
O objetivo não é recolher o máximo de dados possível. O objetivo é uma impressão digital de sistema pequena e consistente, recolhida da mesma forma em cada dispositivo de teste. Isto permite identificar muito mais rapidamente as diferenças entre um ambiente funcional e um ambiente com falhas.
1. Registar a versão e o build do Windows com winver
Prima tecla Windows + R, escreva winver e confirme. A janela mostra a versão do Windows instalada e o build do sistema operativo. Ambos os valores devem ser incluídos num relatório de erro.
A edição por si só é demasiado imprecisa. Dois dispositivos podem ambos utilizar o Windows 11, mas ter builds ou níveis de atualização diferentes. Um comportamento que surge após uma atualização só pode, por isso, ser investigado de forma útil se o build estiver documentado.
Ainda assim, anote sempre também a edição. O facto de um dispositivo de teste funcionar com Windows 11 Home, Windows 11 Pro ou Windows 11 Enterprise determina se funcionalidades como o BitLocker, as políticas de grupo ou o Hyper-V estão sequer disponíveis – e influencia, por isso, também o comportamento durante os testes.
2. Consultar os dados centrais do sistema com msinfo32
Abra o comando msinfo32 através de tecla Windows + R. As informações do sistema reúnem muitos dados úteis para testes e análise de erros. São particularmente relevantes:
- Nome e versão do sistema operativo
- Fabricante e modelo do sistema
- Tipo de sistema
- Processador
- Memória física instalada
- Versão e data do BIOS
- Modo do BIOS
- Estado do «arranque seguro» (Secure Boot)
Para processos de QA reprodutíveis, é aconselhável manter estes campos num modelo fixo. Assim evitam-se relatórios de erro em que um testador documenta a versão do BIOS e outro apenas a edição do Windows.
3. Verificar o UEFI e o Secure Boot
Em msinfo32, o campo relativo ao modo do BIOS mostra se o dispositivo arrancou em modo UEFI ou num modo Legacy mais antigo. O campo relativo ao arranque seguro mostra se o Secure Boot está ativo. A Microsoft indica a compatibilidade com UEFI e Secure Boot como parte dos requisitos de sistema do Windows 11.
Para a resolução de problemas, esta informação é útil mesmo quando a aplicação testada não utiliza diretamente o Secure Boot. Diferenças na configuração do firmware e no estado de segurança podem explicar por que motivo o comportamento de instalação, do controlador ou do dispositivo difere entre duas máquinas, de resto, equipadas de forma semelhante.
Não altere as definições de firmware apenas para um teste sem compreender as consequências. Se uma alteração for necessária, documente o estado antes e depois do ajuste e siga as instruções do fabricante do dispositivo ou da placa-mãe.
4. Verificar a versão do TPM com tpm.msc
Prima tecla Windows + R, escreva tpm.msc e abra a gestão do TPM. Se o Trusted Platform Module estiver disponível e operacional, encontrará aí as informações do fabricante e a versão da especificação. Para o Windows 11, o TPM 2.0 é um requisito mínimo.
Se o Windows não mostrar um TPM compatível, isso não significa necessariamente que o hardware esteja em falta. A Microsoft refere que, nalguns dispositivos, o TPM pode estar desativado no firmware UEFI. Consoante a plataforma, pode surgir com designações como Intel PTT ou AMD fTPM.
Para a documentação de testes, bastam normalmente três valores: TPM presente: sim/não, versão da especificação e estado. Chaves sensíveis ou dados de identidade não devem constar de um relatório de erro normal.
5. Documentar o DirectX e o controlador gráfico com dxdiag
Abra o comando dxdiag através de tecla Windows + R. A Ferramenta de Diagnóstico do DirectX mostra, além dos dados do sistema, informações sobre a unidade gráfica e o controlador. No separador Visualização são visíveis, entre outros dados, o nome da GPU, a versão do controlador, a data do controlador, o suporte a DirectX e o modo de visualização.
Estes dados são especialmente importantes em erros de visualização, falhas relacionadas com aceleração de hardware, problemas com vários monitores ou diferenças entre máquinas de teste virtuais e físicas. A Microsoft indica, para o Windows 11, uma unidade gráfica compatível com DirectX 12 e controlador WDDM 2.0 como requisito mínimo.
6. Registar o CPU, a RAM e o tipo de sistema de forma uniforme
O processador, a RAM instalada e o tipo de sistema também se encontram em msinfo32 ou em Definições → Sistema → Acerca de. Ao registar o CPU, anote, se possível, a designação exata do modelo em vez de apenas «Intel» ou «AMD». Quanto à memória, a capacidade instalada é suficiente, desde que não esteja a ser investigado um problema de memória.
Para testes de desempenho ou de carga, deve ainda registar-se se outros processos que consomem muitos recursos estão a ser executados em paralelo. Um resultado de teste sem contexto sobre a utilização do hardware pode facilmente ser mal interpretado.
7. Verificar o espaço de armazenamento livre
Um dispositivo pode cumprir os requisitos formais do Windows e, ainda assim, ter pouco espaço livre para uma atualização, dados de teste temporários ou uma aplicação maior. Por isso, em caso de erros de instalação ou atualização, documente não só o tamanho da unidade, mas também o espaço livre disponível antes do teste.
Segundo a Microsoft, o Windows 11 exige um dispositivo de armazenamento com pelo menos 64 GB. No entanto, para testes de aplicações reprodutíveis, o indicador mais significativo é o espaço livre efetivamente disponível.
Impressão digital de sistema recomendada para relatórios de erro
Um modelo compacto pode, por exemplo, ter o seguinte aspeto:
SO: Windows 11 [edição]
Versão/Build: [winver]
Modelo do dispositivo: [msinfo32]
CPU: [modelo exato]
RAM: [GB]
Modo BIOS: UEFI/Legacy
Secure Boot: Ativado/Desativado/Não suportado
TPM: presente, versão [x.x]
GPU: [modelo]
Controlador gráfico: [versão + data]
DirectX/WDDM: [dxdiag]
Ecrã: [resolução / escala]
Espaço livre: [GB]
Data/hora do teste: [data/hora]Ao comparar duas máquinas, deve utilizar-se o mesmo modelo para ambos os sistemas. As diferenças tornam-se assim imediatamente visíveis, sem que os programadores tenham de percorrer várias capturas de ecrã.
Que dados não devem constar de relatórios de erro públicos?
O diagnóstico do sistema pode conter informações que não são necessárias para a análise técnica. Por isso, não publique números de série, chaves de produto, dados de conta, identificadores de dispositivo, dados de rede privados ou outras informações pessoais ou confidenciais. Verifique os relatórios de diagnóstico exportados antes de os partilhar.
Nas empresas aplicam-se ainda políticas internas para registos e dados de telemetria. Uma boa impressão digital de sistema contém apenas os dados que contribuem para reproduzir o erro.
Por que motivo esta documentação melhora a reprodutibilidade
Um erro que só aparece num único dispositivo de teste não é automaticamente aleatório. Frequentemente, o ambiente difere num pormenor: um build diferente do Windows, um controlador gráfico diferente, uma configuração de firmware diferente, menos espaço livre ou hardware diferente. Se estas diferenças forem registadas de forma estruturada, um «funciona no meu computador» pode transformar-se numa hipótese testável.
Este método é particularmente valioso nos testes de regressão. Guarde a impressão digital de sistema juntamente com a execução do teste. Se o resultado mudar após uma atualização do Windows, do firmware ou de um controlador, torna-se possível identificar qual a variável de ambiente que mudou entre as execuções.
Conclusão
Uma documentação de testes Windows sólida não requer ferramentas extensas de terceiros. Com winver, msinfo32, tpm.msc e dxdiag, é possível registar de forma consistente as características de sistema mais importantes. O decisivo não é a quantidade de dados, mas sim um modelo repetível, utilizado de forma idêntica em todos os dispositivos de teste.
