Felsökning
Felsökning (eller helt enkelt felsökning ) eller rening , inom datavetenskap , i samband med mjukvaruutveckling , indikerar aktiviteten som består i att programmeraren identifierar och korrigerar ett eller flera fel ( buggar ) som upptäckts i programvaran , direkt i fasprogrammering eller efter testfasen eller den slutliga användningen av själva programmet .
Felsökning är en av de viktigaste och svåraste operationerna för att sätta upp ett program , ofta extremt komplicerad på grund av komplexiteten hos programvaran som används och känslig på grund av risken att introducera nya fel eller beteenden som skiljer sig från de som önskas i ett försök att korrigera dem för vilken felsökningsaktiviteten utfördes .
Grundläggande operationer
Även om varje felsökningssession är unik och utgör sin egen historia, gäller vissa allmänna principer för alla felsökningssessioner. I synnerhet för felsökning av programvaror finns det i allmänhet fem steg i felsökning:
- felidentifiering
- identifiering av den komponent i vilken buggen finns
- hitta orsaken till felet
- designa en fix för buggen
- implementering och testning av ovannämnda korrigering
Felupptäckt
Medan syntaxfel vanligtvis markeras av IDE , utför programmeraren i slutet av kodskrivningen en andra testfas genom att utvärdera om programmets utdata är som förväntat genom att kompilera/tolka och exekvera koden. Varje upptäckt av det semantiska felet och körtidsfelet följs av felsökningsfasen , dvs identifieringen av den del av programvaran , ibland mycket komplex, där felet lurar. Ofta utförs denna operation av programmeraren hand i hand med skrivningen av själva koden, som kontinuerligt testar koden och på så sätt undviker ackumulering av fel.
Denna aktivitet stöds av specifika program ( debuggers ) som görs tillgängliga av IDE tack vare användningen av brytpunkter på kodrader och av standardfelmeddelanden som utfärdas i loggfilerna ( t.ex. undantagsdetektering i IDE - konsolerna), som indikerar och visa utvecklaren exekveringen, instruktion för instruktion, av programmet, samtidigt som du tillåter analys av data som bearbetas av själva programmet. I avsaknad av sådana verktyg för felsökningsaktiviteter används den enklare, men också mindre effektiva tekniken för att skriva ut instruktionerna som programmet kör på skärmen eller på en fil , och infogar för detta ändamål i kodfelsökningsinstruktionerna som markerar slutet punkt för programkörning tills fel. Även för detta ändamål kan programmeraren, med hjälp av kommentarer , exekvera endast vissa delar av koden eller tvärtom inte exekvera vissa delar av koden, misstänkt för att orsaka felet. När felet hittas i koden, korrigerar programmeraren iterativt felet tills programmet gör vad som önskas.
En tredje felsökningsfas är den som programmeraren måste lösa när den producerade mjukvaran har skickats för testning eller testning till respektive team och har skickats tillbaka med listan över hittade defekter; i dessa fall är det i allmänhet mycket ofta fel i utformningen eller tolkningen av specifikationerna med avseende på vad som verkligen önskas utan att gå fel.
En fjärde felsökningsfas kan äga rum när slutanvändaren stöter på anomalier under användningen av programmet; generellt i dessa fall genereras ett fel med ett relativt meddelande som skickas via Internet till mjukvarutillverkaren som regelbundet kommer att uppdatera produkten med nya utgåvor utan fel eller uppdateringar (t.ex. Windows ).
Knep för att påskynda felsökningsprocessen
Korrekt mental attityd
Det är nödvändigt att vara självkritisk, och att acceptera det faktum att programmet inte beter sig som det ska och att ett misstag har begåtts, vilket är helt normalt och ofta i utvecklingen; om allt hade förutsetts och det inte fanns några fel skulle programmet fungera korrekt, men ofta erhålls detta resultat nästan aldrig vid det första utkastet av koden, utan bara för efterföljande modifieringar och korrigeringar. Detta tankesätt ökar avsevärt chansen att hitta och åtgärda buggar.
Använd loggfilen
Utöver användningen av IDE-konsolen är det lämpligt att skapa en eller flera loggfiler som kan vara mycket användbara för att verifiera om programmet fungerar som förväntat, och vad som händer före, efter och under uppkomsten av felet.
Var uppmärksam på indata som ges till programmet
Alla indata från användaren måste först valideras syntaktisk och därefter även semantiskt av programmet innan de bearbetas. Detta förbättrar också säkerheten i programmet.
Lagra typerna av fel
Om du redan har skrivit liknande program och du har hittat buggar som liknar det nuvarande, är det en bra idé, baserat på erfarenhet, att försöka komma ihåg det misstag som gjordes och den antagna lösningen.
Knep för att minska behovet av felsökning
Kodritning
Att noggrant rita datastrukturer och funktioner i strukturerad programmering och klasser i objektorienterad programmering är det bästa sättet att minska fel i koden och för att underlätta feldetektering om programmet inte fungerar korrekt.
Läsbarhet för koden
Användningen av tydliga konventioner för namn på variabler , funktioner , klasser, metoder och konstanter, samt för att tala namn, det vill säga som gör det tydligt att en komponent används och framför allt undviker att återanvända samma komponent för olika syften , gör koden tydligare och mer läsbar även efter att ha sökt efter fel.
Kommentarer
Kommentarer är avgörande, speciellt om koden är skriven i flera händer. Speciellt måste kommentaren tillföra ett mervärde till instruktionen. Till exempel om utbildning är
brutto = tara + netto;
det är ingen idé att skriva en kommentar som
/ * bruttovikten är lika med nettovikten plus taravikten * /
eftersom det redan framgår av namnet på variablerna. En kommentar som
/ * "tara" är en konstant definierad i filen constants.php * /
det är säkert mycket mer användbart.
Relaterade artiklar
Externa länkar
- Snabbfelsökningsguide , på heather.cs.ucdavis.edu . _ _
