TESTIKAVA: Mis on, kuidas luua (näite abil)

Testiplaan

Testpakett on üksikasjalik dokument, mis kirjeldab katse äristrateegia, eesmärkide, ajakava, hindamise, tulemused ja täitmiseks vajalikud vahendid testimine tarkvara toode. Testiplaan aitab meil kindlaks teha katsetatava rakenduse kvaliteedi kinnitamiseks vajalikud jõupingutused. Testimiskava on kavandatud tarkvara testimistoimingute läbiviimiseks määratletud protsessina, mida testijuht hoolikalt jälgib ja kontrollib.

Vastavalt ISTQB määratlusele: "Testplaan on dokument, mis kirjeldab kavandatud testitegevuste ulatust, lähenemisviisi, ressursse ja ajakava."

Alustame testplaani näite / stsenaariumi järgimisega: Koosolekul soovite testiplaani meeskonnaliikmetega arutada, kuid nad pole sellest huvitatud -.

Mida te sellisel juhul teete? Valige oma vastus järgmisel joonisel

A) Olen juhataja, tehke kõik nii, nagu ütlesin
B) Olgu, selgitan, miks vajame testikava
valesti Testijuhina
peate neile selgitama testiplaani olulisust, mitte sundima meeskonda tegema seda, mida soovite. Õige Testijuhina
peate neile selgitama testiplaani olulisust, mitte sundima meeskonda tegema seda, mida soovite.

Mis on testimiskava tähtsus?

Testplaani dokumendi koostamisel on mitmeid eeliseid

• Aidake testimeeskonnast väljas olevaid inimesi, näiteks arendajaid, ärijuhte, kliente testimise üksikasjadest aru saada .
• Testplaan suunab meie mõtlemist. See on nagu reegliraamat, mida tuleb järgida.
• Olulised aspektid, nagu testi hindamine, testi ulatus, testimisstrateegia, on dokumenteeritud testimiskavas, nii et juhtmeeskond saab selle üle vaadata ja uuesti kasutada teiste projektide jaoks.

Kuidas kirjutada testplaani

Te juba teate, et testimiskava koostamine on testihalduse protsessi kõige olulisem ülesanne. IEEE 829 kohase testimiskava loomiseks järgige allpool toodud seitset sammu

1. Analüüsige toodet
2. Kujundage testimisstrateegia
3. Määratlege testi eesmärgid
4. Määratlege testikriteeriumid
5. Ressursside planeerimine
6. Planeerige testkeskkond
7. Ajakava ja hinnang
8. Määrake testitulemused

1. samm. Analüüsige toodet

Kuidas saab toodet testida, ilma et oleks selle kohta mingit teavet? Vastus on võimatu. Enne toote testimist peate toote põhjalikult õppima .

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

• Kes veebisaiti kasutab?
• Milleks seda kasutatakse?
• Kuidas see töötab?
• Mis on tarkvara / riistvara, mida toode kasutab?

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

Rakendame nüüd ülaltoodud teadmisi reaalsele tootele: analüüsige panganduse veebisaiti http://demo.guru99.com/V4.

Peaksite sellel veebisaidil ringi vaatama ja ka toote dokumentatsiooni üle vaatama . Tootedokumentatsiooni ülevaade aitab teil mõista nii veebisaidi kõiki funktsioone kui ka selle kasutamist. Kui teil pole üheski asjas ebaselgust, võite lisateabe saamiseks küsitleda klienti, arendajat ja disainerit.

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

Testimisstrateegia on kriitiline samm tarkvara testimise testkava koostamisel. Testistrateegia dokument on kõrgetasemeline dokument, mille töötab tavaliselt välja Test Manager. Selles dokumendis määratletakse:

• Projekti katsetamise eesmärgid ja vahendid nende saavutamiseks
• Määrab testimise pingutuse ja kulud

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

Samm 2.1) Määrake testimise ulatus

Enne mis tahes katsetegevuse algust peaks olema teada katsetamise ulatus. Peate selle üle kõvasti mõtlema.

• Testitava süsteemi komponendid (riistvara, tarkvara, vahevara jne) on määratletud kui " reguleerimisala "
• Süsteemi komponendid, mida ei testita, tuleb samuti selgelt määratleda kui " reguleerimisalast välja jäävad ".

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

• Andke kõigile enesekindlust ja täpset teavet testimise kohta, mida teete
• Kõigil projekti liikmetel on selge arusaam sellest, mida testitakse ja mida mitte

Kuidas määrate oma projekti ulatuse?

Reguleerimisala määramiseks peate -

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

Nüüd peaks selgelt määratlema testimise "ulatus" ja "reguleerimisalast välja".

• Tarkvaranõuete spetsifikatsioonidena keskendub projekt Guru99 Bank ainult veebisaidi Guru99 Bank kõigi funktsioonide ja välise liidese testimisele ( ulatusekontrollis )
• Praegu mittetoimivat testimist, nagu stress , jõudlus või loogiline andmebaas , ei testita. ( Välja ulatust)

Probleemistsenaarium

Klient soovib, et testiksite tema API-d. Kuid projekti eelarve ei luba seda teha. Mida te sellisel juhul teete?

Noh, sellisel juhul peate klienti veenma, et Api testimine on lisatöö ja kulutab märkimisväärseid ressursse. Andke talle teie fakte toetavaid andmeid. Öelge talle, kui Api testimine kuulub reguleerimisalasse, suureneb eelarve XYZ summa võrra.

Klient nõustub ja vastavalt sellele on uued reguleerimisalad, reguleerimisalast välja jäävad

• Reguleerimisala üksused: Funktsionaalne testimine, Api testimine
• Reguleerimisalast väljas olevad üksused: andmebaaside testimine, riistvara ja muud välised liidesed

Samm 2.2) tuvastage testimise tüüp

Testimine Liik on standardne test korras, mis annab oodata test tulemustest.

Iga testimistüüp on sõnastatud konkreetse tootevea tüübi tuvastamiseks. Kuid kõigi testimistüüpide eesmärk on saavutada üks ühine eesmärk - kõigi defektide varajane avastamine enne toote kliendile väljastamist

Levinumaid testimisvahendeid kirjeldatakse järgneval joonisel

Tarkvaratoodete testimiseks on hulgaliselt testimistüüpe. Teie meeskonnal ei saa olla piisavalt jõupingutusi igasuguste testide läbiviimiseks. Testihaldurina peate määrama testimistüüpide prioriteedi

• Millised testimistüübid peaksid veebirakenduste testimiseks keskenduma ?
• Milliseid testimistüüpe tuleks kulude kokkuhoiu mõttes eirata ?

Harjutame nüüd teie projektiga. Toode, mida soovite testida, on panganduse veebisait.
Millistele testimistüüpidele peaksite sel juhul keskenduma?
Valige Kõik rakendatavad A) Üksuse testimine B) API testimine C) Integratsiooni testimine D) Süsteemi testimine E) Testimise installimine / desinstallimine F) Agile testimine Valime projekti Guru99 jaoks ainult B) API testimise C) Integratsiooni testimise D) Süsteemi testimise

Samm 2.3) Dokumendi risk ja probleemid

Risk on tuleviku ebakindel sündmus , mille esinemise tõenäosus ja potentsiaal on kahjum. Kui risk tegelikult juhtub, saab sellest probleem.

Artiklis Riskianalüüs ja lahendus olete juba üksikasjalikult tutvunud riskianalüüsiga ja tuvastanud projektis potentsiaalsed riskid.

Kvaliteedikontrolli testide kavas dokumenteerite need riskid

Risk	Leevendamine
Meeskonna liikmel puuduvad veebisaidi testimiseks vajalikud oskused.	Planeerige koolituskursus, et oma liikmeid paremaks muuta
Projekti ajakava on liiga tihe; seda projekti on raske õigeaegselt lõpule viia	Määrake iga testitegevuse jaoks testprioriteet.
Testijuhil on halvad juhtimisoskused	Plan juhtimise koolitus jaoks juht
Koostöö puudumine mõjutab negatiivselt teie töötajate tootlikkust	Julgustage iga meeskonnaliiget tema ülesande täitmisel ja innustage neid suurematele pingutustele.
Vale eelarve prognoos ja kulude ületamine	Pange paika enne töö alustamist ulatus , pöörake palju tähelepanu projekti kavandamisele ning jälgige ja mõõtke pidevalt edusamme

Samm 2.4) Looge testlogistika

Testlogistikas peaks testijuht vastama järgmistele küsimustele:

• Kes testib?
• Millal test toimub?

Kes testib?

Te ei pruugi teada testija täpseid nimesid, kes katsetab, kuid testija tüübi saab määratleda.

Täpsema ülesande jaoks õige liikme valimiseks peate arvestama ka projekti eelarvega, kas tema oskus on ülesande jaoks sobiv või mitte. Ülesande jaoks vale liikme valimine võib põhjustada projekti nurjumise või viivituse .

Järgmiste oskustega isik on tarkvara testimiseks kõige ideaalsem:

• Oskus mõista klientide vaatenurka
• Tugev soov kvaliteedi järele
• Tähelepanu detailidele
• Hea koostöö

Teie projektis on testijaks testimise eest vastutav liige . Kui lähtuda projekti eelarvest, võite testijaks valida allikas- või allhanke liikme.

Millal test toimub?

Testitegevused tuleb sobitada seotud arendustegevustega.

Te hakkate testima, kui kõik vajalikud joonised on näidatud järgmisel joonisel

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

Testi eesmärk on testi täitmise üldeesmärk ja saavutus. Testimise eesmärk on leida võimalikult palju tarkvaradefekte; enne väljaandmist veenduge, et testitav tarkvara on vigadest vaba .

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

1. Loetlege kõik tarkvara funktsioonid (funktsionaalsus, jõudlus, GUI ...), mida võib-olla on vaja testida.
2. Määratlege ülaltoodud funktsioonide põhjal testi eesmärk või eesmärk

Rakendame need sammud teie Guru99 Panga testimisprojekti testi eesmärgi leidmiseks

Veebisaidi testimiseks vajalike funktsioonide leidmiseks võite valida meetodi „ ÜLAL-ALLA” . Selles meetodis jagate testitava rakenduse komponentide ja alamkomponentide kaupa .

Eelmises teemas olete juba analüüsinud nõuete spetsifikatsioone ja külastanud veebisaiti, nii et saate luua mõttekaardi veebisaidi funktsioonide leidmiseks järgmiselt

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

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

• Kontrollige, kas veebisaidi Guru99 funktsionaalsus (konto, sissemakse …) töötab ootuspäraselt, ilma tõeliste ärikeskkondade tõrgeteta
• Kontrollige, kas veebisaidi väline liides, näiteks kasutajaliides, töötab ootuspäraselt ja vastab kliendi vajadustele
• Veenduge veebisaidi kasutatavuses . Kas need funktsioonid on kasutajale mugavad või mitte?

4. samm. Määratlege testikriteeriumid

Testikriteeriumid on standard või reegel, millele testiprotseduur või testihinnang võib tugineda. Järgmisi testikriteeriume on kahte tüüpi

Peatamise kriteeriumid

Määrake katse jaoks kriitilised suspensioonikriteeriumid. Kui katse ajal on peatamise kriteeriumid täidetud, peatatakse aktiivne katsetsükkel kuni kriteeriumide lahendamiseni .

Testplaani näide: kui teie meeskonnaliikmed teatavad, et 40% testidest on ebaõnnestunud, peate katkestama testimise, kuni arendustiim lahendab kõik ebaõnnestunud juhtumid.

Väljumise kriteeriumid

Selles täpsustatakse kriteeriumid, mis tähistavad katse edukat läbimist. Väljumiskriteeriumid on testi sihttulemused ja need on vajalikud enne järgmise arenguetapi jätkamist. Näide: 95% kõigist kriitilistest testjuhtumitest peab läbima.

Mõned väljumiskriteeriumide määratlemise meetodid on sihitud töötamiskiiruse ja läbipääsukiiruse määramine .

• Käitamiskiirus on sooritatud katsete arvu / testi spetsifikatsiooni testide koguarvu suhe . Näiteks testi spetsifikatsioonis on kokku 120 TC-d, kuid tester sooritas ainult 100 TC-d, seega on käitamiskiirus 100/120 = 0,83 (83%)
• Liigu määr on suhe numbrid test juhtudel sooritanud / test juhtudel hukati . Näiteks üle 100 täidetud TC-i on 80 TC-d läbinud, seega on läbipääsumäär 80/100 = 0,8 (80%)

Neid andmeid saab hankida testmõõdiku dokumentidest.

• Käivitamise määr on kohustuslik 100%, kui ei ole esitatud selget põhjust.
• Läbimäära määr sõltub projekti ulatusest, kuid eesmärk on kõrge läbipääsu määra saavutamine.

Testiplaani näide: teie meeskond on juba testi hukkamised teinud. Nad teatavad teile testi tulemustest ja soovivad, et kinnitaksite väljumiskriteeriumid.

Ülaltoodud juhul on käitumissagedus kohustuslik 100%, kuid testimeeskond läbis ainult 90% testjuhtumitest. See tähendab, et käitusmäär ei ole rahuldatud, seega EI kinnita väljumiskriteeriume

Samm 5) Ressursside planeerimine

Ressursikava on üksikasjalik kokkuvõte igat tüüpi ressurssidest, mis on projekti ülesande täitmiseks vajalikud. Ressurss võib olla projekti lõpuleviimiseks vajalik inimene, seadmed ja materjalid

Ressurss planeerimine on oluline tegur test planeerimine, sest aitab määrata number ressursside (töötaja, seadmed ...), mida kasutatakse projekti. Seetõttu saab testihaldur koostada projekti jaoks õige ajakava ja hinnangu.

See jaotis esindab teie projekti jaoks soovitatud ressursse.

Inimressurss

Järgmine tabel esindab teie projekti meeskonna erinevaid liikmeid

Ei	Liige	Ülesanded
1.	Testijuht	Halda kogu projekti Määratlege projekti suunad Omandage sobivad ressursid
2.	Testija	Sobivate testimisvõtete / -vahendite / automaatika arhitektuuri tuvastamine ja kirjeldamine Kontrollige ja hinnake katsemeetodit Tehke testid, logige tulemused, teatage defektidest. Testijad võivad olla projekti allhanke all või väljastpoolt pärit liikmed, lähtudes projekti eelarvest Madalat oskust nõudva ülesande jaoks soovitan projekti kulude kokkuhoiuks valida tellitud liikmed .
3.	Arendaja testis	Rakendage testijuhud, testprogramm, testipakett jne
4.	Testi administraator	Ehitab üles ja tagab testkeskkonna ning varade haldamise ja hooldamise Toetage testrit testkeskkonna kasutamiseks testi täitmisel
5.	SQA liikmed	Vastutab kvaliteedi tagamise eest Kontrollige, kas testimisprotsess vastab määratletud nõuetele

Süsteemi ressurss

Veebirakenduse testimiseks peaksite ressursid planeerima järgmiste tabelite abil:

Ei	Ressursid	Kirjeldused
1.	Server	Installige testitav veebirakendus See hõlmab eraldi veebiserverit, andmebaasiserverit ja vajaduse korral rakendusserverit
2.	Testimisvahend	Testimisvahend on testimise automatiseerimine, kasutaja toimingu simuleerimine, testitulemuste genereerimine Selle projekti jaoks saate kasutada palju testimisvahendeid, näiteks seleen, QTP jne.
3.	Võrk	Tegeliku äri- ja kasutajakeskkonna simuleerimiseks vajate võrku, mis sisaldab LAN-i ja Internetti
4.	Arvuti	Arvuti, mida kasutajad kasutavad veebiserveri ühendamiseks sageli

6. samm. Planeerige testkeskkond

Mis on testkeskkond

