katsemudel on loogiline struktuur, mis kirjeldab süsteemi funktsionaalsust ja/või kasutaja käitumist, mille järgi genereeritakse testjuhtumid. Testmudeli ehitamine algab konstruktsiooni ehitamisest ja seejärel täidetakse kinnitatud struktuur testjuhtumitega.

Mudelid ehitatakse tavaliselt süsteemi nõuete ja/või eeldatava käitumise alusel. Testmudeli koostamine ja selle haldamine sobib keeruka äriloogikaga suurtele süsteemidele ning seda on keeruline rakendada agiilseid metoodikaid kasutavatele projektidele, sest katsemudeli haldamise ja kvaliteedi tagamise protsessi ülalpidamiskulud on liiga suured.

Testmudeli haldamine on protsess, mis kontrollib testmudeli katvust, testmudelit kirjeldavate stsenaariumide kvaliteeti ja selle aktualiseerimist.

Testmudeli haldamine on pidev protsess eluring toode.

Katsemudeli leviala

Kõigi nõuete katvuse kontrollimiseks saate kasutada jälgimismaatriksiid, mis määravad nõuete katvuse katsestsenaariumide kaupa (vt näidet).
Enne testjuhtumite kirjeldamist tuleb testimudeli struktuur kliendiga kooskõlastada.

Skripti kvaliteet

Stsenaariumide kvaliteedi juhtimiseks on vaja kontrollida mitte ainult testjuhtumite kirjeldamise taset, vaid ka nende kvaliteeti.

Enne testjuhtumite kirjeldamise alustamist on vaja määratleda igale kirjeldustasemele esitatavad nõuded ja testjuhtumite kirjeldamise kvaliteedi kriteeriumid.

Testjuhtumite kirjeldamise võimalikud tasemed:

4. tasemel saab kokkuleppe kliendiga asendada kokkuleppega.

Testjuhtumite kirjeldamise kvaliteedikriteeriumid võivad olla järgmised:

• Testjuhtumid tuleb kirjutada vastavalt nõuetele

Testimine on protsess, mille käigus kontrollitakse, kas toode vastab selle nõuetele. Seetõttu on testjuhtumi üldkirjelduse osas (testijälgimise süsteemides kasutatakse tavaliselt terminit „Kokkuvõte“) vaja viidata konkreetsele nõudele koos nõuete teksti fragmentidega. Seega saab kõigi projektis osalejate jaoks selgeks, mille põhjal see testjuhtum on kirjutatud.

• Kasutage üksikasjalikke eeltingimusi

Kuidas säästa aega testjuhtumitel?

Määrake kõigi testjuhtumite jaoks vormindamisreeglid. Seega on testjuhtum iga projektis osaleja jaoks kergesti mõistetav ja loetav. Näiteks projekti puhul saate sisestada järgmised reeglid.

• Kõik sisendparameetrid tuleb märkida punasega.
• Kõik skriptid peavad olema sinisega esile tõstetud,
• Kõik nuppude, väljade, plokkide nimed on kaldkirjas ja paksus kirjas.
• Olulised lõigud on alla joonitud.
• Igal sooritatud sammul peab olema oodatud tulemus.
• Testjuhtumite iga samm peaks kirjeldama ainult ühte toimingut ja selle eeldatavat tulemust. Need. konkreetses etapis ebaõnnestunud testjuhtumi saamisel peaks olema ühemõtteliselt selge, millisel toimingul viga ilmneb.
• Oodatav tulemus peab olema üheselt mõistetav.

Testjuhtumid peavad olema üheselt mõistetavad, s.t. tuleks koostada ja sõnastada nii, et need ei võimaldaks kahemõttelist tõlgendamist, kuid oleksid kõigile osalejatele selgelt arusaadavad.

Kui testjuhtumite kirjutamine võtab kaua aega, siis võib tekkida olukord, kus spetsialist ei näe enam oma vigu. Selleks on vaja vaadata kõrvalt – siin see aitab ristülevaade. See etapp on soovitatav läbi viia juhtudel, kui testmudeli väljatöötamine on ajaliselt pikenenud ja ajaliselt pikk. Näiteks kui teststsenaariumide väljatöötamine võtab rohkem kui 1 kuu.

Skripti kvaliteedikontrolli protsessi saab läbi viia koos testmudeli juhtimisega- spetsiaalselt valmistatud mall.

Katsemudeli värskendus

Nõuetele vastavuse tagamiseks on vaja regulaarselt uuendada testimudelit ja testjuhtumeid endid, samuti vaadata üle testjuhtumite prioriteedid.

Värskendamiseks saate säilitada "nõuete maatriksi"(Nõuete jälgitavuse maatriks): pärast iga teatud nõude muudatust tehakse testjälgimissüsteemist valik kõigist selle nõudega seotud katsestsenaariumidest ja neid uuendatakse.

Katsemudeli juhtnupud:

• prooviraudtee
• testi link
• Jira + Zefiir
• Microsoft Test Manager (MTM)
• excel

Testimine on protsess, mis võimaldab hinnata toodetava toote kvaliteeti. Kvaliteetne tarkvaratoode peab vastama sellele esitatavatele nõuetele, nii funktsionaalsele kui ka mittefunktsionaalsele. PS peab rakendama kõiki nõutud VI-sid ja sellel ei tohi olla defekte - erinevusi tegelike omaduste või käitumise vahel nõutavatest. Lisaks peavad PS-l olema töökindluse (ei tohi olla katkestusi, krahhi jne), turvalisuse, soovitud jõudluse, hõlpsasti kasutatav, laiendatav jne omadused. Seega on testimine PS-i analüüsimise protsess. , mille eesmärk on tuvastada defekte ja hinnata PS-i omadusi.

Testimisprotsessi eesmärgid

Testimise eesmärk on hinnata kvaliteeti tarkvaratoode läbi

• Komponentide koostoime kontrollid;
• komponentide õige integreerimise kontrollimine;
• Kõigi nõuete täitmise õigsuse kontrollimine ja defektide tuvastamine.

RUP-i testimisprotsessi omadused

Testimine on iteratiivne protsess kõigis elutsükli faasides. Testimine algab algusest esialgne etapp tulevasele tootele esitatavate nõuete tuvastamine ja praeguste ülesannetega tihedalt integreerimine. Iga iteratsiooni jaoks määratakse testimise eesmärk ja selle saavutamise meetodid. Iga iteratsiooni lõpus tehakse kindlaks, mil määral see eesmärk on saavutatud, kas on vaja täiendavaid teste, kas tuleks muuta põhimõtteid ja testimisvahendeid.

Iga leitud defekt registreeritakse projekti andmebaasis koos olukorra kirjeldusega, milles see leiti. Analüütik teeb kindlaks, kas tegemist on reaalse defektiga ja kas tegemist on varem avastatud defekti kordusega. Leitud defekt määratakse prioriteet A, mis näitab paranduse olulisust. Defekti parandab alamsüsteemi, komponendi või klassi väljatöötamise eest vastutav projekteerija või muu juhi poolt määratud isik. Defektide parandamise järjekorda reguleerivad nende prioriteedid. Testija kordab teste ja on veendunud (või ei ole veendunud), et defekt on parandatud.

Testarendaja vastutab testide kavandamise, väljatöötamise ja rakendamise eest. Ta koostab katseplaani ja mudeli, testimisprotseduurid (vt allpool) ning hindab testi tulemusi.

tester (testija) vastutab süsteemi testimise eest. Tema kohustuste hulka kuulub testide seadistamine ja läbiviimine, testi tulemuslikkuse hindamine, vigadest taastumine ja tuvastatud defektide registreerimine.

Artefaktid

Testimise käigus luuakse järgmised dokumendid:

Katseplaan– dokument, mis määratleb iga iteratsiooni testimisstrateegia. See sisaldab praeguse iteratsiooni testimise eesmärkide ja eesmärkide kirjeldust, samuti kasutatavaid strateegiaid. Plaan näitab, milliseid ressursse on vaja, ja sisaldab testide loendit.

Testmudel on esitus sellest, mida ja kuidas testitakse. Mudel sisaldab juhtimisülesannete komplekti, testimismeetodeid, testistsenaariume ja oodatavaid tulemusi (testjuhtumid), testiskripte ja testi interaktsioonide kirjeldusi.

• Kontrolli ülesanne– testandmete kogum, testi teostamise tingimused ja oodatavad tulemused.
• Testimis viis– dokument, mis sisaldab juhiseid kontrolliülesannete seadmiseks ja täitmiseks, samuti saadud tulemuste hindamiseks.
• Testi skript- see on testi lihtsustatud kirjeldus, mis sisaldab lähteandmeid, tingimusi ja toimingute järjestust ning oodatavaid tulemusi.
• Testi skript on programm, mis käivitatakse automatiseeritud testimise käigus, kasutades testtööriistu.
• Katse interaktsiooni kirjeldus on jadade või koostöö diagramm, mis kajastab ajas järjestatud sõnumite voogu testitavate komponentide ja testitava objekti vahel.

Testi tulemused ja testide läbiviimisel saadud andmed.

Töökoormuse mudel kasutatakse lõppkasutajate teostatavate väliste funktsioonide, nende funktsioonide ulatuse ja nende funktsioonide tekitatud töökoormuse modelleerimiseks. Mudel on mõeldud koormus- ja/või stressitestide läbiviimiseks, mis simuleerivad süsteemi tööd reaalsetes tingimustes.

Defektid- need on testimise käigus leitud süsteemi nõuetele mittevastavuse faktide kirjeldused. Need on teatud tüüpi muudatustaotlused.

Testimistööd viiakse läbi igas iteratsioonis kõigis etappides, kuid eesmärgid ja eesmärgid projekti eri etappides on oluliselt erinevad.

Projekti sisenemise etapp. Selles etapis valmistatakse ette katseid. See sisaldab:

• Looge katseplaan, mis sisaldab testimise nõudeid ja testimisstrateegiaid. Igat tüüpi testimiseks (funktsionaalne, koormus jne) saab luua ühe plaani või iga tüübi jaoks eraldi plaanid.
• Testimise ulatuse analüüs.
• Kvaliteedikriteeriumide sõnastamine ja testimise lõpetamine.
• Testimisvahendite paigaldamine ja tööks ettevalmistamine.
• PS arendusprojekti nõuete sõnastamine, mis on määratud testimise vajadustega.

Arendusfaas. Selle faasi iteratsioonides algab testmudeli ja sellega seotud artefaktide ehitamine. Kuna VI mudel on selles faasis juba olemas, võite alustada katsestsenaariumide kavandamist. Samal ajal ei ole soovitatav teste teha, kuna tavaliselt pole selles faasis veel valmis PS-i fragmente. Teostatakse järgmisi tegevusi:

• Testistsenaariumide väljatöötamine.
• Testskriptide loomine.
• Kontrolliülesannete väljatöötamine.
• Katsemeetodite väljatöötamine.
• Töökoormuse mudeli väljatöötamine.

Ehitusetapp. Selles faasis ilmuvad valmis süsteemifragmendid ja prototüübid, mida tuleb testida. Samal ajal kontrollitakse peaaegu igas iteratsioonis kõiki mooduleid (nii varem arendatud ja testitud kui ka praeguses iteratsioonis lisatud uusi). Varasemates iteratsioonides rakendatud teste kasutatakse ka järgnevates iteratsioonides regressioonitestimiseks, st kontrollimaks, kas varem juurutatud süsteemi funktsionaalsus on uues iteratsioonis säilinud. Teostatakse järgmisi tegevusi:

• Koostage iga iteratsiooni jaoks testiplaan.
• Testimismudeli täpsustamine ja lisamine.
• Testide sooritamine.
• Leitud defektide kirjeldus.
• Katsetulemuste kirjeldus.
• Testitulemuste hindamine.

Testimise tulemuste põhjal tehakse programmikoodis muudatused tuvastatud defektide kõrvaldamiseks, misjärel testimist korratakse.

Kasutuselevõtu faas. Selle faasi iteratsioonidel testitakse kogu PS-i tarkvaratootena. Läbiviidud tegevused on sarnased eelmise etapi tegevustega. Defektide tuvastamine määrab muudatuste ja uuesti testimise vajaduse. Iteratiivset protsessi korratakse, kuni testi lõpetamise kriteeriumid on täidetud.

Testitulemusi hinnatakse testimismõõdikute alusel, mis võimaldavad määrata testitava PS kvaliteedi ja testimisprotsessi enda.

Instrumentaalne tugi

Kuna iteratiivne testimisprotsess hõlmab mitut testide kordamist, muutub käsitsi testimine ebaefektiivseks ega võimalda tarkvaratoote kvaliteeti põhjalikult hinnata. See kehtib eriti koormus- ja stressitestide kohta, kus peate töökoormust simuleerima ja koguma märkimisväärsel hulgal andmeid. Lahenduseks on kasutada tööriistu, mis toetavad testide koostamise ja täitmise automatiseerimist.

Sarnaselt arendusprotsessiga järgib ka tarkvara järeltestimise protsess kindlat metoodikat. Metoodika all peame antud juhul silmas erinevaid põhimõtete, ideede, meetodite ja kontseptsioonide kombinatsioone, mida projekti kallal töötades kasutate.

Praegu on testimisel üsna palju erinevaid lähenemisviise, millest igaühel on oma lähtepunktid, täitmise kestus ja igas etapis kasutatavad meetodid. Ja ühe või teise valimine võib olla üsna suur väljakutse. Selles artiklis vaatleme erinevaid tarkvara testimise lähenemisviise ja räägime nende põhifunktsioonidest, mis aitavad teil olemasolevas sordis navigeerida.

Kose mudel (lineaarne järjestikune tarkvara elutsükli mudel)

Waterfall Model on üks vanemaid mudeleid, mida saab kasutada mitte ainult tarkvara arendamiseks või testimiseks, vaid ka peaaegu kõigi teiste projektide jaoks. Tema põhiprintsiip on ülesannete täitmise järjestus. See tähendab, et järgmise arendus- või testimisetapi juurde saame minna alles siis, kui eelmine on edukalt läbitud. See mudel sobib väikeste projektide jaoks ja on rakendatav ainult siis, kui kõik nõuded on selgelt määratletud. Selle metoodika peamised eelised on majanduslik efektiivsus, kasutusmugavus ja dokumentatsioonihaldus.

Tarkvara testimise protsess algab pärast arendusprotsessi lõppu. Selles etapis viiakse kõik vajalikud testid üksustelt üle süsteemi testimisele, et kontrollida komponentide tööd nii üksikult kui ka tervikuna.

Lisaks ülalmainitud eelistele on sellel testimisviisil ka puudusi. Testimisprotsessis on alati võimalus leida kriitilisi vigu. See võib kaasa tuua vajaduse täielikult muuta üht süsteemikomponenti või isegi kogu projekti loogikat. Kuid selline ülesanne on juga mudeli puhul võimatu, kuna selle metoodika eelmise etapi juurde naasmine on keelatud.

Lisateavet kose mudeli kohta leiate eelmisest artiklist..

V-mudel (kontrolli ja kinnitamise mudel)

Sarnaselt Waterfall mudelile põhineb V-mudel otsesel sammude jadal. Peamine erinevus nende kahe metoodika vahel seisneb selles, et testimine on antud juhul planeeritud paralleelselt vastava arendusetapiga. Selle tarkvara testimise metoodika järgi algab protsess kohe, kui nõuded on määratletud ja saab võimalikuks alustada staatilise testimisega, s.t. kontrollimine ja ülevaatus, mis väldib võimalikke tarkvaravigu hilisemates etappides. Iga tarkvaraarenduse taseme jaoks koostatakse sobiv testimisplaan, mis määratleb selle toote eeldatavad tulemused ning sisenemise ja väljumise kriteeriumid.

Selle mudeli skeem näitab ülesannete jagamise põhimõtet kaheks osaks. Disaini ja arendusega seotud on paigutatud vasakule. Tarkvara testimisega seotud ülesanded asuvad paremal:

Selle metoodika põhietapid võivad erineda, kuid sisaldavad tavaliselt järgmist.

• Lava nõuete määratlused. Sellesse faasi kuulub vastuvõtmistestimine. Selle põhiülesanne on hinnata süsteemi valmisolekut lõppkasutuseks.
• Etapp, kus kõrgetasemeline disain või kõrgetasemeline disain (HDL). See etapp viitab süsteemi testimisele ja sisaldab integreeritud süsteemide nõuetele vastavuse hindamist.
• Detailse projekteerimise etapp(Detailne disain) on paralleelne integratsiooni testimise etapiga, mille käigus testitakse süsteemi erinevate komponentide vahelisi koostoimeid.
• Pärast kodeerimise etapp Algab veel üks oluline samm – ühikutestimine. Väga oluline on jälgida, et tarkvara üksikute osade ja komponentide käitumine oleks õige ja vastaks nõuetele.

Vaadeldava testimismetoodika ainsaks puuduseks on valmislahenduste puudumine, mida saaks rakendada testimisfaasis leitud tarkvaravigadest vabanemiseks.

inkrementaalne mudel

Seda metoodikat võib kirjeldada kui mitme kaskaadi tarkvara testimise mudelit. Töövoog on jagatud mitmeks tsükliks, millest igaüks on samuti jagatud mooduliteks. Iga iteratsioon lisab tarkvarale teatud funktsioone. Kasv koosneb kolmest tsüklist:

1. projekteerimine ja arendus
2. testimine
3. rakendamine.

Selles mudelis on võimalik toote erinevate versioonide samaaegne arendamine. Näiteks võib esimene versioon olla testimisfaasis, samal ajal kui teine ​​versioon on väljatöötamisel. Kolmas versioon võib läbida projekteerimisetapi samal ajal. See protsess võib kesta kuni projekti lõpuni.

Ilmselgelt nõuab see metoodika testitavas tarkvaras võimalikult kiire vigade tuvastamist. Nagu ka juurutamise faas, mis eeldab lõpptarbijani jõudva toote valmisoleku kinnitust. Kõik need tegurid suurendavad oluliselt testimisnõuete kaalu.

Võrreldes varasemate metoodikatega, inkrementaalne mudel sellel on mitmeid olulisi eeliseid. See on paindlikum, nõuete muutumine toob kaasa madalamad kulud ja tarkvara testimise protsess on tõhusam, kuna testimine ja silumine on väikeste iteratsioonide abil palju lihtsam. Siiski väärib märkimist, et kogumaksumus siiski kõrgem kui kaskaadmudeli puhul.

spiraalne mudel

Spiraalmudel on tarkvara testimise metoodika, mis põhineb järkjärgulisel lähenemisel ja prototüüpimisel. See koosneb neljast etapist:

1. Planeerimine
2. Riskianalüüs
3. Areng
4. Hinne

Kohe pärast esimese tsükli lõppu algab teine. Tarkvara testimine algab planeerimisetapis ja jätkub kuni hindamisetapini. Spiraalmudeli peamiseks eeliseks on see, et esimesed testitulemused ilmnevad kohe pärast testide tulemusi iga tsükli kolmandas etapis, mis aitab tagada õige kvaliteedi hindamise. Siiski on oluline meeles pidada, et see mudel võib olla üsna kallis ega sobi väikeste projektide jaoks.

Kuigi see mudel on üsna vana, on see kasulik nii testimiseks kui ka arendamiseks. Lisaks peamine eesmärk paljud tarkvara testimise metoodikad, sealhulgas spiraalmudel, on viimasel ajal muutunud. Me kasutame neid mitte ainult rakenduste defektide leidmiseks, vaid ka nende põhjuste väljaselgitamiseks. See lähenemisviis aitab arendajatel tõhusamalt töötada ja vead kiiresti parandada.

Loe spiraalmudeli kohta pikemalt eelmisest blogipostitusest..

Agiilne

Agiilset tarkvaraarenduse metoodikat ja tarkvara testimist võib kirjeldada kui lähenemiste kogumit, mis on keskendunud interaktiivse arenduse kasutamisele, nõuete dünaamilisele kujundamisele ja nende rakendamise tagamisele pideva interaktsiooni tulemusena iseorganiseeruvas organisatsioonis. töögrupp. Enamiku agiilsete tarkvaraarenduse metoodikate eesmärk on minimeerida riske arenduse kaudu lühikeste iteratsioonidega. Selle paindliku strateegia üks põhiprintsiipe on võime kiiresti reageerida võimalikele muutustele, mitte loota pikaajalisele planeerimisele.

Lisateave Agile'i kohta(märkus – artikkel inglise keeles).

Extreme Programming (XP, Extreme Programming)

Extreme Programming on üks näide paindlikust tarkvaraarendusest. Selle metoodika eripäraks on "paarprogrammeerimine", olukord, kus üks arendaja töötab koodi kallal, samal ajal kui tema kolleeg vaatab pidevalt kirjutatud koodi üle. Tarkvara testimise protsess on üsna oluline, kuna see algab juba enne koodi esimese rea kirjutamist. Igal rakendusemoodulil peaks olema üksuse test, et enamikku vigu saaks kodeerimisetapis parandada. Teine eristav omadus on see, et test määrab koodi ja mitte vastupidi. See tähendab, et teatud koodijupi saab lugeda lõpetatuks ainult siis, kui kõik testid läbivad. Vastasel juhul lükatakse kood tagasi.

Selle metoodika peamised eelised on pidev testimine ja lühikesed väljalasked, mis aitab tagada kõrge kvaliteet kood.

Scrum

Scrum – osa Agile’i metoodikast, iteratiivne inkrementaalne raamistik, mis on loodud tarkvaraarenduse protsessi haldamiseks. Vastavalt Scrumi põhimõtetele peaks testimismeeskond olema kaasatud järgmistesse sammudesse:

• Scrumi planeerimises osalemine
• Üksuse testimise tugi
• Kasutaja loo testimine
• Nõustamiskriteeriumide kindlaksmääramiseks tehke koostööd kliendi ja tooteomanikuga
• Automatiseeritud testimise pakkumine

Lisaks peaksid QA liikmed olema kohal kõikidel igapäevastel koosolekutel, nagu ka teised meeskonnaliikmed, et arutada, mida testiti ja tehti eile, mida testitakse täna, samuti testimise üldist edenemist.

Samal ajal viivad Scrumi Agile metoodika põhimõtted spetsiifiliste tunnuste esilekerkimiseni:

• Iga kasutajaloo jaoks vajalike jõupingutuste hindamine on kohustuslik
• Testija peab olema nõuete suhtes tähelepanelik, kuna need võivad kogu aeg muutuda.
• Regressiooni oht suureneb sagedaste koodimuutuste korral.
• Testide samaaegne planeerimine ja läbiviimine
• Arusaamatus meeskonnaliikmete vahel juhul, kui kliendi nõuded pole täiesti selged

Lisateavet Scrumi metoodika kohta leiate eelmisest artiklist..

Järeldus

Kokkuvõtteks on oluline märkida, et tänapäeval eeldab ühe või teise tarkvara testimise metoodika kasutamise praktika mitmekülgset lähenemist. Teisisõnu, te ei tohiks eeldada, et ükski metoodika sobib igat tüüpi projektide jaoks. Neist ühe valik sõltub paljudest aspektidest, nagu projekti tüüp, kliendi nõuded, tähtajad ja paljud teised. Tarkvara testimise vaatenurgast on tavaline, et mõnda metoodikat alustatakse testimisega varajases arenduses, samas kui teiste puhul on tavaks oodata, kuni süsteem on valmis.

Olenemata sellest, kas vajate abi tarkvara arendamisel või testimisel, on spetsiaalne arendajate ja kvaliteedikontrolli inseneride meeskond valmis tegutsema.

Veebiteenuste testimine

Enamik Parim viis hinnata, kas oleme toodet hästi testinud – analüüsige puuduvaid defekte. Need, millega meie kasutajad, juurutajad ja ettevõtted silmitsi seisavad. Nende põhjal saate palju hinnata: mida me ei kontrollinud piisavalt põhjalikult, millistele toote valdkondadele tuleks rohkem tähelepanu pöörata, milline on väljajätmiste protsent üldiselt ja milline on selle muutuste dünaamika. Selle (võib-olla testimisel levinuima) mõõdikuga on kõik korras, aga ... Kui toote välja andsime ja vahelejäänud vigadest teada saime, võis olla juba hilja: Habres ilmus meie kohta vihane artikkel, konkurendid on kiiresti leviv kriitika, kliendid on kaotanud meie vastu usalduse, juhtkond on rahulolematu.

Et seda ei juhtuks, püüame tavaliselt eelnevalt, enne väljalaskmist hinnata testimise kvaliteeti: kui hästi ja põhjalikult me ​​toodet kontrollime? Millistele valdkondadele jääb tähelepanuta, kus on peamised riskid, millised on edusammud? Kõigile neile küsimustele vastamiseks hindame testi katvust.

Miks hinnata?

Igasugune hindamismõõdik on ajaraisk. Sel ajal saate testida, käivitada vigu, valmistada ette automaatteste. Millist maagilist kasu saame testi katvuse mõõdikutest testimisaja ohverdamisele?

1. Oma nõrkade kohtade leidmine. Loomulikult vajame seda? mitte ainult kurvastama, vaid ka teadma, kus on vaja parandusi. Milliseid funktsionaalseid valdkondi testid ei hõlma? Mida me pole kontrollinud? Kus on suurim oht ​​vigade puudumiseks?
2. Harva saame hindamistulemustest 100% katvuse. Mida parandada? Kuhu minna? Kui suur on nüüd protsent? Kuidas saame seda mis tahes ülesandega suurendada? Kui kiiresti saame 100-ni? Kõik need küsimused toovad meie protsessi läbipaistvuse ja selguse., ja vastused neile annab katvuse prognoos.
3. Tähelepanu fookus. Oletame, et meie tootel on umbes 50 erinevat funktsionaalset piirkonda. välja tulema uus versioon, ja hakkame testima neist 1. ja leiame sealt kirjavigu ja paar pikslit liigutanud nuppe ja muid pisiasju ... Ja nüüd on testimise aeg läbi ja see funktsionaalsus on üksikasjalikult testitud. Ja ülejäänud 50? Katvuse hindamine võimaldab meil seada ülesanded tähtsuse järjekorda lähtuvalt hetkeoludest ja tähtaegadest.

Kuidas hinnata?

Enne mis tahes mõõdiku rakendamist on oluline otsustada, kuidas seda kasutada. Alustage täpselt sellele küsimusele vastamisega - tõenäoliselt saate kohe aru, kuidas seda kõige parem arvutada. Ja ma jagan selles artiklis ainult mõningaid näiteid ja oma kogemusi selle kohta, kuidas seda teha. Mitte selleks, et lahendusi pimesi kopeerida – vaid selleks, et Sinu fantaasia saaks sellele kogemusele toetuda, mõeldes läbi Sulle ideaalse lahenduse.

Nõuete katvuse hindamine testidega

Oletame, et teie meeskonnas on analüütikud ja nad ei kuluta oma aega asjata. tööaeg. Nende töö tulemuste põhjal loodi nõuded RMS-is (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (koos lisapluginatega) jne. Selles süsteemis teevad nad nõudeid, mis vastavad nõuete nõuetele (vabandan tautoloogia pärast). Need nõuded on atomaarsed, jälgitavad, spetsiifilised... Üldiselt ideaalsed tingimused testimiseks. Mida me saame sellisel juhul teha? Skriptitud lähenemisviisi kasutamisel siduge nõuded ja testid. Teeme teste samas süsteemis, teeme nõue-testi ühenduse ja igal ajal näeme aruannet, millistel nõuetele on testid, millistel mitte, millal need testid läbiti ja mis tulemusega.
Saame levikaardi, katame kõik katmata nõuded, kõik on õnnelikud ja rahul, me ei jäta vigadest ilma ...

Olgu, lähme tagasi maa peale. Tõenäoliselt pole teil üksikasjalikke nõudeid, need ei ole tuumakad, mõned nõuded on üldiselt kadunud ja iga testi või vähemalt iga teise dokumenteerimiseks pole aega. Võib meelt heita ja nutta või tunnistada, et testimine on kompenseeriv protsess ning mida kehvem on meil projekti analüütika ja arendustegevusega, seda rohkem peaksime ise proovima ja kompenseerima teiste protsessis osalejate probleeme. Analüüsime probleeme eraldi.

Probleem: nõuded ei ole tuumakad.

Ka analüütikud patustavad mõnikord salatiga peas ja tavaliselt on see täis probleeme kogu projektiga. Näiteks töötate välja tekstiredaktorit ja teie süsteemis võib (muu hulgas) olla kaks nõuet: "tuleb toetada html-vormingut" ja "toetamata vormingus faili avamisel avaneb küsimusega hüpikaken peab ilmuma." Mitu katset on vaja esimese nõude põhikontrolliks? Ja 2. jaoks? Vastuste erinevus on suure tõenäosusega umbes sajakordne!!! Me ei saa öelda, et kui esimese nõude kohta on vähemalt 1 test, siis sellest piisab - teise kohta aga tõenäoliselt täielikult.

Seega ei garanteeri nõuete testi läbimine meile üldse midagi! Mida meie katvusstatistika antud juhul tähendab? Peaaegu mitte midagi! Peame otsustama!

1. Sel juhul saab testide nõuete katvuse automaatse arvutamise eemaldada - see ei kanna endiselt semantilist koormust.
2. Iga nõude jaoks, alustades kõrgeimast prioriteedist, koostame testid. Ettevalmistamisel analüüsime, milliseid teste selle nõude täitmiseks vaja läheb, kui paljudest piisab? Teeme täiemahulise testanalüüsi ega jäta kõrvale "üks test on, aga olgu."
3. Olenevalt kasutatavast süsteemist ekspordime/laadime üles nõudmisel teste ja… testime neid teste! Kas neist piisab? Ideaalis tuleks selline testimine muidugi läbi viia koos analüütiku ja selle funktsionaalsuse arendajaga. Printige testid välja, lukustage kolleegid koosolekuruumi ja ärge laske lahti enne, kui nad ütlevad "jah, nendest testidest piisab" (see juhtub ainult kirjalikul kokkuleppel, kui neid sõnu öeldakse tellimisest loobumiseks, isegi ilma teste analüüsimata). Suulise arutelu ajal valavad kolleegid välja vannikriitikat, tegemata jäetud teste, valesti mõistetud nõudeid jne – see pole alati meeldiv, kuid testimisel väga kasulik!)
4. Pärast nõudmisel testide lõpetamist ja nende täielikkuses kokkuleppimist saab selle nõude süsteemis märkida olekuga "testidega kaetud". See teave tähendab palju enamat kui "siin on vähemalt 1 test".

Loomulikult nõuab selline kokkuleppeprotsess palju ressursse ja aega, eriti alguses, kuni praktika välja kujuneb. Seetõttu täitke sellel ainult kõrge prioriteediga nõudeid ja uusi täiustusi. Aja jooksul karmistage ülejäänud nõudeid ja kõik on rahul! Aga ... ja kui nõudeid üldse pole?

Probleem: nõudeid pole üldse.

Nad puuduvad projektist, arutatakse suuliselt, igaüks teeb, mida tahab/oskab ja kuidas aru saab. Testime sama. Selle tulemusel tekib meil tohutul hulgal probleeme mitte ainult testimisel ja arendusel, vaid ka funktsioonide algselt ebaõige rakendamisega - tahtsime midagi täiesti erinevat! Siin saan soovitada valikut “määratle ja dokumenteeri nõuded ise” ja isegi kasutasin seda strateegiat paar korda oma praktikas, kuid 99% juhtudest pole testimismeeskonnas selliseid ressursse - nii et teeme palju vähem ressursimahukas viis:

1. Loo funktsioonide loend. Sami! Google'i tahvelarvuti kujul, PBI-vormingus TFS-is - valige ükskõik milline, kui see pole tekstivorming. Peame veel staatuseid koguma! Lisame sellesse loendisse kõik toote funktsionaalsed alad ja proovime valida ühe üldise lagunemistase (saate välja kirjutada tarkvaraobjekte või kasutaja skripte või mooduleid või veebilehti või API meetodeid või ekraanivorme .. .) – aga mitte kõike korraga! ÜKS lagunemisvorming, mis muudab lihtsamaks ja selgemaks, et te ei jäta olulisi asju kahe silma vahele.
2. Koordineerime selle loendi TÄIELIKUSE analüütikute, arendajate, ettevõtetega, oma meeskonnas ... Püüdke teha kõik, et mitte kaotada toote olulisi osi! Kui sügavalt analüüsida, on teie otsustada. Minu praktikas oli ainult paar toodet, mille jaoks lõime tabelisse üle 100 lehekülje ja need olid hiiglaslikud tooted. Kõige sagedamini on 30-50 rida edasise hoolika töötlemise jaoks saavutatav tulemus. Väikeses meeskonnas ilma pühendunud testanalüütikuteta rohkem fichelista elemente oleks liiga raske säilitada.
3. Pärast seda vaatame läbi prioriteedid ja töötleme kirjeldusloendi iga rida nagu eespool kirjeldatud nõuete jaotises. Kirjutame teste, arutame, lepime kokku piisavuse. Märgime olekud, millise funktsiooni jaoks on piisavalt teste. Testide staatuse, edenemise ja laienemise saame meeskonnaga suhtlemise kaudu. Kõik on õnnelikud!

Aga... Mis siis, kui nõuded säilivad, aga mitte jälgitavas vormingus?

Probleem: nõuded ei ole jälgitavad.

Projekti kohta on tohutult palju dokumentatsiooni, analüütikud kirjutavad kiirusega 400 tähemärki minutis, teil on spetsifikatsioonid, tehnilised kirjeldused, juhised, viited (enamasti juhtub see kliendi soovil) ja kõik see toimib nõuded ja kõik on projektis olnud juba pikka aega Segane, kust millist infot otsida?
Eelmise lõigu kordamine, aidates kogu meeskonnal koristada!

1. Koostame funktsioonide loendi (vt ülalt), kuid ilma nõuete üksikasjaliku kirjelduseta.
2. Iga funktsiooni jaoks kogume kokku lingid tehnilistele spetsifikatsioonidele, spetsifikatsioonidele, juhistele ja muudele dokumentidele.
3. Lähtume prioriteetidest, koostame teste ja lepime kokku nende täielikkuses. Kõik on sama, ainult tänu kõigi dokumentide ühendamisele ühel plaadil suurendame neile juurdepääsu lihtsust, läbipaistvaid olekuid ja testide järjepidevust. Lõpuks on kõik super ja kõik on õnnelikud!

Aga... Mitte kauaks... Tundub, et viimase nädala jooksul on analüütikud klientide soovide põhjal uuendanud 4 erinevat spetsifikatsiooni!!!

Probleem: nõuded muutuvad kogu aeg.

Muidugi oleks tore testida mõnda fikseeritud süsteemi, kuid meie tooted on tavaliselt pinge all. Klient küsis midagi, midagi muutus meie tootevälises seadusandluses ja kuskilt leidsid analüütikud üle-eelmise aasta analüüsivea... Nõuded elavad oma elu! Mida teha?

1. Oletame, et olete juba kogunud linke TK-le ja spetsifikatsioonidele funktsioonide loendi, PBI, nõuete, Wiki märkmete jms kujul. Oletame, et teil on nende nõuete jaoks testid juba olemas. Ja nüüd on nõue muutumas! See võib tähendada muudatust RMS-is või ülesannet TMS-is (Task Management System) või kirja saatmist posti teel. Mõlemal juhul annab see sama tulemuse: teie testid on aegunud! Või võivad need olla ebaolulised. See tähendab, et need vajavad värskendamist (katvus testidega vana versioon toodet millegipärast väga ei peeta, eks?)
2. Funktsioonide loendis, RMS-is, TMS-is (testihaldussüsteem - testrails, sitechco jne) tuleb testid kohe ja veatult märkida ebaoluliseks! HP QC-s või MS TFS-is saab seda nõuete värskendamisel automaatselt teha ning google-tahvelarvutis või wikis tuleb pastakad käest panna. Kuid te peaksite kohe nägema: testid pole olulised! See tähendab, et ootame täielikku ümberteed: uuendame, käivitame uuesti testanalüüsi, kirjutame testid ümber, lepime kokku muudatused ja alles pärast seda märgime funktsiooni/nõude uuesti kui “testidega kaetud”.

Sel juhul saame kõik testi ulatuse hindamise eelised ja isegi dünaamikas! Kõik on õnnelikud!!! Aga…
Kuid olete keskendunud nii palju nõuetega töötamisele, et nüüd pole teil piisavalt aega testide testimiseks ega dokumenteerimiseks. Minu meelest (ja usuvaidlusel on koht!) on nõuded olulisemad kui testid ja nii on parem! Vähemalt on need korras ja kogu meeskond on kursis ning arendajad teevad täpselt seda, mida vaja. AGA EI OLE AEGA TESTIDE DOKUMENTERIMISEKS!

Probleem: testide dokumenteerimiseks pole piisavalt aega.

Tegelikult võib selle probleemi põhjuseks olla mitte ainult ajapuudus, vaid ka teie täiesti teadlik valik neid mitte dokumenteerida (meile see ei meeldi, väldime pestitsiidset toimet, toode muutub liiga sageli jne). Aga kuidas sel juhul testi katvust hinnata?

1. Teil on endiselt vaja nõudeid täisnõuetena või funktsioonide loendina, nii et üks ülaltoodud jaotistest on olenevalt projekti analüütikute tööst siiski vajalik. Kas teil on nõue/funktsioonide loend?
2. Kirjeldame ja lepime suuliselt kokku lühikese testimisstrateegia, ilma konkreetseid teste dokumenteerimata! Selle strateegia võib täpsustada tabeli veerus, wiki lehel või RMS-i nõudes ja sellega tuleb jälle kokku leppida. Selle strateegia osana tehakse ülevaatusi erinevatel viisidel, kuid te teate: millal see on viimane kord testitud ja millise strateegiaga? Ja see, näete, pole ka halb! Ja kõik saavad õnnelikuks.

Aga… Mis veel "kui"? Milline???

Ütle, me teeme kõik ümber ja olgu kvaliteetsed tooted meiega!

| Tunni planeerimine õppeaastaks | Modelleerimise põhietapid

2. õppetund
Modelleerimise põhietapid

Seda teemat uurides saate teada:

Mis on modelleerimine;
- mis võib olla modelleerimise prototüübiks;
- milline on modelleerimise koht inimtegevuses;
- millised on modelleerimise peamised etapid;
- mis on arvutimudel;
Mis on arvutikatse.

arvutikatse

Uutele disainiarendustele elu andmiseks, uute tehniliste lahenduste toomiseks tootmisse või uute ideede katsetamiseks on vaja katset. Katse on katse, mis viiakse läbi objekti või mudeliga. See seisneb teatud toimingute sooritamises ja selle kindlaksmääramises, kuidas eksperimentaalne valim neile toimingutele reageerib.

Koolis teete katseid bioloogia, keemia, füüsika, geograafia tundides.

Uute tootenäidiste katsetamisel ettevõtetes tehakse katseid. Tavaliselt kasutatakse selleks spetsiaalselt loodud seadistust, mis võimaldab teha katset laboritingimustes või tehakse reaalse toote endaga kõikvõimalikke katseid (täismahus katse). Näiteks seadme või sõlme tööomaduste uurimiseks asetatakse see termostaadi, külmutatakse spetsiaalsetes kambrites, testitakse vibratsioonistenditel, kukutatakse maha jne. Hea, kui tegemist on uue kella või tolmuimejaga - kaotus hävitamise ajal ei ole suur. Mis siis, kui see on lennuk või rakett?

Laboratoorsed ja täismahus katsed nõuavad suuri materjalikulusid ja aega, kuid nende tähtsus on sellegipoolest väga suur.

Arenguga arvutitehnoloogia ilmus uus ainulaadne uurimismeetod - arvutikatse. Paljudel juhtudel on arvutisimulatsiooniuuringud aidanud katseproove ja katsestendid, mõnikord isegi asendada. Arvutikatse läbiviimise etapp sisaldab kahte etappi: katseplaani koostamine ja uuringu läbiviimine.

Katseplaan

Katseplaan peaks selgelt kajastama mudeliga töötamise järjekorda. Sellise plaani esimene samm on alati mudeli testimine.

Testimine on konstrueeritud mudeli õigsuse kontrollimise protsess.

Test – algandmete kogum, mis võimaldab kindlaks teha mudeli ehituse õigsuse.

Saadud modelleerimistulemuste õigsuses veendumiseks on vaja: ♦ kontrollida mudeli koostamise väljatöötatud algoritmi; ♦ veenduge, et konstrueeritud mudel kajastaks õigesti originaali omadusi, mida simulatsioonis arvesse võeti.

Mudeli koostamise algoritmi õigsuse kontrollimiseks kasutatakse lähteandmete testkomplekti, mille lõpptulemus on eelnevalt teada või muul viisil ette määratud.

Näiteks kui kasutate modelleerimisel arvutusvalemeid, peate algandmete jaoks valima mitu valikut ja arvutama need "käsitsi". Need on testelemendid. Kui mudel on üles ehitatud, siis testitakse samade sisenditega ja võrreldakse simulatsiooni tulemusi arvutustega saadud järeldustega. Kui tulemused ühtivad, siis on algoritm õigesti välja töötatud, kui mitte, siis tuleb otsida ja kõrvaldada nende lahknevuse põhjus. Testiandmed ei pruugi tegelikku olukorda üldse kajastada ega sisaldada semantilist sisu. Testimise käigus saadud tulemused võivad aga sundida mõtlema algse teabe- või märgimudeli muutmisele, eelkõige selle selles osas, kus on kirjas semantiline sisu.

Veendumaks, et konstrueeritud mudel kajastab originaali omadusi, mida simulatsioonis arvesse võeti, on vaja valida reaalsete lähteandmetega testnäide.

Uuringute läbiviimine

Pärast testimist, kui olete konstrueeritud mudeli õigsuses kindel, võite jätkata otse uuringuga.

Plaan peaks sisaldama katset või katsete seeriat, mis vastavad simulatsiooni eesmärkidele. Iga katsega peab kaasnema arusaamine tulemustest, mis on aluseks modelleerimise tulemuste analüüsimisel ja otsuste tegemisel.

Arvutikatse ettevalmistamise ja läbiviimise skeem on näidatud joonisel 11.7.

Riis. 11.7. Arvutikatse skeem

Simulatsiooni tulemuste analüüs

Modelleerimise lõppeesmärk on teha otsus, mis tuleks välja töötada simulatsioonitulemuste igakülgse analüüsi põhjal. See etapp on otsustav – kas jätkate õppimist või lõpetate. Joonis 11.2 näitab, et tulemuste analüüsi faas ei saa eksisteerida iseseisvalt. Saadud järeldused aitavad sageli kaasa täiendavale katseseeriale ja mõnikord ka probleemi muutumisele.

Testide ja katsete tulemused on lahenduse väljatöötamise aluseks. Kui tulemused ei vasta ülesande eesmärkidele, tähendab see, et eelmistes etappides tehti vigu. See võib olla kas probleemi vale püstitus või infomudeli liialt lihtsustatud konstrueerimine või ebaõnnestunud modelleerimismeetodi või -keskkonna valik või tehnoloogiliste meetodite rikkumine mudeli koostamisel. Kui sellised vead tuvastatakse, tuleb mudelit parandada, st naasta ühte eelmistest etappidest. Protsessi korratakse seni, kuni katse tulemused vastavad simulatsiooni eesmärkidele.

Peamine asi, mida meeles pidada, on see, et tuvastatud viga on ka tulemus. Nagu vanasõna ütleb, õpitakse oma vigadest. Sellest kirjutas ka suur vene luuletaja A. S. Puškin:

Oh, kui palju imelisi avastusi meil on
Valmistage ette valgustusvaim
Ja kogemus, raskete vigade poeg,
Ja geenius, paradokside sõber,
Ja juhus, jumal on leiutaja...

Kontrollküsimused ja ülesanded

1. Millised on modelleerimise probleemiavalduse kaks peamist tüüpi.

2. G. Osteri tuntud "Probleemiraamatus" on järgmine probleem:

Väsimatult töötav kuri nõid muudab 30 printsessi röövikuteks päevas. Mitu päeva võtab tal aega, et muuta 810 printsessi röövikuteks? Mitu printsessi tuleks päevas röövikuteks muuta, et töö 15 päevaga tehtud saaks?
Millise küsimuse saab omistada tüübile "mis juhtub, kui ..." ja milline - "kuidas teha, et ..."?

3. Loetlege modellinduse tuntuimad eesmärgid.

4. Vormistage mänguline probleem G. Osteri "Probleemiraamatust":

Kahest üksteisest 27 km kaugusel asuvast putkast hüppasid korraga välja kaks jõhkrat koera. Esimene töötab kiirusega 4 km / h ja teine ​​- 5 km / h.
Kui kaua võitlus algab?

5. Nimetage võimalikult palju "kingapaari" objekti omadusi. Koostage objekti teabemudel erinevatel eesmärkidel:
■ matkajalatsite valik;
■ sobiva kingakarbi valik;
■ kingahoolduskreemi ostmine.

6. Millised teismelise omadused on elukutse valiku soovituse jaoks olulised?

7. Miks kasutatakse arvutit simulatsioonis laialdaselt?

8. Nimetage teile teadaolevad arvutimodelleerimise tööriistad.

9. Mis on arvutikatse? Too näide.

10. Mis on mudeli testimine?

11. Milliseid vigu modelleerimisprotsessis ilmneb? Mida tuleks teha, kui avastatakse viga?

12. Mis on simulatsioonitulemuste analüüs? Milliseid järeldusi tavaliselt tehakse?