Program debugging
Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 7. april 2022; checks kræver 4 redigeringer .Debugging er et trin i udviklingen af et computerprogram , hvor fejl opdages, lokaliseres og elimineres. For at forstå, hvor fejlen opstod, skal du:
- find ud af de aktuelle værdier af variabler ;
- finde ud af, hvilken sti programmet kørte.
Der er to komplementære fejlfindingsteknologier:
- Brug af debuggere - programmer, der inkluderer en brugergrænseflade til at gå gennem programmet: sætning for sætning, funktion for funktion, stop ved nogle linjer med kildekode, eller når en bestemt betingelse er nået.
- Outputtet af den aktuelle tilstand af programmet ved hjælp af output-operatorer placeret på kritiske punkter i programmet - til skærmen , printeren , højttaleren eller til en fil . Udlæsning af fejlfindingsoplysninger til en fil kaldes logning .
Stedet for fejlretning i et programs udviklingscyklus
En typisk udviklingscyklus, der gentages mange gange i løbet af et programs levetid, ser nogenlunde sådan ud:
- Programmering - introduktion af ny funktionalitet i programmet, rettelse af eksisterende fejl .
- Test (manuel eller automatiseret; af en programmør, tester eller bruger; " røg ", i sort boks -tilstand eller modulær ) - påvisning af en fejl.
- At gengive en fejl er at finde ud af, under hvilke forhold en fejl opstår. Dette kan vise sig at være en vanskelig opgave ved programmering af samtidige processer og med nogle usædvanlige fejl kendt som heisenbugs .
- Debugging - Find årsagen til en fejl.
Værktøjer
Fejlretning kræver ofte høj dygtighed og betydelige ressourcer. En programmørs evne til at debugge er en vigtig faktor for at finde kilden til et problem, men sværhedsgraden ved fejlretning afhænger i høj grad af programmeringssproget og de anvendte værktøjer, især debuggere .
Fejlfindingsværktøjer
En debugger er et softwareværktøj, der gør det muligt for programmøren at observere udførelsen af det undersøgte program, stoppe og genstarte det, køre det i slowmotion, ændre værdier i hukommelsen og endda i nogle tilfælde gå tilbage i tiden.
Også nyttige værktøjer i hænderne på en programmør kan være:
- Profilere . De vil give dig mulighed for at bestemme, hvor længe en bestemt sektion af kode bliver eksekveret. Dækningsanalyse giver dig mulighed for at identificere ikke-eksekverbare kodesektioner.
- API-loggere giver dig mulighed for at spore interaktionen mellem programmet og Windows API ved at skrive Windows-meddelelser til loggen.
- Disassemblers giver dig mulighed for at se monteringskoden for en eksekverbar fil
- Sniffere hjælper med at spore netværkstrafik genereret af programmet
- Hardware interface sniffere giver dig mulighed for at se de data, der udveksles mellem systemet og enheden.
- System logs.
Brug af programmeringssprog på højt niveau gør normalt fejlfinding lettere, hvis sådanne sprog for eksempel indeholder undtagelseshåndteringsfaciliteter, der gør det meget nemmere at finde kilden til problemet. I sprog på lavt niveau kan fejl føre til subtile problemer såsom hukommelseskorruption og hukommelseslækager . Så kan det være ret svært at fastslå, hvad der var den oprindelige årsag til fejlen. I disse tilfælde kan komplekse teknikker og fejlfindingsværktøjer være påkrævet.
"Vores personlige valg er at prøve ikke at bruge debuggere, undtagen at se opkaldsstakken eller værdierne af et par variabler . En grund til dette er, at det er meget nemt at gå tabt i detaljerne i komplekse datastrukturer og programudførelsesstier. Vi finder det mindre produktivt at træde gennem et program end hård tænkning og kodekontrol på kritiske punkter.
Det tager mere tid at klikke på operatører end at se operatørernes beskeder for at udstede fejlretningsoplysninger, placeret på kritiske punkter. Det er hurtigere at beslutte, hvor en debug-sætning skal placeres, end det er at gå gennem kritiske sektioner af kode, selv hvis vi antager, hvor disse sektioner er. Endnu vigtigere er det, at debug-sætninger bevares i programmet, og debugger-sessioner er forbigående.
Blind vandring i debuggeren er højst sandsynligt uproduktivt. Det er mere nyttigt at bruge en debugger til at finde ud af tilstanden af det program, hvor det laver en fejl, og så tænk på, hvordan en sådan tilstand kan opstå. Debuggere kan være komplekse og forvirrende programmer, især for begyndere, for hvem de vil være mere forvirrende end nyttige ... "
“Fejlretning er svært og kan tage uforudsigeligt lang tid, så målet er at omgå det meste. Teknikker, der kan hjælpe med at reducere fejlretningstiden, omfatter godt design, god stil , kontrol af grænsetilstande, validering af indledende påstande og rimelighed af kode, defensiv programmering , veldesignede grænseflader, begrænset brug af globale variabler, automatiske kontroller og kontroller. En ounce forebyggelse er et ton kur værd."
— Brian Kernighan og Rob PikeVærktøjer, der reducerer behovet for fejlretning
En anden retning er at gøre fejlfinding så sjælden som muligt. For dette gælder:
- Kontraktprogrammering - for programmøren at bekræfte på en anden måde, at han har brug for præcis denne opførsel af programmet ved udgangen. På sprog, der ikke har kontraktprogrammering, anvendes selvtest af programmet på nøglepunkter.
- Enhedstest er at teste et programs opførsel stykke for stykke.
- Statisk kodeanalyse - kontrol af koden for standardfejl "ved tilsyn".
- Høj programmeringskultur, især designmønstre , navnekonventioner og gennemsigtig adfærd for individuelle kodeblokke - at erklære over for dig selv og andre, hvordan denne eller hin funktion skal opføre sig.
- Omfattende brug af dokumenterede eksterne biblioteker.
Kodesikkerhed og debugging
Der kan være tale om såkaldt udokumenteret adfærd i programkoden – alvorlige fejl, som ikke optræder under det normale programafviklingsforløb, men som er meget farlige for hele systemets sikkerhed ved et målrettet angreb. Oftest er dette resultatet af programmørfejl. De mest berømte eksempler er SQL-injektion og bufferoverløb . I dette tilfælde er opgaven med at fejlfinde:
- Identifikation af udokumenteret systemadfærd
- Fjern usikker kode
Der er sådanne metoder:
- statisk kodeanalyse. På dette stadium søger scannerprogrammet efter sekvenser i kildekoden, der svarer til usikre funktionskald osv. Faktisk scannes programmets kildekode ud fra en særlig regelbase, der indeholder en beskrivelse af usikre kodeeksempler.
- fuzzing . Dette er processen med at give tilfældige eller forkerte data til programmets input og analysere programmets reaktion.
- Reverse engineering (Reverse engineering). Dette tilfælde opstår, når uafhængige forskere leder efter sårbarheder og udokumenterede funktioner i et program.
Se også
Noter
Litteratur
- Steve Maguire, Writing Solid Code ( Microsoft Press, 1993)
- Steve McConnel, "Perfect Code" (Steve McConnel. Code Complete . Microsoft Press, 1993)
Links
- AMD64 Fejlfinding på instruktionsniveau med dbx
- AMD64 Fejlfinding på instruktionsniveau med Sun Studio dbx
 Ordbøger og encyklopædier | |
|---|---|
| I bibliografiske kataloger |