Hvad er forskellen mellem fejlfinding, test og fejlfinding?

Brug enhver tid på at arbejde eller spille på computere, og snart vil du høre tre ord bundet om: fejlfinding , test og fejlsøgning . Mens de to første er almindelige nok, kan deres betydning muligvis virke uskarp eller endda synonym. I praksis er hver af disse handlinger forskellige, skønt de er beslægtede.

Fejlfinding er slutbrugerens og kundesupportteknikerens bane og begynder, når software eller hardware ikke fungerer som forventet, hvilket giver et uventet eller på anden måde utilfredsstillende resultat. I mange tilfælde er brugerfejl skyld.

Det første trin i fejlfinding er at dække det grundlæggende. Er softwaren eller hardware installeret korrekt? Er det konfigureret korrekt? Har du læst manualen og fulgt alle instruktioner? Måske har du ændret noget i dit system, der udfældede problemet? Har du brugt dette produkt hele tiden, eller er det en ny installation?

Hvis det er en ny installation, kan du næsten være sikker på, at problemet ligger i installationsprocessen, især i tilfælde af hardware. Hardware kræver en enhedsdriver (softwarefil), der fungerer som en bro eller interface mellem hardware og operativsystem. Hvis enhedsdriveren mislykkes, kan hardware ikke kommunikere korrekt med andre systemkomponenter. Enhedsdrivere er muligvis ikke til stede eller er måske blevet installeret i en forkert rækkefølge i forhold til enheden.

Hvis problemet ligger i hardware, der fungerede helt fint indtil i øjeblikket, kan korruption af enhedsdriveren muligvis være årsagen. Geninstallation af driveren kan muligvis løse problemet. En opdateret driver kan også gøre det. Andre gange genoptager en komponent på bundkortet ved at slukke for computeren, udpakke komponenten og derefter geninstallere den, tager det sig af problemet.

Fejlfinding af hardware i Windows ™ -systemer er også tilgængelig via Enhedshåndterings- og hjælpemenuerne . Et gult udråbstegn ved siden af ​​en komponent i Enhedshåndteringen angiver et problem.

Software, der begynder at opføre sig dårligt, kan også blive beskadiget. Geninstallation kan undertiden hjælpe, men hvis et program begyndte at fungere, efter at ny, ikke-relateret software blev installeret, kan der være en konflikt mellem de to. Firewalls og antivirusprogrammer er berygtede for ikke at spille pænt sammen, og det er sandsynligvis klogt at holde sig til kun et program i hver af disse kategorier, medmindre du er en avanceret bruger.

Fejlfinding generelt involverer normalt læsning af manualer eller hjælpefiler, gennemgang af det grundlæggende for at fjerne brugerfejl som en potentiel årsag og brug af en søgemaskine til at undersøge, hvordan andre har løst problemet. Hvis der er en ting, du altid kan stole på som slutbruger, er det, at nogen har gået i dine sko før. Internetsamfundet er meget godt med at yde hjælp, og i de fleste tilfælde kan der findes svar ved omhyggelig søgning.

Testning er forløberen for fejlfinding. Testning er almindeligvis programmets og avancerede brugers forte og forekommer, når et produkt er nyt eller opdateres og skal placeres gennem dets skridt for at eliminere potentielle problemer. Testning identificerer “bugs” eller ufuldkommenheder, så de kan rettes i fejlfindingsprocessen, inden [næste] officielle udgivelse af produktet. Disse “uofficielle” udgivelser er kendt som betaversættelser (f.eks. 3.0 b ), og offentlige frivillige er kendt som betatestere.

Betatestning er en værdifuld ressource for softwareudviklere på grund af de forskellige computersystemer, der deltager, kombineret med det store antal timer og scenarier, som programmet bruges under. Dette skyller uforudsete problemer ud på en måde, der ikke effektivt kan opnås ved brug af intern debuggers. Betatestningsfasen giver forfatterne en god idé om, hvorvidt et produkt til det offentlige er parat.

Hardware testes også beta, men da det er økonomisk uoverkommeligt at levere gratis beta-hardware til offentligheden, udføres hardwaretest og fejlsøgning ofte i hus. Betaprodukter kan imidlertid blive førtpræmieret og i nogle tilfælde distribueret i begrænset antal til industrielle insidere på konferencer som COMDEX.

Betasoftware stilles specifikt til rådighed til test og betragtes ikke som en stabil frigivelse. Betatestere installerer beta-software på deres egen risiko, og for at hjælpe softwareudviklere med at identificere kilden til et problem skal de levere en sund mængde information, når de rapporterer en fejl. Nødvendige data varierer, men inkluderer generelt systemspecifikationer, beta-version og build, de nøjagtige betingelser, under hvilken fejlen opstod, og indholdet af fejlmeddelelser.

Debugging er programmets og udviklernes forte og involverer at rette selve softwarekoden for at eliminere fejl eller fejl. Udviklere forsøger at replikere beta-rapporterede bugs i internt systemer med det formål at fjerne dem.

Mens der er mange typer af fejlfindingsværktøjer, er et simpelt eksempel et værktøj, der giver programmereren mulighed for at overvåge programkode, mens den manipulerer den til at udføre forskellige kommandoer og rutiner. En grundlæggende tilgang er at forenkle koden så meget som muligt på det mistænkte urolige sted, mens problemet stadig gentages, og indsnævre fokuset til potentielle problemlinjer. I virkeligheden er fejlsøgning en kompleks proces, der kræver forskellige tilgange baseret på faktorer som kompleksiteten og længden af ​​selve softwarekoden og det sprog, den er skrevet med.

Fejlsøgning kan være en kedelig opgave, skønt nogle sprog er lettere at fejlsøge end andre. Java inkluderer for eksempel rutiner, der håndterer undtagelsesfejl. En undtagelsesfejl opstår, når programmet støder på en situation, der skal løses, før programmet kan fortsætte korrekt. I dette tilfælde starter en indbygget rutine en "søgning" inden for de forskellige lag med softwarekode, der leder efter et svar på problemet. Hvis en løsning ikke kan findes, opstår der en dødelig undtagelsesfejl , og programmet lukkes ned. Den resulterende fejlmeddelelse kan muligvis indeholde en hukommelsesadresse eller nogle andre kryptiske data, som ikke hjælper brugeren, men som kan være værdifulde til fejlfinding. Velskrevne programmer bør ikke have fatale fejl.

Ældre programmeringssprog som C eller samling er ikke så gennemsigtige og håndterer ikke fejl så effektivt. Fejlsøgningsprogrammer, der er skrevet på disse sprog, kan teste debuggerens evner og tålmodighed.

Heldigvis for slutbrugeren er kommercielt tilgængelig software allerede fejlagtigt af store mangler. På grund af netop denne grund falder de fleste problemer, som slutbrugeren oplever, inden for rammerne af fejlfinding og kan rettes ved hjælp af tidligere nævnte. I de tilfælde, hvor en slutbruger støder på en fejl, kan det at gennemgå bevægelsessystemets bevægelser afsløre en arbejdsgang, indtil fejlen er rettet af udvikleren.

Når du beder om hjælp på et webforum eller en nyhedsgruppe, skal du sørge for at lave dine lektier i forvejen. Fejlfinding er tidskrævende, og folk, som frivilligt hjælper dem, værdsætter nogen, der har gjort en indsats for at finde svar. Spørgsmål om et problem, der er blevet stillet og besvaret gentagne gange, vinder ikke dine venner og betragtes som en dårlig netikette.