TESTIPLAAN Tarkvara testimises (näide)

Katseplaan

A Katseplaan on üksikasjalik dokument, mis kirjeldab tarkvaratoote testimise strateegiat, eesmärke, ajakava, hinnangut, tulemusi ja ressursse. Testiplaan aitab meil kindlaks teha, kui palju jõupingutusi on vaja testitava rakenduse kvaliteedi kinnitamiseks. Testiplaan toimib plaanina tarkvara testimistegevuste läbiviimiseks määratletud protsessina, mida testihaldur jälgib ja kontrollib iga päev.

ISTQB määratluse kohaselt: "Testiplaan on dokument, mis kirjeldab kavandatud testimistegevuste ulatust, lähenemisviisi, ressursse ja ajakava."

Alustame järgmise katseplaani näite/stsenaariumiga: koosolekul soovite testimisplaani meeskonnaliikmetega arutada, kuid nad ei ole sellest huvitatud – .

Katseplaan

Mida te sellisel juhul ette võtate? Valige oma vastus järgmiselt jooniselt

Katseplaan


A) Olen juhataja, teen kõike nii, nagu ma ütlesin

B) Olgu, lubage mul selgitada, miks me vajame katseplaani


Vale

Testijuhina peate neile selgitama testiplaani tähtsust, mitte sundima meeskonda tegema seda, mida soovite.

Korrektne

Testijuhina peate neile selgitama testiplaani tähtsust, mitte sundima meeskonda tegema seda, mida soovite.

 

Mis on testiplaani tähtsus?

Testiplaani dokumendi koostamisel on mitmeid eeliseid

  • Aidake inimesi väljaspool testimismeeskonda, näiteks arendajaid, ärijuhte, 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 testiplaanis, nii et juhtkond saab selle üle vaadata ja teiste projektide jaoks uuesti kasutada.

Kuidas kirjutada testiplaani

Te juba teate, et a Katseplaan on testihaldusprotsessi kõige olulisem ülesanne. IEEE 829 järgi testiplaani loomiseks järgige allolevat seitset sammu

  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

kirjutage katseplaan

1. samm) Analüüsige toodet

Kuidas saab toodet testida ilma mingit infot selle kohta? Vastus on Võimatu. Peate toodet õppima põhjalikult enne selle testimist.

Testitav toode on Guru99 panga veebisait. 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?
  • Mis on tarkvara/riistvara, mida toode kasutab?

Saidi analüüsimiseks saate kasutada järgmist lähenemisviisi

Analüüsige toodet

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

Analüüsige toodet

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 Tarkvaratestimise testiplaani koostamisel. Testistrateegia dokument on kõrgetasemeline dokument, mille on tavaliselt välja töötanud Test Manager. 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 selle panga veebisaidi testimiseks välja töötama testimisstrateegia. Peaksite järgima alltoodud samme

Töötage välja testimisstrateegia

Samm 2.1) Määratlege testimise ulatus

Enne mis tahes katsetegevuse alustamist peaks olema teada testimise ulatus. Peate selle üle tõsiselt mõtlema.

  • Testitavad süsteemi komponendid (riistvara, tarkvara, vahevara jne) on määratletud kui "ulatuses"
  • Süsteemi komponendid, mida ei testita, tuleb samuti selgelt määratleda kui "ulatust väljas. "

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

  • Andke kõigile a usaldus ja täpne teave testimisest, mida teete
  • Kõigil projekti liikmetel on a selge arusaamine sellest, mida testitakse ja mida mitte

Kuidas määrate oma projekti ulatuse?

Ulatuse määramiseks peate:

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

Nüüd tuleks selgelt määratleda testimise "ulatuses" ja "ulatusest väljas".

  • 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, jõudlus or loogiline andmebaas hetkel ei testita. (väljaspool ulatus)

Probleemi stsenaarium

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

Sel juhul peate klienti selles veenma Api testimine on lisatöö ja kulutab märkimisväärseid ressursse. Andke talle andmeid, mis toetavad teie fakte. Öelge talle, kui Api testimine on hõlmatud, suureneb eelarve XYZ summa võrra.

Klient nõustub ja vastavalt sellele on uued ulatused, väljaspool objektid

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

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

Iga testimistüüp on koostatud konkreetset tüüpi tootevigade tuvastamiseks. Kuid kõik testimistüübid on suunatud ühe ühise eesmärgi saavutamisele.Varajane avastamine kõik puudused enne toote kliendile väljastamist”

. Tavaliselt kasutatakse testimise tüüpe on kirjeldatud järgmisel joonisel

Tavaliselt kasutatavad testimistüübid
Tavaliselt kasutatavad testimistüübid

Seal on tonni testimistüüpe tarkvaratoote testimiseks. Sinu meeskond ei saa olla piisavalt jõupingutusi igasuguste katsete läbiviimiseks. Testihaldurina peate seadistama prioriteet testimistüüpidest

  • Millised testimistüübid peaksid olema keskendunud veebirakenduste testimiseks?
  • Millised testimistüübid peaksid olema eiratakse kulude kokkuhoiuks?
Nüüd harjutame teie projektiga. Toode, mida soovite testida, on panga veebisait.

Millistele testimistüüpidele peaksite sel juhul keskenduma?

Valige Kõik, mis rakendatakse
A) Ühiku testimine

B) API testimine

C) Integratsiooni testimine

D) Süsteemi testimine

E) Installi/desinstalli testimine

F) Agiilne testimine




Valime ainult

B) API testimine

C) Integratsiooni testimine

D) Süsteemi testimine

Guru99 projekti jaoks

Samm 2.3) Dokumenteerige riskid ja probleemid

Risk on tulevik ebakindel sündmus tõenäosusega esinemine ja potentsiaal kaotuse eest. Kui risk tegelikult juhtub, muutub see "küsimus".

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

Kvaliteedikontrolli testimisplaanis dokumenteerite need riskid

Oht Leevendamine
Meeskonnaliikmel puuduvad veebisaidi testimiseks vajalikud oskused. kava koolituskursus oma liikmete oskuste tõstmiseks
Projekti ajakava on liiga tihe; seda projekti on raske õigeks ajaks lõpule viia komplekt Testi prioriteet iga katsetegevuse kohta.
Test Manageril on halb juhtimisoskus kava juhtimiskoolitus juhi jaoks
Koostöö puudumine mõjutab negatiivselt teie töötajate tootlikkust Julgustama iga meeskonnaliige oma ülesandes, 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 testija täpseid nimesid, kuid testeri tüüp saab määratleda.

Määratud ülesande jaoks õige liikme valimiseks tuleb arvestada, kas tema oskused on ülesande täitmiseks kvalifitseeritud või mitte, samuti hinnata projekti eelarvet. Ülesande jaoks vale liikme valimine võib põhjustada projekti ei or viivitus.

Tarkvara testimiseks sobib kõige paremini inimene, kellel on järgmised oskused:

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

Teie projektis on testi läbiviimise eest vastutav liige tester. Projekti eelarve alusel saate testijaks valida ettevõttesisese või allhankeliikme.

Millal test toimub?

Testtegevused peavad olema sobitatud nendega seotud arendustegevustega.

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

Test Toimub

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

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

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

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

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

Saate valida 'ÜLAST ALLA' meetod veebisaidi funktsioonide leidmiseks, mida võib olla vaja testida. Selle meetodi puhul jagate testitava rakenduse komponent ja alamkomponent.

Eelmises teemas olete juba nõuete spetsifikatsioone analüüsinud ja veebisaidil käinud, et saaksite luua a Mõttekaart veebisaidi funktsioonide leidmiseks järgmiselt

Määratlege testi eesmärk

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

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

  • Kontrollige, kas veebisait Guru99 funktsionaalsus(Konto, Deposiit…) töötab ootuspäraselt ilma tõrgeteta ja vigadeta reaalses ärikeskkonnas
  • Kontrollige, kas veebisaidi väline liides, nt UI töötab ootuspäraselt ja vastab kliendi vajadustele
  • Kontrollige kasutatavus veebisaidilt. 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 katseotsus. Järgnevalt on kahte tüüpi testikriteeriume

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 on 40% testjuhtumitest ebaõnnestus, peaksite riputama testimine, kuni arendusmeeskond parandab kõik ebaõnnestunud juhtumid.

Määratlege testimise kriteeriumid

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.

  • Käituskiirus on suhe teostatud testjuhtumite arv / testjuhtumite koguarv testi spetsifikatsioonist. Näiteks testi spetsifikatsioonis on kokku 120 TC-d, kuid tester teostas ainult 100 TC-d, seega on käitamiskiirus 100/120 = 0.83 (83%)
  • Läbimise määr on suhe numbrid testjuhtumid läbitud / testjuhtumid teostatud. Näiteks enam kui 100 sooritatud TC puhul on läbinud 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äbilaskevõime 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.

Määratlege testimise kriteeriumid

Ülaltoodud juhul on Run rate kohustuslik 100% kuid katsemeeskond lõpetas vaid 90% testjuhtumitest. See tähendab, et töökiirus ei ole täidetud, seega ÄRGE kinnitage väljumiskriteeriume

5. samm) Ressursiplaneerimine

Ressursiplaan on a üksikasjalik kokkuvõte igat tüüpi ressursse, mis on vajalikud projektiülesande täitmiseks. Ressursiks võivad olla projekti lõpuleviimiseks vajalikud inimesed, seadmed ja materjalid

Ressursside planeerimine on testi planeerimise oluline tegur, kuna aitab sisse määrates kindlaks the,en number projekti jaoks kasutatavate ressursside (töötaja, varustus jne) suurus. Seetõttu 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, Aruanne defektid.

Testija võib projekti eelarve alusel olla sisse- või väljastpoolt tellitud liikmed

Vajaliku ülesande jaoks madal oskus, soovitan teil valida allhanke korras liikmed välja arvatud projekti maksumus.

3.

Arendaja testis

Täitma testjuhtumid, testprogramm, testkomplekt jne.

4.

Testi administraator

Ehitab üles ja tagab Testi keskkond ja varad on juhitud ja säilitada

ToetusTester testkeskkonna kasutamiseks testi täitmiseks

5.

SQA liikmed

Võtke vastutus kvaliteedi tagamise eest

Kontrollige, kas testimisprotsess vastab kindlaksmääratud nõuetele

Süsteemi ressurss

Veebirakenduse testimiseks peaksite planeerima ressursse järgmiste tabelite järgi:

Ei. Vahendid Descriptioone

1.

server

Installige testitav veebirakendus

See hõlmab eraldi veebiserverit, andmebaasiserverit ja vajaduse korral rakendusserverit

2.

Testimisvahend

Testimistööriist on testimise automatiseerimine, kasutaja toimingu simuleerimine, testitulemuste genereerimine

Selle projekti jaoks saate kasutada palju testtööriistu, näiteks Selenium, QTP jne.

3.

võrk

Tegeliku äri- ja kasutajakeskkonna simuleerimiseks vajate LAN-i ja Internetti sisaldavat võrku

4.

arvuti

Arvuti, mida kasutajad kasutavad sageli veebiserveriga ühendamiseks

6. samm) Planeerige katsekeskkond

Mis on katsekeskkond

Testimiskeskkond on tarkvara ja riistvara seadistus, millel testimismeeskond hakkab katsejuhtumeid läbi viima. Testikeskkond koosneb tõeline äri ja kasutaja keskkond, aga ka füüsiline keskkond, näiteks server, esiotsa töökeskkond.

Testikeskkonna seadistamine

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

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

seadistage testkeskkond

Testitava veebirakenduse mõistmiseks peaksite arendajalt esitama mõned küsimused selgelt. Siin on mõned soovitatavad küsimused. Muidugi võite vajadusel küsida ka muid küsimusi.

  • Kui suur on maksimaalne kasutajaühendus, mida see veebisait suudab korraga käsitleda?
  • Millised on riist-/tarkvaranõuded selle veebisaidi installimiseks?
  • Kas kasutaja arvuti vajab veebisaidi sirvimiseks mingeid konkreetseid seadistusi?

Järgnev joonis kirjeldab pangaveebisaidi testkeskkonda http://demo.guru99.com/V4

seadistage testkeskkond

7. etapp) ajakava ja hinnang

Artiklis Testi hinnang, kasutasite juba mõnda tehnikat, et hinnata projekti lõpuleviimiseks tehtavaid jõupingutusi. Nüüd peaksite lisama selle hinnangu ja ajakava testi planeerimisse

Oletame, et testhinnangu etapis jagate kogu projekti väikesteks ülesanneteks ja lisate iga ülesande hinnangu, nagu allpool

Ü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. Luues testiplaanis kindla ajakava, saab testijuht kasutada seda tööriistana projekti edenemise jälgimiseks ja kulude ületamise kontrollimiseks.

Projekti ajakava koostamiseks vajab testihaldur mitut tüüpi sisendit, nagu allpool.

  • Töötaja ja projekti tähtaeg: Tööpäevad, projekti tähtaeg, ressursside olemasolu on tegurid, mis ajakava mõjutavad
  • Projekti hinnang: hinnangu põhjal teab testijuht, kui kaua projekti lõpuleviimiseks kulub. Nii saab ta koostada sobiva projekti ajakava
  • Projekti risk : Riski mõistmine aitab testihalduril lisada projekti ajakavasse piisavalt lisaaega riskidega tegelemiseks

Harjutame näitega:

Oletame, et boss soovib projekti Guru99 lõpule viia üks kuul hindasite juba iga ülesande jaoks tehtud jõupingutusi testhinnangus. Saate ajakava koostada järgmiselt

Ajakava ja prognoos

Samm 8) Testi väljundid

Testi tulemused on loend kõigist dokumentidest, tööriistadest ja muudest komponentidest, mida tuleb testimise toetamiseks välja töötada ja hooldada.

Igas etapis on erinevad testitulemused tarkvaraarenduse elutsükkel.

Testi tulemused

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üklid on läbi.

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

Vahendid

Laadige alla testiplaani näidismall

Laadige alla Guru99 panga veebisaidi süsteemi testimise näidisplaan