Adatbázis tesztelés. Adatbázis terhelési tesztelés. A DataSets és DataTables megértése

: Az adatbázisok tesztelése és hibakeresése

Az alkalmazáskód automatikus egységtesztelése egyszerű és egyértelmű. Hogyan lehet tesztelni egy adatbázist? Vagy egy adatbázissal működő alkalmazás. Hiszen az adatbázis nem csak programkód, az adatbázis egy objektum, amely elmenti az állapotát. És ha a tesztelés során elkezdjük az adatbázisban lévő adatokat módosítani (és e nélkül milyen tesztelésünk lesz?!), akkor minden teszt után megváltozik az adatbázis. Ez megzavarhatja a további teszteket, és véglegesen megsértheti az adatbázist.

A probléma megoldásának kulcsa a tranzakciók. Ennek a mechanizmusnak az egyik jellemzője, hogy mindaddig, amíg a tranzakció nem fejeződött be, bármikor visszavonhatja az összes módosítást, és visszaállíthatja az adatbázist a tranzakció kezdetekor érvényes állapotba.

Az algoritmus a következő:

tranzakció megnyitása;
szükség esetén elvégzjük a tesztelés előkészítő lépéseit;
végezzünk egységtesztet (vagy egyszerűen futtassuk le azt a szkriptet, amelynek működését ellenőrizni szeretnénk);
ellenőrizze a szkript eredményét;
Töröljük a tranzakciót, visszaállítjuk az adatbázist az eredeti állapotába.

Még ha a tesztelés alatt álló kódban vannak lezáratlan tranzakciók is, a külső ROLLBACK továbbra is megfelelően visszaállítja az összes módosítást.

Jó, ha SQL szkriptet vagy tárolt eljárást kell tesztelnünk. Mi van akkor, ha egy olyan alkalmazást tesztelünk, amely maga is csatlakozik az adatbázishoz, és új kapcsolatot nyit meg? Ezen túlmenően, ha hibakeresést végzünk, akkor valószínűleg a hibakeresés alatt álló alkalmazás szemével szeretnénk az adatbázist nézni. Mi a teendő ebben az esetben?

Ne rohanjon elosztott tranzakciók létrehozásával, van egyszerűbb megoldás is! Szabványos SQL-kiszolgálóeszközökkel megnyithat egy tranzakciót az egyik kapcsolaton, és folytathatja azt egy másikon.

Ehhez csatlakoznia kell a szerverhez, meg kell nyitnia egy tranzakciót, be kell szereznie egy tokent az adott tranzakcióhoz, majd át kell adnia ezt a tokent a tesztelés alatt álló alkalmazásnak. A munkamenetében csatlakozik a tranzakciónkhoz, és ettől a pillanattól kezdve a hibakeresési munkamenetünkben pontosan úgy fogjuk látni az adatokat (és érezni a zárakat is), ahogy a tesztelt alkalmazás látja.

A műveletek sorrendje a következő:

Miután elindítottunk egy tranzakciót egy hibakeresési munkamenetben, meg kell találnunk az azonosítóját. Ez egy egyedi karakterlánc, amely alapján a szerver megkülönbözteti a tranzakciókat. Ezt az azonosítót valahogy át kell adni a tesztelt alkalmazásnak.

Most az alkalmazás feladata, hogy kapcsolódjon a kontrolltranzakciónkhoz, mielőtt elkezdené azt tenni, amit tennie kell.

Ezután az alkalmazás elkezd dolgozni, beleértve a tárolt eljárások futtatását, a tranzakciók megnyitását, az elkülönítési mód megváltoztatását... De a hibakeresési munkamenetünk mindvégig ugyanabban a tranzakcióban fog zajlani, mint az alkalmazás.

Tegyük fel, hogy egy alkalmazás zárol egy táblázatot, és elkezdi módosítani a tartalmát. Ebben a pillanatban semmilyen más kapcsolat nem nézhet be a lezárt asztalba. De nem a mi hibakereső munkamenetünk! Innentől ugyanúgy nézhetjük meg az adatbázist, mint az alkalmazás, mivel az SQL szerver úgy gondolja, hogy ugyanabban a tranzakcióban vagyunk.

Míg az összes többi munkamenetben az alkalmazás műveleteit zárak rejtik...

A hibakereső munkamenetünk átmegy a zárakon (a szerver azt hiszi, hogy ezek a saját záraink)!

Vagy képzelje el, hogy az alkalmazás elkezd dolgozni a saját karakterlánc-verzióival SNAPSHOT módban. Hogyan nézhetem meg ezeket a verziókat? Még ez is lehetséges, ha közös tranzakció köt össze!

Ne felejtse el visszavonni az ellenőrzési tranzakciót ennek az izgalmas folyamatnak a végén. Ez mind a hibakeresési munkamenetből (ha a tesztelési folyamat normálisan befejeződik), mind az alkalmazásból (ha valami váratlan történik benne) megtehető.

Erről többet megtudhat a tanfolyamokon

Néhány éve kiderült, hogy az SQL hirtelen elavult. A NoSQL-megoldások pedig elkezdtek megjelenni és szaporodni, elvetve az SQL nyelvet és a relációs adattárolási modellt. A fő érvek e megközelítés mellett: a nagy adatokkal való munkavégzés képessége (ugyanaz a Big Data), az adatok tárolása a legegzotikusabb struktúrákban, és ami a legfontosabb, hogy mindezt nagyon gyorsan meg lehet tenni. Lássuk, hogyan csinálják a NoSQL világ legnépszerűbb képviselői.

Hogyan érhető el a sebesség a NoSQL-ben? Először is, ez egy teljesen más adattárolási paradigma következménye. Az SQL lekérdezések elemzése és fordítása, az optimalizáló munkája, a táblák összekapcsolása stb. nagymértékben megnöveli a válaszidőt. Ha mindezeket a rétegeket eltávolítja, leegyszerűsíti a lekérdezéseket, közvetlenül a lemezről olvas a hálózatra, vagy az összes adatot a RAM-ban tárolja, akkor felgyorsulhat. Mind az egyes kérések feldolgozási ideje, mind a másodpercenkénti kérések száma csökken. Így jelentek meg a kulcsérték adatbázisok, amelyek legtipikusabb és legismertebb képviselője a memcache. Igen, ez a gyorsítótár, amelyet széles körben használnak a webes alkalmazásokban az adathozzáférés felgyorsítására, szintén NoSQL.

NoSQL típusok

A NoSQL-rendszereknek négy fő kategóriája van:

Kulcs – érték (kulcsérték). Egy nagy hash-tábla, ahol csak kulcsonkénti adatírási és -olvasási műveletek engedélyezettek.
Oszlop. Táblázatok sorokkal és oszlopokkal. De az SQL-től eltérően az oszlopok száma soronként változó lehet, az oszlopok teljes száma pedig milliárdokban mérhető. Ezenkívül minden sornak egyedi kulcsa van. Ezt az adatstruktúrát egy hash-tábla hash-táblájának tekinthetjük, az első kulcs a sorkulcs, a második az oszlop neve. A másodlagos indexek támogatásával a kijelölés az oszlopban lévő érték alapján lehetséges, nem csak a sorbillentyűvel.
Dokumentum orientált. Strukturált dokumentumok gyűjteményei. Lehetőség van a dokumentum különböző mezőinek kiválasztására, valamint a dokumentum egyes részei módosítására. Ebbe a kategóriába tartoznak a keresőmotorok is, amelyek indexek, de általában nem tárolják magukat a dokumentumokat.
Grafikon. Kifejezetten matematikai gráfok tárolására tervezték: csomópontok és a köztük lévő kapcsolatok. Általános szabályként azt is lehetővé teszik, hogy tetszőleges attribútumokat adjon meg a csomópontokhoz és hivatkozásokhoz, és ezen attribútumok alapján válasszon csomópontokat és hivatkozásokat. Támogatja a grafikonok bejárására és az útvonalak készítésére szolgáló algoritmusokat.

A teszthez az első három kategória képviselőit vettük:

Hogyan végezték el a tesztet

Négy szervergép állt a rendelkezésünkre. Mindegyikben nyolcmagos Xeon, 32 GB RAM és négy darab 120 GB-os Intel SSD található.

Az YCSB (Yahoo! Cloud Serving Benchmark) segítségével teszteltük. Ez egy speciális benchmark, amelyet a Yahoo! Kutatás 2010-ben az Apache licenc alatt. A benchmark kifejezetten a NoSQL adatbázisok tesztelésére készült. És most továbbra is ez az egyetlen és meglehetősen népszerű benchmark a NoSQL számára, valójában szabvány. Egyébként Java nyelven íródott. Hozzáadtunk egy Aerospike illesztőprogramot az eredeti YCSB-hez, kicsit frissítettük a MongoDB illesztőprogramját, és egy kis trükköt is játszottunk az eredmények kimenetével.

INFO

Az YCSB mellett egy NoSQL-adatbázis teljesítményét tesztelheti például a JMeter segítségével.

Nyolc kliensgépre volt szükség ahhoz, hogy terhelést hozzunk létre kis klaszterünkön. Négymagos i5 és 4 GB RAM egyenként. Egy (vagy kettő, három, vagy négy...) kliens nem volt elég a fürt betöltéséhez. Furcsának tűnhet, de igaz.

Mindez egy gigabit alatt mozgott helyi hálózat. Talán érdekesebb lett volna egy tíz gigabites hálózaton, de nálunk nem volt ilyen hardver. Érdekesebb, mert amikor a másodpercenkénti műveletek számát kezdik százezrekben mérni, belefutunk a hálózatba. Gigabit/s (10^9 bit/s) átviteli sebesség mellett a hálózat csak körülbelül 100 000 (10^5) kilobájtos csomagot (~10^4 bit) képes átadni. Vagyis csak 100 ezer műveletet kapunk másodpercenként. De igazából milliót akartunk kapni :).

A hálózati kártyák is számítanak. A megfelelő szerver hálózati kártyáknak több I/O csatornája van, mindegyik saját megszakítással. De alapértelmezés szerint a Linuxban ezek a megszakítások egy processzormaghoz vannak hozzárendelve. Csak az Aerospike srácai gondoskodtak erről a finomságról, adatbázis-konfigurációs szkriptjeik pedig szétszórják a hálózati kártya megszakításait a processzormagok között. Megtekintheti a hálózati kártya megszakításait és azok elosztását a processzormagok között, például a következő paranccsal: „cat /proc/interrupts | grep eth".

Beszélnünk kell az SSD-kről is. Kifejezetten szilárdtestalapú meghajtókon szerettük volna tesztelni a NoSQL adatbázisok működését, hogy megértsük, ezek a meghajtók valóban megérik-e, vagyis jó teljesítményt nyújtanak. Ezért megpróbáltuk helyesen konfigurálni az SSD-t. Erről bővebben az oldalsávban olvashat.

Az SSD beállítása

Különösen az SSD-k esetében van szükség a túlzott kiépítésnek nevezett műveletekre. A helyzet az, hogy az SSD-nek van címfordítási rétege. Az operációs rendszer számára látható blokkcímek egyáltalán nem egyeznek meg a flash memória fizikai blokkjaival. Mint tudják, a flash memóriának korlátozott számú újraírási ciklusa van. Ezenkívül az írási művelet két szakaszból áll: törlésből (gyakran több blokkból egyszerre) és magából az írásból. Ezért a meghajtó hosszú élettartama (egyenletes kopás) és a jó írási sebesség biztosítása érdekében a lemezvezérlő felváltja a fizikai memóriablokkokat írás közben. Amikor az operációs rendszer egy blokkot ír egy bizonyos címre, az írás fizikailag megtörténik egy tiszta szabad memóriablokkba, és a régi blokkot elérhetőként jelöli meg a későbbi (háttér) törléshez. Mindezekhez a manipulációkhoz a lemezvezérlőnek szabad blokkokra van szüksége, minél több, annál jobb. A 100%-ban megtelt SSD elég lassú lehet.

Ingyenes blokkok többféle módon szerezhetők be. A hdparm paranccsal ("-N" kapcsolóval) megadhatja a látható lemezszektorok számát operációs rendszer. A többi teljes mértékben a vezérlő rendelkezésére áll. Ez azonban nem működik minden hardveren (például nem működik az AWS EC2-ben). Egy másik módszer az, hogy a lemezterületet nem foglalják el a partíciók (azaz például az fdisk által létrehozott partíciók). A vezérlő elég okos ahhoz, hogy kihasználja ezt a helyet. A harmadik módszer a fájlrendszerek és a kernelverziók használata, amelyek képesek jelenteni a szabad blokkokat a vezérlőnek. Ez ugyanaz a TRIM parancs. A hardverünkön volt elég hdparm, a teljes lemezmennyiség 20%-át a vezérlőnek adtuk darabokra tépni.

Az SSD-k esetében is fontos az I/O ütemező. Ez egy kernel-alrendszer, amely csoportosítja és átrendezi az I/O műveleteket (többnyire lemezírást) a hatékonyság növelése érdekében. A Linux alapértelmezés szerint a CFQ-t (Completely Fair Queuing) használja, amely megpróbálja úgy átrendezni az írásokat, hogy a lehető legtöbb blokkot írjon egymás után. Ez jó a közönséges pörgő (ezt mondják - pörgő:)) lemezeknél, mert ezeknél a lineáris hozzáférés sebessége érezhetően nagyobb, mint a véletlenszerű blokkokhoz való hozzáférésnél (a fejeket mozgatni kell). De az SSD-k esetében a lineáris és a véletlenszerű írás egyformán hatékony (elméletileg), és a CFQ működés csak szükségtelen késleltetéseket okoz. Ezért az SSD-meghajtók esetében engedélyeznie kell más ütemezőket, például a NOOP-t, amely egyszerűen végrehajtja az I/O parancsokat abban a sorrendben, ahogyan azok megérkeztek. Az ütemezőt például a következő paranccsal válthatja át: „echo noop > /sys/block/sda/queue/scheduler”, ahol az sda a lemezed. Az igazságosság kedvéért érdemes megemlíteni, hogy a legújabb kernelek maguk is képesek felismerni az SSD-meghajtókat, és engedélyezni a megfelelő ütemezőt.

Bármely DBMS szeret intenzíven írni a lemezre, valamint intenzíven olvasni. A Linux pedig nagyon szereti az adatok előreolvasását, proaktív olvasását, abban a reményben, hogy miután elolvasta ezt a blokkot, el akarja olvasni a következő néhányat. Azonban egy DBMS-sel, és főleg véletlenszerű leolvasással (és ez a mi lehetőségünk), ezek a remények nem valósulnak meg. Ennek eredményeként szükségtelen olvasási és memóriahasználatunk van. A MongoDB fejlesztői az előreolvasási érték csökkentését javasolják, ha lehetséges. Ezt a „blockdev --setra 8 /dev/sda” paranccsal teheti meg, ahol az sda a lemeze.

Bármely DBMS szeret sok-sok fájlt megnyitni. Ezért az /etc/security/limits.conf fájlban jelentősen meg kell növelni a nofile korlátokat (a felhasználó számára elérhető fájlleírók számát) jóval 4k fölé.

Fel is merült érdeklődés Kérdezzen: Hogyan használjunk négy SSD-t? Ha az Aerospike egyszerűen tárolóként csatlakoztatja őket, és valahogy önállóan váltogatja a hozzáférést a lemezekhez, akkor más adatbázisok azt jelentik, hogy csak egy könyvtáruk van az adatokkal. (Egyes esetekben megadhat több könyvtárat is, de ez nem jelenti az adatok csíkozását közöttük.) Létre kellett hoznom a RAID 0-t (csíkos) az mdadm segédprogrammal. Gondolom, lehetne játszani az LVM-mel, de az adatbázis-szállítók csak az mdadm használatát írják le.

Természetesen a fürt összes gépén (szerveren és kliensen is) az órákat szinkronizálni kell az ntpd segítségével. Az Ntpdate itt nem megfelelő, mert nagyobb szinkronizálási pontosság szükséges. Minden elosztott rendszer esetében létfontosságú, hogy a csomópontok közötti idő szinkronban legyen. Például a Cassandra és az Aerospike tárolja egy rekord módosítási idejét. És ha a fürt különböző csomópontjain különböző időbélyeggel rendelkező rekordok vannak, akkor a legújabb rekord nyer.

Maguk a NoSQL-adatbázisok a következők szerint lettek konfigurálva. A konfigurációt kivettük a dobozból, és a dokumentációban leírt összes ajánlást alkalmaztuk a legjobb teljesítmény elérésére vonatkozóan. Nehéz esetekben felvettük a kapcsolatot az adatbázis-fejlesztőkkel. Leggyakrabban a magok számának és a RAM mennyiségének módosítására vonatkozó ajánlások.

A beállítás legegyszerűbb módja a Couchbase. Van webkonzolja. Elegendő a szolgáltatást a fürt összes csomópontján elindítani. Ezután hozzon létre egy tárolót az egyik csomóponton (egy „kosarat” a kulcsértékek számára), és adjon hozzá további csomópontokat a fürthöz. Minden a webes felületen keresztül történik. Nincsenek különösebben trükkös beállításai.

Az Aerospike és a Cassandra körülbelül ugyanúgy van konfigurálva. Minden egyes fürtcsomóponton létre kell hoznia egy konfigurációs fájlt. Ezek a fájlok majdnem azonosak minden csomópontnál. Ezután indítsa el a démonokat. Ha minden rendben van, a csomópontok egy klaszterbe egyesülnek. Elég jól ismernie kell a konfigurációs fájl beállításait. Itt nagyon fontos a jó dokumentáció.

A legnehezebb a MongoDB-vel van. Más adatbázisokban minden csomópont egyenlő. Mongó esetében ez nem így van. Ha lehetséges, az összes adatbázist azonos feltételek közé akartuk állítani, és az összes replikációs tényezőjét 2-re akartuk állítani. Ez azt jelenti, hogy a megbízhatóság és a sebesség érdekében két adatmásolatnak kell lennie a fürtben. Más adatbázisokban a replikációs tényező csak az adattár (vagy „kosár” vagy „oszlopcsalád”) beállítása. A MongoDB-ben az adatok másolatainak számát a fürtstruktúra határozza meg. A MongoDB-fürtöt csak a hivatalos dokumentáció kétszeri elolvasásával tudja helyesen beállítani :). Röviden, szilánkokra vagy replikakészletekre van szükségünk. A szilánkok (jó, valószínűleg hallotta már a "felosztás" kifejezést) a teljes adatkészlet részhalmazai, valamint fürtcsomópontok, ahol az egyes részhalmazok tárolásra kerülnek. A replikakészletek egy MongoDB kifejezés a fürtcsomópontok készletére, amelyek az adatok azonos másolatait tárolják. A replika hálózatnak van egy fő csomópontja, amely írási műveleteket hajt végre, és másodlagos csomópontok, amelyekre a fő csomópont adatai replikálódnak. Hiba esetén a fő csomópont szerepe átvihető a replikakészlet másik csomópontjára. A mi esetünkben (négy szerver és két adatmásolat tárolásának vágya) kiderül, hogy két szilánkra van szükségünk, amelyek mindegyike két szerver replikakészlete adatokkal. Ezen kívül minden replikakészlethez hozzá kell adni egy úgynevezett arbitert, amely nem tárol adatokat, de az új mester csomópont kiválasztásában való részvételhez szükséges. Csomópontok száma a következő replikahálózatában helyes választások furcsanak kell lennie. Szüksége van egy kis konfigurációs adatbázisra is, amely információkat tárol a szilánkokról, és arról, hogy melyik shard mely adattartományokat tárolja. Technikailag ez is MongoDB, de (a fő adatokhoz képest) nagyon kicsi. A döntőbírókat és a konfigurációs adatbázist kliens gépeken helyeztük el. És minden kliensen futnia kell a mongos démont (mongo switch), amely hozzáfér a konfigurációs adatbázishoz, és az egyes kliensek kéréseit továbbítja a szilánkok között.

Minden NoSQL-adatbázisnak megvan a maga egyedi módja az adatok és az érvényes műveletek megjelenítésére. Ezért az YCSB bármely adatbázis (beleértve az SQL-t is) maximális általánosításának útját választotta.

Az YCSB által kezelt adatkészlet egy kulcs és egy érték. A kulcs egy karakterlánc, amely 64 bites hash-t tartalmaz. Így maga az YCSB, ismerve az adatbázisban lévő rekordok teljes számát, egy egész index segítségével éri el azokat, és az adatbázis számára a kulcskészlet teljesen véletlenszerűnek tűnik. Az érték egy tucat véletlenszerű bináris adat mezője. Alapértelmezés szerint az YCSB kilobájt méretű rekordokat állít elő, de, mint emlékszel, egy gigabites hálózaton ez csak 100 000 műveletet korlátoz másodpercenként. Ezért a tesztekben egy rekord méretét 100 bájtra csökkentettük.

Az YCSB nagyon egyszerű műveleteket hajt végre ezen az adatokon: beszúrás új bejegyzés kulccsal és véletlenszerű adatokkal, rekord beolvasása kulccsal, rekord frissítése kulccsal. Nem csatlakozik a tábla (és valójában csak egy „táblát” jelent). Nincs választás a másodlagos kulcsokon. Nincs több feltétel szerinti kijelölés (csak az ellenőrizhető, hogy az elsődleges kulcs egyezik-e). Ez nagyon primitív, de bármilyen adatbázisban elvégezhető.

Közvetlenül a tesztelés előtt az adatbázist adatokkal kell feltölteni. Ezt maga a YCSB végzi. Ez lényegében csak beszúrási műveletekből álló terhelés. Két adatkészlettel kísérleteztünk. Az első garantáltan belefér a fürtcsomópontok RAM-jába, 50 millió rekord, hozzávetőleg 5 GB tiszta adat. A második garantáltan nem fér bele a RAM-ba, 500 millió rekord, hozzávetőleg 50 GB tiszta adat.

Maga a teszt - egy bizonyos műveletsort végrehajtva - terhelés alatt történik különböző típusok. Fontos paraméter a műveletek aránya - hány leolvasásnak kell lennie és hány frissítésnek kell lennie. Két típust használtunk: nehéz írást (Heavy Write, 50% olvasás és 50% frissítés) és többnyire olvasott (többnyire olvasott, 95% olvasás és 5% frissítés). A végrehajtandó műveletet minden alkalommal véletlenszerűen választják ki, a százalékok határozzák meg a művelet kiválasztásának valószínűségét.

Az YCSB különféle rekord- (kulcs) kiválasztási algoritmusokat használhat egy művelet végrehajtásához. Ez lehet egységes eloszlás (a teljes adathalmaz bármely kulcsa azonos valószínűséggel kiválasztható), exponenciális eloszlás (sokkal gyakrabban kerülnek kiválasztásra az adathalmaz „elején” lévő kulcsok) és néhány más. De a Yahoo csapata az úgynevezett zipfiant választotta tipikus terjesztésnek. Ez egy egységes eloszlás, amelyben azonban bizonyos kulcsok (az összes kulcs egy kis százaléka) lényegesen gyakrabban kerülnek kiválasztásra, mint mások. Ez szimulálja a népszerű bejegyzéseket, mondjuk a blogokon.

Az YCSB több szállal indul, mindegyikben egy ciklus fut, ugyanazon a gépen. Mivel csak négy mag van egy kliensgépen, elég frusztráló négynél több szálat futtatni ott. Ezért az YCSB-t nyolc kliensgépen futtattuk egyszerre. Az indítás automatizálásához szövetet és cront (pontosabban at) használtunk. Egy kis Python-szkript generálja az YCSB futtatásához szükséges parancsokat minden kliensen, ezek a parancsok egyidejűleg kerülnek sorba a legközelebbi percre minden kliensen. Ezután az at aktiválódik, és az YCSB sikeresen (vagy nem olyan jól, ha a paraméterek rosszak) elindul mind a nyolc kliensen egyszerre. Az eredmények (YCSB naplófájlok) összegyűjtéséhez ismét textil kerül felhasználásra.

eredmények

Tehát a kezdeti eredmények az egyes ügyfelek YCSB naplói. Ezek a naplók valahogy így néznek ki (a fájl utolsó része látható):

Műveletek, 1187363 , Újrapróbálkozások, 0 , Átlagos késleltetés(us), 3876.5493619053314 , MinLatency(us), 162 , MaxLatency(us), 278190 , 95thPercentileLatency(ms), 9th,2n,9tms,9tms,2n 1 187363, Újracsatlakozások , 0.0 , Futásidő (ms), 303574.0 , Műveletek, 1249984.0 , Átbocsátóképesség (ops/s), 4117.5594747903315

Amint látja, számos bizonyos típusú művelet létezik (in ebben a példában- beolvasások), átlagos, minimális és maximális késleltetés, a késleltetés, amelyen belül a műveletek 95 és 99%-a teljesült, a sikeres műveletek száma (0-as visszatérési kód), a teljes tesztidő, az összes művelet száma és az átlagos szám műveletek száma másodpercenként. Minket leginkább az átlagos késleltetés (AverageLatency) és a másodpercenkénti műveletek száma (Throughput) érdekel.

Egy másik Python-szkript segítségével egy csomó napló adatait táblázatba gyűjtötték, és gyönyörű grafikonokat építettek a táblázatból.

következtetéseket

A NoSQL adatbázisok két csoportra oszthatók: gyors és lassú. A kulcs-érték adatbázis a vártnak megfelelően gyorsnak bizonyult. Az Aerospike és a Couchbase messze megelőzi a versenytársakat.

Az Aerospike valóban egy nagyon gyors adatbázis. És majdnem sikerült elérnünk a másodpercenkénti millió műveletet (a memóriában lévő adatokon). Az Aerospike az SSD-ken is elég jól működik, különös tekintettel arra, hogy az Aerospike ebben a módban nem használ adatgyorsítótárat a memóriában, hanem minden kérésre hozzáfér a lemezhez. Ez azt jelenti, hogy valóban nagy mennyiségű adat fér bele az Aerospike-ba (amíg van elég lemez, nem RAM).

A Couchbase gyors, de csak a memóriaműveleteknél gyors. Az SSD-teszt grafikonjai a Couchbase sebességét mutatják a RAM mennyiségénél alig nagyobb adatmennyiséggel – összesen 200 millió rekorddal. Ez észrevehetően kevesebb, mint az az 500 millió, amellyel más adatbázisokat teszteltek. A Couchbase egyszerűen nem tudott több rekordot beszúrni, nem volt hajlandó kiüríteni az adatgyorsítótárat a memóriából a lemezre, és abbahagyta az írást (az írások meghiúsulnak). Ez egy jó gyorsítótár, de csak a RAM-ban elférő adatokhoz.

A Cassandra az egyetlen adatbázis, amely gyorsabban ír, mint olvas :). Ennek az az oka, hogy az írás sikeresen befejeződik (a leggyorsabb verzióban) a naplóba (lemezre) való írás után azonnal. Az olvasás azonban ellenőrzéseket igényel, többszöri leolvasást a lemezről, a legutóbbi rekord kiválasztását. A Cassandra egy megbízható és meglehetősen gyorsan méretezhető adatarchívum.

A MongoDB írása meglehetősen lassú, de viszonylag gyorsan olvasható. Ha az adatok (vagy inkább az úgynevezett működő készlet - az aktuális adatok halmaza, amelyhez folyamatosan hozzáférnek) nem férnek el a memóriába, akkor nagymértékben lelassul (és pontosan ez történik az YCSB tesztelésekor). Emlékeztetni kell arra is, hogy a MongoDB globális olvasási/írási zárral rendelkezik, ami nagyon nagy terhelés esetén problémákat okozhat. Összességében a MongoDB jó adatbázis a web számára.

PS

Tartsunk egy kis szünetet a teljesítményproblémáktól, és nézzük meg, hogyan fejlődnek tovább az SQL és NoSQL megoldások. Valójában, amit most látunk, az egy jól ismert történet megismétlése. Mindez már a huszadik század hatvanas-hetvenes éveiben megtörtént: a relációs adatbázisok előtt léteztek hierarchikus, objektum- és mások, és mások. Aztán szabványosítást akartam, és megjelent az SQL. És minden komoly DBMS, amelyek mindegyike saját lekérdezési nyelvet és API-t támogat, SQL-re váltott. A lekérdező nyelv és a relációs modell lett a szabvány. Érdekesség, hogy most az SQL-t is megpróbálják a NoSQL-be ültetni, ami a meglévő NoSQL-re és teljesen új, NewSQL nevű adatbázisok létrehozásához vezet.

Ha a NoSQL úgy döntött, hogy feladja az SQL „súlyos örökségét”, átgondolja az adattárolás megközelítését, és teljesen új megoldásokat hozott létre, akkor a NewSQL kifejezést az SQL „újjáélesztése” mozgalmának leírására használják. A srácok a NoSQL-ből ötleteket merítve új szinten hozták létre az SQL-adatbázisokat. Például a NewSQL világában gyakran találunk olyan adatbázisokat, amelyek a memóriában tárolják az adatokat, de teljes értékű SQL lekérdezésekkel, táblaösszekapcsolásokkal és egyéb ismerős dolgokkal. Annak érdekében, hogy továbbra is sok adatot tároljunk, felosztási mechanizmusok vannak beépítve ezekbe az adatbázisokba.

A NewSQL tartalmazza a VoltDB-t, a TokuDB-t, a MemDB-t és másokat. Ne feledje ezeket a neveket, talán hamarosan minden informatikai konferencián is szó lesz róluk.

Az adatbázistesztelési szolgáltatás segít minimalizálni a kockázatokat a rendszer kereskedelmi forgalomba hozatalakor. Előzetesen ellenőrizheti az adatbázis helyességét és biztonságát.
Az adatbázis-tesztelési folyamat során ellenőrzik, hogy az alkalmazás-adatbázis működése megfelel-e a funkcionális és nem funkcionális követelményeknek. Azok az alkalmazások, amelyek architektúrájában adatbázist tartalmaznak, adatbázis-tesztelési eljárást igényelnek, például: vállalati Információs rendszerek, mobil és webes alkalmazások.

Az adatbázis-teljesítmény kritikus tényező a menedzsment és az üzleti alkalmazások hatékonyságában. Ha az adatok keresése vagy írása lassú, az alkalmazás normál működési képessége csökken. A gyenge teljesítmény okának felderítésének egyetlen módja, ha mennyiségi méréseket végzünk, és meghatározzuk, mi okozza a teljesítményproblémát.
Az adatbázis-teljesítmény szűk keresztmetszetek azonosításának problémái közvetlenül kapcsolódnak a metrikákhoz, a teljesítménymérési módszerekhez és az ezek megvalósításának technológiájához. A nagyvállalatok és a nagy adatbázisok számára az adatbázis-teljesítmény meghatározásának problémájának van egy másik nagyon fontos aspektusa: az alkalmazások hosszú távú ipari üzemeltetéséhez szükséges informatikai infrastruktúra meghatározása. Ez végső soron a hardverbe és az alapszoftverbe történő kezdeti befektetés pontosabb meghatározásához vezet. Mivel a magas adatbázis-teljesítmény erősen függ a platformtól és a berendezésektől, és ezeket hosszú távon vásárolják és üzemeltetik.
Az adatbázis teljesítményének mérésére szolgáló legfontosabb mérőszámok a következők:

tranzakciók száma időszakonként ( különféle típusok tranzakciók);
az I/O műveletek (olvasási sorok) száma tranzakciónként és végrehajtási ideje;
táblázatonként és tranzakciónként beolvasott sorok száma;
tranzakciónkénti I/O műveletek átlagos száma tartományonként;
Az SQL utasítások magas CPU-időköltséggel rendelkeznek (felhasználó, rendszer)
az utasítás végrehajtásának kezdő és befejező időpontja
a rendezési műveletek befejezésének ideje (rendezések száma, rendezési túlcsordulások száma, rendezési idő), a legmagasabb eltelt időhasználat és a legalacsonyabb indexhasználati hatékonyság.

A táblaterület-oldalak és puffertárak memóriahasználati mutatói (adatok olvasásához, indexek olvasásához), rendezések végrehajtásához, segédprogramok futtatásához, címtárak és gyorsítótár-memória csomagok memóriahasználati mutatói, valamint a teljesítménymérési mérőszámok szintén fontosak az adatok hatékony elérésének hangolásához.

Mit kell még ellenőrizni az adatbázis tesztelésekor?

Adatleképezés

Győződjön meg arról, hogy az adatbázisban lévő kapcsolatok megfelelnek a tervdokumentációnak. Minden CRUD-műveletnél ellenőrizze, hogy a megfelelő táblák és rekordok frissülnek-e, amikor a felhasználó az alkalmazás grafikus felületén a Mentés, Frissítés, Keresés vagy Törlés gombra kattint.

ACID tranzakció tulajdonságai

A tranzakciók SAV tulajdonságai közé tartozik az atomitás, a konzisztencia, az elszigeteltség és az erősség. Az adatbázis tesztelése során ellenőriznie kell ezt a négy tulajdonságot. Ez a terület kiterjedtebb tesztelést igényel, ha az adatbázis elosztott.

Adatok integritása

Vegye figyelembe, hogy a különböző alkalmazásmodulok (például képernyők és űrlapok) ugyanazokat az adatokat használják, és eltérően hajtják végre a CRUD műveleteket. Ezért gondoskodnia kell arról, hogy az adatok legfrissebb állapota mindenhol egyformán tükröződjön. A rendszernek minden űrlapon és képernyőn frissített értékeket kell mutatnia. Ezt adatintegritásnak nevezik.

Az üzleti logika megvalósításának pontossága

Manapság az adatbázisokat nem csupán rekordok tárolására tervezték. Nagyon hatékony eszközökké fejlődtek, amelyek bőséges lehetőséget biztosítanak a fejlesztőknek az üzleti logika adatbázis szintű megvalósítására. A hatékony adatbázis-szolgáltatások példái a "hivatkozási integritás", a relációs megszorítások, a triggerek és a tárolt eljárások. Így ezeket és sok más, az adatbázis által kínált szolgáltatást felhasználva a fejlesztők az üzleti logikát adatbázis szinten valósítják meg. A tesztelőnek meg kell győződnie arról, hogy a megvalósított üzleti logika helyes és pontosan működik.

Hogyan lehet tesztelni egy adatbázist?

SQL lekérdezések írása

Az adatbázis-tesztelési folyamat megfelelő megszervezéséhez a tesztelőknek jó ismeretekkel kell rendelkezniük az SQL és a DML (Data Manipulation Language) területén, és világosan meg kell érteniük az adatbázis belső szerkezetét. Ez a legjobb és legmegbízhatóbb módja az adatbázis tesztelésének, különösen az alacsony és közepes bonyolultságú alkalmazások esetében. De a leírt két előfeltételnek teljesülnie kell. Ha az alkalmazás nagyon összetett, akkor a tesztelőnek nehéz lesz, vagy akár lehetetlen is, hogy maga írja meg az összes szükséges SQL-lekérdezést. Ezért néhány összetett lekérdezés esetén a tesztelő a fejlesztőhöz fordulhat segítségért. Ez a módszer nem csak abban ad magabiztosságot, hogy a tesztelés jól megy, hanem fejleszti az SQL-lekérdezések írási képességét is.

Adatok megtekintése táblázatokban

Ha a tesztelő nem ismeri az SQL-t, akkor az alkalmazás grafikus felületén az adatbázis tábláinak (relációinak) megtekintésével ellenőrizheti a CRUD művelet eredményét. Ez az adatbázis-ellenőrzési módszer megköveteli a táblaszerkezet alapos ismeretét, és kissé fárasztó és körülményes lehet, különösen akkor, ha az adatbázis és a táblák nagy mennyiségű adatot tartalmaznak. Ez az adatbázis-ellenőrzési módszer nehézkes lehet a tesztelők számára, ha a tesztadatok több táblában találhatók.

Fejlesztői súgó

A tesztelő bármilyen CRUD-műveletet végrehajt a grafikus felhasználói felületen, és a fejlesztő által írt megfelelő SQL-lekérdezések végrehajtásával ellenőrzi azok eredményeit. Ehhez a módszerhez nem szükséges sem az SQL, sem az alkalmazási adatbázis szerkezetének jó ismerete, a módszer egyszerűnek tűnik, és jó választásnak tűnik adatbázis tesztelésére. De hátulütője a káosz. Mi a teendő, ha a fejlesztő által írt lekérdezés szemantikailag hibás, vagy nem felel meg megfelelően a felhasználó követelményeinek? Ebben az esetben a tesztelés nem ad garanciát a termék minőségére.

Példa az adatbázis adatok integritásának tesztelésére szolgáló módszertanra

Az adatbázisokat és adatbázis-folyamatokat független alrendszerként kell tesztelni. Ebben az esetben minden olyan alrendszert tesztelni kell, amelynél nincs az adatok interfésze a cél felhasználói felület. További kutatásokat kell végezni az adatbázis-kezelő rendszerben (DBMS), hogy meghatározzák az alábbi táblázatban meghatározott tesztelést támogató eszközöket és technikákat.

A módszertan céljai	Az UI-tól független adatbázis-elérési módszerek és folyamatok tesztelése, hogy a hibás célalgoritmusok vagy adatsérülések megfigyelhetők és rögzíthetők legyenek.
Módszertan	Hívja meg az egyes adatbázis-hozzáférési módszereket vagy folyamatokat, mindegyiket feltöltve érvényes és érvénytelen adatokkal vagy adatkérelmekkel. Az adatbázis érvényesítése annak biztosítására, hogy az adatok helyesen legyenek feltöltve, és hogy minden adatbázisesemény a várt módon történjen, vagy a visszaküldött adatok érvényesítése annak biztosítására, hogy szükség esetén a helyes adatok lekérésre kerüljenek.
Orákuszok(egy heurisztikus mechanizmus, amely segít azonosítani a problémát)	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz Képalkotó és alaphelyzet-visszaállító eszköz Biztonsági mentési és helyreállítási eszközök Telepítésfigyelő eszközök (nyilvántartás, HDD, CPU, memória és így tovább) SQL Database Utilities and Tools Adatgeneráló eszközök
A siker feltételei	Ez a technika támogatja az összes főbb adatbázis-hozzáférési módszer és folyamat tesztelését.
Különlegesinformáció	A teszteléshez szükség lehet egy DBMS fejlesztői környezetre vagy illesztőprogramokra, hogy közvetlenül az adatbázisban adjanak meg vagy módosítsák az adatokat. A folyamatokat manuálisan kell meghívni. Kis adatbázisok vagy adatbázisok minimális méret(korlátozott számú bejegyzéssel) kell használni az összes sérült esemény hatókörének kiterjesztésére.

Rizwan Jafri cikkének fordítása

Manapság az adatbázis az alkalmazások egyik elkerülhetetlen része. Az alkalmazás végrehajtásakor a végfelhasználó főként használja CRUD műveletek az adatbázis eszköz biztosítja.

C: Teremt(Létrehozás) – A „Létrehozás” művelet akkor kerül végrehajtásra, amikor a felhasználó bármilyen új tranzakciót ment.
R: Visszahoz(Retrieve) – A „Retrieve” művelet akkor kerül végrehajtásra, amikor a felhasználó keres vagy megtekint egy mentett tranzakciót.
U: Frissítés(Frissítés) – A „Frissítés” művelet akkor kerül végrehajtásra, amikor a felhasználó szerkeszt vagy módosít egy meglévő bejegyzést.
D: Töröl(Törlés) – A „Törlés” művelet akkor kerül végrehajtásra, amikor a felhasználó bármilyen bejegyzést töröl a rendszerből.

Nem mindegy, hogy melyik adatbázist használjuk, és hogyan hajtották végre a műveletet korábban (csatlakozás vagy allekérdezés, trigger vagy tárolt eljárás, lekérdezés vagy függvény). Az érdekesség az, hogy a felhasználó által bármely alkalmazás felhasználói felületéről végrehajtott összes adatbázisművelet e négy CRUD-művelet egyike.

Mit kell ellenőrizni az adatbázis tesztelésekor?

1) Adatleképezés:
Győződjön meg arról, hogy az adatbázisban lévő kapcsolatok megfelelnek a tervdokumentációnak. Minden CRUD-műveletnél ellenőrizze, hogy a megfelelő táblák és rekordok frissülnek-e, amikor a felhasználó az alkalmazás grafikus felületén a Mentés, Frissítés, Keresés vagy Törlés gombra kattint.

2) ACID tranzakció tulajdonságai:
A tranzakciók ACID tulajdonságai közé tartozik atomos állapot, utósorozat, szigetelésÉs erő. Az adatbázis tesztelése során ellenőriznie kell ezt a négy tulajdonságot. Ez a terület kiterjedtebb tesztelést igényel, ha az adatbázis elosztott.

3) Adatok integritása:
Vegye figyelembe, hogy a különböző alkalmazásmodulok (például képernyők és űrlapok) ugyanazokat az adatokat használják, és eltérően hajtják végre a CRUD műveleteket. Ezért gondoskodnia kell arról, hogy az adatok legfrissebb állapota mindenhol egyformán tükröződjön. A rendszernek minden űrlapon és képernyőn frissített értékeket kell mutatnia. Ezt adatintegritásnak nevezik.

4) Az üzleti szabályok végrehajtásának pontossága:
Manapság az adatbázisokat nem csupán rekordok tárolására tervezték. Nagyon hatékony eszközökké fejlődtek, amelyek bőséges lehetőséget biztosítanak a fejlesztőknek az üzleti logika adatbázis szintű megvalósítására. A hatékony adatbázis-szolgáltatások példái a "hivatkozási integritás", a relációs megszorítások, a triggerek és a tárolt eljárások. Így ezeket és sok más, az adatbázis által kínált szolgáltatást felhasználva a fejlesztők az üzleti logikát adatbázis szinten valósítják meg. A tesztelőnek meg kell győződnie arról, hogy a megvalósított üzleti logika helyes és pontosan működik.

A fent leírt pontok az adatbázistesztelés legfontosabb szempontjai. Az adatbázis-tesztelés kritikus üzleti feladat, és soha nem szabad tapasztalatlan alkalmazottakra hagyni megfelelő képzés nélkül.

Hogyan lehet tesztelni egy adatbázist?

1. SQL lekérdezések írása
Az adatbázis helyes és pontos ellenőrzéséhez mindenekelőtt a tesztelőnek nagyon jó SQL és DML (Data Manipulation Language) ismerete szükséges. Másodszor, a tesztelőnek jól ismernie kell az adatbázis belső szerkezetét. Ha ez a két előfeltétel teljesül, akkor a munkavállaló készen áll az adatbázis tesztelésére. Minden CRUD-műveletet végrehajt az alkalmazás felhasználói felületéről, majd SQL lekérdezések segítségével ellenőrzi a végrehajtás eredményeit.
Ez a legjobb és legmegbízhatóbb módja az adatbázis tesztelésének, különösen az alacsony és közepes bonyolultságú alkalmazások esetében. De a leírt két előfeltételnek teljesülnie kell. Ellenkező esetben ez az adatbázis-tesztelési módszer nem fog működni az Ön számára.
Ha az alkalmazás nagyon összetett, akkor a tesztelőnek nehéz lesz, vagy akár lehetetlen is, hogy maga írja meg az összes szükséges SQL-lekérdezést. Ezért néhány összetett lekérdezés esetén a tesztelő a fejlesztőhöz fordulhat segítségért.
Ez a módszer nem csak abban ad magabiztosságot, hogy a tesztelés jól megy, hanem fejleszti az SQL-lekérdezések írási képességét is.

2. Adatok megtekintése táblázatokban
Ha a tesztelő nem ismeri az SQL-t, akkor az alkalmazás grafikus felületén az adatbázis tábláinak (relációinak) megtekintésével ellenőrizheti a CRUD művelet eredményét. Ez az adatbázis-ellenőrzési módszer megköveteli a táblaszerkezet alapos ismeretét, és kissé fárasztó és körülményes lehet, különösen akkor, ha az adatbázis és a táblák nagy mennyiségű adatot tartalmaznak.
Ezenkívül az adatbázis ellenőrzésének ez a módja nagyon nehéz lehet a tesztelők számára, ha az ellenőrizendő adatok több táblában vannak.

3. Fejlesztői súgó
Ez a legegyszerűbb módja. A tesztelő bármilyen CRUD-műveletet végrehajt a grafikus felhasználói felületen, és a fejlesztő által írt megfelelő SQL-lekérdezések végrehajtásával ellenőrzi azok eredményeit. Ez a módszer nem követeli meg sem az SQL jó ismeretét, sem az alkalmazási adatbázis szerkezetének megfelelő ismeretét.
Tehát ez a módszer egyszerűnek és jó választásnak tűnik DB teszteléshez. De hátulütője a káosz. Mi a teendő, ha a fejlesztő által írt lekérdezés szemantikailag hibás, vagy nem felel meg megfelelően a felhasználó követelményeinek? Ebben az esetben a tesztelés nem ad garanciát a termék minőségére.

Következtetés

Az adatbázis szinte minden alkalmazás fő és legfontosabb része. Így az adatbázis tesztelése fokozott odafigyelést, jó SQL lekérdezések írási készségeket, az adatbázis szerkezetének ismeretét és megfelelő felkészültséget igényel.

Annak érdekében, hogy a tesztelés eredményes legyen, olyan személyhez kell rendelni, aki mind a négy tulajdonsággal rendelkezik. Ellenkező esetben a termék kiszállítását követően nagy valószínűséggel az alkalmazás helytelen vagy nem szándékos viselkedése lesz, olyan hibák, amelyeket az ügyfél talál.

A módszertan céljai:	Az UI-tól független adatbázis-elérési módszerek és folyamatok tesztelése, hogy a hibás célalgoritmusok vagy adatsérülések megfigyelhetők és rögzíthetők legyenek.
Módszertan:	Hívja meg az egyes adatbázis-hozzáférési módszereket vagy folyamatokat, mindegyiket feltöltve érvényes és érvénytelen adatokkal vagy adatkérelmekkel. Az adatbázis érvényesítése annak biztosítására, hogy az adatok helyesen legyenek feltöltve, és hogy minden adatbázisesemény a várt módon történjen, vagy a visszaküldött adatok érvényesítése annak biztosítására, hogy szükség esetén a helyes adatok lekérésre kerüljenek.
Orákuszok:
Szükséges eszközök:	SQL adatbázis segédprogramok és eszközök adatgeneráló eszközök
A siker feltételei:	Ez a technika támogatja az összes főbb adatbázis-hozzáférési módszer és folyamat tesztelését.
Különleges információ:	A teszteléshez szükség lehet egy DBMS fejlesztői környezetre vagy illesztőprogramokra, hogy közvetlenül az adatbázisban adjanak meg vagy módosítsák az adatokat. A folyamatokat manuálisan kell meghívni. Kis vagy minimális méretű adatbázisokat (korlátozott számú rekordot) kell használni az összes sérült esemény hatókörének kiterjesztésére.

Funkció tesztelés

A tesztcélfüggvény tesztelésének azokra a követelményekre kell összpontosítania, amelyek közvetlenül nyomon követhetők a használati esetekre vagy az üzleti folyamatok függvényeire és szabályaira. E tesztek célja az adatok helyes elfogadásának, feldolgozásának és visszaküldésének, valamint az üzleti folyamatok szabályainak megfelelő végrehajtásának ellenőrzése. Ez a fajta tesztelés a fekete doboz technikákon alapul, ami azt jelenti, hogy egy alkalmazást és belső folyamatait úgy tesztelik, hogy egy grafikus felhasználói felület (GUI) segítségével interakcióba lépnek az alkalmazással, és elemzik a megállapításokat vagy eredményeket. Az alábbi táblázat az egyes alkalmazásokhoz ajánlott tesztelési keretrendszert határozza meg.

