Mudelite testimine piiratud ressurssidega. Tehnoloogiline testimisprotsess. Sisendparameetrite klassifitseerimine

Traditsiooniline lähenemine automatiseeritud testidele näeb välja umbes selline – testikirjutaja uurib testitavat süsteemi ja kirjutab seejärel käsitsi iga üksiku skripti, et testitavat süsteemi testida. Keegi võib siia kirjutada uhke sõna “käsitöö”, aga mina nimetan seda “käsitööks”. Selle põhjuseks on asjaolu, et tavaliselt on sellel testide loomisel ja kirjutamisel kaks probleemi:

"Pestitsiidide paradoks", mida kirjeldas Boris Beizer 1990. aastal. See seisneb selles, et testid on vigade püüdmisel üha vähem tõhusad, kuna vead, mille tuvastamiseks need testid kirjutati, on juba leitud ja parandatud. Kui seda ei juhtu, siis tekivad tõsised küsimused kirjaliku koodi ja tööprotsesside osas.
Testid on staatilised ja neid on raske muuta, samas kui testitav süsteem kipub pidevalt arenema, omandama uusi funktsioone ja muutma vanade käitumist. Ja teste tuleb muuta iga kord, kui funktsionaalsus muutub välimus programm või selle käitumine. Ja kuna testide värskendamise keerukus kasvab, on üha raskem õigustada testide ülalpidamise tohutuid kulusid.

Mudelipõhine testimine ignoreerib neid probleeme peaaegu täielikult, kuna testid luuakse automaatselt täpne mudel rakendusi. See lihtsustab oluliselt nii olemasolevate toetamist kui ka uute, äärmiselt kasulike ja paindlike testide genereerimist.

Mis on modell?

Mudel on testitava süsteemi kirjeldus. Ametlik spetsifikatsioon sobib hästi. Mudel peaks olema kirjeldatavast süsteemist palju lihtsam ja aitama meil kuidagi mõista ja ennustada testitava toote käitumist.

Tavaliselt kasutatakse mudelina kas olekugraafikut või mingit lõpliku oleku masinat. Samas on testimisel testimisel juba kolmandat aastakümmet kasutatud olekugraafikut, mis esindab testimisel ja testimisel oleva tarkvara. Lisateavet selle testi kavandamise tehnika kohta saate lugeda . Või veel parem – terves hunnikus testimist käsitlevates raamatutes, mis on avaldatud viimase 25 aasta jooksul.

Lühidalt võib seda kirjeldada järgmiselt: testitav tarkvara hakkab mingis olekus tööle (“pealeleht on avatud”), võtab vastu mingi kasutajapoolse sisestuse (“vaata kassipoegade fotosid”) ja liigub olenevalt sellest sisendist uude olekusse ("ilmus album kassipoegade fotodega"). Kasutame kogu aeg mudeleid, et mõista selle tarkvara osa, millega me töötame (“Hmm... kui ma olen siin ja ma teen seda See siis olen väljas seal"). Jah, üldiselt võib kogu testimist käsitleda kui testeri liigutamist läbi süsteemi erinevate olekute ja nende liikumiste õige toimumise kontrollimist (see, mida "õigesti" tähendab, on eraldi teema, nii et jätame selle praegu vahele) .

Mis on mudelipõhine testimine?

Ametlikult kirjeldatud mudelite kasutamine tarkvara testimise odavamaks ja lihtsamaks muutmiseks on üsna vana idee. Mudelipõhine testimine ise on selline "täiustatud" musta kasti testimise tehnika. Sellel on traditsiooniliste meetoditega võrreldes mitmeid boonuseid:

Mudelit saab kokku panna juba enne esimeste koodiridade ilmumist
Modelleerimine hõlmab põhjalikku tööd arendatava tarkvara spetsifikatsiooni ja arhitektuuri kallal, mis reeglina võimaldab meil varajases staadiumis vabaneda põhimõttelistest probleemidest ja triviaalsetest ebakõladest.
Mudel sisaldab teavet, mida saab tulevaste testimisvajaduste jaoks uuesti kasutada, isegi kui spetsifikatsioonid muutuvad
Mudelit on palju lihtsam hooldada kui tohutut hunnikut erinevaid teste

Ja mis kõige tähtsam, formaalselt kirjeldatud mudelid koos graafiteooria algedega aitavad hõlpsalt ja vaevata luua sadu teste.

Kotkasilmne Agile fänn võib hüüda: "Hei! meil on BDD ja see katab esimesed kolm punkti ja see on ka spetsifikatsioon!" Vastan "ei midagi sellist - teie näidetest saab tavaline spetsifikatsioon alles siis, kui kuningas Shaka Zulut saab pidada kogu inimkonna spetsifikatsiooniks."

Jätame nüüd arutelu kõrvale ja vaatame, kuidas kasutada graafiteooriat, et mudelist testide jaoks vajalik välja võtta.

Lühike graafiteooria õppeprogramm

Graafiteooria sai alguse 1736. aastal Preisi vanas linnas Köningsbergis. Linn seisis jõe kahel kaldal ja hõivas samal ajal paar saart just selle jõe keskel. Selle linna elanikud püüdsid jõudeolekust välja mõelda, kuidas külastada kõiki seitset silda ilma üht kaks korda ületamata. Otsustasime praktikas jalutuskäikude ajal ja teoreetiliselt köögikogunemiste ajal. Pikka aega keegi ei suutnud tõestada ega ümber lükata selle marsruudi olemasolu enne, kui tuli Euler ja rikkus linnaelanike puhkuse.

Euler tuli välja ideega kujutada iga maatükki graafiku tipuna ja sildu graafiku servadena.

Ja siis järsku selgus, et vajalikku marsruuti pole olemas. Ja kõik sellepärast, et kõigil tippudel on paaritu arv servi. Lõppude lõpuks, kui tipus on paarisarv servi, siis iga kord, kui kõndiv kodanik sellele maatükile siseneb, saab ta sealt väljuda mööda uut silda. Seega selgub, et kõiki sildu ei saa kõndida, ilma et ületaksite üht silda kaks korda.

Sellest ajast alates nimetatakse graafi, mille kõigil tippudel on paarisarv servi, “Euleri graafikuks”. Ja selle graafiku täielik läbimine kannab uhket nime "Euleri tee".

Ja pärast seda tuli Koeningsbergi elanikel leida muud meelelahutust. Ainult üks Hiina matemaatik Mei-Ku Kuan lollitas end nende sildadega. Ja teda vaevas järgmine küsimus:

Kui ei ole võimalik ehitada trassi nii, et iga silda ületataks täpselt üks kord, siis kui suur on minimaalne lisasillaületuste arv, mis tuleb ümbersõidu lõpetamiseks teha.

Ja see on juba väga sarnane probleemiga, millega postiljonid kokku puutuvad. Oletame, et iga tipp on Postkast, kuhu peate tähed panema. Ja oletame, et meie postimees peab viskama igasse kasti kirju ilma tarbetuid liigutusi tegemata.

Kuan tegi ettepaneku kaaluda silla uuesti ületamist kui graafikule teise serva lisamist. Servade lisamisel peaks graafi kõikidel tippudel olema paarisarv servi. Seda protseduuri nimetatakse tavaliselt graafiku "eulerianiseerimiseks". Ja pärast seda, kui graafik on „Eulerianiseeritud”, saame seda mööda ehitada Euleri tee.

Kuani auks nimetati seda probleemi "Hiina postiljoni probleemiks".

Mõned aastad hiljemgi tekkisid igavad, kes hakkasid huvi tundma, mis saab siis, kui graafiku servi mööda saab kõndida ainult ühes suunas. Just see probleem tekibki, sarnaselt New Yorgi taksojuhi peavalule, rajades marsruuti mööda ühesuunalisi tänavaid.

Siin tutvustame teist terminit - digraafi. Või suunatud graafik. See on graafik, mille servi saab lõikuda ainult kindlas suunas. Suunatud servi nimetatakse ka "kaaredeks".

Ja kui Euleri tee või Hiina postimehe probleemi puhul opereerisime tippe puudutavate kaaredega, siis siin tuleb arvestada ka liikumissuunaga. Ja me nõuame sellise graafiku "eulerianisatsiooni" osakaalu, et tippu sisenevate kaare arv oleks võrdne väljuvate kaaredega. Ja lugedes iga sissetuleva kaare kui “+1” ja väljuva kaare kui “-1”, saame arvutada digraafi iga tipu “polaarsuse”. Näiteks kahe sissetuleva ja ühe väljuva kaarega tipul on polaarsus “2 - 1 = 1”.

Digraafi euleriseerimiseks peame joonistama kaared positiivsete ja negatiivsete tippude vahele. Me vajame seda sissetulevate ja väljuvate kaare arvu "joondamist" samal põhjusel, miks me saavutasime suunamata graafis paarisarv servi – iga graafi tipu külastaja peaks saama sealt lahkuda.

Mis on testimisel sellega pistmist?

Oletame, et testijal on testitava süsteemi käitumise mudel. Oletame ka, et see mudel näeb välja nagu digraaf, kus tipud tähistavad süsteemi olekut ja kaared on tegevused, mida testija saab teha süsteemi oleku muutmiseks.

Esimene asi, mida testija teha soovib, on testitava süsteemiga kõikvõimalikud toimingud. Aga kuidas me saame seda tõhusalt teha? Siis mõtleb nutikas tester New Yorgi taksojuhi kohta mõistatuse, mis on lihtsalt veidi maskeeritud. Ja kuna meil on testitava süsteemi mudel juba graafiku kujul olemas, tuleb sellele lihtsalt rakendada sobiv läbimise algoritm, mida saab automaatselt genereerida.

Teisest küljest kõigi hukkamine võimalikud toimingud see on hea, kuid isegi kõige nürim testijuht saab aru, et tegemist on toorkoodi testimise seisukohalt banaalse “riigi katmisega”. Kuid kordajatel on üks ebameeldiv omadus - neil on reeglina iga tipu jaoks palju "järgmisi" olekuid. Mida peaksime tegema, kui tahame katsetada kõiki võimalikke toimingute kombinatsioone? Lahendused sellistele probleemidele nagu Hiina Postimehe probleem ei sobi, sest tagavad vaid iga kaare külastamise, aga mitte kõigi võimalike kaarekombinatsioonide külastamise.

Seda lähenemisviisi kasutati aktiivselt piiratud olekuga masinate testimiseks. Veelgi enam, see nõue tuleneb loomulikult kombinatoorsest testi kavandamise tehnikast, mida nimetatakse "kõik paariks".

Lahenduse pakkus välja teatud de Bruijn. Algoritm näeb välja umbes selline:

Sellele küljele joonistame graafiku, kus algse graafi iga serv on tipp.
Kui algses graafis siseneb kaar "1" tippu, millest kaar "2" väljub, joonistame vastloodud graafikus kaare tipust "1" tipuni "2".
Euleeriseerime saadud graafiku.
Joonistame sellele graafikule Euleri tee.

Põhimõtteliselt ei saa te vaeva näha ja lihtsalt läbida graafiku juhuslikult. Tähelepanuväärne on see, et see strateegia on pestitsiidide paradoksi suhtes üsna vastupidav. Teisest küljest on kellelgi rohkem või vähem keeruline rakendusüsna laialivalguv olekute graafik, millel saate veeta palju aega, enne kui saate "juhusliku jalutuskäigu" abil vähemalt mingi katte.

Kirjutan hiljem, miks siia lisatakse Markov Chains ja kuidas selliste testide paralleelsus tavaliselt lahendatakse. Praegu teeme lühidalt kokkuvõtte.

Kokku

Mudelid on suurepärane viis testitava rakenduse esindus ja arusaamine, kuid need annavad meile ka üsna lihtsa võimaluse teste värskendada ja pidevalt areneva rakendusega sammu pidada.

Rakenduse testimist võime pidada rakenduse mudeli põhjal koostatud graafiku läbimiseks. Graafiteooria pakub omakorda piisavalt tööriistu, et kasutada mudelis kirjeldatud süsteemi käitumist puudutavat teavet uute hiilgavate testide genereerimiseks.

Ja kuna graafikuteooria võimaldab meil mudeliga otse töötada:

Mudeli muutumisel saab automaatselt luua uusi jalutuskäike
Meie testid võivad sama mudeli piires lihtsalt ja loomulikult muutuda
Erinevad läbimisalgoritmid võivad sobida erinevatele testimisvajadustele
Saadud möödaviigualgoritme saab hõlpsasti uuesti kasutada täiesti uues keskkonnas

Kursuse kava:

1.
Testmudel ja kuidas struktuuriga töötada
2.
Kuidas tšekke välja mõelda
1.
2.
Katsekujundustehnikad (must kast)
Valge kasti tehnikate ülevaade
3.
Töö järjekindlusega
4.
Tšekkide koostamine
5.
Prioriteetide seadmine
6.
Pärast testimise dokumenteerimise protsessi

Audit – mida kontrolliti

1.
Katvuse täielikkus (vastavalt vajadusele)
2.
Järjepidevus (duplikaadid, vastuolulised nõuded)
3.
Struktuur (osadeks jaotatud testikomplektid kuidas nad sind tšekkide eest peksavad)
4.
Kontrollide sisu (sõnastus, arusaadav kõigile projektis osalejatele)
5.
Disain (tehnilised vead, korralik välimus)
6.
Kattekiht (Smoke/MAT/AT)
7.
Protsessi järgimine (testi dokumentatsiooniga töötamise protsess)

Igat tüüpi dokumentide vead
Kirjaoskus
60
10,4
Hõlmab kõiki funktsioone
kontrollid
42
9,4
Funktsioonide jaotus
6,4
Välimus
6,2
Üksik stiil
2,1
Dokumendi meetodid
2,1
Tulemuse meetodid
2
55
38
14
20
17
% kõigist projektidest
% kõigist vigadest

Vead testuuringu jaoks, testjuhtumid
Kontrollide vahelejätmine
12,6
Oodatud
tulemus
Duplikaadid
Üksik stiil
Vaidlused
Prioriteet
70
47
6
38
3,5
25
2,4
25
1,6
1,4
19
% kõigist projektidest
% kõigist vigadest

Testmudel

- See loogiline struktuur, mis kirjeldab funktsioone
süsteemi ja/või kasutaja käitumist, mille järgi
genereeritakse testjuhtumid. Testmudeli ehitamine
algab konstruktsiooni ehitamisega ja seejärel kinnitatakse
struktuur on täidetud testjuhtumite/kontrollidega.
c) Dmitri Tištšenko. A1QA ajaveeb, 2014

