Andmebaasi testimine. Andmebaasi koormuse testimine. Andmekomplektide ja andmetabelite mõistmine

: kuidas andmebaase testida ja siluda

Rakenduse koodi automaatne ühikutestimine on lihtne ja arusaadav. Kuidas andmebaasi testida? Või rakendus, mis töötab andmebaasiga. Andmebaas ei ole ju ainult programmi kood, andmebaas on objekt, mis salvestab oma oleku. Ja kui me hakkame testimise käigus andmebaasis andmeid muutma (ja ilma selleta, mis testimine meil on?!), siis peale iga testi andmebaas muutub. See võib segada järgnevaid teste ja rikkuda andmebaasi jäädavalt.

Probleemi lahendamise võti on tehingud. Selle mehhanismi üks omadusi on see, et seni, kuni tehing pole lõpule viidud, saate alati kõik muudatused tagasi võtta ja taastada andmebaasi tehingu algusaegse oleku.

Algoritm on selline:

avada tehing;
vajadusel teostame testimiseks ettevalmistavaid samme;
teostada ühikutest (või lihtsalt käivitada skript, mille tegevust tahame kontrollida);
kontrollige skripti tulemust;
Tühistame tehingu, tagastades andmebaasi algsesse olekusse.

Isegi kui testitavas koodis on sulgemata tehinguid, pöörab väline ROLLBACK ikkagi kõik muudatused õigesti tagasi.

See on hea, kui peame testima SQL-skripti või salvestatud protseduuri. Mis siis, kui testime rakendust, mis loob ise andmebaasiga ühenduse, avades uue ühenduse? Lisaks, kui me silume, siis tõenäoliselt tahame vaadata andmebaasi silutava rakenduse silmade kaudu. Mida sel juhul teha?

Ära kiirusta hajutatud tehingute loomisega, on lihtsam lahendus! Kasutades standardseid SQL-serveri tööriistu, saate tehingu avada ühel ühendusel ja jätkata seda teises.

Selleks peate looma ühenduse serveriga, avama tehingu, hankima selle tehingu jaoks märgi ja seejärel edastama selle testitavale rakendusele. See liitub meie tehinguga oma seansis ja sellest hetkest alates näeme meie silumisseansil andmeid (ja tunneme ka lukke) täpselt nii, nagu testitav rakendus seda näeb.

Toimingute jada on järgmine:

Olles alustanud silumisseansil tehingut, peame välja selgitama selle identifikaatori. See on ainulaadne string, mille järgi server tehinguid eristab. See identifikaator tuleb kuidagi testitavale rakendusele edastada.

Nüüd on rakenduse ülesanne siduda end meie kontrolltehinguga, enne kui ta hakkab tegema seda, mida ta peaks tegema.

Seejärel hakkab rakendus tööle, sealhulgas käivitab oma salvestatud protseduurid, avab tehingud, muudab isolatsioonirežiimi... Kuid meie silumisseanss toimub kogu selle aja rakendusega samas tehingus.

Oletame, et rakendus lukustab tabeli ja hakkab selle sisu muutma. Praegu ei saa lukustatud tabelisse vaadata ükski teine ühendus. Kuid mitte meie silumisseanss! Sealt saame vaadata andmebaasi samamoodi nagu rakendus, kuna SQL-server usub, et oleme samas tehingus.

Kui kõigi teiste seansside puhul on rakenduse toimingud lukuga peidetud...

Meie silumisseanss läbib lukke (server arvab, et need on meie enda lukud)!

Või kujutage ette, et rakendus hakkab SNAPSHOT-režiimis töötama oma stringide versioonidega. Kuidas ma saan neid versioone uurida? Isegi see on võimalik, kui teid seob ühine tehing!

Ärge unustage selle põneva protsessi lõpus kontrolltehingut tagasi võtta. Seda saab teha nii silumiseansist (kui testimisprotsess lõppeb normaalselt) kui ka rakendusest endast (kui selles juhtub midagi ootamatut).

Selle kohta saate rohkem teada kursustel

Paar aastat tagasi selgus, et SQL oli ootamatult aegunud. Ja NoSQL-i lahendused hakkasid ilmuma ja paljunema, jättes kõrvale SQL-keele ja relatsioonilise andmesalvestusmudeli. Peamised argumendid selle lähenemise toetuseks: oskus töötada suurandmetega (sama Big Data), andmete salvestamine kõige eksootilisematesse struktuuridesse ja mis kõige olulisem – oskus seda kõike väga kiiresti teha. Vaatame, kuidas NoSQL-i maailma populaarseimad esindajad seda teevad.

Kuidas saavutatakse kiirus NoSQL-is? Esiteks on see täiesti erineva andmesalvestusparadigma tagajärg. SQL päringute parsimine ja tõlkimine, optimeerija töö, tabelite ühendamine jne pikendavad oluliselt reageerimisaega. Kui võtate kõik need kihid välja, lihtsustate päringuid, loete kettalt otse võrku või salvestate kõik andmed RAM-i, saate kiirendada. Väheneb nii iga päringu töötlemise aeg kui ka päringute arv sekundis. Nii tekkisid võtmeväärtuste andmebaasid, mille tüüpilisem ja laiemalt tuntud esindaja on memcached. Jah, see vahemälu, mida kasutatakse laialdaselt veebirakendustes andmetele juurdepääsu kiirendamiseks, on ka NoSQL.

NoSQL tüübid

NoSQL-süsteemidel on neli peamist kategooriat:

Võti – väärtus (võti-väärtus). Suur räsitabel, kus on lubatud ainult võtmete järgi andmete kirjutamise ja lugemise toimingud.
Veerg. Tabelid ridade ja veergudega. Kuid erinevalt SQL-ist võib veergude arv ridade kaupa olla muutuv ja veergude koguarvu võib mõõta miljardites. Samuti on igal real unikaalne võti. Seda andmestruktuuri võib pidada räsitabeli räsitabeliks, esimene võti on reavõti, teine veeru nimi. Sekundaarsete indeksite toel on valikud võimalikud veerus oleva väärtuse, mitte ainult reaklahvi abil.
Dokumendile orienteeritud. Struktureeritud dokumentide kogud. Võimalik on valida dokumendi erinevate väljade järgi, samuti muuta dokumendi osi. Sellesse kategooriasse kuuluvad ka otsingumootorid, mis on küll indeksid, kuid reeglina ei salvesta dokumente ise.
Graafik. Spetsiaalselt loodud matemaatiliste graafikute salvestamiseks: sõlmed ja nendevahelised ühendused. Reeglina võimaldavad need määrata ka sõlmede ja linkide jaoks suvaliste atribuutide komplekti ning valida nende atribuutide põhjal sõlmed ja lingid. Toetab algoritme graafikute läbimiseks ja marsruutide koostamiseks.

Testimiseks võtsime kolme esimese kategooria esindajad:

Kuidas test läbi viidi

Meie käsutuses oli neli serverimasinat. Igal neist on kaheksatuumaline Xeon, 32 GB muutmälu, neli Inteli SSD-d, igaüks 120 GB.

Testisime YCSB-ga (Yahoo! Cloud Serving Benchmark). See on Yahoo! Uuringud 2010. aastal Apache litsentsi alusel. Võrdlusalus on spetsiaalselt loodud NoSQL-i andmebaaside testimiseks. Ja nüüd on see NoSQL-i jaoks ainus ja üsna populaarne etalon, tegelikult standard. Muide, see oli Java keeles kirjutatud. Lisasime algsele YCSB-le Aerospike'i draiveri, värskendasime veidi MongoDB draiverit ja tegime tulemuste väljundiga ka väikese triki.

INFO

Lisaks YCSB-le saab NoSQL-i andmebaasi jõudlust testida näiteks JMeteri abil.

Meie väikese klastri koormuse loomiseks kulus kaheksa klientmasinat. Neljatuumaline i5 ja 4 GB muutmälu. Ühest (või kahest, kolmest või neljast...) kliendist ei piisanud klastri laadimiseks. See võib tunduda kummaline, kuid see on tõsi.

Kõik see liikus ühes gigabitis kohalik võrk. Võib-olla oleks see kümne gigabitises võrgus olnud huvitavam, kuid meil polnud sellist riistvara. See on huvitavam, sest kui operatsioonide arvu sekundis hakatakse mõõtma sadades tuhandetes, jookseme võrku. Gigabiti sekundis (10^9 bitti/s) läbilaskevõimega suudab võrk läbida vaid umbes 100 000 (10^5) kilobaidist paketti (~10^4 bitti). See tähendab, et me saame ainult 100 000 toimingut sekundis. Aga tegelikult tahtsime miljonit saada :).

Võrgukaardid on samuti olulised. Õigetel serveri võrgukaartidel on vastavalt mitu I/O kanalit, millest igaühel on oma katkestus. Kuid vaikimisi on Linuxis kõik need katkestused määratud ühele protsessorituumale. Selle peenuse eest hoolitsesid ainult Aerospike'i tüübid ja nende andmebaasi konfiguratsiooniskriptid hajutavad võrgukaardi katkestused protsessori tuumade vahel. Võrgukaardi katkestusi ja nende jaotumist protsessorituumade vahel näete näiteks järgmise käsuga: "cat /proc/interrupts | grep eth".

Peaksime rääkima ka SSD-dest. Tahtsime testida NoSQL-i andmebaaside toimimist spetsiaalselt pooljuhtdraividel, et mõista, kas need draivid on tõesti seda väärt, st pakuvad head jõudlust. Seetõttu proovisime SSD-d õigesti konfigureerida. Lisateavet selle kohta saate lugeda külgribalt.

SSD seadistamine

Eelkõige nõuavad SSD-d toiminguid, mida nimetatakse ülevarumiseks. Fakt on see, et SSD-l on aadressi tõlkimise kiht. Operatsioonisüsteemile nähtavad plokkide aadressid ei vasta üldse välkmälus olevate füüsiliste plokkidega. Nagu teate, on välkmälus piiratud arv ümberkirjutamistsükleid. Lisaks koosneb kirjutamisoperatsioon kahest etapist: kustutamine (sageli mitu plokki korraga) ja kirjutamine ise. Seetõttu vahetab kettakontroller kirjutamisel füüsilisi mäluplokke, et tagada draivi pikaealisus (ühtlane kulumine) ja hea kirjutamiskiirus. Kui operatsioonisüsteem kirjutab ploki kindlale aadressile, toimub kirjutamine füüsiliselt mõnele puhtale vabale mäluplokile ja vana plokk märgitakse hilisemaks (tausta)kustutamiseks saadaolevaks. Kõigi nende manipulatsioonide jaoks vajab kettakontroller vabu plokke, mida rohkem, seda parem. 100% täis SSD võib olla üsna aeglane.

Tasuta plokke saab hankida mitmel viisil. Nähtavate kettasektorite arvu määramiseks saate kasutada käsku hdparm (lülitiga "-N"). operatsioonisüsteem. Ülejäänu on täielikult kontrolleri käsutuses. Kuid see ei tööta iga riistvara puhul (näiteks ei tööta see AWS EC2-s). Teine võimalus on jätta kettaruumi partitsioonide (see tähendab näiteks fdiski loodud partitsioonide) hõivamata. Kontroller on piisavalt nutikas, et seda asukohta ära kasutada. Kolmas võimalus on kasutada failisüsteeme ja kerneli versioone, mis suudavad vabadest plokkidest kontrollerile teatada. See on sama käsk TRIM. Meie riistvaras oli piisavalt hdparmi, andsime 20% ketta kogumahust kontrollerile tükkideks rebimiseks.

SSD-de jaoks on oluline ka I/O planeerija. See on kerneli alamsüsteem, mis rühmitab ja järjestab ümber I/O toimingud (peamiselt kettale kirjutamise), et tõhustada. Vaikimisi kasutab Linux CFQ-d (Completely Fair Queuing), mis üritab kirjutisi ümber korraldada, et kirjutada võimalikult palju plokke järjest. See on hea tavaliste keerlevate (nii öeldakse - keerlevate:)) ketaste puhul, sest nende puhul on lineaarse ligipääsu kiirus märgatavalt suurem kui ligipääs juhuslikele plokkidele (pead tuleb liigutada). Kuid SSD-de puhul on lineaarne ja juhuslik kirjutamine (teoreetiliselt) võrdselt tõhusad ja CFQ-funktsioon toob kaasa ainult tarbetuid viivitusi. Seetõttu peate SSD-draivide jaoks lubama muud planeerijad, näiteks NOOP, mis lihtsalt täidab I/O-käske nende saabumise järjekorras. Ajakavandit saate vahetada näiteks järgmise käsuga: "echo noop > /sys/block/sda/queue/scheduler", kus sda on teie ketas. Ausalt öeldes tasub mainida, et uusimad tuumad suudavad ise tuvastada SSD-draive ja lubada nende jaoks õige ajakava.

Igale DBMS-ile meeldib nii intensiivselt kettale kirjutada kui ka intensiivselt lugeda. Ja Linuxile meeldib väga teha andmete ettelugemist ja ennetavat lugemist, lootuses, et kui olete selle ploki läbi lugenud, soovite lugeda ka järgmist. Kuid DBMS-i ja eriti juhusliku lugemise korral (ja see on meie võimalus) ei ole need lootused määratud täituma. Selle tulemusena on meil tarbetu lugemine ja mälukasutus. MongoDB arendajad soovitavad võimalusel ettelugemise väärtust vähendada. Seda saate teha käsuga "blockdev --setra 8 /dev/sda", kus sda on teie ketas.

Igale DBMS-ile meeldib avada palju-palju faile. Seetõttu on vaja oluliselt suurendada nofile limiite (kasutaja jaoks saadaolevate failideskriptorite arvu) failis /etc/security/limits.conf väärtuseni tunduvalt üle 4k.

Samuti tekkis huvi Küsi: Kuidas kasutada nelja SSD-d? Kui Aerospike ühendab need lihtsalt salvestusruumina ja vahetab kuidagi iseseisvalt juurdepääsu ketastele, siis muud andmebaasid viitavad sellele, et neil on ainult üks andmetega kataloog. (Mõnel juhul saate määrata mitu kataloogi, kuid see ei hõlma andmete triibutamist nende vahel.) Pidin mdadm utiliidi abil looma RAID 0 (triibuline). Ma arvan, et LVM-iga saab mängida, kuid andmebaasi müüjad kirjeldavad ainult mdadm-i kasutamist.

Loomulikult tuleb kõikidel klastri masinatel (nii serveril kui ka kliendil) kellad ntpd abil sünkroonida. Ntpdate siin ei sobi, kuna on vaja suuremat sünkroonimistäpsust. Kõigi hajutatud süsteemide puhul on ülioluline, et sõlmedevaheline aeg oleks sünkroonitud. Näiteks Cassandra ja Aerospike salvestavad rekordi muutmisaja. Ja kui klastri erinevates sõlmedes on erineva ajatempliga kirjeid, võidab uusim rekord.

NoSQL-i andmebaasid ise konfigureeriti järgmiselt. Konfiguratsioon võeti karbist välja ja rakendati kõiki dokumentatsioonis kirjeldatud soovitusi parima jõudluse saavutamiseks. Keerulistel juhtudel võtsime ühendust andmebaasi arendajatega. Kõige sagedamini on soovitused seotud tuumade arvu ja RAM-i hulga kohandamisega.

Lihtsaim viis seadistamiseks on Couchbase. Sellel on veebikonsool. Piisab teenuse käivitamisest kõigis klastri sõlmedes. Seejärel looge ühele sõlmele kopp (võtmete väärtuste "korv") ja lisage klastrisse teised sõlmed. Kõik toimub veebiliidese kaudu. Sellel pole eriti keerulisi seadistusi.

Aerospike ja Cassandra on konfigureeritud ligikaudu samal viisil. Peate iga klastri sõlme jaoks looma konfiguratsioonifaili. Need failid on iga sõlme jaoks peaaegu identsed. Seejärel käivitage deemonid. Kui kõik on korras, liidetakse sõlmed klastrisse. Teil peab olema üsna hea arusaam konfiguratsioonifaili valikutest. Hea dokumentatsioon on siin väga oluline.

Kõige raskem on MongoDB-ga. Teistes andmebaasides on kõik sõlmed võrdsed. Mongo puhul see nii ei ole. Soovisime võimalusel seada kõik andmebaasid samadesse tingimustesse ja seada kõigi replikatsiooniteguriks 2. See tähendab, et usaldusväärsuse ja kiiruse huvides peaks klastris olema kaks andmete koopiat. Teistes andmebaasides on replikatsioonitegur lihtsalt andmesalve (või "korvi" või "veergude perekonna") seadistus. MongoDB-s määrab andmete koopiate arvu klastri struktuur. MongoDB klastri saab õigesti konfigureerida ainult sellele pühendatud ametlikku dokumentatsiooni kaks korda lugedes :). Lühidalt, me vajame kilde või koopiakomplekte. Killud (noh, olete ilmselt kuulnud terminit "sharding") on kogu andmestiku alamhulgad, aga ka klastri sõlmed, kuhu iga alamhulk salvestatakse. Replica Sets on MongoDB termin klastri sõlmede komplekti jaoks, mis salvestavad identseid andmete koopiaid. Replica võrgul on põhisõlm, mis teostab kirjutustoiminguid, ja sekundaarsed sõlmed, kuhu põhisõlme andmed kopeeritakse. Rikete korral saab peasõlme rolli üle kanda koopiakomplekti teisele sõlmele. Meie juhtumi jaoks (neli serverit ja soov salvestada kaks andmete koopiat) selgub, et vajame kahte kildu, millest igaüks on kahe andmetega serveri koopiakomplekt. Lisaks tuleb igale koopiakomplektile lisada nn arbiter, mis ei salvesta andmeid, kuid on vajalik uue põhisõlme valimisel osalemiseks. Sõlmede arv koopiavõrgus jaoks õiged valimised peab olema veider. Teil on vaja ka väikest konfiguratsiooniandmebaasi, mis salvestab teavet kildude kohta ja milliseid andmevahemikke millisele killule salvestatakse. Tehniliselt on see ka MongoDB, kuid (võrreldes põhiandmetega) on see väga väike. Panime vahekohtunikud ja konfiguratsiooniandmebaasi kliendimasinatele. Ja igal kliendil peate käivitama mongose deemoni (mongo-lüliti), mis pääseb juurde konfiguratsiooniandmebaasile ja suunab iga kliendi päringud kildude vahel.

Igal NoSQL-i andmebaasil on oma ainulaadne viis andmete ja kehtivate toimingute esitamiseks. Seetõttu valis YCSB mis tahes andmebaasi (sh SQL-i) maksimaalse üldistamise.

Andmekogum, mida YCSB kasutab, on võti ja väärtus. Võti on string, mis sisaldab 64-bitist räsi. Seega, YCSB ise, teades andmebaasis olevate kirjete koguarvu, pääseb neile juurde täisarvuindeksi abil ja andmebaasi jaoks näeb võtmete komplekt välja täiesti juhuslik. Väärtus on tosin juhuslike binaarandmete välja. Vaikimisi genereerib YCSB kilobaidi suuruseid kirjeid, kuid nagu mäletate, piirab see gigabitises võrgus meid vaid 100 000 toiminguga sekundis. Seetõttu vähendasime testides ühe kirje suurust 100 baidile.

YCSB teeb nende andmetega väga lihtsaid toiminguid: sisestamine uus sissekanne võtme ja juhuslike andmetega, kirje lugemine võtme järgi, kirje uuendamine võtme järgi. Tabelit ei ühendata (ja tegelikult on mõeldud ainult ühte "tabelit"). Sekundaarsetel võtmetel pole valikuid. Tingimuste järgi mitut valikut pole (kontrollitakse ainult, kas primaarvõti sobib). See on väga primitiivne, kuid seda saab teha igas andmebaasis.

Vahetult enne testimist tuleb andmebaas andmetega täita. Seda teeb YCSB ise. Sisuliselt on see koormus, mis koosneb ainult sisestamistoimingutest. Katsetasime kahe andmekogumiga. Esimene mahub garanteeritult klastri sõlmede RAM-i, 50 miljonit kirjet, ligikaudu 5 GB puhtaid andmeid. Teine ei mahu garanteeritult RAM-i, 500 miljonit kirjet, ligikaudu 50 GB puhast andmemahtu.

Test ise - teatud toimingute komplekti sooritamine - viiakse läbi koormuse all erinevad tüübid. Oluline parameeter on toimingute suhe – mitu näitu peaks olema ja kui palju uuendusi. Kasutasime kahte tüüpi: rasket kirjutamist (Heavy Write, 50% lugemist ja 50% värskendusi) ja enamasti lugemist (peamiselt loetud, 95% lugemist ja 5% värskendusi). Iga kord valitakse juhuslikult, milline tehe sooritada, protsendid määravad toimingu valimise tõenäosuse.

YCSB saab toimingu sooritamiseks kasutada erinevaid kirje (võtme) valiku algoritme. See võib olla ühtlane jaotus (sama tõenäosusega saab valida mis tahes võtme kogu andmekogumist), eksponentsiaalne jaotus (andmekogumi alguses olevaid võtmeid valitakse palju sagedamini) ja mõned muud. Kuid Yahoo meeskond valis tüüpiliseks distributsiooniks nn zipfiani. See on ühtlane jaotus, kus teatud võtmeid (väike protsent klahvide koguarvust) valitakse aga oluliselt sagedamini kui teisi. See simuleerib populaarseid postitusi näiteks ajaveebides.

YCSB alustab mitme lõimega, millest igaühes jookseb silmus, kõik samas masinas. Kuna ühel klientmasinal on ainult neli tuuma, on see üsna masendav, kui üritate seal käivitada rohkem kui nelja lõime. Seetõttu käitasime YCSB-d korraga kaheksas kliendimasinas. Käivitamise automatiseerimiseks kasutasime kangast ja cronit (täpsemalt at). Väike Pythoni skript genereerib igal kliendil YCSB käivitamiseks vajalikud käsud, need käsud on igal kliendil tulevikus lähima minuti jaoks korraga järjekorda. Seejärel käivitatakse at ja YCSB käivitatakse edukalt (või mitte nii hästi, kui parameetrid on valed) samal ajal kõigil kaheksal kliendil. Tulemuste kogumiseks (YCSB logifailid) kasutatakse uuesti kangast.

tulemused

Seega on esialgsed tulemused iga kliendi YCSB logid. Need logid näevad välja umbes sellised (kuvatakse faili viimane osa):

Toimingud, 1187363 , Korduskatsed, 0 , Keskmine Latency(us), 3876.5493619053314 , MinLatency(us), 162 , MaxLatency(us), 278190 , 95thPercentileLatency(ms), 9th,2ntLatency(ms), 9th,2nt. 1 187363, Taasühendused , 0,0 , käitusaeg (ms), 303574,0 , toimingud, 1249984,0 , läbilaskevõime (operatsioonid/sek), 4117,5594747903315

Nagu näete, on teatud tüüpi toiminguid (in selles näites- lugemised), keskmine, minimaalne ja maksimaalne viivitus, viivitus, mille jooksul täideti 95 ja 99% toimingutest, edukate toimingute arv (tagastuskood 0), testimise koguaeg, kõigi toimingute koguarv ja keskmine arv operatsioonide arvu sekundis. Meid huvitab enim keskmine latentsusaeg (AverageLatency) ja toimingute arv sekundis (Throughput).

Teise Pythoni skripti abil koguti hunniku logi andmed tabelisse ja tabelist koostati ilusad graafikud.

järeldused

NoSQL-i andmebaasid jagunevad kahte rühma: kiired ja aeglased. Võtmeväärtuste andmebaas osutus ootuspäraselt kiireks. Aerospike ja Couchbase on konkurentidest kaugel ees.

Aerospike on tõepoolest väga kiire andmebaas. Ja meil õnnestus peaaegu jõuda miljoni toiminguni sekundis (mälus olevatel andmetel). Aerospike töötab üsna hästi ka SSD-del, eriti kui arvestada, et Aerospike selles režiimis ei kasuta andmete vahemällu mällu, vaid pöördub iga päringu peale kettale. See tähendab, et Aerospike'i mahub tõesti suure hulga andmeid (kui on piisavalt kettaid, mitte RAM-i).

Couchbase on kiire, kuid kiire ainult mälutoimingute puhul. SSD testgraafikud näitavad Couchbase'i kiirust vaid veidi suurema andmemahuga kui RAM-i maht – kokku 200 miljonit kirjet. See on märgatavalt vähem kui 500 miljonit, millega teisi andmebaase testiti. Couchbase lihtsalt ei saanud enam kirjeid sisestada, ta keeldus andmevahemälu mälust kettale välja tõstmast ja lõpetas kirjutamise (kirjutamine ebaõnnestus). See on hea vahemälu, kuid ainult andmete jaoks, mis mahuvad RAM-i.

Cassandra on ainuke andmebaas, mis kirjutab kiiremini kui loeb :). Selle põhjuseks on asjaolu, et sellele kirjutamine lõpetatakse edukalt (kõige kiiremas versioonis) kohe pärast logi (kettale) kirjutamist. Kuid lugemine nõuab kontrolli, mitu lugemist kettalt, kõige värskema kirje valimist. Cassandra on usaldusväärne ja üsna kiiresti skaleeritav andmearhiiv.

MongoDB kirjutamine on üsna aeglane, kuid lugemiseks suhteliselt kiire. Kui andmed (või õigemini, nn töökomplekt - jooksvate andmete kogum, millele pidevalt juurde pääseb) ei mahu mällu, aeglustub see oluliselt (ja just see juhtub YCSB testimisel). Samuti peate meeles pidama, et MongoDB-l on globaalne lugemis-/kirjutuslukk, mis võib väga suure koormuse korral probleeme tekitada. Üldiselt on MongoDB veebi jaoks hea andmebaas.

PS

Teeme jõudlusprobleemidest väikese pausi ja vaatame, kuidas SQL ja NoSQL lahendused edasi arenevad. Tegelikult on see, mida me praegu näeme, ühe tuntud loo kordus. See kõik juhtus juba kahekümnenda sajandi kuuekümnendatel ja seitsmekümnendatel: enne relatsiooniandmebaase olid hierarhilised, objekt- ja muud jt. Siis tahtsin standardimist ja ilmus SQL. Ja kõik tõsised DBMS-id, millest igaüks toetas oma päringukeelt ja API-d, lülitusid SQL-ile. Standardiks sai päringukeel ja relatsioonimudel. On uudishimulik, et nüüd püütakse ka SQL-i NoSQL-ile külge pookida, mis viib nii ümbriste loomiseni olemasoleva NoSQL-i peale kui ka täiesti uute andmebaaside loomiseni, mille nimi on NewSQL.

Kui NoSQL otsustas loobuda SQL-i “raskest pärandist”, vaatas ümber lähenemisviisid andmete salvestamisele ja lõi täiesti uusi lahendusi, siis SQL-i “elustamise” liikumise kirjeldamiseks kasutatakse terminit NewSQL. Võttes ideid NoSQL-ist, lõid poisid SQL-i andmebaasid uuel tasemel. Näiteks NewSQL-i maailmast leiab sageli andmebaase, mis salvestavad andmeid mällu, kuid täisväärtuslike SQL-päringute, tabeliühenduste ja muu tuttava asjadega. Selleks, et endiselt palju andmeid salvestada, on nendesse andmebaasidesse sisse ehitatud jagamismehhanismid.

NewSQL sisaldab VoltDB, TokuDB, MemDB jt. Jäta need nimed meelde, võib-olla varsti räägitakse neist ka igal IT-konverentsil.

Andmebaasi testimisteenus aitab minimeerida riske süsteemi kommertskasutusele võtmisel. Saate eelnevalt kontrollida andmebaasi õigsust ja turvalisust.
Andmebaasi testimise käigus kontrollitakse rakenduste andmebaasi töö vastavust funktsionaalsetele ja mittefunktsionaalsetele nõuetele. Rakendused, mille arhitektuur sisaldab andmebaasi, nõuavad andmebaasi testimise protseduuri, näiteks: ettevõtte Infosüsteemid, mobiili- ja veebirakendused.

Andmebaasi jõudlus on haldus- ja ärirakenduste tõhususe oluline tegur. Kui andmete otsimine või kirjutamine on aeglane, väheneb rakenduse võime normaalselt töötada. Ainus viis halva jõudluse põhjuse väljaselgitamiseks on teha kvantitatiivseid mõõtmisi ja teha kindlaks, mis jõudlusprobleemi põhjustab.
Andmebaasi jõudluse kitsaskohtade tuvastamise probleemid on otseselt seotud mõõdikute, jõudluse mõõtmise meetodite ja nende rakendamise tehnoloogiaga. Suurettevõtete ja suurte andmebaaside jaoks on andmebaasi jõudluse määramise probleemil veel üks väga oluline aspekt: IT-infrastruktuuri määramine rakenduste pikaajaliseks tööstuslikuks kasutamiseks. See viib lõppkokkuvõttes riist- ja põhitarkvara alginvesteeringu täpsemini määramiseni. Kuna andmebaaside kõrge jõudlus sõltub tugevalt platvormist ja seadmetest ning neid ostetakse ja käitatakse pikaajaliselt.
Kõige olulisemad mõõdikud andmebaasi jõudluse mõõtmiseks on:

tehingute arv perioodi kohta ( erinevat tüüpi tehingud);
I/O operatsioonide (lugemisridade) arv tehingu kohta ja selle täitmise aeg;
loetud ridade arv tabeli kohta tehingu kohta;
keskmine I/O operatsioonide arv tehingu kohta vahemiku kaupa;
SQL-lausetel on kõrge protsessori aja töökulu (kasutaja, süsteem)
avalduse täitmise algus- ja lõppajad
sortimistoimingute lõpuleviimise aeg (sortide arv, sortimise ületäitumise arv, sortimise lõpetamise aeg), suurim kulunud ajakasutus ja madalaim indeksi kasutamise efektiivsus.

Tabeliruumi lehtede ja puhverkogumite (andmete lugemiseks, indeksite lugemiseks), sortimiseks, utiliitide käitamiseks, kataloogide ja vahemälupakettide mälukasutuse mõõdikud koos jõudluse mõõtmise mõõdikutega on samuti olulised andmetele tõhusa juurdepääsu häälestamiseks.

Mida tuleks veel andmebaasi testides kontrollida?

Andmete kaardistamine

Veenduge, et andmebaasis olevad ühendused vastavad projektdokumentatsioonile. Kõigi CRUD-toimingute puhul veenduge, et vastavaid tabeleid ja kirjeid värskendatakse, kui kasutaja klõpsab rakenduse GUI-s nuppu Salvesta, Värskenda, Otsi või Kustuta.

ACID tehingu omadused

Tehingute ACID-omadused hõlmavad aatomilisust, konsistentsi, isolatsiooni ja tugevust. Andmebaasi testimise ajal peaksite kontrollima neid nelja atribuuti. See valdkond nõuab põhjalikumat testimist, kui andmebaas on hajutatud.

Andmete terviklikkus

Pange tähele, et erinevad rakendusmoodulid (nt ekraanid ja vormid) kasutavad samu andmeid ja teostavad CRUD toiminguid erinevalt. Seetõttu peate tagama, et andmete uusim olek kajastuks kõikjal võrdselt. Süsteem peaks näitama värskendatud väärtusi kõigil vormidel ja ekraanidel. Seda nimetatakse andmete terviklikkuseks.

Äriloogika rakendamise täpsus

Tänapäeval on andmebaasid mõeldud enamaks kui lihtsalt kirjete salvestamiseks. Need on arenenud väga võimsateks tööriistadeks, mis pakuvad arendajatele rohkelt võimalusi äriloogika juurutamiseks andmebaasi tasemel. Võimsate andmebaasifunktsioonide näited on "viiteterviklikkus", relatsioonipiirangud, käivitajad ja salvestatud protseduurid. Seega, kasutades neid ja paljusid muid andmebaasi pakutavaid funktsioone, rakendavad arendajad äriloogikat andmebaasi tasemel. Testija peab veenduma, et rakendatud äriloogika on õige ja töötab täpselt.

Kuidas andmebaasi testida?

SQL päringute kirjutamine

Andmebaasi testimise protsessi korrektseks korraldamiseks peavad testijatel olema head teadmised SQL-ist ja DML-ist (Data Manipulation Language) ning neil peab olema selge arusaam andmebaasi sisemisest struktuurist. See on parim ja usaldusväärseim viis andmebaasi testimiseks, eriti madala ja keskmise keerukusega rakenduste puhul. Kuid kaks kirjeldatud eeltingimust peavad olema täidetud. Kui rakendus on väga keeruline, on testijal raske või isegi võimatu kõiki vajalikke SQL päringuid ise kirjutada. Seetõttu võib testija mõne keeruka päringu korral pöörduda abi saamiseks arendaja poole. See meetod mitte ainult ei anna kindlustunnet, et testimine on hästi tehtud, vaid parandab ka SQL-päringute kirjutamise oskust.

Andmete vaatamine tabelites

Kui testija SQL-i ei tunne, siis saab ta CRUD operatsiooni tulemust kontrollida rakenduse graafilise liidese abil, vaadates andmebaasi tabeleid (seoseid). See andmebaasi kontrollimise meetod nõuab häid teadmisi tabeli struktuurist ning võib olla veidi tüütu ja tülikas, eriti kui andmebaasis ja tabelites on palju andmeid. See andmebaasi kontrollimise meetod võib testijatele olla keeruline, kui testiandmed asuvad mitmes tabelis.

Arendaja abi

Tester teostab GUI-s kõik CRUD-operatsioonid ja kontrollib nende tulemusi, käivitades vastavad arendaja kirjutatud SQL-päringud. See meetod ei eelda ei häid SQL-i ega rakenduste andmebaasi struktuuri tundmist.Meetod tundub lihtne ja hea valik andmebaasi testimiseks. Kuid selle negatiivne külg on kaos. Mis saab siis, kui arendaja kirjutatud päring on semantiliselt vale või ei vasta õigesti kasutaja nõuetele? Sellisel juhul ei anna testimine toote kvaliteedile mingit garantiid.

Näide andmebaasi andmete terviklikkuse testimise metoodikast

Andmebaase ja andmebaasiprotsesse tuleks testida iseseisva alamsüsteemina. Sel juhul tuleb testida kõiki alamsüsteeme, millel puudub sihtkasutajaliides andmete liidesena. Andmebaasihaldussüsteemis (DBMS) tuleks teha täiendavaid uuringuid, et määrata kindlaks tööriistad ja tehnikad, mis toetavad järgmises tabelis määratletud testimist.

Metoodika eesmärgid	Andmebaasile juurdepääsu meetodite ja kasutajaliidest sõltumatute protsesside testimine, et saaks jälgida ja salvestada rikkis sihtalgoritme või andmete riknemist.
Metoodika	Kutsuge iga andmebaasi juurdepääsu meetodit või protsessi, täites igaüks kehtivate ja kehtetute andmete või andmepäringutega. Andmebaasi valideerimine tagamaks, et andmed on õigesti täidetud ja kõik andmebaasisündmused toimuvad ootuspäraselt, või tagastatud andmete valideerimine tagamaks, et vajaduse korral leitakse õiged andmed.
Oraaklid(heuristiline mehhanism, mis aitab probleemi tuvastada)	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist Pildistamise ja algtaseme taastamise tööriist Varundamise ja taastamise tööriistad Installimise jälgimise tööriistad (register, HDD, CPU, mälu ja nii edasi) SQL-i andmebaasi utiliidid ja tööriistad Andmete genereerimise tööriistad
Edu kriteeriumid	See meetod toetab kõigi peamiste andmebaasi juurdepääsu meetodite ja protsesside testimist.
Erilineteavet	Testimine võib nõuda DBMS-i arenduskeskkonda või draivereid andmete otse andmebaasi sisestamiseks või muutmiseks. Protsessid tuleb kutsuda käsitsi. Väikesed andmebaasid või andmebaasid minimaalne suurus(piiratud arvu kirjetega) tuleks kasutada kõigi rikutud sündmuste ulatuse laiendamiseks.

Rizwan Jafri artikli tõlge

Tänapäeval on andmebaas rakenduse üks vältimatuid osi. Kui rakendus on käivitatud, kasutab lõppkasutaja peamiselt CRUD operatsioonid mida pakub andmebaasi tööriist.

C: Loo(Loo) – toiming "Loo" tehakse siis, kui kasutaja salvestab uue tehingu.
R: Otsi(Retrieve) – 'Retrieve' toiming tehakse siis, kui kasutaja otsib või vaatab mis tahes salvestatud tehingut.
U: Värskenda(Uuenda) – 'Uuenda' toiming tehakse siis, kui kasutaja redigeerib või muudab olemasolevat kirjet.
D: Kustuta(Kustuta) – 'Kustuta' toiming tehakse siis, kui kasutaja kustutab süsteemist mis tahes kirje.

Pole tähtis, millist andmebaasi kasutatakse ja kuidas toiming varem sooritati (liitumine või alampäring, käivitamine või salvestatud protseduur, päring või funktsioon). Huvitav on see, et kõik andmebaasitoimingud, mida kasutaja teeb mis tahes rakenduse kasutajaliidesest, on üks neist neljast CRUD-i toimingust.

Mida andmebaasi testimisel kontrollida?

1) Andmete kaardistamine:
Veenduge, et andmebaasis olevad ühendused vastavad projektdokumentatsioonile. Kõigi CRUD-toimingute puhul veenduge, et vastavaid tabeleid ja kirjeid värskendatakse, kui kasutaja klõpsab rakenduse GUI-s nuppu Salvesta, Värskenda, Otsi või Kustuta.

2) ACID tehingu omadused:
Tehingute ACID omadused hõlmavad aatomilisus, järeljada, isolatsioon Ja tugevus. Andmebaasi testimise ajal peaksite kontrollima neid nelja atribuuti. See valdkond nõuab põhjalikumat testimist, kui andmebaas on hajutatud.

3) Andmete terviklikkus:
Pange tähele, et erinevad rakendusmoodulid (nt ekraanid ja vormid) kasutavad samu andmeid ja teostavad CRUD toiminguid erinevalt. Seetõttu peate tagama, et andmete uusim olek kajastuks kõikjal võrdselt. Süsteem peaks näitama värskendatud väärtusi kõigil vormidel ja ekraanidel. Seda nimetatakse andmete terviklikkuseks.

4) Ärireeglite rakendamise täpsus:
Tänapäeval on andmebaasid mõeldud enamaks kui lihtsalt kirjete salvestamiseks. Need on arenenud väga võimsateks tööriistadeks, mis pakuvad arendajatele rohkelt võimalusi äriloogika juurutamiseks andmebaasi tasemel. Võimsate andmebaasifunktsioonide näited on "viiteterviklikkus", relatsioonipiirangud, käivitajad ja salvestatud protseduurid. Seega, kasutades neid ja paljusid muid andmebaasi pakutavaid funktsioone, rakendavad arendajad äriloogikat andmebaasi tasemel. Testija peab veenduma, et rakendatud äriloogika on õige ja töötab täpselt.

Ülalkirjeldatud punktid on andmebaasi testimise kõige olulisemad aspektid. Andmebaasi testimine on kriitiline äriülesanne ja seda ei tohiks kunagi jätta kogenematute töötajate hooleks ilma korraliku väljaõppeta.

Kuidas andmebaasi testida?

1. SQL päringute kirjutamine
Andmebaasi korrektseks ja täpseks kontrollimiseks peavad testijal olema ennekõike väga head teadmised SQL-ist ja DML-ist (Data Manipulation Language). Teiseks peab testijal olema hea arusaam andmebaasi sisemisest struktuurist. Kui need kaks eeldust on täidetud, siis on töötaja valmis andmebaasi testima. Ta teostab rakenduse kasutajaliidesest kõik CRUD-toimingud ja kontrollib seejärel SQL-päringute abil täitmistulemusi.
See on parim ja usaldusväärseim viis andmebaasi testimiseks, eriti madala ja keskmise keerukusega rakenduste puhul. Kuid kaks kirjeldatud eeltingimust peavad olema täidetud. Vastasel juhul see andmebaasi testimise meetod teie jaoks ei tööta.
Kui rakendus on väga keeruline, on testijal raske või isegi võimatu kõiki vajalikke SQL päringuid ise kirjutada. Seetõttu võib testija mõne keeruka päringu korral pöörduda abi saamiseks arendaja poole.
See meetod mitte ainult ei anna kindlustunnet, et testimine on hästi tehtud, vaid parandab ka SQL-päringute kirjutamise oskust.

2. Andmete vaatamine tabelites
Kui testija SQL-i ei tunne, siis saab ta CRUD operatsiooni tulemust kontrollida rakenduse graafilise liidese abil, vaadates andmebaasi tabeleid (seoseid). See andmebaasi kontrollimise meetod nõuab häid teadmisi tabeli struktuurist ning võib olla veidi tüütu ja tülikas, eriti kui andmebaasis ja tabelites on palju andmeid.
Lisaks võib selline andmebaasi kontrollimise viis olla testijatele väga keeruline, kui kontrollitavad andmed on mitmes tabelis.

3. Arendaja abi
See on kõige lihtsam viis. Tester teostab GUI-s kõik CRUD-operatsioonid ja kontrollib nende tulemusi, käivitades vastavad arendaja kirjutatud SQL-päringud. See meetod ei nõua häid SQL-i ega rakenduste andmebaasi struktuuri tundmist.
Nii et see meetod tundub lihtne ja hea valik DB testimiseks. Kuid selle negatiivne külg on kaos. Mis saab siis, kui arendaja kirjutatud päring on semantiliselt vale või ei vasta õigesti kasutaja nõuetele? Sellisel juhul ei anna testimine toote kvaliteedile mingit garantiid.

Järeldus

Andmebaas on peaaegu iga rakenduse peamine ja kõige olulisem osa. Seega nõuab andmebaasi testimine suurt tähelepanu, head SQL päringute kirjutamise oskust, andmebaasi struktuuri tundmist ja vastavat ettevalmistust.

Et olla kindel, et testimine on tõhus, tuleb see määrata inimesele, kellel on kõik need neli omadust. Vastasel juhul ilmneb pärast toote kohaletoimetamist suure tõenäosusega rakenduse ebaõige või tahtmatu käitumine, vead, mille klient leiab.

Metoodika eesmärgid:	Andmebaasile juurdepääsu meetodite ja kasutajaliidest sõltumatute protsesside testimine, et saaks jälgida ja salvestada rikkis sihtalgoritme või andmete riknemist.
Metoodika:	Kutsuge iga andmebaasi juurdepääsu meetodit või protsessi, täites igaüks kehtivate ja kehtetute andmete või andmepäringutega. Andmebaasi valideerimine tagamaks, et andmed on õigesti täidetud ja kõik andmebaasisündmused toimuvad ootuspäraselt, või tagastatud andmete valideerimine tagamaks, et vajaduse korral leitakse õiged andmed.
Oraaklid:
Vajalikud tööriistad:	SQL-i andmebaasi utiliidid ja tööriistad andmete genereerimise tööriistad
Edu kriteeriumid:	See meetod toetab kõigi peamiste andmebaasi juurdepääsu meetodite ja protsesside testimist.
Eriinfo:	Testimine võib nõuda DBMS-i arenduskeskkonda või draivereid andmete otse andmebaasi sisestamiseks või muutmiseks. Protsessid tuleb kutsuda käsitsi. Kõigi rikutud sündmuste ulatuse laiendamiseks tuleks kasutada väikeseid või minimaalse suurusega andmebaase (piiratud kirjete arvuga).

Funktsioonide testimine

Testimise sihtfunktsioonide testimine peaks keskenduma nõuetele, mida saab otseselt jälgida kasutusjuhtudel või äriprotsesside funktsioonidel ja reeglitel. Nende testide eesmärk on kontrollida andmete õiget vastuvõtmist, töötlemist ja tagastamist, samuti äriprotsessireeglite asjakohast rakendamist. Seda tüüpi testimine põhineb musta kasti tehnikatel, mis tähendab, et rakenduse ja selle sisemiste protsesside testimine toimub rakendusega suhtlemisel graafilise kasutajaliidese (GUI) abil ja leidude või tulemuste analüüsimisega. Järgmine tabel määratleb iga rakenduse jaoks soovitatava testimise raamistiku.

Metoodika eesmärgid:	Testige testimisobjekti funktsionaalsust, sealhulgas navigeerimist, sisestamist, andmete töötlemist ja tagastamist, et jälgida ja salvestada sihtalgoritmi.
Metoodika:	Testi niite või funktsioone ja funktsionaalsus iga kasutusjuhtumi stsenaariumi jaoks eraldi kasutusjuhud, kasutades kehtivaid ja kehtetuid andmeid, et kontrollida, et: kehtivate andmete kasutamisel saadakse oodatud tulemused Kui kasutatakse kehtetuid andmeid, kuvatakse vastavad vea- või hoiatusteated kõiki äriprotsesside reegleid rakendatakse vastavalt
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist piltide loomise ja baasi taastamise tööriist varundus- ja taastetööriistad installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne) andmete genereerimise tööriistad
Edu kriteeriumid:	kõik peamised kasutusjuhtumid kõik põhifunktsioonid
Eriinfo:	Tuvastage või kirjeldage neid elemente või probleeme (sisemised või välised), mis mõjutavad funktsioonitesti rakendamist ja toimivust.

Äriprotsesside tsükli testimine

Äriprotsesside tsükli testimine peaks jäljendama aja jooksul tehtud ülesandeid<Имя проекта>. Peaksite määratlema perioodi, näiteks ühe aasta, ning tegema aasta jooksul toimuvaid tehinguid ja ülesandeid. See hõlmab kõiki päeva-, nädala- ja kuutsükleid, aga ka kuupäevapõhiseid sündmusi.

Metoodika eesmärgid:	Testige sihtmärkprotsesse ja taustprotsesse vastavalt nõutavatele äriprotsesside mudelitele ja plaanidele sihtalgoritmi jälgimiseks ja salvestamiseks.
Metoodika:	Testimine simuleerib äriprotsessi mitut tsüklit, tehes järgmist. Testi sihtmärgi funktsioonide testimiseks kasutatavaid teste muudetakse või laiendatakse, et suurendada iga funktsiooni käivitamiskordade arvu, et simuleerida mitut erinevat kasutajat teatud aja jooksul. Kõik kuupäevast või kellaajast sõltuvad funktsioonid täidetakse kehtivate ja kehtetute kuupäevade ja punktidega. Kõik perioodiliselt käivitatavad funktsioonid käivitatakse või käivitatakse sobival ajal. Testimisel kasutatakse kehtivaid ja kehtetuid andmeid, et testida järgmist. Kui kasutatakse kehtivaid andmeid, saadakse oodatud tulemused. Kui kasutatakse kehtetuid andmeid, kuvatakse vastavad vea- või hoiatusteated. Kõiki äriprotsesside reegleid rakendatakse vastavalt.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist piltide loomise ja baasi taastamise tööriist varundus- ja taastetööriistad andmete genereerimise tööriistad
Edu kriteeriumid:	See tehnika toetab kõigi kriitiliste äriprotsesside tsüklite testimist.
Eriinfo:	Süsteemi kuupäevad ja sündmused võivad vajada spetsiaalseid tugiülesandeid. Asjakohaste nõuete ja testimisprotseduuride tuvastamiseks on vaja äriprotsessi mudelit.

Kasutajaliidese testimine

Kasutajaliidese (UI) testimine testib kasutaja suhtlemist tarkvaraga. Kasutajaliidese testimise eesmärk on tagada, et kasutajaliides annaks kasutajale sobiva juurdepääsu ja navigeerimise testimise sihtmärgi funktsioonidele. Kasutajaliidese testimine aitab ka tagada, et kasutajaliideses olevad objektid toimivad ootuspäraselt ja vastavad ettevõtte või valdkonna standarditele.

Metoodika eesmärgid:	Testige järgmist, et jälgida ja registreerida vastavust standarditele ja sihtalgoritmile. Testi sihtmärgil navigeerimine, mis kajastab äriprotsessi funktsioone ja nõudeid, sealhulgas akna-akna, välja-välja meetodid ja juurdepääsumeetodite kasutamine (tab-klahvid, hiireliigutused, kiirklahvid). Saate testida aknaobjekte ja omadusi, nagu menüüd, suurus, paigutus, olek ja fookus.
Metoodika:	Looge või muutke aknapõhiseid teste, et kontrollida iga rakenduse akna ja objekti õiget navigeerimis- ja objektiolekut.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab testskripti automatiseerimise tööriista.
Edu kriteeriumid:	See tehnika toetab iga avakuva või akna testimist, mida kasutajad laialdaselt kasutavad.
Eriinfo:	Kõikidele kohandatud objektide ja kolmanda osapoole objektide atribuutidele ei pääse juurde.

Toimivuse profileerimine

Toimivuse profileerimine on jõudlustest, mis mõõdab ja hindab reageerimisaegu, tehingukiirusi ja muid ajatundlikke nõudeid. Toimivusprofiilide koostamise eesmärk on kontrollida, kas jõudlusnõuded on täidetud. Jõudlusprofiilide koostamine rakendatakse ja teostatakse testi sihtmärgi jõudlusalgoritmide profileerimiseks ja täpsustamiseks sõltuvalt sellistest tingimustest nagu töökoormus või riistvara konfiguratsioon.

Märge: Järgmises tabelis loetletud tehingud on klassifitseeritud "loogiliste äriprotsesside tehinguteks". Need tehingud on määratletud kui konkreetsed kasutusjuhtumid, mida (majandus)üksus peaks katseeesmärki kasutades täitma, näiteks konkreetse lepingu lisamine või muutmine.

Metoodika eesmärgid:	Määratud funktsionaalsete tehingute või äriprotsesside funktsioonide testimise algoritme järgmistel tingimustel, et jälgida ja salvestada sihtalgoritmi ja rakenduse jõudlusandmeid:
Metoodika:	Rakendage testimisprotseduure, mis on loodud äriprotsesside funktsioonide ja tsüklite testimiseks. Andmefailide muutmine tehingute või skriptide arvu suurendamiseks, et suurendada iga tehingu iteratsioonide arvu. Skripte tuleks käivitada samas süsteemis ( parim variant- alustage ühe kasutajaga, ühe tehinguga) ja korrake mitme kliendiga (virtuaalne või tegelik, vaadake täpsemat teavet allpool).
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist rakenduse jõudluse profileerimise tööriist, näiteks Rational Quantify installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne)
Edu kriteeriumid:	See tehnika toetab testimist: Üks tehing või üks kasutaja: saate edukalt jäljendada tehingustsenaariume, ilma et see tekiks testi rakendamise probleemide tõttu. Mitu tehingut või mitu kasutajat: emuleerige töökoormust edukalt, ilma et see tekiks testi rakendamise probleemide tõttu.
Eriinfo:	Põhjalik jõudlustestimine hõlmab serveri taustakoormust. Kasutada saab mitmeid meetodeid, sealhulgas järgmised: "Tehingute edastamine" otse serverisse, tavaliselt struktureeritud päringukeele (SQL) kõnede kujul. "Virtuaalse" kasutajakoormuse loomine, et simuleerida mitut klienti, tavaliselt mitusada. Selle koormuse saavutamiseks kasutatakse kaugterminali emuleerimise tööriistu. Seda tehnikat saab kasutada ka võrgu üleujutamiseks "andmevooga". Süsteemi koormuse loomiseks kasutage mitut füüsilist klienti, millest igaüks käivitab testskripte. Toimivuse testimine tuleks läbi viia spetsiaalses süsteemis või määratud ajal. See tagab täieliku kontrolli ja täpsed mõõtmised. Jõudluse testimiseks kasutatavad andmebaasid peavad olema kas tegeliku suurusega või võrdselt skaleeritud.

Koormustestimine

Koormustestimine on jõudlustestimine, mille käigus testitavale objektile rakendatakse erinevaid töökoormusi, et mõõta ja hinnata jõudlusalgoritme ning testi sihtmärgi võimet jätkata sobivat toimimist erinevate töökoormuste korral. Koormustestimise eesmärk on kindlaks teha ja tagada, et süsteem töötab õigesti, kui sellele allutatakse eeldatavale maksimaalsele töökoormusele. Koormustestimine hindab ka jõudlusparameetreid, nagu reaktsiooniaeg, tehingu kiirus ja muud ajaga seotud parameetrid.

Märge: Järgmises tabelis loetletud tehingud on klassifitseeritud "loogiliste äriprotsesside tehinguteks". Need tehingud on määratletud kui konkreetsed funktsioonid, mida kasutajalt oodatakse rakenduse kasutamise ajal, näiteks antud lepingu lisamine või muutmine.

Metoodika eesmärgid:	Teostage määratud tehinguid või äriprotsesside variatsioone erineva töökoormuse tingimustes, et jälgida ja salvestada sihtalgoritmi ja süsteemi jõudlusandmeid.
Metoodika:	Kasutage tehingutesti skripte, mis on loodud äriprotsesside funktsionaalsuse ja tsüklite testimiseks, kuid eemaldage mittevajalikud iteratsioonid ja viivitused. Andmefailide muutmine tehingute arvu suurendamiseks või testid, et suurendada iga tehingu sooritamise kordade arvu. Töökoormused peaksid hõlmama näiteks igapäevast, iganädalast ja igakuist tippkoormust. Töökoormused peaksid esindama nii keskmist kui ka tippkoormust. Töökoormused peavad esindama nii hetkelisi kui ka pikaajalisi tippkoormusi. Töökoormusi tuleks testida erinevates testkeskkonna konfiguratsioonides.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne) ressursse piiravad vahendid; näiteks Canned Heat andmete genereerimise tööriistad
Edu kriteeriumid:	See meetod toetab töökoormuse emulatsiooni testimist, mis on töökoormuse edukas emuleerimine ilma testi rakendamise probleemidest tingitud tõrgeteta.
Eriinfo:	Koormustest tuleks läbi viia spetsiaalses süsteemis või määratud ajal. See tagab täieliku kontrolli ja täpsed mõõtmised. Koormustestimiseks kasutatavad andmebaasid peavad olema kas tegeliku suurusega või võrdselt skaleeritud.

Pinge testimine

Stressitestimine on teatud tüüpi jõudlustest, mida rakendatakse ja viiakse läbi selleks, et mõista, kuidas süsteem ebaõnnestub tingimustes, mis vastavad eeldatavatele tolerantidele või sellest väljaspool. Tavaliselt kaasneb sellega ressursside nappus või konkurents ressursside pärast. Madala ressursi tingimused näitavad, kuidas testi eesmärk ebaõnnestub viisil, mis tavatingimustes pole ilmne. Jagatud ressursside vaidlusest võivad tuleneda muud vead, näiteks andmebaasi lukud või võrgu ribalaius, kuigi mõnda neist testidest tehakse tavaliselt funktsioonide ja koormuse testimisel.

Metoodika eesmärgid:	Katsetage katseobjekti funktsioone järgmistel pingetingimustel, et jälgida ja registreerida sihtalgoritmi, mis tuvastab ja dokumenteerib tingimused, mille korral ebaõnnestumine süsteem, et vastavalt sellele edasi toimida: väike mälumaht või vaba mälu puudumine serveris (RAM ja püsimälu) maksimaalne füüsiliselt või tegelikult võimalik ühendatud või simuleeritud kasutajate arv mitu kasutajat teevad samu tehinguid samade andmete või kontodega "liigne" tehingumaht või tingimuste kombinatsioon (vt toimivuse profiilide jaotist ülal)
Metoodika:	Piiratud ressursside testimiseks tuleks testid läbi viia ühes süsteemis ning RAM-i ja püsimälu serveris tuleks vähendada või piirata. Muude pingetestide jaoks tuleks kasutada mitut klienti, kes teevad samu või täiendavaid teste, et luua halvima tehingumaht või mõlema kombinatsioon.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist tehingukoormuse planeerimise ja haldamise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne) ressursse piiravad vahendid; näiteks Canned Heat andmete genereerimise tööriistad
Edu kriteeriumid:	See tehnika toetab pinge emulatsiooni testimist. Süsteemi saab edukalt emuleerida ühel või mitmel tingimusel, mis on määratletud stressitingimustena, ja süsteemi tulemuseks oleva oleku vaatlusi saab salvestada nii tingimuse emuleerimise ajal kui ka pärast seda.
Eriinfo:	Võrgu pinge tekitamiseks võib olla vaja võrgutööriistu, mis laadivad võrku sõnumite ja pakettidega. Süsteemi jaoks kasutatavat püsimälu tuleks ajutiselt vähendada, et piirata andmebaasi kasvu jaoks saadaolevat ruumi. Peaksite sünkroonima klientide samaaegse juurdepääsu samadele andmekirjetele või kontodele.

Võimsuse testimine

Võimsuse testimine paljastab testi sihtmärgile suure andmemahu, et teha kindlaks, kas on saavutatud piirid, mis põhjustavad süsteemi rikke. Võimsuse testimine määrab ka pideva maksimaalse koormuse või võimsuse, mida testitav sihtmärk saab teatud aja jooksul sõita. Näiteks kui testi sihtmärk töötleb aruande loomiseks andmebaasikirjete komplekti, kasutab läbilaskevõime test suurt testandmebaasi ja kontrollib, et tarkvara töötab hästi ja koostab õige aruande.

Metoodika eesmärgid:	Sihtmärgi algoritmi jälgimiseks ja salvestamiseks testige testitava sihtmärgi funktsionaalsust järgmiste suure võimsusega stsenaariumide järgi. Maksimaalne (tegelik või füüsiliselt võimalik) ühendatud või simuleeritud klientide arv, kes täidavad pika perioodi jooksul sama (toimivuse poolest halvimat) äriprotsessi funktsiooni. Andmebaasi maksimaalne suurus (tegelik või ulatus) on saavutatud ja samaaegselt töötab mitu päringut või aruandlustehingut.
Metoodika:	Kasutage jõudluse profileerimiseks või koormuse testimiseks mõeldud teste. Mitut klienti tuleks kasutada samade või täiendavate testide tegemisel, et luua pikema perioodi jooksul halvim tehingumaht või nende kombinatsioon (vt stressitestimine). Andmebaasi maksimaalne suurus (tegelik, skaleeritud või representatiivsete andmetega täidetud) luuakse ja päringute ja aruandlustoimingute käitamiseks pikema perioodi jooksul kasutatakse samaaegselt mitut klienti.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist tehingukoormuse planeerimise ja haldamise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne) ressursse piiravad vahendid; näiteks Canned Heat andmete genereerimise tööriistad
Edu kriteeriumid:	See tehnika toetab võimsuse emulatsiooni testimist. Suurt hulka kasutajaid, andmeid, tehinguid või muid süsteemikasutuse aspekte saab edukalt emuleerida ja jälgida süsteemi oleku muutusi läbi võimsustesti.
Eriinfo:

Turvalisuse ja juurdepääsu kontrolli testimine

Turvalisuse ja juurdepääsu kontrolli testimine keskendub kahele peamisele turbevaldkonnale:

Rakenduse tasemel kaitse, sealhulgas juurdepääs andmetele või äriprotsessi funktsioonidele

Süsteemitaseme turvalisus, sealhulgas sisselogimine või kaugjuurdepääs süsteemile

Nõutavast kaitsetasemest lähtuvalt tagab rakendustaseme kaitse, et subjektidel on juurdepääs ainult teatud funktsioonidele või kasutusjuhtudele või et neile kättesaadavad andmed on piiratud. Näiteks andmete sisestamist ja uute kontode loomist saab lubada kõigile, kustutamist aga ainult halduritele. Andmetaseme turvalisuse korral tagab testimine, et 1. tüüpi kasutajal on juurdepääs kogu klienditeabele, sealhulgas finantsandmetele, samas kui 2. tüüpi kasutajal on juurdepääs ainult sama kliendi demograafilistele andmetele.

Süsteemitaseme turvalisus tagab, et rakendustele on juurdepääs ainult süsteemi õigustega kasutajatel ja ainult vastavate lüüside kaudu.

Metoodika eesmärgid:	Sihtmärgi algoritmi jälgimiseks ja salvestamiseks testige testimise sihtmärki järgmistel tingimustel: Rakendustaseme kaitse: subjektil on juurdepääs ainult nendele funktsioonidele ja andmetele, millele seda tüüpi kasutajal on juurdepääsuõigused. Süsteemitaseme turvalisus: juurdepääs rakendustele on piiratud neile, kellel on süsteemi ja rakenduse õigused.
Metoodika:	Rakenduse tasemel turvalisus: määrake ja loetlege kõik kasutajatüübid ning funktsioonid ja andmed, millele igat tüüpi kasutajal on juurdepääs. Looge iga kasutajatüübi jaoks testid ja kontrollige kõiki juurdepääsuõigusi, luues iga kasutajatüübi jaoks määratletud tehingud. Kasutajatüübi muutmine ja samade kasutajate testide uuesti käivitamine. Igal juhul kontrollige, kas juurdepääs lisafunktsioonidele või andmetele on õigesti lubatud või keelatud. Juurdepääs süsteemi tasemele: vaadake eriteavet allpool.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: Test skripti automatiseerimise tööriist "Häkkeri" tööriistad testimiseks ja turvaaukude leidmiseks OS-i turbehaldustööriistad
Edu kriteeriumid:	See metoodika toetab iga teadaoleva kasutajatüübi asjakohaste funktsioonide ja andmete testimist, mida turbesätted mõjutavad.
Eriinfo:	Juurdepääs süsteemile tuleb kontrollida ja arutada asjakohaste süsteemi- või võrguadministraatoritega. See testimine ei pruugi olla vajalik, kuna see võib olla osa võrgu- või süsteemihaldusfunktsioonidest.

Katastroofitaaste testimine

Avariitaaste testimine kinnitab, et testi sihtmärki saab edukalt taastada mitmesuguste riistvara-, tarkvara- ja võrgutõrgete korral ulatusliku andmekao või andmete terviklikkuse korral.

Süsteemide puhul, mis peavad jätkama töötamist, tagab avariitaastetest, et tõrkest taastumise korral võtavad alternatiivsed või varusüsteemid õigesti üle ebaõnnestunud süsteemi jaoks ilma andmeid või tehinguid kaotamata.

Taastetest on antagonistlik testimisprotsess, mille käigus rakendus või süsteem puutub kokku ekstreemsete või simuleeritud tingimustega, mis põhjustavad tõrkeid, näiteks seadme sisend-/väljundtõrkeid või kehtetuid andmebaasi viiteid ja võtmeid. Taasteprotsessid käivitatakse ning rakendust või süsteemi jälgitakse ja juhitakse, et kontrollida, kas rakenduse või süsteemi ja andmete nõuetekohane taastamine on saavutatud.

Metoodika eesmärgid:	Simuleerige tõrketingimusi ja testige andmebaasi, rakenduste ja süsteemi taastamisprotsesse (käsitsi ja automaatseid) soovitud teadaolevasse olekusse. Toimimisalgoritmi jälgimiseks ja salvestamiseks pärast taastumist on testimisel kaasatud järgmist tüüpi tingimused: voolukatkestus kliendisüsteemis voolukatkestus serverisüsteemis ühenduse katkemine võrguserverite kaudu katkes ühendus või DASD (otsemälu juurdepääsu seadmed) ja DASD kontrollerite toitekadu mittetäielikud tsüklid (andmete filtreerimisprotsesside katkemine, andmete sünkroonimisprotsesside katkemine) kehtetuid viiteid ja andmebaasivõtmeid vigased või rikutud andmeüksused andmebaasis
Metoodika:	Saate kasutada juba loodud teste äriprotsesside funktsionaalsuse ja tsüklite testimiseks taastetestimise toetamiseks tehingute seeria loomisel. Esimene samm on tuvastada taastumise edukuse testid. Toitekatkestus klientsüsteemis: lülitage arvuti välja. Serverisüsteemi toitekatkestus: simuleerib või käivitab serveri väljalülitusprotseduurid. Katkestamine võrguserverite kaudu: simuleerib või algatab võrguühenduse katkemise (ühendusjuhtmete füüsiline lahtiühendamine või võrguserverite või ruuterite toite väljalülitamine). DASD-de ja DASD-kontrollerite ühenduse katkemine või toitekadu: ühe või mitme DASD- või DASD-kontrolleriga ühenduse simuleerimine või füüsiline katkemine. Kui ülaltoodud või simuleeritud tingimused on saavutatud, tuleks sooritada täiendavaid tehinguid ja käivitada taastamisprotseduurid, kui see teine katseetapp on saavutatud. Mittetäielike tsüklite testimisel kasutatakse sama metoodikat, mis eespool kirjeldatud, välja arvatud see, et andmebaasi protsessid ise tuleb enneaegselt katkestada või lõpetada. Järgmiste tingimuste testimine nõuab teadaoleva andmebaasi oleku saavutamist. Mitu andmebaasivälja, viiteid ja võtmeid tuleb käsitsi ja otse andmebaasis rikkuda (kasutades andmebaasi tööriistu). Täiendavad tehingud tuleks teha, kasutades rakenduse funktsioonide testimise ja äriprotsesside tsüklite ning täielikult lõpetatud tsüklite teste.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: piltide loomise ja baasi taastamise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne) varundus- ja taastetööriistad
Edu kriteeriumid:	See tehnika toetab testimist: Üks või mitu simuleeritud tõrget, mis hõlmavad ühte või mitut rakenduste, andmebaasi ja süsteemi kombinatsiooni. Üks või mitu simuleeritud taastamist, mis hõlmavad ühte või mitut rakenduste, andmebaasi ja süsteemi kombinatsiooni teadaolevasse soovitud olekusse.
Eriinfo:	Taastetestimine on suures osas pealetükkiv. Elektrikaablite lahtiühendamise protseduurid (toite- või ühenduse katkemise simuleerimisel) ei pruugi olla soovitavad või teostatavad. Vaja võib olla alternatiivseid meetodeid, näiteks diagnostikatarkvara tööriistu. Nõuab ressursse süsteemidelt (või arvutitoimingutelt), andmebaasidelt ja võrgurühmadelt. Need testid tuleks läbi viia väljaspool tavapärast tööaega või isoleeritud süsteemis.

Konfiguratsiooni testimine

Konfiguratsiooni testimine kontrollib testi sihtmärgi jõudlust erinevate riist- ja tarkvarakonfiguratsioonide korral. Enamikus töökeskkondades võivad kliendi tööjaamade, võrguühenduste ja andmebaasiserverite spetsiifilised riistvaraspetsifikatsioonid erineda. Klienditööjaamadesse võib olla laaditud erinev tarkvara (nt rakendused, draiverid ja nii edasi) ning korraga võivad olla aktiivsed mitmed erinevad tarkvarakombinatsioonid, kasutades erinevaid ressursse.

Metoodika eesmärgid:	Kontrollib testi sihtmärki nõutavates riist- ja tarkvarakonfiguratsioonides, et jälgida ja salvestada sihtalgoritmi erinevates konfiguratsioonides ning määrata konfiguratsiooni oleku erinevusi.
Metoodika:	Funktsioonitestide rakendamine. Mitmesuguse mittetestiga seotud tarkvara, näiteks Microsoft® Excel® ja Microsoft® Word® rakenduste avamine ja sulgemine kas testi osana või enne testi käivitamist. Käivitage valitud tehingud, et simuleerida üksusi, mis suhtlevad testsihtmärgi ja mittetestitava sihttarkvaraga. Korrake ülaltoodud protsessi, minimeerides kliendi tööjaama saadaoleva põhimälu.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: piltide loomise ja baasi taastamise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne)
Edu kriteeriumid:	See tehnika toetab ühe või mitme testi sihtelemendi kombinatsiooni testimist, mis käivitatakse eeldatavates toetatud arenduskeskkondades.
Eriinfo:	Milline mittesihttarkvara on vajalik, saadaval ja juurdepääsetav töölaual? Milliseid rakendusi tavaliselt kasutatakse? Millistel andmetel rakendused töötavad? näiteks Excelis avatud suur tabel või Wordis 100-leheküljeline dokument? Selle testi osana peaksite dokumenteerima ka võrgu, võrguserverid ja süsteemi andmebaasid üldiselt.

Paigalduse testimine

Installatsiooni testimisel on kaks eesmärki. Esimene on veenduda, et tarkvara saab installida (nt uus paigaldus, värskendamine ja täielik või kohandatud installimine) erinevatel standardsetel ja mittestandardsetel tingimustel. Ebatavalised tingimused hõlmavad ebapiisavat kettaruumi, ebapiisavaid õigusi kataloogide loomiseks ja nii edasi. Teine eesmärk on kontrollida, kas tarkvara töötab pärast installimist õigesti. Tavaliselt saavutatakse see funktsionaalsuse testimiseks mõeldud testide seeria käivitamisega.

Metoodika eesmärgid:	Installimise käitumise ja konfiguratsiooni oleku muutuste jälgimiseks ja registreerimiseks tehke iga nõutava riistvarakonfiguratsiooni jaoks testsihtinstallimine järgmistel tingimustel. uus install: uus süsteem, mida pole kunagi varem installitud<Имя проекта> värskendus: süsteem, kuhu see varem installiti<Имя проекта>, sama versioon versiooniuuendus: süsteem, kuhu see varem installiti<Имя проекта>, varasem versioon
Metoodika:	Sihtsüsteemi tingimuste testimiseks töötage välja automaatsed või käsitsi skriptid. uus:<имя проекта>pole kunagi installitud <имя проекта>sama või varasem versioon on juba installitud Alustage või lõpetage installimine. Funktsioonide testimise stsenaariumide etteantud alamhulga rakendamine, tehingute täitmine.
Oraaklid:	Kirjeldage ühte või mitut strateegiat, mida saab testitulemuste korrektseks jälgimiseks kasutada. Oraakel ühendab endas nii vaatlusmeetodi elemendid kui ka konkreetse tulemuse omadused, mis viitavad võimalikule edule või ebaõnnestumisele. Ideaalis teostavad oraaklid enesekontrolli, võimaldades automaattestide abil esialgset edu või ebaõnnestumist hinnata. Siiski peaksite olema teadlik tulemuste automaatse määramisega seotud riskidest.
Vajalikud tööriistad:	See tehnika nõuab järgmisi tööriistu: piltide loomise ja baasi taastamise tööriist installimise jälgimise tööriistad (register, kõvaketas, protsessor, mälu jne)
Edu kriteeriumid:	See meetod toetab arendatud toote installimise testimist ühes või mitmes installikonfiguratsioonis.
Eriinfo:	Millised tehingud<имя проекта>tuleks valida, et pakkuda rakendusele usaldusväärset testi<имя проекта>installimine õnnestus ja ükski oluline tarkvarakomponent ei puudunud?