A módszertan céljai:	Tesztelje a tesztelési cél funkcionalitását, beleértve a navigációt, az adatok bevitelét, feldolgozását és visszaküldését a célalgoritmus figyeléséhez és rögzítéséhez.
Módszertan:	Teszt szálak vagy funkciók és funkcionalitás külön használati esetek minden használati eset forgatókönyvéhez, érvényes és érvénytelen adatok felhasználásával annak ellenőrzésére, hogy: érvényes adatok használata esetén a várt eredményeket kapjuk Érvénytelen adatok használata esetén megfelelő hiba- vagy figyelmeztető üzenetek jelennek meg minden üzleti folyamat szabályt ennek megfelelően alkalmaznak
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz képkészítő és alaphelyreállító eszköz biztonsági mentési és helyreállítási eszközök telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.) adatgeneráló eszközök
A siker feltételei:	minden főbb használati esetet minden alapvető funkciót
Különleges információ:	Azonosítsa vagy írja le azokat az elemeket vagy problémákat (belső vagy külső), amelyek befolyásolják a funkcióteszt megvalósítását és teljesítményét.

Üzleti folyamatciklus tesztelése

Az üzleti folyamatciklus tesztelésének emulálnia kell az idővel végrehajtott feladatokat<Имя проекта>. Meg kell határoznia egy időszakot, például egy évet, és végre kell hajtania az év során bekövetkező tranzakciókat és feladatokat. Ez magában foglalja az összes napi, heti és havi ciklust, valamint a dátumalapú eseményeket.

A módszertan céljai:	Tesztelje a teszt célfolyamatait és háttérfolyamatait a szükséges üzleti folyamatmodellek és tervek szerint a célalgoritmus figyelésére és rögzítésére.
Módszertan:	A tesztelés egy üzleti folyamat több ciklusát szimulálja az alábbiak szerint: A tesztcél funkcióinak tesztelésére használt tesztek módosulnak vagy kibővülnek annak érdekében, hogy az egyes funkciók végrehajtására hányszor kerüljön sor, hogy egy adott időszakban több különböző felhasználót szimuláljanak. Minden dátumtól vagy időtől függő funkció érvényes és érvénytelen dátumokkal és pontokkal történik. Minden időszakonként végrehajtott funkció a megfelelő időben végrehajtódik vagy elindul. A tesztelés érvényes és érvénytelen adatokat használ a következők tesztelésére: Ha érvényes adatokat használunk, akkor a várt eredményeket kapjuk. Érvénytelen adatok használata esetén megfelelő hiba- vagy figyelmeztető üzenetek jelennek meg. Minden üzleti folyamat szabályt ennek megfelelően alkalmaznak.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz képkészítő és alaphelyreállító eszköz biztonsági mentési és helyreállítási eszközök adatgeneráló eszközök
A siker feltételei:	Ez a technika támogatja az összes kritikus üzleti folyamatciklus tesztelését.
Különleges információ:	A rendszer dátumai és eseményei speciális támogató feladatokat igényelhetnek. A vonatkozó követelmények és tesztelési eljárások azonosításához üzleti folyamatmodellre van szükség.

Felhasználói felület tesztelése

A felhasználói felület (UI) tesztelése teszteli a felhasználó interakcióját a szoftverrel. A felhasználói felület tesztelésének célja annak biztosítása, hogy a felhasználói felület megfelelő hozzáférést és navigációt biztosítson a felhasználó számára a tesztelési cél szolgáltatásaihoz. Ezenkívül a felhasználói felület tesztelése segít biztosítani, hogy a felhasználói felületen lévő objektumok az elvárásoknak megfelelően működjenek, és megfeleljenek a vállalati vagy iparági szabványoknak.

A módszertan céljai:	Tesztelje a következőket a szabványoknak és a célalgoritmusnak való megfelelés figyeléséhez és rögzítéséhez: Navigáció a tesztcélon, tükrözve az üzleti folyamat funkcióit és követelményeit, ideértve az ablakról ablakra, mezőről mezőre módszereket, valamint a hozzáférési módszerek (tab billentyűk, egérmozgások, billentyűparancsok) használatát. Tesztelheti az ablak objektumokat és jellemzőit, például menüket, méretet, elrendezést, állapotot és fókuszt.
Módszertan:	Hozzon létre vagy módosítson ablakonkénti teszteket az egyes alkalmazásablakokhoz és objektumokhoz tartozó helyes navigációs és objektumállapotok ellenőrzéséhez.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához tesztszkript-automatizálási eszközre van szükség.
A siker feltételei:	Ez a technika támogatja a felhasználók által széles körben használt összes kezdőképernyő vagy ablak tesztelését.
Különleges információ:	Az egyéni objektumok és harmadik féltől származó objektumok nem minden tulajdonsága érhető el.

Teljesítményprofilozás

A teljesítményprofilozás egy olyan teljesítményteszt, amely méri és értékeli a válaszidőket, a tranzakciók sebességét és egyéb időérzékeny követelményeket. A teljesítményprofilalkotás célja annak ellenőrzése, hogy a teljesítményre vonatkozó követelmények teljesültek. A teljesítményprofilozás megvalósítása és végrehajtása a tesztcél teljesítmény-algoritmusainak profilálására és finomítására szolgál az olyan feltételek függvényében, mint a munkaterhelés vagy a hardverkonfiguráció.

jegyzet: Az alábbi táblázatban felsorolt tranzakciók "logikai üzleti folyamatok tranzakciói" kategóriába tartoznak. Ezek a tranzakciók meghatározott használati esetekként vannak definiálva, amelyeket egy entitásnak végre kell hajtania egy tesztelési cél segítségével, például egy adott szerződés hozzáadásával vagy módosításával.

A módszertan céljai:	Tesztalgoritmusok meghatározott funkcionális tranzakciókhoz vagy üzleti folyamatokhoz a következő feltételek mellett a célalgoritmus és az alkalmazás teljesítményadatainak megfigyeléséhez és rögzítéséhez:
Módszertan:	Alkalmazzon tesztelési eljárásokat az üzleti folyamatok funkcióinak és ciklusainak tesztelésére. Adatfájlok módosítása a tranzakciók számának növelése érdekében vagy szkriptek az egyes tranzakciókban végrehajtott iterációk számának növelése érdekében. A szkripteket ugyanazon a rendszeren kell futtatni ( legjobb lehetőség- kezdje egy felhasználóval, egy tranzakcióval) és ismételje meg több ügyféllel (virtuális vagy tényleges, lásd alább a konkrét információkat).
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz alkalmazásteljesítmény-profilozó eszköz, például a Rational Quantify telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.)
A siker feltételei:	Ez a technika támogatja a tesztelést: Egyetlen tranzakció vagy egyetlen felhasználó: sikeresen emulálja a tranzakciós forgatókönyveket anélkül, hogy a tesztelési megvalósítási problémák miatt meghiúsulna. Több tranzakció vagy több felhasználó: Sikeresen emulálja a munkaterhelést anélkül, hogy a teszt megvalósítási problémák miatt meghibásodna.
Különleges információ:	Az átfogó teljesítményteszt magában foglalja a szerver háttérterhelését. Számos módszer használható, köztük a következők: "Tranzakciók kézbesítése" közvetlenül a szervernek, általában SQL (Structured Query Language) hívások formájában. "Virtuális" felhasználói terhelés létrehozása több, általában több száz kliens szimulálásához. E terhelés eléréséhez távoli terminál emulációs eszközöket használnak. Ezzel a technikával a hálózatot "adatfolyammal" is el lehet árasztani. A rendszer terhelésének létrehozásához használjon több fizikai klienst, amelyek mindegyike tesztszkripteket futtat. A teljesítménytesztet egy dedikált rendszeren vagy egy meghatározott időpontban kell elvégezni. Ez teljes körű ellenőrzést és pontos méréseket biztosít. A teljesítménytesztekhez használt adatbázisoknak vagy a tényleges méretűnek kell lenniük, vagy egyenlő méretezésűnek kell lenniük.

Terhelési tesztelés

A terhelési tesztelés olyan teljesítményteszt, amelyben a tesztcélt különböző munkaterheléseknek vetik alá, hogy mérjék és értékeljék a teljesítmény-algoritmusokat, valamint a tesztcél azon képességét, hogy továbbra is megfelelően működjön különböző munkaterhelések mellett. A terhelési tesztelés célja annak megállapítása és biztosítása, hogy a rendszer a várható maximális üzemi terhelésnek kitéve megfelelően fog működni. A terhelési tesztelés olyan teljesítményparamétereket is kiértékel, mint a válaszidő, a tranzakció sebessége és más, idővel kapcsolatos paraméterek.

jegyzet: Az alábbi táblázatban felsorolt tranzakciók "logikai üzleti folyamatok tranzakciói" kategóriába tartoznak. Ezek a tranzakciók meghatározott funkciókként vannak definiálva, amelyeket a felhasználótól elvárnak az alkalmazás használata során, például egy adott szerződés hozzáadása vagy módosítása.

