Case

Testinfrastruktur for fejlscenarier med Application Verifier – casestudie

Teknisk case om, hvordan vi brugte Application Verifier til først at opbygge en testinfrastruktur for fejlscenarier og dermed forebygge, at fejlene vender tilbage.

Overblik over casen

Dette er en case, hvor vi ikke stoppede ved en enkeltstående fejlrettelse, men brugte Application Verifier til at opbygge selve testinfrastrukturen for fejlscenarier. Målet var ikke kun at finde den aktuelle fejl, men også på forhånd at skabe en tilstand, hvor det er nemt at spore den næste fejl.

Symptomer

  • Test af normale forløb alene bringer sjældent problemer i fejlscenarier frem
  • Problemer ved lav ressourcetilgængelighed og handle-fejl viser sig ofte kun under betingelser, der ligner produktionen
  • Fremgangsmåden ved fejlsøgning bliver let afhængig af enkeltpersoner

Begrænsninger

  • Det er dyrt og risikabelt for alvor at udtømme ressourcerne på en fysisk maskine
  • Vi ville tidligt få frem, hvordan tingene går i stykker omkring de native grænseflader og Win32
  • Løsningen skulle opbygges, så den også kan genbruges ved den næste fejlfinding

Hvad vi observerede

  • Verifier-indstillinger som Handles, Heaps og Low Resource Simulation
  • Spor fra fejlscenarier, herunder !htrace og page heap
  • Sammenhængen mellem vores egen lifecycle-log og Verifiers stop-oplysninger

Sådan isolerede vi fejlen

Først adskilte vi det, vi kunne følge med almindelige logfiler alene, fra det, der ikke kan ses uden Verifier. Derefter satte vi Verifier på en udførelsessti, vi havde pakket ind i et testharness, og lagde tilgangen om til tidligt at få frem fejl, der er svære at genskabe.

Sådan forbedrede vi det

  • Vi opbyggede en testinfrastruktur, der bevidst gennemløber fejlscenarier
  • Vi gjorde det muligt at observere handle- og heap-fejl i kortere løkker
  • Vi strukturerede observationspunkterne, så de nemt kan føres tilbage til senere designreviews og tiltag mod gentagelse

Ydelser, som casen hænger sammen med

Casen hænger direkte sammen med fejlfinding og årsagsanalyse, hvor fejlen genskabes, og årsagen udpeges. Den hænger også sammen med teknisk rådgivning og designreview, hvor det afklares, hvor meget af testene af fejlscenarier og af observationspunkterne der skal indarbejdes i designet.

Søg rådgivning her

Hvis denne side beskriver en udfordring, der ligner din, så bed os om rådgivning og beskriv din nuværende situation og den form for hjælp, du har brug for.

Tilbage til forsiden