Kontakt & hjälp
Reproducerbara tester börjar med en noggrant dokumenterad testmiljö. På Windows-system räcker uppgiften ”Windows 11” i en felrapport oftast inte till. Build-version, firmwareläge, säkerhetsfunktioner, grafikdrivrutin och hårdvara kan påverka om ett fel uppstår och om det går att återskapa på en annan enhet. Den här guiden visar hur du samlar in de viktigaste tekniska uppgifterna för en Windows-testenhet med inbyggda verktyg – utan extra diagnosprogram.
Vilken information hör hemma i dokumentationen av en Windows-testenhet?
I många QA- och supportscenarier är sex grupper särskilt relevanta: operativsystem och build, processor och arbetsminne, firmwareläge, TPM-status, Secure Boot-status samt grafik- och drivrutinsdata. Beroende på applikationen tillkommer skärmupplösning, tillgänglig lagringskapacitet, språk, tidszon och installerade runtime-komponenter.
Syftet är inte att samla in så mycket data som möjligt. Målet är ett litet, konsekvent systemfingeravtryck som samlas in på samma sätt för varje testenhet. Det gör det mycket snabbare att upptäcka skillnader mellan en fungerande och en felaktig miljö.
1. Fastställ Windows-version och build med winver
Tryck på Windows-tangenten + R, skriv winver och bekräfta. Fönstret visar den installerade Windows-versionen och operativsystemets build. Båda värdena bör tas med i en felrapport.
Enbart utgåvan är för oprecis. Två enheter kan båda köra Windows 11 men ha olika builds eller patchnivåer. Ett beteende som uppstår efter en uppdatering kan därför bara undersökas meningsfullt om build-versionen är dokumenterad.
Notera ändå alltid även utgåvan. Om en testenhet kör Windows 11 Home, Windows 11 Pro eller Windows 11 Enterprise avgör om funktioner som BitLocker, grupprincip eller Hyper-V ens är tillgängliga – och påverkar därmed också testbeteendet.
2. Läs av central systeminformation med msinfo32
Öppna kommandot msinfo32 via Windows-tangenten + R. Systeminformation samlar många uppgifter som är användbara för tester och felanalys. Särskilt relevanta är:
- Operativsystemets namn och version
- Systemtillverkare och systemmodell
- Systemtyp
- Processor
- Installerat fysiskt minne
- BIOS-version och -datum
- BIOS-läge
- Status för ”säker start” (Secure Boot)
För reproducerbara QA-processer är det bra att föra dessa fält i en fast mall. Så undviks felrapporter där en testare dokumenterar BIOS-versionen och en annan bara Windows-utgåvan.
3. Kontrollera UEFI och Secure Boot
I msinfo32 visar fältet för BIOS-läge om enheten startade i UEFI-läge eller i ett äldre Legacy-läge. Fältet för säker start visar om Secure Boot är aktivt. Microsoft anger UEFI- och Secure Boot-stöd som en del av systemkraven för Windows 11.
Vid felsökning är denna information användbar även när den testade applikationen inte använder Secure Boot direkt. Skillnader i firmwarekonfiguration och säkerhetsstatus kan förklara varför installations-, drivrutins- eller enhetsbeteende skiljer sig mellan två i övrigt likartat utrustade datorer.
Ändra inte firmwareinställningar bara för ett test utan att förstå konsekvenserna. Om en ändring är nödvändig, dokumentera tillståndet före och efter justeringen och följ instruktionerna från enhets- eller moderkortstillverkaren.
4. Kontrollera TPM-versionen med tpm.msc
Tryck på Windows-tangenten + R, skriv tpm.msc och öppna TPM-hanteringen. Om Trusted Platform Module är tillgängligt och driftklart hittar du där tillverkarinformation och specifikationsversionen. För Windows 11 är TPM 2.0 ett minimikrav.
Om Windows inte visar någon kompatibel TPM betyder det inte alltid att hårdvaran saknas. Microsoft påpekar att TPM på vissa enheter kan vara inaktiverat i UEFI-firmware. Beroende på plattform kan det till exempel heta Intel PTT eller AMD fTPM.
För testdokumentationen räcker normalt tre värden: TPM finns: ja/nej, specifikationsversion och status. Känsliga nyckel- eller identitetsuppgifter hör inte hemma i en vanlig felrapport.
5. Dokumentera DirectX och grafikdrivrutin med dxdiag
Öppna kommandot dxdiag via Windows-tangenten + R. DirectX-diagnosverktyget visar, förutom systemdata, även information om grafikenheten och drivrutinen. På fliken Skärm syns bland annat GPU-namn, drivrutinsversion, drivrutinsdatum, DirectX-stöd och visningsläge.
Dessa uppgifter är särskilt viktiga vid visningsfel, kraschar som rör hårdvaruacceleration, problem med flera bildskärmar eller skillnader mellan virtuella och fysiska testmaskiner. Microsoft anger för Windows 11 en DirectX 12-kompatibel grafikenhet med WDDM 2.0-drivrutin som minimikrav.
6. Registrera CPU, RAM och systemtyp på ett enhetligt sätt
Processor, installerat RAM-minne och systemtyp hittar du också i msinfo32 eller under Inställningar → System → Om. Notera för CPU:n helst den exakta modellbeteckningen i stället för bara ”Intel” eller ”AMD”. För arbetsminnet räcker den installerade kapaciteten, så länge inget minnesproblem undersöks.
Vid prestanda- eller belastningstester bör man dessutom notera om andra resurskrävande processer körs parallellt. Ett testresultat utan kontext om hårdvarubelastningen kan lätt feltolkas.
7. Kontrollera ledigt lagringsutrymme
En enhet kan uppfylla Windows formella krav och ändå ha för lite ledigt utrymme för en uppdatering, tillfälliga testdata eller en större applikation. Dokumentera därför vid installations- och uppdateringsfel inte bara diskstorleken, utan även det lediga utrymmet före testet.
Windows 11 kräver enligt Microsoft en lagringsenhet på minst 64 GB. För reproducerbara applikationstester är det dock det faktiskt tillgängliga lediga utrymmet som är det mer relevanta måttet.
Rekommenderat systemfingeravtryck för felrapporter
En kompakt mall kan till exempel se ut så här:
OS: Windows 11 [utgåva]
Version/build: [winver]
Enhetsmodell: [msinfo32]
CPU: [exakt modell]
RAM: [GB]
BIOS-läge: UEFI/Legacy
Secure Boot: På/Av/Stöds ej
TPM: finns, version [x.x]
GPU: [modell]
Grafikdrivrutin: [version + datum]
DirectX/WDDM: [dxdiag]
Skärm: [upplösning / skalning]
Ledigt utrymme: [GB]
Testtidpunkt: [datum/tid]Vid jämförelse mellan två maskiner bör samma mall användas för båda systemen. Skillnader blir då direkt synliga, utan att utvecklare behöver söka igenom flera skärmdumpar.
Vilka uppgifter bör inte finnas i offentliga felrapporter?
Systemdiagnostik kan innehålla information som inte behövs för den tekniska analysen. Publicera därför inga serienummer, produktnycklar, kontouppgifter, enhets-id, privata nätverksuppgifter eller annan personlig eller konfidentiell information. Kontrollera exporterade diagnosrapporter innan du delar dem.
I företag gäller dessutom interna riktlinjer för loggar och telemetridata. Ett bra systemfingeravtryck innehåller bara data som bidrar till att återskapa felet.
Varför denna dokumentation förbättrar reproducerbarheten
Ett fel som bara uppstår på en enda testenhet är inte automatiskt slumpmässigt. Ofta skiljer sig miljön i en detalj: en annan Windows-build, en annan grafikdrivrutin, en avvikande firmwarekonfiguration, mindre ledigt utrymme eller annan hårdvara. Om dessa skillnader registreras strukturerat kan ett ”det fungerar hos mig” bli en testbar hypotes.
Metoden är särskilt värdefull vid regressionstester. Spara systemfingeravtrycket tillsammans med testkörningen. Om resultatet ändras efter en Windows-, firmware- eller drivrutinsuppdatering går det att spåra vilken miljövariabel som ändrats mellan körningarna.
Slutsats
En hållbar Windows-testdokumentation kräver inga omfattande tredjepartsverktyg. Med winver, msinfo32, tpm.msc och dxdiag kan de viktigaste systemegenskaperna registreras konsekvent. Avgörande är inte mängden data utan en repeterbar mall som används på samma sätt på alla testenheter.