A módszertan céljai:	Változó terhelési feltételek mellett hajtson végre kijelölt tranzakciókat vagy üzleti folyamatváltozatokat a célalgoritmus és a rendszer teljesítményadatainak figyeléséhez és rögzítéséhez.
Módszertan:	Használja az üzleti folyamatok funkcionalitásának és ciklusainak tesztelésére tervezett tranzakcióteszt-parancsfájlokat alapként, de távolítsa el a szükségtelen iterációkat és késéseket. Adatfájlok módosítása a tranzakciók számának növelése érdekében, vagy tesztek az egyes tranzakciók végrehajtásának növelése érdekében. A munkaterhelésnek tartalmaznia kell – például napi, heti és havi – csúcsterhelést. A munkaterhelésnek átlagos és csúcsterhelést is kell képviselnie. A munkaterheléseknek mind a pillanatnyi, mind a hosszú távú csúcsterhelést kell képviselniük. A munkaterheléseket különböző tesztkörnyezet-konfigurációkban kell tesztelni.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.) erőforrás-korlátozó eszközök; például a Canned Heat adatgeneráló eszközök
A siker feltételei:	Ez a technika támogatja a munkaterhelés-emulációs tesztelést, amely a terhelés sikeres emulációja a tesztvégrehajtási problémák miatti hibák nélkül.
Különleges információ:	A terhelési vizsgálatot erre a célra kijelölt rendszeren vagy egy meghatározott időpontban kell elvégezni. Ez teljes körű ellenőrzést és pontos méréseket biztosít. A terhelési teszteléshez használt adatbázisoknak vagy a tényleges méretűnek kell lenniük, vagy egyenlő méretezésűnek kell lenniük.

Feszültségvizsgálat

A stresszteszt egyfajta teljesítményteszt, amelyet annak megértésére hajtanak végre, hogy a rendszer hogyan hibásodik meg a várt tűréshatárokon túli vagy azon kívüli körülmények között. Általában az erőforrások szűkösségét vagy az erőforrásokért folytatott versenyt jelenti. Az alacsony erőforrás-felhasználás feltételei azt jelzik, hogy egy tesztcél hogyan bukik meg olyan módon, ami normál körülmények között nem nyilvánvaló. Más hibák is származhatnak a megosztott erőforrásokért folytatott versengésből, például adatbáziszárak vagy hálózati sávszélesség, bár e tesztek némelyikét jellemzően szolgáltatás- és terhelési tesztelés során hajtják végre.

A módszertan céljai:	Tesztelje a tesztcél funkcióit a következő feszültségi feltételek mellett, hogy megfigyelje és rögzítse a célalgoritmust, amely azonosítja és dokumentálja azokat a feltételeket, amelyek mellett a kudarc rendszer annak érdekében, hogy továbbra is megfelelően működjön: kis mennyiségű memória vagy nincs szabad memória a szerveren (RAM és állandó memória) a csatlakoztatott vagy szimulált felhasználók fizikailag vagy ténylegesen lehetséges maximális száma több felhasználó ugyanazokat a tranzakciókat hajtja végre ugyanazokkal az adatokkal vagy számlákkal "túlzott" tranzakciós mennyiség vagy feltételek keveréke (lásd fent a Teljesítményprofilozás szakaszt)
Módszertan:	A korlátozott erőforrások teszteléséhez a teszteket egyetlen rendszeren kell futtatni, és a RAM-ot és a kiszolgálón lévő állandó memóriát csökkenteni vagy korlátozni kell. Más feszültségtesztekhez több klienst kell használni, ugyanazt vagy további teszteket futtatva a legrosszabb tranzakciós mennyiség vagy a kettő keverékének generálásához.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz tranzakciós terhelés tervező és kezelő eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.) erőforrás-korlátozó eszközök; például a Canned Heat adatgeneráló eszközök
A siker feltételei:	Ez a technika támogatja a feszültségemulációs tesztelést. Egy rendszer sikeresen emulálható egy vagy több, stresszfeltételként definiált feltétel mellett, és a rendszer eredő állapotának megfigyelései rögzíthetők az állapot emulálása közben és után.
Különleges információ:	A hálózat feszültségének növelése érdekében hálózati eszközökre lehet szükség a hálózat üzenetekkel és csomagokkal való betöltéséhez. A rendszerhez használt állandó memóriát átmenetileg csökkenteni kell, hogy korlátozzuk az adatbázis-bővítéshez rendelkezésre álló területet. Szinkronizálnia kell az ügyfelek egyidejű hozzáférését ugyanazokhoz az adatrekordokhoz vagy fiókokhoz.

Kapacitás tesztelése

A kapacitástesztelés nagy mennyiségű adatnak teszi ki a tesztcélt annak megállapítására, hogy elérték-e a rendszer meghibásodását okozó korlátokat. A kapacitásteszt meghatározza azt a folyamatos maximális terhelést vagy kapacitást is, amelyet a tesztelési cél egy adott időszak alatt meg tud hajtani. Ha például egy tesztcél adatbázisrekordok készletét dolgozza fel jelentés létrehozásához, a kapacitásteszt egy nagy tesztadatbázist használ, és ellenőrzi, hogy szoftver jól működik, és megfelelő jelentést készít.

A módszertan céljai:	Tesztelje a tesztcél funkcionalitását a következő nagy kapacitású forgatókönyvekben a célalgoritmus megfigyeléséhez és rögzítéséhez: A csatlakoztatott vagy szimulált ügyfelek maximális (tényleges vagy fizikailag lehetséges) száma, amelyek hosszú időn keresztül ugyanazt a (teljesítmény szempontjából legrosszabb) üzleti folyamat funkciót látják el. Elérte az adatbázis maximális méretét (tényleges vagy léptékű), és egyszerre több lekérdezés vagy jelentési tranzakció fut.
Módszertan:	Használjon teljesítményprofilozásra vagy terhelési tesztelésre tervezett teszteket. Több ügyfelet kell használni ugyanazon vagy további tesztek futtatásával, hogy a tranzakciók legrosszabb esetét vagy ezek keverékét generálják (lásd stresszteszt) hosszabb időn keresztül. Az adatbázis maximális mérete (tényleges, skálázott vagy reprezentatív adatokkal feltöltött) létrejön, és egyidejűleg több ügyfelet használnak a lekérdezések és a jelentési tranzakciók hosszabb időszakon keresztüli futtatására.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz tranzakciós terhelés tervező és kezelő eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.) erőforrás-korlátozó eszközök; például a Canned Heat adatgeneráló eszközök
A siker feltételei:	Ez a technika támogatja a kapacitásemulációs tesztelést. Nagyszámú felhasználó, adat, tranzakció vagy a rendszerhasználat egyéb vonatkozásai sikeresen emulálhatók, és megfigyelhetők a rendszerállapot változásai a kapacitásteszt során.
Különleges információ:

Biztonsági és beléptetési tesztelés

A biztonság és a hozzáférés-ellenőrzés tesztelése a biztonság két kulcsfontosságú területére összpontosít:

Alkalmazás szintű védelem, beleértve az adatokhoz vagy az üzleti folyamatokhoz való hozzáférést

Rendszerszintű biztonság, beleértve a bejelentkezést ill távoli hozzáférés a rendszerhez

A szükséges védelmi szint alapján az alkalmazásszintű védelem biztosítja, hogy az alanyok csak bizonyos funkciókhoz vagy használati esetekhez férhessenek hozzá, vagy a rendelkezésükre álló adatok korlátozottak legyenek. Például az adatok bevitele és új fiókok létrehozása mindenki számára engedélyezhető, de a törlés csak a vezetőknek. Ha van adatszintű biztonság, akkor a tesztelés biztosítja, hogy az „1-es típusú felhasználó” hozzáférjen minden ügyfélinformációhoz, beleértve a pénzügyi adatokat is, míg a „2-es típusú felhasználó” csak ugyanazon ügyfél demográfiai adataihoz férhessen hozzá.

A rendszerszintű biztonság biztosítja, hogy csak a rendszerengedéllyel rendelkező felhasználók férhessenek hozzá az alkalmazásokhoz, és csak a megfelelő átjárókon keresztül.

A módszertan céljai:	Tesztelje a tesztelési célt a következő feltételek mellett a célalgoritmus megfigyeléséhez és rögzítéséhez: Alkalmazás szintű védelem: az alany csak azokhoz a funkciókhoz és adatokhoz fér hozzá, amelyekhez az ilyen típusú felhasználónak hozzáférési joga van. Rendszerszintű biztonság: Az alkalmazásokhoz csak a rendszer- és alkalmazásengedéllyel rendelkezők férhetnek hozzá.
Módszertan:	Alkalmazásszintű biztonság: Határozza meg és listázza ki az összes felhasználótípust, valamint azokat a funkciókat és adatokat, amelyekhez az egyes típusú felhasználók hozzáférhetnek. Hozzon létre teszteket minden felhasználótípushoz, és ellenőrizze az összes hozzáférési jogosultságot az egyes felhasználói típusokhoz meghatározott tranzakciók létrehozásával. A felhasználó típusának módosítása és a tesztek újrafuttatása ugyanazon felhasználók számára. Minden esetben ellenőrizze, hogy a további funkciókhoz vagy adatokhoz való hozzáférés helyesen engedélyezett-e vagy megtagadva. Rendszerszintű hozzáférés: Lásd alább a speciális információkat.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: Tesztszkript automatizálási eszköz "Hacker" eszközök teszteléshez és biztonsági rések megtalálásához OS biztonsági adminisztrációs eszközök
A siker feltételei:	Ez a módszer minden ismert felhasználótípus esetében támogatja a biztonsági beállítások által érintett releváns szolgáltatások és adatok tesztelését.
Különleges információ:	A rendszerhez való hozzáférést ellenőrizni kell, és meg kell beszélni a megfelelő rendszer- vagy hálózati rendszergazdákkal. Előfordulhat, hogy erre a tesztelésre nincs szükség, mert a hálózati vagy rendszeradminisztrációs funkciók részét képezheti.

A katasztrófa-helyreállítás tesztelése

