Programfelsökning

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 7 april 2022; kontroller kräver 4 redigeringar .

Felsökning är ett steg i utvecklingen av ett datorprogram , där fel upptäcks, lokaliseras och elimineras. För att förstå var felet uppstod måste du:

ta reda på de aktuella värdena för variabler ;
ta reda på vilken sökväg programmet körde.

Det finns två kompletterande felsökningstekniker:

Använda debuggers - program som inkluderar ett användargränssnitt för att gå igenom programmet: sats för sats, funktion för funktion, stopp vid några rader med källkod eller när ett visst tillstånd uppnås.
Utdata från det aktuella tillståndet för programmet med hjälp av utdataoperatorer som finns på kritiska punkter i programmet - till skärmen , skrivaren , högtalaren eller till en fil . Att mata ut felsökningsinformation till en fil kallas loggning .

Platsen för felsökning i utvecklingscykeln för ett program

En typisk utvecklingscykel, som upprepas många gånger under ett programs livstid, ser ut ungefär så här:

Programmering - införande av ny funktionalitet i programmet, korrigering av befintliga fel .
Testning (manuell eller automatiserad; av en programmerare, testare eller användare; " rök ", i black box- läge eller modulärt ) - upptäckt av ett fel.
Att återskapa ett fel är att ta reda på under vilka förhållanden ett fel uppstår. Detta kan visa sig vara en knepig uppgift när man programmerar samtidiga processer och med några ovanliga buggar som kallas heisenbugs .
Debugging - Hitta orsaken till ett fel.

Verktyg

Felsökning kräver ofta hög kompetens och betydande resurser. Förmågan hos en programmerare att felsöka är en viktig faktor för att hitta källan till ett problem, men svårigheten att felsöka är starkt beroende av programmeringsspråket och de verktyg som används, särskilt debuggers .

Felsökningsverktyg

En debugger är ett mjukvaruverktyg som låter programmeraren observera körningen av programmet som undersöks, stoppa och starta om det, köra det i slow motion, ändra värden i minnet och till och med, i vissa fall, gå tillbaka i tiden.

Användbara verktyg i händerna på en programmerare kan också vara:

Profilerare . De låter dig bestämma hur länge ett visst avsnitt av koden körs. Täckningsanalys låter dig identifiera icke-körbara avsnitt av kod.
API-loggrar låter dig spåra interaktionen mellan programmet och Windows API genom att skriva Windows-meddelanden till loggen.
Disassemblers låter dig se monteringskoden för en körbar fil
Sniffers hjälper till att spåra nätverkstrafik som genereras av programmet
Hårdvarugränssnittssniffer låter dig se data som utbyts mellan systemet och enheten.
Systemloggar.

Att använda programmeringsspråk på hög nivå gör vanligtvis felsökningen lättare om sådana språk innehåller till exempel undantagshanteringsmöjligheter som gör det mycket lättare att hitta källan till problemet. På lågnivåspråk kan buggar leda till subtila problem som minneskorruption och minnesläckor . Då kan det vara ganska svårt att avgöra vad som var den ursprungliga orsaken till felet. I dessa fall kan komplexa tekniker och felsökningsverktyg krävas.

"Vårt personliga val är att försöka att inte använda debuggers, förutom att se anropsstacken eller värdena för ett par variabler . En anledning till detta är att det är mycket lätt att gå vilse i detaljerna i komplexa datastrukturer och programexekveringsvägar. Vi tycker att det är mindre produktivt att gå igenom ett program än att tänka hårt och kodkontrollera sig själv vid kritiska punkter.

Att klicka på operatörer tar mer tid än att titta på operatörernas meddelanden för att utfärda felsökningsinformation, placerad på kritiska punkter. Det är snabbare att bestämma var en debug-sats ska placeras än att gå igenom viktiga delar av koden, även om vi antar att vi vet var dessa avsnitt är. Ännu viktigare är att felsökningssatser bevaras i programmet, och felsökningssessioner är övergående.

Blind vandring i felsökaren är troligen improduktivt. Det är mer användbart att använda en debugger för att ta reda på tillståndet för programmet där det gör ett misstag, och sedan tänka på hur ett sådant tillstånd kan uppstå. Debuggers kan vara komplexa och förvirrande program, särskilt för nybörjare, för vilka de kommer att vara mer förbryllande än användbara ... "

“Felsökning är svårt och kan ta oförutsägbart lång tid, så målet är att kringgå det mesta. Tekniker som kan hjälpa till att minska felsökningstiden inkluderar bra design, bra stil , kontroll av gränstillstånd, validering av initiala påståenden och kodens rimlighet, defensiv programmering , väldesignade gränssnitt, begränsad användning av globala variabler, automatiska kontroller och kontroller. Ett uns av förebyggande är värt massor av botemedel."

— Brian Kernighan och Rob Pike

Verktyg som minskar behovet av felsökning

En annan riktning är att göra felsökning så sällan som möjligt. För detta gäller:

Kontraktsprogrammering - för programmeraren att på ett annat sätt bekräfta att han behöver exakt detta beteende hos programmet vid utgången. På språk som inte har avtalsprogrammering används självtestning av programmet vid nyckelpunkter.
Enhetstestning är att testa ett programs beteende bit för bit.
Statisk kodanalys - kontroll av koden för standardfel "genom förbiseende".
Hög programmeringskultur, i synnerhet designmönster , namnkonventioner och transparent beteende hos enskilda kodblock - att förklara för dig själv och andra hur den eller den funktionen ska bete sig.
Omfattande användning av beprövade externa bibliotek.

Kodsäkerhet och felsökning

Det kan förekomma så kallat odokumenterat beteende i programkoden – allvarliga fel som inte dyker upp under den normala programkörningen, men som är mycket farliga för hela systemets säkerhet vid en riktad attack. Oftast är detta resultatet av programmeringsfel. De mest kända exemplen är SQL-injektion och buffertspill . I det här fallet är uppgiften att felsöka:

Identifiera odokumenterat systembeteende
Ta bort osäkra koder

Det finns sådana metoder:

statisk kodanalys. I detta skede söker skannerprogrammet efter sekvenser i källkoden som motsvarar osäkra funktionsanrop etc. Faktum är att programmets källkod skannas utifrån en speciell regelbas som innehåller en beskrivning av osäkra kodexempel.
luddig . Detta är processen att ge slumpmässiga eller felaktiga data till programmets indata och analysera programmets reaktion.
Reverse engineering (Reverse engineering). Det här fallet uppstår när oberoende forskare letar efter sårbarheter och odokumenterade funktioner i ett program.

Se även

Anteckningar

Litteratur

Steve Maguire, Writing Solid Code ( Microsoft Press, 1993)
Steve McConnel, "Perfect Code" (Steve McConnel. Code Complete . Microsoft Press, 1993)

Länkar

Ordböcker och uppslagsverk	Stor ryss Britannica (online)
I bibliografiska kataloger	J9U : 987007543228905171 LCCN : sh85036145