🏅 Kako radi GPU rudarenje?

GPU je važna jedinica računala koja je odgovorna za renderiranje i prikazivanje slika i videa. Jedinice za grafičku obradu optimizirane su za obradu velikih blokova podataka. Stoga je bolji od CPU-a za rudarenje. Ako rudarite bilo koju kriptovalutu s GPU-om, ne trebate se često prebacivati između dva zadatka. Dakle, može obraditi više hasheva istovremeno.

✅ Izvješće o pogrešci u testiranju softvera

Izvješće o greškama u testiranju softvera detaljan je dokument o greškama pronađenim u softverskoj aplikaciji. Izvješće o pogreškama sadrži svaki detalj o pogreškama kao što su opis, datum kada je pogreška pronađena, ime testera koji ju je pronašao, ime programera koji ju je popravio itd. Izvješće o pogrešci pomaže identificirati slične pogreške u budućnosti kako bi se mogle izbjeći. Defect_ID – Jedinstveni identifikacijski broj kvara. Mana Description – Detaljan opis kvara uključujući podatke o modulu u kojem je kvar pronađen. Verzija – Verzija aplikacije u kojoj je pronađen kvar. Koraci – Detaljni koraci zajedno sa snimkama zaslona pomoću kojih programer može reproducirati nedostatke. Datum podizanja – Datum kada je nedostatak istaknut Referenca– gdje u vama Navedite reference na dokumente poput . zahtjeve, dizajn, arhitekturu ili možda čak i snimke zaslona pogreške kako biste lakše razumjeli nedostatak Otkrio – Ime/ID ispitivača koji je ukazao na nedostatak Status - Status kvara, više o tome kasnije Popravio – Ime/ID programera koji je to popravio Datum zatvaranja – Datum zatvaranja kvara Ozbiljnost koji opisuje utjecaj kvara na aplikaciju Prioritet što je povezano s hitnošću otklanjanja kvara. Prioritet ozbiljnosti može biti visok/srednji/nizak na temelju hitnosti utjecaja pri kojoj bi kvar trebao biti popravljen

Proces upravljanja greškama u testiranju softvera

Što je proces upravljanja greškama?

Upravljanje greškama je sustavan proces za prepoznavanje i ispravljanje grešaka. Ciklus upravljanja nedostacima sadrži sljedeće faze 1) Otkrivanje nedostataka, 2) Kategorizacija nedostataka 3) Popravljanje nedostataka od strane programera 4) Provjera od strane testera, 5) Zatvaranje nedostataka 6) Izvješća o nedostacima na kraju projekta

Ova tema će vas uputiti kako primijeniti proces upravljanja nedostacima na web stranicu projekta Guru99 Bank. Možete slijediti korake u nastavku za upravljanje nedostacima.

Korak 1) Otkriće

U fazi otkrivanja, projektni timovi moraju otkriti kao mnogi nedostatke kao moguće, prije nego što ga krajnji kupac otkrije. Kaže se da se nedostatak otkrije i promijeni status primljen kada to programeri priznaju i prihvate

U gornjem scenariju, testeri su otkrili 84 nedostatka na web stranici Guru99.

Pogledajmo sljedeći scenarij; vaš tim za testiranje otkrio je neke probleme na web stranici Guru99 banke. Smatraju ih nedostacima i prijavljuju razvojnom timu, ali postoji sukob –

U tom slučaju, što ćete učiniti kao voditelj testiranja?

A) Složite se s testnim timom da je to nedostatak

B) Test Manager preuzima ulogu suca koji odlučuje je li problem nedostatak ili ne

C) Dogovorite se s razvojnim timom da nije kvar

ispravan

Netočno

U tom slučaju treba primijeniti postupak rješavanja sukoba, a vi preuzimate ulogu suca koji će odlučiti je li problem na web stranici nedostatak ili ne.

Korak 2) Kategorizacija

Kategorizacija nedostataka pomaže programerima softvera da odrede prioritete svojih zadataka. To znači da ova vrsta prioriteta pomaže programerima da prvo poprave one nedostatke koji su vrlo ključni.

Nedostatke obično kategorizira voditelj testiranja –

Napravimo malu vježbu kako slijedi

Povucite i ispustite prioritet kvara u nastavku

