Testiranje baze podataka. Testiranje opterećenja baze podataka. Razumijevanje skupova podataka i tablica podataka

: Kako testirati i ispravljati pogreške u bazama podataka

Automatsko jedinično testiranje koda aplikacije jednostavno je i izravno. Kako testirati bazu podataka? Ili aplikacija koja radi s bazom podataka. Uostalom, baza podataka nije samo programski kod, baza podataka je objekt koji čuva svoje stanje. A ako počnemo mijenjati podatke u bazi tijekom testiranja (a bez toga, kakvo ćemo testiranje imati?!), onda će se nakon svakog testiranja baza mijenjati. To može ometati naknadne testove i trajno oštetiti bazu podataka.

Ključ rješenja problema su transakcije. Jedna od značajki ovog mehanizma je da sve dok transakcija nije dovršena, uvijek možete poništiti sve promjene i vratiti bazu podataka u stanje u trenutku kada je transakcija započela.

Algoritam je ovakav:

otvoriti transakciju;
ako je potrebno, provodimo pripremne korake za testiranje;
izvršiti jedinični test (ili jednostavno pokrenuti skriptu čiji rad želimo provjeriti);
provjeriti rezultat skripte;
Otkazujemo transakciju, vraćajući bazu podataka u izvorno stanje.

Čak i ako postoje nezatvorene transakcije u kodu koji se testira, vanjski ROLLBACK će i dalje ispravno vratiti sve promjene.

Dobro je ako trebamo testirati SQL skriptu ili pohranjenu proceduru. Što ako testiramo aplikaciju koja se sama povezuje s bazom podataka, otvarajući novu vezu? Osim toga, ako otklanjamo pogreške, tada ćemo vjerojatno htjeti pogledati bazu podataka kroz oči aplikacije kojoj se otklanjaju pogreške. Što učiniti u ovom slučaju?

Nemojte žuriti sa stvaranjem distribuiranih transakcija, postoji jednostavnije rješenje! Koristeći standardne alate SQL poslužitelja, možete otvoriti transakciju na jednoj vezi i nastaviti je na drugoj.

Da biste to učinili, trebate se spojiti na poslužitelj, otvoriti transakciju, dobiti token za tu transakciju, a zatim proslijediti ovaj token aplikaciji koja se testira. Pridružit će se našoj transakciji u svojoj sesiji i od tog trenutka nadalje, u našoj sesiji otklanjanja pogrešaka vidjet ćemo podatke (i također osjetiti zaključavanja) točno onako kako ih vidi aplikacija koja se testira.

Slijed radnji je sljedeći:

Nakon pokretanja transakcije u debug sesiji, moramo saznati njen identifikator. Ovo je jedinstveni niz po kojem poslužitelj razlikuje transakcije. Taj se identifikator mora nekako proslijediti aplikaciji koja se testira.

Sada je zadatak aplikacije povezati se s našom kontrolnom transakcijom prije nego što počne raditi ono što bi trebala raditi.

Tada aplikacija počinje raditi, uključujući pokretanje svojih pohranjenih procedura, otvaranje svojih transakcija, mijenjanje načina izolacije... Ali naša sesija otklanjanja pogrešaka cijelo će to vrijeme biti unutar iste transakcije kao i aplikacija.

Recimo da aplikacija zaključa tablicu i počne mijenjati njezin sadržaj. U ovom trenutku nijedna druga veza ne može pogledati u zaključanu tablicu. Ali ne i naša sesija otklanjanja pogrešaka! Odatle možemo gledati bazu podataka na isti način kao što to čini aplikacija, budući da SQL poslužitelj vjeruje da smo u istoj transakciji.

Dok su za sve druge sesije radnje aplikacije skrivene bravama...

Naša sesija otklanjanja pogrešaka prolazi kroz brave (poslužitelj misli da su to naše vlastite brave)!

Ili zamislite da aplikacija počne raditi sa svojim vlastitim verzijama nizova u SNAPSHOT modu. Kako mogu pogledati ove verzije? I to je moguće ako ste povezani zajedničkom transakcijom!

Ne zaboravite vratiti kontrolnu transakciju unatrag na kraju ovog uzbudljivog procesa. To se može učiniti i iz sesije otklanjanja pogrešaka (ako se proces testiranja završi normalno) i iz same aplikacije (ako se u njoj dogodi nešto neočekivano).

Više o tome možete naučiti na tečajevima

Prije nekoliko godina pokazalo se da je SQL odjednom zastario. I počela su se pojavljivati i množiti NoSQL rješenja, odbacujući SQL jezik i model relacijske pohrane podataka. Glavni argumenti u prilog ovom pristupu: sposobnost rada s velikim podacima (isti Big Data), pohranjivanje podataka u najegzotičnije strukture i, što je najvažnije, mogućnost da se sve to učini vrlo brzo. Pogledajmo kako to rade najpopularniji predstavnici NoSQL svijeta.

Kako se postiže brzina u NoSQL-u? Prije svega, to je posljedica potpuno drugačije paradigme pohrane podataka. Parsiranje i prevođenje SQL upita, rad optimizatora, spajanje tablica itd. uvelike povećavaju vrijeme odziva. Ako uklonite sve te slojeve, pojednostavite upite, čitate s diska izravno na mrežu ili pohranite sve podatke u RAM, možete dobiti na brzini. Smanjuje se i vrijeme obrade svakog zahtjeva i broj zahtjeva u sekundi. Tako su se pojavile baze podataka ključ-vrijednost, čiji je najtipičniji i najpoznatiji predstavnik memcached. Da, ova predmemorija, koja se široko koristi u web aplikacijama za ubrzavanje pristupa podacima, također je NoSQL.

NoSQL vrste

Postoje četiri glavne kategorije NoSQL sustava:

Ključ - vrijednost (key-value). Velika hash tablica u kojoj su dopuštene samo operacije pisanja i čitanja podataka po ključu.
Stupac. Tablice s redovima i stupcima. Ali za razliku od SQL-a, broj stupaca od retka do retka može biti varijabilan, a ukupan broj stupaca može se mjeriti u milijardama. Također svaki red ima jedinstveni ključ. Ovu strukturu podataka možete zamisliti kao hash tablicu hash tablice, prvi ključ je ključ retka, drugi je naziv stupca. Uz podršku sekundarnih indeksa, izbori su mogući prema vrijednosti u stupcu, a ne samo prema ključu retka.
Orijentiran na dokumente. Zbirke strukturiranih dokumenata. Moguće je birati po raznim poljima dokumenta, kao i mijenjati dijelove dokumenta. Ova kategorija također uključuje tražilice, koje su indeksi, ali u pravilu ne pohranjuju same dokumente.
Grafikon. Posebno dizajniran za pohranu matematičkih grafova: čvorova i veza između njih. U pravilu vam također omogućuju da navedete skup proizvoljnih atributa za čvorove i veze i odaberete čvorove i veze na temelju tih atributa. Podržava algoritme za prelaženje grafova i izradu ruta.

Za test smo uzeli predstavnike prve tri kategorije:

Kako je test proveden

Na raspolaganju su nam bila četiri poslužiteljska stroja. Svaki ima Xeon s osam jezgri, 32 GB RAM-a, četiri Intel SSD-a od po 120 GB.

Testirali smo koristeći YCSB (Yahoo! Cloud Serving Benchmark). Ovo je posebno mjerilo koje je objavio Yahoo! Istraživanja 2010. pod licencom Apache. Benchmark je posebno kreiran za testiranje NoSQL baza podataka. I sada ostaje jedino i prilično popularno mjerilo za NoSQL, zapravo standard. Usput, napisano je u Javi. Dodali smo upravljački program za Aerospike izvornom YCSB-u, blago ažurirali upravljački program za MongoDB, a također smo malo prevarili s izlazom rezultata.

INFO

Osim YCSB-a, možete testirati performanse NoSQL baze podataka koristeći, na primjer, JMeter.

Bilo je potrebno osam klijentskih računala da opterete naš mali klaster. Četverojezgreni i5 i 4 GB RAM-a svaki. Jedan (ili dva, ili tri, ili četiri...) klijenta nisu bili dovoljni za učitavanje klastera. Možda se čini čudnim, ali je istinito.

Sve se to kretalo u jednom gigabitu lokalna mreža. Možda bi bilo zanimljivije na mreži od deset gigabita, ali mi nismo imali takav hardver. Zanimljivije je, jer kad se broj operacija u sekundi počne mjeriti u stotinama tisuća, trčimo u mrežu. S propusnošću od gigabita u sekundi (10^9 bita/s), mreža može proći samo oko 100 000 (10^5) kilobajtnih paketa (~10^4 bita). Odnosno, dobivamo samo 100 tisuća operacija u sekundi. Ali zapravo smo htjeli dobiti milijun :).

Mrežne kartice su također važne. Ispravne mrežne kartice poslužitelja imaju nekoliko I/O kanala, svaki sa svojim prekidom. Ali prema zadanim postavkama u Linuxu, svi ti prekidi su dodijeljeni jednoj jezgri procesora. Samo su se dečki iz Aerospikea pobrinuli za tu suptilnost, a njihove konfiguracijske skripte baze podataka raspršuju prekide mrežne kartice po procesorskim jezgrama. Možete vidjeti prekide mrežne kartice i kako su raspoređeni po procesorskim jezgrama, na primjer, pomoću sljedeće naredbe: “cat /proc/interrupts | grep eth".

Također bismo trebali razgovarati o SSD-ovima. Željeli smo testirati rad NoSQL baza podataka posebno na solid-state diskovima kako bismo shvatili jesu li ti diskovi stvarno vrijedni toga, odnosno da li pružaju dobre performanse. Stoga smo pokušali ispravno konfigurirati SSD. Više o tome možete pročitati na bočnoj traci.

Postavljanje SSD-a

Konkretno, SSD zahtijeva radnje koje se nazivaju overprovisioning. Činjenica je da SSD ima sloj za prevođenje adresa. Adrese blokova vidljive operativnom sustavu uopće ne odgovaraju fizičkim blokovima u flash memoriji. Kao što znate, flash memorija ima ograničen broj ciklusa ponovnog pisanja. Osim toga, operacija pisanja sastoji se od dvije faze: brisanja (često nekoliko blokova odjednom) i samog pisanja. Stoga, kako bi se osigurala dugotrajnost pogona (ravnomjerno trošenje) i dobra brzina pisanja, kontroler diska mijenja fizičke memorijske blokove tijekom pisanja. Kada operativni sustav zapiše blok na određenu adresu, pisanje se fizički događa u neki čisti slobodni blok memorije, a stari blok je označen kao dostupan za naknadno (pozadinsko) brisanje. Za sve ove manipulacije, kontroler diska treba slobodne blokove, što više, to bolje. SSD koji je 100% pun može biti prilično spor.

Besplatni blokovi mogu se dobiti na nekoliko načina. Možete koristiti naredbu hdparm (s prekidačem "-N") za određivanje broja vidljivih sektora diska operacijski sustav. Ostatak će biti na potpunom raspolaganju kontroloru. Međutim, to ne radi na svakom hardveru (na primjer, ne radi u AWS EC2). Drugi način je ostaviti prostor na disku koji ne zauzimaju particije (što znači particije stvorene, na primjer, fdiskom). Upravljač je dovoljno pametan da iskoristi ovu lokaciju. Treći način je korištenje datotečnih sustava i verzija kernela koji mogu prijaviti slobodne blokove kontroleru. Ovo je ista naredba TRIM. Naš hardver je imao dovoljno hdparma, 20% ukupnog volumena diska dali smo kontroleru da ga raskomada.

I/O planer također je važan za SSD-ove. Ovo je podsustav jezgre koji grupira i mijenja redoslijed I/O operacija (uglavnom pisanja na disk) radi poboljšanja učinkovitosti. Prema zadanim postavkama, Linux koristi CFQ (Completely Fair Queuing), koji pokušava preurediti zapise kako bi upisao što više blokova uzastopno. Ovo je dobro za obične diskove koji se vrte (tako kažu - vrte se:)) jer je kod njih brzina linearnog pristupa osjetno veća od pristupa nasumičnim blokovima (glave treba pomicati). Ali za SSD diskove, linearno i nasumično pisanje jednako su učinkoviti (teoretski), a rad CFQ samo uvodi nepotrebna kašnjenja. Stoga, za SSD diskove morate omogućiti druge planere, kao što je NOOP, koji jednostavno izvršava I/O naredbe redoslijedom kojim su stigle. Planer možete promijeniti, na primjer, sljedećom naredbom: “echo noop > /sys/block/sda/queue/scheduler”, gdje je sda vaš disk. Da budemo pošteni, vrijedi spomenuti da najnoviji kerneli sami mogu otkriti SSD pogone i omogućiti ispravan planer za njih.

Svaki DBMS voli intenzivno pisati na disk, kao i intenzivno čitati. A Linux stvarno voli čitati unaprijed, proaktivno čitanje podataka, u nadi da ćete, nakon što pročitate ovaj blok, htjeti pročitati sljedećih nekoliko. Međutim, s DBMS-om, a posebno s nasumičnim čitanjem (a to je naša opcija), tim nadama nije suđeno da se ostvare. Kao rezultat toga, imamo nepotrebno čitanje i korištenje memorije. MongoDB programeri preporučuju smanjenje vrijednosti čitanja unaprijed ako je moguće. To možete učiniti naredbom “blockdev --setra 8 /dev/sda”, gdje je sda vaš disk.

Svaki DBMS voli otvarati mnogo, mnogo datoteka. Stoga je potrebno značajno povećati nofile ograničenja (broj dostupnih deskriptora datoteka za korisnika) u datoteci /etc/security/limits.conf na vrijednost znatno iznad 4k.

Također ustao interes Pitaj: Kako koristiti četiri SSD-a? Ako ih Aerospike jednostavno povezuje kao pohranu i nekako neovisno izmjenjuje pristup diskovima, onda druge baze podataka impliciraju da imaju samo jedan direktorij s podacima. (U nekim slučajevima možete navesti više direktorija, ali to ne uključuje razdvajanje podataka između njih.) Morao sam stvoriti RAID 0 (prugasti) pomoću uslužnog programa mdadm. Pretpostavljam da se može igrati s LVM-om, ali dobavljači baza podataka opisuju samo korištenje mdadm-a.

Naravno, na svim strojevima u klasteru (i poslužitelju i klijentu) satovi moraju biti sinkronizirani pomoću ntpd-a. Ntpdate ovdje nije prikladan jer je potrebna veća točnost sinkronizacije. Za sve distribuirane sustave bitno je da vrijeme između čvorova bude sinkronizirano. Na primjer, Cassandra i Aerospike pohranjuju vrijeme izmjene zapisa. A ako postoje zapisi s različitim vremenskim oznakama na različitim čvorovima klastera, tada će najnoviji zapis pobijediti.

Same NoSQL baze podataka konfigurirane su na sljedeći način. Konfiguracija je izvađena iz kutije, a primijenjene su sve preporuke opisane u dokumentaciji za postizanje najboljih performansi. U teškim slučajevima kontaktirali smo programere baze podataka. Najčešće su preporuke vezane uz prilagodbe broja jezgri i količine RAM-a.

Najlakši način za postavljanje je Couchbase. Ima web konzolu. Dovoljno je pokrenuti uslugu na svim čvorovima klastera. Zatim stvorite kantu na jednom od čvorova ("košarica" za ključeve-vrijednosti) i dodajte druge čvorove u klaster. Sve se radi putem web sučelja. Nema posebno zahtjevnih postavki.

Aerospike i Cassandra konfigurirani su približno na isti način. Morate stvoriti konfiguracijsku datoteku na svakom čvoru klastera. Te su datoteke gotovo identične za svaki čvor. Zatim pokrenite demone. Ako je sve u redu, čvorovi će se udružiti u klaster. Morate prilično dobro razumjeti opcije konfiguracijske datoteke. Ovdje je vrlo važna dobra dokumentacija.

Najteže je s MongoDB-om. U drugim bazama podataka svi su čvorovi jednaki. To nije slučaj s Mongom. Željeli smo staviti sve baze podataka u iste uvjete, ako je moguće, i postaviti faktor replikacije za sve na 2. To znači da bi trebale postojati dvije kopije podataka u klasteru, radi pouzdanosti i brzine. U drugim bazama podataka faktor replikacije samo je postava pohrane podataka (ili "košara", ili "obitelj stupaca"). U MongoDB-u broj kopija podataka određen je strukturom klastera. MongoDB klaster možete ispravno konfigurirati samo ako dvaput pročitate službenu dokumentaciju koja mu je posvećena :). Ukratko, trebaju nam krhotine ili setovi replika. Shardovi (dobro, vjerojatno ste čuli izraz "sharding") su podskupovi cijelog skupa podataka, kao i čvorovi klastera gdje će svaki podskup biti pohranjen. Skupovi replika je MongoDB izraz za skup čvorova klastera koji pohranjuju identične kopije podataka. Replika mreže ima glavni čvor koji izvodi operacije pisanja i sekundarne čvorove na koje se podaci iz glavnog čvora repliciraju. U slučaju kvarova, uloga glavnog čvora može se prenijeti na drugi čvor skupa replika. Za naš slučaj (četiri poslužitelja i želja za pohranjivanjem dvije kopije podataka) ispada da su nam potrebna dva sharda, od kojih je svaki replika skupa dva poslužitelja s podacima. Osim toga, svakom skupu replika mora se dodati tzv. arbitar koji ne pohranjuje podatke, ali je potreban za sudjelovanje u izboru novog glavnog čvora. Broj čvorova u mreži replike za ispravni izbori mora biti neparan. Također vam je potrebna mala konfiguracijska baza podataka koja će pohranjivati informacije o shardovima i koji su rasponi podataka pohranjeni na kojem shardu. Tehnički, ovo je također MongoDB, ali (u usporedbi s glavnim podacima) vrlo je malen. Postavili smo arbitre i konfiguracijsku bazu podataka na klijentska računala. I na svakom klijentu trebate pokrenuti mongos daemon (mongo switch), koji će pristupiti konfiguracijskoj bazi podataka i usmjeravati zahtjeve od svakog klijenta između shardova.

Svaka NoSQL baza podataka ima svoj jedinstveni način predstavljanja podataka i valjanih operacija na njima. Stoga je YCSB krenuo putem maksimalne generalizacije bilo koje baze podataka (uključujući SQL).

Skup podataka na kojem radi YCSB je ključ i vrijednost. Ključ je niz koji uključuje 64-bitni hash. Dakle, sam YCSB, znajući ukupan broj zapisa u bazi podataka, njima pristupa pomoću cjelobrojnog indeksa, a za bazu podataka skup ključeva izgleda potpuno nasumično. Vrijednost je desetak polja slučajnih binarnih podataka. Prema zadanim postavkama, YCSB generira zapise veličine kilobajta, ali, kao što se sjećate, na gigabitnoj mreži to nas ograničava na samo 100k operacija u sekundi. Stoga smo u testovima smanjili veličinu jednog zapisa na 100 bajtova.

YCSB izvodi vrlo jednostavne operacije na ovim podacima: umetanje novi unos s ključem i nasumičnim podacima, čitanje zapisa po ključu, ažuriranje zapisa po ključu. Nijedna tablica se ne spaja (i doista se misli samo na jednu "tablicu"). Nema odabira na sekundarnim ključevima. Nema višestrukih odabira prema uvjetu (jedina provjera je odgovara li primarni ključ). Ovo je vrlo primitivno, ali se može učiniti u bilo kojoj bazi podataka.

Neposredno prije testiranja bazu je potrebno popuniti podacima. To radi sam YCSB. U biti, ovo je opterećenje koje se sastoji samo od operacija umetanja. Eksperimentirali smo s dva skupa podataka. Prvi zajamčeno stane u RAM čvorova klastera, 50 milijuna zapisa, približno 5 GB čistih podataka. Drugi garantirano ne stane u RAM, 500 milijuna zapisa, otprilike 50 GB čistih podataka.

Sam test - izvođenje određenog skupa operacija - izvodi se pod opterećenjem različiti tipovi. Važan parametar je omjer operacija - koliko očitavanja treba biti i koliko ažuriranja. Koristili smo dvije vrste: intenzivno pisanje (Heavy Write, 50% čitanja i 50% ažuriranja) i uglavnom čitanje (Mostly Read, 95% čitanja i 5% ažuriranja). Koju operaciju treba izvršiti odabire se nasumično svaki put, postoci određuju vjerojatnost odabira operacije.

YCSB može koristiti različite algoritme odabira zapisa (ključeva) za izvođenje operacije. To može biti uniformna distribucija (bilo koji ključ iz cijelog skupa podataka može se odabrati s istom vjerojatnošću), eksponencijalna distribucija (ključevi "na početku" skupa podataka bit će odabrani puno češće) i neke druge. Ali Yahoo tim odabrao je takozvani zipfian kao tipičnu distribuciju. Ovo je jednolika raspodjela u kojoj se, međutim, određeni ključevi (mali postotak ukupnog broja ključeva) biraju znatno češće od drugih. Ovo simulira popularne postove na, recimo, blogovima.

YCSB počinje s više niti, pokrećući petlju u svakoj od njih, sve na istom stroju. Sa samo četiri jezgre na jednom klijentskom stroju, prilično je frustrirajuće pokušavati pokrenuti više od četiri niti. Stoga smo pokrenuli YCSB na osam klijentskih računala istovremeno. Za automatizaciju pokretanja koristili smo fabric i cron (točnije, at). Mala Python skripta generira naredbe potrebne za pokretanje YCSB-a na svakom klijentu, te se naredbe stavljaju na čekanje u isto vrijeme za najbližu minutu u budućnosti na svakom klijentu. Zatim se pokreće at i YCSB se uspješno pokreće (ili ne tako dobro, ako su parametri pogrešni) u isto vrijeme na svih osam klijenata. Za prikupljanje rezultata (YCSB log datoteke), ponovno se koristi tkanina.

rezultate

Dakle, početni rezultati su YCSB zapisnici od svakog klijenta. Ovi zapisnici izgledaju otprilike ovako (pokazuje se posljednji dio datoteke):

Operacije, 1187363 , Ponovni pokušaji, 0 , Prosječna latencija(us), 3876.5493619053314 , Min latencija(us), 162 , MaxLatency(us), 278190 , 95thPercentileLatency(ms), 12 , 99thPercentileLatency(ms), 22 , Povrat=0, 118 7363, Ponovna povezivanja, 0,0, vrijeme izvođenja (ms), 303574,0, operacije, 1249984,0, propusnost (ops/sek), 4117,5594747903315

Kao što vidite, postoji niz operacija određene vrste (u u ovom primjeru- čita), prosječna, minimalna i maksimalna kašnjenja, kašnjenje unutar kojeg je ispunjeno 95 i 99% operacija, broj uspješnih operacija (povratni kod 0), ukupno vrijeme testiranja, ukupan broj svih operacija i prosječan broj operacija u sekundi. Najviše nas zanima prosječna latencija (AverageLatency) i broj operacija u sekundi (Throughput).

Korištenjem druge Python skripte, podaci iz hrpe zapisa prikupljeni su u tablicu, a iz tablice su izgrađeni prekrasni grafikoni.

zaključke

NoSQL baze podataka dijele se u dvije skupine: brze i spore. Baza podataka ključ-vrijednost pokazala se brzom, kao što se i očekivalo. Aerospike i Couchbase daleko su ispred konkurencije.

Aerospike je doista vrlo brza baza podataka. I gotovo smo uspjeli doći do milijun operacija u sekundi (na podacima u memoriji). Aerospike dosta dobro radi i na SSD-ovima, pogotovo ako se uzme u obzir da Aerospike u ovom modu ne koristi predmemoriranje podataka u memoriji, već pristupa disku za svaki zahtjev. To znači da u Aerospike stvarno možete smjestiti veliku količinu podataka (sve dok ima dovoljno diskova, a ne RAM-a).

Couchbase je brz, ali brz samo u memorijskim operacijama. SSD testni grafikoni pokazuju brzinu Couchbasea s količinom podataka tek malo većom od količine RAM-a - ukupno 200 milijuna zapisa. To je osjetno manje od 500 milijuna s kojima su testirane druge baze podataka. Couchbase jednostavno nije mogao umetnuti više zapisa, odbio je izbaciti predmemoriju podataka iz memorije na disk i prestao je pisati (pisanje ne bi uspjelo). Ovo je dobra predmemorija, ali samo za podatke koji stanu u RAM.

Cassandra je jedina baza podataka koja brže piše nego čita :). To je zato što je pisanje u njega uspješno završeno (u najbržoj verziji) odmah nakon pisanja u dnevnik (na disk). Ali čitanje zahtijeva provjere, nekoliko čitanja s diska, odabir najnovijeg zapisa. Cassandra je pouzdana i prilično brza skalabilna arhiva podataka.

MongoDB je prilično spor za pisanje, ali relativno brz za čitanje. Ako podaci (ili bolje rečeno, ono što se zove radni set - skup trenutnih podataka kojima se stalno pristupa) ne stanu u memoriju, ona jako usporava (a upravo se to događa kod testiranja YCSB-a). Također morate zapamtiti da MongoDB ima globalno zaključavanje čitanja/pisanja, što može uzrokovati probleme pod vrlo velikim opterećenjem. Sve u svemu, MongoDB je dobra baza podataka za web.

P.S

Napravimo mali predah od problema s performansama i pogledajmo kako će se SQL i NoSQL rješenja dalje razvijati. Zapravo, ovo što sada vidimo je ponavljanje poznate priče. Sve se to već dogodilo šezdesetih i sedamdesetih godina dvadesetog stoljeća: prije relacijskih baza postojale su hijerarhijske, objektne i druge, i druge. Onda sam htio standardizaciju i pojavio se SQL. I svi ozbiljni DBMS-ovi, od kojih je svaki podržavao vlastiti jezik upita i API, prebacili su se na SQL. Jezik upita i relacijski model postali su standard. Zanimljivo je da sada također pokušavaju ucijepiti SQL na NoSQL, što dovodi do stvaranja omotača povrh postojećeg NoSQL-a i potpuno novih baza podataka nazvanih NewSQL.

Ako je NoSQL odlučio napustiti “teško nasljeđe” SQL-a, preispitati pristupe pohranjivanju podataka i stvoriti potpuno nova rješenja, tada se izraz NewSQL koristi za opisivanje pokreta za “oživljavanje” SQL-a. Uzimajući ideje iz NoSQL-a, dečki su ponovno stvorili SQL baze podataka na novoj razini. Na primjer, u NewSQL svijetu često možete pronaći baze podataka koje pohranjuju podatke u memoriju, ali s potpunim SQL upitima, spajanjima tablica i drugim poznatim stvarima. Kako bi se i dalje pohranjivalo puno podataka, u ove baze podataka ugrađeni su mehanizmi za dijeljenje.

NewSQL uključuje VoltDB, TokuDB, MemDB i druge. Zapamtite ova imena, možda će se uskoro i o njima govoriti na svakoj IT konferenciji.

Usluga testiranja baze podataka pomoći će minimizirati rizike prilikom uvođenja sustava u komercijalni rad. Moći ćete unaprijed provjeriti ispravnost i sigurnost baze podataka.
Tijekom procesa testiranja baze podataka provjerava se usklađenost rada baze podataka s funkcionalnim i nefunkcionalnim zahtjevima. Aplikacije koje u svojoj arhitekturi uključuju bazu podataka zahtijevaju proceduru testiranja baze podataka, na primjer: korporativna Informacijski sustavi, mobilne i web aplikacije.

Performanse baze podataka kritični su faktor u učinkovitosti upravljanja i poslovnih aplikacija. Ako je pretraživanje ili pisanje podataka sporo, sposobnost aplikacije da normalno funkcionira smanjuje se. Jedini način da se otkrije uzrok loših performansi je da se poduzmu kvantitativna mjerenja i utvrdi što je uzrok problema s performansama.
Problemi identificiranja uskih grla u performansama baze podataka izravno su povezani s metrikama, metodama mjerenja performansi i tehnologijom za njihovu implementaciju. Za velike korporacije i velike baze podataka problem određivanja performansi baze podataka ima još jedan vrlo važan aspekt: određivanje IT infrastrukture za dugoročni industrijski rad aplikacija. To u konačnici dovodi do točnijeg određivanja početnog ulaganja u hardver i osnovni softver. Budući da visoka izvedba baze podataka jako ovisi o platformi i opremi, oni se kupuju i rade dugoročno.
Najvažnije metrike za mjerenje performansi baze podataka su:

broj transakcija po vremenskom razdoblju ( različite vrste transakcije);
broj I/O operacija (čitanje redaka) po transakciji i vrijeme njenog izvršenja;
broj pročitanih redaka po tablici po transakciji;
prosječan broj I/O operacija po transakciji prema rasponu;
SQL izjave imaju visok operativni trošak CPU vremena (korisnik, sustav)
vrijeme početka i završetka izvođenja naredbe
vrijeme dovršetka sortiranja (broj sortiranja, broj preljeva sortiranja, vrijeme dovršetka sortiranja), najveće korištenje proteklog vremena i najniža učinkovitost korištenja indeksa.

Mjerni podaci o korištenju memorije za stranice tabličnog prostora i skupove međuspremnika (za čitanje podataka, za čitanje indeksa), za izvođenje sortiranja, za pokretanje uslužnih programa, za direktorije i pakete predmemorije, zajedno s metričkim pokazateljima performansi, također su važni za podešavanje učinkovitog pristupa podacima.

Što još trebate provjeriti prilikom testiranja baze podataka?

Mapiranje podataka

Provjerite odgovaraju li veze u bazi podataka projektnoj dokumentaciji. Za sve CRUD operacije, provjerite jesu li odgovarajuće tablice i zapisi ažurirani kada korisnik klikne Spremi, Osvježi, Traži ili Izbriši iz GUI aplikacije.

Svojstva ACID transakcije

ACID svojstva transakcija uključuju atomičnost, dosljednost, izolaciju i snagu. Tijekom testiranja baze podataka trebali biste provjeriti ova četiri svojstva. Ovo područje zahtijeva opsežnije testiranje ako je baza podataka distribuirana.

Integritet podataka

Imajte na umu da različiti aplikacijski moduli (kao što su zasloni i obrasci) koriste iste podatke i različito izvode CRUD operacije. Stoga morate osigurati da se najnovije stanje podataka posvuda jednako odražava. Sustav bi trebao prikazati ažurirane vrijednosti na svim obrascima i ekranima. To se zove integritet podataka.

Točnost implementacije poslovne logike

Danas su baze podataka dizajnirane za više od pukog pohranjivanja zapisa. Razvili su se u vrlo moćne alate koji programerima pružaju brojne mogućnosti za implementaciju poslovne logike na razini baze podataka. Primjeri snažnih značajki baze podataka su "referentni integritet", relacijska ograničenja, okidači i pohranjene procedure. Stoga, koristeći ove i mnoge druge značajke koje nudi baza podataka, programeri implementiraju poslovnu logiku na razini baze podataka. Ispitivač mora osigurati da je implementirana poslovna logika ispravna i radi točno.

Kako testirati bazu podataka?

Pisanje SQL upita

Kako bi pravilno organizirali proces testiranja baze podataka, testeri moraju dobro poznavati SQL i DML (Data Manipulation Language) te jasno razumjeti unutarnju strukturu baze podataka. Ovo je najbolji i najpouzdaniji način testiranja baze podataka, posebno za aplikacije niske i srednje složenosti. Ali moraju biti ispunjena dva opisana preduvjeta. Ako je aplikacija vrlo složena, ispitivaču će biti teško ili čak nemoguće da sam napiše sve potrebne SQL upite. Stoga se u slučaju nekih složenih upita, tester može obratiti razvojnom programeru za pomoć. Ova metoda ne samo da daje povjerenje da je testiranje dobro obavljeno, već i poboljšava vještinu pisanja SQL upita.

Pregled podataka u tablicama

Ako ispitivač ne poznaje SQL, tada može provjeriti rezultat CRUD operacije pomoću grafičkog sučelja aplikacije pregledom tablica (relacija) baze podataka. Ova metoda provjere baze podataka zahtijeva dobro poznavanje strukture tablice i može biti pomalo zamorna i glomazna, posebno kada baza podataka i tablice imaju veliku količinu podataka. Ova metoda provjere baze podataka može biti teška za testere ako se testni podaci nalaze u nekoliko tablica.

Pomoć za programere

Tester izvodi sve CRUD operacije na GUI-ju i provjerava njihove rezultate izvršavanjem odgovarajućih SQL upita koje je napisao programer. Ova metoda ne zahtijeva niti dobro poznavanje SQL-a niti dobro poznavanje strukture baze podataka aplikacije.Metoda se čini jednostavnom i dobar izbor za testiranje baze podataka. Ali njegova loša strana je kaos. Što ako je upit koji je napisao programer semantički netočan ili ne ispunjava ispravno zahtjeve korisnika? U tom slučaju testiranje ne daje nikakvo jamstvo o kvaliteti proizvoda.

Primjer metodologije za testiranje integriteta podataka baze podataka

Baze podataka i procesi baze podataka trebali bi se testirati kao neovisni podsustav. U tom slučaju moraju se testirati svi podsustavi bez ciljanog korisničkog sučelja kao sučelja za podatke. Potrebno je provesti dodatna istraživanja u sustavu za upravljanje bazom podataka (DBMS) kako bi se odredili alati i tehnike za podršku testiranju definiranom u sljedećoj tablici.

Ciljevi metodologije	Testiranje metoda i procesa pristupa bazi podataka neovisno o korisničkom sučelju, tako da se mogu promatrati i zabilježiti neispravni ciljni algoritmi ili oštećenje podataka.
Metodologija	Pozovite svaku metodu ili proces pristupa bazi podataka, popunjavajući svaki s važećim i nevažećim podacima ili zahtjevima za podatke. Provjera valjanosti baze podataka kako bi se osiguralo da su podaci ispravno popunjeni i da se svi događaji u bazi podataka odvijaju prema očekivanjima ili provjera valjanosti vraćenih podataka kako bi se osiguralo da su točni podaci dohvaćeni kada je to potrebno.
Proročišta(heuristički mehanizam koji pomaže identificirati problem)	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte Alat za vraćanje slika i osnovne linije Alati za sigurnosno kopiranje i oporavak Alati za nadzor instalacije (registar, HDD, CPU, memorija i tako dalje) Pomoćni programi i alati SQL baze podataka Alati za generiranje podataka
Uvjeti za uspjeh	Ova tehnika podržava testiranje svih glavnih metoda i procesa pristupa bazi podataka.
Posebnainformacija	Testiranje može zahtijevati razvojno okruženje DBMS-a ili upravljačke programe za unos ili promjenu podataka izravno u bazi podataka. Procesi se moraju pozivati ručno. Male baze podataka ili baze podataka minimalna veličina(s ograničenim brojem unosa) treba koristiti za proširenje opsega svih oštećenih događaja.

Prijevod članka Rizwan Jafri

Danas je baza podataka jedan od neizbježnih dijelova aplikacije. Kada se aplikacija izvrši, krajnji korisnik uglavnom koristi CRUD operacije koje pruža alat baze podataka.

C: Stvoriti(Stvori) - Operacija 'Stvori' izvodi se kada korisnik spremi bilo koju novu transakciju.
R: dohvatiti(Dohvati) - Operacija 'Dohvati' izvodi se kada korisnik pretražuje ili gleda bilo koju spremljenu transakciju.
U: Ažuriraj(Ažuriraj) - Operacija 'Ažuriraj' izvodi se kada korisnik uređuje ili mijenja postojeći zapis.
D: Izbrisati(Delete) - Operacija 'Delete' se izvodi kada korisnik izbriše bilo koji unos iz sustava.

Nije bitno koja se baza podataka koristi i kako je operacija prethodno izvedena (pridruživanje ili podupit, okidač ili pohranjena procedura, upit ili funkcija). Zanimljivo je da su sve operacije baze podataka koje korisnik izvodi, iz korisničkog sučelja bilo koje aplikacije, jedna od ove četiri CRUD operacije.

Što provjeriti prilikom testiranja baze podataka?

1) Mapiranje podataka:
Provjerite odgovaraju li veze u bazi podataka projektnoj dokumentaciji. Za sve CRUD operacije, provjerite jesu li odgovarajuće tablice i zapisi ažurirani kada korisnik klikne Spremi, Osvježi, Traži ili Izbriši iz GUI aplikacije.

2) Svojstva ACID transakcije:
ACID svojstva transakcija uključuju valentnost, podslijed, izolacija I snaga. Tijekom testiranja baze podataka trebali biste provjeriti ova četiri svojstva. Ovo područje zahtijeva opsežnije testiranje ako je baza podataka distribuirana.

3) Integritet podataka:
Imajte na umu da različiti aplikacijski moduli (kao što su zasloni i obrasci) koriste iste podatke i različito izvode CRUD operacije. Stoga morate osigurati da se najnovije stanje podataka posvuda jednako odražava. Sustav bi trebao prikazati ažurirane vrijednosti na svim obrascima i ekranima. To se zove integritet podataka.

4) Točnost implementacije poslovnih pravila:
Danas su baze podataka dizajnirane za više od pukog pohranjivanja zapisa. Razvili su se u vrlo moćne alate koji programerima pružaju brojne mogućnosti za implementaciju poslovne logike na razini baze podataka. Primjeri snažnih značajki baze podataka su "referentni integritet", relacijska ograničenja, okidači i pohranjene procedure. Stoga, koristeći ove i mnoge druge značajke koje nudi baza podataka, programeri implementiraju poslovnu logiku na razini baze podataka. Ispitivač mora osigurati da je implementirana poslovna logika ispravna i radi točno.

Gore opisane točke najvažniji su aspekti testiranja baze podataka. Testiranje baze podataka kritičan je poslovni zadatak i nikada se ne smije prepustiti neiskusnim zaposlenicima bez odgovarajuće obuke.

Kako testirati bazu podataka?

1. Pisanje SQL upita
Kako bi ispravno i točno provjerio bazu podataka, prije svega, tester mora vrlo dobro poznavati SQL i DML (Data Manipulation Language). Drugo, ispitivač mora dobro razumjeti unutarnju strukturu baze podataka. Ako su ova dva preduvjeta zadovoljena, tada je zaposlenik spreman za testiranje baze podataka. On/ona će izvršiti sve CRUD operacije iz korisničkog sučelja aplikacije, a zatim provjeriti rezultate izvršenja pomoću SQL upita.
Ovo je najbolji i najpouzdaniji način testiranja baze podataka, posebno za aplikacije niske i srednje složenosti. Ali moraju biti ispunjena dva opisana preduvjeta. U suprotnom, ova metoda testiranja baze podataka neće raditi za vas.
Ako je aplikacija vrlo složena, ispitivaču će biti teško ili čak nemoguće da sam napiše sve potrebne SQL upite. Stoga se u slučaju nekih složenih upita, tester može obratiti razvojnom programeru za pomoć.
Ova metoda ne samo da daje povjerenje da je testiranje dobro obavljeno, već i poboljšava vještinu pisanja SQL upita.

2. Pregled podataka u tablicama
Ako ispitivač ne poznaje SQL, tada on/ona može provjeriti rezultat CRUD operacije korištenjem grafičkog sučelja aplikacije pregledom tablica (relacija) baze podataka. Ova metoda provjere baze podataka zahtijeva dobro poznavanje strukture tablice i može biti pomalo zamorna i glomazna, posebno kada baza podataka i tablice imaju veliku količinu podataka.
Osim toga, ovaj način provjere baze podataka može biti vrlo težak za testere ako se podaci koji se provjeravaju nalaze u više tablica.

3. Pomoć za programere
Ovo je najlakši način. Tester izvodi sve CRUD operacije na GUI-ju i provjerava njihove rezultate izvršavanjem odgovarajućih SQL upita koje je napisao programer. Ova metoda ne zahtijeva niti dobro poznavanje SQL-a niti dobro poznavanje strukture aplikacijske baze podataka.
Stoga se ova metoda čini jednostavnom i dobrim izborom za testiranje baze podataka. Ali njegova loša strana je kaos. Što ako je upit koji je napisao programer semantički netočan ili ne ispunjava ispravno zahtjeve korisnika? U tom slučaju testiranje ne daje nikakvo jamstvo o kvaliteti proizvoda.

Zaključak

Baza podataka je glavni i najvažniji dio gotovo svake aplikacije. Stoga testiranje baze podataka zahtijeva veliku pažnju, dobre vještine pisanja SQL upita, poznavanje strukture baze podataka i odgovarajuću pripremu.

Kako bismo bili sigurni da je testiranje učinkovito, mora se dodijeliti osobi koja posjeduje sve četiri navedene kvalitete. U protivnom će nakon isporuke proizvoda najvjerojatnije doći do netočnog ili nenamjernog ponašanja aplikacije, grešaka koje će kupac pronaći.

Ciljevi metodologije:	Testiranje metoda i procesa pristupa bazi podataka neovisno o korisničkom sučelju, tako da se mogu promatrati i zabilježiti neispravni ciljni algoritmi ili oštećenje podataka.
Metodologija:	Pozovite svaku metodu ili proces pristupa bazi podataka, popunjavajući svaki s važećim i nevažećim podacima ili zahtjevima za podatke. Provjera valjanosti baze podataka kako bi se osiguralo da su podaci ispravno popunjeni i da se svi događaji baze podataka odvijaju prema očekivanjima ili provjera valjanosti vraćenih podataka kako bi se osiguralo da su točni podaci dohvaćeni kada je to potrebno.
Proročišta:
Potrebni alati:	Pomoćni programi i alati SQL baze podataka alati za generiranje podataka
Uvjeti za uspjeh:	Ova tehnika podržava testiranje svih glavnih metoda i procesa pristupa bazi podataka.
Posebne informacije:	Testiranje može zahtijevati razvojno okruženje DBMS-a ili upravljačke programe za unos ili promjenu podataka izravno u bazi podataka. Procesi se moraju pozivati ručno. Male baze podataka ili baze podataka minimalne veličine (s ograničenim brojem zapisa) trebale bi se koristiti za proširenje opsega svih oštećenih događaja.

Ispitivanje funkcija

Testiranje ciljne funkcije trebalo bi se usredotočiti na zahtjeve koji se mogu izravno pratiti do slučajeva upotrebe ili funkcija i pravila poslovnog procesa. Svrha ovih testova je provjeriti ispravnost prihvaćanja, obrade i povrata podataka, kao i pravilnu implementaciju pravila poslovnih procesa. Ova vrsta testiranja temelji se na tehnikama crne kutije, što znači da se testiranje aplikacije i njezinih internih procesa vrši interakcijom s aplikacijom pomoću grafičkog korisničkog sučelja (GUI) i analizom nalaza ili rezultata. Sljedeća tablica definira okvir testiranja preporučen za svaku aplikaciju.

Ciljevi metodologije:	Testirajte funkcionalnost cilja testiranja, uključujući navigaciju, unos, obradu i vraćanje podataka za praćenje i snimanje ciljnog algoritma.
Metodologija:	Testirajte niti ili funkcije i funkcionalnost odvojeni slučajevi upotrebe za svaki scenarij slučaja upotrebe, korištenje valjanih i nevažećih podataka kako bi se potvrdilo da: korištenjem valjanih podataka postižu se očekivani rezultati Ako se koriste nevažeći podaci, prikazuju se odgovarajuće poruke pogreške ili upozorenja sva pravila poslovnih procesa primjenjuju se u skladu s tim
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alat za stvaranje slike i oporavak baze alati za sigurnosno kopiranje i oporavak alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.) alati za generiranje podataka
Uvjeti za uspjeh:	sve glavne scenarije upotrebe sve osnovne funkcije
Posebne informacije:	Identificirajte ili opišite one elemente ili probleme (unutarnje ili vanjske) koji utječu na implementaciju i izvedbu testa značajki.

Testiranje ciklusa poslovnih procesa

Testiranje ciklusa poslovnih procesa trebalo bi oponašati zadatke koji se izvode tijekom vremena<Имя проекта>. Trebali biste definirati razdoblje, kao što je jedna godina, te izvršiti transakcije i zadatke koji će se dogoditi tijekom godine. To uključuje sve dnevne, tjedne i mjesečne cikluse, kao i događaje temeljene na datumima.

Ciljevi metodologije:	Testirajte testne ciljne procese i pozadinske procese prema potrebnim modelima poslovnih procesa i planovima za praćenje i snimanje ciljnog algoritma.
Metodologija:	Testiranje simulira nekoliko ciklusa poslovnog procesa radeći sljedeće: Testovi koji se koriste za testiranje značajki ciljnog testa bit će izmijenjeni ili prošireni kako bi se povećao broj izvođenja svake značajke radi simulacije više različitih korisnika tijekom određenog razdoblja. Sve funkcije ovisne o datumu ili vremenu izvodit će se korištenjem valjanih i nevažećih datuma i razdoblja. Sve funkcije koje se povremeno izvršavaju bit će izvršene ili pokrenute u odgovarajuće vrijeme. Testiranje će koristiti važeće i nevažeće podatke za testiranje sljedećeg: Kada se koriste valjani podaci, postižu se očekivani rezultati. Ako se koriste nevažeći podaci, prikazuju se odgovarajuće poruke pogreške ili upozorenja. Sva pravila poslovnih procesa primjenjuju se u skladu s tim.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alat za stvaranje slike i oporavak baze alati za sigurnosno kopiranje i oporavak alati za generiranje podataka
Uvjeti za uspjeh:	Ova tehnika podržava testiranje svih kritičnih ciklusa poslovnih procesa.
Posebne informacije:	Datumi i događaji sustava mogu zahtijevati posebne zadatke podrške. Za utvrđivanje relevantnih zahtjeva i postupaka testiranja potreban je model poslovnog procesa.

Testiranje korisničkog sučelja

Testiranje korisničkog sučelja (UI) testira interakciju korisnika sa softverom. Cilj testiranja korisničkog sučelja je osigurati da korisničko sučelje korisniku pruža odgovarajući pristup i navigaciju do značajki cilja testiranja. Testiranje korisničkog sučelja također pomaže osigurati da objekti u korisničkom sučelju rade prema očekivanjima i da su u skladu s korporativnim ili industrijskim standardima.

Ciljevi metodologije:	Testirajte sljedeće za praćenje i bilježenje usklađenosti sa standardima i ciljnim algoritmom: Navigacija ciljnog testa, odražavajući funkcije i zahtjeve poslovnog procesa, uključujući metode prozor-prozor, polje-polje i korištenje metoda pristupa (tipke tabulatora, pokreti miša, tipkovnički prečaci). Možete testirati objekte i karakteristike prozora kao što su izbornici, veličina, izgled, stanje i fokus.
Metodologija:	Stvorite ili modificirajte testove po prozoru kako biste provjerili ispravnu navigaciju i stanja objekta za svaki prozor aplikacije i objekt.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva alat za automatizaciju testne skripte.
Uvjeti za uspjeh:	Ova tehnika podržava testiranje svakog početnog zaslona ili prozora koji će korisnici široko koristiti.
Posebne informacije:	Ne može se pristupiti svim svojstvima prilagođenih objekata i objekata trećih strana.

Profiliranje izvedbe

Profiliranje performansi je test performansi koji mjeri i procjenjuje vrijeme odziva, brzine transakcija i druge zahtjeve koji su vremenski osjetljivi. Svrha profiliranja izvedbe je provjera jesu li zahtjevi izvedbe postignuti. Profiliranje performansi implementira se i izvodi kako bi se profilirali i poboljšali algoritmi izvedbe cilja testa kao funkcije uvjeta kao što su radno opterećenje ili konfiguracija hardvera.

Bilješka: Transakcije navedene u sljedećoj tablici klasificirane su kao "transakcije logičnog poslovnog procesa". Te se transakcije definiraju kao specifični slučajevi upotrebe za koje se očekuje da će ih entitet izvršiti koristeći cilj testiranja, kao što je dodavanje ili izmjena određenog ugovora.

Ciljevi metodologije:	Testirajte algoritme za određene funkcionalne transakcije ili funkcije poslovnih procesa pod sljedećim uvjetima kako biste promatrali i zabilježili ciljni algoritam i podatke o izvedbi aplikacije:
Metodologija:	Primijenite postupke testiranja namijenjene testiranju funkcija i ciklusa poslovnih procesa. Modificiranje podatkovnih datoteka za povećanje broja transakcija ili skripti za povećanje broja ponavljanja izvedenih u svakoj transakciji. Skripte se trebaju izvoditi na istom sustavu ( najbolja opcija- započnite s jednim korisnikom, jednom transakcijom) i ponovite s više klijenata (virtualnih ili stvarnih, pogledajte posebne informacije u nastavku).
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alat za profiliranje performansi aplikacije kao što je Rational Quantify alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.)
Uvjeti za uspjeh:	Ova tehnika podržava testiranje: Jedna transakcija ili jedan korisnik: Uspješno oponašajte transakcijske scenarije bez neuspjeha zbog problema s implementacijom testa. Više transakcija ili više korisnika: Uspješno emulirajte radno opterećenje bez neuspjeha zbog problema s implementacijom testa.
Posebne informacije:	Sveobuhvatno testiranje performansi uključuje pozadinsko opterećenje poslužitelja. Postoji nekoliko metoda koje se mogu koristiti, uključujući sljedeće: "Isporuka transakcija" izravno na poslužitelj, obično u obliku poziva Structured Query Language (SQL). Stvaranje "virtualnog" korisničkog opterećenja za simulaciju nekoliko klijenata, obično nekoliko stotina. Za postizanje ovog opterećenja koriste se alati za emulaciju daljinskog terminala. Ova se tehnika također može koristiti za preplavljivanje mreže "streamom podataka". Da biste opteretili sustav, koristite nekoliko fizičkih klijenata, od kojih svaki pokreće testne skripte. Testiranje performansi trebalo bi se provesti na namjenskom sustavu ili u određeno vrijeme. To omogućuje potpunu kontrolu i točna mjerenja. Baze podataka koje se koriste za testiranje performansi moraju biti stvarne veličine ili jednako skalirane.

Ispitivanje opterećenja

Testiranje opterećenja je test izvedbe u kojem se cilj testa podvrgava različitim radnim opterećenjima kako bi se izmjerili i procijenili algoritmi izvedbe i sposobnost cilja testa da nastavi ispravno funkcionirati pod različitim radnim opterećenjima. Svrha testiranja opterećenja je utvrditi i osigurati da će sustav ispravno raditi kada je izložen očekivanom maksimalnom radnom opterećenju. Testiranje opterećenja također procjenjuje parametre performansi kao što su vrijeme odziva, brzina transakcije i drugi parametri povezani s vremenom.

Bilješka: Transakcije navedene u sljedećoj tablici klasificirane su kao "transakcije logičnog poslovnog procesa". Te se transakcije definiraju kao specifične funkcije koje se od korisnika očekuju tijekom korištenja aplikacije, poput dodavanja ili mijenjanja određenog ugovora.

Ciljevi metodologije:	Izvršite određene transakcije ili varijacije poslovnog procesa pod različitim uvjetima radnog opterećenja za praćenje i snimanje ciljnog algoritma i podataka o performansama sustava.
Metodologija:	Koristite skripte za testiranje transakcija osmišljene za testiranje funkcionalnosti poslovnih procesa i ciklusa kao osnovu, ali uklonite nepotrebna ponavljanja i kašnjenja. Modificiranje podatkovnih datoteka za povećanje broja transakcija ili testova za povećanje broja izvršenja svake transakcije. Radna opterećenja trebaju uključivati - na primjer, dnevna, tjedna i mjesečna - vršna opterećenja. Radna opterećenja trebaju predstavljati i prosječna i vršna opterećenja. Radna opterećenja moraju predstavljati trenutna i dugotrajna vršna opterećenja. Radna opterećenja trebaju se testirati u različitim konfiguracijama ispitnog okruženja.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.) alati za ograničavanje resursa; na primjer, Canned Heat alati za generiranje podataka
Uvjeti za uspjeh:	Ova tehnika podržava testiranje emulacije radnog opterećenja, što je uspješna emulacija radnog opterećenja bez kvarova zbog problema s implementacijom testa.
Posebne informacije:	Testiranje opterećenja trebalo bi se provesti na namjenskom sustavu ili u određeno vrijeme. To omogućuje potpunu kontrolu i točna mjerenja. Baze podataka koje se koriste za testiranje opterećenja moraju biti stvarne veličine ili moraju biti jednako skalirane.

Ispitivanje napona

Testiranje otpornosti na stres vrsta je testa performansi koji se implementira i izvodi kako bi se razumjelo kako sustav pada pod uvjetima na ili izvan očekivanih tolerancija. Obično uključuje nedostatak resursa ili natjecanje za resurse. Uvjeti s niskim resursima pokazuju kako cilj testa ne uspijeva na način koji nije očit u normalnim uvjetima. Drugi nedostaci mogu proizaći iz sukoba za dijeljene resurse, kao što su zaključavanja baze podataka ili propusnost mreže, iako se neki od ovih testova obično izvode u testiranju značajki i opterećenja.

Ciljevi metodologije:	Testirajte funkcije ispitnog cilja pod sljedećim naponskim uvjetima kako biste promatrali i zabilježili ciljni algoritam koji identificira i dokumentira uvjete pod kojima neuspjeh sustav kako bi nastavio s radom u skladu s tim: mala količina memorije ili nedostatak slobodne memorije na poslužitelju (RAM i trajna memorija) najveći fizički ili stvarno mogući broj povezanih ili simuliranih korisnika više korisnika obavlja iste transakcije s istim podacima ili računima "pretjeran" obujam transakcija ili mješavina uvjeta (pogledajte odjeljak Profiliranje izvedbe iznad)
Metodologija:	Za testiranje ograničenih resursa, testove treba izvoditi na jednom sustavu, a RAM i trajnu memoriju na poslužitelju treba smanjiti ili ograničiti. Za druge testove napona trebalo bi koristiti više klijenata, pokrećući iste ili dodatne testove za generiranje volumena transakcije u najgorem slučaju ili kombinaciju oba.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alat za planiranje i upravljanje transakcijskim opterećenjem alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.) alati za ograničavanje resursa; na primjer, Canned Heat alati za generiranje podataka
Uvjeti za uspjeh:	Ova tehnika podržava testiranje emulacije napona. Sustav se može uspješno emulirati pod jednim ili više uvjeta, definiranih kao uvjeti stresa, a opažanja rezultirajućeg stanja sustava mogu se zabilježiti tijekom i nakon što je stanje emulirano.
Posebne informacije:	Za stvaranje stresa na mreži, možda će biti potrebni mrežni alati za punjenje mreže porukama i paketima. Trajna memorija koja se koristi za sustav trebala bi se privremeno smanjiti kako bi se ograničio raspoloživi prostor za rast baze podataka. Trebali biste sinkronizirati istovremeni pristup klijenata istim zapisima podataka ili računima.

Ispitivanje kapaciteta

Testiranje kapaciteta izlaže testni cilj velikim količinama podataka kako bi se utvrdilo jesu li dosegnuta ograničenja koja uzrokuju kvar sustava. Testiranje kapaciteta također određuje kontinuirano maksimalno opterećenje ili kapacitet koji cilj testiranja može voziti tijekom određenog razdoblja. Na primjer, ako cilj testa obrađuje skup zapisa baze podataka za generiranje izvješća, test kapaciteta će koristiti veliku testnu bazu podataka i potvrditi da softver dobro radi i daje ispravno izvješće.

Ciljevi metodologije:	Testirajte funkcionalnost testnog cilja u sljedećim scenarijima velikog kapaciteta kako biste promatrali i zabilježili ciljni algoritam: Maksimalni (stvarni ili fizički mogući) broj povezanih ili simuliranih klijenata koji obavljaju istu (najlošiju u smislu izvedbe) funkciju poslovnog procesa tijekom dugog razdoblja. Dosegnuta je maksimalna veličina (stvarna ili skala) baze podataka i istovremeno se izvodi više upita ili transakcija izvješćivanja.
Metodologija:	Koristite testove dizajnirane za profiliranje performansi ili testiranje opterećenja. Treba koristiti više klijenata za izvođenje istih ili dodatnih testova za generiranje najgoreg slučaja količine transakcija ili njihove kombinacije (vidi testiranje otpornosti na stres) tijekom duljeg razdoblja. Izrađuje se maksimalna veličina baze podataka (stvarna, skalirana ili popunjena reprezentativnim podacima) i više klijenata se istovremeno koristi za pokretanje upita i izvješćivanje o transakcijama tijekom duljeg razdoblja.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte alat za planiranje i upravljanje transakcijskim opterećenjem alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.) alati za ograničavanje resursa; na primjer, Canned Heat alati za generiranje podataka
Uvjeti za uspjeh:	Ova tehnika podržava testiranje emulacije kapaciteta. Veliki broj korisnika, podataka, transakcija ili drugih aspekata korištenja sustava može se uspješno emulirati i promatrati promjene u stanju sustava tijekom testiranja kapaciteta.
Posebne informacije:

Testiranje sigurnosti i kontrole pristupa

Testiranje sigurnosti i kontrole pristupa usredotočeno je na dva ključna područja sigurnosti:

Zaštita na razini aplikacije, uključujući pristup podacima ili funkcijama poslovnih procesa

Sigurnost na razini sustava, uključujući prijavu ili daljinski pristup sustavu

Na temelju potrebne razine zaštite, zaštita na razini aplikacije osigurava da subjekti imaju pristup samo određenim značajkama ili slučajevima upotrebe ili da su im dostupni podaci ograničeni. Na primjer, unos podataka i kreiranje novih računa može se dopustiti svima, ali brisanje - samo upraviteljima. Ako postoji sigurnost na razini podataka, testiranje osigurava da "korisnik tipa 1" ima pristup svim informacijama o klijentu, uključujući financijske podatke, dok "korisnik tipa 2" ima pristup samo demografskim podacima o tom istom kupcu.

Sigurnost na razini sustava osigurava da samo korisnici sa sistemskim dozvolama imaju pristup aplikacijama i to samo putem odgovarajućih pristupnika.

Ciljevi metodologije:	Testirajte cilj testiranja pod sljedećim uvjetima kako biste promatrali i zabilježili ciljni algoritam: Zaštita na razini aplikacije: subjekt ima pristup samo onim funkcijama i podacima za koje korisnik ove vrste ima pravo pristupa. Sigurnost na razini sustava: Pristup aplikacijama ograničen je na one s dopuštenjima za sustav i aplikacije.
Metodologija:	Sigurnost na razini aplikacije: Definirajte i navedite sve vrste korisnika te funkcije i podatke kojima je dopušten pristup svakoj vrsti korisnika. Kreirajte testove za svaki tip korisnika i provjerite sva prava pristupa kreiranjem transakcija definiranih za svaki tip korisnika. Promjena tipa korisnika i ponovno pokretanje testova za iste korisnike. U svakom slučaju, provjera je li pristup dodatnim funkcijama ili podacima ispravno dopušten ili odbijen. Pristup na razini sustava: Pogledajte posebne informacije u nastavku.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: Alat za automatizaciju testne skripte "Hakerski" alati za testiranje i pronalaženje sigurnosnih rupa Alati za sigurnosnu administraciju OS-a
Uvjeti za uspjeh:	Ova metodologija podržava testiranje relevantnih značajki i podataka na koje utječu sigurnosne postavke za svaku poznatu vrstu korisnika.
Posebne informacije:	Pristup sustavu treba provjeriti i raspraviti s odgovarajućim administratorima sustava ili mreže. Ovo testiranje možda neće biti potrebno jer može biti dio funkcija administracije mreže ili sustava.

Testiranje oporavka od katastrofe

Testiranje oporavka od katastrofe potvrđuje da se testni cilj može uspješno oporaviti od raznih kvarova hardvera, softvera i mreže s velikim gubitkom podataka ili integriteta podataka.

Za sustave koji moraju nastaviti s radom, testiranje oporavka od katastrofe osigurava da, u slučaju oporavka od kvara, alternativni ili rezervni sustavi ispravno "preuzmu" sustav koji je otkazao bez gubitka podataka ili transakcija.

Testiranje oporavka je antagonistički proces testiranja u kojem je aplikacija ili sustav izložen ekstremnim uvjetima ili simuliranim uvjetima koji uzrokuju kvar, kao što su I/O kvarovi uređaja ili nevažeći pokazivači i ključevi baze podataka. Pokreću se procesi oporavka i aplikacija ili sustav se nadziru i kontroliraju kako bi se potvrdilo da je postignut pravilan oporavak aplikacije ili sustava i podataka.

Ciljevi metodologije:	Simulirajte uvjete kvara i testirajte procese oporavka (ručno i automatski) baze podataka, aplikacija i sustava u željeno poznato stanje. Za praćenje i snimanje algoritma rada nakon oporavka, u testiranje su uključene sljedeće vrste uvjeta: prekid napajanja u sustavu klijenta prekid napajanja u poslužiteljskom sustavu prekid veze preko mrežnih poslužitelja prekinuta veza ili gubitak napajanja DASD-a (uređaji za izravni pristup memoriji) i DASD kontrolera nepotpuni ciklusi (prekid procesa filtriranja podataka, prekid procesa sinkronizacije podataka) nevažeći pokazivači i ključevi baze podataka nevažeće ili oštećene stavke podataka u bazi podataka
Metodologija:	Možete koristiti već izrađene testove za testiranje funkcionalnosti poslovnih procesa i ciklusa kao osnovu za stvaranje niza transakcija za podršku testiranju oporavka. Prvi korak je identificirati testove za uspjeh oporavka. Prekid napajanja u sustavu klijenta: Isključite računalo. Prekid napajanja sustava poslužitelja: Simulira ili pokreće postupke za isključivanje poslužitelja. Prekid putem mrežnih poslužitelja: Simulira ili inicira gubitak mrežne veze (fizičko odspajanje spojnih žica ili isključivanje napajanja mrežnih poslužitelja ili usmjerivača). Prekid veze ili gubitak napajanja DASD-ova i DASD kontrolera: simulacija ili fizički gubitak veze s jednim ili više DASD-ova ili DASD kontrolera. Kada se dostignu gornji ili simulirani uvjeti, treba izvršiti dodatne transakcije i pokrenuti postupke oporavka kada se postigne ovaj drugi testni korak. Kod testiranja nepotpunih petlji koristi se ista metodologija kao što je gore opisano, osim što se sami procesi baze podataka moraju prekinuti ili prekinuti prije vremena. Testiranje sljedećih uvjeta zahtijeva postizanje poznatog stanja baze podataka. Nekoliko polja baze podataka, pokazivača i ključeva mora biti oštećeno ručno i izravno u bazi podataka (pomoću alata baze podataka). Dodatne transakcije trebale bi se izvršiti korištenjem testova iz ciklusa testiranja značajki aplikacije i poslovnih procesa te potpuno završenih ciklusa.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: alat za stvaranje slike i oporavak baze alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.) alati za sigurnosno kopiranje i oporavak
Uvjeti za uspjeh:	Ova tehnika podržava testiranje: Jedan ili više simuliranih kvarova koji uključuju jednu ili više kombinacija aplikacija, baze podataka i sustava. Jedan ili više simuliranih oporavka, koji uključuju jednu ili više kombinacija aplikacija, baze podataka i sustava, u poznato željeno stanje.
Posebne informacije:	Testiranje oporavka uvelike je nametljivo. Postupci za odspajanje električnih kabela (kada se simulira napajanje ili gubitak veze) možda nisu poželjni ili izvedivi. Mogu biti potrebne alternativne metode kao što su dijagnostički softverski alati. Zahtijeva resurse iz sustava (ili računalnih operacija), baza podataka i mrežnih grupa. Ove testove treba izvoditi izvan uobičajenog radnog vremena ili na izoliranom sustavu.

Testiranje konfiguracije

Konfiguracijsko testiranje provjerava izvedbu testnog cilja pod različitim hardverskim i softverskim konfiguracijama. U većini radnih okruženja specifične hardverske specifikacije za klijentske radne stanice, mrežne veze i poslužitelje baze podataka mogu varirati. Klijentske radne stanice mogu imati različit učitan softver (npr. aplikacije, upravljačke programe i tako dalje), a mnoge različite kombinacije softvera mogu biti aktivne u isto vrijeme, koristeći različite resurse.

Ciljevi metodologije:	Provjerava cilj testa u potrebnim hardverskim i softverskim konfiguracijama za promatranje i snimanje ciljnog algoritma u različitim konfiguracijama i utvrđivanje razlika u statusu konfiguracije.
Metodologija:	Primjena funkcionalnih testova. Otvaranje i zatvaranje različitog softvera koji nije povezan s testiranjem, kao što su Microsoft® Excel® i Microsoft® Word® aplikacije, bilo kao dio testa ili prije izvođenja testa. Izvršite odabrane transakcije za simulaciju interakcije entiteta s ciljnim i netestnim ciljnim softverom. Ponovite gornji postupak, minimizirajući dostupnu glavnu memoriju na radnoj stanici klijenta.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: alat za stvaranje slike i oporavak baze alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.)
Uvjeti za uspjeh:	Ova tehnika podržava testiranje jedne ili više kombinacija ciljnih elemenata testa koji se izvode u očekivanim podržanim razvojnim okruženjima.
Posebne informacije:	Koji je neciljani softver potreban, dostupan i dostupan na radnoj površini? Koje se aplikacije najčešće koriste? Na temelju kojih podataka rade aplikacije? na primjer, velika proračunska tablica otvorena u Excelu ili dokument od 100 stranica u Wordu? Kao dio ovog testa, također biste trebali dokumentirati mrežu, mrežne poslužitelje i baze podataka sustava općenito.

Testiranje instalacije

Testiranje instalacije ima dvije svrhe. Prvo je provjeriti može li se softver instalirati (npr nova instalacija, ažuriranje i puna ili prilagođena instalacija) pod raznim standardnim i nestandardnim uvjetima. Neuobičajeni uvjeti uključuju nedovoljno prostora na disku, nedostatne dozvole za stvaranje direktorija i tako dalje. Druga je svrha provjeriti radi li softver ispravno nakon instalacije. Obično se to postiže izvođenjem niza testova namijenjenih testiranju funkcionalnosti.

Ciljevi metodologije:	Izvršite probnu ciljnu instalaciju na svakoj potrebnoj konfiguraciji hardvera pod sljedećim uvjetima kako biste promatrali i zabilježili ponašanje instalacije i promjene stanja konfiguracije: nova instalacija: novi sustav koji nikad prije nije instaliran<Имя проекта> ažuriranje: sustav na kojem je prethodno instaliran<Имя проекта>, ista verzija ažuriranje verzije: sustav na kojem je prethodno instaliran<Имя проекта>, ranija verzija
Metodologija:	Razvijte automatizirane ili ručne skripte za testiranje stanja ciljanog sustava. novi:<имя проекта>nikad instaliran <имя проекта>već je instalirana ista ili starija verzija Pokrenite ili dovršite instalaciju. Primjena unaprijed određenog podskupa scenarija testiranja funkcija, izvršavanje transakcija.
Proročišta:	Navedite jednu ili više strategija koje se mogu koristiti u tehnici za ispravno promatranje rezultata ispitivanja. Proročanstvo kombinira elemente metode kojom se promatranje može izvesti i karakteristike određenog ishoda koje ukazuju na mogući uspjeh ili neuspjeh. U idealnom slučaju, proročanstva će izvršiti samoprovjeru, omogućujući početnu procjenu uspjeha ili neuspjeha automatiziranim testovima. Međutim, trebali biste biti svjesni rizika povezanih s automatskim utvrđivanjem rezultata.
Potrebni alati:	Ova tehnika zahtijeva sljedeće alate: alat za stvaranje slike i oporavak baze alati za praćenje instalacije (registar, tvrdi disk, CPU, memorija itd.)
Uvjeti za uspjeh:	Ova tehnika podržava testiranje instalacije razvijenog proizvoda u jednoj ili više konfiguracija instalacije.
Posebne informacije:	Kakve transakcije<имя проекта>treba odabrati kako bi pružio pouzdan test koji aplikacija<имя проекта>je uspješno instaliran i da nije nedostajala nijedna važna softverska komponenta?