Testimiskeskkond on tarkvara ja riistvara seadistamine, milles testimisrühm hakkab testjuhtumeid käivitama. Testikeskkond koosneb tõelisest äri- ja kasutajakeskkonnast , samuti füüsilistest keskkondadest, nagu server, esiotsa töötav keskkond.

Testkeskkonna seadistamine

Tagasi oma projekti juurde, kuidas saate selle pangaveebisaidi jaoks testkeskkonna seadistada ?

Selle ülesande täitmiseks vajate tugevat koostööd testimeeskonna ja arendusmeeskonna vahel

Sa peaksid küsima arendaja mõned küsimused mõista veebirakenduse uuritava selgelt . Siin on mõned soovitatud küsimused. Muidugi võite vajadusel küsida ka teisi küsimusi.

• Milline on maksimaalne kasutajaühendus, mida see veebisait saab korraga käsitseda?
• Millised on riistvara / tarkvara nõuded selle veebisaidi installimiseks?
• Kas kasutaja arvuti vajab veebisaidi sirvimiseks mingeid konkreetseid seadeid?

Järgmine joonis kirjeldab panganduse veebisaidi www.demo.guru99.com/V4 testikeskkonda

Samm 7) Ajakava ja prognoosimine

Artiklis Testi hindamine kasutasite projekti lõpuleviimise pingutuste hindamiseks juba mõnda tehnikat. Nüüd peaksite lisama nii selle hinnangu kui ka ajakava testide kavandamiseks

Oletame, et testi hindamise etapis jagate kogu projekti väikesteks ülesanneteks ja lisate iga ülesande jaoks hinnangu allpool

Ülesanne	Liikmed	Hinnake jõupingutusi
Looge testi spetsifikatsioon	Testikujundaja	170 töötundi
Tehke testi täitmine	Testija, testi administraator	80 töötundi
Testi tulemused	Testija	10 töötundi
Katse kohaletoimetamine		20 töötundi
Kokku		280 töötundi

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

Graafiku koostamine on projektijuhtimises levinud termin. Luues testide planeerimisel kindla ajakava, saab testihaldur seda kasutada tööriistana projekti edenemise jälgimiseks, kulude ületamise kontrollimiseks.

Projekti ajakava loomiseks vajab testihaldur mitut tüüpi sisestust, nagu allpool:

• Töötaja ja projekti tähtaeg : tööpäevad, projekti tähtaeg, ressursside kättesaadavus on ajakava mõjutanud tegurid
• Projekti hinnang : Tugihinnangu põhjal teab Test Manager, kui kaua kulub projekti lõpuleviimiseks. Nii saab ta koostada sobiva projekti ajakava
• Projektirisk : riski mõistmine aitab Test Manageril lisada projekti ajakavasse piisavalt lisaaega riskide käsitlemiseks

Harjutame näite abil:

Oletame, et ülemus soovib projekti Guru99 ühe kuu jooksul lõpule viia, hindasite juba Test Estimationis iga ülesande jaoks tehtud pingutusi. Ajakava saate luua allpool

8. samm. Testige tulemusi

Test Deliverables on kõigi dokumentide, tööriistade ja muude komponentide loend, mis tuleb väljatöötada ja hooldada, et toetada testimist.

Tarkvaraarenduse elutsükli igas etapis on erinevad testitulemused.

Testi tulemused antakse enne testimise faasi.

• Katseplaanide dokument.
• Testjuhtumite dokumendid
• Test Design spetsifikatsioonid.

Testitulemused esitatakse testimise ajal

• Testskriptid
• Simulaatorid.
• Testiandmed
• Testi jälgitavuse maatriks
• Tõrkelogid ja täitmispäevikud.

Testi tulemused antakse pärast testimistsüklite lõppu.

• Testi tulemused / aruanded
• Defektiaruanne
• Paigaldus- / katseprotseduuride juhised
• Väljalaskemärkused

Ressursid

Laadige alla prooviplaani mall

Laadige alla veebisaidi Guru99 Bank süsteemi prooviplaan