TESTIPLAAN Tarkvara testimises (näide)

Katseplaan

A Katseplaan on üksikasjalik dokument, mis kirjeldab tarkvaratoote testimisstrateegiat, eesmärke, ajakava, hinnangut, tulemusi ja ressursse, mis on vajalikud tarkvaratoote testimiseks. Testimisplaan aitab meil kindlaks määrata testitava rakenduse kvaliteedi valideerimiseks vajaliku pingutuse. Testimisplaan on kavandiks tarkvara testimise tegevuste läbiviimiseks määratletud protsessina, mida testijuht hoolikalt jälgib ja kontrollib.

ISTQB definitsiooni kohaselt on testimisplaan dokument, mis kirjeldab kavandatud testimistegevuste ulatust, lähenemisviisi, ressursse ja ajakava.

Alustame järgmise testiplaani näite/stsenaariumiga: Koosolekul soovite meeskonnaliikmetega testiplaani arutada, kuid nad pole huvitatud.

Mida sa sellisel juhul teed? Vali oma vastus nagu näidatud järgmisel joonisel.

👉 Registreeru tasuta reaalajas tarkvara testimise projektile

Mis on testimisplaani tähtsus?

Testiplaani dokumendi koostamisel on mitu eelist.

• Aidata testimismeeskonnast väljaspool olevaid inimesi, näiteks arendajaid, ärijuhte ja kliente, mõistma testimise üksikasjad.
• Katseplaan juhikuid meie mõtlemine. See on nagu reegliteraamat, mida tuleb järgida.
• Olulised aspektid, nagu testi hindamine, testi ulatus, Testistrateegia See on dokumenteeritud testimisplaanis, et juhtkond saaks seda üle vaadata ja teistes projektides uuesti kasutada.

Testiplaanide tüübid

Neid on kolme peamist tüüpi Katseplaanid tarkvara testimises.

1. Põhitesti plaan: Üldine dokument, mis kirjeldab üldist testimisstrateegiat, ulatust, ressursse ja ajakava kõigi testimistasemete jaoks. See toimib projekti peamise tegevuskavana.
2. Tasemepõhine testimiskava: Keskendub konkreetsetele testimistasemetele, näiteks ühik-, integratsiooni-, süsteemi- või vastuvõtutestidele. Iga plaan kirjeldab selle taseme lähenemisviisi, keskkonda ja tulemusi.
3. Tüübispetsiifiline testimiskava: Targetspetsialiseeritud testimistüübid, näiteks jõudlus-, turvalisus-, kasutatavus- või automatiseerimistestid. See määratleb sellele testitüübile ainuomased tööriistad, tehnikad ja kriteeriumid.

Need testiplaanid tagavad koos igakülgse katvuse, viivad testimise eesmärgid vastavusse projekti eesmärkidega ja parandavad meeskondadevahelist koordineerimist tarkvara kvaliteedi parandamiseks.

Kuidas kirjutada testiplaani

Te juba teate, et a Katseplaan on kõige olulisem ülesanne TestihaldusprotsessJärgige allolevaid seitset sammu, et luua IEEE 829 standardile vastav testimisplaan.

1. Analüüsige toodet
2. Kavandage testimisstrateegia
3. Määratlege testi eesmärgid
4. Määratlege testimise kriteeriumid
5. Ressursside planeerimine
6. Planeeri katsekeskkond
7. Ajakava ja prognoos
8. Määrake testi tulemused

1. samm) Analüüsige toodet

Kuidas saab toodet testida ilma mingit infot selle kohta? Vastus on VõimatuSa pead toote tundma õppima. põhjalikult enne selle testimist.

Testitav toode on Guru99 pangandusveebisait. Peaksite uurima kliente ja lõppkasutajaid, et teada saada nende vajadusi ja ootusi rakenduse suhtes.

• Kes hakkab veebisaiti kasutama?
• Milleks seda kasutatakse?
• Kuidas see toimib?
• Millist tarkvara/riistvara toode kasutab?