Kontrolli katvus

1) Hetke kliendi soovid spetsifikatsioonides\nõuetes\plaanides
2) Lepingud projekti kohta
3) Kättesaadavus vajalikud kontrollid iga funktsiooni jaoks:
Testi kavandamise tehnikad:
◦
◦
◦
◦
Samaväärse partitsiooni testimine
Piirväärtuste testimine
Paaripõhine testimine
Oleku ülemineku testimine

Samaväärsuse jaotamine

VASTAVASTAVATE KLASSIDE TEHNOLOOGIA

*näite lihtsustamiseks võtame püsihinna

1) Jaga sisendparameetrid klassidesse

Parameeter
1. klass
2. klass
Toote versioon
Standard
Premium
<0
0 <= количество < 100
Kogus
3. klass
>= 100
* Põhjuse hääl – toote versiooni puhul peate testima KÕIKI kehtiva väärtusklassi väärtusi.
Näiteks välja Makse (väärtused: kaart, sularaha, ülekanne) puhul on loogiline testida KÕIKI valikuid eraldi

2) 1 klass == 1 kontroll

Toote versioon
Juhtum 1
Standard
Juhtum 2
Premium
Kogus

2) 1 klass == 1 kontroll

Toote versioon
Juhtum 1
Standard
Juhtum 2
Premium
Kogus
Juhtum 3
-1
Juhtum 4
16
Juhtum 5
125

3) Negatiivne kontroll juhul ainult 1. klassi kohta

Toote versioon
Kogus
Tulemus
Juhtum 1
Standard
50
Positiivne
Juhtum 2
Premium
50
Positiivne
Juhtum 3
Standard
-1
Negatiivne
Juhtum 4
Standard
16
Positiivne
Juhtum 5
Standard
125
Negatiivne

4) Kaaluge positiivsed kontrollid uuesti

Toote versioon
Kogus
Tulemus
Juhtum 1
Standard
50
Positiivne
Juhtum 2
Premium
50
Positiivne
Juhtum 3
Standard
-1
Negatiivne
Juhtum 4
Standard
16
Positiivne
Juhtum 5
Standard
125
Negatiivne

5) Kokku

Toote versioon
Kogus
Tulemus
Juhtum 1
Premium
50
Positiivne
Juhtum 2
Standard
-1
Negatiivne
Juhtum 3
Standard
16
Positiivne
Juhtum 4
Premium
125
Negatiivne

Veel klasse...

Parameeter
1. klass
2. klass
Toote versioon
Standard
Premium
<0
0 <= Кол-во < 100
Murdosaline
Terve
Numbrid
Mitte numbrid
Kogus
3. klass
> 100
Tühi

Toote versioon
Kogus
Tulemus
Juhtum 1
Standard
50
Positiivne
Juhtum 2
Premium
10
Positiivne
Juhtum 3
Premium
-1
Negatiivne
Juhtum 4
Standard
16
Positiivne
Juhtum 5
Premium
150
Negatiivne
Juhtum 6
Premium
19,45
Negatiivne
Juhtum 7
Premium
%Arv!
Negatiivne
Juhtum 8
Standard
-
Negatiivne

Toote versioon
Kogus
Tulemus
Juhtum 1
Standard
50
Positiivne
Juhtum 2
Premium
10
Positiivne
Juhtum 3
Premium
-1
Negatiivne
Juhtum 4
Standard
16
Positiivne
Juhtum 5
Premium
150
Negatiivne
Juhtum 6
Premium
19.45
Negatiivne
Juhtum 7
Premium
%Arv!
Negatiivne
Juhtum 8
Standard
-
Negatiivne

~30% positiivseid juhtumeid

Toote versioon
Kogus
Tulemus
Juhtum 1
Standard
50
Positiivne
Juhtum 2
Premium
10
Positiivne
Juhtum 3
Premium
-1
Negatiivne
Juhtum 4
Premium
150
Negatiivne
Juhtum 5
Premium
19.45
Negatiivne
Juhtum 6
Premium
%Arv!
Negatiivne
Juhtum 7
Standard
-
Negatiivne

Funktsioon
Sisendparameeter
Saaja
Saada
Teema
Keha
Failid
Kinnitage
Failid
Teksti vormindamine
Kustuta
Tühine
1. klass
2. klass
Olemasolev aadress Olematu aadress
Suurus 0
0 < Размер <= Limit
Sisaldab @ sümboleid
._-+
Muud sümbolid peale @ . _ - +
Vorming
Mitte vormindada
Suurus 0
0 < Размер <= Limit
Sisaldab tegelasi
välja arvatud „∞₽₾₾©¥£µ®” sümbolid ∞₽₾₾©¥£µ®
Suurus 0
0 < Размер <= Limit
Vormindamine
Vormindamine puudub
Ei
Üks
Suurus 0
0 < Размер <= Limit
Toetatud
Toetamata
Teksti pole valitud
vali
Tekst
vormindamine
Klõpsake
3. klass
Suurus > Piirang
Suurus > Piirang
Suurus > Piirang
Palju
Suurus > Piirang
Vormindatud
tekst

№
1
2
Saaja
Olemas
0 < Размер <= Limit
Teema
0 < Размер <= Limit
Sisaldab tegelasi
välja arvatud “∞₽₾₾©¥£µ®”
3 Sisaldab @ sümboleid. _ 0< Размер <= Limit
-+
4 Vorming
0 < Размер <= Limit
5 Olematu aadress 0< Размер <= Limit
6 Suurus 0
Sisaldab tegelasi
välja arvatud “∞₽₾₾©¥£µ®”
7 Suurus > Piirang
Sisaldab tegelasi
välja arvatud “∞₽₾₾©¥£µ®”
8 Pole vormindatud
0 < Размер <= Limit
9 0 < Размер <= Limit
Suurus 0
10 0 < Размер <= Limit
Suurus > Piirang
11 0 < Размер <= Limit
Sisaldab tegelasi
“∞₽₾₾©¥£µ®”
12 On olemas
0 < Размер <= Limit
0 < Размер <= Limit
Vormindamine
Ei
Üks
Oodatud
tulemus
Saadetud
Saadetud
0 < Размер <= Limit
Kolm
Saadetud
0 < Размер <= Limit
0 < Размер <= Limit
Vormindamine
Kolm
Ei
Üks
Saadetud
Ei tarnitud
Ei saadetud
Vormindamine
Üks
Ei saadetud
0 < Размер <= Limit
Vormindamine
0 < Размер <= Limit
0 < Размер <= Limit
Ei
Üks
Kolm
Kolm
Ei saadetud
Ei saadetud
Ei saadetud
Ei saadetud
Suurus > Piirang
Ei
Ei saadetud
Keha
Failid

#
Sisend
Tulemus
Tühine
Tühista kustutamine
Tekst pole valitud\ära vali
vormindamine
Kiri kustutatud
Kirja pole kustutatud
Tekst
Vormindamine on rakendatud
4
Rikkalik tekst
Rakendati uus vorming
5
Saadaval suurus ja formaat
väärtused
Fail lisatud
Ärge määrake faili
Faili pole lisatud
Määrake sobimatu suurusega fail
(min< или >max)
Faili pole lisatud
Määrake toetamata fail
Faili pole lisatud
1
Funktsioon
Eemaldus
2
3
6
7
8
Vormindamine
Manus
faili
Süsteem ei rakenda vormindamist

Piirväärtused

PIIRVÄÄRTUSE TEHNIKA

Ülesanne: Evakuatsiooniplaani testjuhtumite loomine

0
Põhitest
Närvide rahustamiseks
Negatiivne test
99

99
0
0
99

Kõigi paaride leidmine (vt graafikut)
Matemaatikas on see Descartes'i korrutis:
Evacuation_Plan x Risk_Assesment = ((a,b) | a ∈ Evacuation_Plan, b ∈ Risk_Assesment)
Evakuatsiooni_plaan x riski_hinnang =
{ (-1,-1),
(-1,0), (-1,1),
(-1,50),
(-1,98), (-1,99), (-1,100),
(0,-1),
(0,0),
(0,1),
(0,50),
(0,98),
(0,99),
(0,100),
(1,-1),
(1,0),
(1,1),
(1,50),
(1,98),
(1,99),
(1,100),
(50,-1), (50,0), (50,1), (50,50),
(50,98), (50,99), (50,100),
(98,-1), (98,0), (98,1), (98,50),
(98,98), (98,99), (98,100),
(99,-1), (99,0), (99,1),
(99,50), (99,98), (99,99),
(99,100),
(100,-1), (100,0), (100,1), (100,50), (100,98), (100,99), (100,100),
}
7x7 = 49 tšekki

Evacuation_Plan = (-1, 0, 1, 50, 98, 99, 100)
Risk_Assessment = (-1, 0, 1, 50, 98, 99, 100)
EP_Type = (Standardne, Premium)
RA_Type = (Standardne, Premium)
Juhtumite arv = 7 * 7 * 2 * 2 = 196

Paaripõhine testimine

KÕIGI PAARIDE TESTIMISE TEHNIKA

Ülesanne

Andmesalvestus (5): PostgreSQL, Oracle, MySQL, JSON, XML
Operatsioonisüsteem (4): Windows 7, 8, 10, OS X 10
RAM (3): 1024 MB, 4096 MB, 8192 MB
Kõvaketas (2): SCSI, IDE
Täielik otsing = 5 * 4 * 3 * 2 = 120 valikut

Ideed

1. Testige väärtuspaare, mitte ammendavaid otsinguid
2. Tõhususe empiiriline tõestus
3. Kõik paarid/ortogonaalsed massiivse tehnika valikud

Ortogonaaliga töötamine
massiivid

1
2
3
4
5
Andmed
PostgreSQL
Oraakel
MySQL
JSON
XML
OS
Windows 7
Windows 8
Windows 10
OS X 10
RAM
1024 MB
4096 MB
8 192 MB
HDD
SCSI
IDE

Ortogonaaliga töötamine
massiivid
1. Saate aru, millised ja kui palju sisendparameetreid:
Andmekogu
OS
RAM
HDD
5. veerg
6. veerg
1
1
1
1
1
1
1
2
2
2
2
2
1
3
3
3
3
3
1
4
4
4
4
4
1
5
5
5
5
5
2
1
2
3
4
5
2
2
3
4
5
1
1
2
3
4
5
2
3
4
5
1
2
Andmed
PostgreSQL
Oraakel
MySQL
JSON
XML
2
4
5
1
2
3
OS
Windows 7
Windows 8
Windows 10
OS X 10
2
5
1
2
3
4
3
1
3
5
2
4
RAM
1024 MB
4096 MB
8 192 MB
3
2
4
1
3
5
HDD
SCSI
IDE
3
3
5
2
4
1
3
4
1
3
5
2
3
5
2
4
1
3
4
1
4
2
5
3
4
2
5
3
1
4
4
3
1
4
2
5
4
4
2
5
3
1
4
5
3
1
4
2
5
1
5
4
3
2
5
2
1
5
4
3
5
3
2
1
5
4
5
4
3
2
1
5
5
5
4
3
2
1
2. Valige sobiv ortogonaalne massiiv – L25(56 ^6)

Ortogonaaliga töötamine
massiivid
1. Saate aru, millised ja kui palju sisendparameetreid:
1
2
3
4
5
Andmed
PostgreSQL
Oraakel
MySQL
JSON
XML
OS
Windows 7
Windows 8
Windows 10
OS X 10
RAM
1024 MB
4096 MB
8 192 MB
HDD
SCSI
IDE
2. Valige sobiv ortogonaalne massiiv -
3. Ortogonaalse massiivi koostamine
4. Eemaldage mittevajalikud VEERUD
L25(56^6)
Andmekogu
OS
RAM
HDD
1
1
1
1
1
2
2
2
1
3
3
3
1
4
4
4
1
5
5
5
2
1
2
3
2
2
3
4
2
3
4
5
2
4
5
1
2
5
1
2
3
1
3
5
3
2
4
1
3
3
5
2
3
4
1
3
3
5
2
4
4
1
4
2
4
2
5
3
4
3
1
4
4
4
2
5
4
5
3
1
5
1
5
4
5
2
1
5
5
3
2
1
5
4
3
2
5
5
4
3

Ortogonaaliga töötamine
massiivid
1. Saate aru, millised ja kui palju sisendparameetreid:
Andmekogu
OS
RAM
HDD
1
PostgreSQL
Windows 7
1024 MB
SCSI
2
PostgreSQL
Windows 8
4096 MB
IDE
3
PostgreSQL
Windows 10
8 192 MB
SCSI
4
PostgreSQL
OS X 10
1024 MB
SCSI
5
PostgreSQL
Windows 10
1024 MB
SCSI
6
Oraakel
Windows 7
4096 MB
SCSI
7
Oraakel
Windows 8
8 192 MB
SCSI
1
2
3
4
5
8
Oraakel
Windows 10
1024 MB
SCSI
Andmed
PostgreSQL
Oraakel
MySQL
JSON
XML
9
Oraakel
OS X 10
1024 MB
SCSI
OS
Windows 7
Windows 8
Windows 10
OS X 10
10
Oraakel
Windows 10
1024 MB
IDE
11
MySQL
Windows 7
8 192 MB
SCSI
RAM
1024 MB
4096 MB
8 192 MB
12
MySQL
Windows 8
1024 MB
SCSI
HDD
SCSI
IDE
13
MySQL
Windows 10
4096 MB
IDE
14
MySQL
OS X 10
1024 MB
SCSI
15
MySQL
OS X 10
4096 MB
SCSI
16
JSON
Windows 7
4096 MB
IDE
17
JSON
Windows 8
4096 MB
SCSI
18
JSON
Windows 10
1024 MB
SCSI
19
JSON
OS X 10
4096 MB
SCSI
20
JSON
OS X 10
8 192 MB
SCSI
21
XML
Windows 7
4096 MB
SCSI
22
XML
Windows 8
1024 MB
SCSI
23
XML
Windows 10
4096 MB
SCSI
24
XML
OS X 10
8 192 MB
IDE
25
XML
Windows 10
4096 MB
SCSI
2. Valige sobiv ortogonaalne massiiv – L25(56 ^6)
3. Ortogonaalse massiivi koostamine
4. Eemaldage mittevajalikud VEERUD
5. Sisestage sisendparameetrite väärtused
6. Täitke lüngad + kontrollige asjakohasust

PICT
Andmekogu
OS
RAM
HDD
1
JSON
OSX_10
4096 MB
SCSI
2
Oraakel
Windows 7
1024 MB
IDE
3
MySQL
Windows10
8192 MB
IDE
4
Oraakel
Windows 8
8192 MB
SCSI
5
JSON
Windows 8
1024 MB
IDE
6
JSON
Windows 7
8192 MB
SCSI
7
Oraakel
Windows10
1024 MB
SCSI
8
XML
Windows 7
4096 MB
IDE
9
MySQL
OSX_10
1024 MB
SCSI
10
JSON
Windows10
4096 MB
SCSI
11
XML
Windows10
8192 MB
SCSI
12
PostgreSQL
Windows 8
4096 MB
SCSI
13
MySQL
Windows 7
4096 MB
SCSI
14
XML
Windows 8
1024 MB
IDE
15
PostgreSQL
Windows 7
1024 MB
IDE
16
XML
OSX_10
8192 MB
IDE
17
PostgreSQL
Windows10
8192 MB
SCSI
18
MySQL
Windows 8
4096 MB
IDE
19
PostgreSQL
OSX_10
8192 MB
IDE
20
Oraakel
OSX_10
4096 MB
SCSI

105162*452 = 134 400

1
2
3
4
5
…
105
Teema
araabia keel
Kunstiajalugu
Bioloogia
Äri
Uuringud
Keemia
…
EAL
Kooliaste (16)
Elementaarne
Keskmine
Kõrge
Üle kooli
Kõrge/keskmine
…
Tõenäosus
Kindel
Esialgne
Tööhõive
Tüüp
Täis
osa
Asendaja
Ajutine
Lepingu pikkus
1
2
3
4
Kaaskiri

Teie eesmärk süsteemiadministraatorina
on rakendada tõhusaid strateegiaid
arvutiressursside maksimeerimine.

D. Gunter, S. Barnett, L. Gunter.
Windows NT ja Unixi integreerimine

IT-spetsialistid ei pea end kurssi viima mitte ainult arvukate arvutiajakirjanduses avaldatud testidega, vaid ka ise välja töötama testiprotseduurid, mis on vajalikud nii tarnija valikul kui ka oma lahenduse loomisel. Seetõttu püüame vastata küsimustele, mis tekivad keerulises testimisprotsessis, eriti kui see puudutab selliseid keerulisi süsteeme nagu serverid.

Mida testitakse ja miks?

Sageli on arvutiajakirjanduses mitmesugused ülevaated programmide, riistvara ja lahenduste kohta. Erilist huvi pakuvad reeglina funktsionaalselt homogeensete toodete võrdlevad ülevaated, mis esitavad testitulemusi. Arvatakse, et need üksikasjalikud tabelid aitavad kasutajal, administraatoril ja IT-spetsialistil vähemalt selles vallas toimuvaga kursis olla ja isegi tootevaliku üle otsustada.

Niisiis, milliseid tegureid sellistel juhtudel arvesse võetakse, mis on uurimisobjekt ja mis tüüpi testid on kõige populaarsemad?

Testimiskriteeriumid on tavaliselt järgmised:

toote funktsionaalsus;
õppimise lihtsus;
paigaldamise lihtsus;
dokumentatsiooni ja toe kvaliteet;
esitus;
Seadmete puhul võetakse mõnikord arvesse ka disaini.

Samuti on väga mitmetähenduslikud kriteeriumid. Mitte kaua aega tagasi peeti ühes veebiserverite ülevaates üldise hinnangu andmisel positiivset tegurit "kõrge integreerituse tase operatsioonisüsteemiga". Aga kui rakenduse rike põhjustab operatsioonisüsteemi tõrke (mille tõenäosus on võrdeline integratsiooniastmega) - kas see on tõesti eelis?

Kas sada jänest võrdub ühe tiigriga?

Eraldi peatuksin riistvara hindamisel omasel hinna/jõudluse suhtel. Esmapilgul on see tõesti ainus objektiivne kriteerium, mis seob uuritava süsteemi tehnilised omadused tarbija rahakotiga. Siiski pole kõik nii lihtne, kui tundub. Fakt on see, et ülalmainitud lähenemine toimib ainult ostmise hetkel ega võta arvesse omamiskulusid, seadmetesse või tarkvarasse tehtavate investeeringute ohutust ega edasise moderniseerimise võimalust.

Tüüpiline näide on Inteli protsessoritel olevate vanemate süsteemide mudelite võrdlus RISC-platvormide sarja nooremate mudelitega. Jah, tõepoolest, antud hinnaklassis on Inteli arhitektuuriga masinad RISC-süsteemidega võrreldavad või mõnel juhul isegi paremad. See aga, mis mõne platvormi jaoks on lagi, on teiste jaoks vaid lähtetase jne.

Järeldused: olge kriitiline toote hindamise kriteeriumide suhtes – teil ja testijatel võib olla erinev maitse. Proovige Unixi fännidele öelda, et süsteemi konfigureerimise graafilise liidese mugavuse huvides tasub pärast IP-parameetrite muutmist leppida vajadusega taaskäivitada. Mis puudutab süsteemiüksuse kompaktset disaini, siis see on hea seni, kuni peate õhukesesse korpusesse lisama täiendava kõvaketta.

Lühidalt, mõelge testitulemused ümber vastavalt oma vajadustele.

Serverite testimise eripära

Kui arvuti ei lülitu sisse, on see vigane.
Kui see välja ei lülitu, on see server.
Rahvamärk

Meie arvates on serverite üks põhinõudeid töökindlus. Kindlasti on oluline ka jõudlus, mis mõjutab süsteemi reageerimisaega – kasutaja seisukohalt kõige olulisemat omadust, kuid teenuse kättesaadavuse määrab töökindlus. Usaldusväärsusest sõltub ka selle esitamise õigeaegsus, teabe asjakohasus ja terviklikkus.

Lisaks tuleb arvestada, et spetsialiseeritud, st ainult ühte teenust pakkuvad serverid on siiski pigem erand kui reegel. Tavaliselt ühendab üks selline arvuti mitmeid funktsioone – näiteks võib rakendusserver toimida ka failiserveri, prindiserveri, varundusteenuse kontrollerina jne. Sideserverid töötavad tavaliselt mitme rakendusetaseme protokolliga, millest igaüks teenindab oma "deemoni" poolt".

Ja lõpuks, serveri töö iseloomulik tunnus on tippkoormuse olemasolu. Nende ilmumise põhjused võivad olla väga erinevad - alates tööpäeva algusest suures organisatsioonis (eriti kui kõik kasutajad jõuavad õigel ajal tööle) kuni Interneti-teenuse pakkuja "mahajäetud" ühenduse taastamiseni, kui mahajäämus tekib. e-posti ja uudistegruppide kohta jõuab suhtlusserveritesse.

Need tegurid, st suurema töökindluse nõue mitme teenuse osutamise ja tippkoormuse tingimustes, peaksid olema serveritestimise ideoloogia määramisel võtmetähtsusega.

Kahjuks on enamik arvutiajakirjanduses avaldatud arvustusi pühendatud kas erinevate riistvaralahenduste jõudluse võrdlemisele järjestikuste testülesannete kogumi puhul või teatud teenuse võrdlevale testimisele (näiteks erinevate tootjate veebiserverite testimisele). Selle lähenemise üks hullemaid variante on see, kui sarnaste lahenduste võimaluste võrdlevat ülevaadet nimetatakse testimiseks vaid seetõttu, et väljaande autor teostas paigalduse ja tootega veidi “sõitis”.

Katsetingimused

Esiteks väike teooria. Glenford Myers esitab oma artiklis "Tarkvara usaldusväärsus" mitu "testimise aksioomi". Proovime neid järgides mõelda, mida ja kuidas testida.

Aeg-ajalt ilmub arvutiajakirjanduses peaaegu sportlikku laadi teateid: firma N toode näitas M testis rekordeid.Kui informatiivsed on tootmisettevõtete läbiviidud testid?

Teie programmi ei saa testida

Tihti kirjutavad testid ettevõtte töötajad konkreetse toote jaoks. Protsessori jõudlustestid, mis on kirjutatud nii, et mõistavad konkreetse protsessori eeliseid, on muutunud kõneaineks. Näiteks valitakse testimisprogrammi suurus, võttes arvesse selle paigutust vahemällu jne. Selliste tulemuste graafiline esitus on sageli üsna kallutatud.

Rakenduste arhitektuuri ja nende OS-i ressursside kasutamise tundmine võimaldab tarkvaraarendajatel konfigureerida süsteemi nii, et see saavutaks oma programmi jaoks maksimaalsed tulemused. Pole vahet, kas muu tarkvara või teenused tunnevad end selliste operatsioonisüsteemi installide puhul mugavalt ja kas testitav rakendus võtab ressursse kinni.

Autor puutus selle nähtusega kokku, kui üritas konfigureerida Netscape Enterprise'i veebiserverit Solarise (SPARC) all. http-protokolli kasutava serveri jõudlust suurendati ligi 6 (!) korda (MS InetLoadiga testimise järgi), kuid komplekstestis osutus kasv kolmekordseks, POP3 serveri jõudlus aga kahekordistus, vahendab Uudised. server jäi muutumatuks ja SMTP näitas kaks korda halvemaid tulemusi kui enne muudatusi.

Lisaks saavad tootjad, teades konkreetse testikomplekti omadusi, optimeerida süsteemi parameetreid spetsiaalselt selle jaoks. Selle näiteks on Netscape'i veebileht, mis pakub soovitusi Netscape Enterprise Serveri konfigureerimiseks testimiseks SPECweb96 abil.

Vigade tuvastamiseks viiakse läbi testimine

Serverite ja serveritarkvara puhul tähendab see, et seade tuleks sundida töötama kõige ebasoodsamas režiimis - viige läbi "ellujäämise" test. Seda saab saavutada serveri testimisega järgmises töökonfiguratsioonis:

kõik teenused peavad töötama;
kõiki teenuseid tuleb testida üheaegselt (täielik test);
igale teenusele saadetakse päringute voog, mis simuleerib kasutaja tüüpilist tegevust;
see aktiivsus peaks testi ajal perioodiliselt suurenema, kuni vähemalt üks teenus ei suuda enam päringute töötlemisega hakkama saada.

Siin on asjakohased kaks märkust:

1. Kasutaja käitumismudel.

Kasutajatega seoses peab administraator olema pessimist. Ellujäämistestid tuleks koostada vastavalt.

Pakkuge ette maksimaalne arv toiminguid, mida tavalises olekus lihtsalt ei tuleks pähegi. Hinnake (või kontrollige), kas süsteem selles olukorras normaalselt töötab. Ja sama oluline, kas kasutaja saab temalt selge sõnumi, et seda ei tasu enam teha ja miks.

2. Teenus on lõpetanud päringute töötlemise: võimalikud valikud.

Vastavalt raskusastmele võib sellised rikked jagada 4 rühma:

vähenenud jõudlus - teenusel pole aega töödelda, kuid see vastab õigesti (tagastab vastava veakoodi - "Liiga palju ühendusi" jne);
teenuse ebanormaalne lõpetamine, mis ei too kaasa süsteemile negatiivseid tagajärgi: vastav programm on oma töö lõpetanud, mälust laaditud ja süsteemi ressursid on vabastatud;
teenuse ebanormaalne lõpetamine, mis mõjutab negatiivselt süsteemi jõudlust. Programm kas "ripub" protsesside loendis ilma ressursse vabastamata või arestib lõpetamise ajal täiendavaid ressursse;
süsteemi krahh - parimal juhul järgneb taaskäivitamine, halvimal juhul - külmutamisega.

Valmistage ette testid nii õigete kui ka valede sisendite jaoks

See aksioom kirjeldab eelmist sisendinfovoogude osas.

Kuidas süsteem reageerib mitmekümne megabaidi suuruse kirja saatmisele? Kas see takerdub järjekorda, blokeerides sellega teie meilisüsteemi määramata ajaks (eriti kui side adressaadi hostiga on regulaarselt katkenud), või see hävitatakse ja kasutajat teavitatakse, et sellised toimingud on vastuvõetamatud?

G. Myersi samast raamatust võetud nõuanne: "Püüdke mitte lasta süsteemil kasutajat vihaseks ajada, sest see võib sisendis põhjustada ootamatuid olukordi – Reegel nr 5 kasutajavigade minimeerimiseks dialoogisüsteemides. Pessimistina olemine ei tähenda misantroobiks olemist!"

Kuidas on lood uudisteserveriga – kas artikli suurus on maksimaalne?

Kas keegi, kes kavatseb laadida poole teie FTP saidist, võiks avada kolm tosinat paralleelset FTP-seanssi ja kui jah, siis kuidas see teie kanalit ja teiste FTP-d külastada soovivate inimeste tööd mõjutaks?

Selle lähenemisviisi õigsust kinnitava näitena võib tuua intsidendi raketiristlejaga Yorktown, kus operaatori sisestusviga põhjustas mootori juhtimissüsteemi rike. Või teine, mida tsiteerib Myers ise: "New Yorgi politsei dispetšersüsteemi SPRINT operaatorid lõbustasid end vabal ajal, üritades seda keelata, sisestades tahtlikult valesid sõnumeid." See juhtus 70ndate alguses. Võib-olla on moraal sellest ajast peale pehmenenud, kuid see on ebatõenäoline.

Vältige kordumatuid teste

Serverite ja serveritarkvara testimise puhul on see aksioom eriti asjakohane. Esiteks on nende testimiseks vaja riistvaraliselt eraldatud koormusgeneraatorite olemasolu (Client-Side Load Generator, CSLG) – tavaliselt on need tööjaamade rühmad, mis täidavad testi kliendiosa ja edastavad serverile päringute voo. Teiseks võib tulemusi mõjutada serverit ja CSLG-d ühendava võrgu olek. Lisaks sõltub jõudlus paljudel juhtudel serveri kõnede ajaloost. Enamik serverirakendusi kasutab vahemällu. Vahemällu juurdepääsu kiirus on palju suurem kui ketta alamsüsteemile juurdepääsu kiirus. Rakenduse vahemälu võib täituda testprogrammide esialgsete või silumiste tõttu – ja tulemused võivad vastavalt muutuda. Veelgi enam, keeruka testimise korral on võimalik rakenduste ristmõju - näiteks sõltub POP3- või IMAP-serveritele ajaühikus töödeldavate keeruliste päringute arv e-posti spooli suurusest, mida saab suurendada eelmise SMTP-testiga. . Lõpuks mõjutavad jõudlust operatsioonisüsteemi sätted.

Kõigil korralikel arvustustel on jaotis „Kuidas testid läbi viidi”. Mõnes väljaandes on see üksikasjalikum, teises vähem - tundub, et testimise kirjeldamiseks ja salvestamiseks pole endiselt standardit. Selle suurepärane näide on SPECweb96 test. See dokument võtab arvesse serverirakenduse testimise eripära. Erinevalt traditsioonilistest kirjeldustest on olemas nõuded operatsioonisüsteemi ja testitava rakenduse lisaseadete logimiseks – seda mainitakse tavaliselt ka parimates testikirjelduste näidetes vaid möödaminnes.

Võib-olla jõuate ise arusaamisele, et peate oma testi läbi viima. See vajadus võib tekkida järgmistel juhtudel:

plaanite oma võrku laiendada, mis suurendab sellel asuvate serverite koormust;
kavatsete tarkvara uuendada (või muuta);
otsustate vahetada oma serveri (või serverid) produktiivsemate vastu;
Lõpuks, võib-olla olete just otsustanud välja mõelda oma süsteemi "kasvu piirid".

Tõenäoliselt on teie esimene samm avaldatud arvustuste vaatamine. Seega, kellegi teise saadud andmete kasutamiseks suhtuge neisse kriitiliselt ja püüdke muuhulgas mõista selle testimise läbi viinud inimeste motivatsiooni. Ja siis sõltub kõik teist - eesmärgi mõistmisest, piisava testide komplekti valimisest või kirjutamisest ning testimise enda korrektsest läbiviimisest. Loodan, et selles artiklis esitatud kaalutlused aitavad teid selles.

18.09.2003 Aleksander Petrenko, Jelena Britvina, Sergei Grošev, Aleksandr Monakhov, Olga Petrenko

Paljud inimesed teavad, kuidas programmi välja töötada; vähemalt kõik on seda korduvalt teinud, aga kvaliteetse programmi loomise selgitamine on palju keerulisem.

Tarkvaratööstus püüab pidevalt kvaliteediprobleemi lahendada, kuid kui olulised on selle edusammud, on praegu üsna raske öelda. Artiklis räägitakse uue põlvkonna testimisvahenditest, mis on loodud programmide kvaliteedi parandamiseks. Kuid tööriistad, isegi automaatsed, ei saa aidata, kui neid valesti kasutatakse. Seetõttu eelneb tööriistade arutelule „õige” testimise üldsätete avaldus.

Lähenemisviisid programmide kvaliteedi parandamiseks

Programmide "kvaliteedivõitlust" saab pidada kahel viisil. Esimene võimalus on “lihtne”: koondage meeskond headest programmeerijatest, kellel on sarnaste projektide kogemus, andke neile täpselt määratletud ülesanne, head tööriistad ja looge head töötingimused. Suure tõenäosusega on võimalik välja töötada hea kvaliteediga tarkvarasüsteem.

Teine viis pole nii lihtne, kuid see võimaldab hankida kvaliteetseid tarkvaratooteid ka siis, kui loetletud tingimusi ei ole võimalik täita - pole piisavalt häid programmeerijaid, ülesande täitmisel selgust jne. See tee eeldab arendusprotsesside standardiseerimist: ühtsete nõuete kehtestamist tööetappidele, dokumentatsioonile, regulaarsete koosolekute korraldamist, koodikontrollide läbiviimist jne. Üks esimesi edusamme sellel rindel oli tarkvarasüsteemi elutsükli kontseptsiooni juurutamine, mis määratles selgelt vajaduse kaaluda paljusid ülesandeid, mille lahendamiseta ei saa loota tarkvaraprojekti edule.

Lihtsaimas versioonis on elutsükli etappide komplekt järgmine:

nõuete analüüs;
projekteerimine (esialgne ja detailne);
kodeerimine ja silumine ("programmeerimine");
testimine;
käitamine ja hooldus.

Standardiseeritud olelusringi diagramm koos vajalike tööde selge reguleerimisega ja vastavate dokumentide loetelu moodustasid nn kose- ehk kaskaadmudeli aluse. Juga mudel eeldab tarkvaraarenduse protsessi jäika jaotamist etappideks ja üleminek ühest etapist teise toimub alles pärast eelmise etapi töö täielikku lõpetamist. Iga etapp lõpeb täieliku dokumentatsiooni väljastamisega, mis on piisav selleks, et arendust saaks jätkata teine meeskond. Kose mudel on DoD arendusprotsessi standardites muutunud domineerivaks. Paljud, taht-tahtmata, isegi sellest mudelist kõrvale kaldudes, nõustusid üldiselt selle mõistlikkuse ja kasulikkusega.

Kose mudel nõudis kõigi nõuete täpset ja täielikku sõnastamist; nõuete muutmine oli võimalik alles pärast kõigi tööde lõpetamist. Kose mudel ei vastanud küsimusele, mida teha nõuete muutumisel või muutub nende nõuete mõistmine otseselt arenduse käigus.

80. aastate lõpus pakuti välja nn spiraalmudel ning töötati välja ja testiti praktikas iteratiivse ja inkrementaalse arengu meetodit (IID). Spiraalmudel võttis arvesse kosemudeli probleeme. Spiraalmudeli põhirõhk on protsessi iteratiivsusel. Kirjeldatakse vaid poolepäevase iteratsiooni pikkusega IID kasutamise kogemusi. Iga iteratsioon lõpeb tarkvara uue versiooniga. Iga versiooni juures täpsustatakse (ja võimalusel ka muudetakse) sihtsüsteemile esitatavaid nõudeid ning võetakse meetmeid uute nõuete rahuldamiseks. Üldiselt järgib seda mudelit ka Rational Unified Process (RUP).

Kas see lahendas kvaliteediprobleemi? Ainult mingil määral.

Üha enam tõmbab tähelepanu probleem tarkvara kvaliteedi parandamine üldiselt ja testimise kvaliteedi parandamine; Ülikoolid juurutavad testimise ja kvaliteedi tagamise erialasid, koolitavad spetsiaalseid testimisspetsialiste ja kvaliteeditagamise insenere. Siiski maksavad vead ainuüksi USA-s endiselt 20–60 miljardit dollarit aastas. Samal ajal langeb ligikaudu 60% kahjudest lõpptarbijate õlule. Tekib olukord, kus tarbijad on sunnitud ostma ilmselgelt defektiga kaupa.

Olukord pole siiski lootusetu. USA riikliku standardi- ja tehnoloogiainstituudi läbiviidud uuring näitas, et tarkvaratõrgetega seotud kadusid saab vähendada umbes kolmandiku võrra, kui investeerida rohkem jõupingutusi testimise infrastruktuuri, eriti testimisvahendite arendamisse.

Mis on põhirünnaku suund? Mida näitavad "parimad tavad"?

80ndatel ja 90ndatel kõlas vastus sellele küsimusele umbes nii. Kõige kallimad vead tehakse elutsükli esimestes faasides - need on vead nõuete määratlemisel, arhitektuuri valikul ja kõrgetasemelisel disainil. Seetõttu peate keskenduma vigade leidmisele kõigis etappides, sealhulgas kõige varem, ootamata, kuni need avastatakse valmisrakenduse testimise käigus. Üldjoontes kõlas lõputöö nii: “Kas vähendada hetkede vahelist aega? vead ja selle avastamise hetk. Lõputöö on tervikuna hea, kuid mitte eriti konstruktiivne, kuna ei anna otseseid soovitusi selle aja vähendamiseks.

Viimastel aastatel on seoses meetodite esilekerkimisega, mida tavaliselt tähistatakse epiteediga agiilne (“krapsakas”, “krapsakas”), on välja pakutud ja rakendatud uusi konstruktiivseid meetodeid vigade varaseks tuvastamiseks. Näiteks kaasaegsed mudelid, nagu Microsoft Solutions Framework (MSF) ja eXtreme Programming (XP), tõstavad testi arendamiseks esile järgmised soovitused.

kõik vajalikud testid peavad olema programmi selle või selle osa rakendamise ajaks valmis; sellisel juhul vastab tavaliselt üks test ühele nõudele;
eelnevalt loodud testide komplekt tuleb (muutmata nõuete kohaselt) täita programmi mis tahes versioonis;
kui nõuetes tehakse muudatusi, tuleks katseid võimalikult kiiresti muuta.

Teisisõnu, viga – olgu see siis nõuetes, kujunduses või teostuses – ei kesta kauem kui hetkest, mil selle nõude elluviimise kontrollimiseks testitakse. See tähendab, et kuigi astronoomiline aeg vea “sissetoomise” ja selle avastamise vahel võib osutuda suureks, ei läinud palju pingutust raisku ning juurutamine ei jõudnud kaugele.

Me ei peatu nende sätete õiglusel ja nende tõhususel. Nagu sageli juhtub, osutus uuenduse kõrvalmõju olulisemaks kui selle idee tegelik elluviimine. Sel juhul on arutelud nutikate meetodite üle viinud uue arusaamani testimise kohast tarkvara arendusprotsessis. Selgus, et testimine selle sõna laiemas tähenduses, s.o. arendus, testide vahelejätmine ja tulemuste analüüsimine ei lahenda mitte ainult programmikoodis juba tehtud vigade leidmise probleemi. Tõsine suhtumine testimisse võimaldab vigu ennetada: enne koodi kirjutamist tuleks mõelda, milliseid vigu selles võib teha ning kirjutada nendele vigadele suunatud test, kuna koodi kvaliteet paraneb.

Uute elutsükli mudelite puhul näib testimine lahustuvat teistesse arendusfaasidesse. Seega ei sisalda MSF testimise faasi – teste kirjutatakse ja kasutatakse alati!

Seega peavad tarkvara tootmisprotsessi erinevad tegevused olema testimistegevustega hästi integreeritud. Sellest lähtuvalt peavad testimisvahendid olema hästi integreeritud paljude teiste arendustööriistadega. Tarkvaraarendustööriistade suurtootjatest said sellest esimesena aru Telelogic (telekommunikatsioonitarkvara projekteerimise, modelleerimise, juurutamise ja testimise tööriistade komplekt, mis põhineb SDL/MSC/TTCN tähistustel) ja Rational Software (sarnane komplekt, peamiselt põhineb UML-i tähistusel). IBM astus järgmise sammu, alustades Rationali tööriistade võimaluste integreerimist Eclipse'i tarkvaraarenduskeskkonda.

XP lõputöö – “Enne selle juurutamist kirjuta test” – on loosungina hea, kuid tegelikult on see sama ebakonstruktiivne. Suurte tarkvarasüsteemide jaoks on vaja välja töötada testid erinevatel eesmärkidel: moodulite testid, integratsiooni- või komponentide testid, süsteemitestid.

Testimise kolm komponenti – ekskursioon teooriasse

Ühiku testimine eksponeeritakse väikesed moodulid (protseduurid, klassid jne). Suhteliselt väikese, 100–1000 rea suuruse mooduli testimisel on võimalik kontrollida kui mitte kõiki, siis vähemalt paljusid loogilisi harusid juurutamisel, erinevaid teid andmete sõltuvuse graafikus ja parameetrite piirväärtusi. Selle järgi koostatakse kriteeriumid testi katvus(kaetud on kõik operaatorid, kõik loogikaharud, kõik piiripunktid jne).

Kõigi moodulite õigsuse kontrollimine ei garanteeri kahjuks moodulsüsteemi korrektset toimimist. Kirjanduses käsitletakse mõnikord moodulite süsteemi testimise ebaõige korralduse "klassikalist" mudelit, mida sageli nimetatakse "suure hüppe" meetodiks. Meetodi olemus seisneb selles, et esmalt testitakse iga moodulit eraldi, seejärel kombineeritakse need süsteemiks ja testitakse kogu süsteemi. Suurte süsteemide puhul on see ebareaalne. Selle lähenemisviisi korral kulub palju aega vigade lokaliseerimisele ja testimise kvaliteet jääb madalaks. Alternatiiv "Suurele hüppele" - integratsiooni testimine Süsteemi etapiviisiliselt ülesehitamisel lisatakse moodulite rühmad järk-järgult.

Komponentide tehnoloogiate levik tekitas selle termini "komponentide testimine" integratsioonitestimise erijuhuna.

Täielikult juurutatud tarkvaratoode allutatakse süsteemi testimine. Selles etapis ei huvita testijat mitte üksikute protseduuride ja meetodite õige rakendamine, vaid kogu programm tervikuna, nagu lõppkasutaja seda näeb. Testid põhinevad programmile esitatavatel üldistel nõuetel, mis hõlmavad mitte ainult funktsioonide õiget rakendamist, vaid ka jõudlust, reageerimisaega, vastupidavust tõrgetele, rünnakutele, kasutajavigadele jne. Süsteemi ja komponentide testimiseks kasutatakse teatud tüüpi testide katvuskriteeriume (näiteks, kas kõik tüüpilised tööstsenaariumid on hõlmatud, kõik ebatavaliste olukordadega stsenaariumid, stsenaariumide paariskoosseisud jne).

Testimisvahendid – tegelik praktika

Olles lõpetanud metoodika ekskursiooni, pöördume tagasi küsimuse juurde, milliseid testimisvahendeid praegu kasutatakse ja kui palju need vastavad uutele ideedele testimise koha kohta programmi arendusprotsessis.

Hetkel on enim automatiseeritud järgmised tööetapid: testi täitmine, saadud andmete kogumine, testide katvuse analüüs (üksuse testimiseks kogutakse tavaliselt teavet kaetud operaatorite ja kaetud loogiliste harude kohta), päringute töötlemise oleku jälgimine veaparandus.

Vaatame testimisvahendid üle vastupidises järjekorras – alates süsteemi testimisest kuni üksuse testimiseni.

GUI rakenduste testimise tööriistu kasutatakse laialdaselt. Neid nimetatakse sageli funktsionaalse testimise tööriistad. Kui rakenduse vastutuse tase ei ole kõrge, võib sellist testimist piirata; Seda tüüpi testid on kõige odavamad.

Seda tüüpi testimisel kasutatakse laialdaselt salvestamise ja taasesituse tööriistu; Tuntuimate toodete hulka kuuluvad Rational Robot (IBM/Rational), WinRunner (Mercury Interactive), QARun (Compuware). Lisaks on olemas tööriistad tekstiterminali liideste jaoks, näiteks Compuware'i QAHiperstation.

Mercury Interactive'i LoadRunneri tööriistakomplekti kasutatakse laialdaselt veebirakenduste ja muude hajutatud süsteemide koormuse testimiseks; selle eesmärk ei ole luua keerukaid testimisstsenaariume, kuid see pakub rikkalikku materjali jõudluse analüüsiks ja kitsaskohtade otsimiseks, mis mõjutavad hajutatud süsteemi jõudlust.

Salvestus- ja taasesitustööriistade kasutamise ligikaudne üldine skeem on järgmine:

stsenaariumi väljamõtlemine (soovitavalt nõuete süstemaatilise analüüsi põhjal);
viia läbi tööseanss vastavalt sellele stsenaariumile; tööriist salvestab kogu kasutajalt tuleva sisendinfo (klahvivajutused klaviatuuril, hiireliigutused jne) ja genereerib vastava skripti.

Saadud skripti saab käivitada mitu korda, tehes selles vajadusel väikseid muudatusi.

Skripti kirjutamisel saab teha peatusi, et näidata, milliseid süsteemi vastuseid konkreetses olukorras õigeks pidada, millised kasutaja sisendandmete variatsioonid on võimalikud jne. Kui sellised variatsioonid on olemas, valib tööriist järgmisel testi esitamisel iseseisvalt ühe määratletud alternatiividest. Kui süsteemi vastus ei vasta oodatud vastusele, salvestatakse viga.

Seda tüüpi testimise võimalused on aga piiratud:

skriptide salvestamine on võimalik ainult siis, kui teil on tulevase graafilise liidese prototüüp;
skripti tugi on väga töömahukas; sageli on lihtsam skript uuesti kirjutada kui seda redigeerida;
Seetõttu ei ole tulemuslik teostada testide loomise tööd paralleelselt süsteemi enda arendamisega ning üldjuhul on see võimatu enne prototüübi loomist.

Järgmine tööriistade klass on komponentide testimise tööriistad. Näiteks on Test Architect (IBM/Rational). Sellised tööriistad aitavad korraldada ühe komponenditehnoloogia (nt EJB) abil loodud rakenduste testimist. Testprogrammi erinevate komponentide, eriti moodulite, skriptide ja skriptide testide loomiseks on saadaval mallide komplekt.

Kas see tööriist vastab täiustatud testiarenduse nõuetele? Üldiselt jah: testi koostamiseks piisab komponentide liideste kirjeldusest. Kuid on ka nõrkusi, mis on aga omased enamikule teistele tööriistadele. Seega tuleb testimisskript käsitsi kirjutada. Lisaks puudub ühtne süsteem testide katvuse kriteeriumide täpsustamiseks ja nende kriteeriumide sidumiseks süsteemi funktsionaalsete nõuetega.

Viimane siin käsitletud tööriistaklassidest on üksuse testimise tööriistad. Näiteks Test RealTime (IBM/Rational), mis on mõeldud C++ moodulite testimiseks. Selle tööriista oluline komponent on "avalduste" (väidete) kontrollimise mehhanism. Lausete abil saab sõnastada nõuded klasside funktsioonide/meetodite sisend- ja väljundandmetele loogiliste tingimuste kujul, sarnasel kujul saab seada muutumatuid nõudeid objektiandmetele. See on märkimisväärne edasiminek võrreldes Test Architectiga. Väiteaparaat võimaldab süstemaatiliselt esitada funktsionaalseid nõudeid ja nende nõuete põhjal koostada testi katvuse kriteeriumid (samas ei paku Test RealTime katvuse analüüsi automatiseeritud tuge).

Põhimõtteliselt saab seda tööriista kasutada täiustatud testide arendamiseks, kuid sama funktsioon ise testtoimingute genereerimine jääb realiseerimata - seda tööd tuleb teha käsitsi. Testide ja väidete taaskasutamiseks puudub tehniline ega metoodiline tugi.

Uue põlvkonna tööriistad, mis järgivad mudelipõhist testimist või spetsifikatsioonipõhist testimise lähenemisviisi, pakuvad neile probleemidele lahendust.

Kuidas saavad mudelid aidata

Arendaja ja testija peas on alati olemas nii programmi ülesehituse üks või teine “mudel” kui ka selle soovitud käitumise “mudel”, mille põhjal koostatakse eelkõige testitavate omaduste nimekirjad ning luuakse vastavad testinäited. (Pange tähele, et tegemist on erinevate mudelitega; esimesi nimetatakse sageli arhitektuurseteks, teisi aga funktsionaalseteks või käitumuslikeks.) Need koostatakse sageli dokumentidest või mitteametlikest aruteludest.

Mudelite ja spetsifikatsioonide väljatöötamist seostatakse programmeerimise “matematiseerimisega”. Programmide kujundamisel ja isegi genereerimisel on püütud kasutada erinevaid matemaatilisi lähenemisviise juba arvutite algusaastatest peale. Suhtelist edu on saavutatud kompilaatorite teoorias, relatsiooniandmebaasides ja mitmetes väga spetsiifilistes valdkondades; Enamikus praktilistes valdkondades ei olnud võimalik saavutada märkimisväärseid tulemusi. Paljud inimesed on muutunud programmeerimise formaalsete meetodite suhtes skeptiliseks.

90ndate esimesel poolel tekkis uus huvi formaalsete meetodite vastu. Selle põhjustasid esimesed tulemused, mis saadi testimisel formaalsete mudelite ja formaalsete spetsifikatsioonide abil.

Mudelipõhise testimise eelised olid järgmised:

funktsionaalsete nõuete spetsifikatsioonil põhinevad testid on tõhusamad, kuna need on rohkem keskendunud funktsionaalsuse kontrollimisele kui testid, mis põhinevad ainult teostuse tundmisel;
Enesekontrolli teste saab luua formaalsete spetsifikatsioonide põhjal, kuna sihtsüsteemi tulemuste kontrollimise kriteeriumid saab sageli välja võtta formaalsetest spetsifikatsioonidest.

Selliste testide kvaliteedi osas polnud aga selgust. Mudeleid on tavaliselt lihtsam rakendada, seega võib eeldada, et mudelit hästi "katvad" testid on tegelike süsteemide katmiseks liiga kehvad. Vaja oli ulatuslikku katsetamist reaalsetes projektides.

Mudel on mingisugune süsteemi struktuuri ja käitumise peegeldus. Mudelit saab kirjeldada süsteemi oleku, sellel tehtavate sisendtoimingute, lõppolekute, andmevoogude ja juhtimisvoogude, süsteemi poolt tagastatavate tulemuste jms kaudu. Süsteemi erinevate aspektide kajastamiseks kasutatakse erinevaid terminite komplekte. Formaalne spetsifikatsioon on süsteemimudeli ja selle käitumise nõuete täielik kirjeldus konkreetse formaalse meetodi osas. Süsteemi omaduste kirjeldamiseks võite kasutada mitut mudelit mitme formalismi piires. Tavaliselt, mida üldisem on modelleerimismärk, seda keerulisem on programmide testimise automatiseerimine selles tähistuses kirjeldatud mudeli/spetsifikatsiooni alusel. Mõned tähistused ja keeled on rohkem keskendunud kirjelduse juurdepääsetavusele ja läbipaistvusele, teised - hilisemale analüüsile ja tõlkimisele, eriti spetsifikatsiooni tõlkimisele testiks. Tööstusliku kasutuse nõuetele vastavat formaalset spetsifikatsioonikeelt on püütud välja töötada (näiteks RAISE metoodika), kuid laialdast kasutust pole need leidnud.

On mitmeid formaalseid spetsifikatsiooni tähiseid, mis on juba klassikaliseks saanud: VDM, Z, B, CCS, LOTOS jne. Mõned neist, näiteks VDM, on kasutusel eelkõige kiirprototüüpimiseks. B-keel on mugav analüüsimiseks, eelkõige mudelite analüütiliseks kontrollimiseks. Kõiki neid keeli kasutatakse ülikooliprogrammides aktiivselt. Reaalses praktikas kasutatakse UML-i arhitektuurimudelite kirjeldamiseks ning käitumismudelite koostamiseks SDL/MSC keeli, UML-i käivitatavaid diagramme ja sarnaseid tähistusi.

Loetletud keeled ja käitumismudelite tähistused ei ole kahjuks piisavalt üldised. Need on end telekommunikatsioonirakendustes hästi tõestanud ja on praktiliselt kasutud "üldiste" tarkvarasüsteemide funktsionaalsuse kirjeldamisel: operatsioonisüsteemid, kompilaatorid, DBMS-id jne.

Uue põlvkonna tööriistad mudelite/spetsifikatsioonide kirjeldamiseks ja vahendid testide genereerimiseks, et kontrollida antud mudeli rakendamise käitumise järjepidevust, väidavad end olevat vahendid selliste süsteemide testide väljatöötamiseks.

Mudelipõhised testimise tööriistad

Test Real Time on selle rühma üks esimesi esindajaid. Parasofti Jtest pakub suuremaid võimalusi. Comformiqi tööriistad on huvitavad. Mudelipõhiste testide arendustööriistade perekonda pakub Venemaa Teaduste Akadeemia Süsteemi Programmeerimise Instituut koostöös ettevõttega ATS. Kuna autorid on UniTesK perekonnaga palju rohkem tuttavad, kirjeldame mudelipõhise testimise lähenemisviisi üldist skeemi UniTesK näidete abil.

Riis. 1. Spetsifikatsiooni ja testi arendusprotsessi etapid

Spetsifikatsiooni ja testi väljatöötamise protsessi üldine ülevaade koosneb neljast etapist (joonis 1).

Esimene faas on suhteliselt lühike, kuid reaalsetes projektides on see oluline. Siin on sätestatud mudeli abstraktsioonitase. Mudel peaks olema võimalikult lihtne: see võimaldab teil nõuda põhjalikku testide komplekti. Samas peab mudel olema sisukas ja paljastama testitava teostuse eripära. Seega on esimese faasi ülesandeks leida kompromiss abstraktsuse ja detaili vahel.

Teise faasi ülesanne on kirjeldada süsteemi käitumisele esitatavaid nõudeid. Paljud lähenemisviisid (näiteks SDL) pakuvad välja käivitatavate mudelite kirjeldamise, mida võib pidada tulevaste rakenduste prototüüpideks. Nõuete seadmine sel juhul määratakse valemiga "rakendus peab käituma samamoodi nagu mudel". Lähenemisviis on selge, kuid kahjuks paljudes reaalsetes olukordades see ei tööta. Oletame, et mudeli poolt konstrueeritud teatud sõnumi päis tähistab ühte aega ja juurutusest tulenev sarnane päis veidi erinevat aega. Kas see on viga või mitte? Üks näide veel. Mäluhaldussüsteemi mudel genereeris kursori vabale mälukohale, tegelik süsteem aga teistsuguse osuti: mudel ja süsteem töötavad erinevates aadressiruumides. Kas see on viga?

UniTesK – ühtne lahendus

UniTesK soovitab kasutada niinimetatud kaudseid või piirangute spetsifikatsioone. Need on täpsustatud protseduuride eel- ja järeltingimuste ning andmetüüpide muutumatute piirangute kujul. See mehhanism ei võimalda mudelil kirjeldada funktsioonide eeldatavate väärtuste arvutamise algoritme, vaid ainult nende omadusi. Oletame, et mäluhaldussüsteemi puhul täpsustatakse mudelit Boole'i avaldis sellises järeltingimuses nagu "osuti väärtus kuulub vabale mälualale". Ruutjuure funktsiooni järeltingimuse lihtne näide on toodud aadressil ; sama spetsifikatsioon on esitatud kolmes erinevas tähistuses: C, Java ja C# keelte stiilis. Tavapäraste programmeerimiskeelte spetsifikatsioonilaiendite kasutamine klassikaliste formaalsete spetsifikatsioonikeelte asemel on samm, mille astuvad peaaegu kõik selliste tööriistade arendajad. Neid eristab vaid tähistuste väljendusvõime ning spetsifikatsioonide analüüsi- ja tõlkimisvõime.

Kolmas etapp on testskripti väljatöötamine. Lihtsamal juhul saab skripti kirjutada käsitsi, kuid selles tööriistarühmas on see halb vorm. Test, s.t. Programmi või andmestruktuuri mõnest kirjeldusest lähtudes saab genereerida vastavate parameetritega kõnede jada sihtsüsteemi operatsioonidele. Me nimetame sellist kirjeldust stsenaarium. Conformiq pakub lõpliku olekumasina kirjeldamiseks. Automaadi erinevad olekud vastavad sihtsüsteemi muutujate erinevatele väärtustele, üleminekud vastavad kõnedele selle süsteemi toimingutele. Automaadi määratlemine tähendab iga oleku kirjeldamist, millisesse olekusse me sellest olekust liigume, kui pöördume mis tahes etteantud parameetriga etteantud toimingu poole. Kui sellist kirjeldust on lihtne hankida, pole vaja midagi muud teha: tööriist genereerib testi automaatselt ja esitab testi tulemused näiteks MSC diagrammide kujul. Kuid kas see on lihtne näiteks ühe täisarvulise muutuja ja kahe või kolme toiminguga programmi puhul? Tõenäoliselt jah. Üldjuhul on seda aga lihtsalt võimatu teha.

UniTesK-s ei kirjeldata testijadade genereerimiseks lõpliku oleku masinat, vaid see genereeritakse testi täitmise ajal. Testi arendajalt nõutakse vaid meetodi määramist mudeli oleku arvutamiseks sihtsüsteemi oleku põhjal ja meetodi praeguses olekus rakendatud testtoimingute loetlemiseks. Need arvutused registreeritakse testjuhtumites. Järgmine katsemõju valitakse stsenaariumi spetsifikatsiooni alusel, sõltuvalt eelnevate mõjude tulemustest. Sellel lähenemisviisil on kaks olulist eelist. Esiteks võimaldab see koostada keerulisi testijadasid ülimalt kompaktsel ning kergesti kirjutataval ja arusaadaval kujul. Teiseks muutuvad testid väga paindlikuks: neid saab hõlpsasti parameetreid määrata vastavalt hetke testimisvajadustele ja isegi automaatselt kohaneda mudeli väiksemate muudatustega. Joonisel fig. 3 on stsenaariumimeetodi näide.

Üldiselt kirjeldab testskript iteraatoreid antud klassi kõigi meetodite jaoks, kuid iga kord lahendab testiarendaja ainult kohaliku probleemi – kuidas itereerida sisendparameetridüksainus meetod. Üldine ülesanne on kõnejärjekorra korraldamine; kuidas naasta samasse olekusse vajalik arv kordi, et testida veel ühte meetodit, veel ühte parameetri väärtust; millal peatuda, et mitte teha tarbetut tööd - selle kõige eest hoolitseb tööriist.

UniTesK kasutab ühtset testiarhitektuuri, mis sobib erineva keerukusega, erinevate ainevaldkondadega seotud süsteemide testimiseks ja testi skaleeritavuse tagamiseks. Testkomponendid, mis nõuavad inimese kirjutamist, eraldatakse teegist ja automaatselt genereeritud komponentidest (joonis 4).

Reaalsetes süsteemides on eristatavate olekute arv ja igas neist lubatud katsetoimingute arv väga suur, mis viib kombinatoorse "olekute plahvatuseni". Selle efekti vastu võitlemiseks on välja töötatud mudeli faktoriseerimise mehhanism: need sihtsüsteemi olekud, mille erinevus on käesoleva testi ülesannete seisukohast ebaoluline, liidetakse mudeli üheks üldistatud olekuks; testi mõjud kombineeritakse sarnaselt rühmadesse. Faktoriseerimise protsess annab arendajale loomingulise vabaduse, kuid samas toetab seda põhjalikud uuringud, mis määravad piisavad tingimused, mis garanteerivad tulemuste õigsuse ja testimisaja olulise vähenemise, säilitades samal ajal saavutatud testi katvuse.

Riis. 4. Testprogrammide arhitektuur

UniTesK loojad, uskudes, et testide arendamiseks ei tohiks olla eraldi keskkonda, mitte ainult ei andnud sellele võimet matkida erinevaid programmeerimiskeeli, vaid tagasid selle koostisosade tööriistade integreerimise populaarsetesse programmiarendustööriistadesse. Joonisel fig. 5 näitab UniTesK kasutamise seanssi Sun Microsystemsi arenduskeskkonnas Forte 4.0.

Uus kvaliteet, mida uued tööriistad lubavad

Nagu eespool märgitud, seisavad testimistööriistade loojad tavaliselt silmitsi järgmiste väljakutsetega.

testi katvuse kriteeriumide puudumine või ebaselge definitsioon, otsese seose puudumine funktsionaalsete nõuetega;
katse taaskasutamise toetuse puudumine;
testi enda automaatse genereerimise puudumine (see kehtib nii sisendmõjude kui ka võrdlustulemuste või teostuse õigsuse automaatsete analüsaatorite kohta).

Kas testimisvahenditel, mis kasutavad testi loomiseks sihtsüsteemi mudelit või formaalset spetsifikatsiooni, on traditsiooniliste tööriistade ees põhimõttelisi eeliseid? Sellele küsimusele vastamiseks näitame, kuidas mudeleid kasutavate tööriistade märgitud probleemid lahendatakse.

Testi katvuse kriteeriumid. Peamine kriteerium on kõigi väidete, eriti protseduuride või meetodite järeltingimusi määratlevate väidete kontrollimine. Seda on lihtne kontrollida ja hõlpsasti seostada sihtsüsteemi funktsionaalsete nõuetega. Seega pakuvad UniTesK tööriistad, Java ja C# platvormide tööriistad neljal tasemel pesastatud kriteeriume.

Testide taaskasutamine. Taaskasutamise tase on oluliselt kõrgem kui traditsioonilistel tööriistadel. Testi arendaja ei kirjuta testskripti, vaid kinnituse kontrollimise kriteeriume ja testskripti. Mõlemal puudub palju juurutamise üksikasju ja seetõttu on neid lihtsam sihtsüsteemi uue versiooni jaoks uuesti kasutada või sarnase projekti spetsifikatsioone ja teste kohandada. Näiteks UniTesK statistika näitab, et korduvkasutuse tase erinevate operatsioonisüsteemide tuumade testimisel ületab 50%.

Automaatne testide genereerimine. See on uute tööriistade peamine eelis; siin on nad traditsioonilistest tööriistadest märkimisväärselt ees, kuna nad ei kasuta suvalist tüüpi tähistusi ning modelleerimis- ja spetsifikatsioonimeetodeid, vaid just neid, mis pakuvad eeliseid testide automaatsel genereerimisel. Seega võimaldavad avaldused genereerida test "oraakleid" - programme tulemuse õigsuse automaatseks analüüsimiseks; erinevat tüüpi lõplike olekutega masinad või nende analoogid võimaldavad genereerida testjadasid. Lisaks, kuna mudelid on tavaliselt lihtsamad kui teostused, saab neid põhjalikumalt analüüsida, nii et testikomplekt muutub süstemaatilisemaks.

Vaatlusaluseid tööriistu on testitud reaalsete suuremahuliste projektide peal. Loomulikult on igal projektil teatud eripärad, mis võivad takistada põhjalikku testimist. Kuid nende tööriistade kasutamise kogemus näitab, et tavaliselt on käsitsi testimise abil võimalik saavutada häid tulemusi, paremaid kui sarnastes projektides saadud tulemused. UniTesK kasutajad peavad tavaliselt vastuvõetavaks kvaliteeditasemeks sihtsüsteemi 70-80% koodikatet; sel juhul peab olema täidetud vähemalt kõigi loogikaharude järeltingimustes katmise kriteerium. Mõnede keerukate programmide puhul (sh GCC kompilaatori optimeerimisplokk) saavutati katvuse tase 90-95%.

Kas selle lähenemisviisi kohaldamisel on mingeid põhimõttelisi piiranguid? Peaaegu võimatu on seda kasutada juhul, kui ühel või teisel põhjusel ei osanud ega tahtnud keegi klient-arendaja-testija ahelas selgelt sõnastada sihtsüsteemile esitatavaid nõudeid. See pole aga mitte ainult piirang, vaid ka täiendav stiimul arendusprotsesside täiustamiseks, järjekordne põhjus, miks kliendile selgitada, et projekteerimisfaasis tehtud investeeringud tasuvad enam kui ära, vähendades projekti üldist arendusaega ja -kulusid.

Meetodi spetsifikatsiooni üldstruktuuri elementide nimetused:

S- Operatsiooni allkiri

A- Juurdepääsu spetsifikatsioon

- Eeltingimus

B- Funktsionaalsusharude määratlus

> - Järelseisund

Java:

Klassi SqrtSpecification ( S Specification static double sqrt(double x) A loeb x, epsilon ( = 0; ) post ( > if(x == 0) ( B haru “Null argument”; > return sqrt == 0; > ) else ( B haru "Positiivne argument"; > return sqrt >= 0 && > Math.abs((sqrt*sqrt-x)/x) ) ) )

Si:

S spetsifikatsioon double SQRT(double x) A loeb (double)x, epsilon ( = 0.; ) katvus ZP ( if(x == 0) ( B return(ZERO, "Zero argument"); ) else ( B return( POS, "Positiivne argument"); ) ) post ( > if(kate(ZP, NULL)) ( > return SQRT == 0.; > ) else ( > return SQRT >= 0. && > abs((SQRT*SQRT) - x)/x) ) ) )

C#:

nimeruum Näited ( spetsifikatsiooniklass SqrtSpecification ( S spetsifikatsioon static double Sqrt(double x) A loeb x, epsilon ( = 0; ) post ( > if(x == 0) ( B haru NULL ("Null argument"); > return $ this.Result == 0; > ) else ( B haru POS("Positiivne argument"); > return $this.Result >= 0 && > Math.Abs(($this.Result * $this.Result - x)/ x) ) > ) > ) ) )

Veebiteenuste testimine

Enamik Parim viis hinnake, kas testisime toodet hästi – analüüsige puuduvaid defekte. Need, millega meie kasutajad, juurutajad ja ettevõtted on kokku puutunud. Nende põhjal saab palju hinnata: mida me pole piisavalt põhjalikult kontrollinud, millistele toote valdkondadele tuleks rohkem tähelepanu pöörata, milline on üldine väljajätmiste protsent 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õib olla juba hilja: Habres ilmus meie kohta vihane artikkel, konkurendid on kiiresti leviv kriitika, kaotasime klientide usalduse meie vastu, 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 testime? Millistele valdkondadele jääb tähelepanuta, kus on peamised riskid, milline on edasiminek? Kõigile neile küsimustele vastamiseks hindame testi katvust.

Miks hinnata?

Igasugune hindamismõõdik on ajaraisk. Praegu saate testida, vigu luua ja automaatteste ette valmistada. Millist maagilist kasu saame testide katvuse mõõdikutest, et ohverdada testimisaega?

Oma nõrkade kohtade leidmine. Muidugi, kas me 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?
Harva saame oma katvuse hindamise tulemuste põhjal 100%. 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 hindamine.
Tähelepanu fookus. Oletame, et meie tootel on umbes 50 erinevat funktsionaalset piirkonda. Selgub uus versioon, ja hakkame neist 1 testima ja leiame sealt kirjavigu ja paar pikslit liigutanud nuppe ja muid pisiasju... Ja nüüd on testimise aeg läbi ja seda funktsionaalsust testitakse detailselt... 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 paremini arvutada. Ja selles artiklis jagan lihtsalt mõningaid näiteid ja oma kogemusi selle kohta, kuidas seda teha. Mitte selleks, et lahendusi pimesi kopeerida – vaid selleks, et Sinu kujutlusvõime tugineks sellele kogemusele, mõeldes läbi Sinu jaoks ideaalse lahenduse.

Nõuete katvust hindame testidega

Oletame, et teie meeskonnas on analüütikud ja nad ei raiska oma aega. 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. Nad sisestavad sellesse süsteemi nõuded, mis vastavad nõuete nõuetele (vabandust tautoloogiast). Need nõuded on atomaarsed, jälgitavad, spetsiifilised... Üldiselt ideaalsed tingimused testimiseks. Mida me saame sel juhul teha? Skriptitud lähenemisviisi kasutamisel siduge nõuded ja testid. Teeme samas süsteemis teste, teeme nõue-testi ühenduse ja näeme igal ajal 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 ühtegi viga...

Olgu, naaseme taevast maa peale. Tõenäoliselt pole teil üksikasjalikke nõudeid, need ei ole tuumakad, mõned nõuded on täielikult kadunud ja teil pole aega iga testi või vähemalt iga teise dokumenteerimiseks. Võib meelt heita ja nutta või tunnistada, et testimine on kompenseeriv protsess ning mida hullem on projekti analüüsi ja arendusega lood, seda rohkem peame ennast proovile panema ja kompenseerima teiste protsessis osalejate probleeme. Vaatame probleeme eraldi.

Probleem: nõuded ei ole tuumakad.

Ka analüütikud teevad mõnikord oma peas vigu ja tavaliselt on see täis probleeme kogu projektiga. Näiteks arenete tekstiredaktor, ja teie süsteemis võib (muu hulgas) olla kaks nõuet: "html-vormingut peab toetama" ja "faili avamisel toetamata vorming, peaks ilmuma küsimusega hüpikaken. Kui palju katseid on vaja esimese nõude põhikontrolliks? Ja 2. jaoks? Vastuste vahe on suure tõenäosusega umbes sajakordne!!! Me ei saa öelda, et kui esimese nõude jaoks on vähemalt 1 test, siis sellest piisab - kuid teise nõude jaoks on see tõenäoliselt nii.

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

Sel juhul saab nõuete katvuse automaatse arvutamise testidega eemaldada - see ei kanna endiselt semantilist koormust.
Iga nõude jaoks, alustades kõrgeimast prioriteedist, koostame testid. Ettevalmistamisel analüüsime, milliseid teste see nõue nõuab, kui paljudest piisab? Me viime läbi täiemahulise testanalüüsi ja ei ütle seda maha, et "on üks test, noh, okei."
Olenevalt kasutatavast süsteemist ekspordime/laadime üles nõudmisel teste ja... testime neid teste! Kas neid on piisavalt? Ideaalis tuleks selline testimine muidugi läbi viia koos analüütiku ja selle funktsiooni arendajaga. Printige testid välja, lukustage kolleegid koosolekuruumi ja ärge laske neil minna enne, kui nad ütlevad "jah, neist testidest piisab" (see juhtub ainult kirjalikul kokkuleppel, kui öeldakse, et need sõnad allkirjastavad, isegi ilma testide analüüsimine. Suulise arutelu käigus valavad kolleegid välja kriitikat, sooritamata teste, valesti mõistetud nõudeid jne – see ei ole alati meeldiv, kuid testimisel väga kasulik!)
Pärast testide nõuetekohast lõpetamist ja nende täielikkuses kokkuleppimist saab sellele nõudele süsteemis määrata oleku "testidega kaetud". See teave tähendab palju enamat kui "siin on vähemalt 1 test".

Loomulikult nõuab selline heakskiitmise protsess palju ressursse ja aega, eriti alguses, enne praktika omandamist. Seetõttu rakendage ainult kõrge prioriteediga nõudeid ja uusi täiustusi. Aja jooksul karmistate ülejäänud nõudeid ja kõik on rahul! Aga... mis siis, kui nõudeid polegi?

Probleem: nõudeid pole üldse.

Nad puuduvad projektist, arutatakse suuliselt, igaüks teeb mis tahab/oskab ja kuidas aru saab. Testime samamoodi. 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 võin soovitada valikut “määratle ja dokumenteeri nõuded ise” ja kasutasin seda strateegiat isegi paar korda oma praktikas, kuid 99% juhtudest pole testimismeeskonnas selliseid ressursse – nii et võtame natuke vähem ressursimahukas tee:

Loo funktsioonide loend. Sami! Google'i märgi kujul, PBI-vormingus TFS-is – valige ükskõik milline, kui te seda ei tee teksti vorming. Peame veel staatusi koguma! Sellesse loendisse lisame kõik toote funktsionaalsed alad ja proovime valida ühe üldise lagunemistase (saate üles kirjutada tarkvaraobjekte või kasutajaskripte või mooduleid või veebilehti või API meetodeid või ekraanivorme. .) – lihtsalt mitte kõike seda korraga! ÜKS lagunemisvorming, mis on teie jaoks lihtsam ja visuaalsem, võimaldab teil olulisi asju mitte kahe silma vahele jätta.
Lepime selle nimekirja TÄIELIKUSES kokku analüütikute, arendajate, ettevõtetega, oma meeskonna sees... Püüdke teha kõik, et mitte kaotada toote olulisi osi! Kui sügavalt analüüsida, on teie enda otsustada. Minu praktikas on olnud vaid üksikuid tooteid, mille jaoks lõime tabelisse üle 100 lehekülje ja need olid hiiglaslikud tooted. Kõige sagedamini on 30-50 rida järgneva hoolika töötlemise jaoks saavutatav tulemus. Väikeses meeskonnas ilma pühendunud testanalüütikuteta suurem arv funktsiooniloendi elemente on liiga raske hooldada.
Pärast seda lähtume prioriteetidest ja töötleme funktsioonide loendi iga rida nagu ülalkirjeldatud 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, kuid mitte jälgitavas vormingus?

Probleem: nõuded ei ole jälgitavad.

Projekti kohta on tohutul hulgal dokumentatsiooni, analüütikud kirjutavad kiirusega 400 tähemärki minutis, teil on spetsifikatsioonid, tehnilised kirjeldused, juhised, sertifikaadid (enamasti juhtub see kliendi soovil) ja kõik see toimib. nõuetena ja kõik on projektis olnud pikka aega Kas olete segaduses, kust millist teavet otsida?
Kordame eelmist lõiku, aidates kogu meeskonnal end organiseerida!

Loome funktsioonide loendi (vt ülal), kuid ilma Täpsem kirjeldus nõuded.
Iga funktsiooni kohta kogume linke tehnilistele spetsifikatsioonidele, spetsifikatsioonidele, juhistele ja muudele dokumentidele.
Lähtume prioriteetidest, koostame teste, lepime kokku nende täielikkuses. Kõik on sama, ainult ühendades kõik dokumendid ühte tabelisse, suurendame neile juurdepääsu lihtsust, läbipaistvaid olekuid ja testide järjepidevust. Lõpuks on meiega kõik suurepärane ja kõik on rahul!

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 mingit fikseeritud süsteemi, kuid meie tooted on tavaliselt elavad. Klient küsis midagi, midagi muutus meie tootevälises seadusandluses ja kuskilt leidsid analüütikud üle-eelmise aasta analüüsis vea... Nõuded elavad oma elu! Mida teha?

Oletame, et olete juba kogunud linke tehnilistele spetsifikatsioonidele ja spetsifikatsioonidele funktsiooniloendi tabeli, PBI, nõuete, Wiki märkuste 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. Igal juhul toob see kaasa sama tagajärje: teie testid on ebaolulised! Või need ei pruugi olla asjakohased. See tähendab, et need vajavad värskendamist (testi katvus vana versioon toode millegipärast tegelikult ei loe, eks?)
Funktsiooniloendis, RMS-is, TMS-is (Test Management System – testrails, sitechco jne) tuleb testid tingimata ja koheselt ebaoluliseks märkida! HP QC-s või MS TFS-is saab seda nõuete värskendamisel automaatselt teha, kuid Google'i plaadil või wikis peate selle käsitsi sisestama. Kuid te peaksite kohe nägema: testid pole olulised! See tähendab, et meie ees seisab täielik kordustee: värskendage, käivitage testanalüüs uuesti, kirjutage testid ümber, leppige kokku muudatustes ja alles pärast seda märkige funktsioon/nõue uuesti kui "testidega kaetud".

Sel juhul saame kõik testi ulatuse hindamise eelised ja seda dünaamikas! Kõik on õnnelikud!!! Aga…
Kuid olete kulutanud nii palju aega nõuete kallal töötamisele, et teil pole nüüd piisavalt aega testide testimiseks ega dokumenteerimiseks. Minu arvates (ja siin on ruumi usuvaidluseks!) on nõuded olulisemad kui testid ja nii on parem! Vähemalt on nendega kõik korras ja kogu meeskond on teadlik ning arendajad teevad täpselt seda, mida vaja. AGA TESTIDE DOKUMENTERIMISEKS EI JÄÄ AEGA!

Probleem: testide dokumenteerimiseks pole piisavalt aega.

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

Teil on endiselt vaja nõudeid, kas täielike nõuete või funktsioonide loendina, nii et mõned ülalkirjeldatud jaotised on olenevalt projekti analüütikute tööst siiski vajalikud. Kas teil on nõuded/funktsioonide loend?
Kirjeldame testimisstrateegiat ja lepime selles lühidalt kokku, 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. Seda strateegiat testitakse erinevalt, kuid teate: millal seda viimati testiti ja millise strateegiaga? Ja see, näete, pole ka halb! Ja kõik saavad õnnelikuks.