En stor ødelagt frelse er bevis, ikke en forklaring
Når en lagre mislykkes å laste, forsvinner en søk, eller en migrasjon bryter en spillregel, den første gjenstanden kan være enorm: hundrevis av felt, hekkede samlinger, en lang handlingshistorie, et innholdsbilde og et miljø som ikke eksisterer lenger. Den gjenstanden er verdifull fordi den representerer problemet. Det er vanskelig fordi det gir en utvikler mye mer informasjon enn de kan grunne til på en gang. Å lese den linje etter linje produserer ofte gjetninger i stedet for en forklaring.
Deltafeilsøking endrer målet. I stedet for å be en person om å oppdage den ene relevante verdien, spør en deterministisk prediksjon om en kandidat fortsatt demonstrerer feilen. Deretter fjerne eller forenkle deler av staten mens prediksjonen fortsatt er sant. Det endelige resultatet er et minimalt regresjonsfall: liten nok til å gjennomgå, stabil nok til å spille på nytt, og eksplisitt om den invariant som forblir brutt.
Minimal betyr ikke visuelt liten eller universellt minste. Det nyttige målet er et materialet redusert kontraeksempel under en avgrenset kostnad. En reduserer kan stoppe når ingen hele gruppe kan fjernes, når et utførelsesbudsjett er utmattet, eller når fixturen er forståelig nok til å bli en regresjonstest. Den bevarte egenskapen betyr mer enn en abstrakt optimal.
Etablere reprodusabilitet før reduksjon
Reduksjon virker bare når feilen gjentas. Først fange det nøyaktige prediksjonen: kaster den gjeldende lasteren en klassifisert feil, gjør en invariant retur falsk, er en resulterende tilstand forskjellig fra det forventede utfallet, eller produserer en handlingssekvens et ugyldig bidrag? Unngå å bruke en vag predikasjon som \"spillet ser feil ut.. Prediken må returnere det samme svaret for de samme inngangene, eller redusereren vil jage støy.
Record miljøet sammen med kandidaten: program bygge eller forplikte, migrere versjon, adapter versjon, innhold og konfigurasjon øyeblikksbilde, deterministiske frø, plattform antakelser og start fixtur hash. Hvis en live klokke, tilfeldig kilde, fjernkonfigurasjon hente eller bakgrunnsarbeider kan endre resultatet, erstatte det med en deterministisk test grense eller registrere det som en eksplisitt begrensning. Reduseren må ikke i hemmelighet teste et nytt miljø på hvert forsøk.
For handling-sekvens feil, bevare den opprinnelige tilstanden og de bestilte handlingene separat. En endelig tilstand kan skjule operasjonen som produserte den. En sekvens fixtur kan uttrykke \"start fra denne profilen, utføre disse syv forespørsler, så invariant mislykkes.\" Denne separasjonen gjør det mulig å krympe felt, samlinger og handlinger uten å forvirre én type bevis for en annen.
Reduser felt og samlinger i partisjoner
Start med grove partisjoner. Del det øverste nivået lagret i feltgrupper, fjern en gruppe fra en arbeidskopi, og kjør prediksjonen. Hvis feilen vedvarer, hold fjerningen; hvis den forsvinner, gjenopprett gruppen og subdivider den. Dette er mer effektivt enn å slette ett felt om gangen fra et stort objekt. Fortsett å hekke poster og samlinger når en relevant region er identifisert.
Innsamlinger trenger spesiell omsorg. Oppfinnelser, søkeposter, tellere og hendelseshistorikk kan referere til hverandre. Fjerning av en oppføring kan endre listeindekser, kapasitetsregler eller aggregerte balanser. Normalisere bestilling der ordren ikke er meningsfull, bevare stabile identifikatorer der referanser krever dem, og oppgi om et manglende element bør være fraværende, null eller representert av en eksplisitt arvelig reserve. En reduserer bør ikke gjøre en reell migrasjonsfeil til en tolkefeil forårsaket av feilutformet testinndata.
Bruk verdien krymping etter strukturell reduksjon. Flytt heltalls mot null eller en viktig grense, forkorte strenger, erstatte en lang identifikator med en sikker testidentifikator, og redusere tidsstempler til en stabil epoke bare når deres nøyaktige verdi ikke er betingelsen under test. Hver forenkling må holde prediksjonen sant. Dette avslører ofte at en tilsynelatende kompleks profil feil er virkelig \"en pensjonert element ID pluss en full beholdning\" eller \"en negativ teller etter en hoppet versjon.\"
Reduser handlingssekvenser uten å endre deres mening
Noen feil oppstår bare etter tid: et kjøp forsøk igjen etter en reconnect, en lagre etter en konfigurasjonsoppdatering eller en migrasjon etter en avbrutt tutorial. Bruk samme partisjonsidé til handlinger. Fjern en sammenhengende halvdel av sekvensen, replay og hold fjerningen hvis invarianten fortsatt mislykkes. Deretter subdivid. Bevar nødvendige oppsettshandlinger, men utfordrer tilfeldig navigasjon, gjentatte leser og urelaterte mutasjoner.
Handlinger bør ha stabile parametere og resultatforventninger. En reduserer som erstatter hver forespørsel med en ny tilfeldig transaksjons-ID er ikke lenger å teste den opprinnelige remantikken. En reduserer som fjerner den opprinnelige funksjonsflag-lasten kan endre konfigurasjonskonteksten. Record action-identitet, relevante innganger, pålitelig mot upålitelig kilde, og det punkt hvor invarianten er kontrollert. Dette gjør den endelige sekvensen nyttig for både utviklere og QA.
Når en sekvens avhenger av konvaluta, velg en deterministisk tidsplan. Ta opp rekkefølgen der arbeidere eller simulerte klienter når kritiske grenser. Hvis feilen bare oppstår under et løp, kan en test trenge en kontrollert barriere i stedet for å timing-avhengige søvnsamtaler. Målet er ikke å late som konvaluta er enkelt; det er å gjøre den observerte interleeving reprodusible nok til å resonnere om.
Bevar den krenkede invarianten i den endelige gjenstanden
En liten fixtur uten en påstand blir en annen mystisk fil. Lagre den krenkede invariant ved siden av fixturen i klare termer: duplisert rett for én transaksjonsidentitet, ukjent katalogreferanse etter migrasjon, negativ valuta, utilgjengelig fullført søk eller semantisk feil etter en rundtur. Inkluder den forventede klassifiseringen og den observerte. Fixturen bør mislykkes av en grunn, ikke bare fordi en funksjon returnerer falsk.
Sammenlign før og etter tilstanden semantisk. En rå diff kan inneholde omskrevne tidsstempler, omorganiserte tabeller, genererte IDer eller serielisasjonsformatering. En semantisk diff markerer verdier som påvirker invarianten. Det kan rapportere at et element endret fra en gyldig arvlig tilbakefall til en ukjent ID, eller at en balanse ble inkrementert to ganger for den samme ledgernøkkelen. Hold normalizeren smal og dokumentert; en bred normalizer kan slette den meget defekt som redusereren er ment å bevare.
Skriv et replay manifest med fixturstien, kildehash, redusert hash, miljøfingeravtrykk, deterministisk frø, handlingssekvens hvis noen, predikere navn og forventet resultat. Dette manifestet lar en annen person omkjøre saken uten tilgang til den opprinnelige overdimensjonelle tilstanden. Det gjør også fixturen egnet for CI, der et minimalt tilfelle bør være raskt og klart i stedet for avhengig av en privat lokal maskin.
Vet når reduksjonen bør stoppe
Hver prediksjon kjører kostnader tid. Noen migrasjoner er langsomme; noen scenarier trenger serviceadaptere; noen feilforhold er flaky til et miljø er fikset. Sett budsjett for forsøk, veggtid og gjenstander teller. Stopp når fixturen er liten nok til å forklare problemet, når ingen partisjon kan fjernes uten å miste feilen, eller når det gjenværende arbeidet krever domenevurdering i stedet for mekanisk krymping.
Reduksjon har grenser. Det kan ikke bestemme om et arveelement skal kartlegge til en erstatning, om en pensjonert søk trenger kompensasjon, eller om en lagret verdi er lovlig i en omdesignet økonomi. Dette er produktbeslutninger. Det kan også trygt redusere krypterte eller sensitive data ved å kopiere det til brede verktøy. I disse tilfellene, skape en syntetisk ekvivalent som bevarer strukturtilstanden, eller holde den begrensede undersøkelsen innenfor den passende tilgangsgrensen.
Ikke publisere en rå spillertilstand som en regresjonsarrangement. Stripnavn, kontaktinformasjon, mottaksdata, enhetsidentifikatorer, tilgangssymboler, og ethvert felt som ikke trengs for prediksjonen. En minimal fixtur er en mulighet til å forbedre personvernet samt diagnostisering. Den endelige gjenstanden bør være trygg å inkludere i prosjektets testkorpus og nyttig nok til å hindre gjentaelse.
Praktisk sjekkliste
- Definer en deterministisk feil predikasjon før du fjerner noen tilstand.
- Opptak programmet, adapter, innhold, konfigurasjon, frø og fixture miljø.
- Hold opprinnelig tilstand og handlingssekvens separat når atferden utfolder seg over tid.
- Reduser toppnivå grupper først, deretter hekkede felt, samlinger og verdier.
- Bevar referanser og strukturell gyldighet mens utfordrende semantisk relevans.
- Bruk en kontrollert konvaluta tidsplan i stedet for timing-avhengig retries.
- Oppbevar den krenkede invarianten, forventet klassifisering, semantisk diff og replay manifesterer seg med resultatet.
- Stopp på et nyttig avgrenset kontradøme; ikke optimalisere på ubestemt tid for teoretisk minimalitet.
- Redakt eller syntetisere sensitive data før en fixtur går rutinemessige tester.
Vanlige spørsmål
Er delta-feilsøking bare for krasj?
Nei. Predikasjonen kan være en krasj, men det kan også være et krenket spill invariant, et feil rettighetstall, en mislykket spare-last rundtur, en avvist migrasjonsklassifisering, eller en feil mellom forventet og observert tilstand. Det er mest nyttig når en kompleks inngang på en pålitelig måte produserer et resultat som ikke bør forekomme.
Hva om feilen er intermitterende?
Først reduserer ikke-determinismen. Fiks frø, fange konfigurasjon, isolere tid og nettverksgrenser, og kontroll konkular. Hvis utfallet forblir probabilistisk, bruk en terskelbasert prediksjon bare med forsiktighet og registrere den begrensningen. Et stabilt mindre scenario er vanligvis mer verdifullt enn en stor flaky fixtur.
Kan en reduserer kjøres mot produksjonsdata?
Rutinreduksjon bør ikke. Bruk syntetiske eller omdelte armaturer og et kontrollert miljø. En begrenset hendelsesundersøkelse kan trenge beskyttede bevis, men det er en separat operasjonsprosess med tilgangskontroller, oppbevaringsregler og gjennomgang. Ikke gjør regresjonspakken til en kopi av spillerdata.
Hva hevder Persistium her?
Persistium er i utvikling som en lokal-første pålitelighet produktfamilie. Denne noten presenterer en generelt nyttig reduksjon arbeidsflyt og hevder ikke at et offentlig produkt automatisk diagnostiserer vilkårlige lagrer, har observert kundefeil, eller driver en vert analyse tjeneste.
