🏅 Hur fungerar GPU Mining?

GPU är en viktig enhet i datorn som ansvarar för rendering och visning av bilder och videor. Grafiska bearbetningsenheter är optimerade för bearbetning av stora datablock. Därför är det bättre än CPU för gruvdrift. Om du bryter någon kryptovaluta med GPU behöver du inte ofta byta mellan två uppgifter. Så den kan bearbeta fler hash samtidigt.

Defekthanteringsprocess i mjukvarutestning

Vad är defekthanteringsprocessen?

Defekthantering är en systematisk process för att identifiera och åtgärda buggar. En defekthanteringscykel innehåller följande steg: 1) Upptäckt av defekt, 2) Defektkategorisering 3) Åtgärd av defekter av utvecklare 4) Verifiering av testare, 5) Defektstängning 6) Defektrapporter i slutet av projektet

Det här ämnet kommer att guida dig om hur du tillämpar defekthanteringsprocessen på projektets Guru99 Banks webbplats. Du kan följa stegen nedan för att hantera defekter.

Steg 1) Upptäckt

I upptäcktsfasen måste projektteamen upptäcka som många defekter som möjlig, innan slutkunden kan upptäcka det. En defekt sägs upptäckas och ändras till status accepterade när det är erkänt och accepterat av utvecklarna

I scenariot ovan upptäckte testarna 84 defekter på webbplatsen Guru99.

Låt oss ta en titt på följande scenario; ditt testteam upptäckte några problem på Guru99 Banks webbplats. De betraktar dem som defekter och rapporteras till utvecklingsteamet, men det finns en konflikt –

I så fall, som testledare, vad kommer du att göra?

A) Håller med testteamet om att det är en defekt

B) Testledare tar rollen som domare för att avgöra om problemet är defekt eller inte

C) Håll med utvecklingsteamet om att det inte är en defekt

Correct

Felaktig

I sådana fall bör en lösningsprocess tillämpas för att lösa konflikten, du tar rollen som domare för att avgöra om webbplatsproblemet är ett fel eller inte.

Steg 2) Kategorisering

Defektkategorisering hjälper mjukvaruutvecklarna att prioritera sina uppgifter. Det betyder att den här typen av prioritet hjälper utvecklarna att först åtgärda de defekter som är mycket avgörande.

Defekter kategoriseras vanligtvis av testledaren -

Låt oss göra en liten övning enligt följande

Dra och släpp defektprioriteten nedan

1) Webbplatsens prestanda är för långsam
2) Webbplatsens inloggningsfunktion fungerar inte korrekt
3) Webbplatsens GUI visas inte korrekt på Mobil enheter
4) Webbplatsen kunde inte komma ihåg användarinloggningssessionen
5) Vissa länkar fungerar inte

Här är de rekommenderade svaren

Nej.	Systembeskrivningar	Budget	Förklaring
1	Webbplatsens prestanda är för långsam	Hög	Prestandafelet kan orsaka enorma besvär för användaren.
2	Webbplatsens inloggningsfunktion fungerar inte korrekt	Kritisk	Inloggning är en av huvudfunktionerna på bankwebbplatsen om den här funktionen inte fungerar, det är allvarliga buggar
3	Webbplatsens GUI visas inte korrekt på mobila enheter	Medium	Defekten påverkar användaren som använder Smartphone för att se webbplatsen.
4	Webbplatsen kunde inte komma ihåg användarinloggningssessionen	Hög	Detta är ett allvarligt problem eftersom användaren kommer att kunna logga in men inte kunna utföra några ytterligare transaktioner
5	Vissa länkar fungerar inte	Låg	Detta är en enkel lösning för utvecklingsmän och användaren kan fortfarande komma åt sidan utan dessa länkar

Steg 3) Defektlösning

Defektupplösning i mjukvarutestning är en steg-för-steg-process för att åtgärda defekterna. Defektlösningsprocessen börjar med att tilldela defekter till utvecklare, sedan schemalägger utvecklarna att defekten ska åtgärdas enligt prioritet, sedan fixas defekter och slutligen skickar utvecklarna en rapport om lösningen till testhanteraren. Denna process hjälper till att åtgärda och spåra defekter enkelt.

Du kan följa följande steg för att åtgärda defekten.

Uppdrag: Tilldelad till en utvecklare eller annan tekniker att fixa, och ändrade status till svara.
Schemafixning: Utvecklarsidan tar ansvar i denna fas. De kommer att skapa ett schema för att åtgärda dessa defekter, beroende på defektens prioritet.
Åtgärda defekten: Medan utvecklingsteamet åtgärdar defekterna, spårar testhanteraren processen för att åtgärda defekter jämfört med ovanstående schema.
Rapportera resolutionen: Få en rapport om lösningen från utvecklare när defekter är åtgärdade.

Steg 4) Verifiering

Efter utvecklingsteamet fixerad och rapporterade defekten, testteamet verifierar att defekterna faktiskt är åtgärdade.

Till exempel, i scenariot ovan, när utvecklingsteamet rapporterade att de redan åtgärdat 61 defekter, skulle ditt team testa igen för att verifiera att dessa defekter faktiskt var åtgärdade eller inte.

Steg 5) Stängning

När ett fel har åtgärdats och verifierats, ändras defektens status som stängt. Om inte, måste du skicka ett meddelande till utvecklingen för att kontrollera defekten igen.

Steg 6) Felrapportering

Defektrapportering i mjukvarutestning är en process där testledare förbereder och skickar felrapporten till ledningsgruppen för återkoppling om defekthanteringsprocessen och defekternas status. Sedan kontrollerar ledningsgruppen felanmälan och skickar feedback eller ger ytterligare support vid behov. Felrapportering hjälper till att bättre kommunicera, spåra och förklara defekter i detalj.

Styrelsen har rätt att få reda på defektens status. De måste förstå defekthanteringsprocessen för att stödja dig i detta projekt. Därför måste du rapportera dem den aktuella defektsituationen för att få feedback från dem.

Varför behöver du defekthanteringsprocess?

Ditt team hittade buggar när de testade Guru99 Banking-projektet.

Efter en vecka svarar utvecklaren -

Nästa vecka svarar testaren

Som i ovanstående fall, om defektkommunikationen görs verbalt, blir saker och ting snart mycket komplicerade. För att kontrollera och effektivt hantera buggar behöver du en defekt livscykel.

Viktiga defektmått

Tillbaka till scenariot ovan. Utvecklaren och testteamen har granskat de rapporterade defekterna. Här är resultatet av den diskussionen

Hur mäter och utvärderar man kvaliteten på testutförandet?

Detta är en fråga som varje Test Manager vill veta. Det finns 2 parametrar som du kan överväga enligt följande

I scenariot ovan kan du beräkna avvisningsförhållande för avhopp (DRR) är 20/84 = 0.238 (23.8 %).

Ett annat exempel, förmodat att Guru99 Banks webbplats har totalt 64 defekter, men ditt testteam upptäcker bara 44 defekter dvs de missade 20 defekter. Därför kan du beräkna defektläckageförhållandet (DLR) är 20/64 = 0.312 (31.2%).

Slutsats, kvaliteten på testutförandet utvärderas via följande två parametrar

Ju mindre värde på DRR och DLR är, desto bättre kvalitet är testkörningen. Vad är förhållandet intervall som är godtagbart? Detta intervall kan definieras och accepteras som bas i projektmålet eller så kan du referera till mätvärden för liknande projekt.

I detta projekt är det rekommenderade värdet på acceptabelt förhållande 5 ~ 10 %. Det betyder att kvaliteten på testutförandet är låg. Du bör hitta motåtgärd för att minska dessa förhållanden som t.ex

Förbättra medlemmens testkunskaper.
Spendera mer tid för testkörning, speciellt för granskning av testkörningsresultaten.

Vanliga frågor

En bugg är konsekvensen/resultatet av ett kodningsfel.

A Defekt i mjukvarutestning är en variation eller avvikelse av programvaran från slutanvändarens krav eller ursprungliga affärskrav. Ett programvarufel är ett fel i kodningen som orsakar felaktiga eller oväntade resultat från ett program som inte uppfyller faktiska krav. Testare kan stöta på sådana defekter när de utför testfallen.

Dessa två termer har mycket tunna skillnader, i branschen är båda fel som måste åtgärdas och används omväxlande av några av de Testning lag.

När testare utför testfallen kan de stöta på sådana testresultat som strider mot förväntade resultat. Denna variation i testresultat kallas för ett programvarufel. Dessa defekter eller variationer hänvisas till med olika namn i olika organisationer som problem, problem, buggar eller incidenter.

En felrapport i mjukvarutestning är ett detaljerat dokument om buggar som finns i programvaran. Bugrapporten innehåller varje detalj om buggar som beskrivning, datum när felet hittades, namnet på testaren som hittade det, namnet på utvecklaren som fixade det, etc. Bugrapporten hjälper till att identifiera liknande buggar i framtiden så att det kan undvikas.

Defekt_ID – Unikt identifikationsnummer för defekten.
defekt Description – Detaljerad beskrivning av defekten inklusive information om den modul i vilken defekten upptäcktes.
Version – Version av applikationen där defekten upptäcktes.
Steg - Detaljerade steg tillsammans med skärmdumpar med vilka utvecklaren kan återskapa defekterna.
Datum höjt – Datum då defekten uppstår
Referens- var i dig Ange referens till dokument som . krav, design, arkitektur eller kanske till och med skärmdumpar av felet för att förstå felet
Upptäckt av – Namn/ID på testaren som tog upp defekten
Status - Status för defekten, mer om detta senare
Fixat av – Namn/ID på utvecklaren som fixade det
Datum stängt – Datum då defekten är avslutad
Svårighetsgraden som beskriver felets inverkan på applikationen
Budget som är relaterat till brådskande åtgärdande av defekter. Allvarlighetsprioritet kan vara Hög/Medel/Låg baserat på hur brådskande defekten ska åtgärdas.

Klicka här. om videon inte är tillgänglig

Resurser:

Ladda ner ett exempel på mall för felrapportering