Mis on viga?
Viga on kodeerimisvea tagajärg / tulemus.
Tarkvara testimise defekt
Defekt Tarkvara testimine on variatsioon või kõrvalekalle tarkvara rakendus lõppkasutaja nõuetele või originaal äri nõuetele. Tarkvara defekt on viga kodeerimisel, mis põhjustab tegelikele nõuetele mittevastava tarkvaraprogrammi valesid või ootamatuid tulemusi. Testijad võivad selliste juhtumitega kokku puutuda testide läbiviimisel.
Nendel kahel terminil on väga õhuke erinevuste rida. Tööstuses on mõlemad vead, mis tuleb parandada, ja nii mõnigi testimisrühm kasutab neid omavahel.
Kui testijad teste sooritavad, võivad nad kohata selliseid testitulemusi, mis on vastuolus oodatavate tulemustega. Sellele testitulemuste variatsioonile viidatakse kui tarkvara defektile. Nendele defektidele või variatsioonidele viidatakse erinevates organisatsioonides erinevatel nimedel, näiteks probleemid, probleemid, vead või juhtumid.
Selles õpetuses saate teada
- Veateade
- Defektide haldamise protsess
- Avastus
- Liigitamine
- Resolutsioon
- Kontrollimine
- Sulgemine
- Aruandlus
- Oluline defektide mõõdik
Veateade tarkvara testimisel
Vearaport Tarkvara testimine on üksikasjalik dokument umbes vead leiti tarkvara rakendus. Veaaruanne sisaldab kõiki vigade üksikasju, nagu kirjeldus, vea leidmise kuupäev, selle leidnud testija nimi, selle parandanud arendaja nimi jne. Veaaruanne aitab tulevikus sarnaseid vigu tuvastada, nii et seda saab vältida.
Veast arendajale teatades peaks teie veaaruanne sisaldama järgmist teavet
- Defect_ID - defekti kordumatu identifitseerimisnumber.
- Defekti kirjeldus - defekti üksikasjalik kirjeldus, sealhulgas teave mooduli kohta, milles defekt leiti.
- Versioon - rakenduse versioon, milles defekt leiti.
- Sammud - üksikasjalikud sammud koos ekraanipiltidega, millega arendaja saab defekte taasesitada.
- Kuupäev tõstatatud - vea tõstatamise kuupäev
- Viide - kus on Teil viide sellistele dokumentidele. nõuded, disain, arhitektuur või võib-olla isegi vea ekraanipildid, mis aitavad defektist aru saada
- Detected By - defekti tõstatanud testija nimi / ID
- Staatus - defekti olek, täpsemalt sellest hiljem
- Parandatud - selle parandanud arendaja nimi / ID
- Suletud kuupäev - defekti sulgemise kuupäev
- Tõsidus, mis kirjeldab defekti mõju rakendusele
- Prioriteet, mis on seotud defektide kõrvaldamise kiireloomulisusega. Tõsiduse prioriteet võib olla kõrge / keskmine / madal, lähtudes löögi kiireloomulisusest, mille korral defekt tuleks vastavalt fikseerida
Kui videole pole juurdepääsu, klõpsake siin
Ressursid
Laadige alla defektide aruandluse malli näidis
Mõelge testihaldurina järgmisele
Teie meeskond leidis Guru99 panganduse projekti testimisel vigu.
Nädala pärast vastab arendaja -
Järgmisel nädalal vastab testija
Nagu ülalnimetatud juhul, kui defektidega suhtlemine toimub suuliselt, muutuvad asjad varsti väga keeruliseks. Vigade kontrollimiseks ja tõhusaks haldamiseks vajate defekti elutsüklit.
Mis on defektide haldamise protsess?
Defektide haldamine on süstemaatiline protsess vigade tuvastamiseks ja parandamiseks. Defektide haldamise tsükkel sisaldab järgmisi etappe: 1) defektide avastamine, 2) defektide kategoriseerimine 3) defektide parandamine arendajate poolt 4) kontrollimine testijate poolt, 5) defektide sulgemine 6) defektide aruanded projekti lõpus
See teema juhendab teid, kuidas rakendada defektide haldamise protsessi projekti Guru99 Bank veebisaidil. Defektide haldamiseks võite järgida alltoodud samme.
Avastus
Avastamisfaasis peavad projekti meeskonnad avastama võimalikult palju defekte , enne kui lõpptarbija selle avastab. Defekt on väidetavalt avastanud ja muutus status vastuvõtt , kui see on tunnustatud ja aktsepteeritud arendajad
Ülaltoodud stsenaariumi korral avastasid testijad veebisaidil Guru99 84 defekti.
Vaatame järgmist stsenaariumi; teie testimeeskond avastas Guru99 panga veebisaidil mõned probleemid. Nad peavad neid defektideks ja teatasid arendusmeeskonnale, kuid seal on konflikt -
Mida te sellisel juhul testijuhina teete?
A) Nõustuge testimeeskonnaga, et see on defekt
B) Testijuht võtab kohtuniku rolli, et otsustada, kas probleem on puudus või mitte
C) leppige arendusmeeskonnaga kokku, et tegemist pole defektiga Correct InCorrect
Sellisel juhul tuleks konflikti lahendamiseks rakendada lahendamisprotsessi. Te võtate kohtuniku rolli otsustamaks, kas veebisaidi probleem on defekt või mitte.
Liigitamine
Defektide kategoriseerimine aitab tarkvaraarendajatel oma ülesandeid tähtsuse järjekorda seada. See tähendab, et selline prioriteet aitab arendajatel esmalt need ülitähtsad vead parandada.
Defektid kategoriseerib testihaldur tavaliselt -
Teeme väikese harjutuse järgmiselt allpool lohistades vigade prioriteedi
- Kriitiline
- Kõrge
- Keskmine
- Madal
| 1) Veebisaidi jõudlus on liiga aeglane |
|
| 2) Veebisaidi sisselogimisfunktsioon ei tööta korralikult |
|
| 3) Veebisaidi GUI ei kuvata mobiilseadmetes õigesti |
|
| 4) Veebisait ei mäletanud kasutaja sisselogimisseanssi |
|
| 5) Mõned lingid ei tööta |
|
Siin on soovitatavad vastused
| Ei | Kirjeldus | Prioriteet | Selgitus |
|---|---|---|---|
| 1 | Veebisaidi jõudlus on liiga aeglane | Kõrge | Jõudlusviga võib põhjustada kasutajale suuri ebamugavusi. |
| 2 | Veebisaidi sisselogimisfunktsioon ei tööta korralikult | Kriitiline | Sisselogimine on üks panganduse veebisaidi põhifunktsioone, kui see funktsioon ei toimi, see on tõsised vead |
| 3 | Veebisaidi GUI ei kuvata mobiilseadmetes õigesti | Keskmine | Defekt mõjutab kasutajat, kes kasutab veebisaidi vaatamiseks nutitelefoni. |
| 4 | Veebisait ei mäletanud kasutaja sisselogimisseanssi | Kõrge | See on tõsine probleem, kuna kasutaja saab sisse logida, kuid ei saa teha täiendavaid tehinguid |
| 5 | Mõni link ei tööta | Madal | See on arenduspoiste jaoks lihtne lahendus ja kasutaja saab saidile siiski ilma nende linkideta juurde pääseda |
Defektide lahendamine
Defektide lahendamine tarkvara testimisel on defektide kõrvaldamine samm-sammult. Defektide lahendamise protsess algab defektide määramisega arendajatele, seejärel arendajad kavandavad defekti fikseerimise prioriteediks, seejärel defektid fikseeritakse ja lõpuks saadavad arendajad testijuhile lahenduse aruande. See protsess aitab defekte hõlpsalt parandada ja jälgida.
Defekti kõrvaldamiseks võite järgida järgmisi samme.
- Ülesanne : määratud parandamiseks arendajale või muule tehnikule ja muutis olekuks vastamise .
- Ajakava parandamine : selles etapis võtab vastutuse arendaja pool. Nad loovad ajakava nende defektide kõrvaldamiseks, sõltuvalt defekti prioriteedist.
- Defekti parandamine : kui arendustiim parandab defekte, jälgib testihaldur defekti parandamise protsessi võrreldes ülaltoodud ajakavaga.
- Teata lahendusest : kui defektid on fikseeritud, saate arendajatelt resolutsiooni aruande.
Kontrollimine
Pärast arendusmeeskond fikseeritud ja teatatud defekti testimise meeskond kontrollib , et vead on tegelikult lahendatud.
Näiteks ülaltoodud stsenaariumi korral, kui arendusmeeskond teatas, et nad on juba 61 defekti parandanud, testis teie meeskond uuesti, et kontrollida, kas need defektid on tegelikult parandatud või mitte.
Sulgemine
Kui defekt on lahendatud ja kontrollitud, muudetakse defekti olekuks suletud . Kui ei, siis olete saatnud arendusele teate defekti uuesti kontrollimiseks.
Defektidest teatamine
Defektiaruandlus tarkvara testimisel on protsess, mille käigus testijuhid koostavad ja saadavad defektide aruande juhtimismeeskonnale defektide haldamise protsessi ja defektide seisundi kohta tagasiside saamiseks. Seejärel kontrollib juhtkond defektiaruannet ja saadab tagasisidet või pakub vajadusel täiendavat tuge. Vigadest teatamine aitab paremini suhelda, defekte üksikasjalikult jälgida ja selgitada.
Juhatusel on õigus teada defekti staatust. Nad peavad mõistma defektide haldamise protsessi, et teid selles projektis toetada. Seetõttu peate neile tagasiside saamiseks teatama praegusest defektisituatsioonist.
Oluline defektide mõõdik
Tagasi ülaltoodud stsenaariumi juurde. Arendajal ja testimeeskondadel on teatatud defektid üle vaadatud. Siin on selle arutelu tulemus
Kuidas mõõta ja hinnata testi täitmise kvaliteeti?
See on küsimus, mida iga testijuht tahab teada. Seal on 2 parameetrit, mida võite pidada järgmisteks
Ülaltoodud stsenaariumi korral saate arvutada, et defektide tagasilükkamise suhe (DRR) on 20/84 = 0,238 (23,8%).
Teine näide, mille kohaselt peaks Guru99 Banki veebisaidil olema kokku 64 viga, kuid teie testimisrühm tuvastab ainult 44 viga, st neil oli 20 puudust . Seetõttu saate arvutada defektide lekkearvu (DLR) 20/64 = 0,312 (31,2%).
Kokkuvõtteks võib öelda, et testi täitmise kvaliteeti hinnatakse kahe parameetri abil
Mida väiksem on DRR ja DLR väärtus, seda parem on testide teostamise kvaliteet. Mis suhe on vastuvõetav ? Selle vahemiku võiks määratleda ja aktsepteerida projekti sihtmärgina või võite viidata sarnaste projektide mõõdikutele.
Selles projektis on vastuvõetava suhte soovitatav väärtus 5 ~ 10%. See tähendab, et testi täitmise kvaliteet on madal. Nende suhtarvude vähendamiseks peaksite leidma vastumeetmed, näiteks
- Parandage liikme testimisoskusi.
- Kulutage rohkem aega täitmise testimiseks, eriti testi täitmise tulemuste ülevaatamiseks.