Saidi analüüsimiseks võite kasutada järgmist lähenemisviisi.

Nüüd rakendame ülaltoodud teadmisi reaalse toote puhul: Analüüsima panganduse veebisait https://demo.guru99.com/V4.

Sa peaksid võtma a Vaata ringi see veebisait ja ka läbi toote dokumentatsioon. RevTootedokumentatsiooni ülevaade aitab teil mõista kõiki veebisaidi funktsioone ja selle kasutamist. Kui teil on mõne üksuse osas ebaselge, võite seda teha intervjuu klient, arendaja, disainer, et saada rohkem teavet.

2. samm) Töötage välja testimisstrateegia

Testistrateegia on a kriitiline samm tarkvara testimise testiplaani koostamisel. Testimisstrateegia dokument on kõrgetasemeline dokument, mille tavaliselt töötab välja testijuht. See dokument määratleb:

• Projekti oma testimise eesmärgid ja vahendid nende saavutamiseks
• Määrab testimise jõupingutusi ja kulud

Tagasi oma projekti juurde, peate välja töötama testimisstrateegia selle panga veebisaidi testimiseks. Peaksite järgima alltoodud samme.

Samm 2.1) Määratlege testimise ulatus

Enne mis tahes testimistegevuse alustamist peaks olema teada testimise ulatus. Selle üle tuleb hoolikalt järele mõelda.

• Testitava süsteemi komponendid (riistvara, tarkvara, vahevara jne) on defineeritud järgmiselt „ulatusse“
• Samuti tuleb selgelt määratleda süsteemi komponendid, mida ei testita. "väljaspool reguleerimisala".

Testimisprojekti ulatuse määratlemine on kõigi sidusrühmade jaoks väga oluline. Täpne ulatus aitab teid.

• Anna kõigile usaldus ja täpne teave testimise kohta, mida te teete.
• Kõigil projekti liikmetel on a selge arusaam sellest, mida testitakse ja mida mitte.

Kuidas te oma projekti ulatust määrate?

Ulatuse määramiseks peate:

• Täpne kliendi nõue
• Projekti eelarve
• Toote spetsifikatsioon
• Teie testimeeskonna oskused ja anded

Nüüd peaks see selgelt määratlema testimise „ulatusse kuuluvad” ja „ulatusse mitte kuuluvad”.

• Nagu tarkvara nõue specs, projekti Guru99 pank keskendub ainult kõigi funktsioonid ja veebisaidi väline liides Guru99 pank (ulatuses testimine)
• Mittefunktsionaalne testimine nagu stress, sooritusvõime or loogiline andmebaas ei testita. (väljaspool ulatus)

Probleemi stsenaarium

Klient soovib, et te testiksite tema API-t. Kuid projekti eelarve ei võimalda seda teha. Mida te sellisel juhul teete?

Noh, sellisel juhul peate klienti veenma, et Api testimine on lisatöö ja nõuab märkimisväärseid ressursse. Esita talle oma fakte toetavaid andmeid. Ütle talle, et kui API-testimine on hõlmatud, suureneb eelarve XYZ võrra.

Klient nõustub ja vastavalt sellele on uued ulatused ja ulatusevälised üksused

• Kohaldamisalasse kuuluvad üksused: Funktsionaalne testimine, Api testimine
• Reguleerimisalast väljas olevad üksused: Andmebaasi testimine, riistvara ja muud välised liidesed

Samm 2.2) Määrake testimise tüüp

A Testimise tüüp on standardne testimisprotseduur, mis annab oodatud testitulemuse.

Iga testimistüüp on loodud tuvastama teatud tüüpi tootevigu. Kuid kõik testimistüübid on suunatud ühe ühise eesmärgi saavutamisele: „Varajane avastamine kõik puudused enne toote kliendile väljastamist”

. Tavaliselt kasutatakse Testimistüüpe on joonisel kirjeldatud järgmiselt

Seal on tonni testimistüüpe tarkvaratoote testimiseks. Teie meeskond ei saa panna piisavalt pingutust, et hakkama saada igasuguste testidega. Testijuhina peate määrama prioriteet testimistüüpidest

• Millised testimistüübid peaksid olema keskendunud veebirakenduste testimiseks?
• Millised testimistüübid peaksid olema eiratakse kulude kokkuhoiuks?

Samm 2.3) Dokumenteerige riskid ja probleemid

Risk on tulevik ebakindel sündmus tõenäosusega esinemine ja potentsiaal kaotuse eest. Kui risk tegelikult aset leiab, saab sellest 'probleem'.

Artiklis Riskianalüüs ja lahendus, olete juba üksikasjalikult tutvunud riskianalüüsiga ja tuvastanud projekti võimalikud riskid.

Kvaliteedikontrolli testimisplaanis dokumenteerite need riskid

Oht	Leevendamine
Meeskonnaliikmetel puuduvad veebisaidi testimiseks vajalikud oskused.	Plaani a koolituskursus oma liikmete oskuste tõstmiseks
Projekti ajakava on liiga tihe; seda projekti on raske õigeks ajaks lõpule viia	komplekt Testi prioriteet iga testitegevuse jaoks.
Testijuhil on kehvad juhtimisoskused.	kava juhtimiskoolitus juhi jaoks
Koostöö puudumine mõjutab negatiivselt teie töötajate tootlikkust	Julgustama iga meeskonnaliige oma ülesande täitmisel, ja inspireerida neid suurematele pingutustele.
Vale eelarveprognoos ja kulude ületamine	Pange paika ulatus Enne töö alustamist pöörake palju tähelepanu projekti planeerimisele ning jälgige ja mõõtke pidevalt edusamme

Samm 2.4) Loo testlogistika

Test Logisticsis peaks testijuht vastama järgmistele küsimustele:

• Kes testib?
• Kui kas test toimub?

Kes testib?

Te ei pruugi teada testijate täpseid nimesid, kes testivad, aga testeri tüüp saab määratleda.

Õige liikme valimiseks konkreetse ülesande jaoks tuleb arvestada, kas tema oskused on ülesande jaoks kvalifitseeritud või mitte, ning hinnata ka projekti eelarvet. Vale liikme valimine võib põhjustada projekti ebaõnnestumise. ei or viibima.

Tarkvara testimiseks sobib ideaalselt inimene, kellel on järgmised oskused:

• Võime mõistma kliendi vaatenurk
• Tugev soov kvaliteeti
• Tähelepanu detailideni
• hea koostöö

Teie projektis on testi läbiviimise eest vastutav liige testerProjekti eelarve põhjal saate testijaks valida ettevõttesisese või alltöövõtja.

Millal test toimub?

Testtegevused peavad olema sobitatud nendega seotud arendustegevustega.

Te hakkate testima, kui olete kõik vajalikud esemed näidatud järgmisel joonisel.

3. samm) Määratlege testi eesmärk

Testi eesmärk on testi teostamise üldine eesmärk ja saavutus. Testimise eesmärk on leida võimalikult palju tarkvaravigu; tagada, et testitav tarkvara on veavaba enne vabastamist.

Testi eesmärkide määratlemiseks peaksite tegema järgmised kaks sammu

1. Loetlege kõik tarkvarafunktsioonid (funktsionaalsus, jõudlus, graafiline kasutajaliides jne), mida võib vaja minna testida.
2. Määratlege sihtmärk või eesmärk testist ülaltoodud omaduste põhjal

Rakendame neid samme, et leida teie Guru99 panga testimisprojekti testieesmärk

Võite valida 'ÜLEVALT-ALLA' meetod veebisaidi funktsioonide leidmiseks, mida võib vaja minna testida. Selle meetodi puhul jagate testitava rakenduse osadeks komponendid ja alamkomponendid.

Eelmises teemas olete juba analüüsinud nõuete spetsifikatsioone ja tutvunud veebisaidiga, seega saate luua Mõttekaart veebisaidi funktsioonide leidmiseks toimige järgmiselt.

See joonis näitab kõiki funktsioone, mis Guru99 veebisaidil võivad olla.

Ülaltoodud omaduste põhjal saate projekti Guru99 testi eesmärgi määratleda järgmiselt:

• Kontrollige, kas veebisait Guru99 funktsionaalsus(Konto, sissemakse…) töötab ootuspäraselt, ilma igasuguste vigade või vigadeta reaalses ärikeskkonnas.
• Kontrollige veebisaidi välist liidest, näiteks UI, töötab ootuspäraselt ja vastab kliendi vajadustele
• Kontrollige kasutatavus veebisaidist. Kas need funktsioonid on kasutajale mugavad või mitte?

4. samm) Määratlege testi kriteeriumid

Testikriteeriumid on standard või reegel, millel saab põhineda testimisprotseduur või testihinnang. Testikriteeriume on kahte tüüpi:

Peatamise kriteeriumid

Määrake testi jaoks olulised peatamise kriteeriumid. Kui testimise ajal on vedrustuse kriteeriumid täidetud, on aktiivne katsetsükkel peatatud kuni kriteeriumid on täidetud lahendatud.

Testiplaani näide: kui teie meeskonnaliikmed teatavad, et 40% testjuhtumitest ebaõnnestus, peaksite riputama testimine, kuni arendusmeeskond parandab kõik ebaõnnestunud juhtumid.

Väljumise kriteeriumid

See määrab kriteeriumid, mis tähistavad a edukas katsefaasi lõpetamine. Väljumise kriteeriumid on testi sihipärased tulemused ja need on vajalikud enne järgmisesse arendusfaasi minekut. Näide: 95% kõigist kriitilistest testjuhtumitest peavad läbima.

Mõned väljumiskriteeriumide määratlemise meetodid on sihtmärgi määramine jooksukiirus ja läbimise määr.

• Jooksukiirus on suhe teostatud testide arv ja/testide koguarv testi spetsifikatsioonist. Näiteks testi spetsifikatsioonis on kokku 120 TC-d, aga testija käivitas ainult 100 TC-d, seega on käivitusprotsent 100/120 = 0.83 (83%).
• Läbimise määr on suhe järgmiste vahel: läbitud testide arv / teostatud testide arvNäiteks ülaltoodud 100 täidetud tehnilise kontrolli (TC) hulgast läbis 80 TC-d, seega on läbimise määr 80/100 = 0.8 (80%).

Neid andmeid saab hankida Test Metric dokumentidest.

• jooks määr on kohustuslik 100% välja arvatud juhul, kui on esitatud selge põhjus.
• Sooritama määr sõltub projekti ulatusest, kuid kõrge läbimismäära saavutamine on eesmärk.

Katseplaani näide:Teie meeskond on juba testid sooritanud. Nad teatavad teile testi tulemusest ja tahavad, et te seda kinnitaksite Väljumise kriteeriumid.

Ülaltoodud juhul on jooksukiirus kohustuslik ja see on 100%, aga testimismeeskond lõpetas ainult 90% testidest. See tähendab, et käivituskiirus ei ole täidetud, seega ÄRGE kinnitage väljumiskriteeriume.

5. samm) Ressursiplaneerimine

Ressursiplaan on üksikasjalik kokkuvõte kõikvõimalikud ressursid, mis on projekti ülesande täitmiseks vajalikud. Ressursid võivad olla projekti lõpuleviimiseks vajalikud inimesed, seadmed ja materjalid.

Ressursside planeerimine on testimise planeerimise oluline tegur, kuna see aitab kaasa määrates kindlaks the,en number projektis kasutatavate ressursside (töötajad, seadmed jne) kohta. Seega saab testijuht koostada projekti jaoks õige ajakava ja hinnangu.