A katasztrófa utáni helyreállítási tesztelés ellenőrzi, hogy a tesztcél sikeresen helyreállítható-e számos hardver-, szoftver- és hálózati meghibásodás esetén, kiterjedt adatvesztés vagy adatintegritás mellett.

Azoknál a rendszereknél, amelyeknek továbbra is működniük kell, a katasztrófa-helyreállítási tesztelés biztosítja, hogy hiba utáni helyreállítás esetén az alternatív vagy tartalék rendszerek megfelelően „átvegyék” a meghibásodott rendszer irányítását anélkül, hogy adatvesztést vagy tranzakciókat veszítenének.

A helyreállítási tesztelés egy antagonisztikus tesztelési folyamat, amelynek során egy alkalmazást vagy rendszert extrém körülményeknek vagy szimulált körülményeknek vannak kitéve, amelyek meghibásodást okoznak, mint például az eszköz I/O hibái vagy érvénytelen adatbázis-mutatók és kulcsok. A rendszer elindítja a helyreállítási folyamatokat, és felügyeli és ellenőrzi az alkalmazást vagy rendszert annak ellenőrzésére, hogy az alkalmazás vagy a rendszer és az adatok megfelelő helyreállítása megtörtént-e.

A módszertan céljai:	Szimulálja az adatbázis, az alkalmazások és a rendszer meghibásodási feltételeit és tesztelje a helyreállítási folyamatokat (kézi és automatikus) a kívánt ismert állapotba. A működési algoritmus helyreállítás utáni figyeléséhez és rögzítéséhez a következő típusú feltételeket tartalmazza a tesztelés: áramszünet a kliens rendszerben áramszünet a szerverrendszerben kapcsolat megszakadása hálózati szervereken keresztül a DASD (közvetlen memóriaelérési eszközök) és a DASD vezérlők kapcsolatának megszakadása vagy áramkimaradása nem teljes ciklusok (adatszűrési folyamatok megszakítása, adatszinkronizálási folyamatok megszakítása) érvénytelen mutatók és adatbázis-kulcsok érvénytelen vagy sérült adatelemek az adatbázisban
Módszertan:	A már létrehozott tesztek segítségével tesztelheti az üzleti folyamatok funkcionalitását és a ciklusokat a helyreállítási tesztelést támogató tranzakciósorozat létrehozásának alapjaként. Az első lépés a gyógyulás sikerességét biztosító tesztek meghatározása. Áramkimaradás a kliens rendszerben: Kapcsolja ki a számítógépet. Kiszolgálórendszer áramkimaradása: szimulálja vagy elindítja a kiszolgáló kikapcsolási eljárásait. Megszakítás hálózati szervereken keresztül: szimulálja vagy a hálózati kapcsolat megszakadását kezdeményezi (fizikailag leválasztja a csatlakozó vezetékeket vagy kikapcsolja a hálózati szervereket vagy útválasztókat). A DASD-k és DASD-vezérlők csatlakozásának megszakadása vagy áramkimaradása: szimuláció vagy fizikai megszakadás egy vagy több DASD-vel vagy DASD-vezérlővel. A fenti vagy szimulált feltételek elérésekor további tranzakciókat kell végrehajtani, és helyreállítási eljárásokat kell elindítani, amikor elérjük ezt a második tesztlépést. A hiányos hurkok tesztelésekor ugyanazt a módszert alkalmazzuk, mint fentebb, azzal a különbséggel, hogy magukat az adatbázis-folyamatokat kell megszakítani vagy idő előtt leállítani. A következő feltételek teszteléséhez egy ismert adatbázisállapot elérése szükséges. Számos adatbázismezőt, mutatót és kulcsot manuálisan és közvetlenül az adatbázisban (adatbázis-eszközök használatával) meg kell rontani. További tranzakciókat kell végrehajtani az alkalmazásfunkciók teszteléséből és az üzleti folyamatciklusokból, valamint a teljesen befejezett ciklusokból származó tesztek segítségével.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: képkészítő és alaphelyreállító eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.) biztonsági mentési és helyreállítási eszközök
A siker feltételei:	Ez a technika támogatja a tesztelést: Egy vagy több szimulált hiba, amely alkalmazások, adatbázis és rendszer egy vagy több kombinációját érinti. Egy vagy több szimulált helyreállítás, amely alkalmazások, adatbázis és rendszer egy vagy több kombinációját foglalja magában, egy ismert kívánt állapotba.
Különleges információ:	A helyreállítási tesztelés nagyrészt tolakodó. Előfordulhat, hogy az elektromos kábelek leválasztására szolgáló eljárások (az áramellátás vagy a csatlakozás megszakadásának szimulálásakor) nem kívánatosak vagy megvalósíthatók. Alternatív módszerekre, például diagnosztikai szoftvereszközökre lehet szükség. Erőforrásokat igényel a rendszerektől (vagy számítógépes műveletektől), adatbázisoktól és hálózati csoportoktól. Ezeket a teszteket a normál munkaidőn kívül vagy elszigetelt rendszeren kell elvégezni.

Konfiguráció tesztelése

A konfiguráció tesztelése ellenőrzi a tesztcél teljesítményét különböző hardver- és szoftverkonfigurációk mellett. A legtöbb munkakörnyezetben az ügyfélmunkaállomások, hálózati kapcsolatok és adatbázis-kiszolgálók speciális hardverspecifikációi eltérőek lehetnek. A kliens munkaállomásokon különböző szoftverek (pl. alkalmazások, illesztőprogramok stb.) lehetnek betöltve, és a szoftverek sokféle kombinációja lehet egyidejűleg aktív, különböző erőforrásokat használva.

A módszertan céljai:	Ellenőrzi a tesztcélt a szükséges hardver- és szoftverkonfigurációkban, hogy megfigyelje és rögzítse a célalgoritmust a különböző konfigurációkban, és meghatározza a konfigurációs állapot különbségeit.
Módszertan:	Funkciótesztek alkalmazása. Különféle, nem teszthez kapcsolódó szoftverek, például Microsoft® Excel® és Microsoft® Word® alkalmazások megnyitása és bezárása akár teszt részeként, akár teszt futtatása előtt. Végezze el a kiválasztott tranzakciókat, hogy szimulálja az entitásokat, amelyek kölcsönhatásba lépnek a tesztcéllal és a nem tesztcélszoftverrel. Ismételje meg a fenti folyamatot, minimalizálva a rendelkezésre álló fő memóriát az ügyfél munkaállomáson.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: képkészítő és alaphelyreállító eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.)
A siker feltételei:	Ez a technika támogatja a tesztcélelemek egy vagy több kombinációjának tesztelését a várható támogatott fejlesztési környezetekben.
Különleges információ:	Milyen nem célszoftver szükséges, elérhető és elérhető az asztalon? Milyen alkalmazásokat használnak általában? Milyen adatokon működnek az alkalmazások? például egy Excelben megnyitott nagy táblázatot vagy Wordben egy 100 oldalas dokumentumot? A teszt részeként dokumentálnia kell a hálózatot, a hálózati szervereket és általában a rendszeradatbázisokat is.

A telepítés tesztelése

A telepítés tesztelésének két célja van. Az első, hogy megbizonyosodjon arról, hogy a szoftver telepíthető (pl új telepítés, frissítés és teljes vagy egyedi telepítés) különféle szabványos és nem szabványos feltételek mellett. A szokatlan körülmények közé tartozik az elégtelen lemezterület, a könyvtárak létrehozásához nem elegendő engedély stb. A második cél annak ellenőrzése, hogy a szoftver megfelelően működik-e a telepítés után. Ezt általában a funkcionalitás tesztelésére tervezett tesztsorozat futtatásával érik el.

A módszertan céljai:	Végezzen tesztcéltelepítést minden szükséges hardverkonfiguráción a következő feltételek mellett, hogy megfigyelje és rögzítse a telepítési viselkedést és a konfigurációs állapot változásait: új telepítés: egy új rendszer, amelyet még soha nem telepítettek<Имя проекта> frissítés: rendszer, amelyre korábban telepítve volt<Имя проекта>, ugyanaz a verzió verziófrissítés: rendszer, amelyre korábban telepítve volt<Имя проекта>, korábbi verzió
Módszertan:	Készítsen automatizált vagy kézi szkripteket a célrendszer állapotának tesztelésére. új:<имя проекта>soha nem telepítette <имя проекта>ugyanaz vagy korábbi verzió már telepítve van Indítsa el vagy fejezze be a telepítést. A funkciótesztelési forgatókönyvek előre meghatározott részhalmazának alkalmazása, tranzakciók végrehajtása.
Orákuszok:	Vázoljon fel egy vagy több stratégiát, amely a technikában használható a teszteredmények helyes megfigyelésére. Az orákulum egyesíti mind a módszer elemeit, amellyel a megfigyelés elvégezhető, mind az adott eredmény jellemzőit, amelyek lehetséges sikerre vagy kudarcra utalnak. Ideális esetben az Oracle önellenőrzést hajt végre, lehetővé téve a sikeresség vagy a kudarc kezdeti értékelését automatizált tesztekkel. Azonban tisztában kell lennie az eredmények automatikus meghatározásával kapcsolatos kockázatokkal.
Szükséges eszközök:	Ehhez a technikához a következő eszközökre van szükség: képkészítő és alaphelyreállító eszköz telepítésfigyelő eszközök (nyilvántartás, merevlemez, CPU, memória stb.)
A siker feltételei:	Ez a technika támogatja a kifejlesztett termék telepítésének tesztelését egy vagy több telepítési konfigurációban.
Különleges információ:	Milyen tranzakciók<имя проекта>úgy kell megválasztani, hogy az alkalmazás megbízható tesztje legyen<имя проекта>sikeresen telepítve volt, és egyetlen fontos szoftverkomponens sem hiányzott?