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 – .
Mida te sellisel juhul ette võtate? Valige oma vastus järgmiselt jooniselt
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
- Analüüsige toodet
- Kavandage testimisstrateegia
- Määratlege testi eesmärgid
- Määratlege testimise kriteeriumid
- Ressursside planeerimine
- Planeeri katsekeskkond
- Ajakava ja prognoos
- Määrake testi tulemused
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
Nüüd rakendame ülaltoodud teadmisi reaalse toote puhul: Analüüsima panganduse veebisait http://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 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
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
- 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 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
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?
Millistele testimistüüpidele peaksite sel juhul keskenduma?
Valige Kõik, mis rakendatakse
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
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
- Loetlege kõik tarkvara funktsioonid (funktsionaalsus, jõudlus, GUI jne), mida võib olla vaja testida.
- 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
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.
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.
Ü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
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
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
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.
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