See jaotis esindab teie projekti jaoks soovitatud ressursse.

Inimressurss

Järgmine tabel esindab teie projektimeeskonna erinevaid liikmeid

Ei.	Liige	Ülesanded
1.	Testijuht	juhtima kogu projekt Määratlege projekt suunad Hankige sobivad ressursid
2.	Tester	Sobivate testimistehnikate/tööriistade/automaatikaarhitektuuri tuvastamine ja kirjeldamine Kontrollige ja hinnake katsemeetodit Täitma testid, logi tulemused ja aru defektid. Testijad võivad olla projekti eelarvest lähtuvalt nii ettevõttesisesed kui ka allhanke korras tellitud liikmed. Ülesande jaoks, mis nõuab madal oskus, soovitan teil valida allhanke korras liikmed välja arvatud projekti maksumus.
3.	Arendaja testis	Täitma testijuhtumid, testimisprogramm, testikomplekt jne.
4.	Testi administraator	Ehitab üles ja tagab Testi keskkond ja varad on juhitud ja säilitada Tugiteenuse testija testikeskkonna kasutamiseks testi läbiviimiseks
5.	SQA liikmed	Võtke vastutus kvaliteedi tagamise eest. Kontrollige, kas testimisprotsess vastab ettenähtud nõuetele

Süsteemi ressurss

Veebirakenduse testimiseks peaksite ressursid planeerima järgmiselt:

Ei.	Ressursid	Descriptioone
1.	server	Paigalda testitav veebirakendus. See hõlmab eraldi veebiserverit, andmebaasiserverit ja rakendusserverit, kui see on kohaldatav.
2.	Testimisvahend	Testimistööriist on testimise automatiseerimiseks, kasutaja toimingute simuleerimiseks ja testi tulemuste genereerimiseks. Selle projekti jaoks on saadaval hulgaliselt testimisvahendeid, näiteks Selenium, QTP jne.
3.	võrk	Teil on vaja võrku, sealhulgas kohtvõrku ja internetti, et simuleerida reaalset äri- ja kasutajakeskkonda.
4.	arvuti	Arvuti, mida kasutajad sageli veebiserveriga ühenduse loomiseks kasutavad

6. samm) Planeerige katsekeskkond

Mis on katsekeskkond

Testimiskeskkond on tarkvara ja riistvara komplekt, millel testimismeeskond testimisjuhtumeid käivitab. Testimiskeskkond koosneb järgmisest: tõeline äri ja kasutaja keskkond, aga ka füüsilised keskkonnad, näiteks server ja esiotsa töökeskkond.

Kuidas testimiskeskkonda seadistada

Tagasi teie projekti juurde, kuidas te seadistate testimiskeskkond selle panga veebisaidi jaoks?

Selle ülesande täitmiseks peate tugev koostöö testimismeeskonna ja arendusmeeskonna vahel.

Testitava veebirakenduse mõistmiseks peaksite arendajalt esitama mõned küsimused selgeltSiin on mõned soovitatavad küsimused. Muidugi võite vajadusel esitada ka teisi küsimusi.

• Kui palju kasutajaühendusi see veebisait korraga hallata suudab?
• Millised on selle veebisaidi installimise riist-/tarkvaranõuded?
• Kas kasutaja arvuti vajab veebisaidi sirvimiseks mingeid erilisi seadeid?

Järgnev joonis kirjeldab panga veebisaidi testkeskkonda. https://demo.guru99.com/V4

7. etapp) ajakava ja hinnang

Artiklis Testi hinnang, olete juba kasutanud mõningaid tehnikaid projekti lõpuleviimiseks vajaliku töömahu hindamiseks. Nüüd peaksite selle hinnangu ja ajakava lisama testimisplaani.

Testihinnangu etapis oletame, et jagate kogu projekti väikesteks ülesanneteks ja lisate iga ülesande hinnangu järgmiselt