1) Izvedba web stranice je prespora
2) Funkcija prijave na web stranici ne radi ispravno
3) GUI web stranice ne prikazuje se ispravno Mobilni uređaji
4) Web stranica nije mogla zapamtiti sesiju prijave korisnika
5) Neki linkovi ne rade

Evo preporučenih odgovora

Ne.	Description	Prioritet	Objašnjenje
1	Izvedba web stranice je prespora	visok	Greška u izvedbi može uzrokovati velike neugodnosti korisniku.
2	Funkcija prijave na web mjesto ne radi ispravno	Kritično	Prijava je jedna od glavnih funkcija bankovne web stranice ako ova značajka ne radi, to su ozbiljne greške
3	GUI web stranice ne prikazuje se ispravno na mobilnim uređajima	Srednji	Kvar utječe na korisnika koji koristi pametni telefon za pregled web stranice.
4	Web stranica se nije mogla sjetiti sesije prijave korisnika	visok	Ovo je ozbiljan problem jer će se korisnik moći prijaviti, ali neće moći izvršiti daljnje transakcije
5	Neki linkovi ne rade	Nizak	Ovo je jednostavno rješenje za razvojne programere, a korisnik i dalje može pristupiti stranici bez ovih poveznica

Korak 3) Rješavanje kvarova

Rješavanje kvarova u testiranju softvera je korak po korak proces popravljanja nedostataka. Proces rješavanja nedostataka počinje dodjeljivanjem nedostataka programerima, zatim programeri planiraju popraviti nedostatak prema prioritetu, zatim se nedostaci popravljaju i na kraju programeri šalju izvješće o rješavanju upravitelju testiranja. Ovaj postupak pomaže u lakom popravljanju i praćenju nedostataka.

Možete slijediti sljedeće korake kako biste popravili kvar.

Raspored: Dodijeljeno programeru ili drugom tehničaru za popravak i promijenjen status u Odgovarajući.
Popravljanje rasporeda: Razvojna strana preuzima odgovornost u ovoj fazi. Oni će izraditi raspored za popravljanje tih nedostataka, ovisno o prioritetu kvara.
Popravite kvar: Dok razvojni tim popravlja nedostatke, Test Manager prati proces popravljanja nedostataka u usporedbi s gornjim rasporedom.
Prijavite rješenje: Dobijte izvješće o razrješenju od programera kada se nedostaci poprave.

Korak 4) Provjera

Nakon razvojnog tima fiksna i izvijestio kvar, tim za testiranje provjerava da su nedostaci stvarno riješeni.

Na primjer, u gornjem scenariju, kada je razvojni tim izvijestio da je već popravio 61 nedostatak, vaš bi tim ponovno testirao kako bi provjerio jesu li ti nedostaci stvarno popravljeni ili ne.

Korak 5) Zatvaranje

Nakon što je kvar riješen i verificiran, status kvara se mijenja kao zatvoreno. Ako nije, morate poslati obavijest razvoju da ponovno provjeri kvar.

Korak 6) Prijava kvarova

Prijava kvarova u softverskom testiranju je proces u kojem voditelji testiranja pripremaju i šalju izvješće o nedostacima upravljačkom timu za povratnu informaciju o procesu upravljanja nedostacima i statusu defekata. Zatim upravljački tim provjerava izvješće o kvaru i šalje povratne informacije ili pruža dodatnu podršku ako je potrebno. Izvješćivanje o kvarovima pomaže u boljoj komunikaciji, praćenju i detaljnom objašnjenju kvarova.

Uprava ima pravo znati status kvara. Oni moraju razumjeti proces upravljanja nedostacima kako bi vam pomogli u ovom projektu. Stoga im morate prijaviti trenutnu situaciju kvara kako biste od njih dobili povratne informacije.

Zašto vam je potreban proces upravljanja greškama?

Vaš tim je pronašao greške tijekom testiranja projekta Guru99 Banking.

Nakon tjedan dana programer odgovara –

Sljedeći tjedan odgovara tester

Kao u gornjem slučaju, ako se komunikacija s nedostatkom odvija verbalno, stvari ubrzo postaju vrlo komplicirane. Za kontrolu i učinkovito upravljanje greškama potreban vam je životni ciklus greške.

Važna metrika kvarova

Povratak na gornji scenarij. Razvojni i testni timovi pregledavaju prijavljene nedostatke. Evo rezultata te rasprave

