Kontakt & hjælp
Reproducerbare test starter med et omhyggeligt dokumenteret testmiljø. På Windows-systemer er angivelsen ”Windows 11” i en fejlrapport som regel ikke nok. Build-version, firmwaretilstand, sikkerhedsfunktioner, grafikdriver og hardware kan påvirke, om en fejl opstår, og om den kan reproduceres på en anden enhed. Denne guide viser, hvordan du indsamler de vigtigste tekniske data for en Windows-testenhed med indbyggede værktøjer – uden ekstra diagnosesoftware.
Hvilke oplysninger hører hjemme i dokumentationen af en Windows-testenhed?
I mange QA- og supportscenarier er seks grupper særligt relevante: operativsystem og build, processor og hukommelse, firmwaretilstand, TPM-status, Secure Boot-status samt grafik- og driverdata. Afhængigt af applikationen kommer skærmopløsning, tilgængelig lagerkapacitet, sprog, tidszone og installerede runtime-komponenter i tillæg.
Formålet er ikke at indsamle så mange data som muligt. Målet er et lille, konsistent systemfingeraftryk, der indsamles på samme måde på hver testenhed. Det gør det langt hurtigere at få øje på forskelle mellem et velfungerende og et fejlbehæftet miljø.
1. Registrér Windows-version og build med winver
Tryk på Windows-tasten + R, skriv winver og bekræft. Vinduet viser den installerede Windows-version og operativsystemets build. Begge værdier bør medtages i en fejlrapport.
Udgaven alene er for upræcis. To enheder kan begge køre Windows 11, men have forskellige builds eller patchniveauer. En adfærd, der opstår efter en opdatering, kan derfor kun undersøges meningsfuldt, hvis buildet er dokumenteret.
Notér alligevel altid også udgaven. Om en testenhed kører Windows 11 Home, Windows 11 Pro eller Windows 11 Enterprise, afgør om funktioner som BitLocker, gruppepolitik eller Hyper-V overhovedet er tilgængelige – og påvirker dermed også testadfærden.
2. Aflæs centrale systemoplysninger med msinfo32
Åbn kommandoen msinfo32 via Windows-tasten + R. Systemoplysninger samler mange data, der er nyttige til test og fejlanalyse. Særligt relevante er:
- Operativsystemets navn og version
- Systemproducent og systemmodel
- Systemtype
- Processor
- Installeret fysisk hukommelse
- BIOS-version og -dato
- BIOS-tilstand
- Status for ”sikker opstart” (Secure Boot)
For reproducerbare QA-processer anbefales det at føre disse felter i en fast skabelon. Sådan undgås fejlrapporter, hvor én tester dokumenterer BIOS-versionen, og en anden kun Windows-udgaven.
3. Kontrollér UEFI og Secure Boot
I msinfo32 viser feltet for BIOS-tilstand, om enheden startede i UEFI-tilstand eller i en ældre Legacy-tilstand. Feltet for sikker opstart viser, om Secure Boot er aktiv. Microsoft angiver UEFI- og Secure Boot-understøttelse som en del af systemkravene til Windows 11.
Ved fejlsøgning er denne information nyttig, selv når den testede applikation ikke direkte bruger Secure Boot. Forskelle i firmwarekonfiguration og sikkerhedstilstand kan forklare, hvorfor installations-, driver- eller enhedsadfærd afviger mellem to ellers ensartet udstyrede maskiner.
Ændr ikke firmwareindstillinger blot for én test uden at forstå konsekvenserne. Hvis en ændring er nødvendig, skal du dokumentere tilstanden før og efter justeringen og følge vejledningen fra enheds- eller bundkortproducenten.
4. Kontrollér TPM-versionen med tpm.msc
Tryk på Windows-tasten + R, skriv tpm.msc og åbn TPM-administration. Hvis Trusted Platform Module er tilgængelig og driftsklar, finder du der producentoplysninger og specifikationsversionen. For Windows 11 er TPM 2.0 et minimumskrav.
Viser Windows ikke et kompatibelt TPM, betyder det ikke nødvendigvis, at hardwaren mangler. Microsoft påpeger, at TPM på visse enheder kan være deaktiveret i UEFI-firmwaren. Afhængigt af platformen kan det for eksempel hedde Intel PTT eller AMD fTPM.
Til testdokumentationen er normalt tre værdier tilstrækkelige: TPM til stede: ja/nej, specifikationsversion og status. Følsomme nøgle- eller identitetsdata hører ikke hjemme i en almindelig fejlrapport.
5. Dokumentér DirectX og grafikdriveren med dxdiag
Åbn kommandoen dxdiag via Windows-tasten + R. DirectX-diagnoseværktøjet viser ud over systemdata også oplysninger om grafikenheden og driveren. På fanen Skærm ses blandt andet GPU-navn, driverversion, driverdato, DirectX-understøttelse og skærmtilstand.
Disse oplysninger er særligt vigtige ved visningsfejl, nedbrud relateret til hardwareacceleration, problemer med flere skærme eller forskelle mellem virtuelle og fysiske testmaskiner. Microsoft angiver for Windows 11 en DirectX 12-kompatibel grafikenhed med WDDM 2.0-driver som minimumskrav.
6. Registrér CPU, RAM og systemtype ensartet
Processor, installeret RAM og systemtype finder du også i msinfo32 eller under Indstillinger → System → Om. Ved CPU'en bør du helst notere den præcise modelbetegnelse i stedet for blot ”Intel” eller ”AMD”. For arbejdshukommelsen er den installerede kapacitet tilstrækkelig, medmindre der undersøges et hukommelsesproblem.
Til performance- eller belastningstest bør det desuden noteres, om andre ressourcekrævende processer kører parallelt. Et testresultat uden kontekst om hardwarebelastningen kan let blive fejlfortolket.
7. Kontrollér ledig lagerplads
En enhed kan opfylde de formelle Windows-krav og alligevel have for lidt ledig plads til en opdatering, midlertidige testdata eller en større applikation. Dokumentér derfor ved installations- og opdateringsfejl ikke kun drevstørrelsen, men også den ledige plads før testen.
Windows 11 kræver ifølge Microsoft en lagerenhed på mindst 64 GB. For reproducerbare applikationstest er det dog den faktisk tilgængelige ledige plads, der er det mere sigende tal.
Anbefalet systemfingeraftryk til fejlrapporter
En kompakt skabelon kan for eksempel se sådan ud:
OS: Windows 11 [udgave]
Version/build: [winver]
Enhedsmodel: [msinfo32]
CPU: [præcis model]
RAM: [GB]
BIOS-tilstand: UEFI/Legacy
Secure Boot: Til/Fra/Ikke understøttet
TPM: til stede, version [x.x]
GPU: [model]
Grafikdriver: [version + dato]
DirectX/WDDM: [dxdiag]
Skærm: [opløsning / skalering]
Ledig plads: [GB]
Testtidspunkt: [dato/klokkeslæt]Ved en sammenligning mellem to maskiner bør samme skabelon bruges til begge systemer. Forskelle bliver dermed straks synlige, uden at udviklere skal gennemsøge flere skærmbilleder.
Hvilke data bør ikke indgå i offentlige fejlrapporter?
Systemdiagnostik kan indeholde oplysninger, der ikke er nødvendige for den tekniske analyse. Offentliggør derfor ikke serienumre, produktnøgler, kontooplysninger, enheds-id'er, private netværksdata eller andre personlige eller fortrolige oplysninger. Kontrollér eksporterede diagnoserapporter, før du deler dem.
I virksomheder gælder desuden interne retningslinjer for logs og telemetridata. Et godt systemfingeraftryk indeholder kun data, der bidrager til at reproducere fejlen.
Hvorfor denne dokumentation forbedrer reproducerbarheden
En fejl, der kun opstår på én enkelt testenhed, er ikke automatisk tilfældig. Ofte adskiller miljøet sig på ét punkt: et andet Windows-build, en anden grafikdriver, en afvigende firmwarekonfiguration, mindre ledig plads eller anden hardware. Hvis disse forskelle registreres struktureret, kan et ”det virker hos mig” blive til en testbar hypotese.
Metoden er særligt værdifuld ved regressionstest. Gem systemfingeraftrykket sammen med testkørslen. Hvis resultatet ændrer sig efter en Windows-, firmware- eller driveropdatering, kan det spores, hvilken miljøvariabel der ændrede sig mellem kørslerne.
Konklusion
En solid Windows-testdokumentation kræver ikke omfattende tredjepartsværktøjer. Med winver, msinfo32, tpm.msc og dxdiag kan de vigtigste systemegenskaber registreres konsistent. Det afgørende er ikke mængden af data, men en gentagelig skabelon, der bruges identisk på alle testenheder.