Ülesanne	liikmed	Hinnake jõupingutusi
Looge testi spetsifikatsioon	Testi disainer	170 töötundi
Tehke testkäivitus	Testija, testi administraator	80 töötundi
Test Report	Tester	10 töötundi
Testi kohaletoimetamine		20 töötundi
Summa		280 töötundi

Seejärel loote ajakava nende ülesannete täitmiseks.

Ajakava koostamine on projektijuhtimises levinud termin. Testiplaneerimises kindla ajakava loomisel saab testijuht seda kasutada projekti edenemise jälgimise ja kulude ületamise kontrollimise vahendina.

Projekti ajakava loomiseks vajab testijuht mitut tüüpi sisendit:

• Töötaja ja projekti tähtaegAjakava mõjutavad tegurid on tööpäevad, projekti tähtaeg ja ressursside kättesaadavus.
• Projekti hinnangHinnangu põhjal teab testijuht, kui kaua projekti lõpuleviimine aega võtab. Seega saab ta koostada sobiva projekti ajakava.
• Projekti riskRiski mõistmine aitab testijuhil projekti ajakavasse lisada piisavalt aega riskidega tegelemiseks.

Harjutame näitega:

Oletame, et boss soovib projekti Guru99 lõpule viia üks kuu ja olete juba iga ülesande pingutuse testihinnangus hinnanud. Ajakava saate luua järgmiselt

Samm 8) Testi väljundid

Testi tulemused on nimekiri kõigist dokumentidest, tööriistadest ja muudest komponentidest, mida tuleb testimise toetamiseks arendada ja hooldada.

Igas etapis on erinevad testitulemused tarkvaraarenduse elutsükkel.

Testitulemused on saadaval enne testimise etapp.

• Testiplaanide dokument.
• Testjuhtumite dokumendid
• Katse disaini spetsifikatsioonid.

Testitulemused on saadaval ajal testimine

• Testi skriptid
• Simulaatorid.
• Testi andmed
• Jälgitavuse maatriksi testimine
• Vealogid ja täitmislogid.

Testitulemused on saadaval pärast testimistsükkel on läbi.

• Testi tulemused/aruanded
• Defekti aruanne
• Paigaldamise/ testimisprotseduuride juhised
• Väljalaskemärkmed

Testimise planeerimise levinumad väljakutsed (ja nende lahendused)

Tõhus testide planeerimine seisab sageli silmitsi praktiliste takistustega. Nende väljakutsete äratundmine ja ennetavate lahenduste rakendamine tagab sujuvama teostuse ja kõrgema tarkvara kvaliteedi.

1. Ebaselged nõuded
   Väljakutse: Ebamäärased või muutuvad projektinõuded toovad kaasa mittetäieliku testimise.
   Lahendus: Viige läbi nõuete läbivaatusi ja hallake nõuete jälgitavuse maatriksit.
2. Piiratud ressursid
   Väljakutse: Ebapiisavad tööriistad, aeg või oskuslikud testijad mõjutavad testi kvaliteeti.
   Lahendus: Prioriseeri kriitilisi testijuhtumeid ja kasuta automatiseerimist korduvate ülesannete jaoks.
3. Ebareaalsed tähtajad
   Väljakutse: Tihedad ajakavad vähendavad aega testide nõuetekohaseks kavandamiseks ja läbiviimiseks.
   Lahendus: Kasutage hindamistehnikaid ja teavitage sidusrühmi riskidest varakult.
4. Kehv suhtlus
   Väljakutse: Meeskondade vaheline ebakõla põhjustab viivitusi ja ümbertegemist.
   Lahendus: Läbipaistvuse tagamiseks rakendage regulaarseid sünkroonimiskoosolekuid ja jagatud armatuurlaudu.
5. Ebapiisav riskijuhtimine
   Väljakutse: Võimalike riskide eiramine võib projekti ajakava rööpast välja viia.
   Lahendus: Tuvastage riskid varakult, pidage riskilogi ja kavandage leevendusstrateegiaid.

KKK: