🏅 Hvordan fungerer GPU-minedrift?

GPU er en vigtig enhed på computeren, der er ansvarlig for gengivelse og visning af billeder og videoer. Grafiske behandlingsenheder er optimeret til behandling af store datablokke. Derfor er det bedre end CPU'en til minedrift. Hvis du miner enhver kryptovaluta med GPU, behøver du ikke ofte skifte mellem to opgaver. Så det kan behandle flere hashes samtidigt.

Defekthåndteringsproces i softwaretest

Hvad er defekthåndteringsproces?

Defekthåndtering er en systematisk proces til at identificere og rette fejl. En defektstyringscyklus indeholder følgende trin: 1) Opdagelse af defekt, 2) Defektkategorisering 3) Udbedring af defekter af udviklere 4) Verifikation af testere, 5) Defektlukning 6) Fejlrapporter ved projektets afslutning

Dette emne vil guide dig til, hvordan du anvender defekthåndteringsprocessen på projektets Guru99 Bank-websted. Du kan følge nedenstående trin for at håndtere defekter.

Trin 1) Opdagelse

I opdagelsesfasen skal projektholdene opdage som mange defekter som muligt, før slutkunden kan opdage det. En defekt siges at blive opdaget og ændret til status accepteret når det er anerkendt og accepteret af udviklerne

I ovenstående scenarie opdagede testerne 84 defekter på webstedet Guru99.

Lad os tage et kig på følgende scenarie; dit testteam opdagede nogle problemer på Guru99 Bank-webstedet. De betragter dem som defekter og rapporterede til udviklingsteamet, men der er en konflikt –

Hvad vil du i så fald gøre som testleder?

A) Enig med testteamet, at det er en defekt

B) Test Manager tager rollen som dommer til at afgøre, om problemet er defekt eller ej

C) Aftal med udviklingsteamet, at der ikke er en defekt

Korrekt

Ukorrekt

I sådanne tilfælde bør der anvendes en løsningsproces for at løse konflikten, du tager rollen som dommer for at afgøre, om webstedsproblemet er en defekt eller ej.

Trin 2) Kategorisering

Kategorisering af fejl hjælper softwareudviklerne med at prioritere deres opgaver. Det betyder, at denne form for prioritet hjælper udviklerne med at rette de defekter først, som er meget afgørende.

Defekter kategoriseres normalt af testlederen –

Lad os lave en lille øvelse som følger

Træk og slip defektprioriteten nedenfor

1) Hjemmesidens ydeevne er for langsom
2) Hjemmesidens login-funktion fungerer ikke korrekt
3) Webstedets GUI vises ikke korrekt på Mobil enheder
4) Hjemmesiden kunne ikke huske brugerens login-session
5) Nogle links virker ikke

Her er de anbefalede svar

Nej.	Description	Prioritet	Forklaring
1	Hjemmesidens ydeevne er for langsom	Høj	Ydeevnefejlen kan forårsage enorme besvær for brugeren.
2	Hjemmesidens login-funktion fungerer ikke korrekt	Kritisk	Login er en af hovedfunktionerne på bankwebstedet, hvis denne funktion ikke virker, er det alvorlige fejl
3	Webstedets GUI vises ikke korrekt på mobile enheder	Medium	Defekten påvirker den bruger, der bruger Smartphone til at se hjemmesiden.
4	Hjemmesiden kunne ikke huske brugerlogin-sessionen	Høj	Dette er et alvorligt problem, da brugeren vil være i stand til at logge ind, men ikke være i stand til at udføre yderligere transaktioner
5	Nogle links virker ikke	Lav	Dette er en nem løsning for udviklingsfolk, og brugeren kan stadig få adgang til webstedet uden disse links

Trin 3) Fejlløsning

Defektløsning i softwaretest er en trinvis proces til at rette fejlene. Defektløsningsprocessen starter med at tildele defekter til udviklere, derefter planlægger udviklere, at defekten skal rettes efter prioritet, derefter rettes defekter, og endelig sender udviklere en rapport om løsning til testmanageren. Denne proces hjælper med at rette og spore defekter nemt.

Du kan følge de følgende trin for at rette fejlen.

Opgave: Tildelt en udvikler eller en anden tekniker til at rette, og ændret status til Reaktion.
Fastsættelse af tidsplan: Udviklersiden tager ansvaret i denne fase. De vil oprette en tidsplan for at rette disse defekter, afhængigt af defektprioriteten.
Ret fejlen: Mens udviklingsteamet retter defekterne, sporer Test Manager processen med at rette defekter sammenlignet med ovenstående tidsplan.
Rapportér beslutningen: Få en rapport om løsningen fra udviklere, når defekter er rettet.

Trin 4) Bekræftelse

Efter udviklingsteamet fast og rapporteret defekten, testholdet revideres at manglerne rent faktisk er løst.

For eksempel, i ovenstående scenarie, når udviklingsteamet rapporterede, at de allerede har rettet 61 defekter, ville dit team teste igen for at bekræfte, at disse defekter faktisk var rettet eller ej.

Trin 5) Lukning

Når en defekt er blevet løst og verificeret, ændres defekten status som lukket. Hvis ikke, skal du sende en meddelelse til udviklingen om at kontrollere defekten igen.

Trin 6) Fejlrapportering

Fejlrapportering i softwaretest er en proces, hvor testledere udarbejder og sender fejlrapporten til ledelsesteamet for feedback på defekthåndteringsprocessen og defekternes status. Derefter tjekker ledelsesteamet fejlrapporten og sender feedback eller yder yderligere support, hvis det er nødvendigt. Fejlrapportering hjælper til bedre at kommunikere, spore og forklare defekter i detaljer.

Bestyrelsen har ret til at kende fejlstatus. De skal forstå defekthåndteringsprocessen for at støtte dig i dette projekt. Derfor skal du indberette den aktuelle defektsituation for at få feedback fra dem.

Hvorfor har du brug for Defect Management Process?

Dit team fandt fejl, mens de testede Guru99 Banking-projektet.

Efter en uge svarer udvikleren -

I næste uge svarer testeren

Som i ovenstående tilfælde, hvis den defekte kommunikation sker verbalt, bliver tingene snart meget komplicerede. For at kontrollere og effektivt håndtere fejl har du brug for en defekt livscyklus.

Vigtige fejlmålinger

Tilbage til ovenstående scenarie. Udvikleren og testholdene har gennemgået de rapporterede defekter. Her er resultatet af den diskussion

Hvordan måles og evalueres kvaliteten af testudførelsen?

Dette er et spørgsmål, som alle Test Manager ønsker at vide. Der er 2 parametre, som du kan overveje som følgende

I ovenstående scenarie kan du beregne afvisningsforholdet (DRR) er 20/84 = 0.238 (23.8 %).

Et andet eksempel, antaget, at Guru99 Bank-webstedet har total 64 defekter, men dit testteam opdager kun 44 defekter, dvs. de savnede 20 defekter. Derfor kan du beregne fejllækageforholdet (DLR) er 20/64 = 0.312 (31.2%).

Konklusion, kvaliteten af testudførelsen evalueres via følgende to parametre

Jo mindre værdien af DRR og DLR er, jo bedre kvalitet er testudførelsen. Hvad er forholdsområdet som er acceptabel? Dette interval kan defineres og accepteres som udgangspunkt i projektmålet, eller du kan henvise til metrics for lignende projekter.

I dette projekt er den anbefalede værdi af acceptabelt forhold 5 ~ 10 %. Det betyder, at kvaliteten af testudførelsen er lav. Du bør finde modforanstaltninger for at reducere disse forhold som f.eks

Forbedre medlemmers testfærdigheder.
Brug mere tid til testudførelse, især til gennemgang af testudførelsesresultaterne.

Ofte Stillede Spørgsmål

En fejl er konsekvensen/udfaldet af en kodningsfejl.

A Fejl i softwaretest er en variation eller afvigelse af softwareapplikationen fra slutbrugerens krav eller oprindelige forretningskrav. En softwarefejl er en kodningsfejl, som forårsager forkerte eller uventede resultater fra et softwareprogram, som ikke opfylder de faktiske krav. Testere kan støde på sådanne defekter, mens de udfører testcaserne.

Disse to udtryk har en meget tynd forskel, i branchen er begge fejl, der skal rettes og bruges i flæng af nogle af de Test teams.

Når testere udfører testcaserne, kan de støde på sådanne testresultater, som er i modstrid med de forventede resultater. Denne variation i testresultater omtales som en softwarefejl. Disse defekter eller variationer omtales med forskellige navne i forskellige organisationer som problemer, problemer, fejl eller hændelser.

En fejlrapport i softwaretest er et detaljeret dokument om fejl fundet i softwareapplikationen. Fejlrapport indeholder hver enkelt detalje om fejl som beskrivelse, dato for, hvornår fejlen blev fundet, navn på tester, der fandt den, navn på udvikler, der rettede den, osv. Fejlrapport hjælper med at identificere lignende fejl i fremtiden, så det kan undgås.

Defekt_ID – Unikt identifikationsnummer for defekten.
Defekt Description – Detaljeret beskrivelse af Defekten, herunder information om det modul, hvori Defekten blev fundet.
version – Version af den applikation, hvor defekten blev fundet.
trin – Detaljerede trin sammen med skærmbilleder, som udvikleren kan genskabe defekterne med.
Dato hævet – Dato, hvor defekten er rejst
Reference- hvor i dig Angiv reference til dokumenter som . krav, design, arkitektur eller måske endda skærmbilleder af fejlen for at hjælpe med at forstå defekten
Opdaget af – Navn/id på den tester, der har rejst defekten
Status - Status for defekten, mere om dette senere
Rettet af – Navn/id på udvikleren, der har rettet det
Dato lukket – Dato, hvor defekten er lukket
Severity som beskriver manglens indvirkning på ansøgningen
Prioritet som er relateret til uopsættelighed for at reparere defekter. Alvorlighedsprioritet kan være Høj/Middel/Lav baseret på den hastende virkning, ved hvilken defekten skal repareres.

Klik link. hvis videoen ikke er tilgængelig

Ressourcer:

Download en prøveskabelon til fejlrapportering

Du kan lide: