Kas ir kļūda?
Kļūda ir kodēšanas kļūdas sekas / rezultāts.
Programmatūras testēšanas defekts
Defektu programmatūras testēšana ir variācija vai novirze no lietojumprogrammatūras no gala lietotāja prasībām vai oriģināliem biznesa prasībām. Programmatūras defekts ir kļūda kodēšanā, kas rada nepareizus vai negaidītus rezultātus no programmatūras, kas neatbilst faktiskajām prasībām. Testētāji, izpildot pārbaudes gadījumus, varētu saskarties ar šādiem defektiem.
Šiem abiem terminiem ir ļoti plāna atšķirību līnija. Rūpniecībā abas ir kļūdas, kuras ir jānovērš, un tāpēc dažas testēšanas komandas izmanto savstarpēju apmaiņu.
Testētāji, izpildot pārbaudes gadījumus, var saskarties ar tādiem testa rezultātiem, kas ir pretrunā ar gaidāmajiem rezultātiem. Šī testa rezultātu variācija tiek saukta par programmatūras defektu. Šos defektus vai variācijas dažādās organizācijās norāda dažādi nosaukumi, piemēram, jautājumi, problēmas, kļūdas vai starpgadījumi.
Šajā apmācībā jūs uzzināsiet
- Kļūdu ziņojums
- Defektu pārvaldības process
- Atklāšana
- Kategorizēšana
- Izšķirtspēja
- Pārbaude
- Slēgšana
- Ziņošana
- Svarīga defektu metrika
Kļūdu ziņojums programmatūras testēšanā
Blusas pārskats Programmatūras testēšana ir detalizēts dokuments par kļūdām atrodamas lietojumprogrammas. Kļūdu pārskatā ir sniegta katra informācija par kļūdām, piemēram, apraksts, datums, kad kļūda tika atrasta, pārbaudītāja vārds, kurš to atrada, izstrādātāja vārds, kurš to novērsa, utt. Kļūdu pārskats palīdz identificēt līdzīgas kļūdas nākotnē, lai no tā varētu izvairīties.
Ziņojot par kļūdu izstrādātājam, kļūdu pārskatā jāietver šāda informācija
- Defect_ID - unikāls defekta identifikācijas numurs.
- Defekta apraksts - detalizēts defekta apraksts, ieskaitot informāciju par moduli, kurā tika atrasts defekts.
- Versija - tās lietojumprogrammas versija, kurā tika atrasts defekts.
- Soļi - detalizētas darbības kopā ar ekrānuzņēmumiem, ar kuriem izstrādātājs var reproducēt defektus.
- Date Raised - datums, kad defekts tiek uzrādīts
- Atsauce - kur jūs norādiet norādi uz līdzīgiem dokumentiem. prasības, dizains, arhitektūra vai varbūt pat kļūdas ekrānšāviņi, lai palīdzētu saprast defektu
- Detected By - pārbaudītāja vārds / ID, kurš konstatēja defektu
- Statuss - defekta statuss, vairāk par to vēlāk
- Fixed by - izstrādātāja vārds / ID, kurš to laboja
- Closed Date - datums, kad defekts ir aizvērts
- Smagums, kas raksturo defekta ietekmi uz lietojumu
- Prioritāte, kas saistīta ar steidzamu defektu novēršanu. Smaguma prioritāte varētu būt augsta / vidēja / zema, pamatojoties uz trieciena steidzamību, kurā attiecīgi jānosaka defekts
Noklikšķiniet šeit, ja videoklips nav pieejams
Resursi
Lejupielādējiet defektu ziņošanas veidnes paraugu
Apsveriet sekojošo kā testa pārvaldnieku
Pārbaudot Guru99 Banking projektu, jūsu komanda atrada kļūdas.
Pēc nedēļas izstrādātājs atbild -
Nākamajā nedēļā testētājs atbild
Tāpat kā iepriekš minētajā gadījumā, ja defektu komunikācija tiek veikta mutiski, drīz viss kļūst ļoti sarežģīts. Lai kontrolētu un efektīvi pārvaldītu kļūdas, jums ir nepieciešams defektu dzīves cikls.
Kas ir defektu pārvaldības process?
Defektu pārvaldība ir sistemātisks process kļūdu identificēšanai un novēršanai. Defektu pārvaldības ciklā ietilpst šādi posmi: 1) defektu atklāšana, 2) defektu kategorizēšana 3) defektu novēršana, ko veic izstrādātāji, 4) pārbaude, ko veic testētāji, 5) defektu slēgšana, 6) defektu ziņojumi projekta beigās
Šī tēma palīdzēs jums uzzināt, kā piemērot defektu pārvaldības procesu projekta Guru99 Bank vietnē. Lai pārvaldītu defektus, varat veikt tālāk norādītās darbības.
Atklāšana
Atklāšanas posmā projekta komandām ir jāatklāj pēc iespējas vairāk defektu , pirms galīgais klients to var atklāt. Šādu bojājumu esot atklāts, un izmaiņas statusā pieņemts , ja tas ir atzīts un pieņemts ar izstrādātājiem
Iepriekšminētajā scenārijā testētāji atklāja 84 defektus vietnē Guru99.
Apskatīsim šādu scenāriju; jūsu testēšanas komanda atklāja dažus jautājumus Guru99 bankas vietnē. Viņi tos uzskata par defektiem un ziņo izstrādes komandai, taču pastāv konflikts -
Šādā gadījumā kā testu vadītājs jūs darīsit?
A) Vienojieties ar testa komandu, ka tas ir defekts
B) Testu vadītājs veic tiesneša lomu, lai izlemtu, vai problēma ir nepilnīga
C) Vienojieties ar izstrādes komandu, kas nav defekts Correct InCorrect
Šādā gadījumā konflikta risināšanai jāpiemēro izšķiršanas process. Jums jāpiedalās tiesneša lomā, lai izlemtu, vai vietnes problēma ir vai nav defekts.
Kategorizēšana
Defektu kategorizēšana palīdz programmatūras izstrādātājiem noteikt viņu uzdevumu prioritāti. Tas nozīmē, ka šāda veida prioritāte palīdz izstrādātājiem vispirms novērst tos ļoti svarīgos defektus.
Testu pārvaldnieks defektus parasti iedala kategorijās -
Veiksim nelielu vingrinājumu, kā parādīts zemāk, nosakot defektu prioritāti
- Kritisks
- Augsts
- Vidējs
- Zems
| 1) Vietnes veiktspēja ir pārāk lēna |
|
| 2) Vietnes pieteikšanās funkcija nedarbojas pareizi |
|
| 3) Vietnes GUI netiek pareizi parādīta mobilajās ierīcēs |
|
| 4) Vietne nevarēja atcerēties lietotāja pieteikšanās sesiju |
|
| 5) Dažas saites nedarbojas |
|
Šeit ir ieteicamās atbildes
| Nē. | Apraksts | Prioritāte | Paskaidrojums |
|---|---|---|---|
| 1 | Vietnes veiktspēja ir pārāk lēna | Augsts | Veiktspējas kļūda var radīt milzīgas neērtības lietotājam. |
| 2 | Vietnes pieteikšanās funkcija nedarbojas pareizi | Kritisks | Pieteikšanās ir viena no galvenajām bankas vietnes funkcijām, ja šī funkcija nedarbojas, tā ir nopietnas kļūdas |
| 3 | Vietnes GUI netiek pareizi parādīta mobilajās ierīcēs | Vidējs | Defekts ietekmē lietotāju, kurš izmanto viedtālruni, lai apskatītu vietni. |
| 4 | Vietne nevarēja atcerēties lietotāja pieteikšanās sesiju | Augsts | Šī ir nopietna problēma, jo lietotājs varēs pieteikties, bet nevarēs veikt turpmākus darījumus |
| 5 | Dažas saites nedarbojas | Zems | Tas ir viegli labojams izstrādes puišiem, un lietotājs joprojām var piekļūt vietnei bez šīm saitēm |
Defektu izšķiršana
Defektu izšķiršana programmatūras testēšanā ir soli pa solim defektu novēršana. Defektu novēršanas process sākas ar defektu piešķiršanu izstrādātājiem, pēc tam izstrādātāji plāno defektu novērst pēc prioritātes, pēc tam defekti tiek novērsti, un visbeidzot izstrādātāji testa pārvaldniekam nosūta izšķirtspējas ziņojumu. Šis process palīdz viegli novērst un izsekot defektus.
Lai novērstu defektu, varat veikt šādas darbības.
- Uzdevums : piešķirts izstrādātājam vai citam tehniķim, kas to labo, un mainīja statusu uz Atbildēt .
- Grafika labošana : šajā posmā atbildību uzņemas izstrādātāja puse. Viņi izveidos grafiku šo defektu novēršanai, atkarīgs no defekta prioritātes.
- Novērst defektu : Kamēr izstrādes komanda novērš defektus, Testa pārvaldnieks izseko defekta novēršanas procesu salīdzinājumā ar iepriekš minēto grafiku.
- Ziņot par izšķirtspēju : pēc defektu novēršanas saņemiet izstrādātāju ziņojumu par izšķirtspēju.
Pārbaude
Pēc izstrādes komandas fiksēto un ziņo par defektu, testēšanas komanda pārbauda , ka defekti ir faktiski atrisināt.
Piemēram, iepriekš minētajā scenārijā, kad izstrādes komanda ziņoja, ka jau ir novērsusi 61 defektu, jūsu komanda vēlreiz pārbaudīs, vai šie defekti tiešām ir novērsti vai nav.
Slēgšana
Kad defekts ir novērsts un pārbaudīts, defekta statuss tiek mainīts kā slēgts . Ja nē, jums ir jānosūta paziņojums attīstībai, lai vēlreiz pārbaudītu defektu.
Ziņošana par defektiem
Defektu ziņošana programmatūras testēšanā ir process, kurā testu vadītāji sagatavo un nosūta defektu ziņojumu vadības komandai, lai saņemtu atsauksmes par defektu pārvaldības procesu un defektu statusu. Tad vadības komanda pārbauda defektu ziņojumu un, ja nepieciešams, nosūta atsauksmes vai sniedz papildu atbalstu. Defektu ziņošana palīdz labāk sazināties, izsekot un detalizēti izskaidrot defektus.
Valdei ir tiesības zināt defekta statusu. Viņiem ir jāsaprot defektu pārvaldības process, lai jūs atbalstītu šajā projektā. Tāpēc jums jāziņo viņiem par pašreizējo defektu situāciju, lai saņemtu no viņiem atsauksmes.
Svarīga defektu metrika
Atpakaļ uz iepriekš minēto scenāriju. Izstrādātājs un testēšanas komandas pārskata paziņotos defektus. Lūk, šīs diskusijas rezultāts
Kā izmērīt un novērtēt testa izpildes kvalitāti?
Šis ir jautājums, kuru vēlas uzzināt katrs testa vadītājs. Ir 2 parametri, kurus varat uzskatīt par šādiem
Iepriekš minētajā scenārijā jūs varat aprēķināt defektu noraidīšanas koeficientu (DRR), kas ir 20/84 = 0,238 (23,8%).
Cits piemērs, domājams, ka Guru99 bankas vietnē ir kopā 64 defekti, taču jūsu testēšanas komanda atklāj tikai 44 defektus, ti, viņiem trūka 20 defektu. Tāpēc jūs varat aprēķināt defektu noplūdes koeficientu (DLR) 20/64 = 0,312 (31,2%).
Secinājums: testa izpildes kvalitāte tiek vērtēta, izmantojot divus parametrus
Jo mazāka DRR un DLR vērtība, jo labāka ir testa izpildes kvalitāte. Kāds ir pieņemamais attiecību diapazons ? Šo diapazonu varētu definēt un pieņemt projekta mērķa bāzē, vai arī varat atsaukties uz līdzīgu projektu metriku.
Šajā projektā ieteicamā pieņemamās attiecības vērtība ir 5 ~ 10%. Tas nozīmē, ka testa izpildes kvalitāte ir zema. Jums vajadzētu atrast pretpasākumus, lai samazinātu šos koeficientus, piemēram,
- Uzlabot dalībnieka testēšanas prasmes.
- Veltiet vairāk laika izpildes pārbaudei, īpaši testa izpildes rezultātu pārskatīšanai.