Kako izmjeriti i ocijeniti kvalitetu izvođenja testa?

Ovo je pitanje koje svaki Voditelj ispitivanja želi znati. Postoje 2 parametra koja možete razmotriti kao sljedeće

U gornjem scenariju možete izračunati omjer odbijanja prebjega (DRR) je 20/84 = 0.238 (23.8 %).

Još jedan primjer, pretpostavimo da web stranica banke Guru99 ima ukupno 64 nedostatke, ali vaš tim za testiranje samo otkriva 44 nedostatke tj. promašili su 20 defekti. Stoga možete izračunati da je omjer curenja kvara (DLR) 20/64 = 0.312 (31.2%).

Zaključak, kvaliteta izvedbe testa ocjenjuje se pomoću sljedeća dva parametra

Što je manja vrijednost DRR-a i DLR-a, to je bolja kvaliteta izvršenja testa. Koji je raspon omjera koji je prihvatljiv? Ovaj raspon može biti definirana i prihvaćena baza u cilju projekta ili se možete pozvati na metriku sličnih projekata.

U ovom projektu preporučena vrijednost prihvatljivog omjera je 5 ~ 10%. To znači da je kvaliteta izvršenja testa niska. Trebali biste pronaći protumjere za smanjenje ovih omjera kao što su

Poboljšati vještina testiranja člana.
Provesti više vremena za testiranje izvršenja, posebno za pregled rezultata izvršenja testa.

PITANJA I ODGOVORI

Greška je posljedica/ishod greške kodiranja.

A Greška u testiranju softvera je varijacija ili odstupanje softverske aplikacije od zahtjeva krajnjeg korisnika ili izvornih poslovnih zahtjeva. Softverski defekt je pogreška u kodiranju koja uzrokuje netočne ili neočekivane rezultate softverskog programa koji ne ispunjava stvarne zahtjeve. Testeri bi mogli naići na takve nedostatke tijekom izvođenja testnih slučajeva.

Ova dva pojma imaju vrlo tanku liniju razlike. U industriji oba su greške koje se moraju popraviti i tako ih naizmjenično koriste neki od Ispitivanje timovi.

Kada ispitivači izvršavaju testne slučajeve, mogli bi naići na rezultate testa koji su kontradiktorni očekivanim rezultatima. Ova varijacija u rezultatima testiranja naziva se kvar softvera. Ovi nedostaci ili varijacije se u različitim organizacijama nazivaju različitim imenima, kao što su problemi, greške ili incidenti.

Izvješće o greškama u testiranju softvera detaljan je dokument o greškama pronađenim u softverskoj aplikaciji. Izvješće o pogreškama sadrži svaki detalj o pogreškama kao što su opis, datum kada je pogreška pronađena, ime testera koji ju je pronašao, ime programera koji ju je popravio itd. Izvješće o pogrešci pomaže identificirati slične pogreške u budućnosti kako bi se mogle izbjeći.

Defect_ID – Jedinstveni identifikacijski broj kvara.
Mana Description – Detaljan opis kvara uključujući podatke o modulu u kojem je kvar pronađen.
Verzija – Verzija aplikacije u kojoj je pronađen kvar.
Koraci – Detaljni koraci zajedno sa snimkama zaslona pomoću kojih programer može reproducirati nedostatke.
Datum podizanja – Datum kada je nedostatak istaknut
Referenca– gdje u vama Navedite reference na dokumente poput . zahtjeve, dizajn, arhitekturu ili možda čak i snimke zaslona pogreške kako biste lakše razumjeli nedostatak
Otkrio – Ime/ID ispitivača koji je ukazao na nedostatak
Status - Status kvara, više o tome kasnije
Popravio – Ime/ID programera koji je to popravio
Datum zatvaranja – Datum zatvaranja kvara
Ozbiljnost koji opisuje utjecaj kvara na aplikaciju
Prioritet što je povezano s hitnošću otklanjanja kvara. Prioritet ozbiljnosti može biti visok/srednji/nizak na temelju hitnosti utjecaja pri kojoj bi kvar trebao biti popravljen

Kliknite ovdje ako video nije dostupan

Resursi:

Preuzmite uzorak predloška za prijavu kvarova

Možda ti se svidi: